a16z: DeFi Struggling to Support a True Financial Market

Original Title: Enabling the future of onchain markets: The role of predictability
Original Authors: @PGarimidi, @jneu_net, @MaxResnick, a16z
Translation: Peggy, BlockBeats

Editor's Note: As blockchain performance continues to improve, the industry's focus is shifting from "how many transactions can be processed" to "when transactions get confirmed." Long seen as just throughput (TPS), performance for financial systems is more about the predictability of transactions — i.e., once a transaction is submitted, can it be promptly and reliably included in a block.

This article points out that most blockchains currently offer only the assurance of "eventually getting on-chain" without control over time. This second-level uncertainty may be acceptable in payment scenarios, but in financial transactions requiring millisecond-level responses, it directly leads to price degradation, arbitrage opportunities, and fairness issues, undermining the competitiveness of on-chain markets.

Furthermore, this issue stems from the underlying mechanism: in a single leader block production structure, transaction ordering and inclusion rights are highly centralized, making it prone to risks like censorship, delays, and information asymmetry.

In light of this, the authors propose two directions: providing short-term, predictable transaction inclusion guarantees and introducing information hiding mechanisms pre-confirmation to reduce front-running and adverse selection. In conclusion, for blockchain to truly become financial infrastructure, what is more important than throughput is the determinism and fairness of transaction execution.

Below is the original article:

Blockchain can now confidently claim that its capacity is sufficient to compete with existing financial infrastructure. The current production system can handle tens of thousands of transactions per second, with orders of magnitude increases foreseeable in the near future.

However, compared to mere throughput capacity, financial applications require predictability. Whether it's matching trades, participating in auctions, or exercising options, when a transaction is sent, the system must reliably guarantee when that transaction will be confirmed on-chain, which is crucial for the normal operation of the financial system. Once transaction confirmation encounters uncertain delays (whether from adversarial actions or incidental factors), many applications will lose availability.

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 a block in as short a time as possible.

Take the on-chain order book as an example. An efficient order book relies on market makers continuously providing liquidity by constantly placing buy and sell orders to keep the market functioning. The core issue market makers face is to minimize the buy/sell spread while avoiding adverse selection risks due to price deviations from the market.

Therefore, a liquidity provider must consistently update orders to reflect changes in market conditions. For example, when the Federal Reserve makes an announcement that causes asset price fluctuations, the liquidity provider needs to adjust their quotes immediately. If these trades used to update orders cannot be settled on-chain instantly, they may be executed by arbitrageurs at stale prices, resulting in losses. As a result, the liquidity provider has to widen the spread to reduce risk exposure, thereby weakening the on-chain exchange's competitiveness.

It is precisely the predictable inclusion of trades in blocks that gives liquidity providers the ability to rapidly respond to on-chain events, thus maintaining on-chain market efficiency.

What We Have vs. What We Need

Currently, most blockchains only provide strong assurances for finality, a process that typically occurs within a few seconds. While this is sufficient for payment-related applications, it remains too fragile for financial applications that require real-time responses from multiple participants.

Continuing with the example of an order book: if a liquidity provider can only secure a guarantee of "will be included in a block in the next few seconds," while an arbitrageur's trade could make it into an earlier block, this guarantee becomes meaningless. Without strong inclusive assurances, the liquidity provider can only hedge the increased adverse selection risk by widening the spread, resulting in users getting worse trade prices. This also makes on-chain transactions significantly less attractive compared to venues that provide stronger execution certainty.

If blockchains are to truly realize their vision as modern capital market infrastructure, developers must address these issues so that high-value financial applications like order books can truly thrive on-chain and remain competitive.

Why Is Achieving "Predictability" So Challenging?

Enhancing transaction inclusivity guarantees on existing blockchains to support these application scenarios is an extremely challenging task. Some protocols currently rely on a single node (the "leader") to decide at any moment which transactions can be included in a block. While this mechanism simplifies the engineering of high-performance blockchains, it also introduces a potential economic bottleneck: these leaders can extract value. Typically, within a time window where a node is chosen as a leader, it has complete control over which transactions are included in the block.

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

In a permissionless network, leaders naturally have incentives for value extraction, often referred to as Miner Extractable Value (MEV). MEV extends far beyond sandwich attacks on AMM trades. Even just delaying the inclusion of transactions by a few tens of milliseconds can lead to significant profits while undermining the efficiency of the underlying application. An order book that prioritizes processing orders from select traders places other participants in an unfair competitive environment. In the most extreme cases, leaders may even exhibit strong adversarial behavior, causing traders to abandon the platform altogether.

