Executive Summary

• Credit card infrastructure is insufficient for autonomous commerce, which requires instant settlement and low transaction fees, prompting the adoption of alternative payment rails like stablecoins.

• Cloudflare announced the NET Dollar, a US Dollar-backed stablecoin, to extend its infrastructure vision to payments and support the agentic web, allowing for machine-speed transactions and new business models.

• Cloudflare’s NET Dollar expands Cloudflare beyond compute fees –capturing transaction economics, earning yield on reserves, and enabling granular pricing to amplify platform power and boost revenue.

• The introduction of NET Dollar, along with emerging protocols like x402, AP2, and 8004, enables a complete trust and payment infrastructure for autonomous machine-to-machine commerce, enhancing Cloudflare’s product suite and allowing for granular pricing and pay-per-use models.

• The Pay-Per-Crawl system allows publishers to set a price per request in NET Dollar, giving them control over their content and revenue.

• Cloudflare’s Agents SDK and NET Dollar integration enable autonomous spending and revenue generation for AI agents, creating a new market for specialized services and inter-agent commerce.

• Cloudflare is building the AI Cloud – compute, storage, inference, orchestration, and now payments—behind consistent developer primitives. NET Dollar + x402 makes value transfer native to the internet, and cheap high-throughput chains make micropayments viable at scale.

Introduction

Credit cards revolutionized commerce in the 20th century. The payment rails we use today – built atop that legacy – work well enough when humans are clicking checkout buttons. But the internet doesn’t move at human speed anymore. AI Agents are beginning to transact autonomously, executing millions of micro-decisions that each require instant settlement. Running this new economy over credit card infrastructure feels like streaming 4K video over dial-up.

The tailwinds of adoption of alternative payment rails have set in on stablecoins. Stripe spent $1.1 billion acquiring Bridge1 to control stablecoin infrastructure and is building Tempo, positioning for $1.4 trillion in payment volume. Google is working on their own permissioned blockchain and has enabled stablecoin payouts on Youtube, enabling PYUSD by PayPal which is now sitting at $3.7 billion in circulation (Source: Artemis Analytics2). These infrastructure giants realize that they can not just control the payment rails but the fundamental unit of money that moves over them.

This September, Cloudflare entered the race with a move that makes perfect strategic sense. The company routes 20% of all web traffic through 330+ global edge locations and has been positioning itself as the “AI Cloud”34 – infrastructure optimized for the agentic web. It generated $1.67 billion in revenue for fiscal 20245 by helping developers build and deploy applications at internet scale. Now with their launch of NET Dollar6 – a US Dollar-backed stablecoin designed for the agentic web and more – Cloudflare is extending that infrastructure vision to payments. This isn’t diversification into fintech. This is infrastructure eating payments.

Why It Matters

The Credit Card Problem for Autonomous Commerce

AI Agents don’t transact like humans. A travel agent might compare prices across dozens of airlines in milliseconds, executing a purchase the instant some requirements are made. An inventory agent might place hundreds of micro-orders throughout the day as stock depletes. A content agent might pay $0.001 for an API call, execute the request, and move on – all in under a second.

Credit card infrastructure cannot support this. The economics are absurd: a $0.50 transaction loses 63% to processing fees ($0.30 fixed + 2.9% variable). Even PayPal’s micropayment rate of $0.05 + 5% claims 15% of small transactions. Manual authorization flows add seconds of latency. Settlement takes days. Cross-border payments face currency conversion, wire transfer delays, and $25-45 fees that make microtransactions economically impossible. And you can’t feasibly give AI Agents a credit card7.

Traditional payments were designed for humans making deliberate purchases. The agentic web requires payment infrastructure that operates at machine speed, machine scale, and machine economics.

The Economics of Introducing a Stablecoin

Cloudflare’s move follows a pattern. Companies controlling infrastructure are realizing that issuing currency amplifies platform power.

Capture transaction economics, not just usage fees. Currently when developers use Cloudflare Workers to power paid APIs, Cloudflare only earns compute charges. Payment flows through another processor like Stripe who takes a cut of the payment. With NET integrated natively, Cloudflare earns on both the compute and the payment flow – approximately 0.5—1% of transaction volume plus infrastructure charges.

Generate yield on reserves. This is the less obvious but potentially more significant advantage. Stablecoin issuers earn yield on reserves backing their tokens. Under the GENIUS Act8, reserves must be held in T-bills or cash equivalents yielding 3-4%. A stablecoin with $1B circulation generates $40-50M annually in risk-free yield. This revenue can subsidize infrastructure pricing, allowing Cloudflare to compete on price in ways traditional cloud providers cannot. Workers, R2, and D1 could be priced at or below cost, with the difference made up by stablecoin yield. More generous free allocations can be funded by yield from paying customers. This accelerates developer adoption and NET circulation in a virtuous cycle. Yield revenue also provides capital to invest in platform features that might not have immediate ROI but increase developer stickiness.

Enable business models impossible on traditional rails. NET Dollar allows pricing at the granular level: $0.0001 per API call, $0.000001 per database row, $0.01 for an AI image. Credit cards make this economically absurd. Stablecoins make it trivial.

This creates a fundamentally different competitive dynamic. Cloudflare isn’t just competing on infrastructure quality or developer experience. They’re competing with a business model that lets them operate infrastructure at negative gross margins while still being profitable. Traditional cloud providers can’t match this without issuing their own stablecoins.

