MPP defines how agents pay. It doesn't yet define how either party evaluates trust before payment.

The gap

An agent receives a 402 challenge from a service. Before paying, it has no signal about the service's on-chain legitimacy. Conversely, a service receiving payment has no signal about the agent's wallet state, credential status, or compliance posture. Both sides are flying blind.

The discovery extension (draft-payment-discovery-00) tells agents what a service offers and how much it costs. It doesn't tell them whether to trust it — and it gives the service no way to require the agent to prove anything about itself beyond payment.

Proposed extension

A wallet-state trust extension that adds optional pre-payment verification to the MPP flow:

1. Service declares trust requirements in x-payment-info (via the discovery extension):

"x-payment-info": {
  "method": "tempo",
  "intent": "charge",
  "amount": "0.01",
  "currency": "USD",
  "trust": {
    "required": true,
    "accepted_providers": [
      {
        "jwks": "https://verifier.example.com/.well-known/jwks.json",
        "endpoint": "https://verifier.example.com/v1/attest"
      }
    ],
    "conditions": [
      {
        "type": "token_balance",
        "chainId": 8453,
        "contractAddress": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
        "threshold": 10,
        "decimals": 6
      }
    ]
  }
}

2. Agent obtains attestation before paying — calls the attestation endpoint with wallet address and conditions, receives a signed result:

{
  "sig": "f5CwIBo6P5xX4Q+GU591P8k+abHOGt8nMJZeiW0Q7c7RKZSHxIqT3gfU0tJ7Yx63PadY2RNFw/ctbaNIneDlng==",
  "kid": "insumer-attest-v1",
  "attestation": {
    "id": "ATST-36CAF8C2CAC5D1AC",
    "pass": true,
    "results": [{ "condition": 0, "met": true }],
    "attestedAt": "2026-03-19T00:35:47.615Z",
    "expiresAt": "2026-03-19T01:05:47.615Z"
  }
}

3. Agent includes attestation in payment credential:

Authorization: Payment credential="...", attestation="<base64url-encoded-jwt>"

4. Service verifies attestation offline — fetches JWKS from the declared jwks URI, selects key by kid, verifies sig. No real-time call to the attestation provider needed at verification time.

Design principles (aligned with MPP)

• Provider-agnostic: Any attestation service implementing JWKS + signed boolean responses works. The accepted_providers array declares which signing keys the service trusts.
• OPTIONAL extension: Services opt in by declaring trust in their discovery document.
• Offline-verifiable: JWKS-based signature verification. No runtime dependency on the attestation provider after initial key fetch (cacheable per standard HTTP headers).
• Complementary to existing extensions: Discovery tells the agent what's available. This extension tells the agent what's required to be trusted. ThoughtProof's reasoning verification (feat: add Reasoning Verification extension for MPP #187) evaluates decision quality. Together: discovery + trust + reasoning = complete pre-payment stack.

Production reference

Wallet-state attestation with ECDSA P-256 signing and JWKS verification is already live in production across 32 blockchain networks, with integrations in the x402 cold-start trust spec (coinbase/x402#1375), Google A2A trust signals (a2aproject/A2A#1628), and UCP attestation extension (Universal-Commerce-Protocol/ucp#264). The response example above is from a live API call (Base USDC, block 0x2987400).

API docs: insumermodel.com/developers/api-reference

Happy to draft the extension spec (draft-payment-trust-00.md) if there's interest.