L2 Wars

Blast: Jumping the Shark

I think it’s no secret that L2s have been a bit disappointing with their progress thus far. Very few have moved past stage 0, they all have centralized sequencers (which matters for censorship resistance & potentially regulatory), and they all have multisigs governing million or billion dollar bridges. Then we got Blast, the most DGAF version of an “L2” we’ve seen yet, garnering nearly $1B deposits in what is essentially a multi-sig.

The fact that they launched before they even have a bridge and got $1B in deposits tells you a lot about the state of things (especially user behavior). The problem is that it puts a somewhat unfair light on what other L2s are trying to accomplish, and bastardizes the meaning of an L2. Pic below from Arbitrum blog unrelated.

As a side note, I agree with this take below. Top catalysts for the next market meltdown imo are either:

1. stETH exploit
2. Bridge exploit
3. Restaking (or rehypothestaking)
4. Another protocol with endogenous collateral gets too big

Native yield combines #1 and #2, and possibly #3 as a stETH exploit (in the case of Blast) is now effectively an exploit on the bridge as well, and it could also be… re-staked. And if the bridge gets exploited first, now you have potentially billions of stolen stETH getting sold on the market, leading to DeFi insolvencies.

This is getting fucking silly already

Native yield and restaking will be the catalyst of the next market meltdown and the birthing pool of the next Great Fraud

Calling it now, bookmark this https://t.co/hhpcKnk2h8

— laurence (@functi0nZer0) December 15, 2023

Blast was a turning point in my opinion, and the L2 wars have officially begun. Teams will start to call out other L2s for their practices and ecosystems will continue to fragment into their own silos with their own social consensus. This means better interoperability & liquidity between ecosystem rollups as they can share bridges and sequencers, and worse when travelling outside.

Rollups have always been competitors, but we had a couple years of peace as they all had their training wheels on. Now that some are starting to progress (like Arbitrum moving to Stage 1) and L1’s like Solana starting to become competitive, you’ll start to see it get nastier.

There’s also the reality that there are only so many general purpose EVM rollups we need. Like most things, it will be winner take most.

i.e., the l2 wars are starting and they’re going to be nastier than the l1 wars b/c everyone shares a common ground (and asset) this time. who is building “for the good of eth”, and whose tvl is a liability?

what’s that degenspartan saying? something something profiting from war

— ceteris (@ceterispar1bus) August 15, 2023

People are starting to take note, and 2024 will be a big year for Ethereum L2s and their future. While I appreciate the sentiment in the tweet below, I don’t believe it. The L2 wars will be just like the L1 wars.

L2s are in danger not because of the tech, but because they will fight each other on bd and marketing and miss the forest for the trees.

The ethereum endgame of scaling via rollups requires as much social interoperability as it does technical.

A united front or death

— binji 🔴 (@binji_x) December 10, 2023

We’re running it back turbo.

You can think of @arbitrum as the biggest L2 with over 50% market share, or you can think of it as the second biggest stand alone blockchain by most metrics

— Size Chad (@SizeChad) December 6, 2023

2024 will be the year of the superchain https://t.co/qZRi1bD9We

— 1 BTC pikachu (📜, 🤝) (@ttyl5h) December 17, 2023

L2 Ecosystems Will be Siloed

Ethereum L2s are led by Arbitrum and Optimism, with ~60% of all L2 DeFi TVL from Arbitrum and ~20% from Optimism. Note that this is DeFi TVL, not TVL in their respective bridges. The numbers are similar for bridges though, with Arbitrum’s $8.1B (51%) and Optimism’s $4.6B (30%) responsible for the $15.75B in L2 bridges. While TVL is not a perfect metric, it’s a good one for L2 bridges in our opinion as it reflects the desire to use and perceived risk/reward in a particular rollup.

Outside of the big two, the recent leaders have been Base, zkSync Era and Mantle. Base got off to a hot start but has really cooled off since Friend Tech and hasn’t had much new since, zkSync has a lot of TVL that is mostly airdrop farming, and Mantle is a new eco with a massive treasury. Other ZK-rollups like Polygon, Scroll and Starknet round out the rest.

Outside of Starknet, all of these L2s are some version of the EVM, mostly offering copy pasta protocols seen in other ecosystems before them. It will be up to these rollups to get their own unique applications. Base had this initially with Friend Tech that was pivotal in helping it get off to its hot start.

Crucially, we do not believe these rollups will interoperate with each other well. We can already see this forming in the numerous rollups stacks builders are now choosing from as ecosystems look to cement their tech and earn the business of developers. Rollups are lucrative and the more rollups an ecosystem has using their tech, sequencers and token, the better for it. At the end of the day, rollups are looking after their own token first and foremost, not ETH.

Since September, Arbitrum is the only L2 that has actually been increasing its profits MoM. zkSync has seen a reduction in airdrop farmers, Base has seen their flagship app FriendTech quiet down, and Optimism has seen a decline as well, maybe partially cannibalized by Base.

While their tokens are mostly memes for now, in the long run we should expect them to accrue a significant portion of execution fees (gas & MEV) on their rollups while potentially serving as a token needed to run a sequencer as well. We also would expect shared sequencers to be ecosystem specific, as sequencing is a valuable part of the execution stack and ecos will want to create synergies between their own chains.

We’ll dive into these ecosystem offerings here.

Arbitrum

The main rollup is “Arbitrum One”, this is the rollup that uses Ethereum for DA and has >$8b of assets on it. They have since launched their own DA layer called Anytrust, which is a data availability committee that Orbit chains can use for cheaper fees. Arbitrum Nova is the first chain to use Anytrust and is thus referred to as an Optimium, not an Optimistic Rollup. Orbit is Arbitrum’s latest product that allows developers to create their own chain and choose to settle to Arbitrum One or Nova, depending on the security/fee tradeoff the project desires.

Arbitrum recently put their hat into the ApeDAO ring along with other L2 stacks to become the home for ApeChain (yes I know this entire sentence sounds ridiculous). The proposal is to make ApeChain an Orbit Chain that uses AnyTrust for DA. The benefit of using AnyTrust is that you can make APE the gas token on ApeChain without it introducing significant APE sell pressure like it would if it were a rollup (would need to constantly sell APE for ETH to pay L1 DA costs). What’s the benefit for Arbitrum? ApeChain would use Arbitrum One for “settlement” (i.e. a bridge) while using the DAC for DA. This would congregate more liquidity around Arbitrum One as they would have the native bridge for ApeCoin. The revenue from this is small, but the liquidity + brand is what Arbitrum is going for. It’s important to note that having a shared bridge for eco rollups is an idea a lot are going with. A bridge is kind of a moat as more liquidity makes bridging between eco rollups easier, especially if they use a shared sequencer.

In addition to Orbit, Arbitrum has also developed Stylus, what they call “EVM+”. Stylus, estimated for Q1 2024, is a programming environment for all Arbitrum chains that allow developers to write programs in Rust, C, C++ and more to run alongside EVM programs. Going beyond what the basic EVM can do is needed to create a competitive advantage within rollup ecos and Stylus is that for Arbitrum.

Lastly, Arbitrum has partnered with the shared sequencer Espresso to bring shared sequencers to Arbitrum chains. Arbitrum and Espresso are working on a joint solution called Timeboost, a “modification to the existing first-come, first-served model (FCFS) that relies on sealed-bid priority gas auction ordering”. All Arbitrum Orbit chains will be able to integrate and share this sequencer if they so desire, creating better cross-chain composability between orbit chains. Espresso and (eventually) Timeboost will be available to all Ethereum rollups, not just Arbitrum, but it remains to be seen whether other rollup stacks will adopt the same protocol.

Optimism

The Superchain. According to Optimism, the Super chain is “a network of chains that share bridging, decentralized governance, upgrades, a communication layer and more—all built on the OP Stack.” Are you seeing a trend here? All of these ecosystems want to create their own hubs who share bridges and communicate more effectively with themselves vs outside chains. Think of it like States/Provinces in a Country. A local language, common beliefs, etc. Interacting within is easy, but the rules change when you go abroad.

The Superchain is still a concept and work is being done to determine the best path forward. Are these chains all general purpose? App specific? Alternative VMs? Shared sequencers? In addition to all of that, Optimism also makes it explicit that chains in the Superchain will share governance and will be governed by the OP Collective. Anyone is free to fork the OP Stack and not share governance if they so desire, but they will not be apart of the Superchain and benefit from all of the shared components.

An example of this is Base. Base is a fork of the OP Stack but a standalone rollup with its own sequencer, bridge, and (potentially) token. The Optimism deal with Base is quite an interesting one to analyze from an economic perspective and we will discuss this further in the value accrual section.

Polygon

Polygon announced their new vision in “Polygon 2.0”, a sort of mash-up between the Optimism and Arbitrum stacks along with Cosmos’ Interchain security. Essentially, you have 4 layers: Staking, Interoperability, Execution, and Proving.

The staking layer will be where validators stake POL (MATIC after token migration). Then you have the interop layer which will act as the bridge for minting assets to/from Ethereum. All chains in the Polygon ecosystem that utilize assets from Ethereum will use this shared bridge which has the benefit of allowing for easier cross-chain communications. On top of this is the execution layer. You will have the zkEVM which uses Ethereum for DA, the PoS zkEVM which is a transition from the current PoS L1 that will use an off-chain DA solution, and then Supernet chains, essentially appchains like in Cosmos’ Interchain Security or Avalanches Subnets.

While all of these will use POL staked on L1 they have different tradeoffs. The zkEVM will use Ethereum for DA and will be both the most secure and most expensive. The PoS zkEVM will use alternative DA and will just post the proofs to Ethereum, allowing for cheaper fees at lower security. The supernets are re-staked POL (and the option for additional tokens) for appchains. Polygon and Celestia recently announced their integration.

zkSync

zkSync has what they call the “ZK Stack”, a modular framework that allows developers to deploy “Hyperchains”. Like the others, yes, they share liquidity with one another, all sharing the same bridge on L1.

Hyperchains allow devs to choose from numerous parts like other rollup stacks, and zkSync has also been working on their DAC zkPorter. Rollups can choose from rollup/validium/volition mode, l2/l2, decentralized/centralized sequencers, solo/shared sequencer, private/public data, and gas token, whether ETH or custom.

Starkware & Scroll

We’re not going to go further into these here but will highlight that Starkware has similar ideas with their StarkEx appchains and Starknet, and while Scroll is mainly focused on their mainnet right now, we would expect them to open up their own custom rollup solution as well.

Overall Thoughts

While all of these ecosystems sharing a bridge is good for liquidity and helps them create a moat, it does increase the damage that an exploit on any of these eco’s rollups will do. Rollups are always seen as assets to Ethereum, as they use ETH and pay ETH fees to the L1. But there’s an argument that at a certain size they start to become a liability, as an exploit with 10%, 15% or more of total ETH can now result in contagion for the entire Ethereum ecosystem. Over the next few years we’ll see more discussions around this and how to best plan/mitigate before it happens.

With all that being said, rollups will not necessarily fragment into their own ecos. We believe this to be the most likely, but if you want to play devil’s advocate then you can look to something like Polymer as to why rollup-eco interoperability will be fine. Polymer looks to bring IBC to Ethereum rollups, launching as an OP Stack/Cosmos SDK chain using Ethereum for Settlement and EigenDA for DA. IBC is a good protocol, it’s just hard to use outside of Cosmos.

If Polymer can make this work then it could mean a lot for multi-chain interoperability moving forward. Is Polymer, ironically, the most “Ethereum Aligned” of them all?

Ethereum Alignment: ETH Bridge + Alt-DA

What does “Ethereum Alignment” mean? This phrase gets thrown around a lot, but there’s not really one single definition for what it is.

