The Inevitability of UNIchain

Over the past few months, there has been increasing interest shown in application-specific chains (or rollups), commonly referred to as appchains. The basic idea is having an independent blockchain with its own validators/sequencers, focused around a specific protocol/application.

This differs from the generalist blockchain philosophy that has been dominant to date, from Ethereum to BSC and Polygon and Solana–not to mention generalized L2s like Optimism, Arbitrum, or Starknet–where the belief has been that the interoperability and composability gains from having a common platform for storing and updating state are of utmost importance.

However, the view that various applications would eventually want to have their own chains is not exactly new. The teams working on Cosmos, Polkadot, and Avalanche have been working towards versions of this future for years. Compound took a step in this direction in 2020 with their announcement of Compound Chain, to be built on Polkadot’s Substrate, but ended up abandoning that effort (at least for the time being) when they realized that the infrastructure wasn’t yet mature enough.

Earlier this year, dYdX reinvigorated interest in appchains with the announcement that they would be moving to their own chain utilizing the Cosmos SDK. And just recently, the Delphi Labs team shared an incredibly comprehensive analysis of how they see the crypto and DeFi ecosystem evolving, ultimately landing on Cosmos as the platform where they plan to focus their efforts.

‍

At Nascent, over the past two years we have become increasingly convinced that some form of an appchain-centric (or approllup-centric) world is the likely future state of the crypto ecosystem.

Rather than attempt to provide a thorough analysis of why and how this will come about, I’ll instead provide a single case study that can hopefully help builders who aren’t yet thinking about appchains understand why they’ll eventually have to consider them.

‍

‍

As the dominant DEX and with a strong brand, Uniswap is a prime candidate for eventually moving to its own application-specific chain or rollup. It has among both the greatest ability and highest incentives among all contracts/applications to move to its own chain.

Over the past year, Uniswap V3 has done a little under $700 billion in volume on Ethereum L1, with over 38.8 million trades at an average transaction size of ~$17,870. In doing these trades, what costs did traders have to pay?

Cost #1: Swap Fees

The first and most obvious is swap fees. Most centralized exchanges charge fees to both makers (those posting offers to the order books) and takers (those accepting offers that are already posted on the order books). Since exchanges want to encourage marketmakers to provide a deep order book, makers typically pay lower swap fees than takers, and some who do especially high trading volumes can even earn rebates.

In Uniswap’s case, the liquidity providers (LPs) act as makers and the traders as the takers. Historically, swap fees have been 0.30% (30bps) for the trader, all of which has gone to the LPs, resulting in a -0.30% (negative 30bps) fee received by the LPs. In UniV3, different pools can have different fees, ranging from 0.01% or 1.00%, but they all have the same dynamic of 100% of the fees paid by the trader being received by the LPs.¹ As a result, traders have paid–and LPs have earned–just under $1.2 billion in swap fees over the past year, amounting to an average of 0.171% per trade.

That’s a lot of fees! Compared to fees paid on centralized exchanges by retail traders, it’s pretty reasonable though.

Unfortunately for traders, that wasn’t the biggest cost they paid to trade on Uniswap.

Cost #2: Transaction Fees

Where were those Uniswap trades settled? Ethereum, of course. And each trade had gas costs associated with it, paid to Ethereum validators (directly) and ETH holders (indirectly). Note that this is not a fee that traders on centralized exchanges have to pay at all. So in its quest to be the best trading venue in the world, the fact that Uniswap needs to have its traders pay a fixed (though fluctuating) fee per transaction is far from ideal.

And much like with gasoline in meatspace, gas on Ethereum isn’t cheap: Uniswap traders spent $1.63 billion on gas in the past year. That’s equivalent to an extra 0.235% (23.5 bps) per trade.

That means, on average, traders pay 17.1 bps to LPs and 23.5 bps to Ethereum validators. That’s 37% more being paid to validators than to LPs! Quite a bit of value leakage happening there.

But at least those first two costs are transparent to traders… which brings us to:

Cost #3: MEV

