Blockchains are fast enough for finance. Now what?

We need to solve much more than throughput to truly compete with existing financial infrastructure.

Blockchains can now credibly claim to have the capacity required to compete with existing financial infrastructure. Production systems today can process tens of thousands of transactions per second, with orders of magnitude improvement on the horizon.

Beyond raw throughput, though, financial applications need predictability. When a transaction is sent — whether it’s a trade, an auction bid, or exercising an option — having a reliable guarantee on when that transaction will land is necessary to the functioning of financial systems. If transactions face unpredictable delays (whether adversarial or by happenstance) many applications become unusable. For onchain financial applications to be competitive, the chain must have short-term inclusion guarantees, where if a valid transaction is submitted to the network, it is guaranteed to be included as soon as possible.

For example, consider an onchain order book. Efficient order books require market makers to continuously provide liquidity by maintaining orders to buy and sell the assets on the book. The key problem market makers deal with is maintaining as tight a spread (the difference between their buy and sell prices) as possible while not opening themselves up to adverse selection by offering prices out of line with the rest of the market. To do this, market makers must constantly update their orders to reflect the state of the world. For instance, if a Federal Reserve announcement causes asset prices to jump, market makers need to instantly respond by updating their orders to the new price. Here, if a market maker’s transactions to update their orders don’t land instantly, they’ll take a loss by having arbitrageurs fill their orders at out-of-date prices. Market makers would then need to post larger spreads to decrease their exposure to such events, in turn making onchain venues less competitive.

Predictable transaction inclusion is what gives market makers strong guarantees on their ability to quickly react to offchain events and keep onchain markets efficient.

What we have versus what we need

Today, existing chains offer only robust guarantees of eventual inclusion, kicking in over the span of seconds. While these guarantees are good enough for applications like payments, they are too weak to support a large class of financial applications where market participants need to react to information in real time. Take the order book example above: For market makers, a guarantee that they will be included “in the next few seconds” is meaningless if arbitrageurs’ transactions can land in earlier blocks. Without strong inclusion guarantees, market makers have to account for the increased amount of adverse selection by widening their spreads and offering users worse prices. This in turn makes trading onchain less appealing compared to other venues that do offer stronger guarantees.

For blockchains to truly fulfill the vision of serving as the infrastructure to modernize capital markets, builders need to address these issues so that high-value applications like order books can thrive.

What is so hard about predictability?

Strengthening the inclusion guarantee for existing chains to support these use cases is challenging. Some protocols today may rely on one node (a “leader”) that can dictate transaction inclusion at any given time. While this simplifies the engineering challenge of building a performant chain, it also introduces a potential economic chokepoint where those leaders can extract value. Generally, for the window in which a node is elected as leader, they have complete power over what transactions are included in a block.

For a chain that handles any amount of financial activity, the leader holds a privileged position. If this single leader decides to not include any one transaction, the only recourse is to wait for the next leader that is willing to include that transaction. In a permissionless network, leaders are incentivized to extract value, colloquially known as MEV. MEV goes well beyond things like sandwiching AMM trades. Even just a leader’s ability to delay transaction inclusion by 10s of milliseconds could net them a large profit and degrade the efficiency of the underlying applications. An order book that prioritizes only a subset of traders’ transactions leaves everyone else on an unfair playing field. In the worst case, the leader can be so adversarial that traders leave the platform altogether.

Say there is a rate hike and the price of ETH immediately falls by 5%. Every market maker on an order book rushes to cancel their resting orders and to make new orders at the new prices. At the same time, every arbitrageur submits an order to sell ETH at the outdated standing orders. If this order book is being run on a protocol with a single leader, the leader has an outstanding amount of power. The leader could simply choose to censor all of the market maker cancels, thus allowing the arbitrageurs to massively profit. Or instead of outright censoring the cancels, the leader could delay the cancels until after the arbitrageurs land their transactions. The leader could even directly insert their own arbitrage transactions to fully capitalize on the price discrepancy.

A tale of two desiderata: The need for censorship resistance and hiding

In the face of these advantages, it becomes uneconomical for market makers to actively participate; whenever there is a price movement they might be taken advantage of. The issue boils down to the leader being overly privileged in two key ways: 1) The leader can censor transactions by anyone else, and 2) the leader can see others’ transactions and submit their own transactions accordingly in response. Either of these two issues can turn out to be catastrophic.

An example

We can nail down the issue precisely with the following example. Consider an auction that has two bidders, Alice and Bob, where Bob is also the leader for the block the auction happens in. (The fact that there are only two bidders is for illustrative purposes; the same reasoning applies regardless of how many bidders there are.)

The auction accepts bids over the duration it takes for the block to be produced, say from time t=0, to t=1. Alice submits a bid b_A at time t_A and Bob submits a bid b_B at time t_B > t_A. Since Bob is the leader for the block, he can always guarantee he moves last. Alice and Bob also have a continuously updating source of truth for the price of the asset that they can read from (e.g., the mid-point price on a centralized exchange). At time t, let this price be p_t. We assume that at time t, the expected price of the asset at time t=1 (when the auction concludes) is always p_t. That is, at any given time, the price both Alice and Bob expect the asset to be at when the auction concludes is equal to the price they currently see. The rules of the auction are simple: whoever has the higher bid out of Alice and Bob wins the auction and pays their bid.

