[Extension Proposal] `agent-trust` — DID-based identity and trust scoring for x402 payments

[1xmint]

GitHub Issue Draft: x402 agent-trust Extension Proposal

Title: [Extension Proposal] agent-trust — DID-based identity and trust scoring for x402 payments

Labels: extension, proposal

---

Problem

x402 enables agent-to-agent payments, but the paying agent is currently just a wallet address. There's no standard way for agents to:

1. Prove their identity beyond a wallet signature
2. Assess counterparty trustworthiness before paying
3. Get trust-based pricing (discounts for reliable agents)
4. Verify the server is who it claims to be (mutual auth)

This matters because as agent commerce scales, agents need to make trust decisions about counterparties they've never interacted with before — especially when real money is involved.

Proposed Solution

A new agent-trust extension that adds optional DID-based identity proofs and trust score exchange to x402 flows:

• PaymentRequired: Server advertises its DID, minimum trust score, pricing tiers, and a trust verification endpoint
• PaymentPayload: Client includes its did:key, a signed proof (Ed25519), timestamp, and nonce
• SettlementResponse: Server returns its own proof (mutual auth), the client's resolved trust score, and a receipt ID

Trust scores are 0-100 integers computed from behavioral signals (success rate, latency, uptime), attestation signals (counterparty feedback), and manifest adherence. The scoring algorithm is deterministic — any party can independently verify.

Flow

Client                                Server
  │                                     │
  │──── GET /resource ────────────────→ │
  │                                     │
  │←── 402 PaymentRequired ──────────── │
  │    extensions.agent-trust:          │
  │      providerDid: did:key:z6Mk...  │
  │      minTrustScore: 50             │
  │      signatureAlgorithm: Ed25519   │
  │                                     │
  │──── Payment + identity proof ────→  │
  │    extensions.agent-trust:          │
  │      did: did:key:z6Mk...          │
  │      proof: Ed25519(canonical_msg) │
  │      timestamp + nonce             │
  │                                     │
  │    Server verifies:                │
  │    1. Signature valid?             │
  │    2. Nonce unique? (replay)       │
  │    3. Trust score ≥ minimum?       │
  │                                     │
  │←── 200 + mutual auth ────────────  │
  │    extensions.agent-trust:          │
  │      providerProof: Ed25519(...)   │
  │      trustScore: 82                │
  │      receiptId: uuid               │

Key Design Decisions

