Original title: Enabling the future of onchain markets: The role of predictability
Original authors: @PGarimidi, @jneu_net, @MaxResnick, a16z
Compiled by: Peggy, BlockBeats

Editor's Note: As blockchain performance continues to improve, the focus of industry discussions is shifting from "how many transactions can be processed" to "when will transactions be confirmed." For a long time, performance has been simplified to throughput (TPS), but for financial systems, what is more critical is the predictability of transactions, that is, whether a transaction can be included in a block in a timely and reliable manner after it is submitted.

This article points out that most blockchains currently only provide a guarantee that the data will eventually be uploaded to the blockchain, but the timing is uncontrollable. This second-level uncertainty is acceptable in payment scenarios, but in financial transactions that require millisecond-level responses, it will directly lead to price degradation, arbitrage opportunities, and unfairness, weakening the competitiveness of the on-chain market.

Looking further, this problem stems from the underlying mechanism: under a block-producing structure with a single leader, the ordering and inclusion rights of transactions are highly centralized, which can easily lead to risks such as censorship, delays, and information asymmetry.

Based on this, the author proposes two directions: first, to provide short-term, predictable transaction security; and second, to introduce an information hiding mechanism before confirmation to reduce front-running and adverse selection. In short, for blockchain to truly become a financial infrastructure, the certainty and fairness of transaction execution are more important than throughput.

The following is the original text:

Blockchain can now confidently claim that its capacity is sufficient to compete with existing financial infrastructure. Current production systems can already handle tens of thousands of transactions per second, and this is expected to increase by orders of magnitude in the foreseeable future.

However, compared to mere throughput capacity, financial applications require predictability even more. Whether it's matching transactions, participating in auctions, or exercising options, once a transaction is sent, the system must be able to reliably guarantee when the transaction will be confirmed and recorded on the blockchain. This is crucial for the normal operation of the financial system. Once there is uncertainty or delay in transaction confirmation (whether from adversarial behavior or unforeseen factors), many applications will become unavailable.

Therefore, for on-chain financial applications to be competitive, the underlying blockchain must provide short-term inclusion guarantees: once a valid transaction is submitted to the network, it should be included in the block in the shortest possible time.

Take an on-chain order book as an example. An efficient order book relies on market makers to continuously provide liquidity, maintaining market operation by constantly posting buy and sell orders. The core challenge for market makers is to minimize the bid-ask spread (i.e., the difference between buy and sell quotes) while avoiding adverse selection risk due to quotes deviating from the market.

Therefore, market makers must continuously update their orders to reflect changes in market conditions. For example, when a Federal Reserve announcement causes asset price fluctuations, market makers need to adjust their quotes immediately. If these transactions used to update orders are not recorded on the blockchain in a timely manner, they may be executed by arbitrageurs at outdated prices, resulting in losses. Consequently, market makers are forced to widen spreads to reduce risk exposure, thereby weakening the competitiveness of on-chain trading venues.

It is precisely this predictable inclusion of transactions into the block that gives market makers the ability to respond quickly to off-chain events, thereby maintaining the efficiency of the on-chain market.

What we already have, and what we truly need.

Currently, most blockchains only offer a strong guarantee that the data will eventually be written to, a process that typically occurs within seconds. While this is sufficient for payment applications, it remains too weak for the many financial applications that require real-time responses from participants.

Continuing with the order book example: if market makers only receive a guarantee that their trades will be written into a block within the next few seconds, while arbitrageurs' trades might be written into an earlier block, then this guarantee is essentially meaningless. Without strong inclusion guarantees, market makers can only hedge against increased adverse choice risk by widening spreads, thus resulting in worse trading prices for users. This also significantly reduces the attractiveness of on-chain transactions compared to venues offering stronger execution certainty.

If blockchain is to truly realize its vision as the infrastructure of modern capital markets, developers must address these issues to enable high-value financial applications such as order books to truly grow and become competitive on the chain.

Why is it so difficult to achieve "predictability"?

