Substrate, Not Standards
Why payment infrastructure for agent commerce is a substrate problem, and how MultiversX answers it
An AI agent in a continuous decision loop reads state and signs transactions. Most of what it signs moves value. A trading agent settles a position. A research agent pays for a query. An orchestrator pays subordinate agents for completed work. Every meaningful action eventually resolves into a transfer.
That cadence belongs to the software running the loop. For most of the history of payment infrastructure, the rails were built around human tempo. The agent stack does not run on it.
Here we explain why the agent stack needs different rails, why the industry has just spent a year racing to define them, and why the substrate underneath those rails decides whether they carry the workload.
The standards race is the signal
Within the past year, every major company with a stake in software-driven commerce has shipped a payment standard for autonomous systems. Coinbase shipped x402, an HTTP-native protocol reviving the long-dormant 402 status code for machine-to-machine settlement. Stripe and Tempo published the Machine Payments Protocol, or MPP, which is on the IETF standards track and extends x402. Within days, more than a hundred services adopted it, including Anthropic, OpenAI, Shopify, Visa, and Cloudflare. Google introduced AP2 for signed agent authorization mandates. OpenAI's ACP defines an attribution layer for agent-initiated commerce.
Different protocols, different layers, same conclusion. Existing payment infrastructure was built for humans transacting at human cadence and does not extend to software transacting at software cadence. The convergence is the market making that conclusion explicit.
What these standards share is a set of assumptions about the rail underneath. Settlement that responds in the same time domain as the calling software. Programmability sufficient for one process to pay another, without prior account provisioning, without a checkout flow, and without a human in the loop.
What standards do not decide
A standard is an interface. It defines how software requests payment and how it proves payment. It does not, by itself, move value. The movement happens on whatever rail the standard sits on top of, and the rail decides whether the interface works in production.
A protocol like MPP can advertise multiple rails in parallel: a card processor, a stablecoin transfer, a Lightning channel, a chain-native token. The standard is rail-agnostic by design. An agent making thousands of micropayments per minute against an inference API cannot afford rails where each transaction takes seconds to finalize, costs more in fees than the payment is worth, or requires accounts established at every counterparty in advance.
The substrate decides whether the standard works. It is also where most existing rails fail.
Why most existing rails do not carry the workload
Card and ACH rails were built around batch settlement on human cadence. They clear in days, require pre-established account relationships, and apply fee structures designed for human-sized amounts. Per-call payments at fractions of a cent are outside the workload they were built for.
Channel-based protocols like Lightning solve the micropayment problem inside a single channel. Two parties pre-fund a shared escrow and exchange off-chain signed updates as long as the channel stays open. The model is efficient where it applies, and bound by topology. An agent transacting many-to-many at scale has to either route through intermediary channels with sufficient liquidity, or open and fund a new channel per counterparty. Channel topology is the wrong shape for the traffic patterns the agent workload produces.
Programmable blockchains move past both constraints in principle. The rail is open, the payment is programmable, and the standard sits cleanly on top. In practice, multi-second finality and gas costs at the cent level fail per-call payments at fractions of a cent. The gas costs more than the payment is worth, the finality window outlasts the agent's decision cycle, and an agent without the chain's native token cannot transact at all. The rail is the right shape; the substrate underneath is not.
MultiversX clears these constraints because the substrate was built to. Sub-second finality means a payment confirms inside the agent's decision cycle. Adaptive state sharding means capacity scales with the number of agents transacting concurrently. Native gas abstraction at the protocol level means an agent without the native token still transacts, with no trusted intermediary holding its funds. None of these properties is novel in isolation. The combination makes per-call payments at fractions of a cent operationally viable.
Three transaction patterns, three architectural answers
Three transaction patterns show up in real agent traffic, each placing a different demand on the rail underneath.
- Discrete one-time payments. An agent pays a single counterparty once for a single resource. The rail needs to confirm the payment inside the agent's decision cycle and produce verifiable proof the counterparty can act on. On MultiversX this is a standard EGLD or ESDT transfer with the payment challenge tagged in the data field. The facilitator verifies receiver, amount, token, and tag against the original challenge. No smart contract interaction, minimum overhead. The pattern works because finality lands inside the cycle. On a chain with multi-second finality, the same flow is technically valid and operationally useless.
- High-frequency streaming payments. An agent pays the same counterparty repeatedly over a session, often thousands of times. Touching the chain on every payment is wasteful regardless of how fast finality is. The rail needs a way to authorize incremental transfers off-chain while keeping settlement guarantees onchain. On MultiversX this is a state channel session. The agent locks tokens in an onchain escrow contract, then streams off-chain vouchers authorizing incremental payments. The receiver holds the most recent voucher and settles onchain when the session ends. The chain is touched twice per session whether ten payments happened or ten thousand. State channels become useful at scale when the open and settle operations themselves run at the same speed as the payments they bracket.
- Payments by agents holding no native token. An agent transacting on a chain whose native token it does not hold cannot pay gas, and so cannot transact at all. The standard workarounds are to pre-fund the agent or route it through a custodial wrapper. Both reintroduce a trusted intermediary, the property the rest of the rail was meant to avoid. The rail needs gas abstraction native to the protocol. On MultiversX this is Relayed v3, a protocol-level transaction type where the facilitator wraps and broadcasts the transaction and pays the gas. The agent signs the inner payload, the facilitator submits and pays for it, and the payment clears under the agent's authority. The facilitator never holds the agent's funds.
All three modes are exposed through the MultiversX MCP server as structured tools. Agents running on Claude, Cursor, or any MCP-compatible client discover them the same way they discover any other onchain capability.
These three shapes are the transaction patterns the agent workload actually produces. A rail that serves only some of them is incomplete for the workload.
What this enables
The use cases are not hypothetical. They follow directly from what the rails make possible.
Agent-to-agent commerce. An orchestrator delegates work to a subordinate agent and pays per completed task. A research agent pays an analytics provider per query, settling each transaction in milliseconds instead of paying for a subscription that may not match its usage. A purchasing agent pays a delivery agent on confirmation of receipt. Each is one autonomous system transacting with another at the speed both operate, with no human in the approval loop. This is what A2A means in practice: software economies running in real time on programmable rails.
Programmatic autonomous markets. Agents bidding in a programmatic ad auction, settling per impression. Agents trading in continuous liquidity markets, opening and closing positions inside their own decision cycle. Agents responding to oracle updates inside the same window the update lands. The substrate has to clear faster than the market moves, or the market structure breaks. Sub-second finality plus gasless agent payments plus deterministic ordering at agent timescales is what makes such markets feasible.
The same primitives extend further. When value transfer is fast enough and programmable enough that software can route it autonomously, the design space opens for instruments with continuous, programmable settlement. The rail that carries agent payments is the rail for a much broader category of programmable value movement.
What we are building
The agentic stack on MultiversX is being built end to end. The MCP server exposes the network's onchain capabilities to any MCP-compatible client, including AI agents on Claude and Cursor. The MPP standard from Stripe and Tempo runs on top, alongside continued x402 support. The SDK, facilitator service, session contract, specification, and x402 adapter are all open source.
The pieces compose into a single coherent surface for agent commerce: standards-compliant at the interface, primitive-matched at the protocol layer, and running on a network engineered to handle the throughput agentic commerce produces, at the speed agents transact. The substrate decides whether the rest of the stack works in production. MultiversX is engineered so it does.
The fundamentals
Choosing a payment rail for agent commerce is a decision about whether the substrate matches the workload. Standards define how the rail is called. The rail decides whether it answers in time, at scale, and without preconditions the workload cannot satisfy.
Settlement that lands inside the agent's decision cycle. Capacity that grows with the number of agents transacting concurrently. Primitives that work for the patterns the workload actually produces.
This is what Supernova is built for.