The Way Forward

Open Protocols - x402, AP2, & 8004

The agentic web requires more than a stablecoin – it needs a complete trust and payment infrastructure. Three protocols are emerging as the foundational standards, and Cloudflare is positioning itself at the intersection of all three.

x402: HTTP-Native Payments

The HTTP 402 “Payment Required” status code has sat dormant since the web’s inception – a placeholder for a payment layer that never materialized. Coinbase’s x402 protocol launched in May 2025, finally giving it meaning.

x402 transforms any HTTP endpoint into a paywall through a simple flow:

1. Client requests a resource without payment

2. Server responds with a ‘402 Payment Required’ and payment instructions(amount, token, recipient address, network)

3. Client signs a stablecoin transaction and resubmits with an ‘X-Payment’ header

4. A facilitator service verifies payment onchain

5. Server responds with ‘200 OK’ and the requested resource

No accounts, no API keys, no subscriptions – just cryptographic proof of payment embedded in HTTP headers. The developer flow is a few lines of extra code.

Cloudflare announced the creation of the x402 Foundation alongside Coinbase in September 2025 (with more details to follow later this month) signaling that x402 will be native to Cloudflare’s infrastructure. The protocol already has over 61 million transactions across the ecosystem this past month9, with adoption accelerating across AI companies, data providers, and content platforms.

AP2: Google’s Agent Payments Protocol

Google launched the Agentic Payments Protocol (AP2) in September 2025 with backing from over 60 partners including Mastercard, PayPal, Visa, and Cloudflare. Where x402 handles the payment mechanics, AP2 establishes the trust and audit trail10.

AP2 solves a critical problem: how do you verify that an AI agent is authorized to spend, what its budget constraints are, and whether the transaction should be trusted? The protocol provides a secure, auditable framework for agent-driven purchases – essential for enterprise adoption where compliance and accountability matter.

The integration is elegant: x402 handles the “how” of payment, AP2 handles the “who” and “why”. An agent using both protocols can autonomously discover services, verify its authorization, execute payment, and maintain a complete audit trail – all without human intervention.

8004: Trustless Agent Identity

While x402 and AP2 handle payments, 8004 handles trust. Proposed in August 2025 by developers from Metamask, the Ethereum Foundation, Google, and Coinbase, 8004 extends Google’s Agent-to-Agent (A2A) protocol with onchain identity, reputation, and validation registries.

The standard addresses a fundamental problem: how can agents from different organizations discover and trust each other without pre-existing relationships? 8004 provides three lightweight registries11:

1. Identity Registry: A minimal onchain handle that resolves to an agent’s offchain registration file, creating a global namespace for autonomous agents.

2. Reputation Registry: A standard interface for posting and fetching feedback signals. Scoring and aggregation occur both onchain and offchain, enabling an ecosystem of specialized services for agent scoring, auditor networks, and insurance pools.

3. Validation Registry: Generic hooks for recording independent verification of agent work—whether through economic guarantees, cryptographic proofs, or trusted third parties.

The protocol deliberately excludes payments, recognizing that x402 already handles that layer. An agent can use ERC-8004 to verify a counterparty’s reputation, then use x402 to pay for services – composable primitives for the agentic economy.

Together, these protocols form the complete stack for autonomous machine-to-machine commerce.

Enhanced Product Suite

The NET Dollar isn’t just a new product in Cloudflare’s portfolio – it’s the monetary layer than enhances Cloudflare’s entire product suite

Workers AI + NET Dollar

Cloudflare’s serverless inference platform in Workers AI already supports 50+ models at the edge. Right now, they have a pay-for-what-you-use pricing model using a unit called “neurons” – an abstraction that doesn’t represent a particular dollar amount and varies by model complexity. A single neuron might cost differently across model types, creating cognitive overhead for developers trying to estimate costs.

NET Dollar integration solves this by making pricing truly granular and dollar-denominated. Instead of calculating neuron costs, developers could microcharge fractions of a dollar per million input/output tokens directly. This simplifies the pricing model, removing unit-based abstraction and enforcing straightforward dollar-based pricing. A developer knows exactly what they’re spending: $0.0001 per inference, not “X neurons at Y rate”.

R2/D1/Stream + Pay-Per-Use + NET Dollar

An interesting vertical that NET Dollar enables is payment-gating usage of R2 buckets, D1 tables, and Streams. This works on both the platform side (Cloudflare billing developers) and the client side (developers billing their own users).

Consider D1: a developer could payment-gate database tables and release public datasets where users pay $0.001 per query depending on compute used or number of rows accessed. A financial data provider could monetize historical price data. A research institution could offer paid access to proprietary datasets. The database itself becomes a revenue-generating asset.

R2 gains similar capabilities. Content creators can gate access to storage buckets – $0.01 to view an image, $0.10 to download a dataset, $1.00 for premium content. The storage layer becomes a monetization layer without building separate billing infrastructure.

Cloudflare Stream can support true pay-per-view at any price point. A creator can charge $0.25 to watch a video, $0.05 for a preview, or implement dynamic pricing based on content age or demand. The payment happens seamlessly, embedded in the access request itself.

Pay-Per-Crawl