Strengthening transaction inclusion guarantees on existing blockchains to support these application scenarios is inherently a challenging task. Some protocols currently rely on a single node (i.e., the "leader") deciding at any given time which transactions can be included in a block. While this mechanism simplifies the engineering of building high-performance blockchains, it also introduces a potential economic bottleneck: these leaders can extract value from it. Typically, during the time window in which a node is elected as leader, it has complete control over which transactions are included in a block.

For any blockchain that hosts financial activities, the leader holds a privileged position. If a single leader decides not to include a transaction, the only recourse is to wait for the next leader to be willing to include it.

In a permissionless network, leaders are naturally incentivized to extract value, a practice often referred to as Mean Value Exploitation (MEV). MEV goes far beyond simply performing pinch attacks on AMM (Authorized Market Maker) transactions. Even delaying transaction execution by just a few tens of milliseconds can generate substantial profits while simultaneously degrading the efficiency of the underlying application. An order book that prioritizes only a subset of traders' orders creates an unfair competitive environment for other participants. In the most extreme cases, leaders may even exhibit strong antagonism, causing traders to abandon the platform altogether.

Imagine this scenario: if an interest rate hike occurs, the price of ETH instantly drops by 5%. All market makers on the order book will quickly cancel their existing orders and re-list them at the new price; simultaneously, arbitrageurs will submit sell orders, absorbing these unupdated orders at the old price. If this order book operates on a single-leader protocol, the leader will possess immense power. The leader can directly vet all market maker order cancellations, allowing arbitrageurs to reap huge profits; or, even without complete vetting, can delay the on-chain processing of cancellations, allowing arbitrageurs' trades to be packaged first; even the leader can insert its own arbitrage trades, fully exploiting this price mismatch.

Two key objectives: censorship resistance and information hiding

Under this power structure, market makers lose their economic incentive to participate; they are vulnerable to being systematically "harvested" whenever prices change. The crux of the problem lies in the excessive privileges enjoyed by leaders in two areas:

1) Leaders can review the transactions of others;

2) Leaders can see the trading activities of others and adjust their own trading behavior accordingly.

Either of these two points could have disastrous consequences.

Case

We can illustrate the problem more precisely with a simple example. Imagine an auction scenario with only two bidders: Alice and Bob, where Bob is also the leader of the block. (The two bidders are used here for illustrative purposes only; in reality, this applies to any number of participants.)

The auction takes place within a block generation time window, for example, from time 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 leader of the block, he can ensure that he always bids last.

Meanwhile, both Alice and Bob can continuously obtain the real-time price of an asset (e.g., the median price from a centralized exchange). At any time t, this price is denoted as pt. We assume that at time t, the market's expectation of the price at t=1 (the end of the auction) is always equal to pt. That is, at any given moment, both parties' expectations of the final price are equal to the currently observed price. The auction rules are simple: whoever bids higher wins and pays their bid.

The necessity of resisting censorship

First, consider how Bob could exploit his leader advantage. If Bob could vet Alice's bids, the auction mechanism would fail entirely. Bob could simply submit a very low bid and win the auction without any competition. This would result in virtually zero auction revenue.

The necessity of information hiding

A more complex situation arises: Bob cannot review Alice's bids, but he can see Alice's bids before he makes his own. In this case, Bob's strategy is very simple: when he bids, he only needs to determine if ptB is greater than bA. If so, he bids a price slightly higher than bA; otherwise, he does not participate in the bidding.

Through this strategy, Bob creates an unfavorable choice for Alice. She only wins the auction if the market price changes, causing her bid to exceed the asset's expected value. However, in this scenario, she is actually losing money, so the rational choice is not to participate. Once other bidders withdraw, Bob can win the auction again at an extremely low price, bringing his auction revenue close to zero.

Key conclusions

The key takeaway from this example is that the length of the auction is irrelevant. As long as Bob can review Alice's bids, or sees Alice's bids before he makes his own, the auction is destined to fail.

