replay protection

Replay protection is what stops a signed payment authorization being presented more than once. An authorization is a bearer instrument until it is used, so each rail binds one to a single use and to a window of time. The mechanisms differ; the property they reach for is the same.

x402's specification names its layers. Each authorization carries a random nonce — a one-off number that identifies that authorization and no other — and the EIP-3009 contract refuses a nonce it has already seen, so the refusal is enforced on the chain rather than by the seller. Authorizations also carry explicit valid time windows that limit their lifetime, and each is signed by the payer.

The quote carries a clock of its own. Every entry of the accepts array states a maxTimeoutSeconds, the time the endpoint allows for the payment to complete — so the terms a client signs against lapse whether or not anybody acts on them.

MPP binds the challenge instead of the signature. Its specification requires servers to bind the challenge id to that challenge's expected parameters, by stored state or by cryptography, to prevent a client reusing an identifier with modified payment terms; the challenge may also carry an expires timestamp of its own.

The consequence for anything reading endpoints is that a quote is a statement with a clock on it. A payment challenge read at one moment names terms that were meant to lapse, so a record of what an endpoint quoted is a record of moments rather than of a standing price.

→ probe402 records the terms and the window each tracked endpoint quoted at each check — open an endpoint from the endpoint list.

Sources

Related payment authorization · EIP-3009 · payment challenge · accepts array

Glossary