Cloudflare’s first production implementation of x402 micropayments is Pay-Per-Crawl12 which addresses one of the most contentious issues in AI: content compensation. The economics are stark. Google’s crawler scrapes 20 times per referral, OpenAI does 1500 per referral and Anthropic does 40000 per referral13. Publishers provide raw material for AI while receiving negligible traffic in return.

Pay-Per-Crawl (currently in Closed Beta) can flip this dynamic using NET Dollar as the settlement layer. Publishers set a price per request in NET Dollar. Crawlers either pay via x402 or receive a 402 response with pricing. When a crawler pays, NET Dollar settles instantly onchain – no invoicing, no reconciliation, no payment delays. Cloudflare can act as a Merchant of Record, but the underlying transaction is NET Dollar moving from crawler wallet to publisher wallet.

The system supports three modes: Allow (free access), Charge (paid at publisher’s rate), or Block (no access at any price). This gives publishers a third option beyond “block everything” or “allow and hope for referrals”. The potential is significant, A research agent with a $10 NET Dollar budget can programmatically negotiate access across hundreds of sources, paying fractions of a cent per article, assembling analysis from legitimately licensed content. Major publishers including Condé Nast, TIME, The Associated Press and Fortune have already signed on.

Cloudflare Agents - Supercharged

Staying true to their mission of building the “AI Cloud,” Cloudflare introduced the Agents SDK in February 2025. The SDK runs on Durable Objects—stateful micro-servers that scale to tens of millions of instances globally, maintaining state across requests unlike typical serverless functions.

Integrating NET Dollar with x402, AP2, and ERC-8004 could result in the most significant AI agent developer tooling since Anthropic launched MCP.

The vision: spin up a Cloudflare Agent via the dashboard or Wrangler CLI, and it automatically comes with a NET Dollar wallet for x402 payments, pre-configured with AP2 authorization and ERC-8004 identity. No manual registry configuration needed—the agent discovers other agents via ERC-8004’s identity registry, checks reputation scores, and selects which service providers to hire.

Autonomous Spending: Agents are provisioned with NET Dollar balances and spending rules. A personal assistant agent might have a $5 daily budget and full autonomy to spend it pursuing its owner’s goals—paying for API calls, data access, and other agents’ services without human intervention.

Revenue Generation: Agents can also earn. A research agent charges $0.50 per analysis via x402. The SDK handles payment natively—receive request, verify payment, execute, return result.

Inter-Agent Commerce: Agents hire other agents. A travel agent subcontracts to flight, hotel, and car rental specialists—each transaction settling in NET Dollar. Complex tasks decompose into markets of specialized services.

Cloudflare & the Future of the Internet

The through-line is legible – Cloudflare is building the complete stack for the AI-native internet. Compute, storage, inference, orchestration, and now payments – all unified under one platform, all operating at edge latency, all accessible via consistent developer primitives.

NET Dollar is infrastructure in the deepest sense. Just as TCP/IP enabled reliable data transmission and HTTPS enabled secure communication, x402, the 3 protocols and NET Dollar enable reliable value transmission. The internet finally gets its native payment layer, thirty years after HTTP reserved a status code for it.

The economics finally work. While x402 is chain-agnostic, high-throughput chains like Solana make micropayments viable – transactions cost fractions of a cent, and new infrastructure promises to enable 1 million+ Transactions/Sec. For a $0.001 database query or a $0.0001 API call, the settlement layer can no longer be the bottleneck.

The competitive moat this creates is formidable. A developer who builds on Cloudflare’s stack – Workers for compute, R2/D1 for storage and data, Workers AI for inference, Agents SDK for orchestration, NET Dollar stack for payments – has no reason to leave. Each layer reinforces the others. The switching costs compound.

Conclusion

For three decades, attention was the internet’s currency – harvested through advertising, monetized through surveillance. NET Dollar enables a different model: value exchanged directly at the moment of interaction. Content creators get paid when their work is consumed. API providers get paid when their services are used. Agents get paid when they deliver value.

CEO Matthew Prince: “The Internet’s next business model will be powered by pay-per-use, fractional payments, and microtransactions – tools that shift incentives toward original, creative content that actually adds value.”

Cloudflare isn’t just building payments infrastructure. They’re building the economic foundation for a post-advertising internet –one where the business model aligns with value created rather than attention captured.

Given their track record of reshaping infrastructure categories, it’s a bet worth taking seriously.

Thanks to Brennan Watt (Anza) and Mike McCoy (Sei Development Foundation), without whose help this article wouldn't be possible.

Note: For brevity and sticking to the topic, some concepts like chain forks, blockstore, TVU, and so on have not been covered in this article. This article also takes into consideration the architectures that are live on mainnets and not the improvements to be done in the future.

TLDR;

Block Building is a crucial part of a transaction’s lifecycle on blockchains. It determines which transactions are included in a block and in what order. On Solana, the process begins when users submit transactions to RPC nodes, which forward them to the current leader (block producer). Within the leader’s TPU, transactions are received from the RPCs using QUIC, verified, deduplicated, executed by SVM in parallel, timestamped using PoH, organized into shreds, and propagated to other validators for validation and eventual inclusion into a block.

Sei has a similar process: Users submit transactions to RPCs, which add them to the local mempool. An elected block producer picks transactions off its mempool, constructs a block, and sends a block proposal to the rest of the network that verifies the transactions and votes on whether its valid while each validator optimistically starts to execute the block, and if a consensus is reached, the block is committed to the network.