• DID-based, not wallet-based — decouples identity from payment mechanism. A did:key is transport-agnostic (works on EVM, Solana, or no chain at all).
• Optional and backwards-compatible — servers that don't support it omit the extension. Clients that don't support it pay normally.
• Complements reputation extension — reputation (feat: add reputation extension specification #1024) handles on-chain proof-of-service via ERC-8004. agent-trust handles transport-layer identity and pre-payment trust assessment. They compose: an agent can have both.
• Crypto-agile — Ed25519 today, ML-DSA (post-quantum) tomorrow, no protocol change needed.

Prior Art / Related

x402 repo:

• feat: add reputation extension specification #1024 — reputation extension (ERC-8004 based, on-chain proof-of-service)
• [extension] Support ERC-8004 for payment-based reputation #931 — ERC-8004 reputation support discussion
• Add SWORN Trust Protocol ecosystem partner + sworn-trust extension #1707 — sworn-trust extension (trust-gated pricing)
• Proposal: Identity & Reputation Layer — Agent Scoring, Seller Rankings, and Identity Aggregation for x402 #1277 — Identity & Reputation Layer proposal
• Cold-start trust for new agents: mitigation patterns for the reputation extension #1375 — Cold-start trust mitigation patterns

Ecosystem projects doing identity + trust:

• DJD AgentScore — 0-100 trust score from x402 settlement history (5 dimensions). Simple aggregation, no divergence detection or anti-collusion.
• MoltGuard — 0-100 scoring, Sybil detection via funding cluster analysis, Ed25519 VCs, ERC-8004 integrated. Closest to this proposal but product-specific, not a protocol spec.
• Cascade/SATI — Trust infrastructure on Solana (identity + reputation + validation). Chain-specific, no transport-layer standard.
• ACK (Agent Commerce Kit) — W3C DIDs/VCs for agent identity with x402. DID-based like this proposal but no behavioral trust scoring.
• ScoutScore — Service health monitoring (uptime, response fidelity). Overlaps with reliability signals but not a trust protocol.

What agent-trust adds beyond these:

• Manifest-attestation divergence detection (does the agent do what it claims?)
• Anti-collusion framework (clique detection, burst detection, reciprocity analysis)
• Deterministic scoring algorithm (any party can independently verify)
• Crypto-agility (Ed25519 → ML-DSA post-quantum migration without protocol change)
• Formal spec with standards-body engagement (DIF TAAWG, NIST NCCoE)
• Mutual authentication (both client and server prove identity)

This proposal aligns with the x402 roadmap's request for "Identity Solution Proposals (guides/PRs using existing identity providers)."

Implementation Status

Reference implementation deployed on ClawNet (12,000+ API endpoints, skill marketplace, x402 payments):

• AID verification middleware (checkAidProof) — Ed25519 signature verification, nonce replay protection, timestamp validation
• Trust-gated pricing function (trustGatedCreditCost) — 6 tiers based on trust score
• Mutual authentication — server signs responses with provider DID
• Published scoring library: @aidprotocol/trust-compute v2.0.0 (MIT, standalone, zero platform dependencies)
• On-chain identity: ERC-8004 Agent ID 36118 on Base

Next Steps

If there's interest, I'll submit a spec PR at specs/extensions/agent-trust.md following the extension pattern, then a TypeScript implementation.

Full spec draft: aid-x402-trust-extension.md

[msaleme]

The trust scoring problem is real and we have empirical data on why it matters.

We built a 20-test x402 security harness that includes an Agent Autonomy Risk Score (0-100) answering exactly the question you're raising: should this agent transact unsupervised with this endpoint? The score evaluates five dimensions: recipient consistency, payment validation rigor, information leakage, session security, and facilitator trust.

The finding that's relevant to your proposal: most x402 implementations we've tested trust the facilitator (Coinbase/Stripe) implicitly but don't validate receipt signatures independently. An agent that trusts the payment confirmation without verifying the cryptographic proof is one crafted response away from paying an attacker. DID-based identity would help, but only if the identity is bound to the transaction verification, not just the initial handshake.

Two specific gaps your proposal should address:

1. Trust score manipulation (Sybil risk). If trust scores are based on transaction history, a malicious agent can inflate its score by transacting with colluding agents. The score needs to be resistant to coordinated manipulation. Consider requiring third-party attestation rather than self-reported history.

2. Dynamic trust vs. point-in-time. A DID that was trustworthy yesterday can be compromised today. The trust check needs to happen at transaction time, not just at discovery. Our x402 tests (X4-007 through X4-010) specifically test session token security - a valid session from a trusted DID can still be hijacked.

The Agent Autonomy Risk Score methodology and all 20 x402 tests are open source: https://github.com/msaleme/red-team-blue-team-agent-fabric

Would be interested in testing your agent-trust extension against our harness once you have a reference implementation.

[toplyr-narfur]

Great proposal. A few additional considerations from working on x402 infrastructure (ClawRouter, 6300+ stars) and the x402 SDK:

Agree with @msaleme on Sybil risk and session-level trust checks — those are the hardest design problems. Adding a few complementary points:

1. Graceful degradation for new agents: New DIDs start at trust score 0. Providers need a policy for this. Consider a protocol-level newAgentAllowance field that allows the first N low-value interactions before minTrustScore kicks in, rather than requiring third-party attestation from day one (bootstrapping problem).

2. Nonce scope matters for replay protection: What's the nonce scope — per-provider, per-session, global? A per-provider time-windowed nonce (e.g., valid 60s) balances security with implementation simplicity. Session tokens from trusted DIDs can still be hijacked (as msaleme's harness tests), so the nonce check should happen at transaction time, not just at discovery.

