Authored by: Pranav Garimidi, Joachim Neu, Max Resnick
Compiled by: Luffy, Foresight News
Blockchains can now legitimately claim to possess the capability to compete with existing financial infrastructure. Current production systems can process tens of thousands of transactions per second, with orders-of-magnitude performance improvements on the horizon.
However, beyond raw throughput, financial applications require predictability. When a transaction is initiated—be it a trade, an auction bid, or an option exercise—having a reliable guarantee of when it will be included on-chain is essential for a financial system to function. If transactions face unpredictable delays, a vast array of applications becomes unusable. For on-chain financial applications to be competitive, blockchains must provide short-term inclusion guarantees: a promise that a valid transaction submitted to the network will be included in a block as soon as possible.
Consider an on-chain order book as an example. An efficient order book requires market makers to continuously provide liquidity by posting buy and sell orders. The core challenge for market makers is to minimize the bid-ask spread while avoiding adverse selection from quoting stale prices. To achieve this, market makers must constantly update their orders to reflect the latest market state. For instance, when a Federal Reserve announcement causes a significant price movement, market makers need to respond instantly by updating their orders to the new price. If the transaction used to update their order cannot be included on-chain immediately, arbitrageurs can trade against the stale price, causing losses for the market maker. In response, market makers would be forced to widen their spreads to mitigate risk, thereby reducing the competitiveness of the on-chain exchange.
A predictable transaction inclusion mechanism provides market makers with the assurance they need to respond rapidly to off-chain events, maintaining the efficiency of the on-chain market.
The Gap Between Current State and the Goal
Current mainstream blockchains only offer eventual inclusion guarantees, often measured in seconds. While sufficient for applications like payments, these guarantees are inadequate for the vast majority of financial applications that require market participants to respond to information in real-time.
Returning to the order book example: a guarantee of inclusion "within a few seconds" is meaningless to a market maker if an arbitrageur's transaction can be included in an earlier block. Without strong inclusion guarantees, market makers must hedge their risk by widening spreads and offering worse quotes to users. This makes on-chain trading less attractive compared to other platforms with stronger guarantees.
For blockchains to truly realize their vision of becoming the modern infrastructure for capital markets, developers must solve these problems, enabling high-value applications like order books to thrive.
Why is Predictability Hard to Achieve?
Strengthening transaction inclusion guarantees on existing blockchains to support such use cases is highly challenging. Some protocols rely on a single node (the block producer) to decide the transaction ordering for a given time slot. While this simplifies the engineering of high-performance public chains, it also creates a potential economic monopoly point, allowing the block producer to extract value.
Typically, during the window when a node is elected as the block producer, it has complete control over which transactions are included in the block.
For a blockchain hosting significant financial activity, the block producer holds a privileged position. If this node refuses to include a transaction, users must wait for the next willing block producer. In a permissionless network, block producers have a natural incentive to extract value, commonly known as MEV (Maximal Extractable Value).
MEV extends far beyond simple sandwich attacks. Even delaying a transaction by tens of milliseconds can allow a block producer to earn substantial profits while reducing the efficiency of the underlying application. An order book that prioritizes orders from only some traders puts everyone else at an unfair disadvantage. In the worst case, malicious behavior by a block producer can drive traders away from the platform entirely.
Imagine a scenario where an interest rate hike is announced, causing the price of ETH to drop 5% instantly. All market makers on an order book would rush to cancel their existing orders and repost them at the new price. Simultaneously, all arbitrageurs would submit orders to sell ETH at the stale price.
If this order book runs on a single-block-producer protocol, that node wields immense power. It could choose to censor all market makers' cancellation transactions, allowing arbitrageurs to profit massively. Alternatively, it could delay the cancellation transactions without outright censoring them, letting arbitrage trades execute first. It could even insert its own arbitrage transaction to profit from the price discrepancy.
Two Core Requirements: Censorship Resistance and Information Hiding
Faced with such advantages, active participation by market makers becomes uneconomical, as they can be exploited whenever prices move. The problem fundamentally stems from two privileges of the block producer:
The ability to censor others' transactions.
The ability to see others' transactions and submit its own based on that information.
Either of these issues alone can lead to catastrophic outcomes.
An Example
We can illustrate this problem precisely with an auction. Suppose there are two bidders, Alice and Bob, and Bob happens to be the block producer for the auction's block. (We use two bidders for simplicity, but the logic extends to any number.)
The auction accepts bids during a block production cycle, say from time 0 to time 1. Alice submits a bid bA at time tA, and Bob submits a later bid bB at time tB. Since Bob is the block producer, he can always ensure he acts last.
Both parties have access to a continuously updated price feed (e.g., the mid-price from a centralized exchange), with the price at time t denoted as pₜ. We assume that at any time t, both parties' expected price of the asset at the auction's end (t=1) equals the current price pₜ. The auction rule is simple: the highest bid wins, and the winner pays their bid.
The Necessity of Censorship Resistance
If Bob can use his role as block producer to censor Alice's bid, the auction mechanism completely breaks down. Bob can simply bid any arbitrarily low price, ensuring he wins, and the auction revenue approaches zero.
The Necessity of Information Hiding
A more subtle scenario: Bob cannot directly censor Alice's bid, but he can see her bid before submitting his own. In this case, Bob has a simple strategy:
If the current price pₜ_B > bA, bid just above bA.
Otherwise, abstain from bidding.
With this strategy, Bob subjects Alice to adverse selection: Alice only wins when her bid is above the asset's expected value, and winning means incurring a loss, so she eventually chooses not to bid. Once all competitors drop out, Bob can then win the auction with an extremely low bid, again yielding revenue near zero.
The key conclusion is: the auction duration is irrelevant. As long as Bob can either censor Alice's bid or see her bid before submitting his own, the auction is doomed to fail.
This logic applies equally to high-frequency trading scenarios, including spot, perpetual, and derivatives exchanges: if the block producer possesses the power Bob has in this example, the market fails completely. For on-chain products supporting such use cases to be viable, the block producer must not be granted such privileges.
Why Haven't These Issues Exploded in Reality?
The analysis above paints a bleak picture for on-chain transactions on single-block-producer, permissionless protocols. Yet, many such protocols still see significant trading volume on their decentralized exchanges (DEXs). Why?
In reality, two forces counteract these problems:
Block producers often hold substantial amounts of the native token, aligning their success with the chain's success, thus they don't fully abuse their economic power.
The application layer has developed workarounds to reduce their vulnerability to such issues.
While these factors have allowed DeFi to function so far, they are insufficient in the long run for on-chain markets to truly compete with their off-chain counterparts.
On chains with significant economic activity, becoming a block producer requires substantial staking. Therefore, nodes either hold large amounts of tokens themselves or have sufficient reputation to attract delegations from other holders. In either case, large node operators are well-known, reputable entities. Furthermore, their staked assets give them an incentive to maintain the chain's health. This is why we haven't yet seen nodes fully abuse their power, but it doesn't mean the problem doesn't exist.
First, relying on the goodwill, social pressure, and long-term incentives of node operators is not a reliable foundation for the future of finance. As the scale of on-chain finance grows, so does the potential profit for nodes. The greater the temptation, the more fragile the social-layer pressure restraining nodes from acting against short-term interests becomes.
Second, the degree of power abuse exists on a spectrum, from mild actions to completely destroying the market. Node operators might unilaterally and gradually expand their power to capture more profit. Once someone crosses a line, others will quickly follow. While a single node's actions might seem limited, a collective shift has obvious consequences.
A prime example is time-bandit attacks: a block producer delays releasing a block for as long as the protocol allows to maximize profit. This leads to extended block times and even missed slots. Although the profitability of such strategies is well-known, nodes initially exercised restraint out of a sense of duty to the chain's health. However, this social equilibrium is fragile; once a node starts arbitraging without consequence, others will quickly follow.
Time-bandit attacks are just one example of nodes increasing their returns without fully abusing their power. There are many ways for nodes to boost their returns at the expense of applications. Individually, these actions might be tolerable, but they can eventually cross a threshold where the cost of operating on-chain outweighs the benefits.
Another reason DeFi still functions is that applications move core logic off-chain, only settling the results on-chain. For instance, protocols requiring fast auctions often run the process off-chain, frequently using a permissioned set of nodes to avoid malicious actors. UniswapX's Dutch auctions on Ethereum mainnet and Cowswap's batch auctions are examples of off-chain execution.
While this approach allows applications to run, it puts the underlying blockchain and its value proposition in an awkward position: moving execution logic off-chain reduces the blockchain to a mere settlement layer. One of DeFi's core advantages is composability, but in a world where all execution happens off-chain, applications are naturally siloed. Relying on off-chain execution also adds new assumptions to an application's trust model: besides the underlying chain's availability, the off-chain infrastructure must also function correctly.
How to Achieve Predictability?
To solve these problems, a protocol needs to satisfy two key properties: predictable transaction inclusion and ordering, and privacy for transactions before confirmation.
First Requirement: Censorship Resistance
We formalize the first property as short-term censorship resistance: if a transaction reaches an honest node, it is guaranteed to be included in the next available block.
Short-term Censorship Resistance: Any valid transaction that arrives at any honest node on time is guaranteed to be included in the next block.
More precisely, assume the protocol runs on a fixed clock, e.g., producing a block every 100 milliseconds. If a transaction arrives at an honest node at 250 ms, it should be included in the block at 300 ms. An adversary cannot selectively include or ignore transactions. The spirit of this definition is that users and applications should have a highly reliable path to get their transactions on-chain, not failing because a single node maliciously drops them or experiences a fault.
While this definition requires that a transaction reaching *any* honest node is included, the implementation overhead might be too high. The key is for the protocol to be robust enough that the entry points for transaction inclusion are highly predictable and simple to reason about.
A permissionless single-block-producer protocol clearly fails this property: if the current block producer is malicious, there is no alternative path for inclusion. Conversely, even having a set of, say, four nodes that guarantee inclusion per slot would significantly increase the options for users and applications. Sacrificing some performance is worthwhile to allow applications to thrive robustly. Finding the optimal balance between robustness and performance requires more research, but current protocols clearly offer insufficient guarantees.
Once a protocol guarantees inclusion, ordering becomes the next concern. The protocol can adopt any deterministic ordering rule—the simplest being ordering by priority fee, or allowing applications flexibility in ordering transactions interacting with their state. The optimal way to order transactions remains an active area of research, but regardless, ordering rules only matter if transactions can get on-chain in the first place.
Second Requirement: Information Hiding
The other crucial property a protocol needs, after short-term censorship resistance, is a privacy guarantee we call hiding.
Hiding: No party other than the node that receives a transaction learns any information about that transaction before it is finally ordered by the protocol.
A protocol satisfying hiding allows the node receiving a transaction to see it in plaintext but requires the rest of the network to remain oblivious until consensus is complete and the transaction ordering is determined. For example, a protocol could use timed encryption, making block contents invisible until a deadline, or threshold encryption, where a committee decrypts the block only after it is finalized.
This means a node might abuse information from transactions submitted directly to it, but the rest of the network learns the transaction contents only after the fact. By the time transaction information is public to the entire network, its ordering and confirmation are already settled, preventing others from front-running. This definition works under the premise that there are multiple nodes capable of including transactions per slot.
We do not adopt a stronger privacy definition (like an encrypted mempool)—where only the user knows the transaction—because the protocol needs to filter spam. If transaction contents were completely hidden from the entire network, the network couldn't distinguish spam from valid transactions. The only solution would be to leak some unencrypted metadata, like a payment address that gets charged regardless of transaction validity. But such metadata could leak enough information for an attacker to exploit. Therefore, we choose a middle ground: only a single node sees the transaction content, while the rest of the network does not. This also implies users must have at least one honest node as an entry point per slot.
A protocol possessing both short-term censorship resistance and hiding is an ideal foundation for building financial applications. Returning to the on-chain auction example, these two properties directly prevent Bob's two ways of breaking the market: he cannot censor Alice's bid, nor can he use her bid to guide his own actions, perfectly solving the two problems outlined earlier.
With short-term censorship resistance, any transaction—be it an order update or an auction bid—is guaranteed immediate inclusion. Market makers can modify orders, bidders can place bids quickly, and liquidations can be executed efficiently. Users can be confident their actions will be executed immediately, enabling a new generation of low-latency, real-world-facing financial applications to be built entirely on-chain.
For blockchains to truly compete with and surpass existing financial infrastructure, solving for more than just throughput is essential.