While both blockchains are constantly evolving towards the ultimate goal of increasing bandwidth and reducing latency, through innovative architecture designs, currently Solana takes the lead as is proven by its massive adoption and performance metrics.

Introduction

In terms of high-performance blockchain architecture, Solana continues to set the standard that newer chains like Monad, Aptos, Sui, and Sei are working overtime to match. This article explores the conceptual foundations behind Solana’s Block Production mechanism, contrasting it with Sei’s approach. We’ll examine the transaction flow from when it enters the Transaction Processing Unit (TPU), Banking Stage architecture, Proof of History (PoH) mechanism and in both the Agave and the upcoming Firedancer client and compare it with Sei’s Block Production mechanism, and how Solana remains positioned at the forefront of high-performance blockchain architecture, amid new competition.

Solana Block Production

Solana transactions undergo quite the journey from when a user submits them to being included in a block and finalized. When you click submit on a transaction through a webpage or wallet, the transaction is routed to one of many RPC Nodes. These nodes keep track of all the information on the network but don’t vote on blocks or participate in consensus. The RPC node then forwards the transaction to a validator node designated as the leader.

The Solana network uses a rotating leadership model that appoints a single validator in the network to be the block-producing validator for a fixed time period of 1.6 seconds (4 slots where each slot lasts 400 milliseconds). Validators with higher amounts of stake have a higher chance of being the leader. The leader schedule is determined in advance, so it is possible to know the upcoming leaders in the network.

When the transaction is transmitted to the leader, it enters what is known as its Transaction Processing Unit (TPU). The TPU is where all the transactions to be included in a block during a slot are received, deduplicated, processed, executed, and put in a block before it is sent to other validators to verify (check if all the transactions within it are valid) and come to a consensus on whether it is a valid block to be appended to the chain.

Each Validator client on Solana has its implementation of the Transaction Processing Unit (TPU). However, the basic flow is that once it enters the leader, it gets processed through the TPU, shredded, and sent across the network using Turbine — Solana’s block propagation mechanism. The journey to high throughput begins with the TPU, which consists of different stages, each having a specialized function to carry out in parallel whenever possible. Currently, Agave is the only functioning client (except JitoSolana, a fork of Agave focused on MEV — more on this later) on the Solana Network, with new clients like Firedancer and Sig on the way.

Each transaction on Solana is associated with a fixed base fee based on the number of transaction signatures and the number of CUs (Compute Units) it uses. Each transaction is allocated a maximum CU budget, and exceeding this leads to the transaction terminating. The current budget per transaction is 1.4 million CUs. In 2022, the network introduced priority fees, an optional fee to allow transactions to prioritize themselves against other transactions in the leader’s queue, resulting in faster execution times, and the price depends on the number of compute units in the transaction.

General Implementation

The Agave client in production by Anza — a fork of the original Solana Labs client, now deprecated — is the only active validator on the Solana network, except for the JitoSolana client, which is a fork of it.

When a leader receives a transaction from an RPC, it enters the TPU, where the transaction is received using QUIC, called the Fetch Stage, where transactions received are batched into groups of 128.

QUIC stands for Quick UDP Internet Connections and is a modern transport layer protocol for sending data through packets between devices on the same network. It allows quick delivery of data packets like UDP coupled with the integration of cryptographic key exchange and protocol details into an initial handshake similar to TCP.

The next stage is the SigVerify stage, which receives the packets from the fetch stages, verifies the transaction’s signature, checks for the correct number of signatures, handles de-duplication, and passes on to the next stage, called the Banking stage, which is arguably the most critical stage in the TPU. In this stage, the ‘block production’ truly happens and gets its name from the ‘bank, ‘ which is the chain’s state at a given block. This stage consists of the Scheduler and Execution Zone.

The primary job of the Scheduler is to package the transactions into batches of 64 non-conflicting transactions and schedule them for execution in parallel threads in the Execution Zone, where the transactions are executed by Solana’s Virtual Machine (SVM). The scheduler sorts the transactions by how much the validator wants to execute them based on the fees they will generate and the computing resources required. This aims to prioritize transactions that have a high fee but are cheap to run to maximize validator revenue. The transactions are scheduled to go into 6 threads (2 for vote transactions and 4 for normal transactions), processing transactions in parallel in such a way that conflicting transactions are executed sequentially while non-conflicting transactions are executed in parallel.

The accounts included in the transactions are then locked to make sure there aren’t any conflicts in the accounts involved in the transaction. Then, checks are run to ensure the transaction isn’t too old or has already been processed. After this, the accounts are loaded, transaction logic is executed, and the account state and data like balances, program code, or program state are updated in the Bank using a custom database system called AccountsDB.

These transactions are organized into entries, hashed, and sent to the Proof of History service for timestamping. The block’s bank is updated, and the entries are sent to the next stage, called the Broadcast stage. In this stage, the entries that form a block are packaged into shreds of a block, erasure coded, and then transmitted through a turbine tree generated in this stage to other validators in the network to replay, validate, and vote on whether or not this block should be included in the blockchain. The consensus uses the Proof of History timestamp to easily agree on the order of events, and if a consensus is reached, the block is committed to the chain.

