Author: Pranav Garimidi, Joachim Neu, Max Resnick, a16z crypto researchers; Source: a16z crypto; Translated by: Shaw Golden Finance

Today’s blockchain can confidently claim that it has the processing capacity needed to compete with existing financial infrastructure. Current production systems can handle tens of thousands of transactions per second, and future performance improvements will increase this capacity by orders of magnitude.

However, beyond sheer throughput, financial applications also require predictability. When a transaction is initiated—whether it is a trade, a bid, or an option exercise—reliably ensuring the time it is confirmed on-chain is critical for the normal operation of the financial system. If transactions face unpredictable delays—whether from malicious interference or accidental circumstances—many applications will be unable to operate normally. To make on-chain financial applications competitive, the blockchain must provide short-term guarantees for transaction on-chain: as soon as a valid transaction is submitted to the network, it must be ensured that it is packaged on-chain as quickly as possible.

Take an on-chain order book as an example. An efficient order book requires market makers to provide liquidity by continuously placing buy and sell orders. The core challenge for market makers is how to minimize the bid-ask spread (the difference between buy and sell prices) while avoiding adverse selection risks caused by disconnection from the market. To achieve this, market makers must constantly update their orders to reflect the latest market conditions. For example, when the Federal Reserve issues an announcement causing significant price swings, market makers need to update their orders immediately to the new prices. In such cases, if the transactions used to update orders cannot be instantly put on-chain, arbitrageurs will execute trades at outdated prices, incurring losses. Market makers are forced to widen their spreads to hedge against such risks, which reduces the competitiveness of on-chain trading platforms.

A predictable on-chain transaction mechanism can provide market makers with reliable guarantees, enabling them to respond quickly to off-chain events and maintain efficient on-chain markets.

The Gap Between Current State and Demand

Currently, existing public chains can only provide relatively reliable finality guarantees within a few seconds. This level of guarantee is sufficient for payment applications, but it is far from enough for many financial applications that require real-time responses from market participants. For example, in the order book scenario: for market makers, if arbitrageurs’ transactions can be prioritized and packaged into earlier blocks, then the guarantee of “on-chain within seconds” becomes meaningless. Without strong guarantees, market makers can only hedge the increased adverse selection risk by widening spreads and offering worse quotes, making on-chain trading less attractive compared to other venues with stronger guarantees.

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

Where Is the Difficulty in Achieving Predictability?

Strengthening transaction on-chain guarantees on existing public chains to support such financial scenarios is extremely difficult. Many current protocols rely on a single node (the “block producer”) to decide which transactions are included within a given timeframe. While this design reduces engineering complexity, it also creates potential economic monopolies—block producers can extract value from this arrangement. 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 supporting various financial activities, block producers are in a privileged position. If a block producer refuses to include a certain transaction, users can only wait for the next block producer willing to include it. In permissionless networks, block producers inherently have incentives to extract value, known as miner extractable value (MEV). MEV is far more complex than just sandwich attacks on AMM trades. Even delaying the inclusion of a transaction by a few milliseconds can allow the block producer to profit significantly and severely reduce the efficiency of underlying applications. If the order book only prioritizes some traders’ transactions, it is unfair to all other participants. In extreme cases, malicious behavior by block producers can cause traders to abandon the platform altogether.

For example: when the Federal Reserve announces a rate hike, ETH’s price drops by 5% instantly. All market makers on the order book rush to cancel their existing orders and re-place new ones at the updated prices. Meanwhile, arbitrageurs submit trades trying to sell ETH at outdated prices. If this order book operates on a protocol with a single block producer, that node will have enormous power. It can directly censor all market makers’ cancellations, allowing arbitrageurs to earn huge profits; or it can partially censor or delay processing cancellations, releasing them only after arbitrageurs’ trades are on-chain; or it can even insert its own arbitrage trades, profiting fully from the price deviation.

Two Core Demands: Censorship Resistance and Transaction Privacy

Faced with such a privileged position, active participation by market makers becomes unprofitable—whenever prices fluctuate, they risk being exploited. The fundamental problem stems from the fact that block producers hold excessive privileges in two aspects: they can censor any trader’s transactions; and they can see other traders’ transactions and respond accordingly. Either of these issues can lead to disastrous outcomes.

Example Illustration

