What Is x402B? How On-Chain Escrow Protects AI Agent Payments

x402 connects network requests with payments through HTTP 402 Payment Required responses, enabling AI Agents to complete transactions according to the payment terms provided by the server.

x402B builds on this foundation by introducing escrow contracts, delivery status, and dispute resolution mechanisms, allowing payment authorization, fund locking, product or service delivery, and final settlement to be managed as separate stages. Boson Protocol deployed x402B on the Base mainnet on June 8, 2026. However, its scope of application, compatibility, and actual level of protection still need to be assessed based on the specific implementation.

Key Points

• x402B is an on-chain escrow extension developed by Boson Protocol for the x402 payment protocol. It uses smart contracts to manage transaction funds, allowing payment and final fund release to take place in stages.

• x402 primarily addresses automated payments, while x402B further addresses post-payment delivery risks. When a service purchased by an AI Agent cannot be delivered immediately, the escrow mechanism can provide additional protection.

• Non-custodial Escrow is the core mechanism of x402B. The buyer's funds enter an on-chain escrow contract instead of being transferred in full to the seller's account immediately after payment authorization.

• Delivery confirmation and dispute resolution determine how funds are released. Depending on the specific transaction rules, funds may be distributed after delivery confirmation, the end of the dispute period, or a dispute ruling.

• x402B provides new transaction infrastructure for Agent Commerce. It is suitable for AI Agent commercial scenarios that require asynchronous delivery, transaction protection, and automated settlement, but it cannot eliminate all fulfillment risks.

What Is x402B? How Is It Related to the x402 Payment Protocol?

x402B can be understood as an implementation that adds on-chain transaction protection to the x402 payment process. The core idea behind x402 is to embed payment requirements into the HTTP request and response process. When a client requests a paid resource, the server can return an HTTP 402 status code and provide acceptable payment methods. After the client completes the required authorization, it sends the request again. The server then verifies the payment conditions and decides whether to provide the resource. This model reduces the reliance of automated services on traditional account registration, subscription management, and manual payment processes.

For API calls with immediate delivery, this payment model is generally straightforward. For example, an AI Agent can request a model inference service, complete payment according to the API's quoted price, and receive the corresponding result. However, when a transaction involves customized content, long-running computing tasks, digital licenses, or goods that require waiting for delivery, there may be a time gap between payment and actual fulfillment. Under a direct payment model, once funds have been finally settled, the buyer generally cannot require the seller to return the funds based solely on the original payment protocol.

x402B addresses this issue by introducing an Escrow payment solution. The seller can provide escrow transaction terms in the HTTP 402 response. After the buyer signs the corresponding authorization, the funds are locked in a smart contract, and the release method is determined later based on the delivery and dispute status. It does not replace the entire x402 protocol with a new payment network. Instead, it uses x402's support for different payment schemes to extend its transaction settlement capabilities.

Why Do AI Agent Automated Payments Need On-Chain Escrow?

AI Agents can autonomously call services, compare quotes, and submit payment requests according to predefined tasks. However, completing a payment automatically does not mean that an AI Agent can automatically determine whether the transaction has been fulfilled. For an API request that returns a result immediately, the time gap between payment and service delivery may be very short. For a research report that takes several minutes to generate, a computing task that takes several hours to complete, or even a cross-border product purchase, the interval between payment and delivery may be much longer.

This time gap creates counterparty risk. For example, an AI Agent may pay 100 USDC to an unfamiliar service provider for a customized data report. If the funds are settled directly to the seller's address and the seller ultimately fails to deliver the content, the buyer must rely on an additional refund process, platform rules, or legal remedies to resolve the issue. For automated service providers without an established track record, traditional reputation mechanisms may not cover all risks.