With the introduction of SWQoS in early 2024, if a staked node is available to the RPC, the transaction can be sent to the staked node which has its TPU that processes transactions and sends it to the Leader’s TPU forward port through the Scheduler before it can reach the Execution part of the Banking stage and subsequent stages, and the Leader includes it in the blocks it makes. But sometimes, if the staked node has an upcoming Leader slot available, it may hold on to the block execute it, and include it in the blocks it makes. Each leader allows two types of connections through QUIC — 500 open connections for any RPC node and 2000 stake-weighted connections only for staked validators.

New Implementations & MEV

In 2022, Jump Crypto announced that they’re working on a new validator client built from the ground up in the C programming language and is currently in testing with its first block on the Solana testnet achieved in 2024. A hybrid version called Frankendancer, which combines Firedancer’s networking stack with the existing Agave client’s runtime, is already live on mainnet-beta.

The v0 Firedancer architecture in Frankendancer contains a re-architected TPU, with the rest of the validator client software to be introduced to mainnet-beta soon. The transaction flow is similar but is rewritten with key optimizations, with most of the improvements to the TPU being low-level optimizations like managing context switches, reducing memory copying between threads, efficiently allocating CPU cores to different operations, and avoiding system calls. Another very important optimization being made is the prevention of locking on transactions, eliminating the need for a complex scheduler. More on this in a later article.

Also in 2022, Jito open-sourced the Jito-Solana client — a fork of the Agave (then Solana Labs) client with modifications to enable MEV-boosted validator activity on Solana. It was ‘intentionally designed to earn MEV profits and optimize their distribution to network validators and stakers.’ The client is the centerpiece of a suite of products from Jito aimed at maximizing validator revenue and eliminating network spam, like the Jito Block Engine & relayer, Jito bundles, ShredStream, etc.

MEV (Maximal Extractable Value) refers to any value derived from adding, removing, or reordering the transactions within a given block. The most common types of MEV transactions on Solana are arbitrage involving price discrepancies across different DeFi platforms, liquidations on borrow/lend positions or during blue-chip NFT mints. Frontruns, backruns and sandwiching are not as common due to the absence of a mempool in the validator architecture but Jito’s MEV suite does provide the opportunity for such activity. The beneficiaries of MEV activities are called searchers.

Bundles are groups of atomically executed transactions that are used for MEV activity. If any transaction fails, the rest of the transactions will not be executed and the state will revert back so the state from the first transaction never gets committed, to minimize wastage of block space. Searchers can include extra out-of-protocol fees called tips along with their bundles as an incentive for validators to include their transactions at the top of the block.

When a JitoSolana client is the leader, transactions are forwarded to the ‘Jito Relayer,’ which functions as a proxy router for transactions submitted to the validator. This effectively replaces the Fetch & Sigverify stages by incorporating QUIC, signature verification, and deduplication. The relayer sends the transactions to the ‘Jito Block Engine’ or holds the transactions for 200ms and sends them to the leader’s Relayer Stage, which receives transactions for the next steps while the Block Engine does its thing. Jito runs a few relayers, but validators can choose to run their relayer or just use other relayers since it can run on the same or separate server as the validator.

Jito allows searchers and applications to submit bundles containing time-sensitive transactions for MEV activity like arbitrage and liquidations to the Block Engine. The 200ms delay allows searchers to simulate transactions sent to the relayer and construct transaction bundles accordingly. Blockspace is pre-allocated before the processing of each bundle to ensure its completion. During the delay, an off-chain block space auction is conducted as well, and searchers compete using tips to get their bundles included in the block in their ideal position. The Block Engine then forwards these transactions to the BlockEngine Stage which receives bundles and forwards it to the next stage. The bundles and transactions are then sent to the ‘Bundle Stage’ to be processed and included in a block like in the Agave client.

Will Sei have a say?

Sei is a high-performance EVM-based L1 blockchain built on the Cosmos SDK and Tendermint Consensus Protocol and is optimized for trading and DeFi applications. An immediate parallel to Solana’s early days can be seen as it, too, started as a trading-oriented blockchain aiming to build the decentralized NASDAQ at the speed of light. Sei aims to build the fastest parallelized EVM L1 and handle high-throughput, low-latency workloads. The transaction flow in Sei is different from Solana, as we’ll now see.

When a transaction is submitted and signed on the Sei network, they are routed to the nearest RPC node (runs full validator software unlike on Solana) which performs a series of lightweight validation checks like checking the validity of the signature, the fee sufficiency, transaction format compliance, deduplication, and estimating gas usage. If these checks are successful, the transactions are sent to the node’s local mempool (an in-memory pool of unconfirmed transactions awaiting inclusion in a block), which is prioritized based on the fee involved or time submitted. Then, this mempool is propagated across the network using a gossip protocol, such that all validators sees the same view of the mempool. From the active validator set, a validator is chosen as the block-proposer based on stake weight in a round-robin fashion.

The chosen proposer then gathers transactions from its mempool to include in the block. There is typically a block size limit (depending on the amount of gas — which is the amount of compute — that can be executed in each block), so the proposer will take as many high-priority transactions as fit during this stage which ensures the selected transaction don’t exceed block limits and add or drop transactions if needed. After this selection, the proposer assembles the block along with its metadata. Importantly, the proposer doesn’t fully execute all transactions and relies on previous validations to assume they are valid.

