The future is a messy and monstrous multiverse of offchain actors, offchain networks, sidecars, and coprocessors creating a Frankenstein techstack where application logic lives in multiple places instead of just onchain.
Remember when your favorite dApp’s UI went down and you had to go to Etherscan instead to interact with it, today that might not be possible anymore as dApps have more and more offchain logic.
Blockchains represent a globally shared censorship resistant computation layer—an unstoppable computer. A computer that can also run equally unstoppable applications. These applications, when fully onchain, inherit the properties of the base layer chain. The moment any application logic is shifted offchain these properties are lost.
Many applications and blockchains today no longer inherit these unstoppable properties as logic has slowly shifted offchain. a trend that will persist with stateless blockchains. We’ve explored the evolution of onchain and offchain logic and what the ramifications of such designs could bring including potential concerns with liveness, MEV, censorship, and much more.
The first generation of Ethereum applications put all of their logic onchain. Etherdelta, launched in 2016, was one of the first decentralized exchanges (DEX). It replicated the concept of a traditional central limit order book (CLOB) design and had onchain limit orders. Users would deposit money into the smart contract prior to placing or removing limit orders and executing market orders. The application was reasonably successful until Ethereum transaction costs soared in 2017, pricing out many users. Unlike traditional centralized exchanges where users only pay[1] when orders are matched, users also had to pay for both the creation and deletion of orders - which represent the majority of transactions on any CLOB.
Understanding these limitations, 0x came next in 2017, shifting the CLOB offchain. 0x had offchain order books with onchain settlement, significantly reducing transaction costs for users by making bids and cancellations free[2]. However, in this design the tradeoff for lower transaction fees is reduced decentralization as it requires a 3rd party to run the offchain order book. What would happen if this 3rd party went offline? What if they start censoring users? Having multiple actors such as 0x’s network of relayers operate multiple offchain order books helped alleviate centralization concerns to an extent, as each order book would likely have different risk tolerance for assets and users - but this fragments liquidity. Alternatively, 0x could also be used for Request for Quote (RFQ), where a user would interact with a market maker directly for executions, but in 2018 these markets were extremely nascent.
These concerns limited the adoption of 0x. The launch of automated marker markets (AMMs) such as Uniswap finally grew onchain trading volumes. Uniswap’s key innovation was shifting from a p2p to a p2pool model. Unlike a CLOB, which relies on liquidity from offchain market makers or users continuously updating their offers which is both costly and requires MMs to be constantly online, AMMs put all liquidity into an onchain pool that automatically rebalances. There was no fear of censorship[3]; users could trade whatever assets they wanted whenever they wanted. Today, AMMs drive the majority of volumes, and RFQ and CLOB volumes are merely rounding errors[4].
Although Uniswap began as a fully on-chain protocol, it has shifted gears. UniswapX, a new DEX design proposed by Uniswap Labs in July 2023, shifts some logic offchain. Similar to 0x, where users sign offchain orders, users sign an offchain Dutch order, which 3rd party searchers execute and settle onchain. These offchain orders have a time decay function that lowers the price a user is willing to be filled at - which opens it up to a whole set of MEV opportunities. If the largest AMM by volume is shifting to an offchain RFQ-like model, what does it mean for the rest of crypto? And more importantly, what are the tradeoffs of moving to an offchain domain?
Within the context of DEXs, we expect that offchain liquidity can lead to systemic risk in decentralized finance (DeFi). In a pessimistic depiction below:
We expect RFQ to offer cheaper transaction costs as there is no complicated onchain logic and offers potentially better execution. RFQ providers or executors can capture the spread between offchain and onchain prices with their own inventory, which may be passed on to their customers. In the long run, this will dramatically reduce onchain volumes, resulting in a reduction of yield to AMM LPs, drying onchain liquidity, and reducing “economic liveness”. This can lead to greater volatility onchain as the liquidity of last resort gets thinner. If offchain RFQ providers choose to stop quoting or have technical issues, then liquidators will have to source liquidity onchain, which will have worse execution. Potentially, there may be insufficient liquidity to liquidate certain positions - resulting in lending protocols with bad debt.
However, shifting liquidity offchain does not inherently lead to systemic risk if protocols are designed properly. Further, it is unlikely that all assets will move to RFQ. There will always be markets for onchain AMMs, especially as new designs are created.
UniswapX is not the first to pioneer offchain logic, there are countless applications which have been operating with offchain logic for years.
Routers such as 1inch Exchange and Uniswap Router automatically route users' trades through various AMM pools. Due to the fragmented nature of AMMs, each with its own set of fees and liquidity, it is difficult for users to decide which AMMs to use. Instead, a router makes these decisions on their behalf - often splitting up a trade into many smaller ones to ensure the best execution for users.
Searchers are offchain parties who scan the chain for MEV opportunities such as CEX-DEX arbitrage and liquidations. They closely monitor the blockchain and execute arbitrage and liquidation transactions to keep prices across DEXs in line and prevent bad debt from occurring in lending markets.
Offchain DEXs such as CowSwap have with a network of offchain solvers competing to generate an optimal batch auction solution to ensure its users are filled at a uniform clearing price.
Intents are a nascent area of research where users, instead of explicitly defining their transactions, merely signify some parameters they want fulfilled and outsource the logic of finding optimal routing to offchain 3rd parties. Similar to routers, but intended to be for generalized transactions and have more competition in order filling.
Privacy tools such as Tornado Cash require depositors keep their “deposit note” in a secure offchain location in order to withdraw their assets at a future date. If the user loses their note, then they will not be able to withdraw their assets.
Ordinals / Inscriptions these products use the blockchain as a write only database where offchain indexers read the data and report on the state of asset ownership.
NFTs often have data associated with them that are not stored onchain. This can include the actual image or content along with associated metadata.
Offchain logic is not inherently bad, nonetheless it is paramount to understand the motivations for moving offchain and methods to de-risk these offchain systems.
In an ideal state, everything would be onchain for censorship resistance, transparency, and liveness. Unfortunately blockchains need to manage a delicate balance between decentralization and scalability. Solana’s embodiment of this philosophy is a monolithic L1 with where all logic lives[5], powered by massive resource hungry validators, whereas Ethereum has chosen to take a more rollup centric approach, prioritizing decentralization.
Transacting on Ethereum is expensive because Ethereum is successful. Users want to interact in an ecosystem where there is valuable state, assets, and security with many users. However, congestion pricing prices out segments of users or at least limits users to high value transactions. Increasing the block size would reduce transaction costs but increases latency between validators and the amount of data they have to process and store - a trade off Ethereum is unwilling to take.
While in Bitcoin land, application developers want to extend the functionality of Bitcoin without an underlying protocol change. Hence protocols such as BRC-20, Ordinals / Inscriptions, Taproot Assets and Lighting all have offchain indexers, watchtowers, and the whatnot.
Base layers as the building block that others build upon, must make deliberate and measured updates. There is little capacity to experiment with a feature that might be forked out in a future upgrade, as breaking applications during protocol upgrades is undesirable. Oftentimes it is safer to experiment with features such as proposer-builder-separation (PBS) offchain as potential bugs will only affect a subset of validators and have no liveness impacts. Because there are no ways to A/B test features onchain, offchain is the only way to test and parameterize more radical features[6].
The line between onchain and offchain logic for applications is straightforward, if the app’s logic is wholly encoded within the EVM such as Uniswap (v1-v3), then it is considered onchain.
Traditionally, most offchain infrastructure has been application specific. With applications such as 0x paving the way with offchain order books and onchain settlement. Today, many offchain applications can be orders of magnitude more complex. For example:
Rollups and L2s are generalized compute layers that potentially can inherit the security of their parent chain. Some designs are more secure than others, which is an exercise left up to readers.
Eigenlayer extends Ethereum’s validator set security and lets applications rehypothecate ETH’s economic security for their use cases.
Axiom enables querying and aggregation of historical Ethereum state to smart contracts. Unlike a trusted oracle, their use of zero knowledge proofs lets smart contracts consume the results trustlessly.
MEV-boost is a sidecar to Ethereum that enables proposer builder separate (PBS), where the validator outsources block production to a 3rd party builder instead of doing it themselves.
These out-of-protocol applications require no changes to the underlying Ethereum blockchain[7]. The design space for offchain applications grows everyday, but what trade offs are made?
With logic living in different places, how do application developers, core protocol developers, and users reason about different designs? Not all offchain applications are created equally. Some are secured by multi-signature wallets and fraud proofs, whereas others rely on cryptography like ZK proofs and complex governance mechanisms such as decentralized autonomous organizations (DAOs).
The following is a list of considerations developers should consider when designing offchain applications:
Liveness
The blockchain is always on[8]. They have a large set of distributed validators to ensure that if even a portion of the network goes down, the network will continue running. Do these offchain networks have the same guarantees? Is there more than one computer running this offchain network? If there are multiple computers, how do they communicate with each other - Is there some validator network? If so, are they secured by their own endogenous staking token or leveraging someone else's validator set (a la Eigenlayer)? And how many validators are considered sufficient? Alternatively, instead of a validator set, perhaps they are zk based, and in theory, anyone can generate a proof assuming the prover is open source. The added complexity burdens developers but could be worthwhile depending on how much the network is securing. And this doesn't even encapsulate supporting infrastructure such as explorers, RPCs, data feeds, and data availability providers.
Interoperability
Building on a common base layer provides interoperability guarantees, applications can reference other applications' data and call them trustlessly. Refinance a loan on one lending platform to another using a flash loan. Swap across five different DEXs atomically. When logic shifts offchain, do these interoperability guarantees persist? In some applications, offchain trades can trigger another transaction during settlement. But an L2 communicating with an L1 (or another L2) quickly…well, that's still an active research area.
Censorship Resistance
As a user, can I be censored? Can my ability to transact be limited by this offchain logic? L1s value censorship resistance strongly, hence crLists and a large validator base[9]. Perhaps censorship is possible, but is there a way for a user to exit the system in a censorship-resistant way? Using a validator set instead of a single operator is a solution, but every component has a trade off. Every validator in a validator set needs to be compensated, increasing network operation costs. Perhaps privacy is a solution here.
Market Participants
Related to liveness, how many market participants are participating in this offchain market? If there is only one searcher, what happens if that searcher shuts down their computer, will there be a liveness failure? If there is a monopoly, what ensures the operator will not extract value from the system? Can the system be designed always to ensure that there will be multiple market participants, perhaps by lowering the barriers to entry? This is a problem that intents and Flashbots suffer from. Even though building is a competitive market, there is a duopoly of the best builders.
MEV
Who ensures that offchain information is distributed in a fair and equal manner? In the example of UniswapX, what if users' Dutch orders are shared with a select group of executors before a broader distribution? Empowering a subset to capture more MEV. How do you ensure that OFAs are fair? Alternatively, what if a user's Dutch order is withheld until the execution price has dropped below the market price, resulting in lost value to the user. In this system, users put their trust in the operators. Do the operators have credibility to say that they will not do this? In a centralized setting, trust is your only option.
Credibility
There are hundreds of DeFi forks in the wild. Some had hidden backdoors to enable the developers to drain assets from them. How do offchain products build credibility with their users that they will not rug, spoof, or MEV them? Perhaps the veil of decentralization could sometimes work, or being "ETH aligned". L2beat is great for understanding L2 risk. Alternatively, it might be possible to build accountability along the transaction supply chain, which Skip is doing with dYdX. Another approach is executing optimistically and then using a system like Axiom[10] to prove that a trade was within a certain band of NBBO, which Flood is exploring.
Auditability
An auditable protocol is more credible. Can third party actors detect and monitor what is occurring within the system? The next step is for a protocol to be able to introspect, or audit itself, rather than relying on 3rd parties to do so. For example, a protocol may be oblivious to an external actor spamming the mempool, while 3rd party monitors can detect this. A protocol can build out additional mechanisms to not only monitor this behavior but also to incentivize specific behavior with sticks and carrots. (Barnabe has an excellent read on this subject, he calls this deviant behavior the break of the fence).
Standardization
L2s are diverging from L1s, with the introduction of new mechanisms and languages that are incompatible with the L1. More experimentation is valuable, as Ethereum, by design, innovates slowly. But there needs to be more standardization; every offchain application tries to push its standards. How easy will it be for developers to integrate with offchain protocols in the future? Fragmentation is inevitable, and there will be shims for everything.
Centralization
The easy way to build a product is to have it centralized. Why deal with the overhead of validator sets or decentralized governance? Offchain logic has strong centralizing forces beyond the operation of these networks. Offchain logic can choose to be closed sourced, which reduces the auditability and credibility of it but can prevent forks which is a desirable feature for developers - Starkware only just open sourced their prover after years.
Usability
What must the user do to interface with this offchain logic? Do they connect to a different RPC network? Or is it more complex where the user or the application has to store additional offchain information? In the case of TornadoCash, users have to hold commitments somewhere safe (DA problem). If they lose it - they will lose access to their funds. This problem will become more pressing with stateless Ethereum. Who should store the state: the user's wallet, the application, or an RPC? In another dimension shifting off chain potentially unlocks cheaper compute, enabling complex computation that would’ve been impossible onchain, like ZKML.
Given these considerations, it should be easier to reason about the trade-offs that different offchain designs take. In the long run, it will become even more complex, with application developers debating on where all the logic should live (L1 VM vs part of consensus vs SUAVE vs something else)
The monolithic blockchain died years ago. In the future, most logic will live offchain, not enshrined or controlled by the core protocol. An L1 with dozens of L2s, hundreds of L3s, and numerous sidecars / coprocessors and executors / keepers / searchers / solvers / fillers / MEV bots / indexers / inscriptions that coexist. Ethereum's end goal is to become stateless. The chain should be as lightweight as possible to push decentralization as innovation is pushed to the edges, off the chain. But countless open questions remain.
As more logic moves onchain, who sets the standards? Will offchain application attempt to approach the security of the underlying L1 through a mix of zero knowledge and economic rehypothecation, or not? And what about Ethereum statecraft and the threat of enshrining? Data availability layers turned out to be useful for a rollup-centric future. Ethereum launched EIP-4844, which enshrines Celestia functionality and brings value back to Ethereum. Will the same happen to L2s - will there be a canonical type of L2 that is "state sponsored" by Ethereum? Will this happen with other types of offchain logic?
Many thanks for Xyn, Sina, and friends for feedback.
Addendum
The split between onchain and offchain logic extends beyond applications to blockchains themselves. There are consensus rules on how validators agree on the current state of a blockchain and how to iterate to the next step, but not all logic is encoded as part of consensus. There is logic in the client that is not protocol enforced resides in a weird middle ground, for example, nodes are not slashed if they do not gossip transactions[11].
Or get a rebate with a traditional maker-taker exchange model.
Users could also cancel their limit order for free, but then would have to trust the CLOB operator to delete their initial limit order. Alternatively, users could send an onchain transaction that would invalidate any trade that used their limit order.
Ignoring miner censorship
0x RFQ is <1% of all Ethereum DEX volume
Their offchain NFT merkle tree this is a bit counter to the philosophy
Yes there are testnets, but they don’t have economic value so things such as builder centralization are unlikely to manifest.
Granted, for optimization purposes, introducing some precompiles has greatly reduces the cost of onchain snark verification, and in the case of MEV-boost, there was a consensus change (if you consider the Builder API part of consensus).
Unless you are Solana
Though PBS does change the equation a bit
Axiom is able to provide state proofs on historical data. It can look at the state of the blockchain during the block of execution and determine if the user would have gotten a better price trading through the most liquid AMM pool.
Solana has Turbine which are rules on distributing completed blocks between validators, however there is no protocol enforcement of this distribution method. It is understood that some validators modify their software for MEV related purposes.