Payment methods#

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

---

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 high-frequency micropayment 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.

---

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

---

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.

A2T (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. cumulative Vouchers in Pay-as-you-go, the dispute window in Escrow payment) 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.