Once the block is assembled, the proposer broadcasts a block proposal to the network, with just references to the transaction (block header & transaction IDs) rather than the full block data. It also sends the full block by dividing it into parts and disseminating it across the network, which arrives after the block. Since the validators in the network already have the actual transactions in their mempool, they quickly identify the transactions the block contains and start processing them. Right after sending the block proposal, the proposer disseminates the whole block by splitting it into chunks. If a validator was missing a transaction, it will receive it in this broadcast. This means that by the time the full block data is available, every validator has essentially the same block assembled. The network thus achieves a rapid shared view of the proposed block.

Once a validator has the proposed block, it validates the proposal before voting on it. This involves performing validations on each transaction and verifying that all the transactions in the block are valid according to the state. Then a step is carried out where the block’s transactions are run through in ‘Check mode’ to ensure none would fail if executed. In such a case, the validator would broadcast a ‘prevote’ for a nil block, causing the consensus to move on and the bad block to be dropped. Assuming the block is valid, the validator now enters the Tendermint consensus voting stages — it sends a prevote for this block to all the other validators in the network. If at least 2/3 of the voting power prevotes for the proposed block, the protocol moves to the ‘Precommit stage. ’ Validators then send precommit votes for the block, and if at last 2/3 of the voting power again precommits for the block, it is decided to be the next block of the chain.

By the time precommits are collected, the network has agreed on the block. During these voting stages, the Sei validators begin optimistically executing the transactions even before finalizing the vote. If the required majority is not met, the consensus will move to the next block and try again. Alongside votes, the block itself is finalized to all the nodes in the network. By the time the precommit stage is successful, each validator should have the full block data. At this stage, the network has reached consensus on a specific block, and next comes executing the transactions and committing the block.

Since Sei implements optimistic block processing without waiting for the block to be officially committed, as soon as a validator receives the block proposal, it begins executing the block’s transactions and updating the state to a local data cache. If the network does not reach a consensus on the block, then the cache is cleared, and it’s on to the next block. This optimistic execution cuts down latency since very little needs to be done once consensus is reached because the validators have essentially pre-executed everything.

Once validators have all of the transactions as a part of the block proposal, they try to come to a consensus on the transaction ordering. Instead of waiting for the validators to come to a consensus, validators start optimistically processing transactions and updating the state to a data cache. This processing of transactions is parallelized (similar to Solana) to increase throughput. The validator builds a Direct Acyclic Graph (DAG) of transactions at runtime, enforcing the sequential processing of transactions operating on the same state while maintaining parallelism for others. If the block is accepted by the network, the data from the cache is committed, otherwise, the data from the cache is discarded. The block is now committed to the chain, on-chain state updated and mempools are pruned to remove confirmed or expired transactions. The chain then advances to the next block and the cycle repeats.

Sei vs Solana

While there are quite a few parallels that can be drawn between Solana and Sei, there are some key differences, as you might have noticed from the previous sections. Here are a couple of the architectural design decisions that give the other blockchain the edge:

• Sei follows the Ethereum-esque way of using a mempool that has to be propagated across the network, introducing propagation delay and overhead. Solana’s approach cuts out the gossip lag by directly routing incoming transactions to the leader, resulting in quicker inclusion and feedback. By avoiding a large, lingering mempool, Solana drastically reduces confirmation time and memory usage and can switch leaders quickly without a backlog of transactions slowing things down. Though Sei has optimizations like broadcasting a compact block proposal, it must still deal with the consequences of a mempool-based architecture.

• Sei inherits Tendermint’s proposer selection, where the block proposer is essentially decided block-by-block rather than in a long pre-published schedule. Solana can pipeline block production without pause, whereas Tendermint’s synchronous voting rounds inherently add latency since the number of messages grows significantly as more validators join the network. This is called ‘Quadratic Communication Complexity’ and leads to heavy traffic over the gossip protocol at high node counts. Solana’s design avoids this scaling bottleneck, allowing it to maintain 400ms slots even with hundreds or thousands of validators.

• Sei achieves deterministic finality through a single block commitment process using Tendermint-based consensus, where transactions are finalized as soon as a block receives two-thirds precommits. This guarantees that once a transaction is included, it is irreversible, eliminating the possibility of forks or chain reorganization. Solana uses an optimistic confirmation model with Tower BFT layered over Proof of History, which provides fast but probabilistic finality. While Solana’s blocks are confirmed within a second under normal conditions, finality can take several additional slots. Sei’s strict finality model offers greater predictability and simplicity for applications that require strong guarantees, like settlement layers or institutional finance systems.

So, who is the winner?

Well, the game's not over yet! Until now, Solana is ahead of the game in terms of the most relevant metrics, as we’ve just seen. But both Solana and Sei are constantly innovating and pushing upgrades to their networks with one goal in mind — Increase Bandwidth, Reduce Latency. Solana is increasing blockspace to 50M CUs and maybe even 60M CUs soon, while Sei is working towards a new iteration of the current network in production — Sei Giga, which promises exponential performance upgrades. Who wins? Only time can tell. Until then, we’re off to the races. May the best chain win!

References

• https://solanahowitworks.xyz

• https://www.anza.xyz/blog/introducing-the-central-scheduler-an-optional-feature-of-agave-v1-18

• https://www.helius.dev/blog/all-you-need-to-know-about-solanas-v1-18-update

• https://dune.com/ilemi

