Every major blockchain was designed for human users. AI agents transact at machine speed and need cryptographic proof of execution. That's a categorically different infrastructure problem.
Every major blockchain was designed for human users. AI agents transact at machine speed and need cryptographic proof of execution. That's a categorically different infrastructure problem.
Every blockchain launched in the last decade made the same implicit assumption: the entity on the other end of the transaction is a human. That assumption needs to change. And protocols that don't update their design philosophy accordingly will find themselves optimized for a shrinking user base.
In early 2026, Stripe co-founders Patrick and John Collison included a quiet observation in their annual letter: AI agents will likely be responsible for most internet transactions, and the infrastructure will need to support more than one billion transactions per second to keep up. That figure is aspirational (a horizon, not a current demand). But the direction is clear, and the gap between where blockchain infrastructure sits today and where it needs to be is not a gap that incremental upgrades can close.
The user base is shifting under the feet of protocols still designed for the other 35%.
The human-centric design inheritance
To understand why this matters, you have to look at the design decisions that went into every major blockchain built before 2025. Those decisions were sensible. They were also built around a specific user: a person sitting in front of a screen, making deliberate choices, willing to wait a few seconds for a confirmation.
Ethereum's 12-second block time wasn't an accident. It was a considered trade-off between decentralization, security, and user experience. Twelve seconds is fast enough for a human submitting a swap on Uniswap. It's an eternity for a trading agent running arbitrage across multiple venues. By the time a transaction confirms on Ethereum, the opportunity the agent was executing on has closed, repriced, or been taken by a faster competitor on a different chain.
Full finality on Ethereum takes 12 to 15 minutes. Solana's pre-Alpenglow architecture settled to finality in roughly 12 seconds. Even Solana's Alpenglow upgrade, which targets 150-millisecond finality, is primarily designed around the needs of high-frequency trading systems (systems that are, increasingly, autonomous).
The fee structure problem is subtler but just as significant. Gas pricing on most L1s is dynamic: demand-driven, unpredictable, and prone to spikes during periods of network congestion.
A human trader can absorb a 3x gas spike as an acceptable cost of doing business. A trading agent running thousands of transactions per hour cannot. Gas cost is a direct input to its decision-making logic, and an unexpected spike mid-execution can invalidate the entire strategy the agent was running. Agents need fees that are calculable before execution, not discovered after.
Wallet onboarding is another inherited assumption. Getting an address on Ethereum requires a key generation step, but the surrounding infrastructure assumes a human: browser extensions, seed phrase backups, UI-based signing flows.
These aren't obstacles an agent can navigate. An agent needs a pure API-first account creation path: generate a key, register an address, fund it, and start transacting in a single programmatic sequence with no human intervention at any step.
RPC access compounds all of this. Most blockchain RPC endpoints were designed to serve individual users making occasional requests. The rate limits, response formats, and state completeness of standard RPC APIs are mismatched with agents that need high-frequency access, machine-parseable state, and consistent behavior under load.
An agent making 10,000 requests per hour to a standard public RPC endpoint will hit rate limits long before it exhausts its capital.
What agents actually need from a blockchain
The requirements list for an agent-native blockchain looks different from the list for a human-native one. The differences aren't superficial.
Finality speed needs to fit inside an agent's reasoning loop. An agent that submits a transaction and then needs to wait for confirmation before taking its next action is constrained by finality time at every step. If finality takes 12 seconds, the agent can execute roughly five reasoning cycles per minute. If finality takes 150 milliseconds, it can execute hundreds. The compounding effect over a trading session is enormous. Sub-200ms finality is the floor for agents operating in competitive, time-sensitive markets.
Fee predictability matters as much as fee size. Agents budget execution cost before they act. A model that can predict its fees with certainty can make better decisions than one operating under uncertainty, even if the uncertain fees are on average lower. This is a different optimization target than what most fee markets are built for.
Programmatic account management needs to be a first-class feature: the ability to create wallets, fund them, set spending permissions, and revoke access entirely through API calls. Agents in multi-agent systems often need to create sub-wallets for delegated tasks, fund them with specific amounts, and tear them down when the task completes. This should be trivial.
API documentation and consistency deserve more attention than they typically get. An agent's behavior is only as reliable as the APIs it depends on. Undocumented rate limits, inconsistent response formats across RPC providers, and API behavior that changes under load are manageable annoyances for a human developer. For a deployed agent, they're production failures. Agent-grade infrastructure needs APIs that are stable, versioned, and tested at the throughput agents actually generate.
The requirement that most distinguishes agents from humans, though, is the last one: cryptographic proof of execution.
The trust problem that only agents have
When a human submits a transaction and sees it confirmed, they've done something an agent cannot. They've looked at a screen, read a number, and made a judgment call about whether the outcome matches what they intended. That judgment happens outside the system. It's a human cognitive act.
An agent doesn't have that option. It receives data back from the blockchain and must decide whether to trust it. In a single-agent context, this is manageable: the agent checks the transaction receipt, verifies the state change, and proceeds. But in multi-agent systems, where one agent delegates tasks to another or coordinates across different protocols and chains, the trust problem becomes structurally hard.
When Agent A delegates a financial task to Agent B, how does Agent A know that B actually executed what it claimed to execute? Agent B could return a fabricated confirmation. It could have executed a subtly different operation. In a system where agents are managing real capital, the difference between "Agent B said it executed correctly" and "Agent B can prove it executed correctly" is not an edge case. It's the core security assumption of the entire system.
This is where verifiable compute shifts from a technical feature to a financial primitive. A zkVM proof is an agent-native receipt: a cryptographic attestation that a specific computation ran correctly, produced a specific output, and did so with specific inputs. Agent A doesn't need to trust Agent B. It can verify B's proof directly, in milliseconds, without re-executing the computation itself.
The trust asymmetry between humans and agents points at a structural gap in current blockchain infrastructure.
Most chains can tell an agent what happened. Very few can prove it in a form an agent can programmatically verify. That distinction doesn't matter for human users, who have other ways of establishing trust. For agents operating at scale, in adversarial environments, with no human in the loop, it's the difference between a system that is safe to delegate to and one that isn't.
Infrastructure designed from the agent-first premise
The design requirements above aren't things you can bolt onto an existing general-purpose L1. They need to be architectural decisions, made early, that shape everything downstream.
Nexus's dual execution architecture reflects this. NexusCore, the high-performance substrate that houses the Nexus Exchange and other enshrined coprocessors, targets sub-200ms block confirmation. Core blocks execute at high frequency; EVM blocks execute on a fixed cadence synchronized to them. This is a separate execution layer, purpose-built for applications where latency is the binding constraint.
USDX, the native stablecoin built on Nexus, is designed with programmatic settlement in mind. Agents that need to denominate positions, settle trades, or stream payments to other agents need a stablecoin that is native to the chain, composable with the Exchange, and accessible without the friction of cross-chain bridging. USDX is used as margin on the Nexus Exchange, which means an agent running a perpetuals strategy can manage margin, execute trades, and settle positions entirely within a single execution environment without touching external bridges or wrapped assets.
The timing of these design decisions matters. Agentic finance is early: 500,000 AI wallets and 15 million agent transactions are a rounding error against the scale the Stripe founders are pointing at.
But infrastructure that works for agents at 500,000 wallets is very different from infrastructure that works at 500 million.
