This chapter is organized by concept; each entry can be navigated directly from the right-hand TOC. Start with the four payment methods, then drill into the specific technologies they involve.

Seller forms:

• HTTP Seller: Operates a public HTTP service exposed via a public domain. Suitable for existing APIs / datasets / inference endpoints.
• Agent Seller: Runs locally or in a private environment, exposed via messaging channels (XMTP, Telegram, etc.). Doesn't need a public domain, SSL certificate, or HTTP service deployment.

The Buyer is an Agent that signs an EIP-3009 / EIP-712 message via its wallet and submits the credential to the Broker. Any wallet supporting these two signature types works for an Agent — if you don't want to handle signature details yourself, your Agent can simply use Agentic Wallet. HTTP Sellers and Agent Sellers issue payment requests with the same semantics; the same Agent Buyer can transparently handle both carriers.

---

Payment methods ↔ Agent Payments Protocol intent mapping#

Agent Payments Protocol defines four intents: charge / escrow / session / upto. The mapping between current Onchain OS Payment product methods and protocol intents:

Why both Batch and Pay-as-you-go are session intent: At the protocol level, both belong to the "consume now, settle later" session payment shape — the Buyer signs authorizations or vouchers off-chain and on-chain settlement is deferred to the end of the session. They differ in settlement granularity:

• Batch payment settles per "call": The Buyer signs a small ticket (charge credential) on every call; the Broker aggregates many tickets into a single on-chain transaction inside a TEE.
• Pay-as-you-go settles per "amount": The Buyer signs a Voucher with a monotonically increasing cumulative amount (e.g. "cumulative due = 12.34 USDC as of now"); each new Voucher supersedes the old one. Only the latest Voucher is redeemed when the channel closes.

---

One-time payment#

Definition: The simplest payment shape — Buyer pays once, Seller delivers once, transaction ends. Price is known up front; there's no follow-up consumption.

Scenario: The vast majority of paid actions on the internet are one-shot — one API call, one report, one inference. Buyers don't want to be forced into subscriptions, and Sellers don't want to manage accounts for every random Buyer.

Examples: An Agent calls a data analysis API to fetch a single on-chain trace report; an Agent calls an LLM for one inference; a Buyer purchases a single research article; tips / gratuities between Agents.

Underlying technology: The charge intent of Agent Payments Protocol. Wire format (challenge / credential field structure, signature format) is compatible with x402 exact and MPP charge — the same challenge / credential can be recognized in both ecosystems.

---

Batch payment#

Definition: A payment shape designed for batched scenarios. The Buyer signs each call individually; many signatures are compressed and aggregated in the backend into a single on-chain transaction. Because settlement happens after consumption, this is also called "post-pay".

Scenario: In Agent automation, a single task may chain dozens of paid calls, each costing a few cents — sometimes fractions of a cent. Settling each one independently on-chain causes congestion, and the Gas cost may exceed the payment itself. Batch payment solves the settlement-efficiency problem under high-frequency Agent workloads.

Examples: An Agent runs a complex research task that calls 20 paid APIs; IoT devices pay per second for bandwidth or compute; Agents call each other's tools.

Underlying technology: The post-aggregation form of Agent Payments Protocol's session intent — same family as Pay-as-you-go but aggregating by "call count" rather than settling by "cumulative amount". The Buyer signs an EIP-712 credential with a Session Key on every call (wire format follows the aggr_deferred scheme that OKX defined within the x402 framework). The Broker aggregates these credentials inside a TEE into one valid on-chain transaction and submits it for settlement.

Prerequisite: The Buyer must use Agentic Wallet — ordinary EVM wallets cannot support the Session Key authorization mechanism.

HTTP Seller only.

---

Pay-as-you-go#

Definition: The Buyer first deposits funds on-chain. For each consumption, only a "cumulative bill" is signed (off-chain). When usage finishes, the latest bill is submitted on-chain for one-shot settlement; any unused balance is refunded automatically.

Scenario: When the total cost can't be calculated up front — typical example: LLM billing per token, where an article generation might use 500 tokens or 5,000 tokens with no way to know in advance. One-time and Batch payments both require a known unit price up front; this "pay for what you use" pattern is something neither covers.

Examples: LLM token-based billing; streaming-data subscription billed per consumed byte; voice/video API billed per second.

Underlying technology: Agent Payments Protocol's session intent, implemented as a two-tier structure of Escrow contract + off-chain cumulative Vouchers (wire format compatible with MPP EVM Session). HTTP Sellers and Agent Sellers share the same wire format; they differ only in transport:

---

Escrow payment#

Definition: The Client locks funds into an on-chain escrow contract first; after the Provider delivers the service, if the Client raises no dispute, funds are automatically released to the Receiver after the dispute window; otherwise a third-party Arbitrator decides.

Scenario: When two unfamiliar Agents need to cooperate (one performs work, the other pays), there's a classic two-sided trust problem — whoever moves first risks loss. This is the same problem Taobao, eBay, and other e-commerce platforms solved decades ago. Escrow payment puts that pattern on-chain, replacing the traditional platform with a smart contract. In Agent scenarios, task delivery is typically negotiated through messaging channels — a natural fit for the conversational flow of escrow.

Examples: An Agent outsources marketing-asset generation to another Agent; an Agent commissions code review from another; a DAO publishes tasks for Agents to bid on.

Underlying technology: Agent Payments Protocol's escrow intent, based on Optimistic Escrow — a contract standard designed by OKX that defines protocol fields, signature format, Challenge / Credential flow, and the on-chain contract standard.

Funds path: Buyer → Escrow contract (custody) → Receiver (released after acceptance). 2–3 on-chain transactions: order creation + release ± arbitration.

Agent Seller only.

---

HTTP 402#

A reserved HTTP status code meaning "Payment Required" — the client must pay to access this resource. It was defined back in HTTP/1.1 (RFC 2616, 1999), but without a paired payment mechanism, it remained "reserved, not used" for over two decades.

Why has 402 sat unused? Because the HTTP spec only defined the status code's semantics ("payment required") without defining how to pay, who to pay, or how to verify. With no standardized payment flow, browsers and clients didn't know what to do upon receiving a 402. The x402 Protocol fills exactly this gap — defining a complete 402-based payment interaction flow.

Why use 402 rather than a custom code? Because 402's semantics are already "payment required" — a part of the HTTP standard, so all HTTP clients, proxies, CDNs, and load balancers correctly forward this status code. Using a standard code means no need to upgrade any layer of the network infrastructure; the payment protocol can run on the existing HTTP ecosystem directly.

---

x402 Protocol#

An open payment protocol proposed by Coinbase that activates the HTTP 402 status code. It specifies what to put in the 402 response (amount, token, recipient), how the client should sign for payment, and what signature format to use (EIP-3009 standard).

Onchain OS Payment uses two x402 schemes:

• exact: One-time payment — a simple, direct token transfer
• aggr_deferred: Batch payment — an extension OKX defined within the x402 framework, see Batch payment

---

MPP Protocol#

MPP (Machine Payments Protocol) is an open payment protocol led by Stripe / Tempo, positioned as a machine payments protocol for the Agent economy. MPP and x402 solve the same problem (letting machines pay autonomously), but with different design emphasis — MPP introduced the "intent" abstraction earlier.

Relationship between Agent Payments Protocol and MPP: Agent Payments Protocol's wire format is a strict superset of MPP EVM challenge / credential. Integrating MPP EVM means already integrating Agent Payments Protocol's charge. Agent Payments Protocol is not a thin wrapper over MPP — beyond MPP's EVM subset, it extends three more intents (escrow / session / upto, with deliveries / usage report / arbitration hook fields not specified by MPP) and broadens the transport layer from HTTP to IM / QR / offline.

---

Session Key#

A "temporary signing key" pre-authorized by the Buyer in the wallet. Within a pre-agreed authorization scope (limit cap, validity window, scope such as specific Seller domain / endpoint), the Agent can sign on the Buyer's behalf using the Session Key without invoking the Buyer's main private key.

Why it's needed: Agent automation operates at millisecond pace; "manually confirm every signature" is not viable. Session Key lets the Buyer authorize once and use many times — this is the prerequisite for Agent payment to run autonomously.

Relation to the main private key: Session Key is a restricted signing credential — the amount, purpose, and validity period it can sign are bounded by what the main private key authorized. Even if leaked, the loss is limited to the authorized scope.

Session Key is the core mechanism behind Batch payment.

---

TEE (Trusted Execution Environment)#

Trusted Execution Environment — a hardware-isolated trusted execution environment. Code and data running inside a TEE are invisible and tamper-proof to the rest of the system; even if the server's operating system is compromised, the TEE's interior remains safe.

Why Batch payment requires a TEE:

1. To bind the Broker so it cannot misbehave or bypass rules
2. To make aggregation results auditable — anyone can verify the aggregation was honestly executed

The TEE is the only compliant on-chain settlement path for Batch payment.

---

Escrow Contract#

"Escrow contract" is a generic industry term for an on-chain custody contract. This document refers to two independent escrow contracts:

Escrow contract for pay-as-you-go#

After the Buyer deposits funds into this contract, the funds are locked — no one can move them at will, including the Seller, even the Buyer themselves. They can only be moved according to protocol rules (settled by Voucher or refunded on channel close).

Why it's needed: It solves the trust problem on both sides of pay-as-you-go — the Buyer doesn't have to worry "you took my money and ran"; the Seller doesn't have to worry "the Buyer signed the bill and reneges". The rules are written into contract code; both sides can only follow the rules.

For the escrow contract used in escrow-payment scenarios, see Optimistic Escrow.

---

Voucher (Cumulative Receipt)#

The signed credential used in Pay-as-you-go. But unlike a traditional "amount-per-payment" credential, a Voucher records "cumulative due X as of now" rather than "deduct Y this time".

Why a cumulative amount: The cumulative structure provides two safeguards by construction:

• Anti-replay: Amounts increase monotonically; older Vouchers are rejected by the on-chain contract
• Loss-tolerant: Even if some Vouchers are lost or duplicated mid-stream, as long as the Seller holds the latest one, full settlement is recoverable

When it goes on-chain: Vouchers themselves never go on-chain — local signature verification by the Seller suffices. Only at mid-stream settle or channel close does the Seller submit the latest Voucher on-chain, and the on-chain contract pays out per Voucher amount.

What the Seller stores locally: Only the Voucher with the largest cumulative amount (i.e. the latest). Older Vouchers can be discarded — their cumulative amount has been superseded, and the on-chain contract won't accept Vouchers with amounts smaller than what's already settled.

Vouchers use EIP-712 signatures so wallets can render "you're signing a cumulative bill" cleanly.

---

Optimistic Escrow#

The on-chain contract standard for Escrow payment (designed by OKX). Defines four roles (Client / Provider / Receiver / Arbitrator), a six-state state machine, and three main execution paths (optimistic release, dispute arbitration, termination request).

Why "optimistic": Because most transactions don't need arbitration — both sides cooperate happily, and funds release to the Receiver automatically after the dispute window. The Arbitrator is invoked only on the exception path (Client actively raises a dispute). This matches real e-commerce data: the vast majority of orders never trigger after-sales disputes.

Relation to specific task systems: Decoupled. Optimistic Escrow specifies only fund custody and settlement; it doesn't bind to any specific task-publishing system. It can be combined with ERC-8004 (trusted Agent identity), ERC-8211 (smart batch processing), and other protocols.

---

Challenge / Credential#

Agent Payments Protocol defines only two message types at the transport layer: Challenge and Credential.

A2MCP (HTTP Seller) and A2A (Agent Seller) share the same wire format; they differ only in who plays the Seller role and which transport carries the challenge (HTTP 402 response vs. IM message body / URL / card / QR code).

Settlement results are not communicated through protocol messages; the Buyer / Seller obtain them through the Broker's status query endpoint (or the on-chain tx hash).

---

Messaging Channel#

The transport medium that carries Challenge / Credential in Agent Seller scenarios — any channel that lets two Agents exchange text qualifies; no specific protocol is required.

Common messaging channels:

• IM: XMTP, Telegram, Discord, Slack
• Email / Webhook: Email, custom HTTP webhook
• Offline / semi-online: deep links, QR codes, cards

Relation to HTTP: Protocol message semantics are identical across both transports; the only difference is the carrier — HTTP rides 402 response headers, while messaging channels ride message bodies / URLs / cards / QR codes.

Only Agent Sellers use messaging channels: HTTP Sellers always use HTTP. Agent Sellers, since they don't need a public deployment, can flexibly choose a messaging channel.

---

Broker (Protocol Role)#

The third-party role defined by Agent Payments Protocol, responsible for three things: verification, settlement, and state.

• Verification: Checks whether the Buyer-submitted signature is valid
• Settlement: Submits a verified signature to the chain for settlement
• State: Agent Payments Protocol messages (challenge / credential) carry no session memory; state is held by the Broker — minting paymentId, persisting challenges, tracking the state machine, exposing query endpoints