• https://blockworks.co/analytics/solana/sol-onchain-activity

• https://zerocap.com/insights/research-lab/sei-network-cosmos-chain-optimisation/

• https://github.com/sei-protocol/sei-chain/tree/main/docs/rfc

• https://github.com/sei-protocol/sei-chain/blob/main/whitepaper/Sei_Whitepaper.pdf

• https://docs.cosmos.network/main/learn/

• https://blog.sei.io/sei-v2-the-first-parallelized-evm/

• https://www.cyber.capital/news/so-long-solana-the-rise-of-blockchains-parallel-universes

• https://blog.sei.io/twin-turbo-consensus

• https://www.validators.app/

Disclaimer: This article is purely for informational purposes, and none of it should be considered as financial or any other advice.

Subscribe now

A special thank you to Squid (Drift), Fikunmi (Eclipse), Max Resnick, and Alessandro Decina (Anza) for their help and for reviewing earlier drafts of this article.

Introduction

For years, AMMs like Uniswap and Orca have been the backbone of DeFi, with their algorithmic approach making them easy to design and deploy onchain. But they come with trade-offs like higher fees, poor price discovery, and increased slippage. Now, CLOBs - the gold standard in traditional finance - are gaining traction onchain. Unlike AMMs, CLOBs let traders place custom buy and sell orders at specific prices, enabling more efficient and transparent markets.

In this article, we’ll compare Solana’s evolving CLOB and greater DeFi ecosystem to Hyperliquid’s specialized approach, breaking down technical superiorities, challenges, trade-offs made, and the way forward.

CLOBs, AMMs & more

A Central Limit Order Book or CLOB is a traditional exchange mechanism where buyers and sellers post limit orders (with a specified price and quantity), which are queued and matched by price-time priority. The highest bid and lowest ask converge to define the market price, and participants can place orders at any price. This model offers transparent price discovery, allowing users to set custom prices and sizes.

By contrast, Automated Market Makers (AMMs) like Uniswap use liquidity pools and pricing formulas (example: constant-product) instead of order books. AMMs guarantee that any trader can swap against a pool at a price determined by a formula, but at the cost of price impact and less precise control. AMMs are simpler to implement onchain (no orderbook), but they require liquidity providers to deposit tokens and often suffer from slippage on large trades.

Messari Research opines that onchain CLOBs represent the optimal DEX architecture for capital efficiency, price discovery, and scalability, combining the capital efficiency of orderbook matching with transparency. The drawback is they demand low latency and low gas fees to function smoothly onchain - historically a challenge on many blockchains. This means DeFi is relegated to CEX-DEX arbitrage, rather than being the venue for price discovery. CLOBs might not be the endgame for onchain finance, though it will look pretty similar to a CLOB.

Solana getting CLOBbered

Solana’s superiority in throughput and low fees makes it the perfect playground to experiment with different DeFi mechanisms, including CLOBs. Serum DEX was the first iteration launched in 2020 by Alameda Research. It implemented a permissionless onchain CLOB and matching engine. Users placed orders via transactions, and a separate offchain ‘crank’ repeatedly called the matching logic to settle trades. This was a pretty good pilot, but the Solana network was pretty nascent at the time, with suboptimal designs like a FIFO scheduler.

In late 2023, Ellipsis Labs announced Phoenix - a CLOB DEX that improved on Serum by achieving instant, atomic trade settlement without offchain cranking. Its architecture consolidates the orderbook, matching engine and trader balances into a single market account using efficient in-memory data structures. Its design minimizes account inputs, reduces compute usage, and achieves high throughput with subsecond finality. Phoenix primarily runs SOL/USDC and SOL/USDT pairs and even reached a daily volume peak of ~$1.2B early last year.

While Phoenix proves that a completely on-chain CLOB can operate on Solana, it still struggles because Solana’s architecture, despite being one of the fastest out there, isn’t fast enough for market makers to safely place tight bid/ask prices. When prices move quickly, market makers can’t cancel or update their orders in time, which means they often get stuck with bad trades and lose money. To avoid this, they either quote wider spreads (making the DEX less useful) or avoid it entirely.

Why Solana isn’t enough

Solana’s block production is paced by ~400ms slots, meaning order updates take hundreds of milliseconds to reach an optimistic confirmation (since currently, finality is ~12s). By contrast, high-frequency trading operates in sub-millisecond time. Market makers find that stale orders linger, so they must quote more conservatively to avoid being picked off. The single leader design also creates a bottleneck, where if the leader gets busy or censors transactions, all other updates, including cancels, wait, stalling order updates for ~400ms.

Solana’s fee market has also been unpredictable in the past, though improvements are being readily worked on. Market makers struggle to determine how much to bid for priority fees each time they update their quotes. This results in an unfavorable environment where market makers constantly overpay to avoid getting sniped. Traders are also forced to pay gas fees on every limit order, irrespective of whether it gets filled or not, leading to high operational costs.

Another symptom of the single leader design is the Jito blockspace auction, making it impossible for market makers to win the race to cancel their quotes before takers can snipe stale orders. Even if the market maker is faster, what matters is who wins the blockspace auction. They can either pay a lot of money to cancel their quote, or they can let somebody else pay a lot of money to snipe them. This means market makers on Solana cancel orders successfully less often than on CEXs.