On-chain escrow reduces some risks by changing the order in which funds are released. The buyer can first lock the funds in a smart contract. The seller then provides the product or service as agreed, after which the funds are distributed based on delivery confirmation, the dispute period, or other settlement conditions. This means that payment authorization no longer necessarily results in the seller receiving all funds immediately. However, escrow does not mean that a transaction will always succeed, nor can it automatically verify the quality of an off-chain product. The actual level of protection still depends on the delivery verification and dispute resolution mechanisms.

How Does the x402B Transaction Process Work?

x402B combines HTTP payment interactions with on-chain escrow status, enabling AI Agents to complete multiple steps from purchase to settlement through standardized requests. A typical process includes requesting a resource, obtaining a quote, signing an authorization, locking funds, completing delivery, and final settlement.

The buyer's AI Agent requests a resource from the server. The seller generates a transaction quote based on the request and provides escrow payment terms in the HTTP 402 response. These terms may include the price, supported tokens, the escrow contract address, and the seller-signed transaction commitment. After verifying the terms, the buyer signs a meta-transaction authorization and then submits the transaction to the blockchain through a Facilitator or another supported method. The smart contract locks the funds and records the corresponding transaction status.

After the funds are locked, the seller can provide the resource or delivery proof. Subsequent actions are determined by the transaction status and executable actions. The x402B design uses nextActions to describe the steps that can currently be performed, such as confirming delivery, initiating a dispute, or completing settlement. Depending on the specific implementation, funds may be released after delivery confirmation, the end of the dispute window, or dispute resolution. This mechanism expands a one-time payment process into a traceable transaction lifecycle.

How Does x402B's Non-Custodial Escrow Protect Transaction Funds?

Escrow is a mechanism that temporarily holds funds until the transaction conditions are satisfied. In traditional commercial activity, escrow is typically provided by a bank, payment institution, or third-party platform. In x402B, funds are managed by a smart contract according to predefined rules. After the buyer completes the authorization, the stablecoins are locked in an on-chain escrow contract. The seller cannot obtain the funds immediately merely because a payment request has been received.

x402B uses Boson Protocol's escrow infrastructure to manage transaction commitments and settlement status. The buyer and seller complete the transaction operations as agreed, and the smart contract distributes the funds based on delivery confirmation, dispute status, and time limits. The primary value of this mechanism is that it reduces reliance on a single payment platform or counterparty to hold the funds, while allowing the transaction records and fund release conditions to be verified on-chain.

However, non-custodial does not mean risk-free. Smart contract vulnerabilities, incorrect transaction parameters, unreasonable dispute windows, and insufficient delivery proof can all affect the final outcome. In particular, the actual quality of off-chain goods and services cannot be determined automatically based solely on blockchain status. Therefore, x402B provides a programmable transaction protection mechanism, not an unconditional guarantee of all transaction outcomes.

How Does x402B Confirm Product Delivery and Handle Transaction Disputes?

In automated AI Agent transactions, payment and delivery may occur at different times. To address this situation, x402B incorporates delivery status into the transaction lifecycle. For example, after a buyer purchases a digital service, the seller can provide the content or delivery proof through a designated channel, after which the buyer completes confirmation as required by the protocol. For certain products or services, delivery may also involve a redemption credential, an order status update, or other verification steps.

If the buyer believes that the seller has failed to fulfill the transaction, the buyer can initiate a dispute within the time window specified by the rules. Boson Protocol's design supports the participation of a Dispute Resolver. The specific mechanism may include negotiation between the parties, third-party adjudication, or settlement according to predefined timeout rules. The final distribution of funds depends on the transaction status, relevant signatures, and applicable dispute handling conditions, rather than being determined unilaterally by the buyer or seller.

It is important to note that dispute resolution does not mean that a fully automated smart contract will determine the quality of every product. For off-chain delivery, external evidence, manual adjudication, or trusted verification mechanisms may still be required. x402B's advantage is that it can connect the dispute outcome with the execution of on-chain funds. However, determining whether a transaction has actually been fulfilled may still depend on off-chain information.