To me, Ethereum Alignment means using any part of the Ethereum stack in your protocol. Launching on L1? Aligned. Creating an L2 that used Ethereum for DA? Aligned. Creating a rollup that uses another protocol or DAC for DA but still has a validating bridge (i.e. settlement) to Ethereum? Yes, also aligned. This last construction is one I think we will see more of, simply due to the fact that rollups who use Ethereum for DA will always be more expensive than alternatives. But as long as you have a bridge for ETH so your protocol can use ETH as money, it’s all good. You will receive the blessings of the Ethereum gods. Vitalik had a good post around all of these different constructions recently.

The chart below is taken from the fantastic model from 1kxnetwork (note that there are a lot of nuances to the data and we would definitely recommend this thread if further interested). We took a small subset to show hypothetical TPS for Optimism and Arbitrum under various DA sources. As you can see, even with 4844 in its ideal state, throughput is still fairly limited, and the initial implementation of 4844 will only allow ~150-300 TPS across all rollups. Even full Danksharding with the current spec will not be enough, but that’s years down the road anyways. What we will see in the meantime is a large shift towards this model described above; the ETH bridge with alt-DA.

Of course, cheaper rollups have a tradeoff, and Ethereum’s DA will always be saturated. Cost is merely one area to compete on. EigenDA having more capacity does not mean it is “better” than others, just the cheapest.

the problem is you can’t slash the re-staked ETH for withholding data, unless you hard-fork Ethereum itself.

— c-node (@colludingnode) December 5, 2023

All of these things matter but we’re not getting into comparing DA layer specifics here. I want to share an internal chat here because Mark did a really good job describing using alternative DA sources when Ashwath asked him.

Ashwath: In the Superchain (Optimism) docs they mention that the rollups need to have a shared L1 but they can use an alternative DA source. I’m wondering exactly what this means. For example, if a rollup chooses Celestia for DA, do they not post any data to Ethereum anymore or just the state roots?

Mark: This pretty much means that DA can be configured to something other than Ethereum (this is still a lot further down the roadmap for Superchain). While the option for using third party DA like Celestia, Avail, some centralised data availability committee or anything that fits the DA role, Ethereum will still need to receive attestations from whichever DA is being used to authorise that the state transition that has been performed off-chain is valid and that Ethereum accepts the newest received state root of a rollup as valid.

So what this means is that if Ethereum is not used as the default DA, that some sort of commitment attesting to the order and contents of the data needs to be sent to Ethereum. In the zk context this will be the DA layer sending some zk proof to Ethereum (with these zk rollups some additional logic requiring a proof of equivalence protocol will be required for Ethereum to cryptographically verify the integrity of what is being communicated from the DA layer). In the optimistic rollup settings, things get a lot more interesting and this is where we still see the design space for modular fault proof systems being wide open. That is still up for interpretation but OP Labs have been pushing out loads of research I still need to catch up with in that regard. But that will be a crucial deliverable for allowing true DA modularity across all rollup designs.

ZK rollups have a more clear path forward in this paradigm but optimistic is still a bit primordial but certainly attainable. The true superpower for this modular DA is in Ethereum’s capability to use KZG commitments to cheaply, and trustlessly verify about any off-chain computation done by the rollup and an independent DA layer. The rollup just needs to provide both its own internal cryptographic commitment along with KZG commitment to the data (see this post from Scroll).

We have already seen numerous teams make announcements under this construction that we’ll highlight here.

• Eclipse: Eclipse was the first rollup announced under this architecture. Eclipse takes the SVM (Solana virtual machine) and runs a rollup with settlement on Ethereum and DA on Celestia. In this construction, ETH will be the gas token but the majority of fees will need to be converted to TIA to pay for DA. All of the execution fees for the L2 will go to the Eclipse sequencer and at some point (probably) the Eclipse token, so these can be kept in ETH or converted to anything else. Eclipse is mostly using Ethereum for ETH, not Ethereum blockspace.
• Mantle: Ethereum rollup that uses EigenDA for DA. Mantle may be commonly known under its former name BitDAO, and they have recently launched their own LST for Mantle, mETH.
• Manta: Rollup stack to build with parts of Ethereum, Celestia, Polygon, Optimism & Polkadot. They recently became the first rollup to adopt Celestia mainnet for DA. There is a good critique of their architecture on launch from Donnoh at L2BEAT.
• Polygon: Recently announced the addition of Celestia as a DA solution in the Polygon SDK. Notable, as Polygon was also behind the development of Avail, another DA layer.
• Conduit: A RaaS (Rollup as a Service) provider for Op & Arb stack chains, recently announced support for Celestia with a cool demo.
• Astria: Recently announced the Astria EVM, an EVM rollup that uses Astria’s shared sequencer network. They use Celestia for DA.
• Dymension: They don’t fit in this “ETH Alignment” section but are worth mentioning as they are expected to be one of Celestia’s largest users, bringing rollapps to Cosmos. Instead of posting state roots to Ethereum they’re posted to Dymension.
• Versatus: The first stateless Ethereum rollup, will be using EigenDA for DA.
• Polymer: As mentioned above, will be using EigenDA for its Ethereum rollup that looks to expand IBC to Ethereum.
• LayerN: Ethereum for Settlement, Eigen for DA.

There are more besides these mentioned but you get the point. Rollups need more scale and Ethereum cannot provide it. These constructions using other DA sources will be a big theme in 2024 and beyond. What does this mean for ETH?

Value Accrual: ETH, L2 Tokens, Alt-DA

So where does value accrue? We now have numerous execution layers, settlement layers, DA layers and more. There’s ETH, there’s TIA, Eigen’s token and other DA layers, tokens for the rollups themselves like ARB, OP, etc. That’s a lot of fingers in the pie.

We can start by looking at the rollups today and how the revenue they generate is split. There are 3 components to the fees rollups create.

1. Execution: Fees paid on the rollup for execution on the rollup. These go to the rollups token.
2. Settlement: Fees paid to post state roots and validity/fraud proofs. Predominately this is Ethereum.
3. Data Availability: Fees paid to publish to a DA layer.

We can look at the Ethereum rollups today for insights into how these costs work out. The graph below charts fees earned for the respective categories above. Execution (i.e. rollup margin) collected by the L2, Settlement by the L1 (ETH), and DA by the L1 (ETH).

A Couple Notes:

1. Base overestimated fees on launch, Metamask was essentially overcharging users. Their margin looks more like Optimism over the past few months.
2. zkSync margin % was >50% when it launched due to gas limits & high demand from rollup farmers. More recently it sits around 22%, a lower margin that the optimistic rollups due to having to post & verify validity proofs in addition to DA.

Of course, these metrics are for Ethereum specifically, and they’ll look a lot different depending on the rollups execution environment, DA layer and settlement layer. Let’s look at these constructions and where value accrues.

1. Ethereum L2: Ethereum gets all of the DA & settlement fees while the rollup token gets execution/MEV. Ethereum and ETH have strong fundamental flows under this construction.
2. Ethereum Bridge + Alt-DA: Alt-DA gets all the fees, rollup gets all the execution & ETH is left with settlement. For optimistic rollups this amount is negligible and immaterial. For zk rollups it’s a bit better as proofs need to be posted/verified frequently. Under this construction ETH is purely a money or meme, as the majority of fundamental fee income is not captured by ETH. Even if the rollup chooses to make ETH the gas token, it’s mostly recycled, as it needs to be converted to pay for the alt-DA.

What does this mean for each part of the modular stack?

Value Accrual: ETH

Does this mean alt-DA rollups are bearish for Ethereum? Depends on the framing. Ethereum’s blockspace is restricted and so all of these resources for Ethereum will cost more, ceteris paribus, which means more fee income per tx than competitors. But for applications that need cheap fees and high throughput, Ethereum will lose their business.

On the flip side, there will most likely always be a strong desire and demand to use Ethereum, and so if Ethereum DA usage drops a lot due to alt-DA, rollups will start deploying on Ethereum instead. There’s kind of a Jevons paradox here where Ethereum blockspace will always be used up. Not all applications need sub-cent fees, and even $0.05-$0.50 is fine for some applications. Ethereum, in our opinion, has this benefit here in that demand will be saturated in perpetuity, and they can restrict blockspace more so than others. There’s no question though that the idea of crypto just being Ethereum and a bunch of Ethereum L2s is dead, so ETH will not capture all of the addressable market when it comes to rollups.

Arguably, the real bull case for ETH is the global proof verification layer & money. Under this scenario, Ethereum is where every rollup posts proofs and everyone can verify. The largest, decentralized, credibly neutral platform to do so gives it a competitive advantage. And money. Money is hard to quantify, and ETH is not as good of money as BTC, but it is good money. And money is valuable. This is the bull side of using ETH in all the rollups even if no fee income is generated.

Value Accrual: Alt-DA

It’s unclear at this point how much of a commodity DA will become or if DA layers will be able to carve a competitive advantage. For Celestia, it’s their DAS and light client support, which becomes stronger the more rollups that use it. Still, Celestia’s token TIA is not bridgeable to rollups in its current state as Celestia does not support smart contracts, so TIA’s upside is limited until this becomes a reality (in works with validity proofs).

Value Accrual: Rollup tokens

In theory, the rollup tokens have a lot of potential value to capture if you believe that

1. MEV/execution is the main long-term revenue driver
2. Rollup tokens will capture all of the value in their ecosystems

For number 1, this seems likely as DA becomes a race to the bottom in some respects. For number 2, this is much more tricky. Our first datapoint on this is the Optimism-Coinbase deal, in which Optimism gave Coinbase “up to 2.75%” of the OP supply in exchange for 15% of gross profits or 2.5% margin (whichever is greater) in perpetuity. This deal, if used as a benchmark moving forward, would lead us to believe that rollup tokens will not capture as much value as theoretically possible and that the majority will have to come from first party (i.e. Optimism Mainnet, Arbitrum One) instead.

We can look at the recent ApeDAO proposals too. These proposals give ApeDAO the ability to use APE as their gas token and to retain the MEV/execution fees on the chain. Even DA is potentially outsourced, and so the benefit for rollups here is the liquidity and brand.

Future Rollup Constructions

1. Ethereum L2s: First instantiation of rollups like Arbitrum and Optimism. Execution is outsourced to the rollup and everything else (settlement, da, consensus) is through Ethereum.
2. Ethereum L2 + Alt-DA: This is the second stage and the one we’re entering now. You keep the “Ethereum alignment” but use another source to increase throughput/lower fees.
3. Sovereign Rollups: This is the long-term goal for blockchains like Celestia. You go one step further than the iteration above and remove the bridge and dependency on Ethereum completely. These are more similar to Cosmos appchains but they would share a DA layer, allowing for safer bridging.

Celestia explained from an Ethereum alignment perspective in 6 steps:

1. let’s build a secure DA layer for Validiums
2. every external DA acts as a DAC with an honest majority assumption, let’s try adding economic guarantees
3. data unavailability is not provable externally, but

— donnoh.eth 💗 (@donnoh_eth) December 14, 2023

Supporting Ethereum L2s is the least cool thing that Celestia can do

— c-node (@colludingnode) December 13, 2023

At the end of the day, everyone has their own blockchain, and everyone has their own token. The goal is to have strong security guarantees and with that means a need for token demand.

modularism, not maximalism*

*as long as i’m included in everything

— ceteris (@ceterispar1bus) September 15, 2023

You play to win the game.

Is it all modularity though? Are L1s dead? The comeback of Solana would suggest not, along with other L1s that are doing unique things like parallelizing the EVM (Monad & Sei) or introducing new consensus protocols with new VMs (Sui & Aptos).

