TL;DR
x402 lets an agent pay for a resource-server call, but it never binds payment to correctness of execution — a provider can take payment and never deliver, or deliver something other than what was promised. I’ve built and measured a reference design (ZkInferenceEscrow) that closes this gap: payment for an AI inference call settles atomically, in one transaction, only when an on-chain ZK proof verifies the call was executed by a specific, pinned circuit. As a structural side effect, the x402 facilitator becomes optional rather than trusted. This post lays out the design, is upfront about what’s genuinely novel versus known technique, and shares real gas/economics numbers from a Base Sepolia deployment rather than paper estimates.
The gap
x402 (HTTP 402-based agent payments, now under the x402 Foundation) solves payment authorization well, but correctness of the paid-for work is out of scope by design: a client sends money, a server sends something back, and nothing on-chain ties the two together. A dishonest or buggy provider can take payment and withhold the response, or return output that doesn’t match what it promised, and the client has no recourse besides reputation and off-chain trust.
This isn’t a new observation — it’s the classical fair exchange problem (Pagnia & Gärtner, 1999, show it’s impossible without a trusted third party), applied to a specific modern setting: HTTP-native agent payments. The lineage here runs through Zero-Knowledge Contingent Payments (Maxwell’s “pay-to-sudoku”, 2016, hardened against setup-subversion attacks by Campanelli, Gennaro, Goldfeder & Nizzardo, CCS 2017) and FairSwap (Dziembowski, Eckey, Faust, CCS 2018) — neither of which targeted HTTP-native agent payments or ML workloads specifically.
I’m not the first to flag this gap for x402 specifically. There’s at least one recent academic proposal that attacks the same atomicity problem using TEEs plus adaptor signatures, and a couple of industry blog posts sketching “payment settles only when computation is proven” at a conceptual level. None of these, as far as I can find, ship a concrete, x402-scheme-conformant, ERC-8004-integrated reference design with measured costs. That’s the gap this fills.
The design, briefly
The core mechanism is a proof-gated escrow, registered as an x402 payment scheme:
-
Client sends a request; provider responds with a 402 quote binding a specific model circuit (identified by its verifying key) and a salted commitment to the input.
-
Client signs an EIP-3009 payment authorization whose nonce is derived from all request parameters — this is the anti-tamper anchor; a relayer can’t alter any field without invalidating the signature.
-
Provider computes the result and returns it immediately over HTTP (optimistic delivery — the client sees an answer in under a second).
-
In parallel, the provider generates a ZK proof (EZKL/Halo2) that the pinned circuit, run on the committed input, produces the delivered output.
-
One on-chain transaction verifies the proof, releases payment, and publishes the output in calldata — payment and output-availability are the same state transition. No proof, no payment; no payment without provable output.
-
If no valid proof lands by the deadline, the client recovers funds permissionlessly.
What’s actually new here, and what isn’t
Being explicit about this, because I’d rather have this conversation now than in the comments:
Not new: the fair-exchange-via-ZK pattern itself (ZKCP, FairSwap), Halo2/EZKL as a proving stack, x402’s payment layer, ERC-8004 as a validation registry.
A real composition, not just glue: binding this specifically into an x402 payment scheme (rather than an external escrow the client has to know to use) and into ERC-8004’s Validation Registry (so a model’s track record accumulates against an immutable circuit identity, not a mutable API endpoint) is, to my knowledge, not published anywhere as a concrete spec — only as blog-level concept posts.
A genuinely counter-intuitive finding: the naive assumption is that ZK verification gas dominates the per-request cost, so the obvious optimization is proof aggregation. Measuring the actual breakdown shows that escrow-opening (the EIP-3009 pull + state writes), not verification, is the dominant line item once you batch verification — meaning channel-style funding, not proof aggregation, is the first-order lever. This reorders the “obvious” optimization roadmap.
A free structural side effect: because only the contract can authorize payment release, the x402 facilitator degrades from trusted settlement executor to optional, unprivileged relayer — decentralizing the facilitator wasn’t a design goal, it falls out of removing the need to trust anyone with settlement.
Measured, not estimated
Everything below is from real transactions (Base Sepolia), not simulation:
-
Solo settlement (
open+settle, small-circuit model, K5 salted input commitment): ~970k gas total, both operations individually within 2% of local Anvil measurements. -
With channel-based funding + K=8 batched proof verification + a challenge-close mechanism for safe early channel exit: ~84% gas reduction versus solo settlement — down from the naive aggregation-only estimate that undercounted the escrow-opening cost.
-
L1 data-availability fee (OP-Stack/Fjord formula) is a small fraction of total cost at current Base gas prices (~3-4%), but scales to become the dominant term under L1 fee-spike conditions — worth modeling explicitly rather than assuming it’s negligible.
Circuit size is the real constraint on this approach today: proving cost puts a practical ceiling around low-tens-of-millions of parameters on commodity hardware, which is the right regime for scoring/classification/compliance-check models, not frontier LLMs. That’s a documented limitation, not a hidden one — the verifier is pluggable so this improves as faster provers (recursive SNARK aggregation, GKR-based approaches) mature, without changing the settlement semantics above.
Open questions I’d genuinely like input on
-
VK-to-model-identity binding. The proof shows a pinned circuit executed correctly — it doesn’t by itself prove that circuit is the model the provider advertises. I’m using an independent-reproduction attestation pattern (third parties recompile the artifact bundle and attest the resulting VK matches) rather than trying to solve this cryptographically. Is there a cleaner primitive for “this VK corresponds to this claimed model” that doesn’t require trusting the attester set?
-
Batched-circuit privacy. Once you batch K requests into one proof for cost amortization, does anything about the batch (timing, position, which requests get proven vs. skipped) leak information a single-request design wouldn’t? I have a design for output encryption that composes with batching without breaking atomicity, but haven’t seen this specific composition (proof-carrying settlement + batching + in-circuit output encryption) discussed elsewhere and would like to know if I’m missing prior art.
-
Has anyone else already shipped a scheme-conformant reference implementation of this pattern for x402 that I should be citing/comparing against instead of re-deriving?
Happy to go deeper on any part of this — architecture, the gas breakdown methodology, or the attestation design — in the comments.