Author: Pranav Garimidi, Joachim Neu, Max Resnick, a16z crypto researchers; Source: a16z crypto; Translation: Shaw Jinse Finance

Today’s blockchain can confidently claim that it has the processing capacity to compete with existing financial infrastructure. Current production systems process tens of thousands of transactions per second, with future performance expected to improve by orders of magnitude.

However, beyond raw throughput, financial applications also require predictability. When a transaction is initiated—whether it’s a trade, bid, or option exercise—reliably ensuring the confirmation time on the chain is critical for the normal operation of financial systems. If transactions face unpredictable delays—whether due to malicious interference or accidental issues—many applications will be unable to function properly. To make on-chain financial applications competitive, blockchains must provide short-term guarantees that valid transactions submitted to the network are confirmed on-chain as quickly as possible.

Take on-chain order books as an example. Efficient order books require market makers to continuously place buy and sell orders to provide liquidity. The core challenge for market makers is: how to minimize the bid-ask spread while avoiding adverse selection risk caused by outdated quotes. To do this, market makers must constantly update orders to reflect the latest market conditions. For instance, when the Federal Reserve announces a policy change causing asset prices to fluctuate sharply, market makers need to update their orders immediately to the new prices. If the transactions used to update orders cannot be confirmed on-chain promptly, arbitrageurs can execute trades at outdated prices, incurring losses. Market makers are then forced to widen spreads to hedge against this risk, which reduces the competitiveness of on-chain trading platforms.

Predictable transaction confirmation mechanisms can provide reliable guarantees for market makers, enabling them to respond quickly to off-chain events and maintain efficient on-chain markets.

Gap Between Current State and Needs

Currently, existing public blockchains can only provide relatively reliable finality guarantees within a few seconds. This is sufficient for payment applications, but far from enough for many financial applications that require real-time responses from market participants. Using the order book scenario above as an example: for market makers, if arbitrageurs’ transactions can be prioritized and included in earlier blocks, then the “confirmation within seconds” guarantee is meaningless. Without strong confirmation guarantees, market makers can only widen spreads and offer worse quotes to hedge against higher adverse selection risk. This makes on-chain trading less attractive compared to other venues with stronger guarantees.

If blockchain is to truly realize its vision as the infrastructure for modern capital markets, developers must address these issues to enable high-value applications like order books to thrive on-chain.

Where Is the Difficulty in Achieving Predictability?

Enhancing transaction confirmation guarantees on existing public chains to support such financial scenarios is extremely challenging. Many current protocols rely on a single node (the “block producer”) to decide which transactions are included within a given time frame. While this design reduces engineering complexity, it also creates a potential monopoly point—block producers can extract value through their control. Typically, during the window when a node is selected as the block producer, it has absolute control over which transactions are included in the block.

For public chains hosting various financial activities, block producers hold privileged positions. If a block producer refuses to include a transaction, users can only wait for the next block produced by a different node willing to include it. In permissionless networks, block producers have inherent incentives to extract value, known as Miner Extractable Value (MEV). MEV is not limited to simple sandwich attacks on AMM trades; even delaying the inclusion of a transaction by tens of milliseconds can yield huge profits and significantly reduce the efficiency of underlying applications. If order books prioritize certain traders’ transactions, it is unfair to other participants. In extreme cases, malicious behavior by block producers can cause traders to abandon the platform altogether.

For example: the Federal Reserve announces a rate hike, causing ETH prices to drop 5% instantly. All market makers on the order book rush to cancel their existing orders and re-place them at the new prices. Meanwhile, arbitrageurs submit transactions to sell ETH at outdated prices. If the order book runs on a protocol with a single block producer, that node wields enormous power. It could directly censor all market makers’ cancellations, allowing arbitrageurs to profit massively; or delay processing cancellations, then release them after arbitrageurs’ transactions are confirmed; or even insert its own arbitrage trades, profiting fully from price deviations.

Two Core Demands: Censorship Resistance and Transaction Confidentiality

With such an advantage, active participation by market makers becomes unprofitable—any price movement could be exploited. The fundamental problem stems from the fact that block producers have excessive privileges: they can censor any trader’s transactions; they can see other traders’ transactions and respond accordingly. Any of these issues could lead to disastrous outcomes.

