Blog Posts

x402 is doing something very useful and at the same time simple : resurrecting HTTP 402 Payment Required as a standard way for machines to ask for payment and then retry the same HTTP request with proof of payment. The result is an internet-native payment handshake that works for APIs, AI agents, and micro-services—without accounts, API keys, or subscription checkout flows.

At Nevermined, we love that simplicity… and then immediately run into the next question:

Cool—now how do we do subscriptions, usage-based plans, escrow, revenue splits, dynamic cost, and policy-controlled agent wallets… without breaking x402?

This post walks through:

The x402 architecture and its core primitives
What Smart Accounts and Smart Contracts bring to the table
Why we extend x402 (as a v2 extension) with a programmable settlement layer
How the pieces fit together end-to-end
Use cases you can ship

x402 architecture overview

x402 standardizes roles and messages around three main actors:

Client: human app or AI agent that wants a resource
Resource server: the API, service or AI Agent you’re calling (the seller)
Facilitator server: third-party that verifies and settles the on-chain payment so the resource server doesn’t need on-chain infrastructure or pay the transactions gas.

The key idea is: the payment is carried in-band with HTTP, not out-of-band in a separate checkout session.

The Coinbase x402 reference implementation describes this sequence:

Client calls an endpoint normally
Server responds 402 Payment Required + a JSON body describing acceptable payment requirements
Client picks one option, builds a payment payload, and retries the same request with an PAYMENT-SIGNATURE header
Server verifies (via facilitator POST /verify)
Server fulfills the request
Server settles payment (via facilitator POST /settle)
Server returns 200 and may include an PAYMENT-RESPONSE header with settlement details

x402 settlement: why EIP-3009 is both great and limiting

Most current x402 flows use EIP-3009 (ERC-3009) “Transfer With Authorization”: the client signs an EIP-712 typed authorization that allows a transfer to be executed onchain without the sender paying gas (a relayer/facilitator pays gas, the token contract enforces the signature).

This is a fantastic fit for x402’s goals:

client doesn’t need native gas
server doesn’t need any blockchain infrastructure (facilitator settles)
signed intent + nonce + validity windows give good replay protection

But it’s also a hard constraint:

It’s “just a transfer.” You can pay an address, but you can’t express “pay, then execute business logic, then mint access, then split revenue” atomically.
The architecture relies on Facilitators, but there are no clear economic incentives to run them. Facilitators need to pay for clients gas but the protocol doesn't include a simple mechanism to make them economically viable.
It’s token-standard dependent. Facilitator compatibility is anchored on EIP-3009-capable tokens on supported networks.
It’s not inherently stateful. Subscriptions, metering, refunds, conditional release—those need contracts.

This is exactly the gap the Nevermined post calls out: x402 is strong at interoperable stablecoin transfer, while Nevermined is built around a smart-contract settlement layer for flexible flows like subscriptions, credit/usage billing, milestones, and time-based access.

Smart Accounts and Smart Contracts (quick definitions)

Smart Contracts (here: “programmable settlement”)

A Smart Contract is just an on-chain program with persistent state and deterministic execution. In payments, the useful properties are:

atomicity: either everything happens or nothing happens
enforceable rules: escrow, time locks, milestones, splits
composability: contracts can call other contracts; external integrations can build on the same primitives

x402 itself is intentionally not a business-model protocol—it’s a payment handshake. Smart contracts are the missing “business logic layer.”

Smart Accounts (Account Abstraction wallets)

A Smart Account is a smart contract wallet (a Smart Contract Account, SCA) with programmable authorization logic: multisig, social recovery, session keys, spending limits, paymasters for gas sponsorship, batching, etc. A common standard is ERC-4337, which introduces UserOperations processed via an EntryPoint contract and bundlers (alt mempool), enabling account abstraction without L1 protocol changes.

Smart Accounts matter for agentic payments because they let you say:

“My agent can spend up to $5/day on tools, only to whitelisted contracts.”

…and enforce that cryptographically.

Why Smart Accounts > traditional wallets (especially for agents)

External Owned Accounts (EOAs aka wallets) are fine for humans clicking “confirm” in a browser, but brittle for autonomous systems. Smart Accounts offer:

Policy-controlled automation: session keys, allowlists, rate limits, per-merchant caps (ideal for agents).
Key management upgrades: multisig, recovery, rotation.
Gas abstraction: a paymaster can sponsor gas; the agent can hold only stablecoins.
Batching: approve + pay + call in one operation (less failure surface).
Composable auth: integrate enterprise IAM-like controls on-chain.

ERC-4337’s architecture is explicitly designed to unlock these wallet features via programmable validation logic.

Why Smart Contracts augment “plain” x402 (EIP-3009 settlement)

The current x402 using EIP-3009-only settlement tops out at “pay-to-access” is already valuable, but it’s not enough for real commerce.