Imagine this scenario: If a rate hike occurs, ETH's price instantly drops by 5%. All market makers on the order book will promptly cancel their existing orders and place new orders at a new price; meanwhile, arbitrageurs will submit sell orders to take advantage of these outdated orders. If this order book runs on a single leader's protocol, the leader will hold significant power. The leader can directly choose to review all market makers' order cancellations, allowing arbitrageurs to make huge profits; or, even without full review, the leader can delay the on-chain time of cancellations, waiting for arbitrageurs' transactions to be prioritized in blocks; furthermore, the leader can even insert their own arbitrage trades, fully exploiting this price discrepancy.

Two Key Objectives: Censorship Resistance and Information Hiding

In this power structure, market makers will lose the economic incentive to participate; every time the price changes, they are at risk of systematic "harvesting." The crux of the issue is that the leader has excessive privilege in two aspects:

1) The leader can review others' transactions;

2) The leader can see others' transaction content and adjust their own transaction behavior accordingly.

Either of these two points could have catastrophic consequences.

Case Study

We can further illustrate the issue with a simple example. Consider an auction scenario with only two bidders: Alice and Bob, where Bob is also the leader of that block. (This two-bidder scenario is used here for illustrative purposes; the issue applies to any number of participants.)

The auction takes place within a time window of a block, 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). As Bob is the leader of the block, he can ensure that he always places the final bid.

