x402 receipt verification: RPC trust model

[bitcryptic-gw]

The reference implementation currently uses a structural stub for x402 payment verification — it validates receipt shape (chain, currency, amount) but does not confirm on-chain settlement against an EVM RPC.

Replacing the stub requires choosing a trust model. The options as we see them:

Third-party RPC (Alchemy, Infura, etc.) — lowest implementation friction, but introduces an external dependency and a trust assumption that conflicts with the self-hosted, minimal-trust philosophy of the reference implementation.

Self-hosted EVM node — no external trust, but operationally heavy. Reasonable for a production deployment; probably too much for a reference implementation to mandate.

Signed proof / attestation — the payer provides a cryptographic proof of settlement that the server can verify without an RPC call. Cleanest for agents. Not yet standardised in x402 itself.

Light client / SPV-style — verify just enough of the chain state to confirm settlement without a full node. Theoretically attractive, practically immature for EVM.

We want to avoid picking a trust model in the reference implementation before the community has weighed in, since the choice will influence what MDF recommends (or leaves open) in the spec.

Questions for the community:

• What trust model are you using or planning to use for x402 settlement verification?
• Is there appetite in the x402 ecosystem for a signed proof / attestation approach that eliminates the RPC dependency?
• Should MDF remain agnostic here and let deployers configure their RPC, or should we recommend a default?

Tracking this as an open design question. Implementation of real verification is blocked on resolution.

[evidai]

Sharing a reference from a non-CDP x402 facilitator in case the comparison helps the thread.

LemonCake (https://lemoncake.xyz) ships an x402 gateway at /g/<id> and acts as its own facilitator for the agent-payment loop. Our take on some of the rough edges in this discussion:

• 402 challenge body: accepts[] advertises both buyUrl (human checkout) and mintUrl (machine — agent's Buyer Key mints a Pay Token JWT directly), plus the spec's WWW-Authenticate header. Agents don't have to guess which path is theirs.
• Settlement-before-token: we commit the charge (with a unique charge_ref — idempotent) before the Pay Token JWT is issued. The gateway pass step is JWT verification only — no settlement check at request time, so no ordering races.
• X-PAYMENT v2 / setSettlementOverrides: we sidestep the CDP /verify quirks by running our own adapter (StubAdapter for mock, StripeOffSessionAdapter for live). Stripe off-session: $1 real-card charge through the full loop verified 2026-06-02.
• Custody: virtual balance = sum of unused Pay Tokens. No pool, never holds funds (FSA-cleared design). USDC path keeps the agent's own key as the transfer subject.

30-second demo (no signup): https://lemoncake.xyz/demo

(Disclosure: working on LemonCake. Sharing as a non-CDP reference implementation, not pitching.)

[bitcryptic-gw]

Thanks for the reference and for being upfront about the context.

The settlement-before-token pattern with an idempotent charge_ref is a useful data point — committing the charge before issuing the token sidesteps the verification ordering problem cleanly. And the buyUrl/mintUrl split in the challenge body is a neat solution to the human-vs-agent path question that we've been treating as an open problem on our end.

Will take a look at the demo. Appreciate the non-CDP perspective.

[evidai]

The cleanest way we found around the RPC-trust problem in #2 is to not settle on-chain at all — fiat settlement makes the receipt a signed facilitator artifact you verify offline against a published key (no RPC / node / SPV). That only covers off-chain-settled x402, so for native on-chain you're still in your four-option space — might be worth MDF carving "off-chain-settled x402" out as its own profile.

Working reference if useful: https://lemoncake.xyz/demo

[bitcryptic-gw]

That's a useful distinction — off-chain settlement really is a different trust model, not just a different transport. If the receipt is a facilitator-signed artifact verifiable against a published key, the RPC problem goes away entirely and the four-option space in #3 only applies to native on-chain settlement.

Carving "off-chain-settled x402" out as a named profile makes sense. It would let MDF say clearly: if your implementation uses a facilitator with off-chain settlement, receipt verification is just JWT + published key, here's the profile. On-chain settlement is a separate profile with its own trust model options.

Will note this in the issue as a potential path forward. Appreciate the framing.