x402 and the Agentic Web: How AI Agents Will Pay Each Other

The web is shifting from human-first interfaces to machine-first highways. In this emerging “Agentic Web,” AI agents browse, negotiate, and transact on our behalf—subscribing to APIs, paying for models, tipping data providers, and settling micro-bounties for computations. To make that real, agents need a native, interoperable way to pay each other online and to authenticate paid access across heterogeneous services. That is where the idea of x402 comes in: a pragmatic extension of HTTP’s “402 Payment Required” pattern paired with cryptographic receipts and modern crypto rails.

This article explores x402 as a design pattern for agent-to-agent payments, the rails likely to power it, the standards already available, and the security model that will make it safe at scale.

The Agentic Web Needs Native Payments

Most web services today are optimized for human logins and card-based billing. AI agents have different needs:

• They consume APIs at machine speed and require per-request or per-second pricing.
• They negotiate across multiple providers and must switch rapidly based on latency, cost, or quality.
• They cannot store card numbers, nor should we bind them to centralized identities.
• They need programmable wallets, policy controls, and cryptographic receipts to make access portable.

HTTP already contains a hint for this world: the 402 Payment Required status code. While 402 is not standardized for general use, it signals that a resource is gated by payment. Developers have occasionally used it to implement paid APIs, and MDN documents its semantics and reserved status for future use. See MDN’s overview of 402 Payment Required for context (link at the end of this paragraph). MDN Web Docs: 402 Payment Required

On the Bitcoin side, the Lightning Network pioneered practical micropayments with streaming, instant settlement over payment channels. It’s widely studied and deployed; for a technical overview, see Bitcoin Optech’s topic page. Bitcoin Optech: Lightning Network

On Ethereum and EVM chains, Account Abstraction (AA) via ERC‑4337 introduced smart-wallet features, including “paymasters” that can sponsor or conditionally cover gas fees for users or autonomous agents, enabling gasless or policy-based transactions. EIP‑4337: Account Abstraction

These building blocks—402 signaling, Lightning micropayments, and AA paymasters—point to a near-future pattern for agent-native payments.

What Is x402?

x402 is a design pattern that combines HTTP 402 challenges with cryptographic payment proofs and programmable wallets. It is not a formal standard; rather, it is a pragmatic approach that service operators and builders can adopt today to bootstrap paid machine-to-machine interactions.

In an x402 flow:

1. An agent requests a resource or API endpoint.
2. The server returns 402 Payment Required with a machine-readable challenge that includes:
   • Accepted payment methods: BOLT11 invoices (Lightning), LNURL‑pay, ERC‑681 payment URIs (EVM), or stablecoin options.
   • A time-bound quote or tariff schedule.
   • A nonce/quote ID to prevent replay.
   • An optional token schema for post-payment authentication (e.g., macaroon-like tokens or signed receipts).
3. The agent pays via the chosen rail and submits a proof:
   • Lightning: invoice preimage or a signed receipt.
   • EVM: transaction hash meeting ERC‑681 parameters.
   • Streaming settlement: a live stream established via Superfluid for duration-based access.
4. The server verifies payment and issues a capability token for continued access without repeating the full payment handshake, with TTL and scope limits.

This decouples identity from billing while giving agents the primitives they need: payment negotiation, proof of settlement, and portable, time-bound capabilities.

For developers exploring paid APIs over Lightning and HTTP 402 patterns, Lightning Labs’ work on L402 and LSAT shows one practical path, combining invoices with macaroons-style access tokens. Lightning Labs GitHub: L402

Payment Rails For Agents

Agents will pick rails based on cost, latency, and counterparty compatibility. Expect multi-rail support to be the norm.

• Lightning for Bitcoin micropayments and low-latency streams.
  • Strong for frequent, tiny payments and pay-per-request APIs.
  • Can pair with capability tokens after payment verification. Bitcoin Optech: Lightning Network
• EVM smart wallets with ERC‑4337 paymasters for flexible fee policies.
  • Agents can transact without gas in the base currency; paymasters can charge in stablecoins, set rate limits, or sponsor authorized calls. EIP‑4337: Account Abstraction
• ERC‑681 payment links for standardized payment URIs.
  • Service providers can present payment requests in a consistent format across EVM chains. EIP‑681: Payment Requests
• Stablecoins (e.g., USDC) for predictable pricing and treasury operations across chains.
  • Useful for settling larger invoices or balancing accounts post‑stream. Circle: USDC
• Streaming payments for time-based services (compute, bandwidth, or model access).
  • Streaming reduces prepayment friction and aligns cost with real usage. Superfluid: Streaming Payments
• Cross-chain settlement or routing when providers and agents live on different L2s or chains.
  • Interoperability layers like CCIP can connect disparate environments; implement carefully with security review. Chainlink CCIP

Identity, Receipts, and Authorization

Payments are only half the problem. Agents need a way to prove entitlement after payment without leaking keys or enduring repeated on-chain settlement.

• Capability tokens: Similar to macaroons, they can encode caveats like expiration, scope, or usage limits. They’re portable across calls but revocable and time-bound.
• Signed receipts: On-chain transactions already produce canonical identifiers; Lightning produces preimages. Services can accept either as proofs and issue session capabilities.
• DIDs and decentralized identifiers: Agents can use DIDs to present cryptographic identities compatible with verifiable credentials, reducing dependency on centralized OAuth. W3C DID Core
• WebAuthn for operator-attested actions: If humans supervise agents, WebAuthn-based multisig or approvals can bind key material to hardware-backed authenticators. W3C WebAuthn