Relation to x402 Facilitator: Same architectural slot, different scope. The Facilitator is designed for a single HTTP round-trip and is stateless; the Broker shoulders commercial relationships that may span many steps and many days (e.g. Pay-as-you-go's cumulative Vouchers, Escrow payment's dispute window) and must persist challenges / paymentIds / Vouchers / state machines. For the one-time-payment case, the Broker behaves identically to a Facilitator.

Why it's needed: Technically the Buyer could transfer directly to the Seller, but the Broker solves several practical problems:

• The Seller doesn't have to run a node: The Broker handles on-chain interactions (RPC connections, gas management, transaction submission) on the Seller's behalf; the Seller only needs a recipient address.
• Verification and settlement are separated: The Broker does cryptographic verification first (~100ms, off-chain), then submits to the chain only after the credential is confirmed valid. This makes verification very fast while settlement remains reliable.
• Unified compliance entry: Compliance checks like KYT can be enforced uniformly at the Broker layer rather than being reimplemented by every Seller.

Is Onchain OS itself a Broker?: Yes. The core role of Onchain OS Payment is the Broker — receiving the Buyer's credential, verifying validity, running KYT, submitting to chain, confirming completion to the Seller — while also managing cross-session state. Coinbase's CDP Facilitator is the equivalent in the x402 context (single-round-trip only).

Does it touch funds?: The Broker submits on-chain transactions, but funds flow directly from Buyer to Seller's recipient address. The Broker doesn't custody funds and isn't an intermediary account. Its role is closer to a "notary" — verify and execute, but never hold. (In Pay-as-you-go / Escrow payment, funds are locked in on-chain Escrow contracts, also outside the Broker.)

Can I run my own?: Both Agent Payments Protocol and x402 are open protocols; anyone can implement their own Broker. But running one means maintaining blockchain node connections, gas management, transaction signing and broadcast, KYT compliance, state persistence — the full stack. Using Onchain OS Payment's Broker service saves you all of that.

---

EIP-3009#

An Ethereum signature standard that lets a user sign a "transfer authorization" — once a contract receives the signature, it can initiate the on-chain transfer on the user's behalf.

Role: The signature foundation for One-time payment. The point: the Buyer doesn't have to submit an on-chain transaction or pay gas; signing one message is enough. The Broker submits on their behalf.

---

EIP-712#

Ethereum's structured-data signing standard. Compared to ad-hoc string signing, EIP-712 makes signed content structured and human-readable — wallets can clearly render "you're signing this" (amount, address, deadline, etc.) instead of a hex blob.

Role: Session Key signing in Batch payment and Voucher signing in Pay-as-you-go are both based on EIP-712.

---

Gas Subsidy#

Fee waivers OKX provides for payment transactions on X Layer. On-chain transactions usually require gas (paid to miners/validators), but on X Layer, when paying with USDG or USD₮0, gas is zero — covered by OKX.

Scope: Only applies to payment transactions on X Layer using USDG and USD₮0. See Supported networks.

Significance for micropayments: Any small amount becomes economically viable. On a chain with gas fees, a $0.001 payment that costs $0.01 in gas is obviously a non-starter. With zero gas on X Layer, the Buyer's actual cost = the Seller's listed price, no overhead. This is a baseline condition for high-frequency low-value AI Agent calls.

Will it be removed?: The gas-subsidy policy depends on OKX's operational strategy. Even if the policy changes in the future, X Layer's gas rates themselves are far below high-cost chains like Ethereum mainnet.

---

KYT#

KYT (Know Your Transaction) is transaction-level compliance screening. By analyzing on-chain fund flows, it identifies transactions linked to sanctioned addresses, mixers, darknet markets, stolen funds, and other high-risk entities.

KYT vs. KYC:

The x402 protocol does not require user registration or KYC; Onchain OS achieves compliance at the transaction layer through KYT, filtering illicit funds while preserving anonymity.

Will it slow down payments?: Imperceptibly. KYT screening runs in parallel with transaction verification; impact on end-to-end latency is in the millisecond range.

What if I'm flagged?: Flagged transactions don't pass verification; the server doesn't return the paid resource and the Buyer isn't charged. The specific rejection reason is returned via an error code. If you believe it's a false positive, contact the Onchain OS support team.

Does the Seller need to implement KYT themselves?: No. Onchain OS automatically runs KYT during transaction verification — fully transparent to Sellers. This is one of the core differences between Onchain OS and the x402 protocol.

---

Next#

Want to start integrating#

Want to dive into the protocol layer#