L1 Wars Revival? Monad, Sei, Berachain, Sui, Aptos & More

Wait, L1 Wars are back?

“And what’s the deal with L2s. If the rollup is so much faster and cheaper, why don’t they just make the base layer out of whatever the hell they’re doing on the L2?” pic.twitter.com/XETvbVfKa7

— Doug Colkitt (@0xdoug) December 9, 2023

While the Ethereum ecosystem is moving towards a rollup roadmap, and new projects like Celestia, EigenDA and Avail look to extend this, the monolithic/integrated architecture is by no means dead. If anyone thought this, the last few months of Solana and more recently Cosmos chains should put that all to rest. There are a few unique L1s out or coming out soon worth keeping tabs on.

• Monad: An EVM based L1, Monad seeks to substantially increase the throughput of the EVM through parallelization and other improvements. Monad has been working on optimizations in 4 areas:
  • MonadBFT: A derivative of Hotstuff, MonadBFT is a high performance consensus mechanism with 1 second slot times and single slot finality.
  • Deferred Execution: In Monad, execution is decoupled from consensus. This allows for significant throughput increases as consensus can come to the order of transactions before executing.
  • Parallel Execution: Uses optimistic execution. In contrast to Solana, where writes are required to be specified up-front, optimistic execution essentially executes all transactions “optimistically” and then re-tries the ones that conflict (later transaction is re-executed).
  • MonadDb: A custom database for storing blockchain state. You can think of it as “Firedancer for the EVM”.

  All of these optimizations are done with preserving Ethereum tooling compatibility and wallets, devs and users can all integrate seamlessly.

• Sei: A Cosmos appchain that is live today, recently announced their own parallelized EVM solution. Sei’s EVM aims to make optimizations similar to monad like optimistic execution and SeiDB while preserving backwards compatibility. This thread has some good discussion between the Monad and Sei teams. Parallelizing the EVM is something more are talking about these days.
• Berachain: An EVM-equivalent Cosmos appchain, Berachain uses a novel “proof of liquidity” mechanism for sybil resistance. Instead of securing the network with the native PoS token, Berachain will utilize assets like BTC, ETH and others in liquidity pools. The exact design has not been released/made public yet. They have also developed Polaris, their modular framework for integrating the EVM into applications.
• Sui/Aptos: the Move chains who each use Narwhal as the consensus mechanism. Sui recently released zkLogin & zkEmail. zkLogin allows users to create addresses with web2 credentials, looking to fix the challenging onboarding process in crypto today.

And speaking of L1s, we should talk about the hottest one today, Solana.

Solana Separates from the Pack

Chicken or the Egg

In last year’s “Year Ahead for Infrastructure” report we had a section on Solana and concluded with the below.

“Solana is a truly differentiated product in an industry with so many copycats, and if you’re going to pursue the monolithic vision, it would probably look something like Solana. It’s also important to point out that so far, all blockchains have failed to scale. Ecosystems going through what seem like existential crises are nothing new; both Bitcoin and Ethereum went through their own challenges (Mt. Gox for Bitcoin and the DAO hack for Ethereum). It’s now Solana’s turn with the FTX collapse, and while surviving is by no means guaranteed, if they do, they’ll come out of the other side better for it. Encouragingly, DeFi protocols like Mango, Drift, and Zeta, among others, are all working towards new versions, with plans to go live soon.

Solana is dead. Long live Solana.”

While sentiment was at an all-time low, there were reasons to be constructive and look at Solana objectively. In 2023 this trend continued, with the technical fundamentals improving but the narrative refusing to adjust. That was until the past two months, as nearly every metric for Solana has been seeing hockey stick like growth. The industry finally seems comfortable saying that Solana, along the likes of Ethereum and Cosmos, has earned its place. Did fundamentals lead price, or is price now changing the fundamental? Was it the chicken or the egg?

It’s a trick question; the answer is both.

The recent rally in SOL has led both DEX and NFT volumes. DEX volumes started picking up after SOL 2x’d from $20→$40 as people starting chasing Solana ecosystem tokens.

DEX volumes blew past previous ATHs and were up >20x from where they were just a couple months ago in September.

This led to the highest Solana DEX volume % compared to Ethereum we have seen. But maybe more importantly, it did it without TVL budging too much. Solana DEX volumes hit >50% of that of Ethereum the week of December 11-18 on <5% of the TVL, and on a couple days, volume actually surpassed. The Solana architecture allows for more capital efficiency and Solana should be expected to have a much higher Volume/TVL ratio than others moving forward.

On the flip side, while we can appreciate the capital efficiency, there are benefits to having a lot of passive TVL, especially for LSTs. We saw this impact last week as someone selling ~$8m of mSOL on-chain led to a short-term de-peg and liquidations on some money markets. Solana still needs more on-chain liquidity.

All this activity has led to a dramatic increase in Solana fees, most notably priority fees. In fact, fees from non-vote transactions are now making up >50% of fee income for validators. Priority fees surpassed their previous weekly high (the previous week) by 2.7x, and are up ~10x from where they were throughout 2023.

This is extremely important. As we’ve mentioned before, fee voting has a natural centralizing force because fee expenditure for validators is fixed but income is variable (larger validators make more). Seeing more income from non-vote fees is an extremely healthy development.

Next was NFTs, who didn’t really start their run until they could do so in dramatic fashion at the end of November. Solana NFTs were not really participating until SOL had 3x’d and eco tokens had done even better. Again, people moving further and further out on the risk curve as SOL goes higher should not surprise. Early buyers feel rich and later buyers want to make up for missing the original rally’s.

Putting these numbers in perspective, both DEX and NFT volumes went up close to 10x from October 1st. As we said prior, DEX volume led NFTs, who really had their blow-off at the end of November.

Lastly, as one more data point, bridge volume tells a similar story. Bridge volumes started spiking at the beginning of November and around the 6th to 9th as DEX volumes increased. Then they died down a bit and picked back up at the end of the month with NFT volumes. For the month of November, there was ~$0.5B of inflow to Solana from other ecosystems.

Solana NFTs have historically traded with a fairly strong negative correlation to the price of SOL, i.e. SOL up, NFTs down (denominated in SOL). This is the first time in a long time that SOL/USD has been going up and NFTs denominated in SOL are going up, suggesting new money flowing in and not just Solana native traders going in/out of NFTs.

So, you may read this and say price moves fundamentals, which is true. You cannot deny what price does to an ecosystem, as developer interest has also been spiking with the latest activity.

Developers attention continues to dramatically increase on Solana pic.twitter.com/KAbXqoXLv1

— Jacob Creech (@jacobvcreech) December 13, 2023

And more data from Alliance, showing a strong recovery in developer interest over the second half of 2023. We’d expect this share to continue to increase.

But it’s also not the whole story as this was, in our opinion, bubbling under the surface for the entire year. Solana has gone through numerous upgrades that have allowed it to handle the recent demand, something it wouldn’t have been able to in the past. And maybe most important, they have one of the most passionate and fastest growing communities.

The dark horse that not many are talking about rn is — not the tech— but how fast Solana’s community is growing

each event is getting more and more turnout

everyday people are tweeting about using solana for the first time

the momentum is picking up

— mert | helius.dev (d/acc) (@0xMert_) December 1, 2023

But enough about price and community. We want to take the rest of this section to highlight some notable projects upcoming and applications that truly are only possible on Solana.

Firedancer/Frankendancer

Firedancer is the most anticipated development for the Solana ecosystem over the next 2-3 years. It’s a new validator client written in C, a lower-level language than the Labs client in Rust. In layman’s, it’s a complete re-write from the ground up.

Recently, Frankendancer was launched on testnet and is expected to go live in the first half of 2024. Frankendancer is just one component of the Firedancer client, namely the networking one that handles all of the inbound and outbound. This is QUIC, TPU (transaction processing unit), Sigverify and dedup on the inbound side and blockpacking & Turbine on the outbound. The rest of the client uses the same Labs components live today. The full client with all three components is expected to go live in 2025, although timelines may vary due to the complexity and constantly changing codebase.

To give context as to how the Firedancer team goes about building, they have created their own QUIC implementation as the original is essentially too complicated and large of a scope for what Solana needs it for. fd_quic looks to simplify and reduce the spec’s size and complexity.

I personally am super disappointed with the QUIC protocol for high speed comms. It is complicated, the reference implementations are slow, and the spec is massive.

We have spent the better part of a year with multiple engineers to rebuild QUIC. Aiming to design something better

— 🍈 cantelopepeel 🍈 (@CantelopePeel) November 20, 2023

The main improvements Firedancer has made on the networking side are:

• Receiving transactions have shown 40GB/s on FD vs 0.2GB/s on Labs
• New QUIC implementation, fd_quic
• Modular architecture: instead as running as a single process, is split between tiles (individual Linux C processes)
• Custom networking stack: utilizes receive side scaling to load balance network traffic across multiple CPUs
• Tile system that facilitates NUMA Awareness, Cache locality, Lockless concurrency and Large page sizes
• Advanced data parallelism
• FPGAs to increase signature verification to ~8 million/s (vs 1m/s GPU and 30k/s CPU)
• Defense in Depth: designed to mitigate attacks/vulnerabilities/bugs in one part of the stack from affecting everything else

For a full, longer-form writeup I would recommend this post from Helius as it’s the best deep-dive on Firedancer done yet, and goes into detail on all of the points in the bullets above.

There aren’t a lot of negative angles to look at when it comes to Firedancer, but if I had to come up with one it would be that there’s a real chance Firedancer doesn’t increase client diversity at all (as economically, no one would be incentivized to run a less performant one) and due to the complexity of maintaining the client, Solana would be reliant on Jump. There’s a possibility that validators will run multiple clients as a backup, and the Solana Labs client will improve a lot over time, but it’s a non-zero chance that this is how it plays out.

good solana fud (imo):
– fee market theory good, implementation bad. poor implementation can lead to edge cases in bull
– firedancer won’t increase client diversity & presents a new centralization vector as fd team will be only ones capable of maintaining
– closed-source ethos

— ceteris (@ceterispar1bus) November 7, 2023

With that being said, Firedancer will still, at a minimum, be a big boon to Solana from a performance perspective; that part is not really up for debate. And listen, I’m not gonna fade buffalu.

doubt it.

will be the most high performant open source codebase known to man. will be rough at first and take a few months to stabilize. no software is bug free.

after that will be mostly derisked and will rip faces.

— buffalu (@buffalu__) December 9, 2023

In addition to Firedancer, there is another new client in development by Syndica called Sig, one that is written in Zig and optimized for reads vs writes (as a real-world example, optimizing for reading/refreshing your twitter feed vs sending dm’s). Sig will add to Solana’s client diversity, assuming everyone doesn’t just run Firedancer.

Payments: Where Solana can Excel

While Solana can be successful in numerous sectors like DeFi, NFTs, DePIN and more, the one in which it can really excel vs other networks is payments. This is not to say Solana can’t excel in DeFi or NFTs, after all they did just flip Ethereum L1 in both of these metrics recently. However, this is an infra report, so we’re going to talk about infra-specific verticals.

Payments, especially micropayments, only work when transaction fees are fractions of a cent. This is an area Solana has a competitive advantage in and we’d like to see significant traction in 2024. Never having simple payment infrastructure has led the industry to never exploring what can be built on top of payments. It’s a massively missed opportunity for the OG use-case.

Controversial opinion: No chain that posts calldata to Ethereum L1 will get traction for low cost payments (p2p, commerce, etc)

EIP4844, compression, etc, none of these will result in sufficient cost reduction. You’re still overpaying for security. Off-chain DA is the only way https://t.co/BRwIU7jRVV

