The agentic commerce protocol is a shorthand for the stack of standards that lets AI agents transact autonomously with merchants, APIs, and other agents. It is not one document from one company. It is a convergence of efforts — Stripe's ACP, OpenAI's checkout work in ChatGPT, Anthropic's tool-use patterns, and a cluster of Ethereum Improvement Proposals — all pointing at the same shape: agent identity, bounded authorization, and stablecoin settlement. If you are designing a system where software initiates payments, you are building on this protocol whether or not you use that name.

This guide decomposes the agentic commerce protocol into its three working layers: identity (who the agent is and what it represents), authorization (what it may spend and under what constraints), and settlement (where the money actually moves). You will see which standards matter today, how Stripe's announcement and OpenAI's agentic checkout fit the model, and why cross-chain settlement via an orchestration layer like Eco Routes is the final piece that turns a single-chain demo into a production agent payment system.

Strip away the branding and an agentic commerce protocol is a contract between four parties: the user who delegates authority, the agent that acts on their behalf, the counterparty that sells goods or services, and the settlement rail that moves the money. The protocol specifies how the agent proves who it is, how the user bounds what it can spend, how the counterparty verifies the transaction, and how the money arrives.

Stripe introduced its Agentic Commerce Protocol (ACP) in 2025 to formalize the checkout side of this contract. OpenAI rolled out Buy It in ChatGPT as an early consumer-facing instantiation, letting users complete purchases inside a conversation. Google shipped an Agent-to-Agent protocol focused on agent interoperability. These efforts converge on the same primitives even though they enter the stack at different layers.

To reason about any agentic commerce protocol, separate the stack into three layers. The identity layer answers "who is this agent and what is it authorized to represent?" The authorization layer answers "what may it spend, on what, and under what constraints?" The settlement layer answers "where does the value actually move and with what finality?"

Most protocol announcements you see in 2025 and 2026 are partial. Stripe's ACP is primarily an identity and authorization spec. x402 is an authorization and payment-trigger spec. ERC-8004 is a pure identity spec. ERC-7683 is a pure settlement-intent spec. A complete system stitches them together, which is why understanding the layers matters more than picking one vendor's umbrella term.

Agent identity is more than a public key. A useful identity answers three questions: which user or organization does this agent represent, which model and version produced its actions, and what is its track record. Without verifiable answers, a counterparty has no basis to extend credit, grant spending limits, or comply with KYC-adjacent obligations. This is the same accountability gap that stablecoin compliance tools solve for human-originated payments, adapted to software counterparties.

The emerging Ethereum standard for this is ERC-8004, which defines a registry for trustless autonomous agents onchain. An agent registers its identity, capabilities, and attested operator; counterparties query the registry to verify. Off-chain, Stripe's ACP defines an equivalent identity envelope for agents operating through traditional merchant infrastructure. The two are complementary — an ERC-8004 agent can present its onchain identity to a Stripe-integrated merchant, and vice versa.

OpenAI's approach inside ChatGPT is more opinionated: the agent identity is implicitly the ChatGPT Business account, and the platform handles the handshake with merchants. Anthropic's published work on tool use and computer use takes the opposite stance, treating identity as something the developer composes at the application layer. Both are valid; both ultimately need to interoperate with standards like ERC-8004 when the counterparty is outside the originating platform.

Authorization is the protocol's hardest and most interesting layer because it has to balance two opposing forces: agents need enough autonomy to be useful, and users need enough control that a misbehaving agent cannot drain an account. The answer the industry has settled on is bounded delegation expressed in code.

On Ethereum, bounded delegation lives in ERC-4337 session keys. A user's smart-contract wallet grants a session key to the agent with narrow constraints: spend up to N tokens, only on these contracts, only until this timestamp. The agent operates freely within that envelope and cannot step outside it. EIP-7702 extends similar delegation semantics to regular externally-owned accounts, which dramatically lowers the onboarding friction for users who do not already hold a smart-contract wallet.

On the HTTP side, Cloudflare's x402 protocol handles authorization inline with each request. An API returns a 402 Payment Required response describing what it costs; the agent's wallet pays and retries; the API serves the response. There is no up-front negotiation or subscription; every call carries its own authorization. This is the natural fit for agent-to-agent compute and data purchases where the counterparty and cost are unknown in advance.

Stripe's ACP slots in at the merchant-integration layer. It defines how a merchant's checkout advertises what authorizations it needs (one-time purchase, subscription, metered billing), how the agent responds with a signed authorization envelope, and how that envelope is later exchanged for settlement. Merchants who integrate ACP get agent traffic without having to build agent-specific flows themselves — the protocol handles it.

Settlement is where a real-world agentic commerce system separates from a slideware demo. The identity and authorization layers can be simulated with test fixtures. Settlement either works in production or it does not. It has to clear within a latency bound the agent workflow tolerates, it has to deliver the exact asset the counterparty accepts on the exact chain they operate on, and it has to be auditable after the fact.

Stablecoins are the default settlement asset because their properties match what agents need: finality in seconds, 24/7 availability, programmability, and open access. Circle's Cross-Chain Transfer Protocol (CCTP) moves native USDC between supported chains by burning on the source chain and minting on the destination. LayerZero, Hyperlane, and Wormhole provide general-purpose cross-chain messaging that can carry stablecoin movements alongside arbitrary data. ERC-7683 standardizes how an intent — "pay X on chain A, receive Y on chain B" — is expressed so any solver can fulfill it.

These are the rails. They are not in competition with each other; they are substrates that different counterparties prefer for different reasons. An agent that only ever transacts with USDC on Base can ignore most of them. An agent that fans out across 15 chains cannot. For the latter, the practical answer is an intent settlement layer that consumes these rails and exposes a uniform settlement interface to the agent.

