Skip to main content
x402 is an open protocol, not a Fireblocks product. The Fireblocks facilitator and agent implement the same standard that other tools across the ecosystem do, so they interoperate with x402 services and directories you do not control. This page maps the landscape and where Fireblocks fits. For the protocol mechanics, see x402 Concepts and Glossary.

​
The open protocol

The x402 specification lives at x402.org and defines the 402 handshake, the PaymentRequired body, and the roles of client, resource server, and facilitator. Any compliant facilitator can settle a payment any compliant client signs, on any supported network. The Fireblocks facilitator follows x402 v2; see the Protocol Reference for the exact message shapes it emits and accepts. What Fireblocks adds is the settlement and custody layer underneath the protocol. Payments settle through a Fireblocks vault, raw private keys never leave Fireblocks, and spending is governed by Fireblocks Policy rules. The protocol stays standard; the key management and controls are the Fireblocks contribution.

​
Discovery and the Bazaar

The Coinbase x402 Bazaar is a directory where agents discover x402-enabled services across the ecosystem. The Fireblocks facilitator’s discovery API (GET /api/discovery/resources) returns resources in the same shape the Bazaar uses, so a Bazaar-aware agent can read a Fireblocks-hosted catalog with the same code. You decide which products are discoverable; publishing a product exposes only its public quote, never your vault or keys. See Publish to the discovery catalog.

​
Agents and the MCP ecosystem

x402 is designed for agent-to-service commerce, and the agent tooling reflects that. The x402 Agent ships as a Model Context Protocol (MCP) server, so any MCP-compatible client (Claude Desktop, Cursor, and others) can pay for resources through a Fireblocks vault by calling a tool. Because the payment side is standard x402, the same agent pays both Fireblocks-hosted services and third-party x402 endpoints. The broader ecosystem is also converging on standards for how agents authorize payments, such as Google’s Agent Payments Protocol (AP2), which can use x402 as a settlement rail. As these standards stabilize, an x402 facilitator remains the component that verifies and settles, regardless of how the agent obtained its authorization.

​
Where Fireblocks differs

The Fireblocks implementation makes choices an operator should know when interoperating:
  • Custody. Settlement runs through a Fireblocks vault using MPC-based key management, so the facilitator process holds no signing material. Many other facilitators sign with a hot key the operator manages directly.
  • Transfer mechanisms. The facilitator settles eip-3009, permit2, upto-permit2, and erc7710. The agent signs eip-3009 and permit2 only, because Fireblocks cannot sign ERC-7710 delegation payloads. A service that offers only ERC-7710 cannot be paid by the Fireblocks agent, though it can be settled by the Fireblocks facilitator.
  • Controls. Spending and settlement are governed by Fireblocks Policy rules rather than application code, which is how a company bounds autonomous agent spend. See Fund and Control Agent Spending.
The x402 protocol specification is independent of Fireblocks and may evolve separately. Third-party components in the ecosystem (other facilitators, directories, token contracts, and delegation frameworks) carry their own risks. Review the facilitator’s DISCLAIMER.md before relying on them in production.