Let’s clarify this with a case study. Suppose there is an auction with two bidders: Alice and Bob, and Bob happens to be the block producer for the auction’s block. (For simplicity, only two bidders are considered, but the logic applies to any number of bidders.)

The auction accepts bids during a period from t=0 to t=1. Alice submits a bid bA at time tA, and Bob submits a bid bB at time tB (tB > tA). Since Bob is the block producer for this block, he can always ensure his bid is the last one. Both Alice and Bob can read the continuously updated true asset price (e.g., the midpoint price from a centralized exchange). Let the price at time t be pt, and assume that at any time t, both parties expect the asset’s price at the end of the auction (t=1) to be equal to the current pt. The auction rules are simple: the highest bid wins and is executed at that bid price.

The Need for Censorship Resistance

Now, consider what happens if Bob exploits his privilege as the block producer. If Bob can censor Alice’s bid, the auction mechanism fails outright. He only needs to bid an extremely low price to guarantee victory, since all other bids are blocked. This would make the auction’s final revenue nearly zero.

The Need for Transaction Privacy

A more complex scenario is when Bob cannot directly censor Alice’s bid but can see her bid before placing his own. In this case, Bob might adopt a simple strategy: when bidding, he checks whether the current price ptB exceeds bA. If so, he bids slightly above bA; if not, he abstains from bidding.

Using this strategy, Bob will keep Alice at risk of adverse selection. Alice can only win if her bid exceeds the asset’s expected value after price updates. But whenever she wins, she expects to incur losses, eventually deciding not to participate further. Once all other bidders drop out, Bob can bid a very low price and win, reducing the auction’s revenue to zero.

The core conclusion from this example is: the length of the auction does not matter. As long as Bob can censor Alice’s bid or see her bid before he places his own, the auction is doomed to fail.

This logic applies equally to all high-frequency trading scenarios, including spot trading, perpetual contracts, and derivatives exchanges: if there exists a block producer with powers similar to Bob’s, the entire market mechanism will collapse. To make on-chain products supporting these scenarios feasible, we must prevent block producers from having such privileges.

How Do These Problems Manifest in Practice?

The above description paints a bleak picture for any on-chain trading protocol that relies on permissionless single block producer nodes. Yet, many decentralized exchanges (DEXs) built on such protocols still see good trading volumes. Why?

In practice, two forces have mitigated these issues:

• Block producers do not fully abuse their economic privileges because they usually have significant vested interests in the success of the underlying public chain;

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

Although these factors have allowed DeFi to operate so far, they are not sufficient in the long term to enable on-chain markets to truly compete with traditional off-chain markets.

On a public chain with substantial economic activity, obtaining block production rights requires staking large amounts of tokens. Therefore, block producers either hold large collateral themselves or have enough reputation to delegate staking rights to others. In either case, large node operators are typically public entities, and their reputation is at risk. Besides reputation, their staked assets create economic incentives to promote the chain’s healthy development. Because of this, we have not seen block producers completely abuse market power as described above—but this does not mean these issues do not exist.

On one hand, relying on social pressure and long-term interests to constrain node operators’ good behavior is not a reliable foundation for future financial systems. As on-chain financial activities grow, the potential profits for block producers will also increase. The greater this potential, the harder it becomes to constrain their behavior through social means and short-term incentives.

On the other hand, the extent of market power abuse by block producers exists along a continuum, from mild misconduct to outright market destruction. Node operators can gradually test boundaries, leveraging their power to extract higher rewards. When some operators push beyond acceptable limits, others tend to follow quickly. Although a single node’s behavior may seem limited, widespread imitation can cause significant disruption.

A typical example is the timing game: block producers delay publishing blocks as long as possible while still ensuring validity, to earn higher rewards. This can extend block times, and if too aggressive, may cause blocks to be skipped. Although profitable, such strategies are initially avoided to maintain the reputation of the chain’s custodians. However, this social equilibrium is fragile. Once a node operator begins employing such tactics for higher gains without penalties, others will follow.

Timing games are just one example of how block producers can increase their returns without fully abusing their power. They can also adopt many other methods to profit at the expense of applications. Individually, these methods may still be within acceptable bounds, but over time, they can push on-chain operational costs beyond benefits.

Another factor that helps DeFi operate normally is that many applications move core logic off-chain, only recording results on-chain. For example, protocols requiring fast auction execution often perform these off-chain. These applications typically run on a set of permissioned nodes to avoid malicious block producers. For instance, UniswapX executes Dutch auctions off-chain on Ethereum, and Cowswap also runs batch auctions off-chain.