The need for censorship resistance

Now let’s consider what happens when Bob can use his advantage from being the leader in this auction. If Bob can censor Alice’s bid, it’s clear that the auction falls apart. Bob can simply bid an arbitrarily small amount and be guaranteed to win the auction since there are no other bids. This causes the auction to clear with effectively 0 revenue.

The need for hiding

The more complicated case is what happens when Bob can’t outright censor Alice’s bid but can still see Alice’s bid before making a bid of his own. In this case, Bob has a simple strategy. When he bids, he simply checks whether p_tB > b_A. If so then Bob bids an amount just above b_A and if not then Bob doesn’t bid at all. By playing this strategy, Bob causes Alice to be adversely selected against. The only time Alice wins is when the price updates so that her bid ends up being higher than the expected value of the asset. Whenever Alice wins the auction, she would expect to lose money and be better off not participating in the auction at all. With all competing bidders gone, Bob can again simply bid an arbitrarily small amount and win with the auction getting effectively 0 revenue.

The key takeaway here is that it does not matter how long this auction takes. As long as Bob can either censor Alice’s bid or see Alice’s bid before he makes his own bid, the auction is doomed to fail.

The same principles from this example apply to any setting where assets are being traded at high frequency, whether that be spot trading, perps, or a derivatives exchange: If there is a leader with the power Bob has in this example, that leader can cause the market to fully unravel. For the onchain products serving these use cases to be viable, they must not grant the leader these powers.

How do these issues arise in practice today?

The story above paints a bleak picture for onchain trading on any permissionless single leader protocol. Nevertheless, decentralized exchange (DEX) volumes on many single leader protocols continue to be healthy, so what gives?

A combination of two forces in practice counteract the issues described above:

1. Leaders don’t fully exploit their economic power as they themselves are generally heavily invested in the success of the underlying chain, and

2. Applications have built workarounds to not be as vulnerable to these issues.

While these two factors have kept decentralized finance (DeFi) working so far, they will not be enough for onchain markets to truly be competitive with their offchain counterparts in the long run.

To be eligible as a leader on a chain with meaningful economic activity requires a large amount of stake. Thus either the leader owns a lot of stake themselves or has enough of a reputation for other token holders to delegate stake to them. In either case, large node operators are generally known entities with reputations at risk. Beyond just their reputation, this stake means these operators also have financial incentives for their chains to do well. Because of this, we largely haven’t seen leaders fully exploit their market power as written above — this doesn’t mean these issues aren’t a problem though.

For one, being reliant on node operators’ goodwill through social pressure and appealing to their long-term incentives isn’t a robust foundation for the future of finance. As the magnitude of onchain financial activity increases, the potential profits for leaders increases accordingly. The more this potential grows, the harder the strain on the social layer to keep leaders’ behavior against their immediate interests.

Second, the extent to which leaders can use their market power is a spectrum, from the benign to causing the market to fully unravel. Node operators can make unilateral pushes towards exploiting their power for higher profits. As some operators push the limits of what is considered acceptable, others quickly follow suit. An individual node’s behavior may seem insignificant, but when everyone changes, the impact is unmistakable.

Perhaps the best example of this phenomenon is with timing games: When leaders look to delay announcing a block until as late as possible while still being valid for the protocol to earn higher rewards. This can cause longer block times and blocks to be skipped when a leader is too aggressive. While the profitability of these strategies was widely known, leaders opted against playing these games primarily in the name of being good stewards of the chain. However, this was a weak social equilibrium. Once a single node operator started playing these strategies to earn higher rewards with no consequences, other operators quickly joined in. Timing games are just one example of how leaders can increase their profits without fully exploiting their market power. There are many other measures leaders can take to increase their rewards at the expense of applications. In isolation, these measures may be workable for applications, but eventually the scale tips to a point where the costs of being onchain outweigh the benefits.

The other factor that has kept DeFi functional is applications moving important logic offchain and only posting the results onchain. For instance, any protocol that needs to quickly run an auction does so offchain. These applications often run their required mechanisms on a permissioned set of nodes to avoid issues with adversarial leaders. For example, UniswapX runs its Dutch auction to fill trades on Ethereum mainnet offchain and similarly Cowswap runs its batch auction offchain. While this works for the applications, it puts the base layer and the value proposition of building onchain in a precarious position. A world where the execution logic for applications lives offchain makes the base layer purely used for settlement. One of the strongest selling points for DeFi is composability. In a world where all execution happens offchain, these applications inherently live in siloed environments. Relying on offchain execution also adds new assumptions to the trust models of these applications. Rather than just relying on the underlying chain to be live, this offchain infrastructure must also be up for the apps to function.

How to get predictability

