feat: add `deferred` payment scheme spec

[tmigone]

At @edgeandnode, we’ve been working on a new payments scheme for x402. Over the past months, we’ve met with the Coinbase team leading the broader x402 effort to ensure our approach is aligned with the spirit of x402 and contributes meaningfully to its vision.

Description

This PR introduces the deferred scheme specification. A followup PR will add the sdk implementation.

deferred is a scheme designed to support trust minimized micro-payments. Unlike the exact scheme, which requires a payment to be executed immediately and fully on-chain, deferred allows clients to issue signed vouchers (IOUs) off-chain, which can later be aggregated and redeemed by the seller. This scheme enables payments smaller than the minimum feasible on-chain transaction cost.

The following diagram represents the sequence diagram for a payment using the deferred scheme. For a detailed explanation on how the scheme works please refer to the specification documents in spec/ directory and the project's README. The very quick TL;DR is:

• Buyer deposits funds into an escrow contract for a specific seller (can be done via signed authorization as well)
• Buyer sends signed vouchers off-chain for each payment (like writing checks)
• Vouchers aggregate - each new payment increases the total owed on the same voucher ID
• Seller collects accumulated vouchers on-chain when it's worth the gas cost

Checklist

• [x] I have formatted and linted my code
• [x] All new and existing tests pass
• [x] My commits are signed (required for merge) -- you may need to rebase if you initially pushed unsigned commits

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[vercel[bot]]

@tmigone is attempting to deploy a commit to the Coinbase Team on Vercel.

A member of the Team first needs to authorize it.

[desimmons]

This is a great proposal. At Dhali, we use XRPL payment channels to support API monetisation. We would definitely consider adopting something like this proposal within our stack. FWIW - we also tweeted about this PR

Can this PR be updated to allow support for arbitrary chains?

[ukstv]

This looks suspiciously close to a unidirectional payment channel design.

[tmigone]

Can this PR be updated to allow support for arbitrary chains?

@desimmons, as long as we are talking about EVM chains it should be trivial. It's just a matter of deploying the escrow contract to the target chain. Glad to hear this could be useful for you! API monetisation seems like a good use case for this type of scheme. Curious to know if there are any pain points or missing features you see in the design that you could benefit from.

[desimmons]

Can this PR be updated to allow support for arbitrary chains?

@desimmons, as long as we are talking about EVM chains it should be trivial. It's just a matter of deploying the escrow contract to the target chain. Glad to hear this could be useful for you! API monetisation seems like a good use case for this type of scheme. Curious to know if there are any pain points or missing features you see in the design that you could benefit from.

For us at Dhali, x402 would ideally support non-EVM chains like XRPL too.

XRPL supports payment channels at the protocol level rather than as deployed smart contracts, so I am reasonably confident this extension of x402 could support something like XRPL. I don't have a good feel at all about the effort involved though.

[tmigone]

For us at Dhali, x402 would ideally support non-EVM chains like XRPL too.

XRPL supports payment channels at the protocol level rather than as deployed smart contracts, so I am reasonably confident this extension of x402 could support something like XRPL. I don't have a good feel at all about the effort involved though.

My bad, I missed the obvious which is you were asking about XRPL 😄 The biggest hurdle I think for XRPL support would be replacing the Escrow smart contract functionality we have. I'm not super knowledgeable on XRPL, perhaps this is something that we could replicate with the built in escrow types. Definitely something to look into once the scheme and it's EVM version is mature enough.

[Dhruv-2003]

interesting take, this seems similar to payment channel and i've built out that scheme as well, have it live on testnet since Jan & been collecting feedback. V1 wasn't compatible with x402, but V2 is.

if u wanna give it a read -https://docs.pipegate.xyz/methods/payment-channels

[tmigone]

I think we should consider rejecting large deposits into escrow. For anything thats >$0.01 I think its safe to assume they'll use exact, and because funding is part of flow (nice work) funding an escrow should be low friction

I like this idea! I think it could be "enforced" at the implementation level and not restricted at protocol/scheme level. For example, the selectPaymentRequirements function could be wired to ignore deferred schemes if the amount to pay exceeds $0.01. wdyt?

[tmigone]

@erikreppel-cb thanks for the review! Appreciate your feedback, seems like we could simplify this quite a bit if we agree on how to solve a few things. In line with this I've left some comments/questions for you on how we can move forward.

In the meantime I have extracted the implementation from this PR so we can just focus on the spec. I'll submit another PR once we are good with this one.

[Ctree35]

Aligning FluxA’s ZK‑batched model with deferred

Great proposal — we’ve been building FluxA, a trust‑minimized, open deferred settlement layer for x402 that lets clients commit now, settle later via EIP‑712 signed commitments that are batched and proven with a ZK‑SNARK, then settled on‑chain in bulk to multiple sellers. We’d like to make FluxA fully compatible with this deferred scheme.

Concretely, the PR defines a deferred flow with buyer escrow, off‑chain signed vouchers that aggregate over time, and settlement when it’s gas‑efficient. That’s conceptually aligned with FluxA; our main delta is that we batch many commitments (potentially across multiple sellers) and settle with an on‑chain ZK proof rather than posting per‑voucher proofs. Could we extend the spec to allow a “batched/zk” variant of deferred with minimal changes? 

Key places we’d propose small additions:

• 402 “Payment Required Response” → add new type in extra field: allow a discriminator so the server/facilitator advertises whether it supports single‑voucher increment or ZK‑batched commitments.
• /verify and /deferred/vouchers flow: keep as‑is for single vouchers, and add an optional bundle submission path for ZK batches at settlement time. 

Happy to open a follow‑up PR with these minimal extensions.

—Chris from FluxA