What Are the Main Differences Between x402 and x402B?

The primary difference between x402 and x402B lies in their approaches to fund settlement and transaction lifecycle management. x402's exact payment scheme is better suited to scenarios where resources are provided immediately after payment, while x402B's escrow scheme is suitable for scenarios where there is a time gap between payment and delivery and additional transaction protection is required.

This comparison does not mean that x402 itself can only be used for simple transactions, nor does it mean that all services using x402 lack refund or dispute handling capabilities. Developers can implement transaction protection through other application-layer mechanisms. The difference with x402B is that it makes escrow payment an integrable payment scheme, directly linking the relevant rules with the on-chain status of the funds.

In addition, x402B does not require all existing x402 clients to automatically support escrow transactions. Only clients with the ability to process the corresponding payment scheme can correctly identify and execute the escrow process. Servers can provide both direct payment and escrow payment options, allowing different clients to choose based on their capabilities.

How Does x402B Work with EIP-712, Stablecoins, and Facilitators?

x402B does not rely on a single smart contract to complete the entire transaction. Instead, it combines off-chain signatures, stablecoin authorizations, on-chain contracts, and transaction relaying components. EIP-712 provides a structured data signing method, enabling buyers and sellers to sign quotes, transaction authorizations, and other parameters. Compared with signing opaque data directly, structured signing allows compatible wallets to display some transaction details more clearly. However, users still need to check the actual authorization scope.

For payment assets, x402B can use supported stablecoins such as USDC to lock funds. Its technical solution involves different paths, including EIP-3009, EIP-2612, Permit2, and standard token approvals. The specific method used depends on the asset, network, and integration conditions. Stablecoins serve as the unit of account and settlement medium, while the escrow contract manages the conditions for releasing funds. These components address different issues.

The Facilitator primarily assists with transaction submission and execution. The buyer can complete the signature first, after which the Facilitator submits the corresponding transaction to the blockchain. In certain implementations, this provides an experience in which the buyer does not need to pay Gas directly. However, Gasless does not mean that on-chain transactions have no cost. It means that another participant bears the cost. x402B also provides a direct on-chain operation path to reduce the impact on continued transaction execution when a Facilitator is unavailable.

What AI Agent Commercial Scenarios Can x402B Support?

Digital content and professional service procurement. An AI Agent may need to purchase industry reports, customized data, software licenses, or third-party research services. These products generally cannot be delivered immediately like a simple API response, and some services also need to generate content based on user requirements. With x402B, the buyer can lock the funds at the time of payment, and the seller can proceed to settlement after delivering the product or service as agreed.

Agent-to-Agent Commerce refers to automated commercial transactions between AI Agents. For example, a market research Agent can purchase computing services from a data analysis Agent, which then calls other models or data sources to complete the task. Multiple independent service providers may not have an established long-term relationship. Standardized transaction commitments, escrowed funds, and dispute resolution mechanisms can therefore reduce some counterparty risks.

Automated e-commerce and physical goods procurement. An AI Agent can be responsible for finding products, comparing quotes, submitting orders, and authorizing payments, while delivery still depends on merchants, logistics providers, and other real-world processes. Boson Protocol has demonstrated a purchasing flow that combines a Facet store, USDC, and x402B escrow. These cases show that automated payments can be combined with real-world product transactions. However, a demonstration in a testing environment does not amount to large-scale commercial adoption.

What Technical and Commercial Limitations Does x402B Face?

First, x402B needs to address delivery verification. For data returned by an API, it may be relatively easy to determine whether the server responded successfully. However, for customized research, design work, or physical goods, determining whether the delivery meets the agreed terms often involves subjective standards. Even if escrow and settlement occur entirely on-chain, the protocol cannot determine whether a product has quality issues based solely on transfer records.