— Peter | Reservoir (@ptrwtts) December 3, 2023

One way to visualize payment activity on Solana is through USDC metrics, and there are some notable things that stand out. First, nearly 2/3 of USDC transfers on Solana are for <$5. Taking advantage of Solana’s sub-cent fees makes this practical. It is not a surprise that such a large portion of USDC transfers on Solana are in this category.

Second, in November we saw the amount of transfers >$5 increase substantially. If you analyze the chart below, there is a much wider distribution of transfer sizes than we’ve seen all year. This suggests new users with different payment patterns, and also since the value of assets (like SOL) on the chain have gone up, a wealth effect.

Lastly, larger transfers are starting to happen on Solana as well, with >20k monthly transfers of at least $100k over the past four months. Circle’s launch of CCTP on Solana should accelerate all of these metrics. And on the topic of Circle, they just launched EURC on Solana as well with numerous day 1 partners.

Those were the high level metrics. They show an architecture that can handle mass low-value payments with increasing demand for larger ones more recently. Now, we want to dive into some of the actual payment apps and what they bring to the table.

• Sphere: provides fiat on/off ramps and features like subscriptions, invoices, payment links, etc. Applications can use Sphere and their no-code dashboard to integrate. Recent partners are with DRiP to enable credit card payments for droplets, Squads multi-sig to pay for the higher membership tier, and more recently an integration with Helium mobile to manage Helium credits. Sphere recently came out of stealth/beta for their official launch.
• Code: For the deep dive, check out our markets report from November. For the tl;dr, Code is a payments app that is uniquely focused on micropayments. Code payments are facilitated with their own token KIN, which has been a point of criticism, but they recently open-sourced their entire stack, so theoretically someone could fork it and use USDC instead if they wanted to.
• Sling: P2P global payment app where you can send money to anyone anywhere for free (currently). Recipients don’t even need the Sling app either as they can just use the link to deposit into their bank account. The wallet is self-custodial and holds USDC. I’d recommend the Breakpoint presentation if you are curious to learn more (the app architecture and demo starts at 11 mins).
• Elusiv & Light Protocol: Privacy focused protocols who are doing work with the Token22 standard to enable private payments.
• TipLink: Allows people to send crypto with only sending a link. When clicking the link, the receiver has a wallet created for them and receives the funds. It’s a very user/normie friendly way to onboard people. TipLink was on display at Breakpoint as attendees were onboarded and given free NFTs or coins.
• Ottr Finance: Self-custodial wallet with fiat on/off ramps. Ottr has also integrated numerous popular apps in the wallet which makes it easy for new mobile users to onboard and start transacting on-chain.
• Helio: Platform that focuses on subscriptions, e-commerce and selling digital goods, making it easy for creators to take payments.
• Candy Pay: Mobile focused SDK that makes it easy to add crypto payments to mobile apps.
• Shopify Integration: Solana Pay integrated with Shopify in August. The Shopify team is doing a lot of work here to expand their crypto offerings.
• Coinbase Integration (?): Reported on December 1st, Coinbase intends to explore Solana to leverage their payment infrastructure. This is notable because Coinbase has their own L2 Base that they are trying to push for payments as well, but Armstrong has noted Solana and how payments need to be under one cent.

This list above is by all means not exhaustive, so for a complete list of all payment apps you can check out https://solanapayments.fun/. Solana has seen strong momentum in this sector and people are taking notice.

imo, the Ethereum community should be alarmed about Solana being quite competitive for payments.

Everyone knows that Solana has payments far “under one second and one cent.”

But fewer know about “Solana Pay”, an open, decentralized high-level payments framework plus integrated… https://t.co/aDjowKVxZ0

— Ryan Berckmans ryanb.eth (@ryanberckmans) December 1, 2023

OPOS: Unique Solana Applications

Outside of payments, we want to highlight some other applications that really take advantage of Solana’s architecture and may not be as well known. These are the only possible on Solana apps (technically, you could build these on other high performant L1s, we just have not seen it done in production).

• Phoenix: crankless limit orderbook DEX on Solana. They recently hit their $1B in cumulative volume milestone. Main competitors are OpenBook and newly announced (but not live) Starport. LOB’s are specifically enabled by cheap, high throughput chains.
• DRiP: A platform for creators that utilize cNFTs, making it cheap & easy for new artists to onboard to Solana. DRiP has some of the best distribution in crypto and is a true consumer-facing application. They recently launched droplets 2.0, their own in-app currency used to reward users and give back to creators.
• Parcl: A unique product that lets users speculate on real estate prices with up to 10x leverage. They recently launched their own points program.
• Sanctum: An innovation in the LST space, Sanctum is essentially a liquidator DAO that accepts all LST’s for SOL. This has the potential to be a massive unlock for Solana DeFi as all LSTs could be added to DeFi protocols without a vigorous underwriting process. Most of the reason why LSTs are winner take most is because the moat they get from on-chain liquidity. With Sanctum, they are willing buyers of any LST, for a fee. This would also reduce contagion risk in Solana as no single LST would garner a monopoly. This would also allow Solana’s single stake pools to be more viable. They recently announced Sanctum Infinity with plans to go live in the next ~2 months.

There are of course many more successful apps on Solana besides these. LST protocols, derivatives, money markets, DePIN and more. Solana is carrying a lot of momentum into 2024 and we’re excited to see what new gets built.

An under-rated component of having a scalable, low-fee blockchain is that it enables non-financialized applications, as the cost of transacting is not a deterrent or calculation a user needs to make. Users can just use applications without worrying about how much money they’ll lose to gas fees. When it becomes expensive to use apps, more development is driven towards applications that offer incentives, and it becomes harder for non-financialized apps to compete. This is why we expect payments to thrive on Solana.

The future of cross-chain is intent-based, with value accruing to solvers.

 We want to start with a categorization of bridges which will provide a mental model for the rest of the section. One way to categorize bridge architectures is token bridge vs liquidity network. 

Bridges that lock (or burn) tokens on the origin chain and mint wrapped versions on the destination chain are considered token bridges. Most examples here are public-goods canonical bridges of chains like IBC or rollup bridges, however, there are also some (potentially) for-profit third-party token bridges such as LayerZero omnichain tokens, LayerZero Aptos, Wormhole Portal, etc. 

The other bridge type is known as the liquidity network. Liquidity networks don’t mint new tokens on the destination chain. Instead, they deal with already existing ones. These are typically native tokens (e.g. OP for Optimism) or their canonical representations (e.g. ETH bridged to Optimism via the canonical Optimism bridge). Since liquidity networks don’t mint new tokens, they need available liquidity to serve cross-chain transfers. Historically, they have been limited to on-chain liquidity pools however as they evolve to adopt intent-based architectures, they can also tap into off-chain liquidity via a network of “solvers”. 

The advantages and disadvantages of each solution can be summarized below. 

	Token Bridge	Liquidity Network
	Tx-Based	Tx-Based	Intent-Based
Reliability	Unbounded liquidity;  can serve any level of user demand as tokens can be minted at the destination as much as needed	Value transfers are bounded by the size of on-chain liquidity pools managed by the bridge.	Can use off-chain and on-chain liquidity sources.
Liquidity Fragmentation	Yes. As users are served by different token bridges, they end up with multiple versions of the same asset (e.g. axlUSDC, layerzeroUSDC, etc.)	No. Deals with native tokens or canonical tokens.	No. Deals with native tokens or canonical tokens.
Vendor lock in	Yes	No	No
Direct Costs	Tokens are minted 1 to 1, w/o slippage. That said slippage is still incurred as users swap between different versions.	Primary costs include LP fees and incentives to rebalance liquidity.	Primary costs include Solver fees and incentives to rebalance liquidity.
Gas Usage	High	High	Low
Speed	Slow	Slow	Fast
Users’ exposure to bridge risk	As long as they hold the wrapped assets at the destination.	Only during in-transit	Only during in-transit

Note that this is purely an architectural categorization and is orthogonal to the trust assumptions bridges are built upon.

Categorization of particular bridges may not always be clear-cut as they may often adopt hybrid solutions. That said, moving forward, we think users will increasingly prefer to move value via intent-driven liquidity networks. To see why let’s take a step back and reflect on how we got here. 

For-Profit Token Bridges Becoming A Thing Of The Past

Historically token bridges weren’t necessarily non-profit. Around the time of the “Solunavax” L1 wars of the past cycle, most L1s lacked a canonical bridge and profit-seeking token bridges filled the immediate user demand by hitting the market at the right time. As these third-party bridges minted their tokens, chains ended up with many different representations of the same token. This not only fragmented UX and liquidity but imposed risks of vendor lock-in. However, most of these dynamics have changed since.

Today, most of the chains have public goods canonical token bridges, designed to make minimum trust assumptions over the chain itself. With the rise of rollups and cosmos chains, most new chains also launch with canonical bridges by default, making it harder for third-party token bridges to capture value. 

Another factor that recently drastically changed the bridging landscape is USDC’s omnichain standard CCTP (cross-chain transfer protocol). Launched by Circle earlier this year, CCTP already supports several chains including Arbitrum, Ethereum, Avalanche, Optimism, Base with others to come. Any user-facing app on these chains can now integrate with CCTP and have Circle *natively* transfer USDC cross-chain.

CCTP has extremely strong advantages compared to alternatives and little to no disadvantages. 

1. Best Execution (No Fees, No Slippage): USDC can be burned/minted 1:1 with no liquidity pools or slippage. Circle has expressed no intention to charge fees for their attestation service; a chain-agnostic USDC brings them a competitive edge over others justifying their motivation to offer this service for free. While apps can charge fees to users, fee extraction will be a race to the bottom as free services pop up. The bottom line is that CCTP will offer the best possible execution for cross-chain USDC transfer. Indeed, the same may be said for non-stable cross-chain transfers as [swap asset X for USDC → transfer USDC → swap USDC to asset Y] might be a very competitive execution path.
2. Liquidity De-Fragmentation: More native USDC removes the painful UI/UX issues dApps/users have historically faced due to the abundance of many different versions of USDC.
3. Capital Efficiency: Apps can natively mint/burn USDC for transfers removing the need for pools and incentives for LPs.
4. Security: No liquidity pools acting as honeypots for hackers. Users won’t be taking on additional trust assumptions when bridging USDC from one chain to another. 
5. Fast Exit for Rollups: Rollup users don’t need to wait days or hours to have their USDC on Ethereum. They can exit as soon as Circle provides an attestation for the USDC burn event.
6. CEX Support & Direct Fiat On/Off Ramps: As native USDC can be blacklisted by Circle, it’s the preferred asset for CEXs from a regulatory perspective.

Unsurprisingly CCTP had a very strong adoption and has been substantially growing its market share by volume since its inception earlier this year. 

Looking at USDC volumes for Stargate and CCTP across pathways supported by both, we can see Stargate losing market share to CCTP. For better or worse, CCTP is eating the lunch of stablecoin bridges.

Thus far, we mentioned two major factors changing the bridging landscape; (i) more chains with canonical bridges (particularly rollups importing Ethereum assets) and (ii) USDC/CCTP. Given that USDC and ETH are by far the most bridged assets (USDC had been accounting for 35%+ of total bridged volume with ETH closely following it) both of these factors directly reduce the TAM of profit-seeking third-party token bridges. Moving forward, we expect the value capture of token bridges to be limited to the long tail assets (e.g. LayerZero OFTs) or exceptional cases like BTC (Bitgo’s WBTC) where the intention is to use the asset on another chain rather than transferring value cross chain.

The future of bridging is intent-based

CCTP and canonical bridges will help increase the share of canonically denominated assets and thereby solve most of the liquidity/UX fragmentation issues. However given their conservative nature, they will always be slow; rollup bridges may take hours or weeks and CCTP may take tens of minutes/hours to be validated.

