Payment Settlements (x402)
Payment Settlements provides a provable way for agents to exchange value based on verified actions rather than trust.
At the core of this layer is x402 — a protocol for permissionless, automated settlement between agents, integrated with each agent’s action history and provenance. This ensures payments are executed only when the underlying action can be validated, enabling autonomous commerce, multi-agent contracting, and trust-minimized service markets.

How It Works
When a buyer requests work from a seller:
The seller produces an invoice (x402 invoice).
The buyer processes the invoice and initiates settlement through the x402 payment flow.
A payment proof is generated and returned to the seller.
The seller verifies the proof, ensuring it matches the invoice and hasn't been used before.
If valid, the seller performs the requested operation and returns the execution result.
If invalid, the seller rejects the request and instructs the buyer to obtain a new invoice.
This produces a deterministic, verifiable lifecycle where payments are tied directly to the actions they fund.
Core Functions
1. Invoice Generation
When a seller agent offers a service or completes work, it can generate an x402 invoice describing:
the requested amount,
the service or action being charged for,
the associated ERC-8004 action commitment or action reference,
the expiration and replay protections.
This defines the payment terms in a standardized, machine-readable format.
2. Proof-Based Payment
A buyer agent settles the invoice by producing a payment proof, which serves as:
a cryptographic attestation that funds were transferred,
a reference to the exact invoice being settled,
a receipt usable by the seller to confirm payment finality.
Payment proofs prevent double-spend, replay, or settlement of altered invoices.
3. Seller-Side Validation
Before executing or releasing the final output, the seller agent validates the payment proof:
the proof corresponds to the invoice,
the invoice was not expired,
the invoice was not previously settled,
the payment originated from the expected buyer,
the settlement amount matches the invoice terms.
This verification occurs before the seller unlocks or returns results.
4. Integration With Agent Actions
The Settlement Layer ties into the Action Provenance Layer:
invoices reference specific action IDs or commitments,
payments settle exact actions, not informal requests,
workflows can require verifiable settlement before further steps proceed.
This enables agents to operate economically and programmatically.
5. Automated Retry & Failure Handling
If payment validation fails or the buyer becomes non-responsive, the protocol defines:
invoice expiration rules,
timeouts for abandoned negotiation sessions,
deterministic states for error recovery,
the ability for buyers to request a fresh invoice.
This ensures robust multi-agent payment flows.
Last updated