Simultaneously, Alice and Bob can continuously access the real-time price of an asset (e.g., the mid-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. In other words, at any moment, both parties' expectations of the final price are equal to the price currently observed. The auction rules are simple: whoever bids higher wins and pays their bid.

The Necessity of Censorship Resistance

First, consider how Bob can leverage his leader advantage. If Bob can review Alice's bid, the auction mechanism will be directly compromised. Bob only needs to submit a very low bid to win the auction without competition. This would result in almost zero auction revenue.

The Importance of Information Hiding

A more complex scenario is this: Bob is unable to inspect Alice’s bid but can see Alice’s bid before making his own bid. In this case, Bob’s strategy is straightforward: when he places a bid, he simply checks if ptB is greater than bA. If it is, he bids slightly higher than bA; if not, he does not participate in the bidding.

With this strategy, Bob puts Alice in a disadvantageous position. Only when the market price changes such that Alice’s bid exceeds the asset’s expected value will she win the auction. However, in this case, she is actually at a loss, so the rational choice is not to participate in the auction. Once other bidders drop out, Bob can then win the auction again with a very low price, driving the auction revenue close to zero.

Key Conclusion

The key conclusion of this example is that the duration of the auction is not crucial. As long as Bob can inspect Alice’s bid or see Alice’s bid before he places his own bid, the auction mechanism is destined to fail.

The same principle applies to all high-frequency trading scenarios—whether it is spot trading, perpetual contracts, or derivatives trading. If there exists a leader with the power described above, that leader has the ability to collapse the entire market structure. Therefore, if on-chain products wish to be viable in these scenarios, they must avoid granting such power to a leader.

How Do These Issues Manifest in Reality?

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

In practice, two forces have to some extent mitigated the above issues: first, leaders have not fully leveraged their economic power because they usually have deep interests aligned with the long-term success of the underlying chain; second, the application layer has reduced its sensitivity to these issues through various "workarounds."

Although these two points have to some extent sustained the current operation of decentralized finance (DeFi), they are not sufficient to enable on-chain markets to genuinely compete with off-chain markets in the long term.

To be a leader on-chain with actual economic activity, one typically needs to hold a significant stake. Therefore, either the node itself holds a large amount of tokens, or its reputation is strong enough that other token holders are willing to delegate stake to it. In both cases, large node operators are usually well-known entities with reputations at stake. Furthermore, this staking itself implies that they have an economic incentive to drive the chain’s long-term development. Therefore, we have not yet widely seen leaders abusing their market power as described earlier—but that does not mean the problem does not exist.

First, relying solely on node operators' "good behavior," social pressure, and consideration of long-term interests cannot form a solid foundation for the future financial system. As on-chain financial activities scale up, leaders can extract increasing potential gains. The greater the potential gains, the harder it is to rely on societal constraints to deter them from pursuing short-term gains.

Second, the extent to which leaders leverage their market power is a continuous spectrum, ranging from almost benign to sufficient to completely undermine the market. Node operators can gradually push the boundaries of "acceptable behavior" to earn higher rewards. Once some nodes attempt to exploit this space, other nodes quickly follow suit. While the behavior of a single node may seem limited in its impact, when collective behavior changes, the impact is significant.

A typical example is the so-called "timing games": leaders may delay block publication as much as possible while still ensuring block validity to earn higher rewards. This behavior leads to block time extension and may even result in blocks being skipped when overly aggressive. Although the profitability of these strategies has long been known, node operators in the past have typically chosen not to adopt them out of consideration for "maintaining network health." However, this is a fragile social equilibrium. Once a node starts using these strategies, earns higher rewards without being penalized, other nodes quickly emulate. "Timing games" are just one example; leaders have various ways to increase their own rewards without fully abusing power, often at the expense of the application layer. Individually, these behaviors may be tolerable, but when they accumulate to a certain extent, the cost of running the chain will outweigh the benefits.

Another key factor in maintaining DeFi operation is for the application layer to migrate critical logic off-chain and only put the results on-chain. For example, any protocol that requires swift auction execution usually conducts the auction off-chain. These applications often rely on a set of permissioned nodes to operate key mechanisms to mitigate risks from adversarial leaders. For instance, Uniswap's UniswapX conducts Dutch auctions off-chain on the Ethereum mainnet to complete trade matching. Similarly, CowSwap also performs batch auctions off-chain. While these solutions are effective at the application layer, they make the underlying layer's value proposition fragile. If the execution logic of applications is all moved off-chain, the underlying blockchain will merely serve as a settlement layer. One of DeFi's most core selling points—composability—will also be weakened. In a world where all execution takes place off-chain, various applications will naturally exist in isolated environments. Furthermore, relying on off-chain execution will introduce new trust assumptions: not only does the underlying blockchain need to remain operational, but the off-chain infrastructure must also be stable and available.

How to Achieve "Predictability"

To address the above issues, the protocol needs to satisfy two key properties: consistent transaction inclusion with ordering rules, and pre-confirmation transaction privacy (a more detailed definition can be found in the relevant papers).

Objective One: 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 ensured that it will be included in the next mineable block.

More specifically, one can assume the protocol operates on a fixed clock, for example, generating a block every 100ms. Therefore, if a transaction is received by some honest node at t=250ms, it must be included in the block generated at t=300ms. Attackers should not have the freedom to selectively include some transactions and exclude others. The core spirit of this definition is that users and applications must be able to submit transactions to the chain in a highly reliable manner at any given time. There should be no situation where a transaction cannot get on-chain due to a node dropping it (whether intentionally or accidentally).

Although this definition requires that "any honest node" can ensure transaction inclusion, in practice, the cost of achieving this may be too high. More importantly, the protocol should have enough robustness to make the path of transactions entering the chain highly predictable. Obviously, a permissionless single leader protocol cannot meet this requirement because once the current leader exhibits Byzantine behavior, transactions will not be able to get on-chain. However, even if a small number of nodes (e.g., four nodes) collectively ensure transaction inclusion for each time slot, it can significantly enhance the on-chain options for users and applications. In order for the applications to truly thrive, it is worth making some performance trade-offs. The optimal balance between robustness and performance still needs to be further explored, but the existing protocol's guarantees are clearly insufficient.

Once the protocol can ensure transaction inclusion, the ordering problem is somewhat solved. The protocol can adopt any deterministic ordering rule to ensure consistency, such as fee priority sorting, or allow applications to customize the ordering of transactions related to their state. Although the optimal sorting method is still an active research problem, the prerequisite always remains that transactions must be successfully included first.

Objective Two: Hiding

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

It is defined as: before a transaction is finally confirmed and included in a block, no other party apart from the receiving node can obtain information about that transaction.

In a privacy-preserving protocol, a node can see the plaintext of transactions sent to itself, but the rest of the network remains unaware of the transaction content until consensus is reached and transaction order is finalized. For example, this can be achieved through time-lock encryption, making block content undecryptable until a certain point in time, or through threshold encryption, where the block is uniformly decrypted after a committee confirms its irreversibility.

This means that even though a receiving node of a transaction may abuse its information, other nodes in the network do not know the transaction content during the consensus process. Once transaction information is revealed, its order is settled and immutable, preventing front-running. To make this mechanism effective, the protocol needs to support transactions being received and included on-chain by multiple nodes in the same slot.

We have not adopted a stronger privacy model (such as a fully encrypted mempool visible only to the user) because the protocol needs to be able to filter out spam transactions. If transaction content is entirely hidden from the network, distinguishing between valid and spam transactions would not be possible. The only alternative is to leak some metadata (such as the address paying the fee), but such information could also be exploited by attackers. Therefore, a more practical design is to allow a single node to fully view transaction content while preventing other nodes in the network from accessing any information until confirmation. This also means that to uphold this property, users need at least one honest node as a transaction gateway in each slot.

A protocol that possesses both "short-term censorship resistance" and "privacy" would provide an ideal foundation for building financial applications. Referring back to the previous auction example, these two properties precisely eliminate the two abilities Bob has to disrupt the market: he cannot inspect Alice's bid and cannot obtain her information before the bid, fundamentally solving the issue.

With short-term censorship resistance, under any submitted transaction—whether matching, bidding, or settling—can be instantly included. Market makers can adjust orders in real-time, bidders can quickly bid, and settlements can be executed efficiently. Users can have confidence 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 make blockchain truly compete with and even surpass existing financial infrastructure, merely increasing throughput is far from sufficient.

[Original Article Link]