Example Illustration

Let’s clarify with a case. Suppose an auction with two bidders: Alice and Bob, and Bob happens to be the block producer of the block containing the auction. (Using only two bidders simplifies explanation; the logic applies to any number of bidders.)

The auction accepts bids during the block creation window, from t=0 to t=1. Alice submits bid bA at time tA; Bob submits bid bB at time tB (where tB > tA). Since Bob is the block producer, he can always ensure his bid is last. Both Alice and Bob can read the real-time asset prices (e.g., the mid-price on a centralized exchange). Let’s denote the price at time t as pt, and assume that at any time t, both expect the final auction price at t=1 to be approximately pt. The auction rule is simple: the highest bid wins and trades at that bid.

The Need for Censorship Resistance

Now, consider what happens if Bob can censor Alice’s bid. The auction mechanism collapses: Bob can bid an extremely low price, guaranteeing his victory, since all other bids are blocked. This results in nearly zero auction revenue.

The Need for Confidentiality

A more complex scenario: Bob cannot directly censor Alice’s bid but can see her bid before submitting his own. He adopts a simple strategy: when placing his bid, he compares the current price ptB to bA. If ptB > bA, he bids slightly above bA; otherwise, he abstains. This causes Alice to face adverse selection: she can only win if her bid exceeds the asset’s expected value after the price updates. Whenever she wins, she expects to lose money, eventually abandoning the auction. Once all competitors leave, Bob can bid very low and win, driving auction revenue to zero.

The core conclusion: the duration of the auction doesn’t matter. If Bob can see Alice’s bid before he bids, or can censor her bid, the auction is doomed to fail.

This logic applies equally to high-frequency trading of assets, including spot, perpetuals, and derivatives: if a block producer has such power, the entire market mechanism collapses. To support such scenarios, on-chain products must not grant block producers these privileges.

How Do These Problems Arise in Practice?

The above scenario paints a bleak picture for permissionless, single block producer protocols. Yet, many decentralized exchanges (DEXs) built on such protocols still see good trading volumes. Why?

In reality, two forces counteract these issues:

• Block producers do not fully abuse their economic privileges because they have strong incentives to ensure the success of the underlying chain;

• Various applications have devised workarounds to reduce their vulnerability to these problems.

While these factors have allowed DeFi to operate so far, they are insufficient for long-term resilience against market competition.

On a public chain with significant economic activity, obtaining block production rights requires staking large amounts of tokens. Therefore, block producers are either large token holders or entities with enough reputation to have others delegate staking to them. In either case, large validators are typically public entities with reputational risks. Besides reputation, their staked assets create economic incentives to promote the health of the chain. As a result, we currently rarely see block producers fully abusing market power as described above—but that doesn’t mean the issues are nonexistent.

One side relies on social pressure and long-term incentives to constrain node operators’ behavior, but this is not a reliable foundation for future financial systems. As on-chain financial activity grows, the potential profits for block producers also increase. The greater this potential, the harder it becomes to restrain them through social or reputational means.

On the other hand, the degree of market power abuse by block producers exists on a continuum—from mild to destructive. Operators can gradually test the limits, exploiting their privileges for higher rewards. As some push beyond acceptable boundaries, others tend to follow. While individual behaviors may seem limited, collective escalation can cause significant disruptions.

A classic example is the “timing game”: block producers may delay publishing blocks to earn higher rewards, or ensure blocks are still valid while extending the time between blocks. Excessive delays can lead to skipped blocks. Although such strategies are known to be profitable, initial restraint is often maintained to preserve the chain’s reputation. However, social equilibrium is fragile: once a validator begins to adopt such tactics for higher gains without punishment, others will quickly follow.

Timing games are just one example of how block producers might subtly increase their profits without outright abuse. They can also employ many other tactics that sacrifice application fairness for short-term gains. Individually, these may seem manageable, but collectively they can push the system beyond sustainable costs.

Another factor supporting DeFi’s normal operation is that many applications move core logic off-chain, only anchoring results on-chain. For example, protocols requiring fast auction execution often perform the actual auctions off-chain, using a set of permissioned nodes to avoid malicious block producers. UniswapX, for instance, runs Dutch auctions off-chain on Ethereum, and Cowswap batches auctions similarly.