3. Privacy / score portability tradeoff: Trust scores attached to DIDs are pseudonymous but linkable. Scoping scores to a single provider reduces tracking surface but limits utility. Portable scores enable cross-provider reputation but create a bigger fingerprint. The protocol should let providers choose the scope via a trustScope: 'provider' | 'ecosystem' field.

4. TrustProvider as a composable interface: Consider defining a TrustProvider alongside Facilitator. A trust provider optionally vouches for an agent's identity and score, while the facilitator handles settlement. This lets the ecosystem compose trust and payment independently — a provider could use Coinbase as facilitator but a specialized trust oracle for scoring.

5. Facilitator orthogonality: agent-trust should compose with existing facilitators (Coinbase, Crossmint) rather than bypass them. The trust layer verifies agent identity, the facilitator verifies payment — these are independent concerns. The extension headers should carry trust metadata without disrupting the existing payment flow.

The TrustProvider interface and newAgentAllowance seem like the most impactful additions to the proposal — they solve the bootstrapping problem and enable composability without requiring every provider to build their own trust infrastructure.

[1xmint]

Great proposal. A few additional considerations from working on x402 infrastructure (ClawRouter, 6300+ stars) and the x402 SDK:

Agree with @msaleme on Sybil risk and session-level trust checks — those are the hardest design problems. Adding a few complementary points:

1. Graceful degradation for new agents: New DIDs start at trust score 0. Providers need a policy for this. Consider a protocol-level newAgentAllowance field that allows the first N low-value interactions before minTrustScore kicks in, rather than requiring third-party attestation from day one (bootstrapping problem).
2. Nonce scope matters for replay protection: What's the nonce scope — per-provider, per-session, global? A per-provider time-windowed nonce (e.g., valid 60s) balances security with implementation simplicity. Session tokens from trusted DIDs can still be hijacked (as msaleme's harness tests), so the nonce check should happen at transaction time, not just at discovery.
3. Privacy / score portability tradeoff: Trust scores attached to DIDs are pseudonymous but linkable. Scoping scores to a single provider reduces tracking surface but limits utility. Portable scores enable cross-provider reputation but create a bigger fingerprint. The protocol should let providers choose the scope via a trustScope: 'provider' | 'ecosystem' field.
4. TrustProvider as a composable interface: Consider defining a TrustProvider alongside Facilitator. A trust provider optionally vouches for an agent's identity and score, while the facilitator handles settlement. This lets the ecosystem compose trust and payment independently — a provider could use Coinbase as facilitator but a specialized trust oracle for scoring.
5. Facilitator orthogonality: agent-trust should compose with existing facilitators (Coinbase, Crossmint) rather than bypass them. The trust layer verifies agent identity, the facilitator verifies payment — these are independent concerns. The extension headers should carry trust metadata without disrupting the existing payment flow.

The TrustProvider interface and newAgentAllowance seem like the most impactful additions to the proposal — they solve the bootstrapping problem and enable composability without requiring every provider to build their own trust infrastructure.

Good catches across the board. Here's where AID stands on each:

Bootstrapping — AID has graduated trust (new agents start at 0, manifest bonus up to +15, guardian vouching for initial signal). Considered adding a newAgentAllowance field to the extension but rejected it — advertising cold-start policy in the PaymentRequired response tells attackers exactly how many free calls each sybil DID gets. Instead, servers that want to accept unknown agents set minTrustScore: 0 on low-value endpoints. Cold-start policy stays server-side, not in the protocol.
Nonce scope — agreed, per-provider time-windowed is the right scope. Updated the spec to make this explicit. Global nonce registry doesn't scale.
Trust scope — intentionally not adding this. AID scores are portable and deterministic by design — the same inputs always produce the same score, verifiable by any party. Provider-scoped scores would mean every provider sees a different number for the same agent, which breaks independent verification. That's the core property that differentiates AID from proprietary reputation systems. If a score is 82, it's 82 for everyone.
TrustProvider interface — this is essentially what @aidprotocol/trust-compute already is. Composable scoring library, independent of any facilitator. Happy to align the naming in the x402 extension docs to match the facilitator pattern.
Facilitator orthogonality — agreed and already the design. Trust metadata in extension headers, payment flow untouched.