As most users will want to move fast, CCTP and canonical bridges won’t directly be used by users. Instead, they will act as back-end services for user-facing apps that compete on speed, capital efficiency, and gas costs to capture value. This is where we think intent-based designs will stand out against the competition.

Across stands out as the most mature intent-based bridge

Perhaps the most mature intent-based liquidity network for cross-chain transfers (swap X on chain A for X’ on chain B) is Across Bridge. For those who are unfamiliar, Across is particularly active in pathways between Ethereum and its rollups. With the rising rollup adoption this year, it has been increasing its market share substantially. 

We can take Across as an example to articulate our overarching thesis that the future of cross-chain will be intent-based. A unique aspect of intent-based liquidity networks is their ability to tap into off-chain liquidity through an open, permissionless marketplace of off-chain actors known as solvers (relayers in Across lingo). 

The high-level idea is simple; users outsource their bridging risks to solvers, who compete with each other to fulfill cross-chain transfer intents and in return capture fees. A flow of a cross-chain transfer via Across can be simplified and broken down into 3 stages as follows.

1. Intent Generation: Users deposit assets into an escrow at the origin expressing their cross-chain transfer intent. User intent also carries (implicit) fees payable to the relayer upon fulfillment. 
2. Fulfillment: To capture the fee, relayers compete with each other to be the first to identify the user intent and fulfill it at the destination. As mentioned, solvers use off-chain liquidity, paying users out of their own pockets at the destination.
3. Settlement: The fulfillment tx at the destination chain is relayed back to the origin chain where it gets validated. Upon validation, the winning relayer gets to unlock assets held in the escrow. Across uses a UMA’s optimistic oracle for validation to minimize on-chain gas costs.

A key aspect of this design is that users have their cross-transfer intents immediately served by relayers who only get paid afterward. This ensures that users experience maximum speed, while relayers minimize their operational expenses including the cost of lending capital, gas consumption, etc. 

In tx-based bridges, the time it takes for users to transfer tokens across chains can at best equal the time to finality on the origin chain + time to finality on the destination chain. Intent-based bridges can go beyond this limitation by relying on relayer competition. A relayer can assume (and price) the risk of a re-org and fulfill user intent at the destination, even if the tx on the origin chain hasn’t been included in a block yet or included but not finalized. Interestingly, we see this playing out in the wild. Users enjoy faster swaps as relayer competition heatens. 

The settlement, on the other hand, is optimized for gas minimization. It’s desired for repayments to happen only periodically (every 2-4 hours) and in batches to reduce the amortized gas costs of each repayment. Another key factor that minimizes gas is Across’ use of UMA’s optimistic oracle for validation.

The final piece of the puzzle is reliability. As a liquidity network, Across needs to make sure there is always available liquidity to serve users at the destination to offer a reliable service. Thus the protocol takes an interest in helping relayers rebalance their liquidity after serving users. To this end, Across uses on-chain liquidity pooled by passive LPs. The pools have a hub and spoke model with one large pool sitting on the Ethereum mainnet and smaller spoke pools sitting on destination chains. 

Today, Across protocol takes a proactive approach to rebalancing; it periodically balances the liquidity of spoke pools by transferring funds between spoke pools and the hub pool. This allows Relayers to request and have their repayments sent to their chain of choice regardless of where users may have made their deposits. Pools also act as backup for off-chain liquidity in case relayers omit or fail to serve users’ intents.

As of now, when rebalancing the pooled liquidity, Across uses canonical bridges of the chains. However, this is about to change with the upcoming universal bridge adapter (UBA). With UBA, instead of protocol transferring LP funds on-chain via canonical bridges, it will also outsource this task to off-chain relayers. To do so, Across will implement “balancing” incentives; when a particular spoke pool is under-balanced, rewards will be paid to those who deposit funds into that pool and penalties will be charged to relayers taking out repayments from that pool. 

Post UBA, Across won’t subscribe to any particular method for bridging. Relayers will be free to pick any bridge of their choice to rebalance pools and assume all risks associated with it. Realistically, they will likely use CCTP whenever they can. UBA will also allow Across to support chains w/o canonical bridges.

Where will the value accrue?

As apps adopt intent-based architecture and solvers take on more roles, we think more of the value will accrue to them and less will accrue to passive LPs. Indeed, it’s possible that at maturity, there won’t be any passive LPs; all liquidity will be of value-in-flight rather than value-at-rest. This isn’t to say there won’t be ways for retail to earn passive income. Users may earn a share of the solver income by delegating/staking tokens. However, unlike today’s landscape where tokens are associated with particular apps, they may be increasingly used to access the income of particular solver(s) who may participate in one or more independent apps. As intent-based apps for cross-chain value transfers (Across, DeBridge’s DLN, Hashflow, Connext, Chainflip, UniswapX, etc.) request similar capabilities from solvers, it’s reasonable to expect the same solvers to participate in many.

Another angle to approach this question is to answer which types of applications will have the highest value capture opportunities for solvers. There are strong reasons to think the lion’s share will be on DEXs (swap X at origin for Y at destination) as opposed to bridges (swap X at origin for X’ at destination). This is because users are way less aware of the implicit/explicit fees they pay when they make a swap (X for Y), as opposed to a transfer (X for X’) and there is simply more MEV in swaps than transfers given the price risk. 

Lines get blurry as intents generalize

Interestingly the lines between apps may also get blurry in an intent-centric world. Similar to other intent-based apps such as CoWSwap, UniswapX, and others, next year Across will introduce “hooks” to extend its capabilities and improve on UX.

With hooks, the hope is for users to express intents in the form of “bridge + action” bundles. At the very least, this will offer a much better UX as it will allow users to take actions (swap, stake, mint, etc.) at the destination chain w/o having to own any gas tokens or switch RPC endpoints. At best, it will allow Across to not just support bridge intents but all sorts of cross-chain intents. While this roadmap makes sense, we think it’s still early for hooks to be widely adopted by next year; the designs for even the most basic cross-chain intents (e.g. transfer, swap) are still in their infancy. Nonetheless, there is a clear trend for “intents” to extend their capabilities to more use cases. 

The deeper takeaway here is that we believe intents aren’t limited to cross-chain transfers or limit orders and instead can be generalized to all use cases of today and much more. This is why we prefer the term “intent” over a specific action such as “swap” or “limit order”. Similarly, we like to use “solver” as an umbrella term to refer to all sorts of off-chain permissionless actors, regardless of the application type. 

Generalizing intents can be so powerful that it justifies re-imagining an entirely new architecture (consensus, mempool, execution, etc.) which is what Anoma is after. For those interested in better understanding what an “intent-centric world” may look like we highly recommend our 3 parts, WTF is Anoma series.

Solver Centralization Getting Real As DEXs Evolve

Similar to bridges, DEXs are also evolving into intent-based architectures, making use of solvers to offer competitive prices to users. Maintaining a decentralized solver network will be among their biggest challenges.

How We Got Here?

In the classic Uniswap experience of the early days, users would sign swap txs and the Uniswap routing API would search through the Uniswap pools to find the optimal route for execution. This worked well in the early days as Uniswap was where all the on-chain liquidity was. As more DEXs became available, there became the need for aggregators. Unlike the Uniswap router, aggregators’ routing isn’t limited to Uniswap pools. As they search through all sorts of on-chain liquidity sources, they can often quote better prices to users. Nonetheless, onchain aggregators are still limited primarily in two ways (i) they need endless integrations to support new liquidity venues and (ii) their reach, for the most part, is limited to on-chain sources. Both lead to users potentially missing out on liquidity and getting sub-optimal prices.  The natural next step in this evolution is to outsource routing to permissionless off-chain actors. This is where intent-based apps with solvers come into play.

CowSwap, 1inch Fusion, UniswapX all rely on a marketplace of solvers who are completely free in how they fill an order; they can use on-chain liquidity pools, flashloans, their inventory, private order flows, etc. CoWSwap still accounts for the most volume as the oldest protocol amongst the three, however, the entrant UniswapX is already gaining significant market share.

An Intent, a Limit Order, an RFQ walk into a Bar…

How would you feel if you had 5-10 butlers waiting to receive your order and then bringing you several options to choose from, one better than the other?

Solver competition is a key aspect of intent-based DEXs. In CowSwap, solver competition takes place in the form of single-block batch auctions while 1inch & Uniswap utilize Dutch auctions. In Dutch auctions, orders are submitted with a decaying price curve and the first solver to fulfill the order wins. With Single Block Batch auctions, all trades in a batch are cleared with a uniform price. This is unlike CFMM-based DEXs where all individual orders are executed at different, order-dependent rates even if they are identical.

There are strong reasons why intent-based DEX may offer better prices than AMMs of today.

1. Better pricing as a result of solvers having access to diverse liquidity sources both on-chain and off-chain and competing against each other in OFAs.
2. Lower chance of losing funds out in slippage or MEV and in some cases, surplus (positive slippage) being returned to the user. 
3. Minimum gas usage; users don’t pay gas for failed transactions and benefit from economies of batch filling.

Finally, with UniswapX and others supporting cross-chain swaps complex UX of bridging (switching RPC endpoints, owning gas tokens, etc.) will be abstracted away from users. These are strong reasons to believe intent-based volume will outcompete pool-based volume as move forward.

50 Shades of Solver Decentralization

As these DEXs gain a larger market share solver decentralization will become an integral part of DeFi.  On that note, we take a look at how these protocols allow potential solvers to operate within their networks. 

On 1inch, the benchmark to be a resolver on 1inch Fusion is based on Unicoin power. When users stake 1inch tokens, they receive st1inch and Unicoin power, based on the lockup duration of the staked tokens. Addresses with 10% or more Unicorn power in the network qualify to become resolvers. Resolvers can also attract Unicorn power from users with 1inch tokens in exchange for rewards APR set by the resolver. Similarly, CowSwap solvers have high capital requirements. Those interested in running a CoWSwap solver must up a bond of $500K cUSDC and 1.5M $COW tokens. Capital requirements for 1inch resolvers are also fairly high with bonds ranging between $600k to $1.5m+ based on today’s prices.

Protocol	Solver Capital Requirements	Unique Solvers (Last 30 Days)
CowSwap	$500K cUSDC + 1.5Mn COW (340K USD)	17
1inch Fusion	Top 10 staked 1inch tokens + Unicorn Power	7
UniswapX	No Strong Requirements For Fillers (‘Quoters’ are currently permissionned)	33

High bond requirements are there to help protocols enforce rules on solvers, discourage misbehavior, and keep them accountable. For example, CowSwap suffered the loss of funds due to an exploit back in February 2023 resulting from a mistake on a solver’s end. However, the lost funds were reimbursed from the solver’s bond of funds. Another example is when on Cowswap, it was observed that solvers were “pennying” or manipulating clearing prices to win more auctions. CIP-13 was then successfully passed wherein solvers found guilty of “pennying” would be slashed. 

While high bonds are effective in keeping solvers accountable they also increase barriers to entry. In theory, increased competition should lead to better execution for users, both in terms of speed and costs. A good example of this is seen in practice with Across where the speed of transfers increases as more relayers compete against each other. 

However, rather than pure solver count, a factor more relevant to DEXs is the competitiveness of individual solvers. This is because the task at hand inherently requires high levels of sophistication given the price risk. In UniswapX, while the number of unique solvers is relatively high, 83% of the volume is still captured by 3 solvers with Wintermute now taking up close to 48% of the total volume, followed by Tokka Labs and Riven with 24% and 11%. We see a similar picture in CowSwap and 1inch Fusion with few solvers making up most of the volume.