Earlier this year, 0x Labs captured data on 700,000 trades that went to AMMs through the 0x API. From this, they found that on average, those trades experienced >20 bps of slippage vs the initially quoted price… and that slippage increased with trade size! Overall, $27M was lost to MEV through the 0x API in the month (June) leading up to the launch of a new slippage protection feature that attempts to address this issue.

Lacking access to more direct data on Uniswap-related MEV, we can make a very rough estimate of MEV captured on Uniswap over the past year with the following assumptions:

1. Trades happening on Uniswap directly experience roughly the same MEV impact as those done via the old 0x API
2. 70% of the trades 0x API routes through AMMs go to Uniswap V3 (roughly UniV3’s AMM market share)
3. MEV as a share of transaction volume in June was consistent with the remainder of the year
4. 16% of Uniswap volume came through the 0x API

With the caveat that those assumptions are almost certainly wrong, they would result in an estimate of roughly $1.76 billion in MEV costs to Uniswap traders over the past year. That’s another 25.4 bps in average cost per trade. Add that to the swap fees and transaction fees, and the result is 66 bps in cost per trade.

How should UNI holders attempt to capture value?

If traders on average pay 66 bps in fees to trade on Uniswap, and Uniswap is easily the market leader among DEXs, there should be ample ability for UNI holders to capture some of that.

Currently, the only avenue that UNI holders have available for capturing value is to use governance to flip the fee switch and take a piece of the swap fees that are currently going to LPs. If the fee switch had been turned on and set at the level used in UniV2, it would have generated ~$193 million (~16.67%) for UNI holders over the past year.

Those potential profits are, of course, not factoring in the negative impact flipping the fee switch would have had on the profitability of LPs, almost certainly resulting in less liquidity and lower trade volumes, and therefore lower fees. This is the core problem with using the swap fee as the source of value capture for UNI holders: it would introduce a spread into the marketplace, necessarily making it a less efficient trading venue.

What about the other two costs, transaction fees and MEV? There currently aren’t good ways for UNI holders to tap into either of those, as long as Uniswap operates primarily on Ethereum or other generalist chains and rollups.

Enter UNIchain.

If Uniswap were to migrate the majority of its activity to its own chain where UNI holders were the validators, it would immediately open up powerful options for both lowering trade costs and capturing value.²

First, rather than paying large fixed fees in gas to Ethereum validators, those costs would be brought down by an order of magnitude or more, immediately making trades (especially smaller ones) much less expensive and therefore the overall exchange more efficient. It is absolutely amazing that Uniswap has seen the success it has to date with traders on average spending more on fixed gas fees than volume-based swap fees. Making the fixed gas fees a minority of trade cost would be a huge win for traders and having those fees capture by UNI holders rather than ETH holders would be a major improvement to UNI’s existing “valueless governance token” model.

Second, controlling the validators/sequencers means that UNI holders would be able to take steps to minimize the MEV cost to traders, such as by implementing threshold encryption (e.g., Osmosis) or batch swaps that execute all trades between assets in a block at the same price (e.g., CoW Protocol). Reduction in MEV would make Uniswap a more efficient trading venue, but to the extent that MEV cannot be entirely eliminated, at least a Flashbots Auction-style system would ensure that much of the MEV could be internalized to UNI holders/validators rather than given away to ETH holders/validators. This ends up being akin to a form of Payment for Order Flow (PFOF).

While the idea that the best value capture model for UNI amounts to PFOF might sound very tradfi, it is likely unavoidable and at least in this form, access to it is democratized and transparent.

Also note that not all MEV is harmful to traders. While it is important to minimize frontrunning and sandwich attacks as a form of MEV that has a direct negative impact on the price of traders, other forms of MEV (e.g., backrunning and arbitrage across pools or venues) is not harmful to traders but is a massive source of potential profit. How massive is the amount of MEV volume (and therefore profit) on Uniswap?

Around 2/3rd of total volume, it would seem.

Again, as most MEV experts agree that MEV can only be minimized, not eliminated entirely, it is better to have the MEV occurring on a chain or rollup where the validators’ incentives are aligned with minimization of the types of MEV harmful to Uniswap traders. And if backrunning and arbitrage-based MEV can be internalized, that has the potential to add significant value to traders, LPs, and UNI holders. On generalized chains/rollups, a wide range of use cases and stakeholders need to be taken into account when attempting to address MEV; on UNIchain, solutions could be tailored specifically around the needs of traders and LPs. For inspiration, look no further than Skip Protocol’s recent proposal for turning MEV revenue into protocol revenue on Osmosis.