The same principle applies to all high-frequency trading scenarios—whether spot trading, perpetual contracts, or derivatives trading. If a leader possesses the aforementioned power, that leader has the ability to collapse the entire market structure. Therefore, if on-chain products are to be viable in these scenarios, they must avoid granting such power to leaders.

How do these problems arise in reality?

The above analysis paints a rather pessimistic picture: on-chain transactions on any permissionless, single-leader protocol will face structural problems. However, the reality is that many decentralized exchanges (DEXs) on such protocols still maintain active trading volumes. What are the reasons behind this?

In practice, two forces have mitigated the aforementioned problems to some extent: First, leaders do not fully utilize their economic power because they typically have a deep vested interest in the long-term success of the underlying blockchain; second, the application layer reduces its sensitivity to these issues through various "workarounds".

While these two factors have sustained the current operation of decentralized finance (DeFi) to some extent, they are insufficient in the long run for on-chain markets to truly compete with off-chain markets.

To become a leader on a blockchain with real economic activity, a significant amount of staked tokens is typically required. Therefore, either the node itself holds a large number of tokens, or its reputation is strong enough that other token holders are willing to delegate their stakes to it. In both cases, large node operators are usually well-known and reputable entities whose actions face reputational risk. Furthermore, this staking itself implies an economic incentive for them to drive the long-term development of the blockchain. Therefore, we haven't yet widely witnessed leaders abusing their market power as described above—but this doesn't mean the problem doesn't exist.

First, relying solely on the "goodwill" of node operators, social pressure, and considerations for long-term interests cannot constitute a solid foundation for the future financial system. As the scale of on-chain financial activities expands, the potential benefits that leaders can extract also increase. The greater the potential benefits, the more difficult it becomes to rely on the social layer to constrain their behavior and prevent them from pursuing short-term gains.

Secondly, the extent to which leaders utilize their market power follows a continuous spectrum, ranging from almost harmless to enough to completely disable the market. Node operators can progressively push the boundaries of "acceptable behavior" to gain higher returns. Once some nodes begin to exploit these spaces, other nodes quickly follow suit. The behavior of a single node may seem to have limited impact, but when overall behavior changes, the effect is significant.

A prime example is the so-called "timing games": leaders delay block publication as much as possible while still ensuring block validity, thereby reaping higher rewards. This behavior leads to longer block times and, in overly aggressive cases, even skipped blocks. While the profitability of these strategies has long been known, node operators have historically chosen not to adopt them for the sake of "maintaining network health." However, this is a fragile social equilibrium. Once a node starts using these strategies and reaps higher rewards without penalty, other nodes quickly follow suit. "Timing games" are just one example; leaders have many other ways to increase their rewards without completely abusing their power, often at the expense of the application layer. Individually, these behaviors may be tolerable, but when they accumulate to a certain scale, the costs of running on the chain will outweigh their benefits.

Another crucial factor sustaining DeFi is the migration of critical logic off-chain at the application layer, with only the results recorded on-chain. For example, any protocol requiring rapid auction execution typically conducts the auction process off-chain. These applications often rely on a permissioned set of nodes to run critical mechanisms, mitigating the risks posed by adversarial leaders. For instance, UniswapX executes Dutch auctions off-chain on the Ethereum mainnet to match transactions, and similarly, CowSwap executes bulk auctions off-chain. While this approach is effective at the application layer, it weakens the value proposition of the underlying layer. If application execution logic is moved off-chain, the underlying blockchain becomes merely a settlement layer. One of DeFi's core selling points—composability—is also weakened. In a world where all execution occurs off-chain, applications are inherently isolated. Furthermore, relying on off-chain execution introduces new trust assumptions: not only does the underlying blockchain need to remain operational, but the off-chain infrastructure also needs to be stable and available.

How to achieve "predictability"?

To address the aforementioned issues, the protocol needs to satisfy two key properties: consistent transaction inclusion and ordering rules, and transaction privacy before confirmation (for a more stringent definition, please refer to relevant papers).

