Architecture for agents
Supernova and the case for sub-second finality on MultiversX
An AI agent operates on the order of hundreds of milliseconds. It reads a price, evaluates a position, signs a transaction, and moves to the next decision. Multiply that by every agent in a market reacting to the same conditions, and you have a system whose effective tempo is set by the slowest component in the loop.
For most of the history of public blockchains, that slowest component has been the chain itself.
Supernova, our next major protocol upgrade, changes that. Block time drops from six seconds to 600 milliseconds. Intra-shard finality lands in the 100 to 250 millisecond range. The settlement layer now operates on the same timescale as the systems it is meant to host.
He we explain why that specific architectural choice matters, why agents need it, and why our approach is structurally different from other paths to sub-second finality.
How agents transact
Human blockchain users initiate transactions one at a time and tolerate confirmation windows of seconds. A few seconds of latency between clicking "swap" and seeing the result is fine for a person. Software running a continuous decision loop cannot tolerate that.
Agents do not behave like people. They operate continuously, in parallel, and react to each other's actions. Three properties of agent transaction patterns matter for the chain underneath them.
- They run at machine speed. A trading agent's full loop, observe-decide-act, finishes well under a second. If settlement takes longer than the decision cycle, the agent is making the next decision before knowing whether the last one succeeded.
- They run in parallel. A market with many agents has many decision loops running concurrently. Throughput requirements scale with the number of agents, not the number of human users.
- They depend on deterministic ordering. When multiple agents react to the same onchain event, the order in which their transactions land determines the economic outcome. An ordering process that cannot keep pace with the rate of arriving transactions becomes a queue, and a queue at that speed is a target for manipulation.
A blockchain designed around human cadence will work for agents the way dial-up worked for streaming video: technically possible, structurally inadequate.
Why execution was the bottleneck
Pre-Supernova, MultiversX consensus required block proposers to execute every transaction in a block before proposing it. Validators then re-executed before voting. Heavy transactions could consume up to 4.5 seconds of a six-second round. The clock that measured "time to finality" was, in practice, measuring computation time.
This is not a MultiversX-specific problem. Most synchronous-execution blockchains share the same critical path: execution must complete before consensus can finalize. The faster such a chain wants to be, the less time the network has to actually process transactions, which forces a tradeoff between speed and the complexity of work the chain can do per block.
The way out of that tradeoff is to stop treating execution as a prerequisite for consensus.
What Supernova brings
Supernova decouples the two processes.
A proposer selects transactions and immediately sends the block for voting. Validators verify the proposal against the network's rules and vote. Once more than two-thirds of votes are aggregated into a consensus proof, the block is final. Execution then runs asynchronously, and its results are notarized in a subsequent block header, typically the very next one.
The finality clock now measures only network propagation and vote aggregation. Execution still happens, with the same correctness guarantees, but it no longer sits on the critical path.
Two consequences follow directly.
Block production runs at network speed, not computation speed. The 600 millisecond block time is a function of how fast validators can communicate, not how long the heaviest transaction takes to execute.
Ordering is locked at proposal time. A proposer commits to a sequence of transactions before knowing what those transactions will produce, which means ordering cannot be manipulated based on execution outcomes that have not happened yet.
Prior upgrades laid the groundwork. Andromeda removed confirmation blocks, expanded the consensus group in execution shards from 63 to 400 validators, and compressed cross-shard coordination from six steps to three. Barnard introduced millisecond-precision timestamps and protocol-level governance. Supernova performs the decoupling.
Why fast validators cannot outrun slow ones
Decoupling consensus from execution raises an obvious question. If blocks finalize before they are executed, what stops the network from proposing blocks faster than a minimum-spec validator can keep up with?
MIP-27 specifies the Execution-Result Inclusion Estimator, or EIE. Before proposing a block, the EIE calculates how long pending execution results will take, using gas used, a fixed time-per-gas constant, and a fixed safety margin. It only includes results that a minimum-spec validator can finish executing before the next block requires their participation.
If execution falls behind anyway, dynamic block gas limits down-adjust until execution catches up. The network self-throttles.
This is a deliberate choice on our part, with a specific consequence: faster validators do not advance the network past what slower validators can sustain. The hardware floor remains accessible. That choice is the key to the rest of the argument.
Why this architecture suits agents specifically
Several paths exist to sub-second finality. Each comes with different tradeoffs. Comparing them clarifies what we are doing.
Monolithic high-performance chains achieve speed by raising hardware requirements. Solana's roadmap toward 100-150 millisecond finality with Alpenglow and Firedancer assumes validators with substantial RAM and bandwidth. The performance is real. The tradeoff is concentration: only operators who can afford the spec run validators, which narrows the validator set over time.
Object-centric and parallel-execution chains like Sui and Aptos achieve high throughput by parallelizing execution across CPU cores. This works well for transactions that operate on isolated state, less well for transactions that contend over shared state. The model is suited to specific workloads.
Rollup-centric architectures like Ethereum's keep the base layer slow on purpose, pushing speed into application-layer rollups. This preserves base-layer decentralization but introduces fragmented execution environments and cross-rollup bridging assumptions for anything that wants to interact across them.
Our combination is different. Adaptive state sharding provides horizontal scale: more shards mean more capacity, without raising the work each validator does. Decoupled consensus provides sub-second finality. The EIE keeps the hardware floor accessible. None of these elements is novel in isolation. The combination is the architectural argument we are making.
For agents, the combination matters because agent-native infrastructure has to satisfy three things at once:
- Settlement faster than the agent's decision loop. Otherwise the chain is the bottleneck.
- Capacity that scales with the number of agents, not just the speed of one. Otherwise contention dominates.
- Decentralization credible enough that agents can rely on it as neutral infrastructure. A chain run by a small set of operators is, from an agent's perspective, indistinguishable from a centralized service with extra steps.
A monolithic chain solves the first by trading off the third. A rollup architecture solves the third by deferring the first. Sharding combined with decoupled consensus and a preserved hardware floor gets all three at once. That is why we believe MultiversX is the substrate agent workloads will converge on.
Where security comes in
Once settlement runs inside the agent's decision cycle, several attack surfaces shrink as a downstream effect.
The window in which an adversary can observe a pending transaction and submit a higher-priority one ahead of it is bounded by finality time. At 100 to 250 millisecond intra-shard finality, that window is small enough to change the economics of front-running. The class of strategies that pay off at multi-second exposure and stop paying off at 200 milliseconds is a real class.
Oracle staleness shrinks proportionally. A price oracle is only as fresh as the most recently finalized block. A roughly 24x reduction in finality time is a roughly 24x improvement in worst-case freshness.
The Propose/Vote-then-Execute model also closes one specific manipulation surface. A proposer cannot reorder transactions based on execution outcomes because execution has not happened yet.
These properties follow from the architecture. They are not what motivated it. An architecture aligned to agent timescales produces security characteristics that an architecture aligned to human timescales cannot.
What ships
Supernova is heading to mainnet. Battle of Nodes recently concluded, with the network processing over one billion transactions during the event. Mainnet activation remains pending standard go/no-go gates including security audit remediation.
When it ships, block time drops from six seconds to 600 milliseconds, intra-shard finality lands in the 100 to 250 millisecond range, and cross-shard transactions, which involve metachain notarization, finalize within two seconds. The economic model is unchanged. Validator hardware requirements are unchanged. The over 3,200 validator nodes currently securing the network continue to do so.
The fundamentals
A decision about which chain to build agent infrastructure on is a decision about whether the substrate matches the workload. Agents need settlement that runs at their pace, capacity that scales with their numbers, and a decentralization story credible enough to stake their operations on.
Sub-second finality without raising the hardware floor. Horizontal scale without fragmenting execution. Deterministic ordering at agent timescales. That is the case we are making for MultiversX as substrate for autonomous systems.