The centralization forces in play are very reflexive. The more access to on-chain and off-chain liquidity sources a solver has, the better the solutions they can offer which increases their success rate and leads to higher revenue. With more revenue, solvers can get more private order flow and further benefit from economies of scale. 

Unsurprisingly, the largest solvers are already operating across protocols. For example, 1inch Labs is not prominent on 1-inch Fusion alone but also on CowSwap. Wintermute, Alpha Labs were active in both UniswapX and 1inch Fusion, Laetres and Otex were active in Cow Swap and 1inch Fusion, etc. Some of them dropped off 1inch Fusion as 1inch increased capital requirements for solvers. 

Collaborating with participants in the transaction supply chain such as liquidity routers, searchers or builders can open up new avenues of profit for solvers. 

Here, it is important to distinguish the roles and motivations of solvers and searchers. While both are profit-seeking entities, solvers optimize transaction workflows for users, while searchers add or reorder transactions to form profitable bundles. Moving forward, we can see solvers and searchers working closer. Searchers can place solver transactions in a bundle where it is most profitable, leading the solver to have more surplus (positive slippage). The solver could in turn share a portion of this surplus with the searcher. If solvers and searchers/builders begin to collaborate directly, it could lead to even fewer parties winning higher volumes of intents and transactions, increasing the barriers to entry and profitability. 

THORChain & Chainflip: The Decentralized  Highway For Bitcoin Is Scaling Up

THORChain had a very successful 2023. Recently it has become the 3rd largest DEX by volume after Uniswap and Pancakeswap and the 5th largest exchange (incl. CEXs) for BTC spot trading.

The rise in volumes came after the launch of streaming swaps. That said, synths and savers, launched earlier have played a major role in making streaming swaps so effective. 

 

A Refresher On THORChain’s Evolution

Before pealing the onion and assessing some key metrics of the projects, we first need some context on THORChain and its recently launched features and products. 

In the early days, THORChain pools were fully composed of dual LPs depositing 50% Rune and 50 % non-Rune assets (BTC, BNB, AVAX, ETH, USDC, etc.). In the last 2 years, THORChain has evolved a fair bit. While the pools still maintain their 50/50 Rune/non-Rune formation, today the liquidity in pools is shared across different participants with different motivations. Namely, these are dual LPs, synth holders (savers and arbs), lenders, and the PoL (protocol-owned liquidity). 

Furthermore, THORChain no longer is limited to swaps but also supports savings (interest accounts), and lending.

• Swaps: Swap X for Y
• Savers: Earn X for X
• Lending: Borrow X for Y

While lending has yet to prove its pmf, savers and swaps have been widely adopted.

Synths

Synths are a powerful, unique design of THORChain which aren’t the easiest to grasp. 

Synths are THORChain’s native assets that can be minted through deposits into pools and burned through withdrawals from the pools. They represent native L1 assets (BTC, BNB, AVAX, ETH, USDC, etc.).

For example, I can mint 1 sBTC (synthetic BTC) by depositing 1 BTC into the BTC/RUNE pool. The sBTC minted is a native THORChain asset that can, under normal circumstances, be redeemed back for 1 BTC (or 1 BTC worth of Rune) at a later date.

Collateral for synths sits in THORChain pools and thus can be used for swaps, savers, and lending. This is different from a typical wrapped asset which would have its collateral sitting idle. 

In this sense, synths have a similar functionality to dual LP positions. They contribute to liquidity and deepen the pools. 

Since all THORChain pools have half Rune and half non-Rune asset formation so does the collateral backing the synth. However, unlike dual LP positions, synths are designed to have 100% price exposure to the non-Rune asset and suffer no IL.

This design relies on dual LPs and synths holders making complementary tradeoffs. Synth holders pass on their IL risk to dual LPs and in turn, forgo (some or all of) their earnings (block rewards and fees). Dual LPs take on a higher IL risk and in turn, get to capture the earnings foregone by synth holders which boosts their yield. 

Here is an imprecise but good enough, simple intuition on how dual LPs and synth holders impact each other.

Since the synths are an IOU on the non-Rune asset, when Rune outperforms the non-Rune asset, dual LPs get to capture a portion of the savers’ initial deposit. The same dynamic applies in the reverse direction. When Rune underperforms the non-Rune asset, savers capture a portion of dual LPs’s deposit. 

The surplus or deficit dual LPs’ experience, manifests as an amplified or minimized IL depending on Rune’s price performance against the paired asset. In a pool loaded with synths, dual LPs experience an amplified IL when Rune underperforms and a minimized IL when Rune outperforms. Indeed, when Rune outperforms, dual LPs can earn “impermanent profit”. Put simply, with synths, dual LPs get a levered long exposure on Rune. The exact relation can visualized below.

For those interested in learning more about synths and savers, we recommend checking out our THORSynths report and our related tweet thread.

PoL

With PoL (protocol-owned liquidity) the hope is for the protocol to throttle the levered long Rune exposure of dual LPs, maintaining it at a reasonable level. The synth utilization target is set at 50% of the total pool depth (and capped at 60%). If synth utilization exceeds the target, the protocol itself deposits dual-sided liquidity into pools to reduce the leverage experienced by dual LPs. It does so by taking out Rune from the Reserve, swapping half of it for non-Rune, and depositing it into the pool. When synth utilization drops below the target, the protocol does the reverse and withdraws away from the pools into the Reserve.

What Are Synths Good For?

So what are synths good for? There are 2 ways to use synths on the network; arbitrage and savers. Arbs bring volume and savers bring liquidity. 

Arbs (ie. synth holders) don’t accrue any earnings (liquidity fees + block rewards). Their only motivation is to perform arbitrage and capture the spread. To do so they use synths because synths are a lot faster & cheaper to deal with than native L1 assets, as they live on the THORChain blockchain.

For example, instead of waiting 30+ mins to arb the BTC and ETH pools using native assets, arbs can use synths to swap in and out of those pools every THORChain block (5-6 seconds), all while saving on expensive Bitcoin and Ethereum gas fees. With synths, arbs can correct the prices of THORChain pools much more effectively than before. As we will see later, this lays the foundation for the recently launched streaming swaps feature.

arb with synths (on the left) vs arb with native assets (on the right)

Savers Bring Liquidity

The other use of synths is to lock them in a vault for yield; ie. savers. Savers retain all the attributes of synths as well as their risks (to be detailed in the risks section) but instead of using synths for arbs, they lock it in a vault to earn yield. In doing so, they contribute to pool depth in a long-lived manner. 

Savers and dual LPs are two different types of liquidity providers with different risk/reward profiles. The design goal of savers is to take on no price exposure to Rune and earn single-sided yield (e.g. BTC Savers earn BTC yield over their BTC deposits). The yield for savers is typically much lower than those of dual LPs.

Savers appeal to a new set of liquidity providers who want to earn yield over their favorite assets (BTC, BNB, ETH, AVAX, USDC, etc.) without losing price exposure to them. These liquidity providers don’t have to reason about IL, buy Rune, or even be aware of Rune’s existence. 

Savers had strong adoption in 2023. The oldest BTC savers have had their BTC sitting on the pool for over a year now and have earned around 3% annual yield over their BTC. Recently the count of saver deposits as well as their sizes have grown substantially as visualized below. Today, roughly 1/4th of all liquidity in pools is savers.

Streaming Swaps Bring Volume

To recap, arbs bring *synth* volume that helps correct the prices, and savers bring liquidity. The next piece of the puzzle is streaming swaps. Streaming swaps bring organic volume by growing the size of native swaps.

Streaming swaps are intuitive to understand. They take a longer time to execute (max allowed is 24 hrs) but execute at a much better rate.  Effectively swaps are broken into multiple sub-swaps executed over time.  A streaming swap with a count of 10 sub-swaps makes the sub-swap/pool ratio 10 times better than the single large swap — the pool appears 10 times larger. A streaming swap with a count of 100 sub-swaps makes the pool appear 100 times larger. The inherent tradeoff here is price vs time.

Streaming swaps have opened THORChain to an entire new market; ie. whales. Soon after their launch, THORChain has become the go-to exchange for 6-7-figure trades. Below we see that streaming swaps average at around 18k in size, the second largest after Curve swaps.

The results on the network kicked in October onwards. The success of streaming swaps is owed to two unique factors.

1. Synths: Synths already allowed arbs to correct the prices of the pools very effectively. However, synths become a lot more effective when used in tandem with streaming swaps. This is because, with streaming swaps, arbs can use synths to correct the prices *during* the swap (before and after each sub-swap) as opposed to *after* the swap. This allows streaming swappers to get an accurate market price as they execute their swap. The arb is so effective that the network can process streaming swaps of size larger than the pool with competitive rates!
2. Slip-based fees: THORChain has a slip-based fee model, where fees paid vary based on how large the swap is relative to pool size, with larger swaps paying higher fees and vice versa. As such, the aggregate fees paid by 10 small sub-swaps is much less than that fee paid by a single large swap, even if they generate the same amount of volume. 

Indeed, before the launch of streaming swaps, there were doubts in the community on whether breaking swaps into many small sub-swaps would reduce the overall fees the network could capture. As it turns out the increase in volume was more than enough to make up for the difference. With fees starting to regularly exceed block rewards, THORChain is one of the exceptional chains/apps on track to grow w/o subsidies. 

In 2023, the yield generated *from fees alone* averaged at 6.5%. This figure is the aggregate yield over the total value locked (bonds + pools).

From Speculation To Fundamentals

The fundamental metrics on THORChain are looking stronger than ever.  Users, volume, and liquidity are all at ATH. Last bull cycle, Rune was mostly a speculative play. Now it’s transitioning into a fundamentals play; one that provides real value to the crypto industry. 

What’s Next For THORChain In 2024?

Aside from the usual, (more integrations with DEXs, wallets, chains, etc. ) the pipeline for the next year includes the following products: rapid swaps (powered by limit orders), memoless txs, and perps. The code for the first two is mostly ready so we can expect them to launch relatively soon (likely in Q1). It’s hard to comment on the timeline for perps as it’s in the early design/research stage.

Rapid Swaps: the price of a streaming swap with the speed of a regular swap.

Limit orders are expected to attract an entirely new type of user to THORChain; ie. traders.  Similar to other THORChain features, they have their THORChain twist. Unlike traditional limit orders that execute against bids/asks in an orderbook, THORChain limit orders execute against the AMM pools when and if their desired target price is satisfied. This will be enabled by streaming swaps and synths working behind the scenes. 

Let’s work through an example to see how they work. Say I place a limit order to sell 1 BTC for at least 50,000 USDC. Under the hood, first, my 1 native BTC is swapped to 1 sBTC and placed in the “orderbook” waiting for execution. From there, it gets stream swapped to sUSDC if and when the pool price can satisfy my target price of 50,000 USDC. 

Limit orders will greatly benefit THORChain in a way that may not be immediately evident. Enter “rapid swaps”. 

Today, THORChain offers two options for swappers: regular swaps with high speed but sub-optimal prices, and streaming swaps that execute slowly with optimal price. A stream swap of size $1m+ can typically take more than an hour to execute.

Rapid swaps promise the best of both worlds; the price of a streaming swap with the speed of a regular swap. With limit orders, it will be entirely possible for a “streaming swap” to execute within a single block w/o sacrificing price execution. Here is a good mental model to see how this will be possible.

With regular swaps, arbs are correcting prices *after* the swap is done. With streaming swaps, the price correction happens *during* the swap, in between sub-swaps. Limit orders take this a step further. Arbs can update their limit orders every block, correcting prices even *before* organic swaps take place. As streaming swaps come in and start to execute, every sub-swap may move prices of the pool such that the limit orders awaiting execution may get triggered and execute against the pool in the other direction. This means streaming swaps can indirectly execute against limit orders within a single block.

