How does an autonomous agent handle an HTTP 402 challenge using typed message signatures and relayer settlement?
This interactive workbench models an agent-to-agent transaction lifecycle across five stages: capability intent matching, an HTTP 402 challenge containing payment metadata, client-side off-chain signing of structured permit data, relayer broadcast, and resource delivery. In actual HTTP architecture, status code 402 (Payment Required) is defined by RFC 9110 as reserved for future use, leaving header names like x402-Invoice-ID as application-level conventions rather than standardized wire headers. Off-chain authorization relies on EIP-712 structured data hashing to verify intent before submitting the transaction to a settlement relayer.
This simulator uses synthetic client-side presets, hardcoded hash digests ('0x7a8b9c...402a'), and mock HTTP headers. It does not communicate with a live blockchain node, testnet, or Web3 provider. Furthermore, RFC 9110 reserves status code 402 without defining standardized request or response headers for autonomous commerce; headers like 'x402-Payment-Token' shown in the inspector are application-level conventions rather than ratified standards.
Select the 'Reset' button to return the simulation from its completed load state to Stage 1 (ACP INTENT). The sequence diagram and active stage description will update to 'Stage 1: ACP Capability & Intent Discovery', displaying an initial POST handshake payload. Then click 'Step Forward' once to advance to Stage 2 (HTTP 402 INVOICE). Observe that the inspector badge switches to 'HTTP 402 Payment Required', the header inspector renders the simulated payment challenge headers (including invoice ID and unit price), and the payload inspector displays the structured permit domain and types.
The Hypertext Transfer Protocol standardizes status codes across client error ranges (4xx). In RFC 9110 Section 15.5.3, status code 402 is designated as 'Payment Required' and is reserved for future use. The core specification does not define normative payment headers, cryptographic payload envelopes, or relayer challenge schemes. RFC 9110: HTTP Semantics
Implementations targeting autonomous machine commerce establish application-level headers and JSON payloads (such as custom invoice IDs and recipient tokens) to convey billing instructions when an unauthenticated or unpaid request arrives.
EIP-712 defines a standard for hashing and signing typed structured data rather than arbitrary bytecode or opaque hex strings. It prevents signature collisions across decentralized applications through a domain separator consisting of fields such as name, version, chainId, and verifyingContract. EIP-712: Typed structured data hashing and signing
In the simulator's Step 3 and Step 4, an agent generates a signature over a typed struct (e.g., PaymentPermit with owner, spender, value, and nonce). A relayer can then broadcast this signed permit on behalf of the agent, sponsoring network gas while executing the token transfer according to the signed parameters. EIP-712: Typed structured data hashing and signing
Defines HTTP status code 402 (Payment Required) in Section 15.5.3 as reserved for future use.
Specifies domain separation, structured data encoding, and deterministic hashing for off-chain message signatures.
This workbench cycles through five authored stages: intent, a four zero two challenge, a signature label, a relay label and service delivery. Headers and JSON are formatted strings from local state. No wallet signing, HTTP request or blockchain broadcast occurs. Spec compliant and settled labels are demonstration text, not independent protocol conformance or settlement proof. Inference and data presets set prices point zero five and point one two USDT. Challenge and permit strings show six decimal places. The zero TRX gas claim and truncated digest are fixed fixtures rather than transaction calculations. Export stores current step separately from expected result, whose completed labels exist before reaching stage five. No actual settled payment is established. Reset returns to stage one while reading current buyer, seller, service and settlement controls. Zero or invalid parsed price falls back to point zero five. Reset does not universally restore default controls. Step forward at stage five cycles to one; auto-run advances on a twelve hundred millisecond timer. Offline graph libraries can be unavailable. No payment or public functionality is certified by this local draft.