Objective 1: Censorship Resistance

We summarize the first property as "short-term censorship resistance". It is defined as follows: as long as a transaction is received by any honest node, it must be guaranteed to be included in the next block that can be generated.

More specifically, we can assume the protocol operates on a fixed clock, for example, generating a block every 100ms. Then, if a transaction is received by a trustworthy node at t=250ms, it must be included in the block generated at t=300ms. Attackers should not have the discretion to selectively include some transactions or exclude others. The core spirit of this definition is that users and applications must be able to reliably submit transactions to the blockchain at any point in time. There should be no situation where a transaction fails to be uploaded to the blockchain due to packet loss at a node (whether malicious or accidental).

While the definition requires that "any honest node" guarantees transaction inclusion, in practice, achieving this can be prohibitively costly. More importantly, the protocol should be robust enough to make the path of transactions onto the chain highly predictable. Clearly, permissionless single-leader protocols cannot meet this requirement, as transactions will fail to reach the chain if the current leader engages in Byzantine behavior. However, even having a small number of nodes (e.g., four nodes) collectively guarantee transaction inclusion for each time slot significantly increases the on-chain options for users and applications. For applications to truly thrive, a certain performance trade-off is worthwhile. Further exploration is needed to find the optimal balance between robustness and performance, but the guarantees provided by existing protocols are clearly insufficient.

Once the protocol can guarantee that transactions are included, the ordering problem is largely solved. The protocol can use any deterministic ordering rule to ensure consistency, such as ordering by priority fee, or allowing applications to customize the ordering of transactions with their associated states. Although the optimal ordering method remains an active research problem, the prerequisite is always that transactions must first be successfully included.

Objective Two: Hiding

After achieving short-term censorship resistance, the next key attribute is "concealment," which is a privacy protection mechanism before transaction confirmation.

It is defined as follows: Before a transaction is finally confirmed and included in a block, no other party besides the node that received the transaction can obtain information about the transaction.

In protocols with hidden features, nodes can see the plaintext of transactions submitted to them, but the rest of the network remains invisible to the transaction content until consensus is reached and the transaction order is finally determined. For example, time-lock encryption can be used to make block content undecryptable before a certain point in time; or threshold encryption can be used to decrypt the block uniformly after the committee confirms that the block is irreversible.

This means that while a node receiving a transaction might misuse its information, other nodes in the network are unaware of the transaction content during the consensus process. Once transaction information is made public, its order is fixed and cannot be changed, thus preventing preemption. For this mechanism to be effective, the protocol needs to support multiple nodes receiving and uploading transactions to the blockchain within the same time slot.

We did not adopt a stronger privacy model (such as a fully encrypted mempool, visible only to the user) because the protocol needs to be able to filter spam transactions. If the transaction content is completely hidden from the entire network, it is impossible to distinguish between valid and spam transactions. The only alternative is to leak some metadata (such as the address used to pay transaction fees), but this type of information can also be exploited by attackers. Therefore, a more realistic design is to allow a single node to see the complete transaction content, but other nodes in the network cannot obtain any information before confirmation. This also means that for this property to hold, a user needs at least one honest node as the transaction entry point in each time slot.

A protocol that simultaneously possesses "short-term censorship resistance" and "anonymity" would provide an ideal foundation for building financial applications. Returning to the auction example mentioned earlier, these two attributes precisely eliminate Bob's two abilities to disrupt the market: he cannot censor Alice's bids, nor can he obtain her information before bidding, thus fundamentally solving the problem.

With short-term censorship resistance, any submitted transaction—whether matching, bidding, or clearing—can be included instantly. Market makers can adjust orders in real time, bidders can place bids quickly, and clearing can be executed efficiently. Users can be assured that any of their actions will be executed immediately. This will enable the next generation of low-latency real-world financial applications to run entirely on-chain.

To enable blockchain to truly compete with, or even surpass, existing financial infrastructure, simply increasing throughput is far from sufficient.

[ Original Link ]