The second limitation involves locked capital and transaction costs. The escrow mechanism improves transaction protection but may also extend the time required to release funds. For low-value, high-frequency API requests, direct payment may be simpler. If every transaction requires escrow status, delivery confirmation, and a dispute window to be maintained, the additional processes and execution costs may offset some of the efficiency advantages. Therefore, x402B may not be suitable for every AI Agent payment scenario.

The final limitation involves compatibility and adoption. x402B's escrow payment scheme requires support from clients, servers, and related relay components. It cannot be assumed that all x402 applications already have these capabilities. Its long-term development will also depend on smart contract security, the reliability of Dispute Resolvers, payment asset liquidity, developer integration costs, and actual transaction demand. Existing technical implementations and commercial cases can demonstrate some feasibility, but they are still insufficient to prove that this model will become a universal standard for all Agent Commerce transactions.

What Does x402B Mean for the Development of Agent Commerce?

The development of Agent Commerce is driving payment infrastructure to expand from simple fund transfers to complete transaction management. When an AI Agent only needs to purchase an API service that returns results immediately, automated payment capabilities may be sufficient. However, when Agents begin purchasing customized services, coordinating multiple suppliers, or participating in real-world product transactions, payment authorization, fulfillment confirmation, refunds, and dispute resolution need to become interconnected stages.

x402B provides a technical path for connecting these stages. Through HTTP payment requests, on-chain escrow, structured signatures, and executable transaction states, AI Agents can obtain a certain level of transaction protection while reducing the need for human involvement. This model can also help create more standardized automated procurement processes, enabling different developers and service providers to build applications around shared payment and settlement interfaces.

However, the maturity of Agent Commerce depends not only on payment technology. Identity verification, transaction authorization, service quality evaluation, dispute governance, and compliance frameworks also need to develop together. x402B addresses only some of the issues related to fund escrow and settlement. Its actual value will ultimately need to be assessed through real transaction volume, fulfillment rates, fund security, and developer adoption.

Summary

x402B is an on-chain escrow extension developed by Boson Protocol on the foundation of the x402 payment system. Compared with direct settlement methods primarily designed for immediate payments, x402B incorporates fund locking, product or service delivery, dispute handling, and final settlement into a single transaction process, providing additional transaction protection for AI Agents purchasing services that are not delivered immediately.

Its core value is not to make AI Agents pay faster, but to establish a clearer connection between automated payments and transaction fulfillment. As AI Agents gradually participate in more complex digital service procurement and commercial transactions, non-custodial Escrow may become an important piece of infrastructure for Agent Commerce. However, its security, scope of application, and commercial maturity still require ongoing validation.

FAQ

What Is x402B?

x402B is an x402 payment extension developed by Boson Protocol. It uses a non-custodial on-chain escrow contract to manage transaction funds and supports delivery confirmation and dispute resolution.

Is x402B the Same Protocol as x402?

They are not exactly the same concept. x402 is a network-native payment protocol, while x402B is a specific extension that adds escrow transaction capabilities to the x402 payment interaction framework. Not all x402 clients support it automatically.

Does x402B Require an AI Agent to Hold ETH to Pay Gas?

Not necessarily. In scenarios that support transaction relaying, a Facilitator can submit the transaction and pay the Gas, so the buyer does not need to hold the native token required to pay Gas. However, on-chain execution costs still exist.

Can x402B Guarantee That an AI Agent Will Not Be Defrauded?

No. On-chain escrow can reduce some risks of non-delivery after payment, but it cannot eliminate issues such as smart contract vulnerabilities, false delivery proofs, or incorrect dispute rulings.

Can x402B Only Use USDC?

No. USDC is a stablecoin used in existing integration cases. The specific supported assets depend on the relevant network, token authorization mechanism, and server configuration.

What Types of Transactions Is x402B Suitable For?

It is better suited to transactions where there is a time gap between payment and delivery or where the buyer and seller require additional fulfillment protection. Examples include customized digital services, software procurement, asynchronous computing tasks, and certain product transactions.