To address these issues, there are two properties we need the protocol to satisfy: consistent transaction inclusion and ordering rules and transaction privacy before confirmation (For a rigorous definition of these properties and an extended discussion see https://arxiv.org/abs/2509.23984, esp. Definitions 9 and 11).

Desideratum #1: Censorship resistance

We encapsulate the first property by short-term censorship resistance. Where a protocol is short-term censorship resistant if any transaction that reaches an honest node is guaranteed to be included in the next possible block:

Short-Term Censorship Resistance: Any valid transaction that reaches any honest node on time will certainly be included in that next possible block.

More precisely, we assume that the protocol operates on a fixed clock where every block is produced at set times, say every 100ms. Then we want the guarantee that if a transaction hits an honest node at t=250ms, it will be included in the block produced at t=300ms. An adversary should not have the discretion to selectively include certain transactions it hears about and leave out others. The spirit of this definition is that users and applications should have an extremely reliable way to land transactions at any point in time. It shouldn’t be the case that a single node happening to drop packets, whether due to malice or simple operational hiccups, causes a trade to not land.

While this definition requires inclusion guarantees for transactions reaching any honest node, in practice the overhead of achieving this may be too high. The important feature is that the protocol should be robust so that the entry points to land onchain behave in extremely predictable ways that are simple to reason about.

A permissionless single leader protocol clearly does not satisfy this property, because if the single leader at any point in time is Byzantine, there’s no other way to land a transaction. However, even a set of four nodes who can guarantee transaction inclusion in every slot greatly improves the amount of options users and applications have to land transactions. It’s worth it to trade off some amount of performance for a protocol that can reliably allow applications to thrive. There’s more work to be done on finding the right tradeoff between robustness and performance, but the guarantees from existing protocols aren’t enough.

Given that a protocol can guarantee inclusion, ordering comes somewhat for free. Protocols are free to use any deterministic ordering rule they like to guarantee consistent ordering. The simplest solution is to order by priority fee or perhaps to allow applications the flexibility to order transactions that interact with their state. The optimal way to order transactions is still an active area of research, but regardless, ordering rules only matter if the transactions to be ordered land.

Desideratum #2: Hiding

After short-term censorship resistance, the next most important property is for a protocol to provide a form of privacy we term hiding.

Hiding: No party, except for the node that a transaction is submitted to, learns any information about a transaction before its inclusion has been finalized by the protocol.

A protocol that is hiding, may allow for the nodes to see all the transactions submitted to them in plain text but requires the rest of the protocol to be blind until consensus is finished and the transaction’s order in the finalized log is already determined. For example the protocol might use timelock encryption so that the entire content of a block is hidden until a certain deadline; or a protocol might use threshold encryption so that the block is decrypted once a committee agrees that it is irreversibly confirmed.

This means that a node may abuse the information from any transaction submitted to them, but the rest of the protocol doesn’t know the contents of what they’re coming to consensus upon until after the fact. By the time transaction information is revealed to the rest of the network, the transaction has already been ordered and confirmed, so no other party can front-run it. For this definition to be useful, this does mean that multiple nodes can land transactions in any given slot.

The reason we forgo the stronger notion where only the user knows anything about their transaction before it is confirmed (e.g., as in encrypted mempools) is that the protocol needs some step to act as a filter for spam transactions. If transaction contents are fully hidden to the entire network, then the network has no way of filtering garbage transactions from meaningful transactions. The only way around this is to leak some unhidden metadata as part of transactions such as a fee payer address that gets charged regardless of a transaction’s validity. However, this metadata may leak enough information for an adversary to take advantage of. Thus we prefer that a single node has full visibility of the transaction, but no other nodes in the network have any visibility of it. This does mean, however, for this property to be useful it’s required for a user to have at least one honest node as an entrypoint to land a transaction every slot.

***

A protocol that is both short-term censorship resistant and hiding provides the ideal base to build financial applications. Going back to our example of trying to run an auction onchain, these two properties directly address the ways Bob could cause the market to unravel. Bob can neither censor Alice’s bid nor use Alice’s bid to inform his own, exactly addressing issues 1) and 2) from our example before. (For more details, see this recent preprint.)

With short-term censorship resistance, anyone submitting a transaction whether it be a trade or an auction bid is guaranteed instantaneous inclusion. Market makers can change their orders; bidders can quickly place bids; liquidations can land efficiently. Users can be sure that any action they take will be immediately executed. This in turn will allow the next generation of low-latency real-world financial applications to be built fully onchain. For blockchains to truly compete with — and exceed the performance of — existing financial infrastructure, we need to solve much more than just throughput.

---

You’re receiving this newsletter because you signed up for it on our websites, at an event, or elsewhere (you can opt out anytime using the ‘unsubscribe’ link below). This newsletter is provided for informational purposes only, and should NOT be relied upon as legal, business, investment, or tax advice. This newsletter may link to other websites or other information obtained from third-party sources — a16z has not independently verified nor makes any representations about the current or enduring accuracy of such information. Furthermore, the content is not directed at nor intended for use by any investors or prospective investors in any a16z funds. Please see a16z.com/disclosures for additional important details, including link to list of investments.