The scoring library is on npm now: npm install @aidprotocol/trust-compute (v2.0.0, MIT). Nonce scope already updated in the extension spec based on this feedback.

[toplyr-narfur]

Great to see the npm package is live \u2014 the deterministic scoring property (same inputs \u2192 same score, verifiable by any party) is a strong design choice that differentiates this from proprietary reputation systems.\n\nA couple of follow-up thoughts on the points where our reasoning diverged:\n\n1. Server-side cold-start policy \u2014 your argument about not advertising sybil budgets in the protocol is well-taken. The approach for low-value endpoints is cleaner. The one consideration: providers implementing this will need a way to communicate their cold-start policy somewhere (even if not in the protocol headers). An optional endpoint or a well-known URI convention could let agents discover cold-start behavior without it being part of the payment flow.\n\n2. Portable scores vs. provider-scoped \u2014 agreed that deterministic portability is the right default. One refinement: a provider might want to apply local weightings on top of the base score (e.g., "I trust AID scores but weight recency 2x for my domain"). This doesn't break portability \u2014 it's a local policy layer on top of a universal score. Worth documenting as a recommended pattern in the extension spec.\n\n3. TrustProvider naming alignment \u2014 aligning with the facilitator pattern in x402 extension docs would make the architecture more discoverable for providers already familiar with the facilitator abstraction. "+1" on that.\n\nThe library being MIT-licensed and independently verifiable is exactly the kind of composable infrastructure the x402 ecosystem needs. Looking forward to seeing how this evolves.

[msaleme]

Good technical discussion. A few things we can actually validate empirically:

The cold-start policy decision (server-side vs. protocol-advertised) is testable. Our x402 harness probes how endpoints handle unknown agents - if the policy leaks through response timing or error messages, it's discoverable regardless of whether it's in the headers. We can add a test for this.

The deterministic scoring claim ("same inputs, same score, verifiable by any party") is the right property but it needs adversarial validation. The Sybil concern still applies: if the inputs to the score are manipulable (transaction history, manifest contents), deterministic scoring just means the attacker can predict exactly what score their Sybil DIDs will get. Determinism helps verification but doesn't help resistance.

We'd be happy to run our 20-test x402 harness against an endpoint implementing the agent-trust extension once there's a reference deployment. The tests that matter most here: X4-007 through X4-010 (session security) and the Agent Autonomy Risk Score, which evaluates exactly the trust question this proposal addresses.

[toplyr-narfur]

Good points on all three. A few thoughts:

Cold-start policy discovery: Agree that response behavior leaks policy information regardless of whether it's in the protocol headers. If an agent can infer a provider's cold-start tolerance from timing patterns or error codes, better to make it explicit so agents can make informed routing decisions upfront rather than burning probes to discover it.

Determinism vs. Sybil resistance: These are orthogonal properties and the spec should treat them separately. Determinism ensures verifiability (any party can recompute the score from the same inputs), but you're right that it doesn't guarantee input integrity. The missing piece is ensuring scoring inputs resist fabrication. A useful framing might split inputs into:

• Hard inputs: onchain payment history, time since first transaction, channel longevity — costly to fabricate because they require real economic commitment
• Soft inputs: provider-reported metadata (manifest claims, uptime declarations, feature lists) — useful signal but manipulable by construction
• Composite tier assignment: weighted combination where hard inputs dominate tier placement, so even if an attacker games soft inputs, the damage is bounded

This makes the Sybil concern concrete: if the scoring function weights hard inputs heavily enough, a Sybil attacker needs real economic skin in the game to reach higher trust tiers, which defeats the purpose.

Harness testing: The offer to validate against X4-007 through X4-010 and the Agent Autonomy Risk Score is exactly the right next step. A spec that survives adversarial testing before any reference implementation exists is far more valuable than one that doesn't. Publishing harness results alongside the spec would also give providers concrete evidence when deciding whether to adopt the extension.