Finally, as a global distributed state system, Solana relies on the public internet to reach consensus, which is inherently noisy and delayed. Packets jitter, nodes lag, and blocks must reach all validators. This is unlike a centralized exchange, where all matching engines share one data center. These internet delays mean an order sent by a maker can be out of date by the time it’s confirmed on the network, further penalizing market makers who must quote conservatively. Most of the code behind DEXs and the network itself is also bug-ridden, which is a significant hindrance. This doesn’t mean CLOBs on Solana aren’t possible but it requires a level of understanding of the chain that very few people have.

Hyperliquid.

Late last year, Hyperliquid—a CLOB-based DEX — launched with its own hyper-optimized appchain and consensus algorithm, built from the ground up to power its enshrined order book. A high performance consensus algorithm (HyperBFT) and a colocated validator set enable block times of ~70ms. Hyperliquid charges no gas fees on orderbook transactions and prioritizes market maker cancels by automatically pulling all order cancels to the top of the block, mitigating the late-cancel problem faced on Solana CLOBs.

But at the end of the day, Hyperliquid is a permissioned consensus environment. It may be permissionless to use but if only a curated few run consensus, you’re operating under a delegated trust model that’s no longer censorship resistant. You’re effectively trading arguably the most important part of DeFi for lower latency. But in return, you don’t have to deal with game-theoretic complications. With no open-source code to publicly audit, you can’t even say if it’s just a Postgres instance running on AWS East-1.

This model may have valid engineering justifications, but censorship resistance is one of the biggest reasons onchain finance must succeed. Considering that Hyperliquid is closer to a CEX alternative than a blockchain, if Binance’s perps platform starts filling orders and allows permissionless access to the platform with a 50ms latency, that effectively nullifies their advantage. But at the end of the day, they do present a viable high-performance trading experience that Solana must seek to match.

Solana’s next moves

The Solana ecosystem has gone into war mode to ensure they are the victor in the CLOB battle. This has manifested itself as multiple approaches to solving the bottlenecks mentioned earlier in the article. Some of these approaches present a radical change to the protocol, and some are performance optimizations. These approaches include a brand new consensus protocol, steady upgrades to validator clients, multiple concurrent producers, and even network extensions. Jito recently released BAM (Blockspace Assembly Markets) to enable verifiable, private sequencing which could enable apps to prioritize maker orders and cancels.

Zeta Markets, a Solana perps DEX, announced their Testnet for Bullet, a low-latency ‘network extension’ (essentially an L2) in March, with mainnet launch planned in the coming months. By essentially creating purpose-built blockspace for orderbook transactions, you can have custom sequencing rules, for example, prioritizing cancels, latency as low as 2ms (soft finality claimed by Bullet), and throughput that’s orders of magnitude higher than what you see in general-purpose chains. While Bullet has its own custom blockspace and transaction execution model, it still relies on Solana for settlement, consensus, and data availability.

Solana’s founder Anatoly Yakovenko argues that an alternative execution layer for CLOBs are not beneficial to the base layer since they do not accrue any value back to it, and there is a general consensus among core contributors to the Solana network that network extensions are essentially a competitor to the base layer itself. He also argues that Solana can provide an L1-native solution that will require the newly announced consensus mechanism (Alpenglow), asynchronous execution, multiple concurrent producers and application specific sequencing on the base layer.

Alpenglow fundamentally revamps Solana’s consensus to achieve ultra-low latency(~97ms) on the base layer. It replaces Solana’s current Proof of History + TowerBFT consensus mechanism, which is the reason for subpar 12s finality and 400ms optimistic confirmations, and takes vote propagation off-chain, dramatically reducing consensus overhead.

Another pillar of Solana’s proposed approach is Multiple Concurrent Producers (MCP), which removes the single-leader bottleneck by allowing parallel block production. In the current single-leader model, only one validator at a time dictates the order of transactions for the entire network, limiting throughput and creating a central point of control. MCP instead enables multiple leaders to propose blocks simultaneously or in overlapping intervals, essentially creating parallel block streams that run concurrently. This parallelization enhances overall throughput and reduces latency by utilizing a greater portion of the network’s capacity simultaneously. It can also boost censorship resistance by preventing a single validator from monopolizing the network for the time period of a slot.

Finally, Asynchronous Execution and App-Specific Sequencing(ASS) work hand in hand to create specialized execution lanes with their own matching and prioritization rules. Asynchronous execution means consensus is reached on the order of transactions without immediately executing them, freeing up the consensus layer to finalize blocks much faster. App-Specific Sequencing lets particular programs or platforms define custom ordering logic within the base layer’s consensus rules. For example, an orderbook program could specify that order cancels receive the highest priority in their lane, ensuring market makers can quickly pull orders without delay. This roadmap aligns with Solana’s mission of outcompeting major stock exchanges and establishing a ‘decentralized NASDAQ’mbuspodma

Bottom Line

Hyperliquid is great at what it is  —  a permissionless CEX alternative, but does not possess the vital redeeming qualities of modern blockchains like censorship resistance and liveness guarantees. Solana aims to provide CEX-like performance with the security guarantees of a blockchain. Hyperliquid can be easily toppled by a centralized system that manages to be more performant, but building a blockchain with a permissionless validator set and optimizing it to beat trad-fi systems is much harder, but with the current progress in optimizing in the Solana network, I am optimistic that this will happen on Solana.