Core Concepts#

HTTP 402#

What is HTTP 402?

HTTP 402 is a reserved status code in the HTTP specification, meaning "Payment Required" -- the client must pay to access the resource. It was defined in the HTTP/1.1 specification (RFC 2616) back in 1999, but since there was no accompanying payment mechanism at the time, it remained in a "reserved but unused" state for over twenty years.

Why has 402 never been put to use?

Because the HTTP specification only defined the semantics of the status code ("payment required"), but did not define how to pay, whom to pay, or how to verify payment. Without a standardized payment flow, browsers and clients had no idea what to do upon receiving a 402. The x402 protocol was created to fill this gap -- it defines a complete payment interaction flow based on 402. See the x402 Protocol FAQ for details.

Why use 402 instead of a custom status code?

Because 402's semantics already mean "payment required" -- this is part of the HTTP standard, and all HTTP clients, proxies, CDNs, and load balancers can correctly transmit this status code. Using a standard status code means no modifications are needed to any intermediate layer of network infrastructure, and the payment protocol can run directly on top of the existing HTTP ecosystem.

x402 Protocol#

What is x402?

x402 is an open payment protocol standard based on the HTTP 402 status code. It defines a complete request-pay-deliver flow: the server returns 402 + payment requirements -> the client pays on-chain -> the client retries with a payment credential -> the server verifies and returns the resource.

What are the roles in the x402 protocol?

• Buyer: The party that initiates the request and makes the payment, typically an AI Agent or application client. The Buyer signs and constructs a payment credential, submitting it to the Seller via an HTTP request header.
• Seller: The party that provides paid APIs or resources. The Seller returns 402 + payment requirements on unpaid requests, and delivers the resource upon receiving a valid payment credential.
• Facilitator: A third-party service responsible for payment Verification and on-chain Settlement. The Facilitator frees the Seller from maintaining blockchain nodes, managing Gas, and submitting transactions -- all of which are handled by the Facilitator. The core role of Onchain OS Payment is the Facilitator.

Who proposed x402?

x402 was proposed and open-sourced by Coinbase, and is currently being advanced by the x402 Foundation (co-governed by Coinbase and Cloudflare). It is an open standard that anyone can implement.

Is x402 only for AI Agents?

No. x402 is a general-purpose HTTP payment protocol that can be used by browsers, mobile apps, CLIs, and automation scripts. AI Agents are currently the most typical use case, because Agents need to autonomously complete paid API calls without human intervention.

Facilitator#

What is a Facilitator?

A Facilitator is a third-party role in the x402 protocol, responsible for payment Verification and on-chain Settlement. In x402's Buyer-Seller-Facilitator three-party architecture, the Facilitator serves as the trust layer in between: after the Buyer signs a payment, the Facilitator verifies the validity of the payment credential and submits the on-chain transaction, so the Seller does not need to maintain blockchain infrastructure on its own.

Why is a Facilitator needed? Can't the Buyer just transfer directly to the Seller?

Technically yes, but the Facilitator solves several practical problems:

Seller doesn't need to run nodes: The Facilitator handles on-chain interactions for the Seller (RPC connections, Gas management, transaction submission), and the Seller only needs a receiving address.

Verification and Settlement are separated: The Facilitator first performs cryptographic verification (~100ms, off-chain), and only submits the on-chain Settlement after confirming the payment credential is valid. This makes verification extremely fast while ensuring reliable settlement.

Unified Compliance entry point: Compliance checks such as KYT screening can be executed uniformly at the Facilitator layer, rather than each Seller implementing them individually.

Is Onchain OS a Facilitator?

Yes. The core role of Onchain OS Payment is the Facilitator -- receiving the Buyer's payment credential, verifying its validity, performing KYT screening, submitting on-chain Settlement, and confirming payment completion to the Seller. Coinbase also provides its own Facilitator service (CDP Facilitator); both are different implementations of the same role.

Does the Facilitator have access to my funds?

The Facilitator submits on-chain transactions, but funds transfer directly from the Buyer to the Seller's receiving address. The Facilitator does not custody funds, nor does it act as an intermediary account. Its role is more like a "notary" -- it verifies and executes, but does not hold funds.

Can I build my own Facilitator?

x402 is an open protocol, and in theory anyone can implement their own Facilitator. However, building your own means you need to maintain the full suite of infrastructure: blockchain node connections, Gas management, transaction signing and broadcasting, KYT Compliance, and more. Using the Onchain OS Payment Facilitator service can save you from all of this.

Settlement#

What is Settlement?