With limit orders, instead of arbs waiting for a swap to happen and arb reactively, arbing will happen proactively. We expect this to become the cheapest and most effective form of arbing on THORChain. 

Our final note here is a recent important proposal that suggests using “trade assets” over synths for arbing to double the capital efficiency of arbs. For those interested we highly recommend following updates regarding this proposal as it’s likely to take arbing on THORChain to another level. A second-order effect here of ‘trade assets’ is that they could reduce synth utilization and thereby LP’s sensitivity to Rune price (detailed in risks in the section below).

THORChain To Become Wallet Agnostic

Memoless txs are a subtle, technical upgrade but one that can greatly benefit the protocol by making THORChain wallet agnostic.

Today, THORChain requires the incoming txs to encode user intent  (e.g. desired asset, destination chain, affiliate fee, etc.) in the txs’ memo field. Wallets that support THORChain must understand this encoding and specify it in the applicable data fields (eg. OP_RETURN in Bitcoin) of the tx when creating it. 

With memoless txs, wallets will no longer need to do this encoding themselves. Instead, any wallet can have the intent implicitly encoded in the tx amount itself with the help of QR codes or other means. Here is a step-by-step example of how this will work.

1. The user asks for a quote through an interface supporting THORChain (e.g. THORSwap).
2. The interface writes the intent  (e.g. desired asset, destination chain, affiliate fee, etc.) on the THORChain blockchain, and in turn, THORChain will generate a numeric deterministic code (e.g. 42344) to represent the intent. Whenever THORChain recognizes an incoming tx amount ending with the code (e.g. an incoming tx of 1.00042344 ETH) it will know how to process it w/o needing further information. 
3. The communication between the wallet and the THORChain interface can be via a QR code or other means. 

Memoless txs will allow integrations to become entirely wallet agnostic and thereby may greatly expand the reach of THORChain.

THORChain Risks

While THORChain/Rune has high upside potential, we also acknowledge it has relatively high risks.

Software Risks

The very nature of the THORChain projects – cross-chain liquidity protocol – is an admittedly risky area, frequently targetted by black hat hackers. Historically, bridge hacks have accounted for more than $2.5B loss and most of these were due to software bugs. THORChain was already a complex protocol with a cross-chain swaps feature alone and now with synths, savers, streaming swaps, PoL, and lending it has a much larger potential surface area for software bugs.

On the positive side, as a multi-year project, THORChain has built a strong defense in depth. The core team and Ninerealms have been taking very effective steps to increase security of the protocols, which include but are not limited to:

• Immunefi bug bounty (max 250k Rune): to convince black hats into becoming white hats
• Node pause: any single node operator can single-handedly pause the network for an hour, if they suspect any malicious activity.
• Tx throttle: rate limits the amount of volume that can go through pools within a period
• Thorsec Team: A 24/7 always-on security team that monitors the network health, responds to incidents and reviews pull requests.

More details on THORChain security can be found here.

Economic Risks

Synths (particularly savers) and lending make THORChain more sensitive to Rune’s price performance. They are all designed to greatly benefit the protocol when Rune outperforms non-Rune assets, yet their impacts are mostly reversed when Rune underperforms non-Rune assets and imposes various risks for the protocol and/or its participants.

Lending

Lending is the most recent feature activated on THORChain. It allows users to deposit native assets and borrow against them. Much like others, lending is also of a kind feature. Lending’s primary purpose is to enable no-liquidation, no-expiry loans. Its secondary purpose is to generate a constant buy pressure on Rune which helps the protocol to lift the caps (pool caps and synths caps). We won’t dive into lending mechanics in detail but instead will give a rough intuition on how it works, as it directly impacts RUNE tokenomics. 

Say I deposit BTC to borrow some USDC. The protocol takes my BTC collateral on Bitcoin and gives me USDC on Ethereum based on the market-driven LTV ratio. The BTC collateral is used to buy and burn Rune. If the collateral value drops below the debt (always denominated in TOR; a non-transferable, unit of account that follows the price of the deepest stablecoin pool) it doesn’t get liquidated. At a later date, when say collateral value goes back up again, I can pay back my debt and get my BTC collateral. As a result of loan repayment, new Rune gets minted.

If during my loan’s lifetime, Rune outperforms the collateral asset (e.g. BTC) in price, the net effect of the loan repayment is a permanent Rune burn, otherwise, the net effect is new Rune entering into circulation from the Reserve.

Ultimately with lending design, the protocol makes a very opinionated bet on Rune outperforming collateral assets BTC and ETH (the only two assets allowed as collateral). This increases sensitivity to Rune’s price. When things go south, it’s entirely possible for lending to be a net negative for the protocol by increasing total Rune supply creating a downward pressure on Rune price. 

Given these risks, lending has received pushback from some long-time community members and has been somewhat of a contentious feature. In the end, lending was released with a “circuit breaker” which auto-sunsets the lending feature for good if Rune supply ever exceeds its original max of 500M. Lending was just recently launched with decent traction and has yet to prove its PMF.

Savers

Similarly, with synths (particularly savers) pools become sensitive to Rune price. Recall the rough intuition we presented earlier on savers vs dual LPs. When Rune underperforms the non-Rune asset there can be more non-Rune owed to outstanding synths than there exists in the pool (liabilities > assets). Below we see this happening in the BTC pool when Rune’s price was below 1$ back in summer.

Importantly the accounting between savers and dual LPs gets realized when either one of them withdraws/deposits to/from the pool. In other words, the actions of each actor impact each other.

When liabilities are more than assets, if a saver exists (swap synth for the native asset), the promised non-Rune is covered via dual LP deposits, which in turn amplifies the IL of all the remaining dual LPs. However, much like savers, dual LPs are also free to leave the pool anytime they want. This begs the question; what happens in a hypothetical edge case black swan where the pool runs at a deficit of non-Rune assets and all of a sudden everyone wants to withdraw? In this case, the last savers to get out can take significant haircuts by paying abnormally high slip-based fees, due to a pool liquidity getting shallow relative to synths getting swapped out. Put simply, last savers may not be able to redeem their assets 1:1. We note that such risk is particularly high in stablecoin pools as Rune can greatly underperform the non-Rune asset in a bear market.

Once again, the protocol imposes synth caps to avoid such a ‘bank run’ scenario. However, it’s important to recognize that these risks do exist. Finally, it’s worth noting that the 9R team has expressed interest in reducing caps back to 30% of the pool (from its current max of 60%) following signals from some Node operators and some voiced concerns from the community regarding AVAX/RUNE pools. 

TLDR; generally speaking, providing liquidity on THORChain is a high-risk, reward play and can be highly sensitive to Rune price. Swappers are exposed to any risk only during a swap, however, this is not the case for liquidity providers. Those who want to participate in pools should do their research, making sure to understand the involved risks, as well as the rewards.

Chainflip

Chainflip recently its launched cross-chain DEX. While THORChain and Chainflip appear as competitors at first glance, both communities realize that their success is a win-win that grows the pie for both. Put another way, THORChain and Chainflip don’t compete against each other. They compete to make CEXs obsolete. 

Much like THORChain, Chainflip is a sovereign app-chain whose validators run nodes of supported chains to collectively manage addresses via TSS; they independently observe and accept incoming txs and sign outgoing txs on supported chains. 

However, when we dive one level further, Chainflip looks quite different than THORChain. All components such as the TSS vaults, trade engine, etc. are all built from scratch with little to no code share with any other project.

THORChain	Chainflip
Cosmos SDK	Substrate
CLP (xyk AMM with slip-based fees)	JIT AMM
Feels like an AMM pool	Feels like a decentralized OTC service
Optimises for passive liquidity	Optimizes for capital efficiency
Individual (streaming) swaps	Batched swaps with uniform price
RUNE as the common base asset	USDC as the common base asset
Supports Bitcoin, Ethereum, BSC, Avalanche, Litecoin, Dodge, Cosmos Hub	Supports Bitcoin, Ethereum, Polkadot, and Arbitrum to begin with
Wallet agnostic (via memoless txs)	Wallet agnostic
Swap, Earn, Lend (more to come)	Swap (more to come)
6 TSS vaults each with 20 nodes	1 TSS vault with a target of 150 nodes

JIT AMM

Chainflip has a one-of-a-kind just-in-time (JIT) AMM, where liquidity provided, is in the form of UNI V3 style range orders as well as limit orders. Both forms of liquidity are actively managed by market makers and consumed by swaps. The DEX acts very much like an open, transparent, decentralized OTC desk with market makers updating their orders on Chainflip just-in-time, after observing incoming swaps. Precisely, market makers are expected to update their orders while swaps are awaiting to reach finality on supported chains and be ‘locked in’ on Chainflip. 

Swaps are bundled (per direction, per pool) and are executed in batches with uniform prices. For example, multiple swaps selling or buying the same asset in a block, will partially cancel out each other and get executed as one large buy or sell swap. This not only prevents attempts to front-run individual swaps but also minimizes slippage. 

The design goal of JIT AMM is to create a highly competitive environment between market makers incentivizing them to bidding their best prices to be able to serve swap intents and in turn earn fees. Market making on Chainflip is expected to be a sophisticated role with competitive market makers using their proprietary off-chain liquidity and potentially prediction models to minimize their price risks.

MEV In Chainflip

Chainflip design is particularly effective in minimizing toxic MEV for users. Batch swaps with uniform prices, coupled with a highly competitive market-making environment, flips front-running on its head. Instead of swappers being front-run by MEV bots, market makers front-run each other to fill swaps and capture fees. In doing so, they end up offering their best price for swappers. 

That said, the intended game theory assumes an arm’s length market maker competition and there may be edge cases where this assumption doesn’t hold. For example, in periods of abnormally high volume, if swaps in the same direction are awaiting to consume all available liquidity, market makers may no longer be able to fill them with accurate market prices. In such an edge case, the dominant strategy for market makers could be to collude to fill the swaps with inaccurate prices favorable for them, instead of competing with each other failing to fill the swaps. In periods of high demand, it will be prudent for front ends to warn users against the likelihood of exhausted liquidity.

USDC As The Base Asset

Much like THORChain, Chainflip adopts a common base pair for its pools to prevent liquidity fragmentation. However, Chainflip also meaningfully differs from THORChain in its decision to use USDC as the base asset.

From a capital efficiency standpoint, the USDC decision is a rational one as market markets can easily hedge their IL risks on external markets against the stables’ orderbooks which have the deepest liquidity across the board. With USDC, the hope is to make it very easy to onboard market markets into the DEX.

However, with this decision, Chainflip also makes a clear trade-off. It introduces an external dependency to a centralized actor at the heart of their protocol, pushing the protocol away from the censorship-resistant end of the spectrum.

A Word On FLIP Tokenomics

FLIP has an elastic supply and depending on the usage of the network, it can become a deflationary asset. Swap fees will buy and burn FLIP while new emissions will be used to incentivize validators and market makers. While FLIP won’t be used in the pools as a routing asset, validators will need to stake FLIP to run and secure the network and FLIP will also be used as the gas token. 

 

Ethereum Roadmap

Hard Forks Ahead

In 2024, we see a lot of upcoming changes being introduced to Ethereum that represent both shifts in the infrastructure landscape as well as the long term roadmap for the network. You can can expect two major hard forks to occur with the Deneb-Cancun hardfork (also known as Dencun) expected as early as February and Prague-Electra hardfork planned for later in the year (where its planning will officially begin in January).

Dencun Hardfork

The Dencun hardfork consists of several upgrades but we can break them down into three categories to give a digestable overview:

 