With Smart Contracts, you can upgrade the core invariant from:

“Pay to access a resource”

“Pay to complete a business action, under enforceable rules”

That same idea is the heart of the Nevermined integration: x402 stays as the HTTP-level handshake, while settlement becomes programmable and stateful.

Concrete benefits of contract-based settlement over EIP-3009-only:

Atomic “pay + execute”: no race conditions between payment and fulfillment logic.
Stateful billing: subscriptions, metering, credits, time windows.
Escrow: lock funds, release on conditions (milestone delivery, SLA, dispute windows).
Revenue splits: platform fees, referrers, multi-party payouts.
Programmable use cases: flexible and new scenarios can be implemented on top of Smart Contracts used by clients and servers to transact
Programmable receipts: onchain proofs (e.g., minted access credits) that can be reused for subsequent calls.

The Nevermined settlement layer we plug into

Nevermined’s Open Souce Smart Contracts already model “payment as an agreement with conditions,” including escrow and distribution patterns. The protocol is organized around components like:

AssetsRegistry: registers agents/plans (supports multiple pricing models)
AgreementsStore: tracks agreements and condition states
PaymentsVault: escrow of funds, balances per token
Templates: pre-defined scenarios implementing fiat & crypto payments, pay as you go, etc.
Conditions: e.g., lock payment, distribute payments, transfer credits
NFT1155Credits: tokenized access rights (expirable, fixed, dynamic)

So instead of inventing a new settlement system for x402, we wire x402 into what already exists—then expose it over HTTP in a way agents can consume safely.

The extension: x402 + Smart Accounts + Smart-Contract settlement

x402 v2 extensions aim to bring more functionality on top of the core protocol without breaking compatibility. Having that in mind, in Nevermined we created a x402 extension that enable Smart Accounts and Smart Contracts settlement.

Design goals of the extension:

Backward compatible: v1-style “exact transfer” still works.
Explicitly opt-in: new behavior is triggered only when the server advertises the usage of the extension.
Smart-account friendly: clients can use Smart Accounts to create permissions that can be transferred and delegated.
Programmable settlement: the extension allow the execution of Smart Contracts during the settlement

You can check the complete flow in the extension documentation, but at the high-level everything works as follows:

A client (or an AI Agent) controlling a Smart Account decides to query a Resource Server (another AI Agent)
The client sends a query to the seller AI Agent and this returns a HTTP 402 Payment Required response, and a list of the payment conditions required to quering the agent
The client using the Smart Account reads the payment requirements and create a x402 Payment Payload including the delegation permissions that allow to purchase and query the agent by a third-party on the clients behalf.
The client makes a request to the server AI Agent including the x402 payment payload using x402 regular protocol. In agent-to-agent scenarios, the client could delegate the delegated permissions to a client AI Agent, which will use them to integrate with the server AI Agent.
The server AI Agent receives the request and send the payment payload to a Facilitator to verify if everything is in order (am I going to get paid?)
The facilitator run an on-chain verification and return the result status to the server AI Agent
If the verification was correct the server AI Agent fulfill the task, whatever it is. After finish send the same payment payload to the facilitator to settle t2he transaction.
The facilitator execute the on-chain settlement (depending on the use case: payments, redemption of credits, etc.)
The client gets the result

Use cases you unlock

Bundles - You pay once and you get a bunch of credits that you can use until you consume all of them or until they expire. Once that happens you just need to top-up and continue.
Subscriptions - Subscribe to the plan of an AI Agent and make automatic recurrent payments (i.e: once a month), to get access to that agent.
Dynamic cost - Because the variable cost of a task (complexity) some scenarios could require charging the user depending on the resources required to execute that task (i.e LLM tokens). With the extension is possible to create delegation permissions to use a range of credits when querying an AI Agent.
Revenue split and fees - They can be baked in the payments distribution and funds dispersed automatically when that payment goes trough. Incentive facllicators, marketplaces, etc.
Safety rails via policies - Restrict what contracts can be called, spend caps, number of requests, etc. This can be computed in the delegated permissions which will be enforced by the protocol.

Wrapping up

x402 gives us the missing HTTP-native “payment handshake” for agents and APIs: fast, simple, composable. But production commerce needs more than transfers—it needs programmable settlement and safer agent wallets.

By extending x402 with:

Smart Accounts for policy-controlled authorization and automation
Smart-Contract settlement for atomic “pay + execute” business logic
and Nevermined’s existing pre-configured use cases

…we get a payment layer that’s still x402 at the edge (HTTP), but far more powerful in the core (settlement).

References

Nevermined + x402: Bridging the Next Generation of Agent-to-Agent Payments

Nevermined x402 extension - Technical specification

‍

Making x402 programmable: extending the HTTP-payments flow with Smart Accounts & Contracts