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

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:<address>:<timestamp>.
• 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:

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:

6. Confidence Badge

Every score published by a Karma Protocol implementation MUST carry a confidence badge indicating the evidence quality:

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:

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`

{
  "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

<script src="https://agentkarma.io/widget.js"
        data-wallet="3Xk..."
        data-face="provider"
        data-theme="dark"></script>

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": "<payee address>",
  "rating": "delivered" | "failed",
  "txSignature": "<Solana signature>",
  "consumerSignature": "<base58 wallet signature>"
}

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": "<payer address>",
  "rating": "paid_cleanly" | "disputed" | "charged_back",
  "txSignature": "<Solana signature>",
  "providerSignature": "<base58 wallet signature>"
}

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": "<address>",
  "content": "Used this oracle for 30 days; data was timely and accurate.",
  "rating": "positive" | "negative" | "neutral",
  "attesterSignature": "<base58 wallet signature>"
}

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):

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:

• 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.
• 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.
• 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.
• 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.
• 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:

• Publish its threat model as a public artifact accompanying the scoring algorithm.
• Tag each mitigation with a status (e.g. shipped, partial, roadmap) so gaps are visible rather than hidden.
• 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.
• 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

struct AgentRecord {
  address: PublicKey
  firstSeen: Timestamp
  lastSeen: Timestamp
  txCount: u32
  providerKarma: Option<f64>          // null if no relevant data
  consumerKarma: Option<f64>          // null if no relevant data
  providerConfidence: Option<Confidence>
  consumerConfidence: Option<Confidence>
  claimed: bool
  displayName: Option<String>
  description: Option<String>
  website: Option<String>
  category: Option<AgentCategory>
}

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.

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<PublicKey>      // attester, if any
  txRef: Option<Signature>         // on-chain reference, if any
  observedAt: Timestamp
}

enum Face { Provider, Consumer, Both }

ScoreSnapshot

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)

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'
}