While this approach ensures application functionality, it makes the underlying chain and its core value propositions vulnerable. If all execution logic is off-chain, the chain becomes merely a settlement layer. One of DeFi’s main advantages is composability, but if all execution occurs off-chain, applications exist in isolated environments. Relying on off-chain execution also introduces new trust assumptions: applications must trust that the underlying chain operates correctly and that off-chain infrastructure is available and reliable.

How to Achieve Predictability

To solve these issues, protocols must have two key features: stable transaction on-chain and ordering rules, and transaction privacy before finalization.

Core Requirement One: Censorship Resistance

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

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

More precisely, assume the protocol operates on a fixed clock, with blocks generated at fixed intervals, e.g., every 100 milliseconds. We need this guarantee: if a transaction arrives at an honest node at 250 milliseconds, it will be included in the block generated at 300 milliseconds. Attackers should not have the power to arbitrarily filter, selectively include, or exclude transactions. The core idea is that users and applications should have highly reliable means to ensure their transactions are successfully on-chain at any moment. A transaction should not fail to be included due to packet loss at a single node—whether malicious or due to operational faults.

Although this definition requires providing guarantees for transactions delivered to any honest node, implementing this in practice may be costly. Its main significance is that the protocol should be sufficiently stable to make the transaction entry point highly predictable and straightforward. Permissionless single node protocols clearly do not satisfy this, because if the only block producer at a given time acts maliciously, transactions have no alternative route to be included. However, even if a set of four nodes can guarantee inclusion during each interval, this greatly increases the options for users and applications to get transactions on-chain. Sacrificing some performance for reliability is worthwhile to enable applications to develop steadily. Finding the right balance between robustness and performance remains an open research area, but current guarantees are far from sufficient.

Once the protocol can ensure transaction inclusion, the ordering problem becomes straightforward. The protocol can adopt any deterministic ordering rule to produce consistent results. The simplest approach is to order by priority fee or allow applications to specify flexible transaction ordering. The optimal ordering method is still actively researched, but in any case, ordering only makes sense when transactions can reliably go on-chain.

Core Requirement Two: Confidentiality

After establishing short-term censorship resistance, the second key feature the protocol must provide is a privacy protection mechanism we call concealment.

Concealment: Before a transaction is finally confirmed on-chain, no participant other than the recipient node can access any information about that transaction.

Protocols satisfying concealment allow the recipient node to see all submitted transactions in plaintext, but require the rest of the protocol to remain unaware of transaction contents until consensus is reached and the transaction order is finalized. For example, the protocol could use time-lock encryption, making the entire block contents invisible until a certain deadline; or employ threshold encryption, where the block is decrypted only after a committee confirms its irreversibility.

This means nodes may misuse the transaction data they receive, but other nodes in the network cannot learn about the transaction until it is finalized. When transaction data is revealed to the network, the transaction has already been ordered and confirmed, preventing front-running. To make this practical, multiple nodes should be able to finalize transactions at any time.

We did not adopt a stronger privacy model—where only the user knows the transaction content before confirmation (e.g., encrypted mempool)—because the protocol needs a stage to filter out spam transactions. If transaction contents are fully hidden from the network, it cannot distinguish spam from valid transactions. The only solution is to include some non-private metadata, such as fee addresses, which are paid regardless of validity. However, such metadata can still leak enough information for attackers to exploit. Therefore, we prefer a design where a single node can see the full transaction, but others cannot. This also means that users must have at least one honest node available at any time to serve as an on-chain entry point.

Conclusion

Protocols that combine short-term censorship resistance with transaction concealment are the ideal foundation for building financial applications. Returning to our on-chain auction example, these two features directly address the issues that could cause market collapse—Bob’s ability to censor Alice’s bid or to use her bid to inform his own—resolving problems 1) and 2) from earlier.

With short-term censorship resistance, any user submitting a transaction—whether a trade or an auction bid—can be assured that it will be immediately packaged on-chain. Market makers can update orders, bidders can respond quickly, and clearing operations can be performed efficiently. Users can trust that any action they initiate will be executed instantly. This will enable the next generation of low-latency, real-world financial applications to be fully built on-chain. To truly compete with or surpass existing financial infrastructure, blockchain must address more than just throughput.