While this approach ensures application stability, it risks undermining the fundamental value proposition of the underlying chain. If core logic is off-chain, the chain becomes merely a settlement layer. One of DeFi’s main advantages is composability; if all execution occurs off-chain, applications become siloed. Relying on off-chain execution also introduces new trust assumptions: applications depend not only on the chain’s proper operation but also on the availability of off-chain infrastructure.

How to Achieve Predictability

To address these issues, protocols must embody two key features: stable transaction confirmation and ordering rules, and transaction privacy before finalization.

Core Requirement 1: Censorship Resistance

We define this as short-term censorship resistance. If a protocol has this property, any transaction arriving at an honest node will be guaranteed to be included in the next available block.

Short-term censorship resistance: Any valid transaction delivered on time to any honest node will be included in the next block.

More precisely, assume the protocol operates on a fixed clock, with blocks generated at regular intervals—say every 100 milliseconds. We need guarantees such that if a transaction arrives at an honest node within 250 milliseconds, it will be included in the block generated at 300 milliseconds. Attackers should not have the power to selectively filter, exclude, or delay transactions arbitrarily. The core idea is that users and applications should have a highly reliable way to ensure their transactions are confirmed promptly, regardless of individual node failures or malicious behavior.

While achieving this guarantee for transactions delivered to any honest node may be costly, its essence is that the protocol should be sufficiently stable to make transaction inclusion highly predictable and straightforward. Permissionless single-node protocols cannot satisfy this, because if the sole block producer acts maliciously, transactions have no other on-chain path. Even with a small committee of four nodes, increasing the number of reliable block producers significantly improves transaction confirmation reliability. Sacrificing some performance for increased reliability is worthwhile for the development of robust applications. Finding the right balance between robustness and throughput remains an open research area, but current guarantees are insufficient.

Once the protocol can ensure transaction inclusion, ordering becomes straightforward. It can adopt any deterministic ordering rule—such as prioritizing by fee or allowing applications to specify custom orderings—since all transactions that are confirmed will be included in a predictable sequence. The key is that only confirmed transactions matter; without guaranteed inclusion, ordering is meaningless.

Core Requirement 2: Confidentiality

After establishing short-term censorship resistance, the second critical feature is a form of privacy we call confidentiality.

Confidentiality: Before a transaction is finalized and included on-chain, no participant other than the recipient node can learn any details of that transaction.

Protocols satisfying confidentiality can allow nodes to see the plaintext of transactions submitted to them, but require that the rest of the network remains unaware of transaction contents until final confirmation. For example, using time-lock encryption to hide transaction details until a certain deadline; or threshold encryption, where only after a committee confirms the block as irreversible can the data be decrypted.

This means nodes might misuse the transaction information they see, but other nodes in the network cannot learn the transaction details before consensus. Once the transaction is included and finalized, it is public, preventing front-running. To make this practical, multiple honest nodes should be able to confirm and include transactions within a short window.

We did not adopt a stronger privacy model—such as only the user knowing the transaction before confirmation—because protocols need some mechanism to filter out spam or invalid transactions. If transaction contents are fully hidden, the network cannot distinguish valid from invalid transactions. The only solution is to include some non-private metadata (e.g., payment addresses), but this can still leak information. Therefore, we prefer a model where a single node can see the full transaction, but the rest of the network cannot until finalization. This also requires users to have at least one honest node to submit transactions reliably.

Conclusion

Protocols that combine short-term censorship resistance with transaction confidentiality form an ideal foundation for building financial applications. Returning to our on-chain auction example, these features directly prevent Bob from censoring Alice’s bids or exploiting her bid information, solving the issues outlined earlier.

With short-term censorship resistance, any user submitting a transaction—be it a trade or a bid—can be assured it will be confirmed immediately. Market makers can update orders freely, bidders can respond quickly, and settlement can be efficient. Users can trust that their operations will be executed promptly. This enables the development of a new generation of low-latency, real-world financial applications fully on-chain. To truly compete with or surpass existing financial infrastructure, blockchain must address far more than throughput.