SUPPORTED PROFILE
One intentionally constrained interoperability target
A conforming implementation accepts x402 version 2 over HTTP, the exact scheme, an EIP-155 network and an EIP-3009 token authorization. Assets, token domains, merchant-to-payee mappings, resource origins and one payer per network/asset are configured as trusted Gate data. A customer-supplied local verifier must recover the exact EIP-3009 signer before transmission.
PRE-TRANSMISSION RULE
Fresh authority and a signed request projection are mandatory
Before payment payload creation, the generic gateway must obtain a fresh non-replay consume permit. Its exact settlement_deadline_at is part of the bound Gate context, with at least 180 seconds of settlement-release headroom. The signed envelope binds the canonical URL, method, SHA-256 body-byte digest, canonical allowed-header projection digest, network, asset, atomic amount and payee. The resource must return a canonically equivalent selected challenge immediately before signing.
DURABLE ARTIFACT
Persist before the adapter attempts its paid request
The customer journal atomically inserts the signed payload, itspayload_digest, authorization_digest, request digest, payer, nonce, valid_after, valid_before and settlement_deadline_at. A globally shared, linearizable journal for the same network, asset and payer must first atomically claim the network + asset + payer + nonce ownership key through claimUniqueAuthorization. The runtime requires its GLOBAL_SHARED_LINEARIZABLE declaration; the customer remains responsible for proving that the storage deployment is not split-brain. A different receipt-bound artifact may never own or use that key.
After the unique claim, a customer-supplied read-only verifier must capture the latest canonical block, query the exact EIP-3009 nonce state at that block hash with a require-canonical guard and return a bound NONCE_UNUSED_ANCHOR. The complete anchor and its request and acceptance timestamps are part of immutable artifact identity. A compare-and-set transition from SIGNED to TRANSMITTING precedes the adapter's paid request. The EIP-3009 valid_before boundary must leave 180 seconds before the settlement deadline. Existing records reconcile and never authorize a retransmission; this is not a guarantee that an external HTTP server processes a request exactly once.
SETTLEMENT DECISION
Server reports inform reconciliation; chain evidence decides
PAYMENT-RESPONSE is retained only as an untrusted reported settlement. CONFIRMED requires a configured chain verifier to decode the canonical transaction's transferWithAuthorization call and bind its canonical transaction and block identity, network, asset, payer, payee, atomic amount, exact nonce, authorization_digest, payload_digest, valid_after, valid_before and confirmation threshold. The settlement block number must be strictly greater than the stored anchor block, and the verifier must establish that the exact stored anchor hash remains a canonical ancestor of that settlement block. Ambiguity is nonterminal; caller-supplied fields alone cannot establish settlement.
SAFE RELEASE
Signing changes the burden of proof
A failure before the paid request starts is definitively not submitted. After transmission may have started, a reservation can be released only as confirmed failure after a sufficiently confirmed canonical chain block beyond valid_before proves the exact EIP-3009 nonce unused, with that UNUSED_EXPIRED evidence accepted before the bound settlement deadline. The proof must echo the stored anchor and revalidate it as a canonical ancestor. After the deadline, unused or expired evidence remains UNKNOWN; the reservation remains charged as SETTLEMENT_UNKNOWN. A later canonical CONFIRMED transfer may still commit that reservation, but no late absence claim can release it. Network errors, invalid reports, insufficient confirmations and verifier failures never establish safe release.
PINNED COMPATIBILITY
Upstream behavior is tested, not certified
The first-party compatibility test uses @x402/core 2.19.0 and @x402/evm 2.19.0. The test exercises the installed package interfaces and exact/EIP-3009 payload shape. Normative specification references are pinned separately to x402 commit 90688e52e58ae9185f2860988bd2c46d2801ceda; the test does not build that Git commit or prove package-to-source correspondence. It is not an x402 Foundation certification, partnership, independent audit or funded live-chain transaction.
IMPLEMENTATION
Evaluate the vendor-authored first-party reference adapter
Open the x402 v2 exact integration guide. The profile is vendor-published and reviewable; it is not an accredited standard, x402 certification or independent audit.