Why Now: 2025 Context

Several 2024–2025 developments make the Agentic Web and x402 viable:

• Post‑Dencun rollups have reduced data availability costs, making microtransactions and paymasters more feasible for everyday agent operations on L2s. Ethereum Foundation: Dencun on Mainnet
• ERC‑4337 wallets and paymasters are maturing, and new proposals like EIP‑7702 allow EOA accounts to temporarily act like smart wallets for better UX and policy control—ideal when agents need bounded permissions to spend or sign. EIP‑7702
• Decentralized AI networks are proliferating, creating native marketplaces where agents buy and sell inference, models, or data. Projects like Autonolas and Bittensor illustrate on-chain autonomous services and AI‑driven economies. Autonolas / OLAS Bittensor

This stack—cheaper L2s, programmable wallets, and AI native marketplaces—sets the stage for agent-to-agent commerce with cryptographic enforcement.

A Minimal x402 Handshake

Here’s a conceptual sketch of the messages in an x402 flow. It’s illustrative—not a formal spec.

• Request:
  • GET /model/inference?prompt=...
• Response:
  • 402 Payment Required
  • JSON body:
    • quote_id: “abc123”
    • price: “1000 msats” or “0.0002 USDC”
    • expires_in: 30s
    • payment_methods:
      • lightning_bolt11
      • lnurl_pay
      • erc681: “ethereum:pay?address=0x…&amount=…”
    • capability_schema: “macaroon”
• Agent pays; submits:
  • POST /model/inference
  • headers:
    • Payment-Proof: “bolt11_preimage:…”
    • Quote-Id: “abc123”
• Server verifies payment and returns:
  • 200 OK with result
  • Capability-Token: “macaroon-like token with TTL and scope”

Once a capability token is issued, subsequent calls can skip the full payment handshake until TTL expires.

For developers, Lightning’s L402 and LSAT combine much of this logic for paid APIs using HTTP 402, invoices, and macaroon tokens. Lightning Labs GitHub: L402

Designing Agent Wallets: Policy, Safety, and Recovery

If agents are going to spend autonomously, wallet design must prioritize constraints:

• Policy engines: Rate limits, allowlists of counterparties, budget caps, time windows, and human-in-the-loop approvals for high-risk actions.
• Session keys: Short-lived keys authorized by a root key to execute bounded tasks, revocable without touching the cold root.
• Paymasters: Sponsor gas for whitelisted operations so agents can spend in stablecoins while gas is handled behind the scenes. EIP‑4337: Account Abstraction
• Modular smart accounts: Adopt standards that keep wallets upgradeable and auditable. EIP‑6900: Modular Smart Accounts

Security First: Why Hardware Matters For Agents

Autonomous agents still rely on human owners for custody of root keys and for defining spending policies. Root keys should live in hardware, with software agents using session authorities derived from those keys.

OneKey hardware wallets are built for this model:

• Open-source firmware and transparent design.
• Support for major chains used by agents, including Bitcoin and EVM ecosystems.
• Secure element to protect seeds, with passphrase options for layered security.
• Smooth integration with the OneKey App for policy controls and transaction review.

In an agentic architecture, you might anchor the root seed in OneKey, issue time‑bound session keys for the agent, and require WebAuthn or hardware confirmation for policy changes or budget escalations. This approach keeps autonomous spending flexible while preserving human oversight.

Interoperability: The Multi‑Rail Reality

No single payment rail wins in the Agentic Web. Services should publish multiple options in their x402 challenge:

• Lightning methods (BOLT11, LNURL‑pay) for true micropayments.
• ERC‑681 for EVM-based payments across L2s.
• Stablecoins for predictable pricing and settlement in enterprise contexts.
• Streaming rails for time-based compute.
• Cross-chain messaging where necessary; use secure interoperability layers with conservative trust assumptions. Chainlink CCIP

Agents, in turn, should maintain pluggable wallets that can route payments intelligently based on context and cost.

Practical Tips For Builders

• Treat 402 as a signal, not a lock‑in. Publish a structured, machine-readable payment challenge with clear expiry semantics.
• Provide receipts and tokens. After payment, issue short‑lived capability tokens. Avoid permanent API keys bound to identity.
• Support multiple rails from day one. Lightning for micro; EVM for programmable policies; stablecoins for predictable treasury.
• Invest in policy and observability. Every agent spend should be auditable with rate limits and human override.
• Keep root keys offline. Use a hardware wallet such as OneKey for custody; delegate session keys to agents with constrained permissions.
• Prefer standards. ERC‑4337 paymasters, ERC‑681 URIs, and capability token patterns make your service interoperable. EIP‑4337: Account Abstraction EIP‑681: Payment Requests

Conclusion

As AI agents increasingly transact online, the web needs a payment handshake that is simple, interoperable, and machine‑native. x402—an extended, pragmatic pattern around HTTP 402—paired with Lightning, ERC‑4337 paymasters, ERC‑681, stablecoins, and streaming payments offers a clear path forward. It keeps identities decoupled from billing, gives services verifiable receipts, and empowers agents to pay as they go.

If you’re building agentic systems, start with solid key management. Anchor root keys in hardware and derive constrained session authorities for your agents. OneKey provides open‑source, secure hardware wallets that fit this model, helping you enforce budgets, approvals, and recovery without slowing your agents down. In the Agentic Web, safe autonomy is the real unlock—and it begins with how agents pay.