1. Data Sharding Foundations: Blob transactions and all the required infrastructure around them are introduced to the protocol.
2. Beacon Chain Upgrades: Quality of life updates to staking exit mechanism, increased attestation inclusion window, validator activation rate-limiting per epoch (8 validators/epoch).
3. EVM Upgrades: Transient storage opcodes, blob resource base fee opcodes, cheaper memory copy opcode, SELFDESTRUCT removal (kinda).

Prague-Electra Hardfork

The second hardfork of 2024 is going to be called Prague/Electra and planning for this set of upgrades will officially begin in January. Despite how early it is, there have been some discussions regarding which upgrades will be suitable for inclusion in this hardfork. Here are some deliverables currently being suggested:

• Addition of BLS12-381 Precompiles
• Verkle Trees
• Execution Layer Triggerable Exits
• EOF (for smart contract deployment – already been delayed over past two hardforks)
• Quality of life upgrades to finality gadget (a change to the consensus layer to reduce the cost of verifying Casper FFG by a factor of 64x)

With a better understanding of the official hardforks ahead in 2024 and a rough idea of what deliverables are expected, we have a good grasp on what we expect core developers to be working on across the variety of consensus and execution clients and core protocol specification. All in all, we are expecting a much more busier year on this end compared to what we observed in 2023.

One of the most significant and discussed upgrades happening in the Dencun hardfork is EIP-4844, and we foresee the inclusion of this upgrade and the various other smaller upgrades that stem from it as being very influential in the larger Ethereum ecosystem including in the world of L2s.

EIP-4844: Data Publication

The spotlight around the Dencun hardfork is undeniably on EIP-4844 (also known as Proto-Danksharding) which is one of the most anticipated upgrades in Ethereum since EIP-1559 and The Merge.

To avoid conflating this upgrade with the more long-term solution towards data sharding known as Danksharding, we will continue to refer to this upgrade as EIP-4844 for the remainder of this read.

 

From Execution to Data Sharding

As blockchain technology continues to evolve and mature we have started to observe shifts in lines of thinking about core components of blockchains and where to separate concerns and optimise the properties that give them value – Ethereum is no exception to this. It seems not too long ago, Ethereum was still set on figuring out a scalable design to implement execution sharding, yet today we observe Ethereum dedicating itself to becoming a credible commitment machine rather than an upscaled internet computer as envisioned earlier in the roadmap, this being very evident by the overall sentiment shared by the community towards the rollup-centric roadmap – which brings us to the present. Today Ethereum positions itself as a data publication and arbitration layer rather than trying to fit a bill as a scalable execution layer blockchain for global adoption. One of the crucial steps that are needed to realise this vision lies with implementing data sharding on the network and EIP-4844 is one of the first big steps in that direction.

A Precedent for Better Utilisation of Blockchain Storage

EIP-4844 is a set of changes that enable Ethereum to be utilised as a trustless proof-of-publication layer without imposing extreme data storage burdens on the network. How Ethereum achieves this is by introducing a new transaction type along with a system around it that enables arbitrary data to be cheaply published across the network but not be tasked with its permanent, long-term storage. We hence see a decoupling of data storage and data publication, where Ethereum may not always be able to provide a means to retrieve data, but the integrity of any previously published data can be cryptographically verified on the network.

By no longer bearing the long-term role of data storage, Ethereum is able to cheaply price the use of this new transaction type and the amount of data it can hold, given it does not contribute to state and history growth (which represent the main externalities that influence resource pricing and fee markets in the network).

In a nutshell, this is what Ethereum provides to applications (data publishers) that seek to leverage EIP-4844:

1. Cheap Data Publication: Since data storage is not a sustained, permanent cost to the negative (since it doesn’t significantly contribute to state and history growth), data publication using the EIP-4844 mechanism can be priced extremely cheap compared to the current cheapest option for publishing data using Ethereum.
2. Proof of Publication: Ethereum canonical state and history can assert to the acknowledgement of a data publication event.
3. Proof of Availability: The protocol guarantees the availability of a submitted data payload for a certain period of time before discarding it. The reason for this is to provide ample opportunities for any interested actor wishing to provide data storage of the published data to retrieve it, thereafter, Ethereum relinquishes responsibilities around data storage/retrievability.
4. Proof of Data Integrity: A data publisher may one day want to retrieve an old data payload that was published to Ethereum in the past. With the 1-of-N trust assumption, this payload should be retrievable from an out-of-protocol source. Once the data publisher, has a payload they can use Ethereum to cryptographically verify the integrity of the data that supposedly was published, this will give them irrefutable confidence that the data they received was indeed the same data published to Ethereum at some past point in time.

EIP-4844 represents the first foundational steps towards introducing data sharding capabilities to Ethereum. This upgrade helps begin this process by introducing blob-carrying transactions to the network as well as all the necessary protocol components that work in unison with this new transaction type. Having just gone through a very simplified walkthrough of how this new data publication system works, we can express this upgrade as comprising of three main components:

1. Blob-Carrying Transactions
2. New Data Gas Fee Market
3. New Cryptographic Primitives

Introducing Blob-Carrying Transactions

EIP-4844 introduces a new transaction type known as a blob-carrying transaction which enables applications to attach arbitrary data intended for publication to this special transaction. Each of these blob transactions can carry up to 128 kB of arbitrary data.

The blob-carrying transactions are what the end-user submits to the network and it contains the data payload that is desired to be published on Ethereum. The essential part to understand about this new transaction type is that the bulk of the transaction size (attributable to the data payload) is only temporarily persisted on Ethereum, where after a certain period of time has passed – the data payload gets discarded – representing Ethereum letting go of its temporary role of providing data retrievability and transitioning to its future role (with respect to this data) of providing verification associated with publication.

The ephemeral part of the transaction being described here is known as the blob sidecar (see the interface here), and it consists of the raw data contents, generated commitments and required cryptographic proofs.

With the blob payload associated with these transactions not being a permanent negative externality on the network, the cost of posting a payload of this size is significantly cheaper compared to current cheapest option of posting data to Ethereum. This naturally makes blob-carrying transactions a highly attractive new option for batch-posting strategies by various rollups that settle on Ethereum given that this could significantly cut a large portion of operating costs that rollup operators face in interfacing with Ethereum to leverage its consensus and arbitration capabilities.

Two-Dimensional Resource Pricing

To understand the second key component introduced with EIP-4844, we need to first get a simple intuition around how transactions are currently priced in Ethereum. We identify two components that shape what users end up paying for transactions:

1. Resource Pricing: protocol component that assigns weight to the computational effort imposed on the network (e.g. total gas consumed by a transaction).
2. Transaction Fee Mechanism: protocol component that uses a market mechanism (like some flavour of auction) to assign market-clearing prices per unit gas that users should bid to incentivise inclusion.

While these two components above are fairly nuanced topics in the realm of decentralised mechanism design, they are crucial to understand what the introduction of new blob-carrying transaction brings to Ethereum. Currently all Ethereum transaction types contribute some execution footprint towards Ethereum be it through EVM computational effort, history growth or state growth. We are going to refer to gas involved with these current transactions as execution gas. Basically, any computational activity we are familiar with that is invoked by transactions consumes this “execution gas” (e.g. calldata costs, native ETH transfers, EVM code execution cumulative effort – as well as the state and history growth associated with these transactions).

Having observed the anatomy of blob-carrying transactions we can notice that some parts of the transaction consume “execution gas” is similar ways to the transactions we are currently familiar with – for example, the block header and body of a transaction contributes to history growth since it makes up part of the payload body of an Ethereum block and so requires processing and consumption of node resources in executing the protocol.

So far its business as usual, but when we look at the ephemeral blob sidecar part of the transaction we realise it is handled completely differently to what we would expect of a normal transaction payload. The blob sidecar is only processed on the consensus layer and is eventually discarded entirely after a certain period of time has elapsed. It is on this premise, that a new resource type is introduced to the protocol to meter the temporary burst costs imposed on the consensus layer – this resource is called data gas.

Additional Data Gas Fee Market Information

Without getting into too much details regarding how the fee market works for this new data gas, we see EIP-4844 allowing a target of 3 blobs per Ethereum blob with a max of 6 blobs under the demand and supply elasticity afforded by EIP-1559-like fee market mechanism; we expect this value to be adjusted to 16 blobs eventually in a future hardfork dependant on how effective this solution ends up being for users. Each blob transaction occupies a fixed size of approximate ~125 kB (regardless of whether a transactor full utilises the space available or not – the blobspace of the transaction still uses up around 125 kB due to how the cryptographic commitment scheme works with the field elements that the data will be encoded into). One final difference of the data gas market pertains to the transaction fee mechanism utilised by it, which is a modified version of EIP-1559 known as exponential EIP-1559 which has superior properties (which would be too long to dive into here but you can read up about here).

New Cryptography Primitives required for EIP-4844 (KZG Methods/Helpers)

The final key component that makes up EIP-4844 is introducing key cryptographic primitives required for computing KZG commitments and evaluating KZG proofs. This is a crucial requirement to enable Ethereum to provide the data publication guarantees described earlier in this section.

For the sake of brevity we will omit explanations regarding how KZG commitments are specifically utilised and the explicit procedure for converting blobs into commitments but highlight some key deliverables that are required to be shipped to enable the data publication service to work as intended. The deliverables include:

• Two precompiles: To perform verification of a blob or a KZG proof belonging to a versioned hash of published data.
• Consensus layer logic: When dealing with blob sidecars, there are various validation checks that are required to be done. With EIP-4844 the availability of the data (which is gossiped) needs to be confirmed (at a later stage with Danksharding, data availability sampling will attest to availability instead of requiring all validators to have the entire data). Along with attesting to availability of retrieval, the versioned hashes must be computed from the blob data to verify the provided version hash was correctly computed and corresponds to the specific blob payload being referenced.

Blob-Sharing Design Space and Protocols

As mentioned earlier, blob-carrying transactions have fixed-size payloads and what this means is that whoever gets a blob transaction included is required to pay fees for the entire blob regardless of whether they only utilised a tiny portion of the available payload space of ~128 kB. There are numerous efficiency problems associated with this and unfortunately it is not as simple as simply making a protocol change to allow blobs to be any size, as the cryptography requires these constraints. The efficiency problems are the following:

• Cost: Users that do not require the entire blobspace of a transaction are overpaying.
• Speed: If there are a surplus of users and limited blobs available, other users may have to wait a block or two or even more to publish their data payloads to Ethereum using a blob transaction.

A logical solution would be to design either a decentralised protocol or trusted application to merge data payloads into single blobs before sending them to Ethereum to participate in the data publication process. Imagine three rollups (Rollup A, Rollup B, Rollup C) each using a single transaction with one blob to use Ethereum for data publication:

Some similarities can indeed be drawn between a blob sharing protocol and something like a shared sequencer, however if you take a closer look you can imagine a blob-sharing protocol as far more simpler in its most basic form as it requires less back and forth communication with Ethereum because once it publishes a merged blob-carrying transaction, it can leave the rest of to each individual rollup in how they decide to to manage their data storage requirements.

Reading this, you might also wonder why Ethereum simply doesn’t enshrine some mechanism to merge blob payloads into singular blobs or collections of blobs to enhance efficiency? One valid reason for this is protocol complexity as this would introduce another knapsack problem at a transaction level, alongside the already NP knapsack problem with constructing blocks – and in a world of increased builder specialisation and outsourced block production, it introduces additional complexity to an already daunting challenge around enshrining PBS mechanisms into Ethereum.

We can certainly expect to see various forms of blob sharing protocols and applications emerge as EIP-4844 use increases after the Dencun hardfork. Some examples of the design space being explored can already be observed here and here.