A useful way to see the settlement layer is the three-tier model. Rails are the underlying primitives — CCTP, LayerZero, Hyperlane, Wormhole, ERC-7683 as a shared intent format. Layers are the orchestration systems that consume those rails to deliver outcomes — Eco Routes, Across, Relay, LiFi. Apps are what the agent actually integrates against. An agent signs an intent at the app level, the layer routes it using whichever rail is fastest or cheapest for the specific pair, and the agent does not have to care about the choice. If you are choosing an orchestration layer, the cross-chain stablecoin swap infrastructure breakdown covers the options in detail.

The rail/layer/app separation matters for the agentic commerce protocol because it means the settlement layer does not have to be re-negotiated per chain. An ACP-compliant merchant on Base, an x402-priced API on Arbitrum, and an ERC-8004-identified counterparty on Optimism can all be paid through the same orchestration layer. The agent's code sees a single settlement interface.

Eco Routes is the settlement layer that ACP implementations plug into when they need cross-chain coverage. A merchant running on Base can accept payments from an agent whose wallet lives on Arbitrum without the merchant integrating a bridge or the agent learning where the merchant's funds sit. The agent signs an intent via Routes CLI or the Routes API; solvers compete to fulfill it; settlement is atomic — completes fully or reverts entirely, which is the property an ACP checkout flow actually needs.

Fifteen chains are supported today: Ethereum, Optimism, Base, Arbitrum, HyperEVM, Plasma, Polygon, Ronin, Unichain, Ink, Celo, Solana, Sonic, BSC, and Worldchain. Seven stablecoins route across them: USDC, USDT, USDC.e, oUSDT, USDT0, USDbC, and USDG. For developers building on top, the treasury API comparison is a useful starting point.

Imagine an agent that helps a small business reconcile vendor invoices. The user delegates to the agent via an ERC-4337 session key with a $10,000 weekly cap, scoped to addresses on an approved vendor list. Each vendor exposes either an ACP-compliant checkout endpoint (for subscription software) or an x402 endpoint (for per-call compute), both declaring their preferred stablecoin and chain.

When the agent needs to pay Vendor A — USDC on Base, $240 monthly subscription — it executes the ACP handshake: requests the merchant's current price, receives a signed quote, signs an authorization, and triggers settlement. The session key enforces the weekly cap and the vendor allow-list.

When the agent needs to pay Vendor B — USDT on Arbitrum, metered compute at $0.002 per call — it uses the x402 flow. Each API call returns a 402 with the price; the agent's wallet pays inline; the response streams back. No up-front contract.

Both flows settle through the same cross-chain orchestration layer. The agent's wallet holds USDC on Optimism; the orchestration layer routes the Base payment via CCTP and the Arbitrum payment via a solver-filled intent, atomically, in seconds. The agent never sees the rail selection. It just sees that the intent it signed resulted in the expected state on the expected chain. Teams implementing this end-to-end often pair it with stablecoin swap aggregators for asset conversion when the source and destination stablecoins differ.

The agentic commerce protocol landscape is moving fast but converging. Three things worth tracking this year. First, whether ACP and x402 develop interoperability — early signals suggest yes, with x402 being used as an ACP-compatible payment-trigger mechanism. Second, ERC-8004 adoption by major agent frameworks; wide adoption means identity portability across ecosystems. Third, cross-chain intent standardization — the intent-based routing protocols landscape is coalescing around ERC-7683 as the common format.

For teams shipping now, the right stance is to build on the layers you need today (session-key authorization, stablecoin settlement, cross-chain orchestration) and stay on the compatibility path for ACP and ERC-8004 as those standards stabilize. You do not need to wait for the protocol to be "done" — you just need to avoid lock-in to anything that is clearly an intermediate step. A good programmable treasury automation stack is the foundation to build on, and picking the right solver network for stablecoins is where settlement-layer performance actually comes from.

The agentic commerce protocol is the emerging stack of standards that lets AI agents authorize, initiate, and settle payments autonomously. It spans identity (ERC-8004, Stripe ACP), authorization (ERC-4337 session keys, x402), and settlement (CCTP, ERC-7683, orchestration layers). No single spec covers all three layers, which is why the "protocol" is really a family.

Stripe's Agentic Commerce Protocol is one implementation of the checkout and authorization layer of the broader agentic commerce stack. It handles merchant-side integration for agent payments but relies on underlying settlement rails — typically stablecoins on public chains — for the actual money movement. It interoperates with standards like ERC-8004 and x402 rather than replacing them.

On Ethereum, authorization is expressed via ERC-4337 session keys or EIP-7702 delegations. A user's wallet grants the agent bounded authority — spend limits, allow-listed contracts, time windows. Off-chain, protocols like Stripe's ACP carry an authorization envelope signed by the user. Both mechanisms let an agent act within constraints the user set in advance.

Agents increasingly transact with counterparties on multiple chains. Without cross-chain settlement, developers write bespoke bridge logic per counterparty. An orchestration layer like Eco Routes consumes rails (CCTP, LayerZero, Hyperlane) and exposes a single intent-based interface, so the agent signs one intent and settlement lands on the correct chain and asset atomically.

Any regulated or widely-held stablecoin can be an ACP settlement asset. Most production deployments default to USDC or USDT because liquidity and chain coverage are deepest. Orchestration layers extend the set — Eco Routes supports USDC, USDT, USDC.e, oUSDT, USDT0, USDbC, and USDG across 15 chains, so merchants and agents rarely have to negotiate which variant to use.