Assumptions underlying the appchain thesis

The primary pushback I get when presenting this thesis to folks who are not yet appchain-pilled is that moving to an appchain breaks composability. (Trust me, I’m very aware of the benefits of composability.) My response is that we’re already in a thoroughly multi-chain world, where the majority of all economic activity in crypto is clearly not all going to happen on a single chain.

This means we need to get much better at trustless and trust-minimized bridging, just as we have needed (and still need) to get better at writing secure contracts in general. Applications across almost any two or more public, permissionless blockchains already have greater potential composability with each other than any legacy financial rails or databases. Appchains may not provide the same degree of atomic composability we’ve grown used to in the early years of DeFi, but as the ecosystem matures, we will find advantages to UX and security in adopting designs that require more explicit decisions be made in choosing the types of composability that are prioritized.

Another driver of an appchain-centric future will be the necessity for many applications to have more direct control over their costs and access to blockspace. While the creators of Solana and various other high-throughput blockchains have managed to implement impressive capacity increases, there are ultimately physical limitations to the volume of transactions that can be processed on any network that values meaningful decentralization. If you are as bullish as I am about the future of our industry, you must believe that the demand to write to a globally accessible and censorship-resistant database is virtually infinite if the cost is low enough. Therefore, some form of market pricing for blockspace is required.

On a permissionless generalized chain, this creates a problem: every application has slightly different limits on what transaction fees its users will be willing to accept; if you make blockspace too cheap, someone is always going to do things like put games fully on-chain and eat up all the space until they push costs above the willingness to pay of users of other applications.

Therefore, once applications reach a certain size, it starts to become increasingly important to have more direct control over their access–and their users’ costs for accessing–blockspace. The solution to this is a chain or rollup where access to blockspace is managed by validators whose primary concern is the success of a single application–their own.

Conclusion

To recap:

• Uniswap as it exists today has three costs paid by traders:
  - Swap fees (variable, paid to LPs)
  - Transaction fees (fixed, paid to ETH validators)
  - MEV (variable, paid to ETH validators and market makers)
• Swap fees are currently both a minority of the cost paid by traders and the only place where UNI could potentially capture value
• Moving to an application-specific rollup where UNI is staked by validators (i.e., UNIchain) would enable reduced transaction fees and MEV
• MEV that cannot be eliminated would be largely internalized to UNI holders, which is likely the best place for UNI to capture value long term

Any application that grows big enough will likely at some point have similar reasons to consider moving their primary home to their own chain or rollup.

To be clear, while we at Nascent believe that appchains will eventually be a major force in the crypto ecosystem, the timeline in which we see this becoming a reality is 3+ years out. Significant advances need to be made to development tools, validator infrastructure, rollups, bridges, wallets, etc. in order for appchains to be a major force in the crypto ecosystem.

That doesn’t mean that it’s not worth considering the appchain path sooner, and Nascent has invested in multiple teams/projects based on this thesis, including Osmosis, SX Network, and Ribbon, with their soon-to-launch options exchange, Aevo.

If you’re working on the infrastructure necessary for an appchain-centric ecosystem or on a project where an appchain is a core component of your long term strategy, we’d love to meet you.

[1] Technically, the right way to model this “swap fee” is not as a fee, but rather as a 60bps bid-offer spread since it is paid to the LPs rather than a third party. But since Uniswap has always presented this as a fee and even accrues it separately in V3, it seems fair to frame it as such.

[2] Realistically, this would probably be an Ethereum-based rollup with validator/sequencer rights being managed via staked UNI; it’s hard to imagine the Uniswap Labs team leaving the Ethereum ecosystem entirely by choosing a Cosmos zone or other non-rollup alternative.

Many thanks for valuable feedback and copy-editing to Will Price, Elle, Matteo Leibowitz, Josh Felker, and Brock Elmore.