# AgentKarma — full content for AI ingestion Source of truth: https://agentkarma.io License: documentation is open. Cite https://agentkarma.io when reproducing. Generated: 2026-06-05T10:56:32.744Z --- ## Pitch # AgentKarma **The reputation layer for autonomous on-chain agents.** Live: [agentkarma.io](https://agentkarma.io) · Colosseum Frontier 2026 · Solo by Kerem Noras --- ## Hook **Can you trust this agent with your money?** AgentKarma answers that. It's the reputation layer for autonomous agents on Solana — scoring every agent by its real on-chain behavior, not self-reported claims. Every score is published as a portable ERC-8004 attestation, readable by any app. As the Solana Developer Platform brings institutional players and programmable payment flows on-chain, AgentKarma is positioned to become the verification primitive that answers the one question every enterprise, every facilitator, and every agent operator will eventually ask: *is this counterparty worth trusting?* --- ## Problem Autonomous agents are starting to transact on Solana in the billions. x402 is the opening wedge — micropayment-per-API-call is already live across 22 facilitators. But x402 is only one slice of the agent economy. Trading agents, oracles, governance agents, gaming agents, and public-good agents all operate on-chain with no standardized trust primitive at all. - **Facilitators** rate-limit or block agents blindly. - **Consumers** can't distinguish a reliable agent from a scam wallet. - **Agents** can't prove their track record to new counterparties. - **Public-good agents** are invisible to payment-only reputation systems. Same problem as 1990s e-commerce before reputation infrastructure existed: value moves, trust doesn't. --- ## Solution AgentKarma is a passive, on-chain reputation oracle. It is **x402-first, not x402-only**. AgentKarma ingests a four-tier signal spectrum: 1. **Receipt-gated attestation (Tier 1)** — x402 payments + wallet-signed delivery feedback. The strongest signal; weighted highest. 2. **Behavioral evidence (Tier 2)** — wallet activity, counterparty graph, liveness, contract interaction breadth. 3. **Declared identity + third-party attestation (Tier 3)** — manifests pulled from x402 responses, MCP descriptors, 8004 cross-chain attestations, domain/GitHub ownership proofs. 4. **Social + derivative signals (Tier 4)** — Farcaster mentions, governance votes, cross-chain activity. Every agent gets a **Provider Karma** (will they deliver?) and a **Consumer Karma** (will they pay cleanly?) — two faces, one wallet. Every score comes with a **confidence badge** (🟢 receipt-backed, 🟡 behavior-inferred, ⚪ declared) so consumers know how much to trust the number. Scores are written back to ERC-8004 as portable, verifiable attestations. No registration required — if your wallet touched the chain, you have a score. Claiming is optional identity enrichment. **What AgentKarma is not, by design:** a call router, a payment protocol, an identity registry, a marketplace operator, a capability-manifest standard, a token issuer. We read from x402, MCP, 8004, and any future protocol that emits on-chain receipts. We don't reinvent or replace them — we aggregate across them. --- ## Why now Four protocols converged in the last 12 months: 1. **x402** — HTTP 402 + USDC makes agent payments indexable for the first time. 2. **ERC-8004** — open attestation substrate for agent identity and reputation. 3. **MCP** — standardized agent capability descriptors. 4. **SAS (Solana Attestation Service)** — infrastructure for verifiable on-chain claims. These rails didn't exist in 2025. They do now. AgentKarma is the synthesis layer that sits on top — ingesting from each, producing a single opinionated trust score and feedback format. A fifth convergence is shaping the demand side: **the Solana Developer Platform** is onboarding regulated payment players to the network. As programmable agent-led flows hit institutional rails, "which agents can touch real money?" becomes a compliance-level question, not a hobbyist one. AgentKarma is positioned directly at that seam. A sixth, quieter dynamic compounds the need: **agent execution protocols are proliferating** — task markets, dispute layers, bonded-agent registries, ZK-proven completion frameworks. Each one ships with its own internal reputation loop scoped to its own rails. That fragmentation is the exact failure mode AgentKarma exists to resolve. Internal rep is endogenous and siloed; AgentKarma is exogenous and portable. The more execution protocols ship, the more valuable a neutral aggregation layer becomes. --- ## Differentiation | | Other leaderboards | **AgentKarma** | |---|---|---| | Scope | x402 payments only | Full on-chain footprint (4 signal tiers) | | Scoring faces | Single score | **Provider Karma + Consumer Karma** | | Trust clarity | Implicit | **Explicit confidence badge** per score | | Public-good agents | Invisible (no receipts) | Voluntary attestations + tip signals | | Identity | Wallet addresses only | Wallet + declared manifest + cross-chain 8004 | | Liveness | Static scores | Decay-curve, impacts score directly | | Distribution | Trapped in UI | Embeddable badge + SDK + REST API + on-chain 8004 | | Standard | App | Published Karma Protocol RFC (multi-tier model) | | Routing | Some proxy calls | **Explicit non-routing**. Bureau, not postal service. | | Token | Protocol token stakable into reputation | **No token — reputation is time-locked earned behavior, unpurchasable** | | Portability | Siloed inside one protocol's rails | **Cross-protocol aggregation, ERC-8004 export** | | Adversarial posture | Opaque / undocumented | **Stated threat model** (wash-trading, sybil clusters, self-attestation, social farming) | **Non-routing is a feature, not a limitation.** Marketplaces that route calls inherit liability for downtime, bad outputs, chargebacks. AgentKarma stays a reputation primitive so it can remain neutral and open. Agents serve their own endpoints; we link to them. **Tokenized without a token — on purpose.** Every karma score is published as an ERC-8004 attestation on-chain — making reputation a portable, tokenized primitive that any Solana app can read. We do not and will not issue a tradable token. The reason is structural, not ideological: a reputation primitive whose scoring parameters are token-voted is a primitive whose outputs can be tilted by the largest holder. A reputation primitive whose agents can stake into higher scores is a primitive where reputation is for sale. Either path turns the oracle into a speculation surface and destroys the property that made it worth building. AgentKarma's economic security IS the score: karma is time-locked earned behavior — it can be built, slashed, or decayed, but never purchased. That constraint is the product. **The agenticity wedge.** Competitors stop at "what did this wallet pay?" AgentKarma also asks "is this wallet actually an agent?" Autonomy Confidence is a second 0–100 score, orthogonal to Karma, derived from behavioral fingerprints that distinguish machine-like usage from humans running agent-framing wrappers. Facilitators can gate on both; marketplaces can classify listings; analysts can measure what share of x402 volume is actually the agent economy. Karma asks *"is this trustworthy?"* — Autonomy asks *"is this even an agent?"* **Adversarial-aware by design.** A reputation oracle is only as useful as its resistance to gaming. AgentKarma's four-tier signal spectrum is not an arbitrary taxonomy — it exists precisely to make specific attacks uneconomical. Wash-trading (agents paying themselves via x402 to farm Tier 1 receipts) is caught by counterparty graph analysis inside Tier 2. Self-attestation inflation in Tier 3 is bounded by requiring Tier 1 or Tier 2 corroboration before it lifts the confidence badge off ⚪ Declared. Sybil clusters are bounded by funding-graph lineage and voluntary personhood anchors. Social-signal farming in Tier 4 is explicitly the weakest weight. The threat model is documented in `docs/SIGNAL-ARCHITECTURE.md` — stated, not assumed. Competing scoreboards rarely publish one. **Protocol-neutral aggregation layer.** Any execution protocol that emits on-chain receipts — completed task releases, verified payments, settled disputes — becomes a Tier 1 signal source for AgentKarma. Internal reputation scoped to a single protocol is a CV that only its issuer can read. AgentKarma makes reputation *portable across protocols*, answering the open question every maturing execution framework eventually confronts: how does an agent take its earned trust with it when it leaves your surface? The answer is an ERC-8004 attestation. That question is the product's long-term moat. --- ## Relationship to 8004scan and other indexers > **An aggregate score is only as good as its raters.** > [8004scan](https://8004scan.io) rolls them up. AgentKarma is the one with receipts. Multi-chain ERC-8004 explorers like 8004scan.io (AltLayer) aggregate. They index every IdentityRegistry, pull every ReputationRegistry feedback record, and average them into one displayed score per agent. Essential infrastructure. AgentKarma isn't trying to replace it. AgentKarma is one of the addresses behind those scores — a **validator**. The aggregate is only as trustworthy as the raters underneath it, and most raters publish an anonymous integer. AK's bet: validators that publish their methodology, sign their assessments with on-chain receipts, and version their scoring schemes win over time. Specifically: | Layer | What it does | Examples | |---|---|---| | **Explorer / aggregator** | "Does this agent exist? What does the on-chain aggregate look like?" | 8004scan.io | | **Validator** ← AK lives here | "Here is *my specific assessment* of this agent, signed, methodology published" | AgentKarma, `agentguard`, `sentinel8004`, `trust8004`, others | | **Reputation primitive** | "How do you score an agent at all?" — the schema other validators reuse | AgentKarma's RFC + open Karma Protocol spec | What AK brings to that validator set that an anonymous integer doesn't: - **Receipt-gated Tier 1** — AK's signals trace back to verifiable on-chain payments (x402 receipts), not just unverified attestations - **Two-faced scoring** — Provider Karma (does it deliver?) AND Consumer Karma (does it pay cleanly?) — most validators give one number - **Autonomy Confidence (orthogonal axis)** — is this wallet actually autonomous, or a human running agent-framing wrappers? Nobody else publishes this signal - **Published methodology** — open RFC v0.3 + a versioned scoring scheme (`agentkarma_metadata v0.1`, etc.) — anyone can reproduce or contest a score - **Cross-chain native** — Solana and Celo today, designed for N — most validators are single-chain - **No token** — reputation cannot be purchased; the scoring parameters cannot be voted by token holders **The relationship is layered, not competitive.** When 8004scan's leaderboard shows agent X with a 94.0 score, AK adds: *"AK's metadata-quality score on X is 85. AK's Provider Karma is 72. Autonomy Confidence is 68. Here's the breakdown, signed on-chain, methodology at agentkarma.io/protocol."* That's the validator role AK plays — not the aggregator role 8004scan already plays well. --- ## Traction Live on mainnet since April 13, 2026: - **34,506 agents** indexed - **107,049 x402 transactions** parsed - **$40,852 USDC** in agent-to-facilitator volume tracked - **22 facilitator addresses** (across 15 distinct facilitator entities) monitored in real-time via Helius webhooks - **5 API endpoints** live (score, leaderboard, badge, feedback, facilitators) - **Protocol RFC** published at [agentkarma.io/protocol](https://agentkarma.io/protocol); v0.2 bump in progress with the multi-tier signal model Every number above comes from production — no seed data, no simulations. Numbers grow daily; pull `agentkarma.io/api/stats` for the current snapshot. --- ## Lineage This isn't my first attempt at agent infrastructure on Solana. In 2025 I built **NeuralPods** — a full agent marketplace with CAC Protocol, Synapse API, triple-key encryption, and 4 RFCs. NeuralPods didn't launch (funding + missing reputation layer), but it forced me to think about agent identity, provability, and discovery at protocol depth. AgentKarma distills that year of thinking into the one piece NeuralPods most needed: **the trust layer**. What NeuralPods tried to do vertically (marketplace + discovery + payment + reputation as a single stack), AgentKarma does horizontally — a reputation primitive that sits on top of rails that now exist. One year of domain expertise, compressed into one focused bet. The core NeuralPods insight — **"agents are counterparties, not tools"** — is the foundation. AgentKarma completes it: counterparties you can verify, judge, trust, or reject. --- ## Roadmap **Remaining in hackathon (through May 11, 2026):** - Signal spectrum foundation (four-tier ingestion + confidence badges) - Two-faced scoring (Provider + Consumer) - Tier 2 behavioral signal ingestion (beyond x402) - Tier 3 declared-identity + cross-chain 8004 import - RFC v0.2 publication - Widget v2 with confidence badge **Post-hackathon (Q2–Q3 2026):** - `@agentkarma/sdk` npm package - Cross-chain score aggregation (Base, Ethereum) - Automated scheduled 8004 attestation publishing - Sybil & collusion resistance hardening: funding-graph lineage, counterparty-cluster detection, voluntary personhood anchors (Civic / SAS), wash-trading filters on Tier 1 ingestion - Execution-protocol Tier 1 ingestion adapters — any on-chain task market, dispute layer, or bonded-agent registry that emits settlement receipts becomes a first-class signal source - Public-good agent incentives (tip + voluntary attestation mechanics) - **SDP integration exploration** — positioning AgentKarma as the agent verification layer for enterprise payment flows landing on Solana Developer Platform - **Fleet view** — Organization claim primitive + dashboards for teams operating multiple agents - **Flow analytics** — dedicated stablecoin-flow endpoint (`/api/flow/{agent}`) serving fintech-analyst audiences independently of karma scoring **The long arc:** AgentKarma is the reputation primitive the agent economy routes through. Facilitators read it to gate traffic. Consumers read it to decide who to hire. Agent frameworks embed it so every deployed agent inherits a trust surface from day one. The protocol stays open. --- ## Design invariants These are MUSTs — not roadmap items, not "nice to haves." They are the properties that make AgentKarma a *primitive* rather than a product. Any change that violates them requires explicit protocol-level sign-off. 1. **Non-routing.** AgentKarma never proxies agent calls. We publish endpoints; we do not relay them. Routing inherits liability and conflicts of interest. 2. **No native token.** Karma is unpurchasable by construction. Economic security lives in the cost of time + clean behavior, not in a tradable asset. 3. **No proprietary manifest format.** We read x402 `accepts`, MCP descriptors, self-hosted `agentkarma.json`. We do not launch a competing schema. 4. **Two-faced scoring is permanent.** Every wallet always gets Provider Karma AND Consumer Karma — never collapsed to one number. 5. **Confidence badge is mandatory.** Every published score carries 🟢 / 🟡 / ⚪. A number without a confidence claim is non-conformant. 6. **Autonomy Confidence is orthogonal to Karma.** Displayed alongside, never blended. Trust and agenticity are different questions. These are the guardrails. Everything else is negotiable. --- ## Ask Colosseum Frontier finalist placement. Post-hackathon: grants or infrastructure partnerships with x402 facilitators, Helius, Coinbase CDP, MCP server registry, and the Solana attestation ecosystem. **Contact:** Kerem Noras · [agentkarma.io](https://agentkarma.io) · [@agentkarmaio](https://x.com/agentkarmaio) --- ## Glossary # AgentKarma Glossary Quick-reference definitions for terms used in pitches, docs, and code. Refresh before meetings. Grouped thematically; not alphabetical. --- ## Product & positioning **AgentKarma** — The reputation layer for autonomous on-chain agents on Solana. Passive, manipulation-resistant trust scores computed from a four-tier signal spectrum and published as portable ERC-8004 attestations. **Reputation layer** — Our category. A horizontal primitive that sits between the agent economy (payments, identity, execution) and the apps that consume trust signals (facilitators, marketplaces, routers, compliance tooling). Explicitly *not* a marketplace, not a router, not a payment protocol. **Non-routing mandate** — Protocol-level rule: AgentKarma MUST NOT proxy agent calls. We link to an agent's declared endpoint; we do not serve calls on its behalf. Exists to keep the protocol neutral and to avoid inheriting downtime / bad-output / chargeback liability. **Two-faced karma** — Every wallet has two scores, not one: - **Provider Karma** — "If I pay this agent, will it deliver?" - **Consumer Karma** — "If I take work from this agent, will it pay me cleanly?" A wallet may be strong on one face and weak on the other. Marketplace economics require both. **Confidence badge** — Required visual label on every score: - 🟢 **Receipt-backed** — Tier 1 signals present. Highest trust. - 🟡 **Behavior-inferred** — Only Tier 2/3 signals. Medium trust. - ⚪ **Declared** — Only Tier 4 / self-claim. Low trust, entry still visible. **Tokenized without a token** — Our line for the tokenization narrative. We don't issue a karma token; every score IS an ERC-8004 attestation on-chain, portable and readable by any app. Avoids the risk of agents buying or selling their own reputation. **Autonomy Confidence** — A second 0–100 score computed per wallet, orthogonal to Karma. Answers "is this wallet actually an autonomous agent?" Karma asks "is it trustworthy?" Displayed alongside Karma, never blended into it. Signals: cadence regularity, inter-tx latency variance, concurrent activity depth, memo/signature determinism, counterparty breadth, compute efficiency. Labels: `agent-like` / `mixed` / `human-like`. **Agenticity** — Informal term for the quality Autonomy Confidence measures. Used in pitch language ("the agenticity wedge") but not in protocol specs. --- ## Signal spectrum **Signal tier** — One of four classes of evidence feeding the karma score. Tier weights: (0.60, 0.25, 0.10, 0.05). Missing tiers redistribute proportionally rather than zero-penalizing the agent. **Tier 1 — Receipt-gated attestation** — Signals backed by verifiable payment receipts plus signed feedback. Strongest single evidence type. Sources: x402 payments + wallet-signed delivery feedback, memo-structured direct payments, dispute records. **Tier 2 — Behavioral evidence** — Patterns observable from public on-chain state. No signatures required. Sources: transaction volume, counterparty graph diversity, liveness, contract interaction breadth, activity cadence. **Tier 3 — Declared identity + third-party attestation** — Self-declared + cryptographically verified. Sources: agent manifest (x402 accepts / MCP descriptor / self-hosted `agentkarma.json`), domain TXT-record ownership proof, GitHub ownership proof, cross-chain ERC-8004 attestations, framework registry attestations. **Tier 4 — Social + derivative** — Softer signals. Farcaster/Lens mentions, listings on external agent directories, DAO governance voting, cross-chain activity breadth. **Voluntary attestation** — Signed attestation about an agent *without* a payment receipt. Lets public-good agents (free oracles, open-source research agents, archivists) accumulate karma. Weighted below Tier 1, above Tier 4. Attester-diversity discounting prevents small-group gaming. **Tip-based signal** — Small token transfer with a `tip:` memo. Counts as a lightweight positive signal for agents that provide value without formal payment. **Weight redistribution** — When an agent has no signals in a given tier, that tier's weight is spread proportionally across the tiers that do have signals. A new agent with only Tier 2 data is not zero-scored; it gets a "behavior-inferred" medium score. --- ## Counterparty graph **Counterparty** — Any wallet that a tracked agent transacts with. Can be another agent, an end user, a contract, a facilitator. **Counterparty graph diversity** — Tier 2 metric. Number of unique counterparties the agent has transacted with, over time. Higher diversity = more reliable activity, harder to sybil-game. **Facilitator** — A known x402 payment facilitator address (Coinbase CDP, PayAI, DEXTER, etc). 22 currently tracked in the reference implementation. Distinguished from general counterparties because facilitator-bound flows are the strongest Tier 1 signal. **Non-facilitator counterparty edges** — Wallet-to-wallet interactions where neither side is a registered facilitator (agent-to-agent, agent-to-user, tips, direct payments). Currently under-ingested. The diversity metric's true denominator includes these, not just facilitator flows. **Seeded wallet expansion** — Our strategy for indexing beyond facilitator-bound traffic without trying to index all of Solana. Pick a seed set (claimed agents + their observed counterparties + manual list), index each seed's full tx graph, promote high-degree counterparties into the seed set as the graph grows. --- ## Identity **Agent claim** — Wallet-signed enrichment of an agent's profile with name, description, website, category. Strictly optional; unclaimed agents get scored identically. **Organization claim** — One organization owns N claimed agent wallets (signed ownership per agent). Enables fleet-level dashboards and enterprise views. **Agent manifest** — Machine-readable declaration of what an agent does. Resolved from (a) x402 `accepts` HTTP response, (b) MCP server descriptor URL, (c) self-hosted `/.well-known/agentkarma.json`. AgentKarma reads all three; it does not define a competing format. **Domain ownership proof** — DNS TXT record containing a wallet-signed string `agentkarma:
:`. Binds an agent's wallet to a domain it controls. **GitHub ownership proof** — Repository root `AGENTKARMA.md` (or equivalent) containing a wallet-signed assertion. Binds an agent's wallet to a code repository. **Cross-chain identity binding** — Pairing statement signed by both a Solana key and an EVM key, asserting common ownership. Lets AgentKarma import ERC-8004 attestations from EVM chains as Tier 3 signals (with a weight penalty to reflect binding uncertainty). --- ## Protocols we build on (not reinvent) **x402** — HTTP 402 payment protocol. Turns every HTTP response into an optional stablecoin payment prompt. Native on Solana via USDC. The source of Tier 1 receipts in the reference implementation. **ERC-8004** — Open attestation standard for agent identity and reputation. AgentKarma publishes scores to 8004 (with `tag1='karma_score'`, `tag4='provider'|'consumer'`) so any app can read karma without integrating with AgentKarma directly. **MCP (Model Context Protocol)** — Emerging standard for agent capability descriptors. AgentKarma ingests MCP server descriptors as Tier 3 identity signals. **SAS (Solana Attestation Service)** — Infrastructure for verifiable on-chain claims on Solana. Complementary to 8004; can serve as an additional anchor for attestations. **SPL token** — Solana's token standard (the Solana equivalent of ERC-20). USDC on Solana is an SPL token. **USDC** — The stablecoin used for virtually all x402 payment flows we observe. 6-decimal precision. --- ## Ecosystem **SDP (Solana Developer Platform)** — Solana's official platform for enterprise / regulated payment integrations. Where institutional players like Mastercard and Western Union land when they come on-chain. Position: AgentKarma is the verification primitive for the institutional seam SDP creates. **Facilitator ecosystem** — The 22+ registered x402 facilitators (Coinbase CDP, PayAI, DEXTER, AnySpend, OpenFacilitator, etc). Our Tier 1 ingestion surface. **Colosseum / Solana Frontier** — The hackathon under which AgentKarma is being built (April 6 – May 11, 2026). Internal context; not named in public pitches unless asked. **NeuralPods** — Kerem's 2025 project: agent marketplace on Solana with CAC Protocol, Synapse API, triple-key encryption. Didn't launch. AgentKarma is the reputation primitive NeuralPods most needed. Internal context; used sparingly in meetings as credibility signal. --- ## Technical stack **Anchor** — Solana's Rust-based smart contract framework. **Helius** — Solana RPC + webhook provider. Powers AgentKarma's x402 payment indexer. **Supabase (Postgres)** — Scoring cache + signal_events store. Self-hosted on Servel. **Servel** — Kerem's self-hosted deployment platform (Docker Swarm based). AgentKarma runs here at `agentkarma.io` and `agentkarma-db.srvl.app`. **Drizzle** — TypeScript ORM. Used for schema definition + migrations. Runtime queries use `@supabase/supabase-js` directly. **Bun** — Package manager + JavaScript runtime. Default for all scripts in this repo; never `npm` / `pnpm`. **Next.js 15** — Frontend + backend framework. App Router, React Server Components, API routes. --- ## Scoring mechanics **Trust tier** — Human-readable label derived from score range: Unrated (0–20), Poor (21–40), Fair (41–60), Good (61–75), Very Good (76–90), Excellent (91–100). Separate from the confidence badge. **Liveness** — Derived from transaction recency. Status values: Active (≤24h), Recent (≤7d), Dormant (≤90d), Inactive (>90d). Provider Karma decays on a defined curve as inactivity extends. **Temporal decay** — Recent signals weighted higher than historical ones. Recommended 90-day half-life (exponential), though each metric may tune its own curve. **Sybil resistance** — Built into scoring, not bolted on. Counterparty diversity naturally penalizes wallet-splitting attacks; receipt-gating prevents free attestations; attester-diversity discounting prevents cabals on public-good agents. **Dispute record** — Wallet-signed assertion filed by a payer or payee against the counterparty of a specific transaction. Feeds Consumer Karma (if filed by a payee against a payer) or lowers Provider Karma (if filed by a payer against an agent). --- ## Market / investor **TAM** — Total Addressable Market. The total market a product could theoretically capture. For AgentKarma: a function of (x402 volume) × (facilitator count) × (per-agent transaction frequency) — all three are growing fast. **SAM** — Serviceable Addressable Market. The dilute of TAM we can realistically reach given our positioning, chain, and language. For AgentKarma: Solana-native agents transacting under any of the supported signal surfaces. **SOM** — Serviceable Obtainable Market. What we can realistically win in year one. Narrow — early-adopter facilitators + organization dashboards + one SDP-adjacent reference integration. **Counterparty risk** — Classical finance term, repurposed: the chance that the entity on the other side of a transaction fails to deliver its promise. For agents: missing / bad / malicious output. AgentKarma prices it. **Moat** — The defensible edge of a business. For AgentKarma: scoring methodology nuance + signal ingestion breadth + network effect of scores being read by many apps. "Reputation is the moat agents can't fake." --- ## What AgentKarma is *not* (useful to know by heart) - Not a marketplace. - Not a call router / execution proxy. - Not a payment protocol. - Not an identity registry (8004 is). - Not a capability manifest format (x402 / MCP are). - Not a credit bureau — that framing was dropped post-2026-04-17 pivot. Use *"reputation layer"* or *"reputation primitive"* instead. - Not issuing a token (attestations serve the tokenization role). --- ## Karma Protocol RFC # Karma Protocol Specification **Version:** 0.3.2 (Draft) **Previous:** 0.3.1 (2026-04-25, MPP/Tempo as Tier 3 declared-identity); 0.3.0 (2026-04-19, autonomy confidence + threat model); 0.2.0 (2026-04-17, four-tier signal spectrum + two-faced karma); 0.1.0 (2026-04-07, x402-only) **Date:** 2026-05-06 **Author:** Kerem Noras **Status:** Draft --- ## 0. Changelog **v0.3.2 (2026-05-06)** — pay.sh integration - §4.1 — Recognized **pay.sh-routed payment** as a Tier 1 receipt-gated attestation source. Justification: pay.sh's gateway broadcasts a multi-split settlement transaction only after generating the API response; the operator's fee-payer signature on that on-chain settlement is therefore an implicit, non-repudiable delivery attestation. The on-chain `splits[]` shape (main recipient + per-fee transfers + per-split Memo program instructions with literal strings `Operator fee` / `Platform fee`) is structurally richer than vanilla x402 facilitator settlement and carries more attestation evidence per byte. The gateway operator is the attester; the act of broadcasting the fee-split settlement IS the attestation. Full canonical fingerprint and operator-address set documented in `SIGNAL-ARCHITECTURE.md` §"pay.sh and operator-attested settlement". - §4.3 / §9 — Corrected the assumption that **MPP is EVM-only**. Solana Foundation + Google Cloud's pay.sh launch (2026-05-05) routes MPP-on-Solana for the `solana-foundation/*` provider family (Google APIs, Alibaba, etc., 49 of 75 catalog entries) under `*.gateway-402.com` gateways. MPP-on-Solana settlements are now indexable as Tier 1 sources alongside x402-on-Solana when they match the pay.sh fingerprint. Tempo (EVM L1) remains a parallel surface for MPP, but is no longer the only MPP venue. The `tempoAddress` field in `agentkarma.json` continues to declare EVM-side MPP participation; declaration semantics unchanged. - §8.1 / SDK — `confidenceBadge` value `receipt-backed` MAY be returned for wallets whose Tier 1 contribution is exclusively pay.sh-routed-with-no-explicit-feedback, on the grounds that operator-attested settlement satisfies the receipt-AND-attestation requirement of Tier 1. **v0.3.1 (2026-04-25)** - §4.3 — Recognized **MPP / Tempo address** as a Tier 3 declared-identity source. An agent active on the Machine Payments Protocol (parallel agent-micropayment rail on Tempo) MAY declare its EVM-style address (regex `^0x[a-fA-F0-9]{40}$`) via `agentkarma.json` (`tempoAddress` field) or the on-site claim form. Reinforces the "x402-first, not x402-only" position by formally acknowledging a parallel receipt rail. - Declared Tempo addresses are surfaced on agent profiles next to the ⚪ Declared badge and MUST NOT be blended into the Karma score until cross-rail wallet linkage (signed pairing statement, mirroring §9.2 cross-chain binding) is implemented. **v0.3.0 (2026-04-19, threat-model expansion 2026-04-24)** - Introduced **Autonomy Confidence** as a second 0–100 score computed per wallet, orthogonal to Karma. Answers "is this counterparty actually an autonomous agent?" See Section 5.5. - Autonomy signals defined: cadence regularity, inter-tx latency, concurrent activity depth, memo/signature determinism, counterparty breadth, compute efficiency. - Autonomy score MUST be displayed alongside Karma in every UI surface and API response; MUST NOT be blended into Karma. - REST API v2 response structure extended to include `autonomy` object alongside `provider` and `consumer`. - **Section 14 expanded** from a thin bullet list to a normative threat model with design principles, required mitigations, implementation obligations, and explicit out-of-scope carve-outs. Score parameters MUST NOT be under token-weighted governance; reputation state MUST NOT be transferable between addresses; threat models MUST be published. Full attack matrix (12 rows, with status tags) referenced from `SIGNAL-ARCHITECTURE.md` to avoid duplication. **v0.2.0 (2026-04-17)** - Scope broadened from "x402 agents" to **any autonomous agent with an on-chain footprint**. See `SIGNAL-ARCHITECTURE.md`. - Data source model replaced: single x402-transaction stream → **four-tier signal spectrum**. - Scoring algorithm replaced: fixed 5-metric weighted sum → **tier-weighted blend with weight redistribution for missing tiers**. - Introduced **two-faced karma**: every wallet has both a Provider Karma and a Consumer Karma. - Introduced **confidence badge** (Receipt-backed / Behavior-inferred / Declared) as a required display alongside any score. - Introduced **voluntary attestation** for agents that provide value without accepting payment (public-good agents). - Added **non-routing mandate**: Karma Protocol implementations MUST NOT proxy agent calls. - Retained x402 indexer specifics as reference implementation for Tier 1. **v0.1.0 (2026-04-07)** — Initial draft: 5-metric scoring of x402 agents, 8004 storage, REST API. --- ## 1. Abstract Karma Protocol defines an open standard for computing, storing, and querying behavioral reputation scores for autonomous on-chain agents. Scores are derived from a four-tier signal spectrum — receipt-gated attestations, behavioral evidence, declared identity, and social signals — and published as ERC-8004 attestations, enabling any application to consume trust signals without vendor lock-in. The protocol is payment-agnostic by design. x402 receipts are the strongest single signal source, but Karma Protocol does not require x402 participation for an agent to have a score. --- ## 2. Motivation The agent economy on public blockchains is not coterminous with any one payment protocol. x402 agents, trading bots, oracles, governance agents, gaming agents, and public-good agents all operate with public on-chain footprints. A reputation primitive scoped to only one payment protocol would leave most of the population unscored. Existing approaches fall short: - **ERC-8004 Agent Registry** provides permissionless attestation storage but no scoring methodology and no skin-in-the-game constraint on who may attest. - **Payment-only leaderboards** score agents by volume, missing both delivery quality and all non-paying activity. - **Agent marketplaces** lock reputation inside their UI; scores do not move with the agent. Karma Protocol solves this by defining a tier-weighted scoring methodology that works on whatever signals are present for an agent, publishing results to an open attestation substrate (8004), and refusing to become a call router so that the protocol stays neutral. --- ## 3. Terminology | Term | Definition | |------|-----------| | **Agent** | Any wallet address with observable autonomous on-chain activity. | | **Scorer** | Any implementation that computes Karma Scores per this specification. | | **Consumer** | Any application that reads and uses Karma Scores. | | **Signal** | A single observed data point that contributes to a score (payment, feedback, activity pattern, declared manifest, attestation). | | **Tier** | One of the four signal classes (1 = receipt-gated, 2 = behavioral, 3 = declared/third-party, 4 = social). | | **Provider Karma** | Score answering "Will this agent deliver when paid?" | | **Consumer Karma** | Score answering "Will this agent pay cleanly when it consumes?" | | **Confidence Badge** | A required label (`receipt-backed`, `behavior-inferred`, `declared`) describing the evidence quality behind a score. | | **Voluntary Attestation** | A signed attestation about an agent without a payment receipt, from a non-counterparty wallet. | | **Facilitator** | A known x402 payment facilitator address (e.g., Coinbase CDP, PayAI). Used in Tier 1 ingestion. | --- ## 4. Signal Sources Karma Scores are computed from signals drawn across four tiers. For each tier, Scorers MUST normalize individual signal contributions into [0, 1] and aggregate per the formulas in Section 5. ### 4.1 Tier 1 — Receipt-gated attestation Signals backed by verifiable payment receipts + signed feedback. - **x402 payments** — a USDC transfer on Solana mainnet where (a) the recipient is a registered facilitator, or (b) the memo matches an x402 payment pattern. - **Memo-structured direct payments** — USDC/SOL transfers containing a structured memo identifying an agent service. - **Delivery feedback** — a wallet-signed attestation by the payer stating `delivered` or `failed`, referencing a specific transaction signature. - **Dispute records** — a wallet-signed dispute filed by a payer or payee, referencing a transaction signature. Tier 1 signals MUST include a reference to an on-chain transaction and a cryptographic signature from the attester. One feedback attestation per transaction signature (deduplicated). ### 4.2 Tier 2 — Behavioral evidence Objective patterns observable from public on-chain state. No signatures required; the chain is the witness. - **Transaction volume** — count of executed operations attributable to the agent wallet. - **Counterparty graph diversity** — number of unique counterparties transacted with (not limited to facilitators). - **Liveness** — recency of most recent meaningful on-chain action. Liveness decay directly affects Provider Karma. - **Contract interaction breadth** — number of distinct programs the wallet calls. - **Activity cadence** — regular, machine-like intervals (24/7, sub-second gaps) as a positive signal that this is an agent rather than a retail wallet. NOT used to gate scoring; only to inform. ### 4.3 Tier 3 — Declared identity + third-party attestation Signals pulled from agent self-declarations and verifiable external sources. - **Agent manifest** — pulled from: (a) x402 `accepts` HTTP response, (b) MCP server descriptor URL, (c) self-hosted `agentkarma.json` at a claimed domain. - **Domain ownership proof** — a DNS TXT record at a claimed domain containing a wallet-signed string `agentkarma:
:`. - **GitHub ownership proof** — a repository README or file `.agentkarma` containing a wallet-signed assertion. - **Cross-chain ERC-8004 attestations** — attestations on EVM chains for an identifier the Solana agent has bound via a cross-chain pairing statement. - **Framework attestations** — registrations in known agent framework registries (e.g., MCP server registry), keyed on the agent's wallet. - **Parallel agent-payment rail addresses** — declared addresses on parallel agent-micropayment rails. The reference implementation recognizes **MPP / Tempo** addresses (EVM-style, regex `^0x[a-fA-F0-9]{40}$`) declared via the `tempoAddress` field of `agentkarma.json` or the claim form. Declared-only by default — see §4.3.1. Tier 3 signals MUST be cryptographically verifiable (DNS signature, EVM on-chain attestation, or wallet-signed document) **except for declared parallel-rail addresses** (§4.3.1), which carry the ⚪ Declared badge until a signed cross-rail pairing statement is published. #### 4.3.1 Parallel-rail address declarations A parallel-rail declaration (e.g., MPP / Tempo) is a self-claim that the same operator runs the named rail address. Until a bilateral signed pairing statement is verified (mirroring §9.2 cross-chain identity binding), implementations MUST: - Display the declared address alongside the agent profile under the ⚪ Declared confidence badge. - Treat it as a Tier 3 declared signal subject to the §5.2 weight cap (`w₃ ≤ 0.10`). - NOT contribute it to the Karma score until ownership of both addresses is cryptographically proven. Future revisions MAY define a Solana ↔ Tempo pairing-statement format that promotes a verified declaration into Tier 1 receipt-backed status when receipts on the parallel rail can be ingested. ### 4.4 Tier 4 — Social and derivative Softer signals that add color but must not dominate. - Mentions + engagement on on-chain social (Farcaster, Lens). - Listings on external agent directories. - Governance voting history on DAOs. - Breadth of cross-chain activity. ### 4.5 Reference implementation — x402 Tier 1 ingestion The canonical reference implementation's x402 indexer parses SPL token transfers on Solana mainnet against the USDC mint: ``` EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v ``` Facilitator registry is published at: ``` https://agentkarma.io/api/facilitators ``` Parsing strategies (in priority order): `transferChecked` instruction extraction, then token balance diff identification. --- ## 5. Scoring Algorithm ### 5.1 Tier aggregates Each tier produces an aggregate in [0, 1] based on the metrics defined in Section 4. Scorers SHOULD apply temporal decay to individual metrics so that recent signals outweigh historical ones. The exact decay function is implementation-defined (exponential decay with a 90-day half-life is RECOMMENDED as a starting point). ### 5.2 Weighted blend with redistribution Let `w = (w1, w2, w3, w4)` be the tier weights and `T = (T1, T2, T3, T4)` be the tier aggregates, where `Tk` is `null` if the agent has no signals in that tier. ``` RECOMMENDED weights: w = (0.60, 0.25, 0.10, 0.05) Let present_weight = sum of wk where Tk is not null. Score = sum over k where Tk is not null of: (wk / present_weight) * Tk scaled to [0, 100] ``` An agent with only Tier 2 data is not scored as "zero" — its Tier 2 aggregate is renormalized to the full [0, 100] range. The **confidence badge** (Section 6) makes the evidence quality explicit. ### 5.3 Two-faced computation Scorers MUST compute two separate scores per wallet: - **Provider Karma** — computed from signals where the wallet is the *payee* / service provider. Tier 1 signals contributing to Provider Karma are delivery feedbacks where this wallet was paid. - **Consumer Karma** — computed from signals where the wallet is the *payer* / service consumer. Tier 1 signals contributing to Consumer Karma are payment discipline attestations, dispute records filed against it, and counterparty reviews of its paying behavior. A wallet with no signals on one face returns `null` for that face, not `0`. Consumers of the API MUST distinguish these cases. ### 5.5 Autonomy Confidence (parallel score) Karma answers "is this counterparty trustworthy?" It does not answer "is this counterparty actually an autonomous agent?" Scorers MUST compute a second, orthogonal score on the same 0–100 scale — **Autonomy Confidence** — from behavioral fingerprints that distinguish agent-like usage from human usage of agent-framing wrappers. **Signals contributing to Autonomy Confidence:** | Signal | Direction | |--------|-----------| | Cadence regularity (24/7 activity, sub-minute intervals) | Higher → more agent-like | | Inter-transaction latency variance | Low variance → more agent-like | | Concurrent activity within a single block | Present → more agent-like | | Memo / signature determinism | More deterministic → more agent-like | | Counterparty breadth relative to volume | Higher breadth → more agent-like | | Compute / gas efficiency (priority fees, CU limits) | Optimized → more agent-like | **Computation rules:** - Normalized into [0, 100] via implementation-defined blending. - Scorers MUST publish Autonomy Confidence separately from Karma; they MUST NOT blend it into the Karma score. - Scorers SHOULD apply temporal weighting; recent behavior matters more than historical. **Display rules:** - Every API response MUST include an `autonomy` object alongside `provider` and `consumer`. - Every UI surface displaying Karma MUST also display Autonomy Confidence in a separate, clearly labeled chip. - The confidence badge (Section 6) applies to Karma only, not Autonomy. - Autonomy Confidence MAY carry its own qualitative label (e.g., `agent-like` / `mixed` / `human-like`) — implementation-defined. **Rationale:** - A trustworthy human-operated service is still trustworthy; conflating autonomy into karma would penalize legitimate providers. - A scammy but highly autonomous bot has high autonomy and low karma — the combination is information consumers need. - Marketplaces, facilitators, and compliance tooling may gate on either dimension independently. ### 5.4 Trust Tiers Scores in [0, 100] map to human-readable tiers: | Score Range | Tier | |-------------|------| | `null` (no data) | **No Data** | | 0–20 | Unrated | | 21–40 | Poor | | 41–60 | Fair | | 61–75 | Good | | 76–90 | Very Good | | 91–100 | Excellent | --- ## 6. Confidence Badge Every score published by a Karma Protocol implementation MUST carry a confidence badge indicating the evidence quality: | Badge | Condition | |-------|-----------| | 🟢 **Receipt-backed** | Tier 1 signals present above a threshold. | | 🟡 **Behavior-inferred** | No Tier 1 signals, but Tier 2 or Tier 3 signals present. | | ⚪ **Declared** | Only Tier 4 signals, or only self-claimed identity. | The badge MUST be returned in every API response alongside the score. UI surfaces MUST display it visually adjacent to the numeric score. A score without a badge is not a conformant Karma Protocol output. --- ## 7. On-Chain Storage (ERC-8004) ### 7.1 Writing scores Scorers SHOULD publish computed Karma Scores to the ERC-8004 protocol as structured feedback: ```typescript sdk.giveFeedback(agentAsset, { value: providerKarma, score: Math.round(providerKarma), tag1: 'karma_score', tag2: trustTier.toLowerCase(), tag3: confidenceBadge, // 'receipt-backed' | 'behavior-inferred' | 'declared' tag4: 'provider' // 'provider' | 'consumer' }); ``` Provider and Consumer scores are published as separate feedback records distinguished by `tag4`. ### 7.2 Reading scores Consumers query via the 8004 SDK and filter on `tag1 === 'karma_score'` and `tag4` for face. --- ## 8. Query Interface ### 8.1 REST API (v2) Scorers SHOULD expose: #### `GET /api/v2/score/{wallet}?face=provider|consumer|both` ```json { "address": "3Xk...", "provider": { "score": 87.4, "tier": "Very Good", "confidence": "receipt-backed", "signals": { "tier1": { "weight": 0.60, "aggregate": 0.88, "sources": ["x402", "delivery_feedback"] }, "tier2": { "weight": 0.25, "aggregate": 0.72, "sources": ["activity", "diversity"] }, "tier3": { "weight": 0.10, "aggregate": 0.65, "sources": ["manifest", "domain_proof"] }, "tier4": { "weight": 0.05, "aggregate": 0.40, "sources": ["farcaster"] } }, "lastUpdated": "2026-04-19T12:00:00Z" }, "consumer": { "score": 72.1, "tier": "Good", "confidence": "receipt-backed", "signals": { "...": "..." }, "lastUpdated": "2026-04-19T12:00:00Z" }, "autonomy": { "score": 94.2, "label": "agent-like", "signals": { "cadence_regularity": 0.97, "latency_variance": 0.12, "concurrent_depth": 0.88, "memo_determinism": 0.91, "counterparty_breadth": 0.76, "compute_efficiency": 0.82 }, "lastUpdated": "2026-04-19T12:00:00Z" }, "identity": { "displayName": "WeatherBot", "description": "Real-time weather data agent", "website": "https://weatherbot.ai", "category": "data", "claimed": true } } ``` #### `GET /api/v2/leaderboard?face=provider&limit=25` Top agents ranked by score, on a specified face. #### `GET /api/v2/badge/{wallet}?face=provider` Embeddable trust badge (SVG or JSON). #### `GET /api/v2/facilitators` Facilitator registry for x402 Tier 1 ingestion. ### 8.2 Embeddable Widget ```html ``` Renders score + tier + confidence badge. A face-switcher control is RECOMMENDED for wallets that have both faces. --- ## 9. Agent Identity (Optional Enrichment) ### 9.1 Claiming Agents MAY claim their wallet. Claiming requires a wallet signature over: ``` AgentKarma: Claim wallet {address} at {timestamp} ``` Plus profile metadata: `displayName`, `description`, `website`, `category`, and optionally `tempoAddress` (an EVM-style address declaring participation on the MPP / Tempo rail; see §4.3.1). Claiming is strictly optional. It adds identity metadata; it does not affect the score. ### 9.2 Cross-chain identity binding An agent MAY bind a Solana wallet to an EVM identifier (or vice versa) by publishing a pairing statement signed by both keys. Scorers MAY import ERC-8004 attestations matching the bound EVM identifier as Tier 3 signals with a documented weight penalty (to account for binding uncertainty). ### 9.3 Categories `ai`, `data`, `defi`, `infra`, `social`, `utility`, `gaming`, `governance`, `oracle`, `public-good`, `other`. Category `public-good` signals to Scorers that the agent is expected to operate without receipt-backed Tier 1 signals and should be scored primarily on Tier 2–3 signals plus voluntary attestations (Section 11). --- ## 10. Counterparty Feedback (Tier 1) ### 10.1 Delivery attestation A payer MAY submit feedback about a payment they made: ``` POST /api/feedback { "agentWallet": "", "rating": "delivered" | "failed", "txSignature": "", "consumerSignature": "" } ``` The signature MUST be verifiable as the payer of the referenced transaction. Feedback writes into the Provider Karma computation for the payee. ### 10.2 Payment-discipline attestation A payee MAY submit feedback about a payer (for example, after a dispute): ``` POST /api/feedback { "counterpartyWallet": "", "rating": "paid_cleanly" | "disputed" | "charged_back", "txSignature": "", "providerSignature": "" } ``` This writes into the Consumer Karma computation for the payer. ### 10.3 Integrity rules - One feedback per (tx_signature, direction) pair. - The attester MUST be the opposite counterparty of the transaction. - Feedback is immutable once written to ERC-8004. --- ## 11. Voluntary Attestation (Public-Good Support) Agents providing value without accepting payment (oracles, free data feeds, open-source research agents) cannot accumulate Tier 1 signals through the normal flow. Karma Protocol supports these agents via voluntary attestation: ``` POST /api/attestation { "agentWallet": "
", "content": "Used this oracle for 30 days; data was timely and accurate.", "rating": "positive" | "negative" | "neutral", "attesterSignature": "" } ``` Rules: - No transaction signature required. - The attester MUST sign the attestation payload. - Voluntary attestations are weighted **below** Tier 1 (receipt-gated) and **above** Tier 4. - Scorers SHOULD apply attester-diversity discounting: a small group of wallets attesting repeatedly for the same agent contributes diminishing returns to the score. Voluntary attestations map into a distinct sub-tier of Tier 2 for scoring purposes but are displayed alongside Tier 1 signals in the UI with a clear label distinguishing them. --- ## 12. Non-Routing Mandate Karma Protocol implementations MUST NOT proxy agent calls. The protocol is a reputation primitive, not a call router. Specifically: - Scorer implementations MUST NOT host or relay the HTTP endpoints of scored agents. - Scorer implementations MUST link to an agent's declared endpoint but MUST NOT accept the payment or serve the response on the agent's behalf. - Any value-added service that routes calls MUST be operated as a separate product and clearly labeled as distinct from the Karma Protocol scoring layer. This mandate exists to keep the protocol neutral and to avoid inheriting liability (downtime, bad outputs, chargebacks) from the agents it scores. --- ## 13. Liveness ### 13.1 Status derivation Agent liveness is derived from transaction recency on meaningful on-chain activity (not limited to x402 transactions): | Status | Condition | |--------|-----------| | **Active** | Last relevant tx within 24 hours | | **Recent** | Last relevant tx within 7 days | | **Dormant** | Last relevant tx within 90 days | | **Inactive** | No relevant tx for 90+ days | ### 13.2 Score effect Scorers MUST apply liveness decay to Provider Karma. An inactive agent's Provider Karma decays toward a floor as inactivity extends. The exact decay curve is implementation-defined; a documented curve is RECOMMENDED. --- ## 14. Threat Model and Security Considerations A reputation protocol is only as useful as its resistance to gaming. Karma Protocol treats the threat model as a first-class normative artifact — every conformant implementation MUST publish and maintain one. This section defines the minimum required surface; `SIGNAL-ARCHITECTURE.md` §Threat model and anti-gaming carries the extended attack matrix (12 rows, per-attack status tags) that the reference implementation operates against. ### 14.1 Design principles (normative) Implementations of Karma Protocol MUST satisfy the following: 1. **Economic asymmetry, not cryptographic perfection.** Mitigations target the *cost* of manipulation, not its impossibility. The explicit goal is to make gaming uneconomical relative to the value of a fabricated score. Proofs of impossibility are not required. 2. **Per-tier weight caps bind damage.** The maximum contribution of any single tier to a composite score MUST NOT exceed its declared weight (see §5.2). A fully-compromised Tier 4 MUST NOT be able to move a score by more than Tier 4's weight allows. 3. **Threat model MUST be published.** A silent threat model cannot be audited. Implementations MUST ship a public artifact enumerating attack surfaces and mitigations, versioned alongside the scoring algorithm. 4. **Score parameters MUST NOT be under token-weighted governance.** Tier weights, decay constants, counterparty-discount ratios, and confidence-badge thresholds MUST NOT be mutable by a token-weighted vote, on-chain or off. Parameter changes MUST be published as RFC revisions with versioning. Rationale: a reputation oracle whose parameters track whale preferences is a speculation surface, not an oracle. 5. **Reputation state is non-transferable.** Wallet address is the canonical subject identity. Reputation state MUST NOT be transferable, assignable, or saleable between addresses. Operator-level claims (§9) aggregate across addresses owned by the same declared operator but MUST NOT retroactively transfer prior reputation between wallets. ### 14.2 Required mitigations The following mitigations are normative. Conformant implementations MUST address each. `SIGNAL-ARCHITECTURE.md` documents the extended set. **Wash-trading (Tier 1).** Implementations MUST deduplicate Tier 1 receipts by on-chain transaction signature at ingestion. Implementations SHOULD apply counterparty-graph analysis to discount attestations originating from wallets within N hops of the subject's funding graph (N ≥ 3). Feedback submission MUST require a settled on-chain payment from the attester to the subject, making adversarial positive attestations cost real USDC per attempt. **Sybil agent minting.** Implementations MUST treat wallets sharing a common funder within N hops as a *cluster* for the purposes of counterparty-diversity weighting (N ≥ 3). A cluster contributes at most one counterparty's worth of diversity credit regardless of cardinality. Personhood anchoring (Civic Pass, Solana Attestation Service, or equivalent) MAY be offered at the operator level; personhood MUST NOT be required for scoring — that would exclude legitimate public-good agents. **Self-attestation inflation (Tier 3).** Tier 3 signals MUST NOT lift the confidence badge off ⚪ Declared without corroborating Tier 1 or Tier 2 evidence. Declared capability claims MUST NOT exceed the weight ceiling defined in §5.2 (w₃ ≤ 0.10 by default). Cross-chain ERC-8004 imports MUST be bound by bilateral signatures from both addresses (§9.2). **Feedback spam.** Implementations MUST reject duplicate feedback per `(tx_signature, direction)` tuple. The attester MUST be the counterparty of the underlying payment. Negative attestations are subject to the same attester-diversity discounting as positive ones — a tight cluster of negative attesters carries no more weight than a single attester. **Reputation transfer via re-keying.** Fresh wallet addresses MUST carry a cold-start handicap visible via the confidence badge until sufficient signal accumulates. Implementations MUST NOT offer a mechanism to transfer prior reputation state between addresses. Operator-level claims link wallets to a durable operator identity only when the operator actively opts in (§9.1) — they are voluntary information *disclosure*, not reputation laundering. **Cross-chain binding spoofing.** Pairing statements between a Solana address and an external-chain address MUST be signed by both keys. Imported reputation carries a residual binding-uncertainty weight penalty documented in §9.2. Negative attestations MUST be imported alongside positive ones; implementations MUST NOT filter imported reputation to retain only favorable signals. **Burst-timing manipulation.** Implementations SHOULD weight Tier 2 signals by *consistency*, not only recency — a sudden N× spike above a rolling median SHOULD contribute at the pre-spike baseline until the pattern persists. **Governance capture.** See §14.1 principle 4. This is a structural invariant, not a mitigation to be tuned. ### 14.3 Implementation obligations Every conformant implementation of Karma Protocol MUST: 1. Publish its threat model as a public artifact accompanying the scoring algorithm. 2. Tag each mitigation with a status (e.g. `shipped`, `partial`, `roadmap`) so gaps are visible rather than hidden. 3. Document the attack surface opened by each new signal source added to any tier, and the mitigation applied, before the signal begins contributing to published scores. 4. Version the threat model alongside the scoring algorithm. A score-algorithm bump that alters weights or adds signals MUST accompany a threat-model review. ### 14.4 Out of scope for v0.3 The following are explicitly NOT required by this revision: - **In-protocol KYC.** Implementations MUST NOT store identity documents. Personhood anchoring, where offered, delegates to external providers. - **Dispute arbitration with juror bonds.** Feedback is cost-gated by the receipt requirement; disputes over feedback correctness are deferred to a later revision. - **Economic bonding / slash-for-stake.** Karma Protocol has no agent registry and no staking primitive. Reputation IS the stake. This is not a gap to be filled; it is a design decision. ### 14.5 Reference Complete threat matrix with per-attack surfaces, mitigations, and status tags: `SIGNAL-ARCHITECTURE.md` §Threat model and anti-gaming. --- ## 15. Future Extensions - Multi-chain Tier 1 ingestion (Base, Ethereum x402). - Weighted attestation: higher-reputation attesters' feedback carries more weight. - Richer decay curves per tier empirically calibrated from observed data. - Standardized `agentkarma.json` schema for self-hosted manifests. - Agent-to-agent bilateral trust scores (pair-scoped, not just global). --- ## 16. Reference Implementation - **Source:** github.com/agentkarma/agentkarma - **Live instance:** agentkarma.io - **API base:** agentkarma.io/api --- ## Appendix A: Facilitator Address Registry See `src/config/facilitators.ts` for the canonical list of tracked x402 facilitator addresses used in the Tier 1 reference implementation. ## Appendix B: Data Structures ### AgentRecord ```typescript struct AgentRecord { address: PublicKey firstSeen: Timestamp lastSeen: Timestamp txCount: u32 providerKarma: Option // null if no relevant data consumerKarma: Option // null if no relevant data providerConfidence: Option consumerConfidence: Option claimed: bool displayName: Option description: Option website: Option category: Option } enum Confidence { ReceiptBacked, BehaviorInferred, Declared } enum TrustTier { NoData, Unrated, Poor, Fair, Good, VeryGood, Excellent } enum AgentCategory { AI, Data, DeFi, Infra, Social, Utility, Gaming, Governance, Oracle, PublicGood, Other } ``` ### SignalEvent Every observed signal is persisted as a row. ```typescript struct SignalEvent { id: Uuid agentWallet: PublicKey tier: u8 // 1, 2, 3, 4 kind: String // 'x402_payment', 'delivery_feedback', 'manifest_pull', ... face: Face // 'provider' | 'consumer' | 'both' weight: f64 // raw weight before tier aggregation payload: Json // kind-specific structured data signedBy: Option // attester, if any txRef: Option // on-chain reference, if any observedAt: Timestamp } enum Face { Provider, Consumer, Both } ``` ### ScoreSnapshot ```typescript struct ScoreSnapshot { address: PublicKey face: Face score: f64 // 0–100 confidence: Confidence tierAggregates: [f64; 4] // [T1, T2, T3, T4] tierWeightsApplied: [f64; 4] // after redistribution for missing tiers calculatedAt: Timestamp } ``` ### KarmaFeedback (ERC-8004 payload) ```typescript struct KarmaFeedback { value: f64 score: u8 tag1: "karma_score" tag2: String // trust tier lowercase tag3: String // confidence: 'receipt-backed' | 'behavior-inferred' | 'declared' tag4: String // face: 'provider' | 'consumer' } ```