Settlement is the on-chain execution process where, after the Buyer's payment credential is verified by the Facilitator, funds are actually transferred from the Buyer's address to the Seller's receiving address. In the x402 flow, Settlement is handled by the Facilitator -- the Seller does not need to submit on-chain transactions on its own.

In simple terms: Verification answers "is this payment valid?", while Settlement answers "when do the funds arrive?". Onchain OS supports both Synchronous Settlement and Asynchronous Settlement modes, which differ in whether the Seller waits for fund confirmation before delivering the resource, or delivers first with the funds arriving shortly after.

What is Synchronous Settlement?

Synchronous Settlement (syncSettle = true) means the Facilitator submits the on-chain transaction and waits for final confirmation before notifying the Seller to deliver the resource. "Confirm first, deliver second" -- no bad debt risk, but requires waiting for on-chain block confirmation.

What is Asynchronous Settlement?

Asynchronous Settlement (syncSettle = false) means the Facilitator returns a transaction hash immediately after verifying the payment credential, and the Seller delivers the resource right away, while on-chain confirmation completes asynchronously in the background. "Deliver first, confirm later" -- near-zero latency, suitable for high-frequency, low-value scenarios.

Is Asynchronous Settlement safe? Is there bad debt risk?

Extremely low. Once a transaction is broadcast to the chain, it is virtually impossible to roll back (especially under X Layer's finality mechanism). Onchain OS checks transaction parameters and broadcast status during the verification step, leaving an extremely narrow window for fraud. For high-frequency, low-value calls (e.g., an inference API at $0.001 per call), the risk-reward ratio of Asynchronous Settlement is far better than the latency cost of Synchronous Settlement.

Which mode should I choose for my use case?

A simple rule of thumb: if the value per call is less than $1 and the call frequency is high, choose asynchronous; if the value per call is high or you have strict requirements for fund confirmation, choose synchronous. Most AI Agent scenarios are suitable for Asynchronous Settlement.

What happens if Asynchronous Settlement fails?

If an on-chain transaction ultimately fails to confirm (extremely rare), the Seller can track it through Onchain OS's settlement status API. At the protocol level, an unconfirmed transaction means the Buyer was not actually charged, and the loss is borne by the Seller -- but the probability is extremely low.

Gas Subsidy#

What is Gas Subsidy?

Gas Subsidy is the fee waiver provided by OKX for payment transactions on X Layer. Normally, on-chain transactions require paying Gas fees (miner/validator processing fees), but when making x402 payments with USDG or USDT on X Layer, the Gas fee is zero -- covered by OKX.

Does Gas Subsidy apply to all chains?

No. Gas Subsidy currently only applies to payment transactions using USDG and USDT on X Layer. When paying on other chains, Gas fees are borne by the Buyer at the standard rate.

What does zero Gas mean for micropayments?

It means any amount, no matter how small, is economically viable. On chains with Gas fees, a $0.001 payment with a $0.01 Gas fee is clearly unreasonable. With zero Gas on X Layer, the Buyer's actual cost = the Seller's listed price, with no additional overhead. This is a foundational requirement for high-frequency, low-value AI Agent call scenarios.

Will Gas Subsidy be discontinued?

The Gas Subsidy policy depends on OKX's operational strategy. It is recommended to follow Onchain OS official announcements for the latest information. Even if the policy is adjusted in the future, X Layer's Gas fee rate is still far lower than high-cost chains like Ethereum mainnet.

KYT#

What is KYT?

KYT (Know Your Transaction) is a transaction-level Compliance screening technology. It analyzes on-chain fund flows to identify transactions associated with high-risk entities such as sanctioned addresses, mixers, darknet markets, and stolen funds.

What is the difference between KYT and KYC?

KYC (Know Your Customer) is identity verification of "people" -- who you are, where you live, your ID number. KYT is risk assessment of "transactions" -- where the funds came from, and whether they are associated with high-risk activities. The x402 protocol does not require user registration or KYC, but Onchain OS achieves Compliance at the transaction level through KYT, filtering illicit funds while preserving anonymity.

Does KYT screening slow down payments?

Not noticeably. KYT screening is executed in parallel with transaction verification, and its impact on end-to-end latency is on the order of milliseconds.

What if my transaction is flagged by KYT?

A flagged transaction will not pass verification, the server will not return the paid resource, and the Buyer will not be charged. The specific rejection reason will be returned via an error code. If you believe it is a false positive, you can contact the Onchain OS support team.

As a Seller, do I need to perform KYT myself?

No. Onchain OS automatically performs KYT checks during the transaction verification step, completely transparent to the Seller. This is one of the core differentiators of Onchain OS compared to the bare x402 protocol.