An agent deciding whether to pay a pay-per-call endpoint is asking two different questions at once, and the x402 ecosystem keeps answering only the easier one.
A proposed x402 extension — attestations, an open PR in the x402 Foundation repo — standardizes two machine-verifiable trust records: a TEE execution attestation (proof that a facilitator's settlement key lives inside a verifiable execution environment, bound to a reproducible image digest) and soulbound badges (non-transferable, issuer-explicit, revocable-with-history records on-chain). Both surface through the same /.well-known/x402 manifest the discovery extension defines.
It is a serious, well-specified design, and it closes a real gap: x402 tells you what a service costs, and until now nothing told you whether the service can be trusted with the payment. But it is worth being precise about what these records do and don't prove, because the difference is where an agent's money actually gets lost.
| Record | Question it answers | Question it does not answer |
|---|---|---|
| Execution attestation (TEE) | Is the settlement key generated in and confined to an enclave image I can reproduce? | Is the instance serving me right now that enclave? |
| Soulbound badge | Has a named issuer I trust made a durable, revocable claim about this address? | Does the endpoint deliver what it advertises, this call, today? |
Read the right-hand column. Both records are answers to custody and reputation questions. Neither is an answer to the delivery question: after my payment settles, will this endpoint return what it advertised?
The execution attestation's verification re-derives a chain:
evidence → measurement → imageDigest → registered key → live settlement addressEvery link is re-derivable from static state. That is the point — it is what makes the claim independently checkable rather than a trust-me statement. But it also means the chain proves key custody, not liveness. A facilitator that (a) keeps its image reproducible and (b) keeps its key registered on-chain, but (c) has since moved to a non-enclave instance that still settles to that same key, passes every step. The "honest manifest" rule asks the server to degrade its own attestation block on failure — but a compromised server will not, and a client re-deriving the chain gets a clean pass either way.
The closing move is a live challenge-response: the client sends a nonce, and the running instance must return a fresh attestation report that quotes the nonce and verifies against the registered measurement. Only then does "the attestation is true right now" become client-checkable rather than server-asserted. This is a spec-level refinement, and it is the kind of thing that only shows up when you probe the model for the failure mode it quietly assumes away.
This is where it matters in practice. When you audit payment-gated x402 endpoints — fetch the manifest, then hit the live 402 challenge and compare what each demands — the dominant defect class is not key custody. It is payment-field drift: the manifest's payTo or amount disagreeing with what the live challenge actually charges. A manifest that names one settlement address while the challenge demands another is a delivery problem, not a custody problem — an enclave key proves nothing about it, because the drift happens in the plaintext fields the attestation does not cover.
Attestations tell you the key is held correctly. They do not tell you the terms are stated correctly, or that the endpoint will honor them.
The useful mental model: a trust record answers "should I consider this operator at all" — a durable, reputation-shaped question. Delivery verification answers "does this specific call deliver, right now" — a live, per-transaction question. An agent that consults only the first is still paying blind.
The two are complementary, and the spec itself is honest about the split — its security notes describe a "durable/live" boundary and instruct clients to fail closed if the manifest says verified mode is not active. What remains missing is the third leg: a primitive for verifying delivery — actually exercising the paid call (or a cheap probe of it) and checking the result against the advertisement, before committing real volume.
For micro-payments, that looks like pay-to-verify: make the call, confirm the response matches the schema and price you were quoted, then scale. For larger amounts, escrow. Trust records make the verification cheaper to trust; they do not replace it.
Attestations are a real step forward for the protocol. The next one — the one an agent's wallet actually feels — is closing the gap between "this key is held correctly" and "this call will deliver".