Equity perpetual futures (equity perps) allow market participants to gain synthetic exposure to traditional equity markets on decentralized venues without relying on brokers or centralized intermediaries. Perpetual futures are arguably crypto’s most successful financial innovation. They solved the complexity and access barriers of traditional derivatives, allowing 24/7 trading and simple leverage without expiry. This simplicity has proved so effective that perps overtook options and futures as the dominant trading instrument for crypto markets.

The same model could now be exported back to traditional finance. If equity perps succeed, they may mark the first time a crypto-native market structure reshapes TradFi, rather than the other way around. By mirroring stock price movements while operating on permissionless infrastructure, they combine the global accessibility and 24/7 liquidity of crypto markets with exposure to some of the most widely traded assets in the world. This convergence has the potential to blur the line between TradFi and DeFi, enabling new forms of trading, hedging, and market participation.

Equity perps are not an entirely new idea. Over the past few cycles, multiple protocols attempted to bring stocks onchain through synthetic representations, but most early efforts failed to achieve meaningful traction due to high costs, fragile oracle designs, liquidity fragmentation, regulatory pressure, and a fundamental mismatch between market hours and 24/7 trading. What has changed in recent years is the emergence of high-performance perp DEX infrastructure, improvements in oracle design, better risk engines, and increased willingness of market makers to support structured liquidity for traditional assets.

The implications extend beyond speculation. Equity perps can offer efficient exposure for global users, enable structured products, improve hedging strategies for DAOs or treasuries, and potentially act as building blocks for more complex onchain capital markets. At the same time, they inherit a unique set of technical, economic, and regulatory challenges distinct from crypto-native perps.

This report aims to provide a comprehensive view of the current equity perp DEX landscape. It is structured into three parts:

1. A review of the equity perps opportunity and market sizing.

2. An exploration of the different perp DEX implementations and oracle designs, with an overview of the current landscape.

3. An analysis of core challenges, criticisms, and opportunities ahead.
   

2. Market Sizing and Context: The 0DTE, CFD Opportunity

For onchain equity perps, the real upside lies not only in the total market of equities derivatives, but in capturing the retail trader demographic that currently drives abundant flow through same-day, leveraged equity instruments. These traders seek fast exposure to equities, high leverage and quick returns. Today they turn to 0DTE (zero-days-to-expiry) options. Perps present a simpler, more accessible vehicle for the same behavioural flow.

What the 0DTE market looks like

• In May 2025, 0DTE contracts tied to the S&P 500 (SPX) made up over 61% of all SPX options volume. Retail traders were responsible for roughly 54% of that 0DTE volume.
  Source: Cboe Global Markets

• Separately, research estimates that the 0DTE/options market on indexes averages over US$500 billion in notional per day.
  Source: Cboe Global Markets

• Many retail traders treat 0DTE as “modern lottery tickets”. These traders mostly have small capital, use high leverage and want an immediate payoff. This mindset overlaps strongly with the appeal of onchain perpetuals.
  

Figure: Share of 0-day-to-expiry (0DTE) contracts in SPX options volume (2016–2025 YTD). 0DTE now accounts for over 60% of SPX options, underscoring the growing retail appetite for short-duration leveraged exposure.

Translating into Onchain Equity Perps Revenue Potential

Assume the following conservative framework:

• Total 0DTE notional: US$500 billion per day (index only)
  Retail share (exposed to levered, fast-turnover trades): 50%, or US$250 billion/day.

• Suppose equity perps manage to capture 5% of that retail flow (US$12.5 billion/day notional).

• If a perp DEX captures fees + funding equivalent to say 5 basis points (0.05%) of notional per day, it gives us US$6.25 million/day.

• Annualised (365 trading days) ≈ US$2.281 billion/year in revenue potential for the protocols that execute well.

If the capture rate rises to 10%, the same math yields US$4.56 billion/year. Thus, even modest migration of retail 0DTE flow into onchain equity perps opens a billion-dollar scale revenue opportunity.

Why this is compelling

• Retail traders already demonstrate an appetite for short-duration, high-leverage equity exposure.

• Onchain perps offer global access with no brokers and middlemen, and no KYC. This dramatically lowers friction - making perps naturally attractive to that cohort.

• The protocols that get infrastructure, UX, liquidity, and regulation right could capture a substantial slice of an existing demographic of retail equity traders, rather than creating demand from scratch.
  

A New Source of Capital Inflow

Over the past several years, the onchain ecosystem has lacked a fresh injection of high-quality underliers and meaningful new capital inflows. Two closely related constraints now hamper growth:

1. There are only a few crypto assets that consistently attract liquidity and institutional interest. For example, there are 590 spot markets on Binance. Of this, the top 18 spot markets on Binance account for 80% of all spot volume, while the other 572 make up the remaining 20% of volume.

2. After the recent wave of ETFs and Digital Asset Treasuries (DATs), there is little to no marginal inbound liquidity entering the market.

Introducing equity perpetuals (perps) offers a dual solution. First, it expands the universe of tradable assets from crypto assets to potentially hundreds of equities and indices, thereby opening up the market from recycling capital among the same assets toward new external flows. Second, it creates a structure designed to onboard non-crypto native capital. Some examples of these are: retail traders who solely trade equities, hedge funds limited in shorting opportunities and global investors seeking 24/7 access. In other words, equity perps could become the next major onchain liquidity gateway, capturing flows that previously either stayed in TradFi or simply never considered crypto.

If executed properly with strong oracles and deep liquidity, this could mark a structural shift from crypto (ex-Bitcoin) being seen as a niche loop and instead being seen as a global trading layer for equities.

3. TradFi Shorting Constraints and Why Perps Matter

Shorting equities in traditional markets remains one of the most structurally constrained activities in finance. According to S3 Partners and Goldman Sachs Prime Brokerage, global equity short interest typically hovers between 2–3% of total market capitalization. Yet this exposure is supply-constrained: it cannot expand meaningfully because it depends on how much stock lenders make available, primarily through prime brokers and custodians.

Borrow Supply and Cost Landscape

• ION Group reports that roughly US $1.3 trillion in U.S. equities is on loan at any given time with the majority being equities, compared to US $60 trillion+ in total market cap, meaning only about 2-3% of the market is shortable at any one time.

• Borrow rates (the annualized fee to short) vary dramatically:

  • General collateral (liquid large caps): 0.3–1.5% annualized

  • Hard-to-borrow mid-caps or crowded shorts: 5–20% annualized

  • Specials (extremely illiquid names): >50%, sometimes 100%+ (examples include GameStop, AMC, Carvana during 2021–2023)

• Recall risk is significant: lenders can pull back inventory on short notice, forcing traders to cover. S3 Partners data shows over 5% of borrow recalls occur within 10 days for crowded names.

Ultimately, this means traders are not limited by conviction or capital, but by inventory access and borrow rates being controlled by intermediaries and counterparties. This also means that retail access to shorting is also usually less accessible.

Perpetual Futures as an Alternative

Perpetual futures completely bypass this structure. Short positions are created synthetically via open interest with no inventory and no risk of recall. The cost of holding a short is expressed through the funding rate, which fluctuates based on long-short demand imbalance.

Empirical averages from leading crypto perp venues show:

• BTC/ETH perps typically have daily funding between ±0.01–0.03%, equivalent to 3.6–11% annualized.

• Even during volatile periods, sustained annualized funding above 20% is rare.

• By contrast, hard-to-borrow equities in TradFi routinely cost 15 to 50% annually in borrow fees, making perps structurally cheaper and more flexible for expressing bearish exposure.

By comparison, onchain perps can scale to any open interest level the market can collateralize. On Hyperliquid, for example, aggregate open interest exceeds US $9 billion with fully symmetric long/short distribution, demonstrating that synthetic liquidity can absorb large directional flow without needing physical borrow.

If the same dynamic is applied to equities, it could meaningfully expand the global capacity for short exposure beyond the 3% float ceiling seen in TradFi. More importantly, it democratizes access for all traders to express directional views on equities without intermediaries or brokers.

4. Current Equity Perp DEX Landscape

TradeXYZ

TradeXYZ represents the most direct attempt yet to build a permissionless equity perp market using high-performance crypto-native infrastructure. Built on Hyperliquid’s HIP-3 framework, TradeXYZ inherits a fully onchain CLOB that allows for price discovery, their own margining framework, and transparent funding logic.

The platform debuted with XYZ100, a weighted basket of the top 100 NASDAQ stocks, and plans to expand into single-name equities over the coming months. During open sessions, oracles are anchored to external institutional feeds via Pyth, while during closures, the system applies an internal smoothing and banding mechanism that limits price drift.

This design ensures prices move gradually even when underlying markets are closed, a major advantage over synthetic systems that must halt trading. Because liquidity and execution occur entirely onchain, TradeXYZ can maintain continuous price discovery through user activity rather than static oracle updates. Early data suggests its weekend pricing tracks closely with NASDAQ futures, making it one of the few venues where genuine price discovery continues after hours.

TradeXYZ’s integration on HIP-3 also signals a broader shift: exchanges are no longer isolated frontends but composable markets that anyone can build on. This could become the foundation for future onchain equity indices, structured products, and ETF-style wrappers.

Ostium

Ostium is one of the earliest functioning equity perp platforms and remains the best-known example of a synthetic pool model adapted to real-world assets. The protocol allows traders to gain exposure to stocks, indices, and commodities through a central liquidity pool known as the Ostium Liquidity Pool (OLP), where liquidity providers take the other side of user trades.

Daily equity perp volume averages around US$7 million, though most activity is still concentrated in gold and major indices. Ostium uses a pull-based Real-World Asset Oracle developed in-house and operated with Stork, designed to aggregate price data from multiple traditional finance sources with asset-specific logic. This ensures secure and scalable feeds across different trading schedules.

However, trading halts outside regular market hours, and funding is either paused or extrapolated during closures. While the OLP model helped bootstrap early liquidity, it is now showing limits as its growth depends on continuous trader losses to reward LPs, and reliance on external quoting restricts scalability. Even so, Ostium deserves credit for proving that real-world assets can be traded onchain through a functional perp interface.

Vest

Vest takes the opposite approach. It uses a central limit order book (CLOB) architecture similar to centralized exchanges like Binance or Bybit, offering deeper liquidity and real-time price discovery. Vest aggregates live pricing data from NASDAQ, NYSE, CBOE, and Pyth, creating one of the most complete oracle coverage systems among current players.

Trading continues through extended hours using CBOE EDGX (pre- and post-market) and BlueOcean ATS (overnight), with the weekend price anchored to the last official close plus a volatility spread. This allows Vest to maintain continuous trading across almost the entire week, a key differentiator for equities that normally operate within fixed hours.

By combining onchain transparency with professional-grade market data, Vest delivers credible pricing and low tracking error during open sessions. Its biggest challenge lies in maintaining meaningful volume over weekends when volatility is artificially constrained. Still, Vest currently stands out as one of the more robust attempts at a continuously priced equity perp venue.

Gains Network

Gains Network brings a familiar brand from crypto into the equities space through its gTrade platform. It uses the same GLP-style architecture popularized by GMX, where users trade against protocol vaults rather than through direct market matching. Prices are sourced from four separate Chainlink node providers, providing redundancy and aggregation across multiple feeds.

Gains supports a wide range of global equities, commodities, and forex pairs, but it restricts trading to active market hours and pauses during closures. This simplifies oracle management but limits liquidity continuity. Its strength lies in accessibility and retail reach. The product is simple to use and integrates well with the existing DeFi ecosystem. However, like Ostium, its design inherently caps scalability and after-hours functionality.

Comparative Overview

5. Perp DEX Implementations

Perp DEXs supporting equities can take two distinct approaches:

• CLOB-based implementations: High-performance matching engines like Hyperliquid enable efficient order routing and tight spreads via onchain orderbooks - similar to how centralized exchange trading works on Binance, Bybit etc.

• Synthetic quoting models (GLP-style): Platforms like Ostium use offchain dealers and RFQ flows with onchain settlement, with positions synthetically held and traded against a centralised vault, made popular by GMX.

CLOB-Based Implementations (Hyperliquid, TradeXYZ)

Central limit order book (CLOB) architectures represent the most scalable model for perpetual DEXs, offering genuine price discovery, depth transparency, and high-frequency matching that mirrors centralized exchanges. Unlike pool-based systems, CLOBs allow traders to interact directly with other participants through bids and asks, enabling organic discovery of equilibrium prices and funding rates rather than relying on external quotes.

With the introduction of HIP-3, Hyperliquid became the first platform to support permissionless market creation. This allows any user to list a new perpetual market, including equities or synthetic assets, using onchain collateral and automated risk parameters. HIP-3 effectively transforms Hyperliquid from a closed exchange into a fully composable onchain trading layer, with oracles, margining, and settlement logic integrated natively into the chain.

TradeXYZ’s integration on HIP-3 builds on this foundation, and has gone live with equity perp listings, firstly starting with XYZ100 (a weighted basket of the top 100 stocks on the NASDAQ) and will be bringing single-name stocks soon. Unlike GLP-style designs, this structure ensures continuous price discovery even when external reference markets are closed, as prices are derived from live market activity rather than static external oracles. This meant that Trade.xyz might have been one of the most accurate venues for NASDAQ100 price discovery over the weekend of the 27th of October (case study below).

Vest operates similarly. It runs a CLOB-based system that aggregates data from multiple exchanges and institutional providers (including NASDAQ, NYSE, CBOE, and Pyth) to ensure accurate pricing and strong liquidity coverage. Vest’s structure mirrors the efficiency of centralized markets while retaining the transparency and settlement benefits of onchain trading. Together with Hyperliquid and TradeXYZ, it represents the leading wave of CLOB-style perpetual exchanges aiming to bridge TradFi and DeFi trading behaviors.

Case study: Weekend price discovery on XYZ100

Credit: @0xmev on Twitter

During the weekend of 27th and 28th October, XYZ100 on Hyperliquid showed early signs of real price discovery for equities outside traditional hours. On Sunday 4 pm ET, XYZ100 traded around 25,460, roughly +0.4% above Friday’s close at 25,360. When CME reopened one to two hours later, futures opened +0.8%, confirming the same direction.

Traders on Hyperliquid had bid above oracle price, paying funding to position for that move, effectively predicting the post-open adjustment before legacy markets did. While small in scale, it demonstrated how onchain perpetual markets can surface genuine price signals during off hours, hinting at their potential to become a continuous layer of global price discovery for equities.

The GLP/OLP Model (Ostium, Gains)

The GLP-style architecture, used by Ostium and Gains Network, synthetically fills orders against a centralized vault rather than through a true orderbook. Traders settle profit and loss directly with the protocol’s liquidity pool called OLP on Ostium and g(asset) vaults on Gains, similar to GMX’s GLP model.

During market hours, oracles pull prices from external feeds to mark trades, but because the vault is always the counterparty, TradFi market makers must quote and hedge exposure off-platform to mimic an orderbook and maintain delta neutrality. This setup allows Ostium to functionally emulate an orderbook but introduces dependency on external venues for hedging.

While this model bootstrapped early liquidity, it introduces scaling challenges. The vault must take the other side of user trades, meaning LPs profit only when traders lose, resulting in a zero-sum structure. Unlike Hyperliquid’s HLP, where pricing is dynamic and liquidity can be hedged onchain, the OLP’s static pricing restricts growth.

For instance, Ostium’s gold market has around $4M in open interest compared to $15M on Hyperliquid’s new PAXG market, despite lower funding rates on Ostium. Out of Ostium’s $57M TVL, $28M (or 50%) sits in the OLP, showing how dependent the protocol remains on this mechanism. Without moving beyond the GLP-style structure, Ostium’s model will likely cap its scalability.

Another important limitation of this design is that pricing depends entirely on external quoting rather than onchain price discovery. Because the model lacks a live market mechanism to continuously update prices, trading must stop during periods when the underlying TradFi markets are closed. This prevents after-hours activity and further restricts liquidity growth, creating a sharp contrast to onchain orderbook systems like Hyperliquid that maintain continuous pricing through synthetic and internal funding rate calculations.

6. Oracle Implementations

Oracle prices are at the heart of how perpetual exchanges function. Every perp market needs a reliable reference price to calculate funding rates, which are what keep the perp price anchored to the underlying asset. Funding payments flow between longs and shorts based on the difference between the perp’s mark price and the oracle price.

When the perp trades above the oracle, funding turns positive, meaning longs pay shorts a small % of their notional position every funding interval. This creates an incentive to short or for longs to close positions and rotate to spot, which pulls the perp price back down toward the oracle. The opposite happens when the perp trades below the oracle: funding becomes negative, shorts pay longs, and buyers are encouraged to take the other side.

For crypto perps, this process is straightforward. The oracle simply tracks the live spot market, updating continuously. But equities are different. Stock markets have fixed trading hours, which means there are long periods with no new spot prices to reference. During these times, the funding mechanism has nothing to anchor to.

The result is a fundamental design problem: how do you maintain a functioning perp market when the underlying asset stops trading? Exchanges either have to pause trading entirely, extrapolate prices through synthetic or internal models, or rely on alternative feeds from after-hours venues. Each approach carries tradeoffs in stability and accuracy.

This is why oracle design is one of the most important differentiators for equity perp exchanges. It determines how often prices update, how funding behaves, and whether a market can remain open and efficient when traditional exchanges are closed.

To make the comparison clearer, oracle designs can be split into two broad categories: market hours and outside market hours. Market hours oracles rely on direct external feeds from exchanges or liquidity providers, while outside market hours require either fallback mechanisms or rely on synthetic pricing models.

Market Hours

During active trading sessions, oracles typically rely on real-time external feeds to provide accurate pricing.

• Vest: Aggregates NASDAQ, NYSE, CBOE, and Pyth. Offers one of the most complete real-time feeds among current players.

• TradeXYZ (HIP-3): Primarily uses external institutional feeds (e.g., Pyth) to anchor funding and mark pricing during market hours.

• Gains / Ostium: Rely on simpler external price feeds or dealer pricing during open sessions, with less granularity compared to Vest.

Outside Market Hours

Once traditional equity markets close, venues diverge in how they handle pricing. Since there is no official market price after hours, they must either (a) stop trading or (b) use a synthetic pricing solution.

• No trading allowed: Gains and Ostium avoid the complexity of after-hours pricing entirely by not supporting trading outside standard sessions.

• Custom internal solution: TradeXYZ uses an internal smoothing and banding mechanism that allows for controlled movement around the last external price.

• External after-hours feeds: Vest uses CBOE EDGX for pre- and post-market pricing and BlueOcean ATS for overnight sessions, with last close plus a volatility spread on weekends.

Why Oracle Design Matters

Equities require more nuanced oracle handling than crypto because of limited trading hours, pre- and post-market liquidity, and regulatory boundaries. These design choices shape funding volatility, tracking error, and how users trade around market opens and closes. This section covers four representative venues: Gains, Vest, TradeXYZ, and Ostium.

TradeXYZ (HIP-3)

Active Hours

• Uses institutional-grade pricing through Pyth and other data partners.

• External reference prices anchor both funding and mark calculations.

Outside Hours

• When external prices are unavailable, TradeXYZ applies an internal smoothing mechanism to limit abrupt moves.

• Prices can move only within a volatility band tied to leverage (for example, ±$500 on a $10,000 asset with 20x leverage).

• Thin liquidity is ignored to maintain stability.

Vest

Active Hours

• Aggregates live feeds from NASDAQ, NYSE, CBOE, and Pyth.

• Funding is continuously calculated during these hours.

Outside Hours

• Pre-market (4 a.m.–9:30 a.m.) and post-market (4 p.m.–8 p.m.) data come from CBOE EDGX.

• Overnight (8 p.m.–4 a.m.) pricing is sourced from BlueOcean ATS, the largest overnight equities venue.
  Weekend sessions use the last market close as the base price, allowing limited movement through a volatility spread.

Ostium

Active Hours

• Uses a pull-based Real-World Asset Oracle, developed in-house and operated in partnership with Stork.

• Data is aggregated from multiple traditional finance sources with asset-specific logic for equities, commodities, and forex.

• Designed to handle events like futures rolls, price gaps, and market closures.

Outside Hours

• Trading stops completely once official exchanges close.
  Because no trading occurs, no synthetic or interim oracle updates are needed.

Gains

Active Hours

• Uses a custom oracle built from data aggregated by four separate Chainlink node providers, ensuring redundancy and cross-validation.

• Prices are refreshed continuously during open sessions, and funding is derived directly from these feeds.

Outside Hours

• Markets close when external trading halts, and no new data is fed to the oracle until markets reopen.

• This avoids reliance on synthetic or low-liquidity pricing.
  
  

7. Criticisms and Structural Limitations of Bringing Equities Onchain via Perps

While equity perps present a clear technical breakthrough, they face several challenges that make adoption and scaling difficult. These limitations are not simply engineering problems but reflect deeper structural differences between equities as long term investment instruments and perps as short term trading tools.

1. Long term instruments in a short term wrapper

Equities are designed for investors who hold positions over longer periods to benefit from compounding, dividends, and favorable tax treatment. Perpetual contracts, on the other hand, are built for short term trading and rely on continuous funding payments to keep prices aligned with spot.

In traditional markets, investors who hold equities for more than a year pay lower capital gains tax rates. Perp traders pay or receive funding continuously and do not benefit from any long term tax advantages. This creates a structure where speculation dominates, and few incentives exist for investors to hold positions for extended periods.

2. Loss of dividends and yield

Dividends are an important source of return for many established companies. With perps, that yield disappears.

• Long positions receive no dividend income, which lowers total returns compared to owning the actual stock.

• Short positions benefit because they are not responsible for paying dividends.

This asymmetry can distort funding dynamics and create persistent biases between long and short positions. Around ex-dividend dates, these effects can cause sharp funding swings and unpredictable market behavior. However, I do expect several no-arbitrage conditions to hold where the expected dividend payout is represented as a negative funding rate such that holding a long perp position should roughly receive an equal amount in funding as they would have holding spot position with a dividend.

3. Regulatory opacity and counterparty risk

Equity markets are heavily regulated, with clear oversight, mandatory disclosures, and established investor protections. Perp exchanges, especially decentralized ones, operate outside these frameworks.

There are no guarantees of solvency, no standardized insurance for users, and little visibility into how risk is managed internally. Some centralized exchanges in the past have used undisclosed liquidation or hedging arrangements, which makes it difficult for traders to assess their real exposure.

For participants accustomed to regulated markets, this uncertainty creates a high barrier to entry. Institutional traders, in particular, are unlikely to engage in meaningful size until legal clarity, reporting standards, and counterparty protections improve.

4. Lack of investor protections

Traditional brokerage accounts in the United States are insured by the Securities Investor Protection Corporation (SIPC), which protects up to $500,000 of customer assets in the event of failure. Perp exchanges, whether centralized or onchain, offer no equivalent coverage.

While crypto native traders accept this risk, equity investors view protection as a baseline expectation. If perps aim to attract this broader demographic, exchanges must eventually compete not only on speed and liquidity but also on the quality of user safeguards.

5. No ownership or governance link

Owning a stock grants voting rights, dividend entitlement, and eligibility for corporate actions. Owning a perpetual contract does not. Equity perps provide exposure to price movements only.

In traditional markets, ownership encourages long term holding and helps stabilize prices through a base of committed investors. Removing that ownership layer turns the market into one driven entirely by speculative flow. As a result, perp markets are more reactive to sentiment, positioning, and funding conditions than to fundamentals.

6. Overnight dislocations and price gaps

Equities trade during fixed hours, but perps operate continuously. During market closures, oracle systems rely on alternative data sources such as dark pool feeds, after hours trading venues, or synthetic references. These sources often have limited liquidity and can drift from the true underlying price.

When the equity market reopens, the gap between the onchain synthetic price and the real market price can cause sharp moves, wider spreads, and volatile funding adjustments. Until traders and liquidity providers become familiar with these transitions, periods around open and close will continue to see elevated risk and unpredictable behavior.

8. Conclusion

Equity perps represent one of the most interesting frontiers for digital markets. For years, innovation in finance has mostly moved from traditional markets into crypto, but this time it might flow in the opposite direction. The perpetual futures model that changed how crypto is traded could now reshape how people gain exposure to equities.

Perps have already shown how powerful simple design can be. They have allowed for round-the-clock trading, and created a unified structure for leverage and price discovery. Extending that same idea to equities could open up an entirely new way for traders around the world to participate in stock markets without brokers, intermediaries, or regional barriers.

The opportunity is not theoretical. The explosion of 0DTE options shows how much appetite there is for fast, leveraged equity exposure. These contracts now make up over sixty percent of SPX option volume, with roughly half driven by retail traders. That same trading behavior of short-term, high-turnover, and increased risk taking maps almost perfectly onto what perps already enable. Even capturing a small fraction of that activity could turn into billions of dollars in annualized trading revenue for onchain platforms.

There’s also a clear structural case. Shorting in traditional markets remains limited by borrow supply, collateral requirements, and high fees. Only a small share of equities are even available to short at a given time, and borrow rates for difficult names can climb into double digits. With perps, these constraints disappear. Short exposure scales with liquidity rather than inventory, and costs adjust naturally through funding rates. It’s an elegant, more flexible system for expressing both bullish and bearish views.

What makes this moment different from earlier synthetic stock experiments is that the infrastructure has finally caught up. Order book-based platforms like TradeXYZ via Hyperliquid’s HIP-3 now deliver real price discovery and deep liquidity, while improved oracle designs and risk engines make continuous pricing possible even when traditional markets are closed. Technology is no longer the bottleneck, and we should see the industry now shift toward pushing adoption and regulation.

Critics often argue that equities are long-term investments and that perps, by nature, promote short-term speculation. That criticism is understandable, but it misses the main point - that does not mean the product lacks value. The goal isn’t to replace long-term equity investing or dividend income, it’s to modernize the trading layer of equities and make it accessible to anyone, anywhere. Crypto perps did not make Bitcoin a better store of value, but they did make it the most liquid and tradable asset in the world. The same dynamic could play out here.

Equity perps have the potential to bring a fresh wave of participation and capital into DeFi. They open the door for global traders who have never touched crypto but understand markets. If this works, it could be the first time crypto truly influences traditional finance rather than the other way around. The idea is still early, but the direction should now feel much clearer. Equity perps could mark the next phase of crypto’s evolution from purely being a rail for crypto assets and instead housing all of finance - equities included.

TON is a Proof-of-Stake blockchain indirectly backed by Telegram Inc through the TON Foundation. It boasts horizontal scaling through a schema called infinite dynamic sharding and as a result managed in a test environment to garner over 100k tps (vs Solana 60k).  We believe the native token for this chain is currently undervalued given its:

1. Concentrated Supply and Scarcity Value in being a Comparatively Underowned L1

2. Clear Go-to-Market Strategy and Stellar Distribution Channels

3. Plenty of Greenfield Growth given Current KPIs

4. Tangible Crypto-Specific Catalysts

Overview of TON

History of the Chain

TON, previously known as the Telegram Open Network, has its roots dating back to 2018 when Pavel and Nikolai Durov, the Telegram founding brothers, began exploring blockchain solutions for Telegram Messenger. During that year, they raised a total of $1.7bn in the ICO of TON tokens (previously known as Grams), followed shortly by the release of the TON whitepaper and the first TON testnet in Spring of 2019. Following a series of regulatory challenges, culminating in the SEC suing Telegram for conducting an unregistered securities offering in October 2019, Telegram agrees to return funds raised from its investors and pays a $18.5m settlement fine by May of 2020.

Whilst the Telegram team ostensibly ceased development on the chain, a new group of developers under the name of NewTON (which latterly rebranded into TON Foundation) coalesced around the project and continued its development in earnest focussing on remaining faithful to the design principles set forth by the whitepaper, namely its ‘blockchain of blockchains’ structure.  Simultaneously, by June of 2020 all of the available TON coins became available for mining via ‘Giver’ smart contracts using a Proof of Work (PoW) system, with CPU mining continuing from 2020 to 2022. We note that whilst this distribution method was meant to promote decentralisation and increased fairness, research clearly indicates that a vast portion of the supply was mined by insiders or TON-foundation related addresses, with only 248 strongly connected addresses mining 85% of the coins in a space of 2 months (Jul-Aug 2020).

The TON Foundation, played a significant role in influencing the price of TON token thus far and is pivotal to the success of the project. Since its formation it has received its funding from grants derived from these initial mining efforts, but also via recent locked OTC sales to professional investors. Enhancing its strategic direction, the TON Foundation announced a partnership with Telegram in September 2023, led by a core team under the guidance of Anatoliy Makosov. This collaboration marks a pivotal step in TON's ongoing development and market positioning in the broader crypto space and strengthens the bull case for TON, providing a coherent and central driving force that is effectively influencing and boosting the token price.  .

Current Ecosystem

TON currently comprises of four major components. These are: TON Blockchain, TON Payments, TON Proxy and TON Storage (decentralised Storage). TON Blockchain is the general purpose blockchain containing a standard execution layer that allows for permissionless transactions. TON Payments is a minimal-fee platform micropayments channel, allowing instant and fast payments between peers. It can currently be accessed via the @wallet bot on Telegram benefitting from in-app convenience. TON Storage allows for storing and distributing files on TON akin to a decentralised Dropbox. Finally, TON Proxy ensures censorship resistance by allowing users to run .ton sites independent of fixed IPs / centralised domains. All four components have a rich roadmap ensuring cross-compatibility and connectivity well into the future.

The chain has benefitted from a cambrian explosion in activity in recent weeks as a result of a concerted and coordinated effort by TON foundation, Telegram and partners to push the on-chain ecosystem. Most notably, we have seen Tether in April announce direction integration within TON allowing for mint-redeems natively which allows for deeper DEX liquidity and on-boarding of further capital. The TON Foundation is also running a variety of liquidity mining incentives including 11m TON (~$50m) earmarked for DeFi LPs. In addition to the DeFi specific incentives, the foundation is running broader on-chain incentive programme totalling over 30m TON. The result of which is an explosive rise in TON-denominated TVL, with 30m in Apr-2024, a 6x increase from the start of the year (see figure below). We do note that DeFi TVL is in general quite mercenary, and likely some of capital will churn once rewards run out in June 2024.

Given that DeFi liquidity mining is ultimately a solved game, and have seen multiple iterations of it in past alt-L1s we believe that the real value in these incentives lie in other, more orthogonal and niche ways in which Telegram can incentivise app-users to interact with TON. The current incentive scheme, awards projects for attracting users via viral gaming mechanics such as one popularised by NotCoin (a simple yet addictive clicker app with over 3.5m Daily Active Users). These incentives are followed by rewards for completing in-app quests such as minting NFTs and DNS names and lastly the aforementioned liquidity mining for the largest DEXes on TON. The ultimate goal here is to utilise the distribution channel readily available to TON to slowly and gradually introduce and familiarise a captive Telegram audience to the on-chain ‘workflow’.

The result of this is dedicated effort is an increase in block-chain activity across all metrics including (see figures below):

• Transactions increased by 10x: Since March 2024 transactions have ranged between 2-4m tx/day up from 200k tx/day last year

• Number of on-chain activated wallets increased by 3.6x: From 600k addresses in January 2024 to 3.5m in end of April 2024.

• Daily Active Wallets (DAWs) increased to six figures: DAWs are now ~160k up from 30k earlier this year

• TON fees per day ranging between $50k-$250k: Half of the TON fee is burned

Whilst these heightened numbers in and of themselves are likely a symptom of in-organic and non-sticky on-chain participation, the velocity and the rapid growth of the ecosystem for a historically small incentive reward programme (compared to Avax’s $180m 2021 programme e.g.) is notable, whether this level of activity and TVL is sustained post the incentives period should be monitored.

Tokenomics Overview

Fundamental to the thesis are the sound tokenomics featured. Whilst the valuation is relatively high at FDV $24bn and circulating market cap of $16bn, the large supply currently tightly held by TON foundation and affiliates, the low inflation rate for validating the network and the methodical OTC sales used to distribute supply to investors are positives.

Current total supply is 5,105,734,318 (5bn issued at launch) with an initial split of 85% tokens to users and 5% to validators. The chain inflates at a rate of 0.6% annually, with the rewards being paid to validators to maintain consensus. Digging a little deeper, we note that ~1.3bn coins are in the Locker Smart Contract (named the Believers Fund), locking over >20% of TON supply until 12 Oct 2025, vesting every month for another 3 years post cliff period. The total comprises ~1 billion TON locked by users and 284 million TON donated for rewards.

In addition to the locker contract, the TON foundation also deactivated ~1.1bn TON held by large early miner wallets that have not had a single outgoing transaction for 48 months. The result of both of these initiatives is the removal of ~47% (2.4bn coins) TON’s supply from circulation for the foreseeable future. Effective circulating market cap therefore is ~$8.5bn.

On the other hand, it is much harder to place a dollar value on the amount of locked OTC coins that have been sold however, based on public announcements there seems to have been at least $30m worth of tokens at least that have been sold to venture and professional investors:

• MEXC Ventures making an ‘eight figure’ investment in TON - October 2023

• Animoca Brands invests in TON Network becoming the largest validator - November 2023

• Mirana Ventures backs TON coin with $8m - March 2024

Given that TON remains in a nascent stage in terms of adoption, the coin has a somewhat weak value accrual narrative around it. However, this should pick up as on-chain activity continues to grow through the burn mechanism in which 50% of all TON fees are burned.

More importantly, Telegram is actively developing utility features for the TON token, which serve as "token sinks" to enhance its value. For instance, Telegram recently announced that it will exclusively use the TON token for ad payments. In this setup, advertisers fund their marketing campaigns using TON, with revenues being split equally between Telegram and content creators. Additionally, Telegram has begun to accept TON for payments related to Telegram Premium, which boasts 5 million subscribers, through the Fragment Store,. These initiatives demonstrate a deliberate effort by the Telegram team to ensure that TON remains a token with practical utility and clear mechanisms for value accrual directly linked to Telegram’s services.

Investment Rationale

Concentrated Supply and an Underowned L1

Moderately low inflation at 0.6%/yr (lower than BTC) with comparatively low float for the medium term given ~50% of the supply locked in both the Believers Fund and inactive miner wallets, combined with the fact that ~86% of mined coins are controlled or at least affiliated to the TON foundation.

Further, majority of attention as well as locked OTC coin investments were done by Asian participants suggesting that EU/US participants are offside (See figure below for cumulative futures returns)

From a technical perspective, the coin is now trading between 2-3x from the start of the year and the 2023 lows. Compared to gains in similar comps such as SOL, AVAX and NEAR, the run up has been fairly muted which allows for much more defined downside risk.

Clear Go-to-Market Strategy and Long Term Vision

Grand vision of building the Web3 SuperApp straight from the convenience of your own phone that can potentially compete with WeChat. This marks a fundamental shift away from the status quo of the slew of crypto blockchains and DApps serving speculators and the tech savvy, which by their very nature are a much smaller TAM and as a result should garner lower valuations. Soft backing by Tether with their integration announcement and of course de facto backed by Telegram with a robust roadmap across TON Blockchain, TON Proxy, TON Payments and TON Storage

Greenfield Growth Opportunities

There is considerably more potential for growth given that currently there are ~3.5m onchain activated wallets compared to Telegram boasting 800 million monthly active users (MAUs), with projections to reach 1.5 billion in the next five years. This represents a substantial yet natural upper bound total addressable market (TAM). TON Foundation is strategically aiming to onboard 30% of Telegram’s MAUs within the next 3-5 years. If Telegram manages to convert even 0.2% of its 200m daily active users), it would surpass Ethereum's current DAU count of approximately 400,000. There’s clearly a huge opportunity for user base expansion.

Crypto-Specific Positive Catalysts

TON has been doing daily $170m+ of volume over the past few months, a spot Binance listing could derisk the investment significantly and provides some upside as well as more downside protection given increased liquidity. Also as ETH continues on its sharding roadmap expect TON to gain further mindshare, given its dynamic sharding architecture, although this is more of a tenuous comparison.

Risks and Mitigants

• Questions surrounding whether the project can sustain its current valuation. It’s an ambitious project that seems to be almost fully valued. At these levels, the chain and native gas token should act as money rather than as a vehicle for tech speculation. Monetary premiums are much harder to obtain than tech premia which are inherently more fleeting.

• Details around TON’s OTC deals would need to be explored further as funds that could potentially be marginal price setters opt into buying discounted OTC tokens instead, reducing open market buy pressure

• Developer engagement is lower than other chains given the somewhat esoteric programming language (FunC) with 39 FT developers, and around 120 monthly active Devs. By comparison ETH has 2,4k FT devs and 7.8k monthly active developers..

• Supply unlocks with the Believers Fund beginning to unlock October 2025 albeit this vests over the course of three years.

• Regulatory risk remains a factor. However, we believe much of that has been derisked given the prior run in with the SEC. Telegram are clearly looking to integrate the token into the platform, there is a reasonable expectation that Telegram has conducted thorough legal due diligence to ensure that their current and future operations with TON abide by necessary legal rules..

Summary

We believe that the vast majority of TON’s growth will not come from already captive on-chain users of EVM and Rust based blockchains. TON is paving a more orthogonal future, carving out its own niche of consumers that value ultra fast, extremely convenient decentralised solutions which prioritise freedom of capital movement and a censorship resistant neo blockchain. In the long-run, an upper bound comparable for TON is BNB at $90bn which is a reasonable and realistic target given the outlined strengths of the investment, providing clear upside and room for BTC outperformance.

Disclaimer

The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.

Sources

• https://www.tonstat.com/

• https://app.ston.fi/liquidity/provide?ft=USD₮&tt=TON

• https://dedust.io/pools/EQA-X_yo3fzzbDbJ_0bzFWKqtRuZFIRa1sJsveZJ1YpViO3r

• https://tonscan.org/stats

• https://tontech.io/stats/#/early-miners

• How to shard your TON smart contract and why - studying the anatomy of TON's Jettons

• https://medium.com/@whiterabbit_hq/ton-blockchain-a-group-of-related-whales-mined-85-of-ton-supply-2e3300cc93bc

• https://ton.vote/EQCb8dxevgHhBnsTodJKXaCrafplHzAHf1V2Adj0GVlhA5xI/proposal/EQCVy5bEWLQZrh5PYb1uP3FSO7xt4Kobyn4T9pGy2c5-i-GS

• https://www.developerreport.com/

Current blockchains have challenges

Today’s major blockchains offer a range of applications, including DeFi, NFTs, social media, and even gaming. However, the quality and capability of these applications are limited by a fundamental challenge: blockchains struggle to process transactions concurrently. In decentralized applications, parallel execution is vital because it allows smart contract platforms to process multiple transactions simultaneously, increasing the overall throughput and responsiveness of the network. To address this crucial obstacle, the last five years of development in the industry have largely been dedicated to improving blockchain performance through parallelization.

In previous reports, we delved into various methods for enhancing scalability, showcasing modular design, innovative architectures like DAGs, and case studies such as Aptos and Sui. However, a commonly overlooked aspect in the blockchain domain is how networks address parallel execution and how these methods can be compared. 

This research report aims to shed light on upcoming layer 1 blockchains that will help solve issues with current blockchains and to establish a classification framework for parallel execution in the future. We will focus on how these solutions enable parallel execution and compare their approaches to overcoming the limitations of existing blockchain networks. By examining the various strategies and techniques employed by these next-generation blockchains, we hope to provide valuable insights into the future of parallel execution and its role in driving blockchain innovation.

The EVM Paradigm

Most current smart contract platforms rely on the Ethereum Virtual Machine (EVM), which suffers from a major drawback: its inability to execute transactions concurrently. This limitation has prompted the development of a new wave of layer 1 solutions emphasizing parallel execution as a means of enhancing scalability and efficiency.

Smart contract blockchains have two main components: the consensus mechanism, which helps nodes agree on transaction ordering and inclusion, and the virtual machine, which runs application code and updates application states and account balances. Ethereum introduced programmable smart contracts through the EVM, a shared system where each node keeps a copy of all applications and their states. Despite its popularity, blockchains using the EVM face limitations in processing speed. For example, Ethereum can process about 10 transactions per second (tps), while the fastest EVM chain, Binance Chain, reaches just over 200 tps. This inefficiency is due to the EVM's sequential processing model, where transactions are processed one after another.

Monad, a scalability-focused layer 1, put this in perspective in a recent article, “For reference: a simple card game with 10,000 users making a move every 10 seconds would need to have 1000 tps.”. As it exists today, it is unlikely that the EVM will be capable of supporting this many transactions within a single chain.

In response to this challenge, developers are exploring solutions that enable parallel execution. This report aims to create a framework to classify how these blockchains achieve parallelization, focusing on parallel execution enhancements. By implementing such strategies, the smart contract ecosystem can overcome the limitations of sequential processing and pave the way for more widespread adoption of decentralized applications.

What exactly is parallel execution? 

In blockchains, parallel execution can be understood through a simple analogy. Picture a grocery store that needs to collect customer payments for their purchases. If the store had only one checkout lane and register, the line would move slowly, frustrating customers and potentially driving them to shop elsewhere. The store employs multiple checkout lanes and registers to speed up the process. This is parallel processing in action, allowing the store to handle several customers simultaneously rather than one at a time.

Applying this analogy to blockchains, the multiple checkout lanes represent different paths or channels for processing transactions. In parallel execution, these channels exist within a single system, enabling it to process multiple transactions at the same time. This setup allows a single blockchain system to handle a higher volume of transactions more efficiently, leading to better overall performance.

Now that we've grasped the importance of parallel execution for blockchain efficiency and scalability let's delve deeper into its mechanics.

How does parallel execution work?

Parallel execution in blockchains means processing unrelated transactions at the same time. Think of unrelated transactions as events that don't impact one another. For instance, if two people trade tokens on separate trading platforms, their transactions can be processed simultaneously. However, if they trade on the same platform, the transactions likely need to be executed in a specific sequence.

The main challenge in implementing parallel execution is determining which transactions are unrelated, or independent. This involves understanding how each transaction affects the blockchain's data. With many interconnected applications, determining which transactions depend on each other can be tricky.

Various blockchain systems use different methods to identify unrelated transactions, typically by managing access to the blockchain's data. Each account or smart contract has its own designated range of data that it can change. Independent transactions don't try to change the same data in the same block, whereas related transactions do.

Some transactions are easier to identify as unrelated than others. For example, a simple token transfer between two people doesn't affect anyone else, so it's clear that these types of transactions are almost always independent. However, transactions involving the same smart contract or account can change its data and can't be executed in parallel. An example would be a token trade that involves multiple platforms, where all participating platforms must wait for the initial transaction's completion before processing other transactions.

In the following sections, we will delve into three distinct methods of achieving parallel execution in blockchain systems: state access/optimistic, sharding, and computation-based parallel execution. It's worth noting that traditionally, only the state access and optimistic models have been considered as true parallel execution methods by others in the blockchain industry, as they enable a single blockchain to process transactions simultaneously. However, with the advent of sophisticated cross-chain communication protocols, the notion of what constitutes parallel execution has expanded significantly. Sharding, for instance, while not traditionally viewed as a method of parallel execution, indeed facilitates parallel processing of transactions across multiple shards, thus warranting consideration. Lastly, we will explore the relatively new concept of computation-based parallel execution. This innovative model, although not widely known yet, represents a revolutionary approach to parallel transaction processing in blockchain systems, and we will cover it in detail later in this paper. As we explore these methods, we will uncover how each one offers unique advantages and presents distinct challenges, paving the way for a more efficient and scalable future for blockchain technology.

Parallel Execution: State Access and Optimistic Models

Currently, most blockchains that feature parallel execution rely on two popular methodologies: the state access method and the optimistic model. The state access method is a strategic approach that preemptively identifies which transactions have access to which part of the blockchain’s state, thus allowing the blockchain to declare which are independent easily. On the other hand, the optimistic model operates under the assumption that all transactions are independent, only to retrospectively verify this assumption and make adjustments where necessary. Several blockchains utilize these methods to facilitate parallelization, showcasing each of these theoretical approaches in action. When people discuss parallel blockchains, these are typically the models they're referring to. This section will explain these two methodologies and their applications in the blockchain landscape.

Solana: The Pioneer of Parallel Blockchains

Solana has distinguished itself as a forerunner in the blockchain landscape, pioneering a unique method to manage transactions and amplify scalability. Its groundbreaking innovation is determining which portions of the blockchain state - the comprehensive record of all accounts or assets - can be accessed by a specific operation.

Picture it as an expansive filing system. Each transaction submits a request to access a particular file. If the file requests are unique, the transactions can be processed independently. But if they request the same file, these transactions become intertwined and require coordination. The real trick is pinpointing which transaction is requesting which file.

Solana, as the first-ever parallel blockchain, introduced a solution. Each transaction must upfront declare which file it intends to access. This requirement is included in Solana's 'Sea Level' execution model, where everything functions within an account-based framework. Each account can only be accessed by a transaction that's linked to it, thereby preventing potential conflicts.

Crucially, Solana also uses stateless programs contained within these accounts. Stateless programs are pieces of code that don't remember any data between executions - they start from scratch every time they're run. When a function call is made, these programs are activated, performing their tasks without relying on any past data. This concept helps maintain transaction independence and contributes to Solana's innovative approach to improving blockchain scalability.

Sui: Introducing The Concepts of Objects

Sui has recently made its debut, causing quite a stir in the blockchain sphere. But what precisely does Sui bring to the table? To dive into the nuances of Sui's architecture, our team has crafted a comprehensive paper comparing it with Aptos (another blockchain we'll explore further down the line). At this juncture, however, our primary focus is on understanding Sui's unique approach to achieving parallel transaction execution.

Sui's parallelization strategy echoes Solana's, but with a distinctive twist: replacing accounts with a construct known as 'objects.' Sui transactions do not reference accounts, rather, they change the attributes of objects, which can be assets or smart contracts. If a transaction is designated as independent (that is, if no other transaction interacts with the targeted object), it bypasses the consensus mechanism entirely - a feature referred to as byzantine consistent broadcasting.

To illustrate, imagine Alice owns a unique NFT, which in Sui's context is represented as an object with “Alice” listed as its “owner". If Alice transfers this NFT to Bob, the transaction, being an independent object transaction, circumvents the consensus process. However, if Alice decides to execute a more complex action, such as purchasing an NFT via a marketplace, the dynamics change. Because the object can be acted upon by other transactions, the transaction may be designated as  dependent and may require sequential ordering prior to its execution.

Fuel: Capitalizing on UTXO for Enhanced Execution

Fuel is a standout player in the blockchain space, making optimal use of the UTXO (Unspent Transaction Output) model. If you think of the UTXO model as a physical cash transaction, it's akin to handing over a 10-dollar bill for a 7-dollar item and receiving 3 dollars in change. By using the UTXO model, Fuel can efficiently parallelize transactions. This is because the UTXO model allows for easy identification of independent transactions - those that don't overlap in the objects, or "bills," they are interacting with. This independence means that such transactions can be processed simultaneously without conflict, significantly enhancing transaction throughput.

The UTXO model, also employed by Bitcoin, is leveraged by Fuel to build strict access lists. These lists serve as regulators, controlling which parts of the blockchain state can be accessed. This strategy relies on the idea of Canonical Transaction Ordering, which arranges transactions within a block in a way that simplifies the process of identifying inter-transaction dependencies.

Fuel brings this concept to life through the development of FuelVM, a new virtual machine, and Sway, an innovative programming language. FuelVM is designed as a streamlined yet fully compatible alternative to Ethereum's Virtual Machine (EVM), which makes it more straightforward for developers to integrate into the Fuel ecosystem.

On top of this, Fuel emphasizes a modular blockchain structure. This modular approach allows transactions executed within Fuel to be settled on the Ethereum mainnet network. Consequently, Fuel is equipped to handle a large number of transactions, all of which are consolidated and settled on Ethereum. This strategic move allows Fuel to manage heavy transaction loads efficiently.

Aptos: Executing Optimistically

In our exploration of blockchain parallelization, we've first described how blockchains can establish dependencies right when a transaction is initiated. We call this the state access method, where the smart contract or developer defines which transactions have access to which part of the state. We now pivot to a different technique called optimistic execution. Optimistic execution is a strategy where each transaction is processed as if it's not connected to any other, allowing all of them to be worked on simultaneously. However, if it turns out that some transactions are linked, they're stopped, their results are wiped, and they're run again. This can speed things up when transactions are mostly stand-alone, but when many transactions are linked, the process has to stop and reset often, which can slow things down.

Aptos uses a method called Block-Software Transactional Memory (Block-STM) to apply this kind of optimistic execution. Aptos is built on Diem's Move language and MoveVM, and it can automatically spot when transactions are linked. It does this without needing the transactions to say which part of the blockchain state (like memory locations) they touch.

A screenshot from the Block-STM whitepaper showcasing how if it turns out that some transactions are linked, the validation is suspended, the results are wiped, and it is run again.

In Block-STM, transactions are first set up in a certain order within a block and then split up amongst different processing threads for simultaneous execution. As these transactions are processed, the system keeps track of the memory locations that each one changes. After each round of processing, the system checks all transaction results. If it finds that a transaction has touched memory locations changed by earlier transactions, its result is wiped and run again. This continues until every transaction in the block has been processed.

The success of Block-STM depends a lot on how linked the transactions are. According to the Aptos team, using 32 processing cores can lead to an eight times speed increase when transactions are highly linked, and a sixteen times increase when linkage is low. However, if every transaction in a block is linked, Block-STM may cause a slight slowdown compared to one-by-one execution.

Monad: The Trendsetter of EVM Chains

Monad is pioneering a new approach among EVM-compatible blockchains, being the first to introduce a parallelized architecture to an EVM layer 1. Like Aptos, it takes an optimistic execution path, operating under the assumption that transactions aren't interconnected, and addressing any dependencies as they arise.

This novel approach hasn't been without its challenges. Implementing significant modifications to blockchain technology is a complex and long-term commitment. Despite this, Monad has remained dedicated to innovation and has become a beacon for other blockchain networks aiming to enhance their own architectures.

Consider the cases of Polygon and Binance Smart Chain, both prominent blockchains that are now working on upgrading their systems to adopt similar strategies. The importance of Monad's pioneering work in optimistic execution cannot be overstated, as it has influenced these large-scale platforms to reevaluate and modify their own architectures.

Polygon, for instance, boasts a fast throughput and a daily transaction volume in the millions. Their network's APIs already provide sufficient data to drive a parallelizable engine, and by exploring an EVM-specific Block-STM, they've managed to avoid the need for API changes. However, given the sheer volume of transactions on the Polygon PoS chain, the assumption of zero dependencies among any block is not practical. Hence, they adopted a minimal metadata approach where transaction dependencies are recorded as metadata in a block, reducing redundancy and computational requirements.

Similarly, Binance Smart Chain is also exploring opportunities for parallel execution within their EVM chain via optimistic execution, reflecting the industry-wide impact of Monad's innovative approach.

Monad's innovative spirit and its commitment to pushing the boundaries of blockchain technology have set a new trend in the EVM space. Its approach to parallelized architecture in an EVM layer 1 has not only improved the efficiency of its own system but has also influenced and inspired other significant players in the field to follow suit, marking a significant shift in the blockchain industry's future.

Sharding-Based Parallel Execution:

So far, we've discussed how various blockchains shatter sequential ordering and achieve parallelization through concepts such as accounts, objects, UTXOs, and optimistic models. However, the next-generation blockchains we're about to examine take a distinct approach to parallelization. Instead of having a single blockchain capable of processing transactions in parallel, these platforms resemble sharding models. The blockchain is partitioned into multiple segments, each responsible for processing its own transactions.

Shardeum: a Sharded Approach to the EVM

Shardeum brings a groundbreaking approach to blockchain scalability through dynamic state sharding, enabling linear scalability. Shards, sub-sections of the network, each handle a portion of the network’s transactions, fostering enhanced resource efficiency and improved throughput. Consider a user transacting on a decentralized application (dapp) hosted on Shardeum. The transaction is assigned to a specific shard based on its associated data. The shard processes the transaction concurrently with others in its jurisdiction, acting like a mini-blockchain. The user benefits from quicker processing, optimizing the user experience.

A key feature of Shardeum is its Ethereum Virtual Machine (EVM) compatibility. Developers can migrate their Ethereum-based dapps to Shardeum with ease, combining Shardeum’s dynamic state sharding and parallel processing with the extensive Ethereum ecosystem.

Dynamic state sharding ensures the network’s adaptability to fluctuating demand, facilitating a scalable, efficient system. Shardeum executes cross-shard transactions atomically, allowing for the seamless execution of complex applications that require multiple user inputs, thus enhancing scalability.

The unique feature of Shardeum lies in its linear scaling capabilities. The network scales linearly as more nodes are added, meaning the transaction throughput increases proportionally with the number of nodes. This linear scaling, combined with node flexibility and auto-scaling features, allows Shardeum to handle varying workloads and network growth optimally. Shardeum marks a significant step towards realizing the full potential of blockchain technology by enhancing scalability for complex applications and offering a practical solution for real-world transaction demands.

Linera: ​​A Revolutionary Multi-Chain Protocol

Linera's innovative solution to blockchain scalability distinguishes itself through its dynamic multi-chain protocol, which encompasses user chains, public chains, and temporary chains.

The illustration above shows the three different chain types in the Linera system: user chains, public chains, and temporary (temp) chains. Each chain type has a distinct role, contributing to the protocol's overall functionality and scalability.

Unlike Shardeum, which partitions its network into numerous shard chains, each responsible for a subset of transactions, Linera pioneers the concept of user-controlled chains. This granular approach provides users with increased control and autonomy while optimizing resource allocation across the network.

User chains, individually owned and controlled by users, form the backbone of Linera's architecture. These chains process transactions by a specific end-user independently, allowing for parallel execution and significantly improving throughput while reducing latency. 

Public chains constitute another critical component of Linera's design. These chains are where decentralized applications, such as Automated Market Makers (AMMs), reside. Public chains are open to all network participants and provide a common platform for applications that require open and unrestricted interaction.

Linera also introduces the concept of temporary chains, purpose-built for handling complex operations like atomic swaps. This feature offers a significant advantage over protocols that require transactions to be recorded on the main chain, potentially causing bottlenecks. In Linera, a temporary chain is created for the duration of an atomic swap, processing independently of and in parallel with other transactions. Once the swap concludes, the temporary chain dissolves, and the updated states are reflected in the involved user chains.

The protocol's structure supports horizontal scaling, an essential feature for maintaining system performance under varying loads. As traffic increases, validators can add more worker machines to manage the increased activity and maintain high throughput under heavy loads.

Unlike other protocols such as Cosmos, where each blockchain or "zone" is operated by a distinct set of validators, Linera unifies all chains within a single set of validators. This unified approach bolsters Linera's protocol's efficiency and security, streamlining cross-chain interactions by removing the complexities of validation by separate validator sets, which could potentially lead to increased latency or discrepancies. Consequently, transactions are processed more efficiently across the entire ecosystem, significantly reducing the risk of conflicts.

Quai Network : Powering Parallelism and Interoperability with Proof-of-Work

Quai Network carves its path in the blockchain industry with its distinctive approach to scalability. By implementing a dynamic and interoperable multi-chain architecture, Quai offers a unique Proof-of-Work-based solution to the scalability problem that enables transaction parallelization via infinite execution sharding. This approach differentiates Quai from protocols like Linera, which utilizes user-controlled chains, while sharing some similarities with Shardeum’s dynamic sharding.

Quai employs a version of sharding akin to traditional methods used to enhance database performance in centralized systems. However, Quai diverges from typical sharding schemes with its dynamic, adaptable and deeply interwoven multi-chain architecture. This is somewhat similar to Shardeum’s dynamic sharding, where the network is divided into shard chains that process transactions independently. However, Quai’s use of merged mining to coordinate these distinct shards creates a uniquely interconnected structure that allows for parallel execution of operations across the network. Unlike all existing implementations of sharding, which introduce some new mechanism of trust to facilitate interoperability (cross-shard transactions), Quai Network’s use of merged mining to interconnect shards ensures that the only mechanism required to process cross-chain transactions is mining. Quai Network’s unique method of achieving interoperability via merged mining significantly enhances throughput and provides the ability to accommodate high volumes of simultaneous transactions without any sacrifice to decentralization or performance.

To enable the coordination of an infinite number of execution shards, Quai Network has introduced a new consensus mechanism known as Proof-of-Entropy-Minima (PoEM). PoEM is based on Proof-of-Work (PoW) consensus but differentiates itself from other consensus mechanisms as the first consensus mechanism to eliminate consensus-based forks. When running PoEM, all nodes will always immediately have the same preference for the next block in the sequence given the same set of information. PoEM allows all nodes to immediately and fairly compare any proposed blocks against each other which eliminates all uncertainty for consensus. By ensuring that consensus is always instantaneous, PoEM provides the necessary prerequisite to infinite sharding. If consensus requires any time to be established, there is a hard limit on the number of execution shards that can be coordinated. PoEM, as the first “zero-time” method of reaching consensus, is the first and only consensus algorithm suited to coordinate an infinitely growing set of chains.

A standout feature of Quai’s architecture is the introduction of Parallel Execution Threads (PETs), referred to in Quai as “Zones.” Each “Zone,” or parallel execution thread, independently and asynchronously processes transactions. The ability for each Quai execution thread to independently process transactions enables the network’s parallel processing capabilities and is one of the core concepts behind Quai’s scalability.

The number of chains in Quai Network is dynamic and adaptable, much like Shardeum’s dynamic shards. Uniquely, however, Quai Network’s use of the PoEM consensus mechanism allows this pattern of dynamic sharding to be performed infinitely with no degradation of performance. Quai Network’s addition of execution shards through dynamic sharding has one clear tradeoff: as more execution shards are added to the network, the time a cross-chain transaction takes to be reference-able by its destination shard will increase. This relationship is sublinear -- Quai’s expansion from 9 shards to 16 shards, for example, would increase the average time for a cross-chain transaction to reach its destination from 3,300 seconds to 4,400 seconds. A further expansion to 25 shards would increase this average time to ~5,500 seconds. Theoretically, if Quai were to expand to 100 shards, the average time to global cross-chain settlement would be ~11,000 seconds. Quai Network’s dynamic sharding algorithm monitors the gas limit and uncle rate of the network to know when additional throughput is demanded, and automatically braids additional execution shards into consensus to accommodate increased demand for throughput.

Furthermore, Quai’s braided structure supports composable multi-chain smart contracts and allows efficient cross-chain contract interactions. Each Quai execution thread has an EVM on top of it, with new op-codes introduced to enable communication with EVMs located on alternate shards. This capability empowers developers to deploy contracts across multiple or all Quai chains, ensuring the operability of decentralized applications (dapps) across the entire network.

Quai Network’s innovative application of sharding, coupled with its merge-mined interoperability and parallel execution threads, represents a significant stride in blockchain scalability within a work-based consensus mechanism. The robust handling of cross-chain transactions and advanced smart contract functionality positions Quai as a noteworthy contributor in the evolving landscape of scalable blockchain protocols.

Computation-Based Parallel Execution:

An emerging paradigm in blockchain parallel execution is the computation-based model. This term, coined by our research team at Amber Group, describes an approach in which computational tasks are processed simultaneously within a shared environment. Distinct from the state access and optimistic models, the computation-based model does not strictly rely on sequential memory-based computations. Instead, it operates on the principles of a highly parallel virtual machine. This design promotes robust and highly efficient parallel execution. The following section will explore the principles of computation-based parallel execution, its potential applications, and the unique challenges it introduces to the broader blockchain technology landscape, providing a comprehensive understanding of this new category of parallel execution within the blockchain environment.

Kindelia: The Pinnacle of Computation-Based Parallel Execution

Kindelia has emerged as a promising solution in the computation-based model of parallel execution in the blockchain. Developed by the Higher Order Company, it is anchored on a unique runtime known as the Higher-Order Virtual Machine (HVM), which enables highly efficient parallel computations.

Kindelia's innovation is founded on a new type of computational model known as "interaction nets," a concept that deviates from the Turing machine model that underpins the majority of modern computers. Interaction nets are based on a graph of interacting nodes, with each node possessing a set of rewrite rules dictating how it interacts with others in the network. Computation is achieved by reducing the interaction net, and systematically eliminating nodes from the network according to their rewrite rules until a final state is reached. This model allows computations to occur in parallel without needing a central clock to dictate the process, as nodes interact locally without any global coordination.

Victor Taelin’s (the CEO of Higher Order Company) personal drawings teach how Interaction Nets can be reduced.

The advantages of this model are manifold. It promotes faster and more efficient computation due to its inherent parallelism, vastly outperforming traditional sequential models of computation. Furthermore, it opens up a realm of applications in various areas of computer science. In the blockchain context, Kindelia stands out as the first truly parallel virtual machine, achieving what many alternative layer 1 companies aspire to. However, due to their reliance on Turing machine-based architectures, these competitors will likely never reach the same level of parallelization.

Kindelia's design requires fewer computational steps to execute functions, maximizes the use of processing cores, and ensures that operations execute in the correct order—all with a minimal extra effort from developers. This streamlined execution process, coupled with the higher level of security, positions Kindelia as a cutting-edge example of computation-based parallel execution in blockchain technology.

Although the theoretical underpinnings of Kindelia and the HVM are advanced, the practical implications are easy to understand: increased speed, efficiency, and security in blockchain computation. Through Kindelia, we are witnessing a revolutionary leap in blockchain technology, marking a significant milestone in the continuous evolution of this transformative field.

Concerns with Parallel Execution

As we explore the potential of parallel blockchains, it's crucial to acknowledge that while they present substantial scalability and speed advantages, they also introduce unique challenges and potential drawbacks. Two primary concerns that are frequently highlighted are the possibility of increased centralization and the issue of high transaction conflict rates.

Parallel blockchains distribute transaction processing among numerous nodes, thereby enhancing transaction processing throughput. However, this distribution can also lead to a concentration of power within a few nodes, thus introducing a degree of centralization. This centralization could potentially undermine the trustworthiness and security of the blockchain, making it more susceptible to attacks. Additionally, the risk of network downtime increases with parallel blockchains. For instance, the Solana network experienced a downtime event in September 2021 due to an overabundance of transaction requests. This incident underscores the potential risks associated with scaling blockchain networks and emphasizes the necessity for solutions to handle high transaction volumes without compromising stability.

The transaction conflict rate is another significant concern. This rate refers to the percentage of transactions that cannot be executed simultaneously due to conflicts. A high conflict rate can lead to numerous transaction redos in a parallel blockchain. According to a report by Flashbots, Ethereum transactions in 2017 had a conflict rate of around 35%. With major applications such as OpenSea and Uniswap dominating the Ethereum network today, the conflict rate could potentially be even higher.

In the context of optimistic execution, if the conflict rate exceeds 30%, the number of transaction redos can significantly disrupt the pipeline. Each redo slows down the transaction processing speed, reducing the impending benefits of parallelization. Consequently, managing the transaction conflict rate is of utmost importance for ensuring the efficiency of parallel blockchains.

Conclusion

The blockchain landscape is evolving significantly as it seeks to address scalability and efficiency issues inherent in its design. We have explored the various methods through which parallel execution can be achieved, each with its distinct set of advantages and challenges. The state access-based model marks the first step towards overcoming the sequential nature of blockchains. Optimistic execution, while promising, introduces the risk of conflicts and the need for efficient conflict resolution strategies. Sharding takes us a step further by partitioning the network into smaller, manageable pieces, each capable of processing transactions independently. Lastly, computation-based parallel execution uses cutting-edge computer science to maximize node performance and application security. Although challenges and potential concerns exist, these models demonstrate the potential to enhance the performance and capability of blockchain technology significantly. As these continue to evolve and mature, we stand at the cusp of a new era in blockchain technology.

Author

Robert McTague is an Investment Associate for Amber Group's Eco Fund, the company's early-stage crypto venture fund. 

Disclaimer

The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.

Earlier this year, Twitter axed third-party apps without warning. A few weeks later, it removed free API access - its cheapest package now costs $42k per month. 

Most users are attuned to this reality by now. Our most important social media apps, from Facebook and TikTok to WeChat and Grab, are centralized silos. While typically docile, these platforms occasionally flex their powers in ways that highlight the capricious nature of centralized authorities, such as censoring and banning users over vague content policies or arbitrarily boosting certain users over others.

These platforms are crucial in our everyday lives. So understandably, users are frustrated by the status quo but left with little alternatives. Therefore, it is no wonder that amid the broad Web3 movement, decentralized social media is a focus vertical. And as the crypto industry seemingly runs on Twitter, building a “decentralized Twitter” can be particularly attractive to Web3 founders, who are acutely aware of Twitter’s pain points.

This report explores decentralized social (DeSoc) protocols. We examine various DeSoc designs and spotlight interesting projects. We also provide our analysis on the pros and cons of each protocol’s approach and outline our thoughts on the vertical overall. 

The Value of Social Graphs

Since its founding, Twitter has had over 19 funding rounds that raised $4.4 billion in capital. It has lost nearly $1 billion cumulatively while it was public. All the while, the product itself has hardly changed over the last five years. 

Yet, Twitter is still incredibly valuable. Depending on which billionaire you ask, its valuation is at least billions of dollars. If put up for auction today, there would undoubtedly be a plethora of buyers willing to bid at generous valuations to Twitter’s revenue.

The key to Twitter's—and any social media platform’s—value lies primarily in its social graph. Features are commodities (see: Clubhouse spaces, Snapchat stories, TikTok/Douyin short-form videos). But unique and differentiated social graphs are immensely valuable. It's what allows niche platforms to grow and maintain share amidst fierce competition (examples: Bilibili, GitHub, LinkedIn, Twitch). Conversely, weak social graphs demoralize users and are to death spirals (examples: Clubhouse, MySpace, Friendster, Vine, Renren, YY, Digg).

Incumbent platforms have long caught on to this and capture value by locking users in. Thus, most users are beholden to incumbent platforms with minimal viable options to exit. 

Decentralized social networks hold the promise of returning value derived from social graphs back to users. The overarching thesis suggests that this approach removes rent-seeking behavior and fosters increased competition on products and features, ultimately creating value for users.

The Promise of Decentralized Social Networks

Censorship resistance and ownership.

One of the clearest benefits of building DeSoc protocols is the guarantee of open access. Decentralized social networks should allow two users to find and communicate with each other, even if all other users want to prevent it. These networks should also allow users to post content and find the content that they want.

This is not to say that centralized filters cannot be applied on top. We can look at Gmail's relationship with decentralized email protocols (SMTP, POP3, IMAP) to imagine what a robust decentralized social network could resemble. Although Gmail is a centralized application, users can choose other clients or own their domain, giving them more control over their data, privacy, and communication preferences. The cost of substitution is trivial.

Most DeSoc protocols have a similar architecture. As a result, users truly own their social graph, giving them the freedom to exit from any one application built on top. 

Composability → Innovation.

Open access to DeSoc protocols will likely lead to faster and more significant innovation among applications built on top of them. This aligns with the previous point - if users have minimal exit costs, applications must compete to provide the best user experience.

In fact, when Twitter's APIs were relatively open access, it had a similar innovation cycle. Many Twitter inventions originated from outside developers. Twitterrific coined the Twitter bird and the term "tweet." Tweetie, another third-party client, created the pull-to-refresh gesture. And widely used TweetDeck emerged first as a third-party platform for managing multiple accounts and tweeting content. Likewise, Facebook had an impactful innovation cycle when it was open access, allowing apps like Zynga, Buzzfeed, Pinterest, and others to leverage Facebook’s social graph and newsfeed for distribution.

But when user growth nears saturation, Web2 platforms tend to shift from cooperating to competing with their partners. Over time, entrepreneurs learn to not build on top of centralized platforms, limiting innovation. 

In contrast, decentralized social networks assure users that access remains open and permissionless. With that guarantee, they are better positioned to attract bright founders over time and foster a robust, positive-sum ecosystem.

Native crypto primitives.

Crypto and DeSoc protocols are often (but not necessarily!) interlinked due to the emphasis on decentralization. For example, profiles in social graph protocols CyberConnect and Lens live on L1 blockchains, and Farcaster IDs are minted on Ethereum. 

This connection to native digital ownership creates a design space largely overlooked by existing social media platforms. Crypto could be utilized as a simple financial primitive to transfer value across the network. For example, Nostr integrates the Lightning network for low-cost Bitcoin tipping.

Crypto primitives can also enhance interaction quality. Spam and bots plague all social media platforms. But because most crypto actions carry financial weight (even in the form of a negligible gas cost), the history of crypto addresses can act as an effective filtering mechanism. Some early experimentation includes building a higher-quality feed or gating a community based on an address’ NFT collection.

Challenges and Open Questions in DeSoc

Chicken-and-egg problem.

The most obvious challenge for any platform/network founder is sparking initial network effects. The value of a network increases as more people use it. By corollary, this suggests that new networks have minimal value. With little value for early users, attracting and retaining them is often the biggest hurdle. And even after gaining a niche community, expanding that into the mainstream is also incredibly challenging.

This is especially true today. Whereas Twitter gained wide adoption with little competition, current generations of social media platforms compete against incumbent platforms with formidable moats and lots of capital. And because users have already built up their social networks and status on existing platforms, rebuilding social capital on a completely new one can be a non-starter.

BitClout tried to solve this by scraping and importing existing social graphs from Twitter to its platform. At launch, BitClout had preloaded profiles of thousands of prominent Twitter users, including Elon Musk, Katy Perry, and Barack Obama. While the campaign served as an effective marketing tactic, the app's lack of differentiation and lack of an organic community failed to keep users engaged, leading to rapid user attrition.

Nonetheless, as seen with the relatively recent rise of TikTok, the cold-start challenge is not insurmountable. Finding a real use case that delivers utility and differentiating experience to users will be key. Further, some DeSoc protocols may not aim for the largest market share and instead opt to be similar to where Linux stands as compared to Windows and Mac, focusing on serving a dedicated niche audience that values open-source, control, and/or privacy over widespread adoption.

Infrastructure and UX gaps

Most DeSoc protocols use public and private keys to give users ownership of their identities. Examples include: Nostr, Farcaster, Lens, and CyberConnect. But setting up a private key is generally more confusing, at least for now,  than traditional log in methods.

And using a private key comes with challenges. What happens if users lose their private key? Some, like Farcaster, have recovery flows but they are complicated. Others, like Damus, have no recovery options. Without proper designs to mitigate private key compromises, users may need to rebuild their social graph entirely. Self-custody is a double-edged sword.

Other hurdles include on-chain actions requiring private key signing and transaction fees, which are significant UX downgrades compared to Web2 platforms. One can easily feel the difference between the ease of onboarding and using TikTok and the strain of doing the same for any one of the DeSoc apps we highlight below.

This will all be solved over time. MPC and smart contract wallets can help with setting up social recovery and abstracting gas costs. But for now, wallet, custody, and recovery are key hurdles in user adoption.

Monetization - an open question

Because virtually all incumbent social media platforms monetize through ad spend, generating revenue through other means still remains an open question.

DeSoc protocols are experimenting with mint fees (one-time payment for unique ID), subscription models (such as paying for unique usernames or permissioned relays) and take-rate models (taking a cut of money circulated on the platform). While these business models make sense on paper, there’s little evidence so far that they are practical on a large scale. Users like the price of free. 

Other open questions:

• Wen token? Do DeSoc protocols require tokens for decentralized governance (like ENS, Uniswap) or can they stay decentralized without tokens (like Linux, Android)? 

• Should developers of DeSoc protocols see equity-like/token upside of the protocol? If they do, would that create perverse incentives? If they don’t, how to sufficiently incentivize developers and give them the resources to build and scale a platform that can rival web2 incumbents?

• Relatedly, how should developers think about raising capital? Some attempt to maximize credibly neutrality by refusing external capital. Others argue that without a sizable warchest, they cannot sufficiently compete against Web2 incumbents.

Industry Map and Where We Are in the Adoption Cycle

Occasionally, a decentralized social app will suddenly see high user signups from external controversies or hype. The Mastodon social network grew by nearly 5x after Elon Musk fired thousands of staff, changed verification policies, and arbitrarily added/removed accounts. And just recently, Damus saw an influx of Chinese users seemingly out of nowhere, rocketing to the top 21 spot among all social apps in China. 

But users tend to churn incredibly quickly and return to incumbent platforms. (To be fair to Damus, the app was ordered to be removed from the App Store by the Cyberspace Administration of China).

On the whole, DeSoc protocols and applications are still arguably in the innovator’s stage of the adoption curve. 

On all metrics, DeSoc adoption is several orders of magnitude lower than incumbent platforms. Total active users on Mastodon and Damus - two relatively popular DeSoc platforms - are still only a mere fraction of Twitter’s MAU. No DeSoc network is a clear winner yet - teams are still experimenting with appropriate architecture to offer good UX while maintaining decentralization.

We highlight some of the more interesting projects below. We primarily focus on the protocol’s design at a high level, weigh its advantages and challenges and provide some commentary based on our analysis. We will not delve deeply into each protocol’s technical implementation within the scope of this report.

Mastodon - Enter the Fediverse

Mastodon emerged as the notable alternative to Twitter, particularly in wake of recent controversies surrounding Twitter. 

Mastodon is built on a network of independently hosted servers called instances. Each instance is managed by its own administrator, who sets the rules and policies for its specific community. Administrators can ban, censor, or encourage content according to their preferences, although many of the servers we have visited strive for neutrality. Accordingly, Mastodon's philosophy encourages users to choose the instance that best aligns with their values and preferences or host their own instance.

Mastodon uses ActivityPub, a standardized, open-source protocol for social networking. It is part of “fediverse”, or federated universe, a term for all platforms that can communicate with each other using the ActivityPub protocol.

Mastodon’s development is crowd funded via Patreon and OpenCollective. No VC is involved.

Pros:

• All the advantages that come with DeSoc platforms - open-sourced, ability to own and control data and social graph, and freedom to exit from one client to another.

• Use of ActivityPub, an open and decentralized protocol for social networking, which significantly improves interoperability and decentralization.

• Strong community focus: Many users appreciate the community-driven nature of Mastodon, where smaller instances foster a more intimate and supportive environment.

Challenges:

• Instances are mostly run by individuals or groups with fewer resources than Web2 incumbents. Most servers are managed by volunteers who bear the responsibility for running their own instances. This includes maintenance costs (e.g., licenses, hardware, electricity) and content moderation risks (e.g., unsavory/unwanted content, copyright infringement, extremist content, and more). Servers can be glitchy, and search features are underpowered compared to Web2 platforms. Inconsistent moderation across different servers can lead to frustrating experiences.

• Whereas Twitter is like a “boiling pot” of all types of diverse interests, topics, and languages, Mastodon’s server architecture tends to verticalize topics. This can fragment the user base, reduce use cases, and minimize serendipitous discovery.

• Difficult onboarding: Twitter can already seem intimidating for new users. Mastodon makes the onboarding process even more complex, with finding and following users across different servers proving more burdensome.

Other points:

• Does not directly incorporate features or technologies from crypto/blockchain. Any such integrations would be third-party developments built on top of Mastodon.

• Variable monetization: Some servers are entirely volunteer-run and ask for donations to maintain the server, while others run advertisements.

Resources:

• Mastodon documentation

• List of Mastodon servers

Our Take

Mastodon's philosophical and design goals are admirable. It gives users the option to create, curate, and choose their own social network experience. And because of its open-source and community-driven development, it will likely remain an essential part of decentralized social media for the long term.

However, several barriers will likely prevent it from reaching the mainstream. Its fragmentation of user base via segregating servers dampens its ability to achieve network effects and broader use cases. For example, although breaking news tends to spread first on Twitter, it is difficult to see that similarly happening on Mastodon. Additionally, the current user experience is lacking, which could explain the poor user retention after the influx of new users from the Twitter event.

Nevertheless, Mastodon serves as a strong alternative for users seeking a close-knit community with shared interests. And, down the road, developers may continue building on top of Mastodon and create third-party applications with seamless navigation and improved user experience.

Farcaster - Sufficiently Decentralized Protocol

Farcaster is a sufficiently decentralized social network built on top of Ethereum. Sufficient decentralization, a term coined by the Farcaster team, is achieved when two users can find each other and communicate, even if the rest of the network wants to prevent it.

Though Farcaster utilizes Ethereum for part of its tech stack, it does not host the entire social network on a blockchain. Instead, Farcaster IDs are registered on Ethereum, while its social graph and content are hosted across a network of nodes called Hubs. These Hubs ensure consistency across the network as they replicate all data and signed messages. The Farcaster protocol also prunes messages to keep Hubs lightweight, improving the protocol's decentralization.

Farcaster promotes competition at the application and client layer. The team believes that superior apps should evolve from this architecture. Since user distribution occurs at the protocol layer, an app with a killer feature should theoretically be able to leverage the protocol's underlying distribution to gain market share. This would be like if Clubhouse leveraged the social graphs of Twitter/Instagram users upon launch.

Farcaster is currently invite-only with ~11k total users registered. The Farcaster protocol is being developed by Merkle Manufactory, which raised $30 million in a round led by a16z last summer. Merkle Manufactory is concurrently building a mobile/desktop client on top of Farcaster called Warpcast. 

Pros:

• With Merkle developing both the protocol and the first client application, it can test and ship new features at a pace similar to Web2 competitors. Warpcast has already seen significant improvements over the last few months, including the launch of a desktop client, QR log-in, mobile app through the app store, and more.

• Even in its early stage, Warpcast feels very familiar to Twitter users with a smooth onboarding experience.

• Thoughtful designs for trustworthy IDs and account recoveries

  • ID: while the primary namespace is fully decentralized, a secondary namespace can be governed. So if you register on Farcaster, no one can take your unique ID (e.g., @918392) away from you, but if you falsely register the handle @jeffbezos, the secondary namespace can elect to take that away from you.

  • Recovery: Built-inrecovery system in case a private key is lost/compromised, with a 7-day window to prevent hostile takeover of accounts.

• Because Farcaster ID’s live on Ethereum L1, there is more flexibility to integrate other crypto elements into clients. For instance, Warpcast incorporates NFT authentication and discoverability into its client.

Challenges:

• Merkle will have to prove its credible neutrality over time, as thus far both the protocol and the de facto client are being developed by a centralized team. VC backing may also hinder claims of credible neutrality.

• Relatedly, because Merkle has a first-mover advantage and is the first to know about new protocol developments, its default client may crowd out third-party clients.

• Growing pains from being at the early stage - such as a user impersonating Apple’s CEO by claiming the @timcook handle.

Other points:

• Monetization will likely be through paying a fee for unique Farcaster names (e.g. @elonmusk), although this is not live yet nor set in stone..

• GTM appears to be curating a western-oriented tech community, including those working in Web2, Web3, VC, etc.

Resources:

• Warpcast’s web page

• Launchcaster - a third party application that surfaces new Web3 projects

• Sufficient Decentralization for Social Networks

• List of applications in Farcaster’s ecosystem

Our Take

Farcaster's more centralized structure at the moment enables it to better respond to user feedback, rapidly iterate, and achieve product-market fit. Its architecture is well-designed and should easily scale to accommodate millions of users. Additionally, Merkle's VC backing offers both financial and networking resources to aid Farcaster's growth.

We are optimistic about the team’s ability to grow its user base beyond the current user niche. The initial go-to-market strategy of targeting tech enthusiasts is clever, as these users are often early adopters of new platforms and more likely to contribute to open-source protocols. There’s already a vibrant developer community, with a myriad of applications leveraging Farcaster’s social graph. A dynamic similar to what Instagram and Vine did for the Twitter feed a decade ago could similarly play out in Farcaster’s ecosystem.

Our primary concern lies in how Farcaster progressively decentralizes over time. This will only be solved over time as the Farcaster team demonstrates that they can slowly let go of the reins, make it easier for developers to run Hubs, and allow third-party developers to compete with Warpcast on a level playing field. 

Lens - Own Your Digital Roots

Built by Aave’s team, Lens Protocol is a smart contract-based social networking platform built on Polygon. Virtually all important social interactions are captured on-chain. Users' profiles and followers are represented by NFTs. Mirroring and collecting (respectively analogous to retweeting and bookmarking) are also on-chain actions that create NFTs. Content itself is stored off-chain to save gas costs and only becomes NFTs when collected. The platform is designed for modularity, allowing developers to create new features through modules.

Similar to Farcaster, Lens aims to be a neutral base layer and encourages competition in the app/client layer. 

Lens previously raised external capital from FTX Ventures last year.

Pros:

• Lens offers unique and innovative features powered by crypto. For instance, the Collect module allows creators to monetize their posts directly with followers. Artists can create "rare collects," enabling followers to collect their artwork for a limited time.  Followers can also mirror these posts and receive referral fees. Because all these actions happen on the blockchain, balances are immediately debited and credited with no intermediaries.

• Unlike Farcaster, Lens can “free-ride” on other nodes already validating the Polygon blockchain. Therefore, Lens is as decentralized and permissionless as the Polygon network itself.

• Modular architecture allows others to create new social primitives.

Challenges:

• Because many user actions are read/write operations on Polygon smart contracts, latency and throughput can be issues, particularly when the blockchain is experiencing high usage or network instability. 

• Unclear GTM: current users seem to be a mix of crypto-natives, creators, developers, and frankly, airdrop farmers. Accordingly, the overlap of shared interests can be small, which may reduce user engagement. This is supported by a relatively low DAU/MAU ratio.

• Spam, primarily from sybil and airdrop farming, makes it difficult to parse signals from noise. 

• Anecdotally, posts are less likely to gain traction unless one of the Lens team members mirrors/re-shares them.

Other points:

• Using third-party protocol XMTP to build a secure, encrypted channel for direct messages and Lit Protocol to create gated publications

Resources:

• Two popular clients: Lenster and Phaver

• Lens Protocol documentation

• List of apps built on Lens

Our Take

Lens is one of the most innovative and exciting DeSoc protocols. It offers features and tools not seen in Web2 or other Web3 platforms, showcasing what crypto-enabled social networks can unlock for creators and fans. Ideally, these features kickstart a strong flywheel where creators start using Lens for more direct relationships with their fans, attracting users to the platform, attracting more creators, and so on. We also like Lens’ modular architecture that creates a wide design space for new social primitives.

Admittedly, the platform still has room for improvement. Popular apps built on Lens lack refined UX, and we have some concerns about Lens' scalability given its current architecture. But these all can be solved in time. We look forward to seeing what third-party developers build on top of Lens.

CyberConnect - Scalable and Context-Rich Social Graph

On the surface, CyberConnect appears quite similar to Lens Protocol. Both are decentralized social networks that leverage smart contracts on generalized blockchains. Like Lens, CyberConnect issues NFTs for profiles, followers, and content. Creators can monetize through NFTs or token-gate parts of their community. And similarly, both are built with a modular architecture, enabling developers to develop and re-use modules as they see fit.

But whereas Lens smart contracts only live on Polygon, CyberConnect uses a combination of blockchains and distributed networks, including Ethereum, Polygon, BNB Chain, IPFS, and Arweave. CyberConnect also caches and batches user actions before uploading them to decentralized storage like Arweave to improve scalability while maintaining data integrity and censorship resistance.

CyberConnect distinguishes itself through its initial and diverse use cases and social graph curation. The first use case of other protocols like Farcaster and Lens is often “decentralized Twitter.” Instead, CyberConnect offers a variety of other products and features:

• ccProfile: an on-chain identity standard for individuals/collectives incorporating on-chain actions.

• Link3: Akin to Linktree and Eventbrite, Link3 helps Web3 users find other profiles and discover/attend events, leveraging ccProfiles and CyberConnect’s social graph.

• W3ST (Web3 Status Token): a more generalized proof-of-attendance concept covering endorsements, roles, credentials, and participation.

• FanClub: a loyalty and community game that recognizes and rewards user contributions to companies and DAOs, similar to Galxe and Crew3.

• Posts: Publication tool similar to Mirror.xyz (decentralized Substack), storing content permanently on-chain and allowing fans to collect posts.

CyberConnect also has a thriving ecosystem of dApps building on top of the protocol, covering diverse use cases that go beyond Twitter features. Its recent hackathon, #Connected2023, particularly bolstered its ecosystem.

CyberConnect raised a $15 million Series A in May 2022, which was co-led by Animoca Brands and Sky9 Capital [Disclaimer: Amber Group also participated in CyberConnect’s Series A.].

Pros:

• Seamless user experience with minimal private key signing required.

• Multichain support and proprietary data indexer enhances scalability, flexibility, and social graph connections. According to our conversation with other developers, this also improves the developer experience.

• Arguably richer social graph incorporating individuals, collectives, events, and various on-chain interactions.

• Wide range of products familiar to Web2 users: Link3 <> LinkTree, Posts <> Substack, Events <> Eventbrite, Phaver <> Twitter, Huddle01 <> Zoom, and more.

• Modular architecture allows others to create new social primitives.

Challenges:

• CyberConnect uses a centralized relayer to improve scalability. This could be decentralized down the line, although no plans have been announced yet.

• Some of Cyberconnect’s first features (events, status tokens, FanClub) are lower engagement products.

• Similar to Lens, difficult to parse signals from noise due to spam activities driven mostly by sybils and airdrop farming.

Other points:

• The average CyberConnect social graph is qualitatively different from that of Farcaster’s or Lens’ due to initial GTM of Events and FanClubs, and other use cases beyond Twitter.

• By tapping into more use cases and not necessarily focusing only on the crypto-native communities, CyberConnect is also positioned to onboard more mass users to Web3.

• Strong B2B onboarding with numerous Web3 organizations boasting Link3 profiles.

• Generated 278E and 401BNB (~$603k) since this February from profile minting fees.

Resources:

• CyerConnect home page and ecosystem apps 

• Link3, Posts, Event, and FanClub

• CyberConnect documentation

• Winning and highlighted projects from #Connected2023 hackathon

Our Take

CyberConnect stands out both in building out a drastically different social graph and in offering a wide range of applications commonly seen in Web2. Its initial GTM on curating crypto-native and crypto-adjacent communities has helped bolster immediate adoption. It could conceivably be a one-stop-shop for decentralized social media and content for the crypto industry, replacing Linktree, Medium, Eventbrite, and other Web2 tools that crypto users/companies use today.

But the efficacy of all the experimentations in different use cases is still to be seen. Likely, if decentralized social platforms are to gain strong adoption and high engagement, there needs to be a killer feature driving growth. 

Nonetheless, CyberConnect's team continues to deliver sleek and innovative products. We look forward to what the team and other developers will build on top of the protocol.

Conclusion

Decentralized social protocols and platforms face an uphill battle in their quest for mainstream adoption. Odds are stacked against founders. Behind every successful new social media app is thousands of other similar failed attempts. 

Yet we remain hopeful. Decentralized social networks have the unique opportunity to introduce completely new social primitives and return the value of the social graph back to users. 

Social media is on the brink of change. While we are still in early innings, the possibilities for reshaping how we connect, share, and engage with one another online are truly limitless, opening doors to a brighter, more inclusive, and empowering digital landscape.

Acknowledgments

Thank you to the following teams for their contribution to research on decentralized social networks: Mastodon, W3C, Lens Protocol, Farcaster, Nostr, CyberConnect, Bluesky.

Thank you to Yilan Huang and Abhi Raheja from CyberConnect and Jayme Hoffman from Allthing.xyz / Launchcaster.

Author

Steven Shi is an Investment Partner for Amber Group's Eco Fund, the company's early-stage crypto venture fund. He has over five years of experience in hedge funds, private equity, and investment banking firms. 

Disclaimer

The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.

Ethereum will complete the final stage of its transition to proof of stake in a month. After the upcoming “Shapella” upgrade (a portmanteau of “Shanghai” and “Capella”), over 16 million ETH of staked Ether can be withdrawn from the Beacon Chain. This headline figure alone has created confusion and some angst among users, investors, and traders about the possible impacts Shapella has on demand/supply flows for ETH and related tokens. 

In this report, we clarify the details of the Shapella upgrade, what to look out for going into the upgrade, and provide our best estimate of how the upgrade may impact ETH, liquid staking derivatives, and other applications.

Quick Takes

• The Shapella upgrade will allow staked ETH on the Beacon Chain to be partially or fully withdrawn. It is expected to occur from late March to early April.

• There are over 1 million accrued ETH rewards on the Beacon Chain. These rewards will be automatically withdrawn, taking around five to seven days for all accrued rewards to become liquid. We estimate around half of these rewards will be re-staked back on the Beacon Chain primarily due to competitive dynamics among staking pool providers.

• There are over 16 million staked ETH principal on the Beacon Chain. We expect around ~2.8 million ETH to be withdrawn but note that this is a conservative estimate and that the range of outcomes is high. We expect ~50% of the withdrawn ETH to rotate back onto the Beacon Chain via liquid staking providers. Key beneficiaries include Lido Finance, Frax Finance, and Coinbase. 

• Long-term, because staking ETH will be de-risked, Ethereum staking participation should rise above 40% and act as the de facto benchmark rate across the Ethereum ecosystem.

• Shapella will also have follow-on impacts on DeFi applications including: liquid staking providers, decentralized exchanges, borrow/lending protocols, meta-governance projects, and re-staking infrastructure. Shapella could also have an impact on the supply elasticity of Ether, affecting its volatility as a trading instrument.

The Basics of Shanghai/Capella 

The Beacon Chain is the backbone of Ethereum’s proof-of-stake consensus, allowing users to stake their Ether to participate in block validation and earn rewards. The chain began accepting deposits in November 2020 and officially launched on December 1, 2020. Users needed to stake a minimum of 32 ETH to earn issuance rewards for performing consensus duties. Prior to the Merge, consensus duties simply consisted of reaching consensus on active validators and their balances. After the Merge (Bellatrix upgrade), validators became responsible for activities that secure the network, such as block proposal, block attestation, and sync committee participation. 

But staked ETH and rewards have been locked up on the Beacon Chain since its inception. So over 16M of staked ETH and 1M of accrued rewards have been stuck on the Beacon Chain for over two years. 

Next month, Ethereum is slated to complete an upgrade called Shanghai / Capella. [Upgrades to the consensus layer are named after stairs (Altair, Bellatrix, Capella). Upgrades to the execution layer are named after cities.] 

The most salient feature in the upcoming Shanghai/Capella upgrade is the ability for validators to opt to withdraw either their accrued rewards or the entirety of the validators’ balance. Consequently, Ether would move from the Beacon Chain to the Execution Layer, where it is freely liquid and can be used for transactions.

Note that rewards from priority fees and MEV payouts are accrued directly to the Execution Layer (i.e. the chain that Ethereum users transact on today). These rewards are immediately liquid. So the only rewards that are locked up until Shapella are issuance rewards on the Consensus Layer.

All indications suggest that the Shapella upgrade will happen around late March to early April. Testing so far is positive. Developers successfully launched Shapella on the Sepolia testnet on February 28 with only minor issues. They have also completed testing on the Zhejiang public test network and a shadow fork on mainnet. 

Sepolia Testnet Successfully Upgraded to Shapella

The next milestone is launching the Shapella upgrade on Goerli around the middle of March before the upgrade hits mainnet.

Withdrawals, Explained

After the Shapella upgrade there will be two types of withdrawals:

1. Full withdrawals. This allows validators to completely exit the Beacon Chain, taking with them their full ETH balance, including their original 32 ETH balance and any accrued rewards or penalties. 

Ethereum imposes a churn limit of how many validators can withdraw each epoch (1 epoch consists of 32 blocks and occurs every 6.4 minutes). This limit increases with more validators on the Beacon Chain. Currently, the churn limit is seven. But this will likely settle at 8 validators per epoch by the time of the upgrade. So when the upgrade occurs, 1,800 validators can fully exit every day, which is over 57,600 of ETH/day.

2. Partial withdrawals: Also known as skimming, partial withdrawals allow validators to sweep their balance in excess of the 32 ETH principal. It allows validators to remain active on the Beacon Chain while withdrawing the accrued income that they have earned. Because accrued rewards are idled capital (i.e., rewards do not auto-compound), skimming improves capital efficiency. Without partial withdrawals, validators would have to completely exit the Beacon Chain to collect their rewards, then re-enter once again. Thus, separating partial withdrawals from full withdrawals improves network stability and prevents queue clogging. 

Partial withdrawals will happen automatically after the upgrade and average one sweep per week. 16 partial withdrawals will automatically occur every slot, starting from index 0 of the Beacon Chain, which is ~147k validators every day.

Should I Stake or Should I Go?

A potentially large supply shock looms over the upgrade. Over 1 million ETH will be automatically liquid from sweeping of partial withdrawals in the week following the upgrade. That’s ~0.8% of total ETH supply and ~$1.6 billion at today’s price.  In addition, theoretically, 16.8 million ETH will be eligible to be withdrawn as well.

The headline figures have caused some FUD. There is a narrative brewing that the market will potentially see large sell flows from enabling withdrawals for ETH that have been illiquid for over two years.

But these concerns may be overblown. Below, we walk through the dynamics of both partial and full withdrawals to better illustrate how withdrawals will work after Shapella and suggest that the supply shock may not be as extreme as headline figures imply. 

Please note that our estimates are rough figures and subject to a wide range of uncertainty. Our analysis involves numerous assumptions. Point figure estimates are almost certainly going to be wrong. Nonetheless, we hope that this report provides context behind our thinking and encourages further discussion and analysis.

Partial Withdrawals - Re-Staking Dynamics Lessen Supply Shock

In total, there are over one million of accumulated ETH rewards that will automatically become liquid. Because there’s a partial withdrawal queue of 16 validators per block, and a portion of validators have to first change their withdrawal credentials before receiving these accrued rewards, it would take five to seven days for all partial withdrawals to become liquid on the Execution Layer. 

But even assuming most validators are conservative and want to hold liquid ETH on the Execution Layer, there are structural dynamics that compel them to re-stake these rewards back onto the Beacon Chain.

53% of accumulated rewards are from staking pools that offer liquid staking tokens (“LSTs”). The major LSTs are provided by relatively decentralized staking providers, such as Lido and Rocket Pool, or centralized custodians, such as Coinbase and Binance. The fair market price of LSTs vary, from a premium of +1.3% for Rocket Pool’s rETH, to a discount of -3.0% for Ankr’s ankrETH. Most LSTs are priced at a discount of -0.1% to -2.0%, with a greater discount typically given to centralized custodians.

Landscape of ETH Liquid Staking Tokens

We believe the existence of LSTs mitigates the potential supply/sell flow from withdrawals because users who stake through these providers already have the option to convert their staked ETH at a nominal discount.

Furthermore, competitive dynamics incentivize re-staking. Lido, who has the leading market share amongst all staking pools, recently affirmed its policy of “APR maximization” by attempting to re-stake as much ETH as possible. With its stETH token trading at only a -0.1% discount, we estimate there will be minimal demand for stETH redemptions. So Lido will likely re-stake virtually all its accumulated rewards of 224k ETH (~$370M), representing over 20% of total accrued rewards. Other staking providers will be compelled to stake as much ETH as possible too, lest they offer uncompetitive APRs vs. Lido and consequently lose market share.

We share our base case assumptions for the percentage of partial rewards that will get re-staked in the tables below. For staking pools with LSTs, we assume that those with a higher LST discount will see more significant redemption pressure to bring the token back to par. 

Our assumptions are admittedly less rigorous for centralized operators with no LSTs and vary based on our understanding of their situation. Kraken, for instance, is unlikely to re-stake given recent SEC charges and its agreement to shut down staking services to US customers. Celsius too would probably prefer liquid ETH. 

Nonetheless, our conversations with institutional node operators like RockX suggest that most are expecting to re-stake the bulk of their rewards to maximize yield. Therefore, we expect that institutional-focused node operators, like RockX and Figment, re-stake most of their rewards. For node operators that have more retail users, such as Stakefish and most centralized exchanges, we assume only 20% of partial rewards are re-staked, with the rest used to meet redemption requests.

Validator Distribution by Entity

Assumptions for Partial Withdrawals

Hence, our baseline assumption is that ~52% of total supply from partial withdrawals will be re-staked back to the Beacon Chain, dramatically shrinking the potential supply shock and sell flow. 

For more in-depth modeling on partial withdrawals, we recommend this post from Data Always. The author concludes that “the decision to make partial withdrawals automatic likely decreased the initial surge of selling by clogging the queue with validators who do not intend to sell.”

Full Withdrawals - ETH Rotation to LSTs as Base Case Assumption

We forecast full withdrawals from the top 20 distribution of validator entities, consisting ~75% of total validators, and make a generalized assumption for the other 25%:

• Pool operators with LSTs will not fully withdraw any of their validators. Recall from above that over half of validators offer LSTs - and we think all will be able to pull their LST to par with ETH from partial withdrawals alone. In fact, most will likely deploy net new validators due to re-staking their ETH rewards.

• Kraken will withdraw the majority of its staked ETH as it is not allowed to offer staking services to US customers anymore. Although it can offer staking in other capacities, its US-centric customer base and regulatory uncertainty will likely cause outflows from Kraken’s staking product. Similarly, we expect Celsius will fully withdraw all their validators to maximize short-term liquidity. 

• For other CEX’s and node operators, we vary assumptions between 10-25% based on our understanding of their target customers (institutional vs. retail) and operating model (pooled vs. solo, custodial vs. non-custodial). We assume that institutional clients will have lower withdrawal needs compared to retail, based on our conversations with various staking participants. Those that operate a pooled/custodial model would also see lower pressure for full withdrawals, as they can net outflows with inflows. 

In sum, we estimate ~2.8M ETH being fully withdrawn from active validators post-Shapella. 

However, like with partial withdrawals, we expect re-staking. Specifically, we expect many stakers who withdraw to rotate their ETH back to liquid staking providers. This is because providers with LSTs offer several advantages to solo staking, including:

• Potential for immediate liquidity through on-chain pools

• Usage of LST as collateral across DeFi, allowing users to borrow stablecoins, leverage stake ETH, and more

• Convenient accessibility to re-staking primitives such as Eigenlayer

Assumptions for Full Withdrawals

The impact of users re-staking ETH likely reduces total supply shock from full withdrawals by ~50%.

A range of on-chain indicators support our forecast for modest withdrawal pressure:

• 14-day moving average of new validators continues to tick up after the lows post-Terra / 3AC collapse.

• LST tokens of major staking pools trade at a negligible discount, with non-custodial liquid staking providers having the smallest discount (or, in Rocket Pool’s case, even a premium). This supports our view that staked ETH will shift from custodial to non-custodial liquid staking.

• ~39% of stakers are profitable in USD since they began staking. A larger percentage of stakers in profit would suggest higher withdrawal pressure.

  

• Low level of voluntary exits by validators in anticipation of the upcoming upgrade. If validators expect a clogged exit queue post-upgrade, some may attempt to front-run the queue by exiting earlier. However, it may still be early, and this is a key indicator to continue to monitor.

Summing It Up

~39k ETH will also become liquid from the 1,136 validators who have exited from the Beacon Chain.

In total, our base case forecast is ~1.8M of ETH that becomes liquid from withdrawals, after adjusting for re-staked ETH. This reflects 1.5% of total ETH supply and 10.5% of total ETH on the Beacon Chain. We believe this projection to be conservative; there is a good chance that the actual figure will be lower than this amount.

We don’t expect all this ETH will be sold. Data indicates that Ethereum's total supply increasingly stays on-chain instead of being sent to centralized exchanges. We think this trend will persist and expect a considerable amount of ETH unlocked from Shapella will remain on-chain.

Modeling the potential sell flow post-Shapella is out of scope of this report - we leave that up to interested readers to build their own model. However note that, due to the Beacon Chain’s exit queue, any potential sell-flow from full withdrawals will likely be prolonged over weeks instead of occurring over a few days. 

The Other Side of the Equation

With the uncertainty overhang of withdrawals finally removed, we foresee an influx of net new demand for staked ETH. Staking ETH will gradually be seen as the de facto benchmark rate within the Ethereum ecosystem, comparable to the Fed Funds rate in the US economy. All-in staking yields should at least match those seen on blue-chip DeFi protocols, such as Aave, Compound, and Euler.

Longer-term, we see 40%+ of ETH will be staked. At 40% staking participation, assuming MEV and priority fees remain at the 30-day trailing average, the all-in APR for validators is ~2.95%.

Impact on Liquid Staking Providers

Shapella benefits liquid staking providers in multiple ways. As mentioned above, LSTs are arguably better collateral compared to ETH. For example, it is capital inefficient to borrow stablecoins against ETH if the same can be done against stETH. And because withdrawals strengthen LSTs’ peg to ETH, their attractiveness as collateral improves. Hence, we expect liquid staking providers to gain market share.

Relatedly, these projects will see lower expenses in maintaining the peg between their LST and ETH. Instant on-chain liquidity for LSTs matters less after Shapella. For instance, consider a scenario where Lido halves its emissions to incentivize liquidity on decentralized exchanges like Curve. Even if the Total Value Locked drastically shrinks, stETH would still hold a tight peg to ETH. This is because if stETH ever trades meaningfully below peg, third-party arbitrageurs would begin to step in. Withdrawals only take ~4-5 days to fulfill in most cases, so we think arbitrageurs would step in even after a 10-30 bps deviation from peg. (At 30 bps, arbitrageurs stand to gain 25% APY from performing the arb). Therefore, DeFi projects like Aave and Compound can still confidently use stETH as a collateral asset, knowing that liquidators and arbitrageurs stand ready to buy any de-pegs.

The upshot is that liquid staking pools will likely see both increased revenues from greater adoption of LSTs along with reduced expenses from token emissions.

A counterargument is that these LST protocols will still need to incentivize liquidity to be well-integrated across DeFi and allow for things like instant liquidations for borrow/lending protocols. But precedents like Euler’s integration of cbETH as collateral suggest that teams understand that instant on-chain liquidity does not fully reflect a token’s collateral quality. 

We believe the key beneficiaries will be Lido Finance. Because stETH is widely adopted across different DeFi applications, it offers the greatest utility among LSTs. And Lido’s managed validator set allows it to accommodate a large influx of staking demand (it recently registered over 150k ETH of inflow in one day). Frax Finance and Coinbase should also benefit for similar reasons, although their LST is less widely adopted. Coinbase also offers a higher take rate at 25%.

Rocket Pool likely benefits to a lesser extent. We are fans of its decentralized design and ethos, but it faces scalability challenges due to ETH/RPL collateral requirements. Its higher take rate, designed to draw in node operators, is also a headwind for growth. That said, watch out for its Atlas upgrade as a significant catalyst. Atlas allows node operators to halve their collateral requirement from 16 ETH to 8 ETH, which has the effect of tripling each operator’s capacity - 16 ETH staked in one validator can now be spread across two validators, so capacity for other users increase from 16 ETH to 48 ETH.

Exploring Second-Order Effects

Shapella not only impacts ETH and staking providers. It also creates follow-on impacts on a wide range of verticals, such as:

ETH-backed stablecoins. Two notable ETH-backed stablecoins, Liquity (LUSD) and Reflexer (RAI), face headwinds post-Shapella. As staked ETH de-risks, users may feel more comfortable using liquid-staked ETH as collateral instead of ETH itself. And because Liquity and Reflexer are specifically set up to be minimally governed, they cannot switch their collateral base to liquid-staked ETH. Perhaps that’s a good thing. LSTs still have risks. But these stablecoins already have minimal circulating supply (LUSD: $230M, RAI: $7M), and it is probable that they see lower market share post-Shapella.

Curve/Convex and other DEX’s. Lido has spent nearly 86M of its own governance token (~$230M at today’s price) to incentivize liquidity across decentralized exchanges, mostly to Curve Finance. This is primarily to make stETH a more attractive asset by creating deeper liquidity and allowing low slippage in trading between the two assets. LDO emissions usually make up at least half of the APR from providing liquidity to the stETH/ETH pair. If Lido reduces these rewards, we would see lower stETH/ETH TVL on Curve and other DEX’s, perhaps causing a re-rating in their valuation. For context, the stETH/ETH pair on Curve makes up ~32% of total TVL.

Meta-governance projects like Convex and Aura, which aggregate voting power and receive rewards from projects like Lido, would also see lower rewards under this scenario. 

On the other hand, Shapella may also catalyze a wave of new liquid staking tokens. Frax Finance only launched its LST a few months ago and used its control of CVX/CRV to whip up market share. Yearn Finance’s upcoming basket of LSTs will follow a similar playbook to bootstrap liquidity. We may see a burgeoning LST war after the Shapella upgrade.

Leverage staking. Because the peg between an LST and ETH is easier to maintain, users will likely feel more confident to leverage stake ETH through on-chain borrow/lending protocols. Primitives like Aave v3’s e-Mode, which allow users to borrow ETH against staked ETH at a 90% LTV, and Gearbox, which allow up to 10x leverage on stETH, create interesting playgrounds for users to experiment (& get rekt) with leveraged staking. So even if no net new users look to stake ETH, existing users will likely push the limits and drive new ETH on the Beacon Chain. 

Re-staking as a primitive. Although EigenLayer’s whitepaper only came out this month, its idea of re-hypothecating staked ETH as a primitive to bootstrap new networks has created excitement through the Ethereum community. The idea is not necessarily new. Both Avalanche and Cosmos have variants of the same concept. But it would further reinforce staked ETH as a desired collateral. Furthermore, if staked participation does indeed reach 40%+, base yields would compress to 3% or lower. In such a scenario, a platform that provides options for greater yield on the same asset would be highly desirable.

Ether’s supply elasticity. Supply elasticity impacts Ether as an asset class to investors and traders. Lower elasticity typically heightens volatility. An open question is whether Ether becomes more or less supply elastic after Shapella. On the one hand, allowing over 16M of ETH to become liquid drastically increases supply elasticity. On the other, this risk is mitigated by the exit queue and Ethereum’s relatively low staking participation. Higher rates of staked ETH could increase short-term elasticity, potentially increasing the asset class’ volatility.

Conclusion

We don’t buy the FUD. Although anything can happen in the short term, the Shapella upgrade is a fundamentally positive event. Amongst other things, it catalyzes higher staking participation, bolsters staked ETH as a desirable asset, improves Ethereum’s security, and de-risks Ether as an asset.

When call we call Ethereum done, if we have to call it done? End of 2023. Merge done. Withdrawals done. Being able to withdraw from the proof of stake system. Basic scaling done. A lot of basic improvements done. Enough cryptography added to Ethereum so that we can support privacy solutions as a layer on top. If we need to, we can stop there. - Vitalik Buterin on the Network State Podcast (emphasis added)

Above all, Shapella will finally put Ethereum’s transition to proof of stake at a close. Developers will finally be able to fully focus on other pressing agendas on Ethereum’s roadmap. After Shapella, look out for EIP-4844, which sets the path for scaling Ethereum by reducing the cost of Layer 2 rollups via danksharding.

Resources

• ETH Withdrawal FAQ

• Beaconcha.in - Beacon Chain explorer and statistics

• Beaconscan - Etherscan’s Beacon Chain block explorer

• Rated Network - Ratings and metrics on Ethereum validators

• Lido on Ethereum Valiator & Node Metrics

• Staking Calculator - BeaconChain

• Simplestakers.info

• Lido Dashboard Catalog (Dune)

• Hildobby’s Ethereum Staking Dashboard (Dune)

Appendix: Lido Finance’s Withdrawal Design

Lido’s design for managing withdrawals from the Beacon Chain clarifies the overall structure for most LSTs. stETH holders go through a three-step process to withdraw:

1. Request: To withdraw stETH, users can send a withdrawal request to Lido, locking the amount of stETH to be withdrawn.

2. Fulfillment: Afterwards, users enter a queue and the Lido protocol handles requests on a first-in-first-out basis. If there is ETH in a buffer from new deposits or partial skimming, it can be used to fulfill withdrawals. If there is not enough ETH in the buffer, Lido would request the necessary number of validators to exit. Note that this queue is within the Lido protocol and separate from Ethereum’s withdrawal queue.

3. Claim: Users claim their share of ETH.

An interesting design choice is that withdrawal requests cannot be canceled but are transferable. It would be possible for a secondary market to form where users in the front of the Lido withdrawal queue can sell their position to those that require liquidity more urgently.

Lido will operate in two modes for withdrawals. In normal times, Lido’s withdrawal will be in turbo mode. Users can typically convert stETH to ETH in ~3-4 days, although this could shrink to just 1-24 hours if there is enough ETH left in a buffer.

However, in the case of mass slashing, Lido will enter bunker mode. This would occur when over 600 Lido validators simultaneously get slashed. No Lido validator has ever been slashed so far. In this mode, all withdrawals will be delayed until losses are socialized between all users. This is to prevent sophisticated users from gaining an advantage over other users, as slashing and penalties occur asynchronously. Without bunker mode, sophisticated actors could predict a mass slashing, withdraw from stETH to ETH to avoid the losses incurred, then re-enter into stETH afterwards. 

Lido’s architecture prioritizes stakers by stating the principle of APR maximization. Instead of leaving more ETH in the buffer to facilitate speedier withdrawals, Lido will instead ensure that ETH spends as little time as possible in the buffer. 

This dynamic “sinks” ETH supply from Shapella back onto the Beacon Chain. It also compels competitors to do the same, lest they offer lower APRs and give up market share. 

Author

Steven Shi is an Investment Partner for Amber Group's Eco Fund, the company's early-stage crypto venture fund. He has over five years of experience in hedge funds, private equity, and investment banking firms. 

Disclaimer

The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.

Introduction

About a decade ago, the world saw a rise in the growth of mobile smartphones. At the time, some large companies thought they could revolutionize smartphones by introducing modular architectures. In 2013, Google announced Project Ara, a new smartphone with a modular design. Unlike today's “monolithic” phones, made of sealed-off pieces of aluminum and glass, Ara would allow users to customize their phones in numerous ways, enabling all of the essential parts to be modular. You wouldn’t be forced to upgrade to a new phone as frequently. Instead, you could simply add the best new parts to your older phone, according to your own preferences. Sadly, modularity did not succeed in the mobile phone ecosystem, and the concept remains a mostly forgotten piece of tech history.

The modular smartphone may serve as a cautionary tale for modular blockchains, as the hype of new and exciting solutions does not guarantee a long-term win, despite current tools' legitimate drawbacks. However, in the case of blockchains, users’ demand for scalability is already pushing developers to build out and adopt modular architectures. This demand makes it unlikely that modular blockchain architectures will share the same fate as that of the modular smartphone.

But what exactly is a modular blockchain architecture? How can we ensure these solutions won’t end up as another Project Ara?  This article hopes to answer all of these questions.

Monolithic and Modular

Before delving further, let’s clarify the difference between monolithic and modular architectures. The simplest way to introduce this concept would be with an example of a familiar concept. Just as mobile phones have certain core components, such as a camera, a battery, and a touchscreen, a blockchain also has core components.

An iPhone is a great example of a “monolithic” phone. It comes with all of the parts needed to use the phone and doesn’t offer much in the way of customization options. Sure, you may not be able to edit the internals much, but it is sleek and fast. However, there may be a time when you wish to customize your phone further. Suppose as the years go by, new phones come out with far better cameras. The rest of your out-of-date phone may work fine, but with your existing camera, you cannot match the experience of the newer phones.

With a modular architecture, you would not have to buy a brand-new phone. Instead, you could swap out your camera like a lego piece and pop in a better one.

Google’s Project Ara is an example of a modular phone. The phone is made of building blocks that can be swapped in and out parts to your choosing. As long as compatible parts are made, Ara will support them.

Like smartphones, blockchains are comprised of multiple essential components; these components are laid out below:

• Consensus

  • The consensus layer of blockchains provides ordering and finality through a network of computers reaching consensus on the state of the chain.

• Execution

  • This layer handles the actual processing of transactions by running their specified code. It is also where users typically interact with the blockchain, such as by signing transactions, deploying smart contracts, and transferring assets.

• Settlement

  • The settlement layer serves as the platform for verifying activity executed on layer 2s, such as rollups, as well dispute resolution. Most importantly, it is where the final state of the actual blockchain is recorded.

• Data Availability

  • The data required to verify that a state transition is valid should be published and stored on this layer. This should be easily retrievable and verifiable in the event of attacks or operational failures where block producers fail to provide transaction data.

Simply put, a monolithic blockchain performs all of these tasks on its own, in a single piece of software, while a modular blockchain separates them into multiple pieces of software. At this point, you may wonder what are the disadvantages of a blockchain which handles all these tasks at once?

This falls back to the age-old problem, the scalability trilemma.

The scalability trilemma says that a blockchain can only have two of the three following characteristics: decentralization, security, and scalability. Existing monolithic blockchains tend to optimize for the secure and scalable corners of the triangle. Bitcoin and Ethereum put more emphasis on being as decentralized and secure as possible. Unfortunately, this comes at a price. The decentralized chains usually do not have high bandwidth for executing transactions. Ethereum caps out around 20 transactions per second, and Bitcoin falls even lower on the scale. 20 transactions per second is woefully inadequate if we want to use these protocols at a global scale. Some monolithic chains could, at least theoretically, get us much closer to global scale, as their TPS and overall throughput are sufficient. However, they often lack decentralization, the core principle of blockchain technology.

A modular architecture aims to outsource some of the work of a blockchain to make more performant chains while maintaining decentralization. Let’s walk through Ethereum and discuss how it is expected to leverage modularity.

An Ethereum-Centric Ecosystem

Examples: Most Layer 1s, Fuel

Ethereum, as it exists today, is a monolithic blockchain. Most other layer 1 blockchains today would also be classified as monolithic blockchains and structured as such. Like the iPhone example, certain capabilities of monolithic blockchains sometimes begin to fall behind those of newer alternatives, leading to the loss of both developers and consumers as they look for the newest and most innovative layer 1. To address Ethereum’s current bottlenecks in throughput, developers are building rollup execution layers to increase transaction bandwidth.

Examples: Optimism, Arbitrum, Fuel, Scroll, ZkSync

Rollups as an execution layer are the most widely used scaling method on Ethereum today. Rollups are separate blockchains with more performant transaction execution and whose net results settle on Ethereum to effectively inherit its (far better) security and decentralization.

At a high level, a rollup is just a blockchain that posts the net result of its blocks to another blockchain. However, this is only one component of being a rollup, as you also need fraud & validity proofs and a method of permissionless insertion of transactions. Rollups accomplish this by syncing the data between two smart contracts, one deployed on layer 1 and one deployed on layer 2. This design is what makes it a rollup and not a sidechain. These key components are necessary for a rollup to be secure, as the rollup can be halted or censored without them. 

Currently, most rollups offer EVM compatibility to help Ethereum developers migrate easily, but in terms of computation efficiency and ease of development, there may be better alternatives for execution layers. Users may even want more quality-of-life features that aren’t present on EVM equivalent chains, such as account abstraction. Given the wide range of developer preferences, it’s likely this trend will continue, and we will see even more novel solutions populate the market, such as SolanaVM and MoveVM execution layers. Fuel is an example of an execution layer that is not EVM compatible and whose sole focus is to perform computations not possible on other rollups. Fuel is also the first “modular execution layer,” which, as we will see, allows it to be a sovereign rollup, a settlement chain, or even a monolithic blockchain. Whereas rollups are only execution layers, Fuel can be more.

Fuel can be modularized in ways normal rollups cannot. Hence the name “modular execution layer.” We will dive into the mechanics of the Celestia architecture soon. (Source: Fuel)

Fuel has shown that execution layers can be creative and prioritize computational speed over EVM support. While many familiar with modular architectures know of Fuel, another great contender is lesser known. One of the most interesting upcoming modular execution layers is called Kindelia. Outside being one of the fastest computation layers, Kindelia has a unique proof system utilizing its virtual machine. Kindelia’s HVM offers a near-instantaneous proof checker built into their smart contract language called Kind. Kind is essential because smart contracts can prove within their code that their code is safe from exploits and operates correctly. This type of design could solve the issue of improperly coded smart contracts and save us from the exploits plaguing smart contracts today. This is just one way Kindelia provides value over other execution layers.

But scaling in terms of an execution layer is just one piece of the puzzle. Developers seek to further modularize monolithic blockchains to squeeze out every possible ounce of performance. This brings us to how the data availability layer can be modularized.

Examples: Metis, ZkPorter, Anytrust

A Validium is a rollup whose data is moved off-chain instead of storing it on-chain.

But why are we moving data off-chain? This is because we are trying to optimize for data availability. The overall efficiency of a rollup system is heavily dependent on the capabilities of its data availability layer. When this layer fails to handle the volume of data generated by the rollup's transaction sequencer, it leads to a bottleneck in processing transactions. As a result, the rollup cannot handle additional transactions, leading to increased gas fees and/or slow execution times. In other words, the performance of the rollup's data availability layer is a critical factor in determining its overall transaction processing capabilities and the fees associated with them.

The drawback of validiums is that they are off-chain, introducing more trust assumptions. We want an on-chain solution to improve the data availability layer of Ethereum. The answer is Danksharding.

The integration of Danksharding into Ethereum transforms it into a streamlined platform for both settlement and data accessibility.

What makes Danksharding innovative is its ability to merge these concepts into a cohesive unit. The rollup proofs and data are verified within the same block, creating a seamless and efficient system. However, as part of their normal operation, rollups require significant storage for their compressed data. Danksharding provides a solution to this requirement, offering the potential for millions of TPS across multiple rollups. Danksharding is a technique that splits network activity into shards to increase space for data blobs. A data blob is a more efficient and standardized data format in Ethereum that can carry a large amount of data and is used by rollups to reduce gas fees. Danksharding utilizes “data availability sampling” to enable nodes to verify significant data amounts by examining only a small portion, paving the way towards a future where cheaper and faster layer 2 networks can thrive while enabling direct transactions on Ethereum.

Danksharding is also great as it would inherit all of the security and decentralization of Ethereum itself. However, this comes with a downside. Due to the relatively slow pace of Ethereum development, we are probably years from Danksharding being properly implemented into Ethereum. EIP-4844 plans to introduce Proto-Danksharding, which is the first step to achieving Danksharding. EIP-4844 enhances Ethereum by introducing a new transaction that accommodates data blobs. This specialized storage for rollup data paves the way for a more cost-effective fee market.

What if you want a fast data availability layer but don’t want to sit around waiting for Danksharding to be released? Celestia is a protocol that offers just that. Shifting from an Ethereum-centric view on modularity, it is worth diving into Celestia to see how else modular blockchains can be interpreted.

A Celestia-Centric Ecosystem

Celestium is a unique solution that combines the data availability of Celestia with the settlement and consensus of Ethereum. Danksharding remains the most secure method due to its integration into Ethereum, decentralization, and robustness. However, some rollups prefer to seek scalability right now rather than waiting for Danksharding to be implemented into Ethereum.

For the projects who can’t wait for Danksharding, one possible choice is to utilize off-chain data availability solutions, such as Validiums, which utilize a "Data Availability Committee" (DAC) to attest to the data being available. However, this method is not as decentralized or secure, as it relies on a multi-sig, and there is no way to verify if the DAC is currently honest or if they have been honest in the past.

Celestium offers a more secure alternative to DACs. With Celestium, the attestation that data is available is backed by the stake of the entire Celestia validator set, meaning if ⅔ of validators provide incorrect information, they can be slashed and potentially lose a large sum of money. This provides a harsh and immediate response, unlike in a DAC where no penalty exists.

Additionally, users can verify the honesty of Celestia by running Data Availability Sampling on the blocks and checking the Quantum Gravity Bridge, which is the trustless 1-way messaging bridge from Celestia to Ethereum. Bridges are typically the most vulnerable part of any solution, so redundancies must be built.

Celestium, along with Danksharding, utilizes data availability sampling (DAS) to verify the non-malicious nature of all data. DAS allows nodes to ensure the availability of a block by downloading random segments and alerting in case any part is missing. This alert system is only one aspect of a DAS mechanism that employs fraud proofs (such as Celestia). In the case of a validity proof DAS mechanism like Danksharding, there is no need for an alert system, as the validity proofs guarantee the correctness of erasure coding and commitments. These mechanisms reduce the risk of concealed block data and ensure numerous nodes randomly inspect the block.

A node randomly samples a block to check its availability. (Source: Vitalik Buterin)

Data sampling is what makes Celestia and Danksharding so secure. At least users know that if corruption happens, they can quickly detect it. In contrast, with the black box of a DAC, there could be corruption for a year, and nobody would realize it. 

Examples: Fuel

In contrast to traditional rollups on Ethereum, sovereign rollups function differently. Unlike standard rollups, sovereign rollups do not rely on a set of smart contracts on the layer 1 to validate and append blocks to the canonical chain. Instead, the blocks are published as raw data directly onto the chain, and the nodes on the rollup are responsible for verifying the local fork choice rule to determine the correct chain. This shifts the responsibility for settlement from the layer 1 to the rollup. Unlike traditional rollups, there is no established trust-minimized bridge between a sovereign rollup and Celestia. This can be seen as a negative, as you would want a bridge to be as trust-minimized as possible, but this does give sovereign rollups the advantage of an independent upgrade path through forking. This allows for easier coordination and more secure upgrades than non-sovereign rollups can offer.  Technically, we should not consider this a rollup, as a rollup usually implies having a unified settlement and data availability layer. Because of this, sovereign rollups are also referred to simply as sovereign blockchains.

To make it easier for developers to create sovereign rollups on Celestia, Celestia has created Rollmint, replacing Tendermint as a consensus mechanism. This enables rollups to publish blocks directly to Celestia instead of going through the Tendermint process. With this design, the community behind the chain has full sovereignty and is not subject to the authority of any other state machine. This sets it apart from communities behind smart contracts or rollups on Ethereum, which are bound by the social consensus of the Ethereum community.

Examples of a Settlement Chain: Fuel, Cevmos, dYmension

The creation of a standalone and modular settlement component is what defines the concept of a settlement rollup. Currently, rollups utilize the Ethereum main chain for settlements, but there are additional solutions apart from this. The Ethereum chain is shared with other non-rollup applications for smart contract transactions, leading to reduced scale and a lack of specialization.

An ideal settlement layer for rollups would only allow rollup smart contracts and simple transfers between rollups while prohibiting or making it expensive for non-rollup applications to settle transactions.

Celestia's design offers a standard global state consensus layer for developers to construct execution rollups that are part of a single trust-minimized cluster. It also enables trust-minimized bridging between rollups on the same global state consensus layer, a new concept not seen in current architectures. Whether or not developers will adopt this new cross-rollup paradigm remains to be seen.

Examples of settlement chains include Cevmos, Fuel, and dYmension, with Polygon competing with Celestia by building its interpretation of a modular architecture. In Polygon’s modular design, Polygon Avail serves as the data availability and consensus modular components, while the Polygon blockchain functions as the settlement layer.

The Case for Monolithic Chains

Many articles on modular blockchains typically pronounce monolithic layer 1s as a dinosaur technology compared to newer modular solutions. Currently, it’s hard to fully support this claim, as one major issue with these scaling solutions is the further trust assumptions they add to the overall system. While we have discussed how most DACs and validiums are insecure, this can even extend to the execution layer (i.e. the rollups).

Some of the most widely used rollups today still have yet to become genuinely decentralized, even though they secure billions of dollars. At the time of writing this article, Optimism still does not have functional fraud proofs, and Arbitrum is mutable from a single multisig. Both protocols are working to address these issues as part of their scheduled development, but it is important to keep in mind that decentralization is not a given just because a protocol uses a particular architecture. Additionally, the bridges between all pieces of modular components, primarily sovereign rollups, can face the same insecurities that cross-chain bridges face. Lastly, one major issue is that there is added complexity to developing on top of a modular stack; for some developers, it may be challenging. Eventually, we expect rollups will solve these issues and achieve sufficient decentralization. However, monolithic layer 1s could also become just as decentralized in the meantime.

Our previous reports discussed how some monolithic layer 1s scale internally with a DAG architecture. This is just one example showing that monolithic blockchains are trying to innovate without relying on off-chain components, and countless other optimizations are being worked on to maximize performance. We cannot simply discredit the idea of a new blockchain design that aims to solve all corners of the scalability trilemma.

Conclusion

Just as there were modular phones, there are now modular blockchains. However, seeing the potential for a rollup-centric future based around Danksharding indicates that modular blockchain architecture is unlikely to suffer the same fate as the modular phone. Execution layers like Kindelia and Fuel will especially see user growth, as their focus on speed and new features will allow the applications built on top of them to be truly innovative.

Unfortunately, many of these modular designs are still untested, and some modular blockchain designs may never gain widespread adoption. Validiums may be completely phased out as Celestia and Danksharding become widely adopted. Celestia’s sovereign rollups may face some of the same bridging issues as existing layer 1s, hindering adoption due to security and complexity concerns.

A decentralized, modular blockchain future is still a long way away. In the meantime, monolithic blockchains will continue to be relevant and keep innovating. When we finally do reach a future where modular blockchains are widely adopted, the monolithic blockchain landscape may also look completely different. Nevertheless, we need scaling solutions to service existing blockchains with liquidity and users, and in the long term, a modular blockchain architecture will likely be the best way to do so.

Author

Robert McTague is an Investment Associate for Amber Group's Eco Fund, the company's early-stage crypto venture fund. He recently won the third place prize during ETHSF with a few friends building on top of Fuel. He is very optimistic about the future of modular blockchains.

Disclaimer

The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.

Smart contracts aren’t that smart

When someone purchases a digital asset stored on a blockchain, it may seem like moving it to a different blockchain is a safe and easy process. After all, in the world of traditional finance, moving money or assets from one database to another is a generally straightforward, even trivial process. However, this isn’t the case in web3. Smart contracts are not as smart as many would think. This is because smart contracts can only view the current state of the blockchain they are deployed on. Viewing the state of another blockchain is totally out of the question. To circumvent this issue, developers have created various tools, such as cross-chain messaging protocols, oracles, and bridges. Are these tools the solution to the problem plaguing web3 today, and can they make smart contracts smarter?

To some extent, yes, but most variations of today's tools rely on off-chain systems and/or centralized parties. This creates a risk where trust in the wrong parties could jeopardize the blockchain ecosystem if these pieces of middleware have a security flaw. We have seen this time and time again. 

With the ecosystem progressively moving towards a multichain future to alleviate scalability issues, we must create tools that are increasingly trust-minimized. With a piece of infrastructure called state proofs, smart contracts become smarter and can view the state of any blockchain at any point in time. State proofs are needed to enable the next generation of decentralized applications.

Problems with the current system

Since smart contracts are limited to accessing only the current on-chain data from their respective blockchains, tools have been created to alleviate this issue. These tools are oracles and cross-chain bridges. Oracles serve as a data bridge allowing decentralized applications to access any chain's historical data and even certain off-chain data. While oracles are needed to enable smart contracts to ingest off-chain data, it may not make sense to use an off-chain indexing solution to access on-chain data. This is because an insufficiently decentralized oracle can be manipulated. Many applications have mitigated this risk by using solutions like Chainlink, an example of an oracle that indexes/aggregates with a sufficiently decentralized (albeit off-chain) architecture. Chainlink secures around $9 billion in TVL today, demonstrating developers' trust in it. While this solution works and may be necessary for specific applications, you may want your data to be kept from being relayed off-chain because it further reduces points of failure. For on-chain data, it may make more sense to query using an on-chain solution, such as state proofs. However, trust minimization is just one of many issues present with the current system; in addition to centralization risks, blockchain interoperability remains a large technical challenge.

Blockchain communities are looking for ways to use their favorite decentralized applications without paying outrageous gas fees, pushing them to migrate to more scalable blockchains. However, building on these blockchains causes liquidity to be fragmented across several ecosystems. Smart contracts can’t natively communicate across chains, limiting smart contracts’ access to on-chain data. This pushes developers to trust centralized bridge operators or distributed networks that operate off-chain.  These may not be the safest options, as seen with cross-chain bridges. Cross-chain bridges, in their current implementation, present much bigger risks than most oracles. So far, bridge hacks have resulted in losses topping $2.5 billion, which is around half of all the TVL in bridges today.

These staggering losses and the frequency with which they occur show that we need more robust solutions to communicate across chains. Relying on counterparties can lead to hacks and exploits that may destabilize whole ecosystems. State proofs are potentially the solution many developers have been looking for to make cross-chain applications far safer.

What are State Proofs?

While we have mentioned state proofs as a nearly trustless solution, we have yet to describe what they are and how they work. A state proof is a digital record that provides evidence of a specific state of a blockchain. The goal of state proofs is to enable blockchains to digitally sign messages in a way that is verifiable by everyone. To properly incorporate state proofs into blockchain applications, Merkle trees, zero-knowledge proofs, and light clients must be used. The easiest way to introduce these concepts is an analogy:

Imagine that you have a big book with lots of information written in it. This book represents a blockchain. Each page in the book is called a block, and each block has a unique code, called a hash, that identifies it. When you want to add new information to the book, you write it on a new page and then add the page to the end of the book. You also include the hash of the previous page in the book so that everyone can see that the new page is connected to the rest of the book.

Let's say that you want to prove to someone that a particular piece of information is written in the book. In this hypothetical situation, each book page can not natively view a previous page of the book nor view a page of a different book. This problem can be circumvented by generating a state proof for a page of a given book. 

A state proof is like a picture of the page in the book where the information is written. This could be a picture of a previous page or a picture of a page in a different book. It includes the hash of the page, as well as the hashes of all the previous pages in the book. This proves that the information is written on a specific page in the book and that it is connected to all the other pages in the book. However, verifying a book that has accumulated years worth of pages would take a while. To make the picture useful, state proofs must utilize a Merkle tree.

Merkle Trees

If the book is big, and there are many pages, it might take a long time to show someone all the pages and prove that the information is in the book. That's where a Merkle tree comes into play. A Merkle tree is a special kind of picture that helps us remember all the pages in the book more quickly. It works by dividing the pages into smaller chunks called leaves and then creating a tree-like picture by mixing pairs of leaves and making a new picture (called a node). The top picture in the tree is called the root, representing the entire book. To prove to someone that a particular piece of information is in the book using a Merkle tree, we just need to show them the root picture and the picture of the specific leaf (page) that the information is on. They can then use the pictures to recreate the tree and ensure the root picture matches the one we showed them. This proves that the specific page and the entire book have not been changed because any changes to the pages would result in a different root picture.

A Merkle tree allows for efficient verification of the contents of a large dataset, such as a blockchain, without the need to verify the entire dataset. This can significantly reduce the time and resources needed to verify a state proof. However, sometimes it may be desirable to verify the contents of a specific book page without revealing the page's actual contents. This is where zero-knowledge proofs (ZKPs) can be helpful.

Zero-Knowledge Proofs

What if you wanted to prove to someone that you know a particular piece of information written in the book but want to keep it private? You can do this using zero-knowledge proofs (ZKP). A ZKP is a unique picture of the page in the book where the information is written. It includes the hash of the page and the hashes of all the previous pages in the book. However, unlike a regular state proof, the ZKP does not reveal the actual information written on the page. It only shows that the prover knows the information without revealing it. A ZKP is like proving that you know specific information written in the book (the blockchain) without revealing the actual information itself. It is a digital fingerprint that allows you to prove that you know the information without revealing any additional details. A state proof will usually be packaged as a ZKP and sent to the destination chain. But how exactly is this proof sent to someone else? We will need to see what messaging protocol enables state proofs to have minimal trust assumptions.

Sending the ZK-Proof payload

Up until now, we assumed that state proofs are a nearly trustless solution compared to any other solution available today. This is true; however, it depends on how the ZKP is relayed to the destination chain. Each implementation has pros and cons, and relying on a messaging protocol with more trust assumptions may make sense in certain cases. There are three ways to achieve a messaging protocol: standard messaging, consensus validation, and optimistic MPC relayer. Let's dive into how each works.

Standard Messaging

Standard messaging works by sending a message from layer 2 to layer 1 or vice versa. However, unlike third-party solutions, standard messaging is a built-in messaging protocol between layer 1 and layer 2 blockchains and is a unique property of rollups.  An example of this would be a rollup such as Optimism. Optimism is able to send asynchronous calls between L1 and L2 users or contracts. Essentially, a contract on L1 can make a call to a contract on L2 and vice versa. This is implemented by deploying “bridge” contracts on both Ethereum and Optimism. You can get the block hash by calling the proper opcode. There is no middle-man third-party/network that needs to transfer the message between contracts. While this approach is sufficiently trustless, if you wanted to send a message to Optimism from Ethereum, you would need to sign the message on both chains. This requires interacting on multiple layers, which causes friction and latency issues. This also cannot be easily extended to two different layer 1s, so there is a limit to how cross-chain applications could use this messaging.

Consensus validation

Since Ethereum has migrated its consensus protocol to Proof of Stake (PoS), verifying the underlying consensus protocol is finally doable. Proving hashing functions on Ethereum PoW (Ethash) was nearly impossible before because the process is very memory intensive. It is now finally possible to verify the consensus, as with PoS you only need to verify BLS signatures which is much more memory efficient. However, it is still expensive to do this computation within a smart contract. It makes more sense to do the computation needed to verify the consensus within a ZKP. Since this verifies the consensus directly, there is no trust assumption. The only issue is the computation could take a while, which would lead to major latency issues and limit which applications could be built with this method. Some blockchains, such as Algorand, use this messaging method to power their cross-chain applications. Consensus validation is the method that powers their network’s cross-chain bridge. However, there is a requirement that the network must be a proof of stake network. As such, some blockchains may not message each other this way. There is also a gas cost issue attached to this approach, as you need to verify the ZKP, which is much more expensive than just consuming a message or verifying a signature.

Optimistic MPC relayer

Herodotus, a company producing software to make state proofs more accessible to developers, is taking a different approach. Herodotus uses an optimistic relayer based on multi-party computation (MPC). MPC is a type of secure computation in which multiple parties (in this case, validators/relayers)  attest if a specific commitment is valid. MPC works similarly to a multisig where more participants make the overall system more secure. But, as you add more validators, more people are required to verify each commitment. The more decentralized this gets, the more expensive it is to verify.

One significant advantage this has over sending a message is that you could use an off-chain call to get the latest block hash and relay this directly to the smart contract on the destination chain, which greatly reduces latency. The downside here is that MPS relayers require more trust. However, this is not necessarily a deal-breaker because network participants can dispute whatever data the MPC validators send. Since we know that layer 2s can message layer 1s in a way that is fully trustless, this can be used as a backup source of truth. Even if the validator set lies, the actual layer 1 to layer 2 messaging cannot lie, so it is simple for network participants to check if the validator set is lying, as it only requires two RPC calls to the chain. One call will check the actual commitment on the chain, and the other call will review the claimed commitment. The fraud proving window is short but can take time, as it will take as long as it takes for consensus validation.

Being trust minimized introduces unavoidable latency.

The latency present in trust-minimized solutions may be a challenge for some applications. An example of an application where speed is essential would be a cross-chain exchange. The speed of state proofs would not be able to accommodate that. That said, different messaging methods can be used to optimize for each specific type of application. However, once we have established the best and fastest way to generate and send state proofs, to whom exactly are we sending them to? And how can all of the topics we discussed be used to secure applications such as cross-chain bridges?  A light client is the final missing piece to understanding the tools involved with state proofs. 

Light Clients

Continuing with the analogy from before, a light client would be someone who wants to access the information in the book (the blockchain) without having to carry the entire book around with them all the time. They can ask a full node (someone who has a copy of the whole book) for the specific information they need or ask for a state proof to verify the existence of a particular piece of information in the book. This allows light clients to interact with the blockchain without storing all the data themselves, which can be helpful for devices with limited storage or computing power. 

State proofs can help light clients import data from other chains cost-effectively and securely. Bridges or other applications can query these light clients to validate activity between two blockchains. Therefore, the need to trust third parties is completely eliminated.

Are state proofs the solution?

Use Cases for State Proofs

Developers can implement state proofs in a variety of applications. While we know the issues plaguing cross-chain bridges, we have not yet explained how state proofs can be used to strengthen a bridge’s security.

Bridges

Algorand is an excellent example of how state proofs could strengthen a bridge. As mentioned before, Algorand is using consensus validation as their form of messaging. Since the Algorand blockchain verifies the consensus directly, this method doesn’t have additional trust assumptions.  In this example, let's imagine that Alice wants to send Bob 10 “AliceCoins” from Algorand to Ethereum. AliceCoins are very sought after, so they want to make sure the tokens arrive quickly, safely, and without permission from or trust in an intermediary. Alice can send these tokens directly to Bob’s Ethereum wallet via a trustless bridge whose code base is open to the public.

Algorand’s state proof powered bridge.

The bridge works by “locking” the AliceCoins in the smart contract on Algorand. The partner smart contract on Ethereum would ask Algroand’s light client (which is kept up to date via state proofs) if Alice has locked the tokens. Once verified, the bridge would mint the same amount of tokens on Ethereum to Bob’s wallet. Developers can model this process backward to enable transfers from Ethereum to Algorand. Bridge operators can create Algorand smart contracts that ask these light clients to validate Ethereum transactions (e.g. depositing ETH in an Ethereum smart contract) via Algorand’s Contract to Contract calls. A pair of light clients on both chains would enable the bridge to work in both directions. There is no reliance on a centralized party to maintain the bridge, and state proofs enable the bridge to be truly trustless.

Account Abstraction

Our previous report talked about how account abstraction will evolve wallets. Account abstraction wallets are programmable smart contract wallets and can utilize state proofs to add to their feature set. By generating a state proof for the wallet at regular intervals, such as every day or every week, wallets could use it to detect the inactivity of a user's account. If the wallet has not undergone any transactions or changes during that period, the state proof will be the same as the previous one. By comparing the current state proof to the previous one, it is possible to determine whether the wallet has been inactive or not. This could be useful for detecting abandoned or dormant wallets or identifying accounts that may have been compromised or otherwise tampered with.

This could be useful for implementing new types of social recovery functionality, which activates when a user loses access to their wallet. If the wallet has been deemed “dormant” by state proofs, the social recovery could start, allowing the user to get back into their account.

Gaming

Web3 game developers currently face a tough dilemma. They want to allow their users to trade their in-game items as NFTs on a thriving marketplace, but they also want to have cheap gas fees so they will not be a friction point for the user. The community typically forces developers to deploy their NFTs onto the Ethereum blockchain because NFT marketplaces on Ethereum have much more volume and liquidity than other chains’ marketplaces. However, this poses an issue for game developers, as if the NFTs are on Ethereum and the developers do not want to have a friction point of bridging, the game will have to deploy there as well.

If the game deploys onto Ethereum, users are stuck paying ridiculous transaction fees. It makes little sense that a gamer should pay a few dollars in fees to interact with a game on-chain. Developers want to deploy their game onto a layer 1 with cheaper gas, or even a layer 2, but still want their in-game items to be sought after.

State proofs could help alleviate this roadblock. As a game developer, you could deploy your NFTs on one chain while using them for a game on a different chain. There would be no bridging of assets and no need to deploy everything to one chain. State proofs would allow you to simply verify a player’s ownership of a given in-game NFT item on say, Ethereum, while conducting the actual in-game interactions on a cheaper layer 1 or layer 2.

Governance

Many decentralized finance applications have embraced the idea of being deployed onto as many chains as possible. While this can be good for reducing fees for the end user, it can make governance a headache. Most of these protocols issue governance tokens across multiple blockchains. With these tokens, participants of the protocol can vote on changes to the protocol. However, this causes a logistical nightmare for the actual governance applications which facilitate the voting. These applications have difficulty aggregating a user’s token balance across multiple chains. Without state proofs, users would have to rely on a trusted oracle or bridge their tokens back to a major chain (such as Ethereum) and then vote there. With state proofs, the governance application could check the state of the user's balances and use the total count of tokens across multiple chains as their voting power.

Closing Thoughts

State proofs make cross-chain applications safer. While applications can benefit from using state proofs, their importance to the application varies on a case-by-case basis. Some applications, such as cross-chain bridges, could utilize state proofs to better protect user funds. For other applications, it may be the case that you truly need a price feed that frequently updates, despite the fact you would be relying on a third-party intermediary for the solution. However, it is wrong to assume that an off-chain price feed is always needed for every application, as state proofs can fill many of those gaps. Account abstraction wallets, gaming, and governance are immediate use cases; however, state proofs are relatively early in their development, so we will eventually see how other applications use state proofs. Builders in the web3 space should push to use solutions that inherit the safety and trust of the protocols they build upon.

Author

Robert McTague is an Investment Associate for Amber Group's Eco Fund, the company's early-stage crypto venture fund. He hopes that as state proofs gain popularity, we will see a rise in safer cross-chain applications.

Disclaimer

The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.

We must continue to evolve

When someone first decides to plunge into decentralized finance, NFTs, or any other type of on-chain activity, they are hit with the realization that they first need to acquire a wallet. Unfortunately, the experience of using an on-chain wallet is much different than the user experience most people are accustomed to. This is a significant friction point that deters millions of potential crypto users.

While wallets do give the user full custody of their assets, they lack the security safeguards of other online accounts. Users must safely store and protect their private keys/seed phrases or risk losing their digital assets. This is very different from, say, a bank account or even a centralized crypto exchange account. For example, Coinbase and basically every other centralized account lets users enable 2FA to ensure the safety of their assets. This type of functionality is not currently possible with any on-chain solution. The lack of basic security features deters retail users from even touching on-chain applications and causes them to stick to their centralized and custodial wallets. As we have recently observed, this is not necessarily a safer option. The failure of firms such as FTX, BlockFi, and Celsius and the resulting loss of user funds has strengthened the case for maintaining self-custody of your assets. However, retail users need an easy way to do so. How can this current paradigm change? By evolving our wallets into account abstraction wallets, we can solve many user experience issues plaguing us today. 

The current system

There are two ways to implement self-custody wallets on-chain: you either need an externally owned account (EOA) or a contract account (CA). Both are capable of sending and receiving digital assets as well as interacting with deployed smart contracts. However, they have some key differences, which are summarized in the below table.

Right now, contract accounts are typically only used for self-custody in the form of a multi-signature wallet, or “multi-sig”. Multi-sigs offer an increase in security but are usually not a practical way for retail users to keep their assets on-chain because they are far more complicated to set up than a normal EOA wallet. Without account abstraction, contract accounts cannot easily be used as the primary method to store digital assets. 

There are 3 important conditions that must be met for something to be classified as an “account”. Regardless of being an externally owned account or a contract account, these conditions must be met. An account must have a:

1. Balance  - This represents the number of digital assets within the wallet

2. Nonce - This ensures that every transaction emitted from the wallet is different

3. Address - This is a unique identifier for each account on the network

While both types of accounts may look similar on the surface, the biggest difference is that an EOA must sign every on-chain transaction. Contract wallets cannot be used as a proper replacement yet because of this. The user owns an EOA wallet via a pair of keys, a public and private key. This pair of keys is known as the signer. An EOA wallet’s address is derived from the public key, while transactions from the account must be signed with the private key. Contract wallets do not have a pair of keys to initiate transactions.  This points to a fatal flaw with externally owned accounts. EOA wallets are both an account and a signer. This leads to headaches and potentially serious problems for users.

Problems with the EOA model.

While it’s disingenuous to say that the current EOA design (which is the standard for wallets today) is fundamentally flawed, it is certainly not in a state that billions of people across the world can use. The main reason for this is that the signer has complete control of the account. If you lose your signer, you lose your account. If someone gets a hold of your signer, they have your account. While this may work to hold a user’s assets under perfect conditions, we do not live in a perfect world. The security of EOA wallets relies entirely on users managing a single private key. There is no safety net; there can be no mistakes. However, people are prone to mistakes, and wallets cannot be this complex if they plan to scale to the masses.

An easy way to see that the current form of self-custody is flawed is to hop on Twitter and search “BAYC Hacked”. 

Holders of monkey jpegs are under constant attack due to how difficult self-custody is at the moment.

They get hacked a lot. 100s of Bored Ape Yacht Club NFTs have been stolen, and they continue to be stolen at a fairly frequent rate. This is a clear problem with the user experience of Ethereum. It should not be easy to lose a digital asset worth six figures. We should not expect the next financial system to rely on 12 words written on a piece of paper.

Account abstraction, the solution?

The goal of account abstraction is to decouple the relationship between the signer and the account. An account abstraction wallet is a smart contract wallet that defines what a valid transaction is, according to pre-specified and customizable rules. The goal is to prevent a signer from having absolute and final control over what happens to a wallet’s assets. Instead of having both EOA accounts and contract accounts, account abstraction merges them into one; smart contract wallets will be able to be used as standalone wallets. This is not possible today, as all transactions must originate from an EOA address. However, each new EIP brings us closer and closer to an account abstraction reality.

History of Account Abstraction

To properly implement account abstraction and reduce the need for EOA accounts, it has been long thought that a network-wide change needs to be made. Since 2016, Vitalik and other Ethereum core developers have been drafting solutions for how this change might look. These are summarized below:

• EIP-86: Proposed by Vitalik Buterin in 2016, less than a year after Ethereum’s initial release, this EIP introduced the concept of smart contracts as “forwarding contracts” and would only accept transactions coming from an “entry point” address, an address from which anyone could send transactions if they followed a specific format. This required major changes to the Ethereum protocol and was scrapped.

• EIP-1014: Proposed by Vitalik Buterin in 2018, this EIP took core ideas from EIP-86 and led to the creation of the CREATE2 opcode. This allows us to predict the address where a contract will be deployed without ever having to actually deploy it. This is important because for a smart contract wallet to function, we must make sure that the smart contract address is the same on all EVM chains, even if it hasn’t been deployed to all of them at the same time.

• EIP-2938: Proposed in September 2020 by Vitalik Buterin, Ansgar Dietrichs, and Matt Garnett, this EIP attempted to make new “account abstraction” transactions, requiring the creation of new opcodes. This proved to be too big of a protocol change, with uncertainties about how it would play out. EIP-2938 was scrapped.

• EIP-3074: Created in October 2020 by Ansgar Dietrichs and Matt Garnett, this EIP introduced two new opcodes: AUTH and AUTHCALL. When used together, they allow a smart contract to send a transaction on behalf of an EOA. As we have seen with other past EIPs, significant network changes have been unlikely to be approved. EIP-3074 was no exception and faced hesitancy about its security risks, so it was not implemented.

It’s important to note that the timeline of EIPs shows that account abstraction has been in the minds of the core Ethereum developers since the dawn of Ethereum. With the merge completed, more developer resources can finally go into account abstraction. The next EIP finally brings us close to next-gen wallets.

• EIP-4337 - Account Abstraction in Ethereum without requiring consensus-layer protocol changes: In September 2021, Vitailk, OpenGSN, and Nethermind proposed EIP-4337 — Account Abstraction via Entry Point Contract Specifications. The EIP attempts to accomplish account abstraction without requiring core protocol changes. This is a huge accomplishment, as protocol changes are what halted most advances so far. EIP-4337 is still in the draft stage and has not been finalized yet, but because EIP-4337 will not change the consensus layer, there are already implementations of it available, including OpenZeppelin and Stackup. The mechanisms of this EIP function can be broken down into three steps:

1. UserOperations, (which are essentially normal transactions with extra data fields enabling account abstraction features), are sent through a custom mempool

2. Afterward, UserOperations are packaged into a single transaction via a Bundler. Bundlers would choose which UserOperation objects to include based on fee-prioritization logic, similar to how miners operate in the existing transaction mempool. The bundler (using a service like Flashbots) calls an EntryPoint contract for verification

3. If there are no errors, the transactions are included in the next block on the network

The EntryPoint contract is a critical piece of infrastructure that is called via the Bundler. This smart contract is called to first verify that the UserOperations follow the pre-specified rules of the account and then execute them. It is important to remember EIP-4337 has no protocol-level changes. This means that Bundler is an EOA address that is submitting all these transactions to the chain. The EntryPoint contract can be extended further by adding a Paymaster. The Paymaster offers a few benefits:

1. It allows application developers to pay fees on behalf of their users

2. It allows users to pay fees in ERC20 tokens, with a contract serving as an intermediary to collect the ERC20s and pay for the gas costs in ETH

This is a massive bonus for application developers who don’t want their users to pay network fees. Users will be able to pay in different tokens directly to a ‘paymaster’ – who would then convert it into ETH for system compatibility. This is just one example of a unique use case that account abstraction wallets have over EOA wallets, and there is much more we must talk about.

Use Cases for Account Abstraction

Transforming wallets into programmable smart contracts opens the doors to new functionality. The benefits and new use cases of having an account abstraction wallet are so great it is actually worth migrating to one for most users. It is analogous to upgrading from an old Nokia phone to the latest smartphone.

Smart contract wallets are a major upgrade in terms of features compared to EOA wallets - Source: Argent Wallet on Twitter.

Social Recovery

One of the most important benefits in terms of securing a user’s digital assets, social recovery aims to protect users if they lose their signing key. Imagine if a user’s laptop broke and they had misplaced their physical copy of their private key or seed phrase. In this scenario, with an EOA wallet, all your assets would be lost forever. Instead of using a seed phrase to recover a wallet, social recovery follows a different method. This is Vitalik’s favorite way to secure a wallet, and he defines how it works below:

1. There is a single "signing key" that can be used to approve transactions

2. There is a set of "guardians," of which a majority can cooperate to change the signing key of the account

If a user loses or forgets their signing key, the social recovery functionality can be activated. Typically, if I were to lose my signing key, and lose my seed phrase, I would be unable to get access to my account. With social recovery, the user can simply reach out to their guardians and ask them to sign a particular transaction to change the signing key registered in the wallet contract to a new one. Although there are some mechanical differences, this is conceptually similar to what happens when you forget your Google account password and need to regain access to your account. 

There are many possible choices for whom to select as a guardian. The three most common options are:

1. Other devices owned by the wallet holder themselves

2. Friends and family members

3. Institutions, which would sign a recovery message if they get a confirmation of your phone number or email, or perhaps in high-value cases verify you personally by video call

Adding new guardians is a reasonably straightforward process.

Screenshot of Unipass wallet’s UI for adding a guardian

The UniPass Wallet is an upcoming smart contract wallet with social recovery as one of its main features. The UniPass Wallet includes an interface by which guardians can be added and removed seamlessly.

Role-based access control

For many traditional “web2” applications, users are required to enable 2-factor authentication (2FA) by the platform's developers. This automatically prevents a large number of hacks from happening. 

It is worth noting that many other articles will claim that multi-factor or 2-factor authentication via SMS or email address is a new feature unlocked by having an account abstract wallet. Implementing this form of 2FA usually leverages Multi-Party Computation (MPC) and an off-chain server. There has yet to be a purely on-chain implementation. But since it is powered by MPC technology, it could also be implemented by just using an EOA wallet. It is disingenuous to say that it is unique to account abstraction wallets. 

However, smart contract wallets can implement a similar type of functionality on-chain by requiring your hot wallet to be used as a form of secondary confirmation. This automatically prevents a large number of hacks from happening, as even if you are phished you may still need confirmation to move your assets. Account abstraction wallets let you define specific security parameters according to your preferences. Examples of this could include:

• Setting a daily transaction limit which specifies a monetary threshold on what can be sent per day unless you confirm via your hardware wallet. This would prevent your wallet from being drained all at once.

• Connecting to a database of well-known “scam” addresses, which would immediately prompt you to confirm a transaction via your hardware wallet if an address you are interacting with is stored in the database.

• Checking Opensea collections and letting you know that you are purchasing a non-verified NFT collection and prompting you to confirm via your hardware wallet, preventing confusion about buying a fake/malicious NFT.

Most importantly, all these features provide a multi-layered safety net when performing on-chain interactions. Most users have no idea what they are signing or approving. Right now, we operate on a system where one misclick can deplete your wallet’s balance instantly, and this needs to change. 

Session keys

Many think blockchain gaming will be the next big narrative in web3. For this to take place, there needs to be a better user experience than what currently exists. It makes no sense that a user should have to approve multiple functions whenever they want to interact with something in the game they are playing. This is not how traditional games work and will deter people due to the unfamiliarity and clumsiness of the interface. Session keys allow users to pre-approve an application's transactions according to a set of parameters: a given duration, a max amount of gas, a max transaction volume of a certain token, or a particular function on a particular contract. A user would be able to pre-approve their session with some basic terms, hit go, and play the game without constantly being bombarded by their wallet asking, “confirm this transaction”.

Batch transactions

Right now, if I wanted to use a decentralized application, I would need to make a new transaction for every on-chain interaction. This is annoying and can also be expensive, as each approved interaction costs money. With an account abstraction account, wallets can bundle multiple transactions together and execute them as one transaction.

This radically simplifies the user experience. Complex transactions and yield farming opportunities can be simplified to require only one click of a button.

Other use cases

The list of features an account abstraction wallet can support is limitless. Because account abstraction wallets are smart contracts, wallet developers can constantly update them with new features and utility. We can even expect third-party plug-ins for wallets. However, this brings me to my next point: the flaws of account abstraction wallets today.

Potential issues with account abstraction

Account abstraction wallets are currently not implemented at the protocol level and currently only exist as smart contracts, with gas being relayed in creative ways. Because these wallets are smart contracts, some issues arise. First, there is a cost to deploy the smart contract wallet, as it uses blockchain storage. This can be circumvented currently by using cheaper chains or by having a relayer cover this cost. However, this does not really circumvent the higher gas costs of submitting a transaction. The gas cost for a single transaction sent via a smart contract wallet is more expensive than sending via an EOA wallet. While this one day could be improved with proper batching of transactions, we are not at that point yet. A second, more important issue is that each wallet needs to be audited before it is used as a replacement for EOAs. If a widely-used smart contract wallet has an exploit, it could be one of the largest hacks of all time. This isn’t just hypothetical, as smart contracts wallets have been hacked before. In 2017, the Parity smart contract wallet saw a hack of 150,000 ETH (valued at 180 million USD today). Three months later, that same smart contract was hacked for another 500,000 ETH (valued at 600 million USD today). Luckily, we have improved our security standards since 2017, and most of what account abstraction wallets currently try to accomplish isn’t unreasonably complex. Security features like social recovery and role-based access control are also built-in by default, which provides a level of protection from any issues in the smart contract itself. However, even with these features, there are still security problems with the current implementation of ERC-4337. The biggest issue is the extremely high privilege that the EntryPoint contract has. If this smart contract has security issues, hackers would be able to exploit any ERC-4337 contract wallet through it.

In addition to security issues, the infrastructure to properly support ERC-4337 is not there completely. The current implementation of ERC-4337  heavily relies on Flashbots. Flashbots is vital to account abstraction, as it packages up a set of UserOperation objects into a single “bundle transaction”, which then gets included in an Ethereum block. Flashbots is specific to Ethereum itself, bringing into question how ERC-4337  wallets could be compatible with other EVM chains. While the contract wallet could be deployed onto another chain, without a comparable mechanism to Flashbots for bundling transactions, the wallet would not be functional. Lastly, smart contract wallets can only interact with decentralized applications that have implemented EIP-1271, which is called to verify signatures from contract wallets. Theoretically, if Opensea or any other decentralized application has not yet implemented EIP-1271, the smart contract wallet will not be able to interact with the application and will be rendered useless.

Established smart contract wallets like Argent didn’t just deviate from ERC-4337 for no reason. Layer 2 networks are working with clean slates to implement protocol-wide changes to circumvent issues raised by ERC-4337.

Layer 2s

Layer 2s are building their networks from the ground up and can more easily implement changes, as they are starting with a cleaner slate, in terms of technical debt. Zksync and Starkware are both Layer 2 networks that have natively built-in account abstraction at the protocol level. Unlike Ethereum, Zksync and Starkware make no distinction between smart contracts and EOAs, and the two types of wallets are merged as one. Layer 2s have achieved true account abstraction beyond what any EIP has successfully implemented thus far. These accounts can initiate transactions, like an EOA, but can also have arbitrary logic implemented in them, like a smart contract. These designs are very similar to the design laid out by EIP-4337. With cheaper fees and the simplification of creating and maintaining a wallet, layer 2s may be the perfect place to onboard the next billion web3 users. In the meantime, however, what if we wanted to use an EIP-4337 wallet on Ethereum? What is the best wallet to do so?

UniPass, an Account Abstraction wallet

While Argent wallet (an amazing account abstraction wallet) is focusing on layer 2s like Starknet, it is important that we see implementations on layer 1s such as Ethereum. UniPass is an account abstraction wallet building a range of features that set it apart from the competition, including both EOA wallets and other account abstraction wallets. When UniPass users initiate a transaction, a third party is required to act as a relayer to fulfill it. In this process, the relayer can allow users to spend arbitrary supported tokens to pay for the gas fee, or even pay the gas fee for the users, thus achieving a gasless user experience. UniPass will provide a default UniPass Relayer Node that you can use out of the box. In the beginning, UniPass Relayer will accept gas payments in the form of its native token and mainstream stablecoins. Additionally, applications can build their own customer relayer to meet the needs of their user base.

Other smart contract wallet solutions often rely on EOA wallets for private key management. UniPass Wallet uses an MPC-based Threshold Signature Scheme (TSS), which allows it to be reliant on EOA wallets for security and availability while also completely avoiding private keys, the largest single point of failure, throughout the entire user journey. This creates a seamless user experience that is both delightful and secure for the users. 

Creating a wallet is as simple as logging in with your Google Account

UniPass also has a unique on-chain email-based verification technique for social recovery. Email protocols (POP3, SMTP, and IMAP), have existed for more than 50 years already, and are a foundational piece of the modern internet. In order to protect emails from malicious modification, DomainKeys Identified Mail (DKIM) was introduced in 2004. DKIM is a standardized identity verification technique for email. Senders are able to add a digital signature to outgoing emails. When an email server receives signed emails, it can verify whether the email is coming from the actual sender and whether the content is modified.

After endless research, UniPass Wallet can now verify DKIM’s digital signature using smart contracts on-chain. This allows users to manage their non-custodial contract accounts and carry out social recovery using only emails. Typical smart contract wallets’ social recovery solutions, like Argent’s, require guardians to be users of Argent or to have an Ethereum wallet already. This means that if your trusted family members and friends are not web3 users, they cannot act as your account’s guardians. With UniPass’s architecture, users can set multiple email addresses as guardians of the account, which can help users set up account recovery by simply submitting emails to a smart contract on-chain. This greatly lowers barriers for guardians and allows all your family members and friends with emails to become guardians of your account.

However, one question arises: how can UniPass keep all this information private? It would not be good if an email address tied to your account is visible to everyone on-chain.  As such, UniPass Wallet uses zero-knowledge technology to completely anonymize users’ private information on-chain, achieving decentralized verification while protecting users’ privacy.

Closing Thoughts

With the collapse of major centralized custodial wallet solutions, many users are flocking toward self-custody wallet solutions. EOA wallets must evolve into account abstraction wallets to scale to the next billion users. They make the onboarding process more accessible, strengthen security, and dramatically improve usability. While we still need to rely on solutions to relay gas in creative ways on layer 1s, layer 2s such as Starknet and Zksync will implement account abstraction in its most pure form. This material UX improvement could easily help foster growth on these networks. The Ethereum community must watch how this plays out closely to safely implement EIPs that change Ethereum’s base protocol. Regardless, there are still wallets, such as UniPass, taking the lead and creating advanced wallets with EIP-4337. I look forward to the day when these solutions become widely used and we wonder how we used to store our digital assets in such an archaic way.

Author

Robert McTague is an Investment Associate for Amber Group's Eco Fund, the company's early-stage crypto venture fund. He hopes that as we integrate account abstraction, blockchain technology will scale to the next billion users. Special thanks to George Zhang (UniPass) for helping us understand all of the finer details of account abstraction.

Disclaimer

Amber has invested in UniPass. The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.

Introduction

In the early 1800s, the five sons of Mayer Rothschild branched out from their base in Frankfurt, establishing branches in London, Paris, Vienna, and Naples. They built out an information network, using carrier pigeons, couriers, and chartered boats to shuttle information across Europe faster than anyone else. Through this network, the Rothschild received news and information faster than anyone else, which they leveraged to make fortunes in arbitrage and trading. Famously, it also enabled Nathan Rothschild to hear of Napolean’s defeat at Waterloo a full 36 hours before London’s official messenger. 

Within all markets, information is valuable. And the competition for privileged access to information is fierce. Even today, in traditional markets, high-frequency trading firms and hedge funds spend billions of dollars on towers and cables across the world, in an arms race to gain information edges measured in mere milliseconds.

Crypto is no exception. On-chain, there is intensifying competition for superior access to order flow and ordering rights. This concept of “maximal extractable value” - or MEV for short - has emerged from a niche topic to the forefront of virtually all crypto protocols. We see increasing dialogue within the community on MEV’s impact on a protocol’s transparency, sustainability, decentralization, security, censorship resistance, valuation, and more. 

We aim to discuss several key topics around MEV in this report. We first introduce what MEV is and why it matters. Then, we outline why we believe MEV is fundamental and the trade-offs in managing MEV. We also summarize the current state of MEV and some of the major players in the field. Finally, we touch on future trends and open questions.

Key Takeaways:

• Understanding MEV is important. MEV affects the security, stability, and user experience. It is also a key component of how blockchain tokens accrue value. Above all, it impacts two fundamental properties of blockchain networks: decentralization and censorship resistance.

• MEV is fundamental. There are solutions to mitigate some forms of MEV. But ultimately, some amount of MEV will always exist. A blockchain network’s gift as a limitless and permissionless smart contract platform is also a curse for more MEV to manifest. Protocols and applications need to think carefully about managing trade-offs in dealing with the MEV. 

• We estimate that under PoW Ethereum, MEV contributed to at least 5.8% of total miner revenue since 2020. Capturing MEV opportunities in the major categories - arbitrage, liquidations, and sandwich attacks - are incredibly competitive and consolidated by a handful of searchers.

• While arguably negligible in impact today, cross-chain MEV is likely a highly centralizing force that impacts all blockchains. Multi-block MEV is also a remote but growing threat to the stability of blockchain networks.

• We can foresee scenarios where payment-for-order-flow (PFOF) or transaction flow auctions exist, returning some amount of MEV to users. Under these scenarios, it appears the most likely path is greater centralization of block builders and reduced yields for validators, but more research needs to be done.

Into the Mempool

MEV was first defined in a seminal report Flash Boys 2.0 by Daian et al. The researchers found and studied multiple bots on Ethereum competing against each other to gain priority ordering and detailed their impact on the blockchain. The paper was also the first to propose a working definition for MEV as  “the total amount of Ether miners can extract from manipulation of transactions within a given timeframe, which may include multiple blocks' worth of transactions.”

That’s a mouthful. To better visualize MEV and understand how MEV is created from first principles, it is helpful to walk through the typical lifecycle of a simple Ethereum transaction.

Lifecycle of an Ethereum Transaction

Suppose Joe wants to swap 100 ETH to USDC on a decentralized exchange. Joe navigates to Uniswap’s front end and connects his MetaMask wallet. He specifies inputs for the trade - 1,000 ETH for $1,300,000 USDC with a 1.0% slippage tolerance - and signs the trade.

His trade is first sent through MetaMask's default RPC endpoint to Infura. Infura propagates this request to other nodes in the Ethereum network, who all similarly propagate to nodes that they are connected to. 

Each validator keeps its own mempool, which is a database of pending transactions that every validator maintains. It builds blocks of transactions based on its own mempool. Typically, these transactions are ordered by gas price. Alternatively, the validator could run custom software to order transactions according to its own rules and logic.

Every 12 seconds, one Ethereum validator is randomly chosen to build and propose a block of transactions. The proposer broadcasts a new block to the network. A committee of other validators is randomly chosen to determine the validity of the block and create attestations to it. After transactions are submitted, they are removed from a node’s mempool. 

How MEV is Created

The mempool is viewable to all. Because Joe’s transaction was submitted publicly, it created a couple of potential profit opportunities:

• Sandwich: Joe’s ETH to USDC trade has an unusually large slippage tolerance of 1%. Although he expects to receive $1,300,000, Joe signaled to the world that he would accept $1,287,000. Other entities monitoring the mempool will see Joe’s tolerance and attempt to “sandwich” it to give Joe the worst possible execution price and capture a risk-free profit. They do so by selling ETH in front of Joe (frontrunning his transaction), allowing Joe to sell at his lowest defined limit, then buying back ETH at a relatively deflated price. 

• Arbitrage: After Joe’s transaction, there will be a temporary price discrepancy in the ETH-USDC pair among Uniswap and other DEXs. There are bots continuously looking for these discrepancies and will automatically execute arbitrage after Joe’s trade (backrunning his transaction) to capture risk-free profit.

Validators are in a privileged position to extract this profit. Ethereum’s consensus protocol only enforces agreement at the block level, allowing validators to choose what happens within each block. Therefore, validators can decide what transactions to include and in what order these transactions are executed.

For instance, suppose that there is $100 of arbitrage profits to be made across DEXs. Alice could submit a transaction that attempts to capture this profit, offering to pay $1 in transaction fees. But, again, the mempool is viewable to all. Bob, seeing Alice’s transaction in the mempool, copies her transaction and offers to pay $2 in gas fees. Others could pile into this trade.

Unmanaged, this dynamic creates incentives for users to create off-chain agreements with validators/miners to guarantee transaction inclusion or ordering. Or, instead, validators/miners themselves can submit and prioritize their own transactions to capture the full $100 arbitrage profit.

Hence the term “maximal extractable value” - or MEV for short. The term was historically referred to as “miner extractable value” but since changed to acknowledge Ethereum’s shift to PoS and growing market share of PoS-based blockchains. 

MEV Supply Chain

Generalizing the lifecycle from above, we can form a supply chain of MEV. This supply chain becomes a useful framework to understand various stakeholders in the ecosystem, where MEV accrues, and how best to mitigate and manage MEV.

The MEV Supply Chain

Source: Flashbots

• User: Anyone who would like to express and submit intent to change the state of the blockchain. 

• Wallet / Application: The user interface that translates user intent into a blockchain transaction. 

• Searcher: Entities that monitor the mempool and submit transactions to extract MEV. 

• Builder: Aggregate transactions from various sources to create a full block, ideally one that maximizes rewards.

• Validator: Perform consensus duties, such as proposing and attesting to blocks.

Defining MEV

An updated definition of MEV for PoS-blockchains:

The total value a validator can extract across a block (or a series of blocks) given the state of its environment and all the actions available to it. 

Validators usually cannot change the state of their environment. This includes the blockchain’s rules, smart contract code on top of the blockchain, the set of transactions in their mempool, etc.

Actions can include reordering, censoring, and inserting transactions. They can also include more niche strategies, such as changing block timestamps, manipulating “randomness”, DOS’ing other validators, and more. 

MEV Types

The three largest and most competitive MEV revenue pools are arbitrage, liquidations, and sandwich attacks. We outline these three below and some other interesting, more niche MEV opportunities that give a better sense of what MEV is.

Arbitrage

Arbitrage is the largest source of MEV revenues. It is considered MEV because ordering matters here.

Arbitrage trading occurs in all markets. But whereas arbitrageurs in traditional markets are exposed to some inventory or timing risk, a lot of MEV arbitrage can instead be performed atomically. Either all the desired trades go through, netting a risk-free profit, or none of the transactions go through. Another aspect of atomic arbitrage is the ability to use flash loans, allowing searchers to operate with minimal capital on hand in some cases. But there also exists classic statistical arbitrage trades that have inventory and timing risk, such as arbitraging prices between a CEX and DEX. 

Atomic arbitrage is now incredibly competitive. Winning arbitrage entails 1) running optimized hardware + software for quickly finding opportunities across thousands of pairs, and 2) submitting extremely efficient trades to minimize gas usage. This second phenomenon is called “gas golfing,” and allows MEV searchers to competitively bid for a trade. 

Liquidations

Money markets like Aave, Compound, and Maker allow users to deposit some assets as collateral and borrow others. As the value of collateral assets fluctuates, so too does users’ borrowing power. 

These protocols rely on market participants to liquidate borrowers if the borrowers exceed their allowed budget. But market participants will not do this for free. To incentivize liquidations, protocols charge a liquidation fee on borrowers and give some of these fees to liquidators.

This is where the MEV opportunity resides. Searchers compete to monitor the positions of all borrowers and attempt to be the first to liquidate those with underwater positions, thus collecting liquidation fees for themselves.

Similar to arbitrage, liquidation events are highly competitive. During sharp market downturns, the competition to liquidate borrowers has led to enormous gas fees. Again, searchers who can optimize their code can bid most competitively for liquidations.  

Gas Prices Paid by Liquidators

Amount of dots represents the amount of liquidators participating. Grey line reflects the average gas price. Source: Qin et al. “An Empirical Study of DeFi Liquidations”

Sandwich Attacks

Transactions on blockchains do not incur instantaneously. When users send swap transactions, they define an acceptable percentage price change (“slippage”) that could occur while a submitted transaction is pending.

“Sandwich attacks” occur if users set too high a slippage for their trades. Searchers exploit these mistakes by first front-running the user’s transaction to the highest acceptable slippage, allowing the trade to occur at an unfavorable price. The user’s trade is then executed, further moving the price. Subsequent to this, the searcher would back-run the trade, netting a profit. In the below example, assuming the searcher paid 4 ETH in gas and priority fees, its risk-free profit is 3 ETH. 

Illustrative example. A user wants to swap 1,000 WETH to USDC with a 1% slippage tolerance. The searcher sees transaction 1 in the public mempool and constructs a bundle of frontrunning and backrunning transactions, and sends it to validators via mev-boost. 

As the above example demonstrates, sandwich attacks are more reliant on transaction ordering privileges. If either half of the sandwich attack fails to execute, the searcher faces potential loss.

As the name connotes, sandwich attacks are seen as toxic MEV and frowned upon by most of the crypto community. Whereas arbitrage and liquidation activities can be either malignant or benign, sandwich attacks are mostly seen as purely value extractive, probably because most users don’t know if and when they were sandwiched. Even several searchers publicly state that they refrain from sandwiching - admitting otherwise so would likely invite criticism and backlash. 

Spotting Sandwich Attacks on Charts

Long-Tail MEV

Long-tail MEV opportunities abound. Some examples:

• Apecoin airdrop: Yuga Labs decided to airdrop tokens to holders of BAYC. NFTX was an application that tokenized NFTs into fungible tokens. One MEV searcher bought up all of the fungible BAYC tokens in NFTX, redeeming the entire pool for an actual NFT, claimed the Apecoin airdrop, then re-supplied the NFTX pool. This earned the bot ~61k APE, equivalent to around $278k at the time. The bot paid $310 in gas price.

• Fat finger: Someone accidentally listed an EtherRock NFT for 444 gwei instead of 444 ETH. A bot immediately sniped it up and sold it for 234 ETH - roughly $600k at the time.

• 1inch dust: 1inch occasionally leaves tiny amounts of tokens in its router for reasons. There is an MEV bot programmed to sweep this router for as little as $4.

MEV Matters

Understanding MEV is important. MEV affects the security, stability, and user experience. It is also a key component of how blockchain tokens accrue value. Above all, it impacts two fundamental properties of blockchain networks: decentralization and censorship resistance.

MEV Creates Negative Externalities

MEV-related activities create negative externalities. For instance, without an effective fee market, competition for MEV can lead to Priority Gas Auctions (“PGAs” - sometimes called Probability Gas Auctions). During PGAs, searchers and bots compete against each other by strategically setting their gas fees to have their transactions included in front of (or behind) certain transactions. This leads to:

• Network congestion, which may cause other transactions to get stuck or dropped by the network

• High and volatile gas prices, crowding out other crypto users and disadvantaging less savvy participants

• Failed bids that unnecessarily consume block space (even failed transactions use up block space)

A high profile example is Yuga Lab’s Otherdeed land sale. Due to the peculiarities around the sale’s auction format, gas prices spiked to an absurdly high level as bidders jostled to have their transaction to be included in a block. Several users bid over 2ETH in gas, only to see failed transactions. Other users were priced out of Ethereum for hours, relegated to simply waiting for the sale to end. 

PGAs also create an arms race to win latency wars, as the searcher that has lower latency is better positioned to place the winning bid. PGAs occur less frequently on Ethereum, due to the advent of Flashbots and other mempool services. But they still happen regularly on high-throughput, low-fee chains like BNB Chain, Polygon side-chain, Aurora, and more.

MEV Can Destabilize the Network

More broadly, MEV drastically alters the incentives to a blockchain network’s stakeholders. If high enough, MEV rewards can encourage validators and miners to engage in malicious activity, such as performing reorg attempts. In fact, some community members have previously published code that would enable Ethereum miners to reorg the Ethereum network to capture prior MEV revenues. At that time, Ethereum’s social layer stopped miners from implementing it.

However, this threat has already materialized on other blockchains. Prior to Avalanche’s Apricot Phase Four upgrade, it was possible for any validator to propose a block. After one validator proposed a block that included meaningful MEV rewards, another validator could publish a longer chain of blocks to “steal” the MEV. So a race to reorg emerged. Clearly, this hinders a blockchain platform’s usability. Even today, other blockchains experience deep reorgs on an almost daily basis that are likely motivated by MEV.

Casual 194 Block Reorg

Source: Polygonscan, @Dogetoshi

Aside from reorgs, MEV also encourages spam transactions on high-throughput blockchains with ineffective fee markets. For instance, spam transactions contributed to Solana’s multiple network outages earlier this year. With significant economic activity on Solana, low transaction fees, and no way for searchers to express their willingness to pay for transaction order preferences, searchers are incentivized to extract MEV by sending an enormous amount of transactions to validators, effectively DOS’ing them. 

MEV Affects All Chains

MEV Is a Centralizing Force

MEV is a centralizing force on all blockchains. 

Block producers can extract MEV in two ways. Either they capture MEV themselves, or they sell reordering rights to others. 

The first case is highly centralizing at the validator level. Professional block producers are more effective in capturing MEV compared to solo validators. There are high returns to sophistication. Professionals can better invest in infrastructure and human capital to optimally capture MEV. They are also better positioned to secure exclusive order flow, giving them a larger set of transactions to build blocks on, or partner with searchers to gain exclusive access to MEV bundles. Moreover, institutions with larger balance sheets can take advantage of capital-intensive MEV strategies (e.g., cross-chain MEV). 

Therefore there are strong incentives to vertically integrate (validators that acquire and run their own searchers) and horizontally merge (combining different MEV searching strategies).

Under this scenario, professional validators will gradually accrue a greater stake in the network from their own profits. Furthermore, if in-protocol delegation is allowed (where users can delegate their tokens to other validators), other users are incentivized to delegate their tokens to these validators, further strengthening their lead.

In the second case, if block producers cannot efficiently run MEV strategies themselves, they can sell reordering rights to others. Ethereum’s roadmap effectively plans to enshrine this by separating block producers and block builders (Proposer-Builder Separation). This diverts MEV’s centralizing force from validators to block builders. However, several questions remain about how best to design this structure. 

And, in either case, MEV rewards are highly variable. This dynamic favors large institutions and validator pools that can socialize/smooth MEV rewards, as most users prefer stable and predictable income.

Inequality Between Validators Without MEV (Left) and With MEV (Right)

Note the distance between the green and red lines significantly widens with MEV extraction. Source: Flashbots

Note also that MEV profits will likely scale superlinearly. MEV extraction within a single block itself scales linearly with the proportion of hashpower/stake of the network. But in addition to this, the potential for capturing multi-block MEV increases as network dominance grows.

MEV Is Important for Economic Security

Yet MEV should not be left untouched. MEV revenues increase the security budget for a blockchain and must be extracted to keep blockchains secure. Both benevolent and malicious actors should attempt to extract as much MEV as possible. Otherwise, MEV left on the table gives malicious actors a clear subsidy to attack the protocol. 

This is not to say that blockchains should blindly increase MEV on the platform to increase economic security. As mentioned above, many types of MEV have negative externalities that detract from user experience. If this type of MEV continues to increase, users will simply leave the network, decreasing fees and economic security. Nonetheless, some amount of MEV is unavoidable. It is a consequence of user activity. 

A robust blockchain design should strive to democratize MEV extraction so that every validator can extract MEV at around the same rate. MEV redistribution systems can also help to improve economic security, as Chitra and Kulkarni’s recent research also suggests. Finally, designs should endeavor to allow new entrants to easily enter the field, nudging the field closer to perfect competition instead of oligopoly. 

MEV Reduces Costs

MEV is not all bad. It can also reduce costs for users. For instance, users who perform swaps on DEXs rely on arbitrageurs making sure that prices on DEXs are in line with CEXs’. In fact, a type of MEV, JIT liquidity, actually improves execution prices for traders. MEV also helps keep algorithmic stablecoins at peg, limit bad debt from accruing on money market protocols, and enable unique DeFi designs (e.g. Primitive’s RMM, Opyn’s Squeeth).

Opyn’s No-Liquidation Power Perpetual Relies on MEV Searchers 

MEV Creates Token Value

Validators earn income from issuance rewards + base transaction fees + MEV/priority fees. Issuance rewards are effectively a redistribution of ownership from passive holders to stakers. And base transaction fees should, for the most part, be minimal and trend to near zero. 

Thus, we argue the long-term value of L1/L2 tokens is rooted in monetary premium (e.g., BTC, ETH) and/or through MEV. Fundamentally, blockchains sell blockspace. Greater MEV opportunities -> greater demand for blockspace. 

Therefore, these platforms need to think carefully about the MEV they create and capture, lest they allow it to leak to other entities.

Below, we list some examples of designs by current protocols to capture and internalize MEV:

• Optimism - running MEV auctions. Optimism is an Ethereum L2. Currently, it runs a centralized sequencer that determines transaction order flow. Based on latest disclosures, Optimism aims to run MEV auctions that auctions off the right to reorder transactions within an N-block window to the highest bidder. Excess profits from these auctions will be directed toward protocol development via retroactive public goods funding.

• Aurora - managing and internalizing MEV order flow. Aurora is an EVM implemented as a smart contract on NEAR. Aurora used to offer gasless transactions until the network continuously got hit with spam transactions. Aurora recently announced an MEV program that manages MEV flow to reduce spam transactions and incentives for Sybil attacks. They are partnering with Kolibr.io to create an open and competitive market for order-flow payments, where transactions are checked for MEV opportunities before they move to public mempool.

• Osmosis - minimizing and capturing MEV. Osmosis is a Cosmos DeFi app chain that aims to mitigate MEV in the long term through threshold encryption. It also aims to implement a system that allows Osmosis to “MEV itself” - such as arbitrage after large transactions - with profits flowing to Osmosis stakers.

• Cosmos - creating cross-chain block space markets. Cosmos is an internet of blockchains and created the backbone of several important blockchains, including BSC, Polygon, and Cronos. But a common criticism is that the native token, ATOM, does not capture value from Cosmos’ contributions. Recently, members of the community put forth a new proposal that seeks to improve value accrual. One proposal includes an Interchain Scheduler, which creates a cross-chain blockspace market that generates revenue from cross-chain MEV activity.

MEV Will Increase

MEV grows with complexity, and we expect MEV to exponentially increase in the next decade. 

Even on Ethereum alone, there has been a step change in MEV growth since the release of Flash Boys 2.0 due to the growth of new protocols and primitives. The rise of a whole new class of assets (NFTs) and various financial experiments related to it also drastically expanded the vectors for MEV to arise. 

This trend is bound to continue. Ethereum’s gift as a limitless and permissionless smart contract platform is also a curse for more MEV to manifest.

The emerging multi-chain world supercharges this trend. MEV already exists on each chain individually. But because different blockchains have different trust assumptions, there will always exist additional MEV at the boundaries. 

There Are No Solutions, Only Trade-Offs

To better understand MEV dynamics, it is helpful to break down blockchains into their three essential elements:

• Virtual machine: VMs determine dimensionality - what a protocol can do. They range from extremely limited to Turing completeness. As mentioned above, greater complexity creates wider vectors for MEV. Allowing any developer to deploy smart contracts that can hold billions of dollars in value is both a boon and a curse. 

• Consensus mechanism: A fundamental property of blockchains is coming to consensus on valid transactions and the order they are executed. Cryptographic transcripts are created to prove that transactions are valid and show us the state of the world. But there are a lot of people trying to change the state of the world at the same time. There will be users that have a higher preference for their proposed state of the world and are willing to spend money to secure that preference.

• Blockspace markets: Blockspace is limited. Markets are required to allocate blockspace efficiently. Due to the factors mentioned above, if markets are designed poorly, users will instead secure order preferences off-chain.

We argue that, due to the above factors, MEV will manifest as long as blockchains allow anyone to deploy smart contracts and move value. 

Hence, we believe that instead of thinking about how to eliminate MEV, it is more productive to think about managing the different trade-offs in managing MEV across those three dimensions. We walk through some considerations for each factor below

Blockspace Markets

Perhaps the lowest-hanging fruit to managing MEV is designing an appropriate blockspace market. Small changes in design can lead to large changes in user experience and externalities (see: EIP-1559).

It is helpful to think of how different designs play out during major market events, such as an intense crypto sell-off or a popular NFT mint. Order preference matters most during these events. 

As the table below shows, most markets without an efficient auction mechanism incentivizes entities to spam the chain with transactions. For example, if winning a MEV opportunity can yield millions in profits, and the chain determines ordering on a “first-come-first-service” basis, searchers won’t hesitate to spam thousands of transactions to validators to secure that profit. 

Blockspace markets also determine the dominant MEV strategy, and therefore, where the “centralizing energy” of MEV is directed. 

Consensus Mechanisms

One of the more promising solutions to reducing toxic MEV is encrypting the mempool. How to effectively do so is still a subject of debate.

For instance, Osmosis, a DeFi app chain in Cosmos’ ecosystem, plans to reduce toxic MEV through threshold encryption. Transactions are encrypted once they enter the mempool, which hides the transaction information, preventing censorship/ordering. The private key used to decrypt the information is shared across all validators. The block is only decrypted after it is finalized. Shutter Network is also working on this solution for Ethereum rollups. On Ethereum itself, Flashbots has discussed using trusted hardware (MEV-SGX) instead of cryptography to achieve similar effects.

A key trade-off here is latency. Threshold encryption by committee is bandwidth-intensive, particularly for large and dispersed committees. Even using trusted hardware like SGX introduces additional latency into the system. These systems also introduce greater complexity, technological risks, and extra trust assumptions to the protocol.

Other consensus mechanism considerations include:

• Implementing single secret leader election to prevent MEV-incentivized DOS attacks

• Single-slot finality versus medium time to finality vs probabilistic finality

• Enshrining the separation of builders and proposers in the protocol itself (e.g., Ethereum’s Proposer-Builder Separation)

Virtual Machine

Limiting what a virtual machine can do reduces MEV. For example, the Bitcoin network is rather limited in what it can do and the breadth of applications built on top of it, so minimal MEV exists on the platform. 

Developers can also decide to create a permissioned platform, which allows the blockchain to focus on a specific vertical and helps control user experience. For instance, Osmosis and Sei are blockchains architected for DeFi. Developers need to submit proposals and get approved before they can deploy smart contracts. This drastically lowers the vectors where MEV can appear. 

The Current State of MEV

Flashbots’ role in shaping the MEV landscape on Ethereum has grown significantly. More recently, the crypto community has grappled with its role in order flow and block building after the US Treasury sanctioned Tornado Cash smart contracts and various related addresses. We describe Flashbots’ origins, its design in both pre- and post-Merge Ethereum, and why censorship concerns only recently cropped up.

Flashbots Origin and MEV-Geth

Flashbots is a research & development organization formed in July 2020 to mitigate the negative externalities of MEV. 

They launched “MEV-geth” in 2021, creating an off-chain private transaction pool and sealed bid blockspace auction for Ethereum. This allowed searchers to create and send “bundles” of transactions. Bundles allowed searchers to describe under what conditions a set of transactions should be executed. Notably, they allowed for atomicity. Either all the transactions go through, or none do. This is particularly beneficial for certain types of trades (e.g., sandwich attacks). 

Searchers sent bundles to a Flashbots relay. The relay was used to validate bundles and mitigate denial-of-service attacks. Valid bundles are then sent to miners. Miners can evaluate all the bundles they receive and create a block with the most profitable ones. 

The benefit of this architecture includes:

• Privacy - transactions are only publicly revealed after they are included in a block. Failed trades are not publicly exposed. Nor do they cost gas. Thus, searchers can be more confident in capturing MEV without the risk of other bots identifying and front-running the opportunity.

• Efficiency - the design creates an efficient market for MEV opportunities. Bids for the most obvious MEV opportunities will be incredibly competitive without consuming unnecessary resources on-chain. New entrants that can capitalize on longer-tail or niche opportunities can freely enter the market.

Important to note about the above architecture is that the design was not a trustless solution. Both relayers and miners could peer into the bundles that searchers submitted. They could have stolen bundles (and allegedly, did). However, reputational costs kept the system intact.

MEV in PoW

From January 2020 up until the Merge, Flashbots estimates the total gross profits of MEV opportunities from arbitrage and liquidations on a select number of DeFi protocols to be ~$675M. This figure should be considered the lower bound estimate of MEV, as it excludes sandwich attacks, NFT MEV opportunities, long-tail DeFi activities, etc. It also only counts Flashbots data - searchers could use other solutions too.

Source: Flashbots Explore

Additionally, Chorus One estimates that there is nearly $1 billion of profits made from sandwiching trades since August 2020. During the same time frame, Messari estimates that total Ethereum miner revenue was ~$28.9 billion. 

This suggests that, from 2020 until the Merge, MEV contributed to at least 5.8% of total miner revenue. 

Looking at extracted MEV by sandwichers gives some insight into the competitiveness of MEV: the top five MEV bots capture ~57.5% of total extracted MEV.

Boosting MEV in PoS

MEV-geth’s design does not work post-Merge. Note that in PoW Ethereum, only a handful of mining pool operators dominated hashpower. Any operator that “cheated” by stealing Flashbots bundles could be punished (e.g. exempted from future order flow). To most miners, it’s not worth losing this business.

Post-Merge, anyone can spin up a validator. The prior MEV-geth design doesn’t work. If you send bundles to solo validators, they would occasionally be incentivized to steal high-value MEV transactions as their own. Punishment does not deter. Furthermore, as mentioned previously, requiring that validators are both builders and proposers can act as a centralizing force - solo operators are unlikely to be as efficient in building optimized blocks as institutional ones.

Therefore, the concept of specialized “builders” emerged with the introduction of “MEV-boost”, Flashbots’ post-Merge MEV solution. Builders are entities solely focused on receiving transactions and building optimized blocks. Builders forward their blocks to relays. 

MEV-boost acts as a relay aggregator. It identifies the most profitable block and submits to it the block proposer.

MEV-boost Architecture

Source: Flashbots

Validators can opt-in to receiving full blocks from builders via relays and receive rewards. These blocks are blinded - validators cannot see the transactions until it has been sent to the network, and risk being slashed if they attempt to steal MEV. 

Ultimately, this architecture mitigates MEV’s centralizing impact on validators. Instead, the architecture nudges centralization to block builders.

Censorship and Filtering

This new architecture introduced new censorship chokepoints. Only a handful of entities run relays and builders, and some of those entities have to abide by local regulators. Notably, several relays and builders, including Flashbots’ own ones, filter out OFAC-sanctioned addresses. They will not include any transactions that interact with any smart contract or addresses specified by the US Treasury Department. 

In fact, only 3 relays consisting 12.5% of mev-boost market share do not censor transactions.

Why the headlines now? Censorship concerns were less prevalent in Ethereum when it was PoW, as mining pools acted as their own block builder. Even if Flashbots attempted to censor transactions, these miners could append censored transactions after Flashbots bundles.

50% of All Block Production were OFAC Compliant

Source: mevwatch.info

Overview of All Relay Operators

Future Trends and Open Questions

Cross-chain MEV

Suppose there is a price discrepancy between Uniswap on Ethereum L1 and Uniswap on Arbitrum. ETH is priced at $1,400 on Ethereum, but $1,300 on Arbitrum. How could one arbitrage this?

1. Official bridge: Buy 1 ETH on Arbitrum and use Arbitrum’s official bridge to move ETH to Ethereum L1, which takes 8 days. Hope that prices don’t move much by then (or maybe hedge with perpetual futures). Sell on Ethereum L1. 

2. Third-party bridge: Instead, use third-party bridges to move ETH to Ethereum L1. Currently, it takes anywhere between 5-20 minutes, depending on a user’s priority on speed, security, and return.

Source: Bungee Exchange by Socket

3. CEX: Some exchanges accept deposits directly from Arbitrum. The time to deposit and withdraw is variable, but roughly between 5-20 minutes as well. 

4. Proprietary balance sheet: Hold a mix of ETH and USDC on both chains, and conduct arbitrage between the two chains when opportunities arise. Rebalance every now and then to ensure sufficient inventory on both chains.

Clearly, option 4 will capture the opportunity virtually all of the time. But this strategy is also the most capital intensive option, favoring professional market makers and institutions. 

In fact, this dynamic creates incentives to collude across multiple chains. Executing cross-chain MEV is probabilistic. An institution could set up validators on a number of chains to minimize risks and more efficiently capture MEV. 

Open questions:

• How do vertically integrated entities play into this? Consider the potential synergies between Binance / Coinbase’s centralized exchange and on-chain operations (withdrawals, deposits, running validators, etc.). Or the synergies between trading firms and bridges (Jump <> Wormhole, Alameda / FTX <> Layer Zero / Stargate, etc.)

• Can bridges that have liquidity on multiple chains capture some of this revenue themselves? 

• How do centralized chains affect the decentralization of other chains? A BNB validator could be well-positioned to invest in Ethereum validators and gain greater stake in the network over time. 

Multi-Block MEV

Multi-block MEV was previously not feasible on Ethereum due to PoW. No one knew in advance who the next block proposer was. 

However, after the Merge, anyone knows who is going to propose the next 32 blocks in an epoch. There are currently over 445k active validators, so at first glance it does not seem likely that a validator gets selected to propose multiple blocks in an epoch, let alone multiple contiguous blocks. However, multiple validators are often under one entity or pool. Coinbase alone controls 13% of all active validators - giving them a ~39% chance of proposing at least 2 blocks in a row.

Probability of Proposing Multiple Consecutive Blocks

Note: p denotes share of total validator, k denotes number of consecutive blocks. Source: Alvaro Revuelta

Probably the biggest threat of multi-block MEV is manipulating TWAP price oracles to exploit money market protocols. Although not a major threat now, when TVL returns on-chain, the risks of these attacks grow.

Source: Twitter

But that’s just one vector, and we have yet to see what other maneuvers are possible with multiblock MEV, especially ones that last several blocks. Five consecutive blocks mean that an entity could control block production for an entire minute on Ethereum.

Open questions:

• What other attack vectors exist with multiblock MEV?

• What measures can be put in place to prevent the possibility of executing multiblock MEV?

PFOF and Transaction Flow Auction

Ultimately, user intent and transaction flow are the primary originators of MEV opportunities. We can therefore imagine a scenario where wallets or applications auction their transaction flow to builders. Wallets, applications, and infrastructure providers are well-positioned to benefit from aggregating and auctioning order flow, giving them another avenue for monetization. 

Open questions:

• How to design an auction market that prevents greater centralization of block builders and searchers with exclusive order flow?

• How much would validator staking yields contract if wallets and applications auctioned off their transaction flow, returning MEV revenues to users instead of flowing to stakers?

Concluding Thoughts

At first glance, the outlook appears bleak. It may seem like crypto’s market structure is trending to be more similar to traditional finance: transactions and trades enter a black box, managed by privileged intermediaries, and results come out the other end.

Fortunately, we see a step change in the number of people engaged in MEV, from debating what is fair and researching appropriate market designs, to actually implementing solutions that mitigate MEV across the supply chain. 

This is a long report, and we only scratched the surface of MEV. We list some additional resources below for readers interested in diving deeper in certain topics.

If you’d like to reach out and discuss these topics with us, please do not hesitate to reach out.

Acknowledgements

Special thanks to Flashbots, Shutter Network, Alkimiya, Bryan Zheng, snoopy, and defi guy for inspiration and feedback for this report.

Author

Steven Shi is an Investment Partner for Amber Group's Eco Fund, the company's early-stage crypto venture fund. 

Additional Resources:

Reading Materials:

• Flash Boys 2.0 - Daian et al.: Seminal report investigating MEV and its impact on Ethereum

• Ethereum is a Dark Forest - Paradigm: Riveting first-hand account of avoiding generalized frontrunners on Ethereum

• Ethereum Blockspace - Who Gets What and Why - Paradigm: First principles based approach to understanding blockspace markets and MEV

• MEV … wat do? - Phil Daian: Arguing why MEV is fundamental and how to manage MEV

• MEV Manifesto - Delphi Digital: Deep dive into MEV design and solutions on Ethereum

• Optimism’s MEVA Proposal: Optimism’s original proposal of MEV auctions on L2

• MEVA (What is it good for?) - Ed Felten: Argument for why MEV Auctions are harmful to user experience and makes centralization worse

• Formalization of Cross-Domain MEV - Obadia et al.: Investigation and formalization of cross-domain MEV

Repositories:

• MEV.wiki: Public wiki for learning about MEV

• Flashbot’s MEV Research Vault: repository of MEV resources

• List of MEV Github codes/repos by 0xmisaka

• The 0 the 1 Guide for MEV by Blockchain at Berkeley

• AwesomeMEV by 0xemperor

Data:

• Flashbots: Documentation and data dashboard

• Mevboost.org: tracking MEV-boost relays and blockbuilders

• EigenPhi: MEV data dashboard

Disclaimer

The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.

Introduction

Over the past decade, blockchains have risen to become the leading form of distributed ledger technology. Despite their current dominance, however, a growing number of projects are proposing alternative solutions to solve certain scalability issues inherent to blockchains. One of these proposed technologies is the DAG, or Directed Acyclic Graph, which has been promoted by a number of alternative layer 1s as a more efficient solution than traditional blockchains. However, there is still a lot of confusion in the web3 space about what exactly a DAG is and how it compares to existing blockchain technology. By clearly explaining how DAGs work and the ways they can be used within crypto applications, this research report aims to educate readers on alternative layer 1s which use DAG technology, while providing a framework to classify different uses of DAG technology and improving knowledge of how they operate.

What exactly does “DAG” mean?

The acronym “DAG” stands for Directed Acyclic Graph. For those unfamiliar with computer science concepts, this may be a mouthful, so we’ve broken down each term below:

- Directed: The data structure  only moves in one direction 

- Acyclic: The data structure cannot return to a previous state from the current state; it is “non-cyclical”

- Graph: When visualized, the data structure appears as an interconnected set of relationships between vertices

What exactly does a DAG structure look like? The best way to determine whether a data structure is a DAG or a blockchain is by checking how the data is ordered. Ordering refers to how we sequence transactions in time. Because our understanding of how time works is linear, we traditionally think about events occurring in a specific sequence. Humans typically all agree on a time, and we all agree events happen sequentially.

The above diagram is an example of “total ordering”. Events will always have an exact order based on which event occurred first. In a set of events that are totally-ordered, we know the exact total order of every one of the events. Using a total order, Event A comes first, then Event B, and then Event C. This is how events are recorded in a blockchain.

However, a total ordering of a distributed ledger may limit scalability in terms of throughput and latency. We may look to “partially order” the ledger to solve some of these issues. This is where the exact ordering of each event in relation to every other event is not known. Rather, only the order of related events is known. We aren't sure of the order of all events, but we can be sure about the order of events which rely upon one another. 

For example, we can say we are certain that Event B happened before Event C. However, in a partially ordered system, we are not sure when Event A occurred. It could have before, after, or even between these events. Event A is unrelated to the other events.

Generally speaking, why would we want to know how these transactions are ordered? The purpose of ordering events is so we can figure out how one event caused another event to happen. Partial ordering has no concept of time, so how can we sequence events without struggling to figure out the times at which each event occured? 

“Causal ordering” is the answer to this problem. Causal ordering is a partial order and does not take into account when the events occurred, but rather, it only takes into account the cause and effect relationship between events. If we can determine which events caused other events, we can order the events.

An example of causal ordering can be seen above. It may not be possible to figure out when these events exactly occured, as they have no timestamps. However, we can see that A caused B to happen, and that B caused C and E to happen. It can then be derived that A eventually led to D and F to occur. Because C caused D and E caused F, we can determine the causal order of C in relation to D and the causal order of E in relation to F. However, we do not need to determine the order of C in relation to E or F, or the order of E in relation to C or D. Not all events have causal relationships to each other and are only partially ordered, and that is okay because unrelated events do not need to be ordered in relation to one another. 

By using causal ordering, we are no longer constrained to a “chain of events”-like structure, allowing us to build a DAG structure instead. Events which have nothing to do with one another do not need to be ordered at all. A distributed ledger that has causally-ordered transactions is structured as a DAG, while a totally-ordered ledger is structured as a blockchain. Because causal ordering allows certain transactions to skip sequencing entirely, a DAG-based ledger may offer a scalability advantage in terms of throughput and latency compared to a blockchain-based ledger.

Many layer 1s today tout DAG technology as a differentiating factor in their design, but not all of them use DAGs to enable causal ordering. Unfortunately, there is no existing framework to subdivide the DAG space. For the purpose of this paper, we will figure out what truly makes a DAG layer 1 and try to group relevant projects in two categories based on how their transactions are ordered. First, we discuss layer 1s which use DAGs to process their transactions, but whose ledgers are totally ordered. Then, we will cover layer 1s whose ledgers are causally-ordered and which use DAGs as the data structures in which they store events and transactions. It is important to differentiate between protocols which use a DAG-based ledger and protocols that use a DAG as part of their transaction processing, as the latter may not gain the same increase in transactional throughput.

Blockchains which use DAGs

How do certain totally-ordered blockchains use DAGs?

Fantom is an example of a blockchain that utilizes a DAG to speed up its consensus protocol while outputting the results in a traditional, totally-ordered blockchain structure. If a blockchain claims to be DAG-based, it is commonly the case that the layer 1 is using a DAG-based consensus mechanism rather than a DAG-based ledger.

Fantom: a gossip-based blockchain that uses DAG technology

Fantom’s consensus protocol, Lachesis, forms a DAG-based structure called the Opera Chain. The Opera Chain network is made up of nodes, which are computers running Fantom’s software. The building blocks of the Fantom’s consensus mechanism are called “event blocks”. Fantom’s concept of blocks is different from the term “blocks” as we commonly refer to them. 

At a high level, nodes create event blocks, which form a DAG. Fantom uses a DAG of event blocks and generates a blockchain (a chain of confirmed blocks).

Fantom stores data in event blocks which contain financial, technical, and other information. Event blocks are data structures created by a single node to share transaction and user information with the rest of the network. In the picture above, we can see the DAG structure, with event blocks spawned by nodes represented as circles. It’s not represented above, but every node is producing event blocks. Every time nodes exchange transactions, they create a new shared event block. Event blocks are shared throughout the network. When one event block communicates to another, the event block that was communicated to stores the prior event block’s transactional information, which then creates a new event block. This information is then communicated to the next event block. Transactional information is hashed, and each event block contains a hashed value of one or more previous event blocks. This causes the data to be immutable, as it is not possible to modify or delete previous event blocks without changing their hashes.

The green highlighted areas of the Opera Chain DAG are event blocks that communicate with one another until they find a single event block called a “Clotho” block (the blue block in the above graph). The Clotho block contains a “flag table,” which is a data structure that saves all the connection data between specific event blocks. To be considered a Clotho block, the Clotho must have a supra majority of more than ⅔ connections to a previous set event block. The Clotho Blocks communicate with other Clotho blocks in the DAG Structure, using the flag table data structure.

Based on the information provided from communicating between each other, Clotho Blocks come to a consensus to create another event block, called an “Atropos” block (green blocks in the above chart). Each Clotho block has a specific timestamp when it was created. If at least ⅔ of all nodes have the same time, the Clotho block becomes an Atropos block. These Atropos blocks are strung together to make up the “Main Chain.” The Main Chain can be viewed as a blockchain within the DAG structure. Each Atropos is connected to other Atropos blocks, sharing the information gathered from all other event blocks, which is gathered from the Clothos blocks.

This Main Chain contains a total order of all the events. All participating nodes have a copy of the Main Chain, and can search for the historical position of its own blocks in the Lachesis consensus protocol. Nodes do not need to store all the information of every event block and can just reference the Main Chain. This leads to fast access to the ordering of the previous events.

It is important to understand that not having the correct recorded time of transactions and partially ordering transactions prevents most DAG protocols from incorporating smart contracts, since smart contracts typically require sequencing of all transactions which interact with them in order to operate properly. This can be seen with IOTA and Avalanche’s X-Chain. In contrast, the Opera Chain is constructed to allow for the correct time and ordering of transactions. However, while the Fantom Opera Chain does offer an increase in transaction throughput compared to Ethereum Mainnet, it may not offer the same latency and throughput as other causally-ordered DAGs. This is due to the Ethereum Virtual Machine (EVM), which Fantom’s Opera Chain uses, being a limiting factor in itself. Fantom’s Opera Chain does make it possible to remove some of this bottleneck by allowing the Cosmos SDK to be built on top of Lachesis instead of the EVM. In the future, Fantom plans to create the Fantom Virtual Machine (FVM), which should further improve scalability. Since Fantom’s rise, new Layer 2 scaling solutions have been built upon Ethereum. Fantom’s EVM layer is losing relevance in this wave of new scaling solutions, and it makes sense for Fantom to focus on the FVM to exceed the limits of what is currently possible with its existing solutions.

DAGs that have a causally ordered output

When most people say "DAG," what they're actually referring to is a causally-ordered distributed ledger. How do these DAGs work, and what differentiates them from their totally-ordered counterparts? Avalanche’s X-Chain, IOTA, and Sui are examples of distributed ledgers which have a causal order.

Avalanche X-Chain, a UTXO-based DAG.

Bitcoin introduced the unspent transaction output (UTXO) model to record the state of transfers between wallets. Each UTXO is a chain of ownership where the current owner signs the transaction to transfer the UTXO ownership to the address of the new holder. In the context of UTXO, Bitcoin would best be described as a blockchain, while Avalanche’s X-Chain would best be described as a DAG. The X-Chain uses the Avalanche consensus protocol, which is causally-ordered. If you send someone AVAX, you are using the X-Chain. To understand how Avalanche’s DAG works, the first step is understanding how the DAG structure of Avalanche is formed.

There are four major building blocks that make up the Avalanche consensus: Slush, Snowflake, Snowball, and Avalanche. Separate from Avalanche is Snowman, which we will discuss later. Let's first look at how Slush consensus operates. The Avalanche network consists of many nodes. Each node has three states: neutral, true, and false. This can better be represented in terms of color: uncolored, blue, and red.

Every node starts off uncolored, where it faces a decision to vote true or false (red or blue). Once a color is chosen, the node communicates with many other nodes in the network. If those nodes do not yet have a color, they will adopt the color of the node which communicated with them. If a majority of the nodes have the same color, the original node keeps its vote the same. If a majority of the nodes are a different color, the original node will flip its vote to that color.

Multiple rounds of communication will occur between nodes until all the nodes are all on the same page. The goal is to have everyone reach consensus on what the color is. The nodes that have the most of a certain color should dictate what the correct color is. This concept is the general building block of Avalanche and everything builds from it. 

The second building block of Avalanche is Snowflake consensus. This is when memory is implemented into the nodes. Each node is given a counter. For every Slush communication which returns the same color, the counter increments. Everytime the node flips its color, the counter resets. Once the counter reaches a high enough number, it will lock its state and prevent the node from changing color. This helps solidify what the true color is.

Nodes start to gain a larger memory in the third building block, Snowball. Snowball builds on top of Snowflake by adding a state of confidence. Rather than changing color based on the nodes it communicates with, it will look back on all of its own color changes and will change its color based on the confidence state of the node, as measured by its vote change history.

This all leads up to Avalanche. Avalanche is an append-only (transactions add on to previous ones) DAG. Avalanche can function without having a DAG structure, as seen with the linearization of Avalanche on the Contract chain (C-Chain) and Platform chain (P-Chain). Team Rocket, the entity behind Avalanche consensus, felt that the DAG architecture was superior to a blockchain approach because it allowed voting to be more efficient, as one transaction is a vote for all transactions it is appended to. 

The Avalanche consensus consists of multiple Snowball instances to build a dynamic DAG of all known transactions -- each Snowball instance is a vertex in a graph. A vertex is like a block in a linear blockchain. It contains the hashes of its parents, and it contains a list of transactions. Avalanche consensus builds on top of Snowball, and the idea of confidence counters but applies it to nodes on a DAG. Instead of red and blue decisions, as previously discussed, nodes in the Avalanche consensus reach a consensus on whether a transaction is correct or if it conflicts with another transaction. Each transaction links onto a parent transaction which all links back to a genesis vertex. A transaction can have child transactions, which reference it and all of its parents. A genesis vertex is needed as one transaction is needed to act as the basis for the rest (IOTA also has a genesis vertex); this is important, as all append-only transactions need to add onto something. However, one unsolved problem caused by directly applying Snowball to a DAG of nodes is handling conflicting transactions, or double spends. Avalanche builds upon Snowball by adding the concept of “chits”. When a confidence threshold is reached, a counter called chit is added to a transaction, giving a value of “1.” If it was not given a value, the chit counter is “0.” The node will count the sum of chit values as an additional confidence method, similar to Snowball. The sum of chits is then used by nodes to determine a confidence in not just the specific transaction, but also in all of its children (new transactions appended onto the node).

Avalanche is capable of taking the building blocks of Slush, Snowflake, and Snowball and adapting them to linear chains. Avalanche does this for its Snowman consensus, which is completely separate from Avalanche consensus. Snowman consensus is account-based, which differs from Avalanche’s UTXO model. The Snowman consensus is used for the Platform chain (P-chain) and Contract chain (C-chain) of the Avalanche networks. The protocol is the same as described above, but each vertex only has one parent instead of multiple. This gives a total ordering of vertices. This causes the overall structure to be a blockchain, not a DAG. This is useful for applications where it is needed to know if a transaction came before another transaction, and also easily supports smart contracts.

The Avalanche consensus protocol is amazing for monetary transfers, and can be applied to various other protocols. It was once used as the pre-consensus mechanism for Bitcoin Cash before being hard forked into its own project, Bitcoin ABC. The DAG structure of Avalanche provided increases in transaction speed, and the lack of smart contracts provided no hindrance to Bitcoin Cash, as it has no need for such applications. In a world of payments, disregarding smart contract needs, Avalanche highlights how a DAG-based ledger can scale efficiently. 

IOTA, a transaction-based DAG using Proof of Work

IOTA’s causally ordered structure is Tangle, which is a network of parallel-processed transactions. The Tangle is the data structure behind IOTA which forms the DAG. IOTA’s tangle holds transactions, where each transaction is represented by a vertex in the graph. When a new transaction joins the Tangle, it chooses two previous transactions to approve, adding two new connections to the graph.

In the diagram below, transaction G approves transactions E and F. Transactions hold information such as “Alice gave Bob ten IOTA coins.” Unapproved transactions are called “tips.” Transaction G is a tip, because it has not been approved yet. Each incoming transaction’s goal is to connect to two tips to approve. There are strategies to choose which two tips to approve, but the simplest is to choose two at random. For new transactions selecting tips to approve, this process is highly scalable.

The red transactions, I and G, are unapproved tips as they do not have any other transactions connected to them. Every other transaction is approved, as each has a transaction connected to it.

However, another important concept that strengthens the DAG architecture of IOTA is the implementation of weights. How can we know if a transaction is trusted or not? In a typical blockchain, it is common to see how many confirmations a blockchain has. IOTA implements a similar technique by seeing how much weight a transaction has.

The weight of a transaction signifies how much work a node has done to create this transaction. Each transaction has an initial weight, and the value can be 1, 3, 9, etc (n3). A higher weighted transaction tells us that the node spent more work on the transaction. Each transaction also has a cumulative weight; this is a score of its own weight plus all transactions which directly or indirectly approve it. Let’s dive into how this mechanism works.

Each transaction has its own weight assigned to it and a cumulative weight that increases every time a tip is added onto the tangle.

In the figure above, we can see that transaction D is directly approved by transactions E and H, while also being indirectly approved by G and I. The cumulative weight of D is 3 + 1 + 3 + 1 + 1 = 9, which is the sum of its own weight plus the weights of E, H, G, and I.

A transaction with a larger cumulative weight is more important than a transaction with a smaller cumulative weight. Each new transaction added to the tangle increases the ancestors cumulative weight by the weight of its own transaction. Older transactions grow in importance over time. The use of cumulative weights avoids spamming and other attack vectors, as it is assumed no entity can generate many transactions with a large enough weight in a short period of time.

Despite being highly scalable, similar to Avalanche’s X-Chain, this method makes it nearly impossible to integrate smart contracts. In an effort to compete with other smart contract chains, IOTA is releasing a separate smart contract layer, dubbed “Assembly.” Assembly is a totally-ordered layer 2 which aims to support both EVM and WASM smart contracts.

Sui, a smart contract DAG using Proof of Stake 

While Sui was included in the causally-ordered section of this report, it actually employs both total and causal ordering. Sui’s transaction processing architecture can be viewed as two parts: one part for dependent transactions that are totally-ordered and executed sequentially, and one part for independent transactions that are causally-ordered and executed in parallel. Transactions that are dependent utilize Sui’s Narwhal and Bullshark protocol. Narwhal is a DAG-based mempool, while Bullshark is a consensus protocol that integrates with Narwhal to reach consensus. Dependent transactions only have to be totally-ordered with other transactions they depend on. However, Sui has another method which it employs when transactions are entirely independent. For these transactions, Sui does not use Narwhal and Bullshark. Instead, it uses a method called Byzantine Consistent Broadcast (BCB). Using this method, there is no need for global consensus, so transactions are processed and written to the ledger nearly instantaneously. 

Whereas most distributed ledgers are centered around addresses, Sui’s ledger is centered around “objects”. It is important to understand that objects can be NFTs, dapps, tokens, or basically anything you can build as a smart contract on a traditional blockchain. Every object has an assigned “owner” property, which states who can interact with the object. An object can have 4 distinct types of ownership. The first type is an object owned by an address, so that a user can possess something on Sui, such as holding coins in their wallet. The second type of ownership is an object owned by another object, such as a token object being held inside of a multisig smart contract object. The third type of ownership is an object being immutable, essentially having no owner. Nobody can change an immutable object, but anybody can interact with it. The fourth and final type of ownership is an object that is shared. Anybody can read or write to a shared object, an example of this being an AMM.

No matter how the transactions are ordered, all transactions are processed in parallel on the same network. 

Transactions, which are simply a change to the metadata of a specific instance of an object, take objects as inputs and read, write, or mutate these inputted objects to produce freshly-created/updated objects as outputs. Each object knows the hash of the last object that produced it as an output. 

Objects can either fit into Sui’s totally-ordered or Sui’s causally-ordered consensus architecture. Total ordering must be present in transactions with shared objects, as any user’s transaction can change the object they are interacting with, so the transaction ordering does matter. However, if an object is owned by an address, only that address is capable of changing it in a transaction. Therefore, transactions written to this object have no relation to any other transactions, which means that it can use Byzantine Consistent Broadcast. While the combination of Narwhal and Bullshark produces a fast consensus architecture, BCB is nearly instant.

Sui’s ledger is an “object store” or “object pool” whose data is stored in a DAG. The act of sending USDC, for example, is the act of updating the “owner” attribute of an object, which has no effect on the other objects.

Sui’s ledger is an “object store” or “object pool” whose data is stored in a DAG. In this DAG, the nodes are objects, while each arrow in the diagram represents a transaction which updates the attributes of a given object or objects. Not represented in this figure is the Genesis transaction, which is a transaction that takes no inputs and produces the objects that exist in the initial state of the system. 

While other distributed ledgers with a DAG structure have failed to offer an integrated smart contract solution, Sui seems to have solved these roadblocks with an innovative approach. Sui’s smart contract language, Move, naturally supports the object typing and parallel execution of Sui’s transaction. Without Move, Sui’s smart contract architecture may not have been possible.

Key Takeaways

Causal ordering of transactions seems to offer a number of advantages versus total ordering, in terms of both speed and throughput. However, the lack of ordering creates issues when trying to create applications which require strict time-based ordering, and many projects have been unable to properly get smart contracts to work on their DAG architecture. Fantom’s totally-ordered, blockchain-like structure allows for EVM and smart contract support. Despite having a totally-ordered output, the developers of Fantom still have found ways to optimize their layer 1 using a DAG-based consensus mechanism. Avalanche chose a different method and created a separate consensus mechanism, Snowman, to support the EVM and add easy-to-develop smart contract support. IOTA also chose another method, and is creating the framework to easily deploy blockchain instances on top of IOTA to support the EVM, effectively creating a totally-ordered layer 2 infrastructure. Sui’s unique design seems promising, and transactions can both be totally-ordered or causally-ordered as needed, allowing for smart contract capabilities on the network while also reducing latency.

Sui is the latest DAG-based layer 1, but it seems to differentiate itself enough and iterate on flaws previously seen in the space, to a point where DAGs as a structure may truly gain adoption as a distributed ledger. Even if causally ordering transactions does not become the future, DAG-based technology helps scale existing blockchains. While DAGs as a scaling method may not be optimal for every scenario, it has seemed to work well for Avalanche’s X-Chain and IOTA in terms of latency and throughput. However, the lack of smart contract support lessens its importance in the current competitive landscape, especially in the age of layer 2 roll-ups and off-chain Zero Knowledge scaling solutions. While most DAG-based ledgers do reduce latency with a low loss of decentralization, both blockchains and DAGs as distributed ledgers are designed where every node on the network needs to process every transaction. This is one of the biggest problems any distributed ledger needs to tackle to be fully scalable. Sui was able to combat this with its unique design of BCB, allowing for transactions to skip consensus. This is not necessarily a key aspect for every DAG-based architecture though, and should not be used as an argument to say all DAG-based architectures are better than all blockchain-based architectures. However, a DAG is just a data structure at the end of the day, and we are seeing use cases of it across distributed ledger technology. Sui’s Mysten Labs is currently working with Celo, a layer 1 blockchain, to implement the Narwhal architecture into its mempool. Narwhal is a mempool protocol which itself is designed as a DAG. Everything about Celo as a ledger is a blockchain, but it has achieved performance improvements using a DAG as a component in its backend. It’s possible that the argument of DAG vs. blockchain ledgers is made less relevant by more modern scaling solutions. This paper’s purpose is to inform readers about architectures that currently exist. With applications like Narwhal, this may be where we see the most usage of DAG’s going forward. It is impossible to predict how widely used DAGs will become in distributed ledgers, but they certainly appear to be growing in relevance as a technology.

About the author

Robert McTague is an Investment Associate for Amber Group's Eco Fund, the company's early stage crypto venture fund. Prior to joining Amber, he graduated with a bachelor’s degree in electrical engineering and worked for a DeFi company where he focused on business development. Outside of his studies, he developed a passion for developing smart contracts and learning about the web3 space as a whole. 

Disclaimer

The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.

Introduction

Over the past two years, there has been an explosion of new smart-contract-enabled distributed ledgers which aim to address the perceived shortcomings of Bitcoin and Ethereum. These “alt layer 1s,” or “alt L1s,” as they’re commonly referred to, typically offer new architectures and make different design trade-offs to increase the scalability and usability of distributed ledgers. A number of these alt layer 1s, such as Solana and Avalanche, have garnered much attention for their growing user bases, expanding ecosystems, and (mostly) high-quality user experiences. As a result, Solana, Avalanche, Near, and others have all raised hundreds of millions of dollars from prominent investors to become the core infrastructure of a next-generation internet.

Recently, there has been increasing discussion about two highly anticipated distributed ledgers: Aptos and Sui. Aptos and Sui have not yet launched their mainnets, and few people other than developers have used their networks. Even so, they have still managed to generate excitement from crypto enthusiasts and raise substantial capital from investors, making their upcoming releases feel like the arrival of two new top-tier L1s.

At least part of the excitement surrounding Aptos and Sui comes from the fact that they were both founded by former members of Facebook’s distributed ledger division, Diem, a.k.a. Libra. Given the impressive professional backgrounds of both teams and the relevance of major L1s within the broader crypto industry, it’s no surprise that both Aptos and Sui have gotten so much attention. 

Both of these layer 1s trace their origins to Facebook, and both use the new smart contract programming language, Move, so you may think they are just two versions of a similar design. However, despite these similarities, their underlying architectures are actually quite different from one another. This post will cover the mechanics of how each of these new distributed ledgers works at a high level and discuss what it means for the future of these two new entrants to the layer 1 landscape.

Aptos’ Blockchain Architecture vs. Sui’s DAG Architecture

You may have noticed that we’ve been using the phrase “distributed ledger” instead of “blockchain” throughout this post. That is because Sui’s distributed ledger is actually an “object store”, the data of which is recorded as a directed acyclic graph, or DAG. Nearly all of the mechanical differences between Aptos and Sui boil down to the fact that Aptos records its ledger as a blockchain, while Sui records it as a DAG. These are simply two different flavors of distributed ledger technology (DLT), but their differences have important implications for their consensus mechanisms, transaction ordering, transaction execution, and overall scalability. 

We will first describe Aptos’ architecture, which contains many common design elements of a typical blockchain, and then we’ll describe how Sui’s DAG operates differently from Aptos and most blockchain architectures. 

Address-centric vs. object-centric

Arguably the most important difference between these two designs has to do with being address-centric vs. object-centric. 

As is the case with most blockchains, almost all activity on Aptos involves changing data associated with addresses. The overwhelming majority of transactions simply update the balances of assets held by a given set of addresses. One implication of this design is that each simple transfer (i.e. Alice pays Bob) requires two updates to the ledger: one for the sending account and one for the recipient account.

“Alice pays Bob 1 USDC” would look something like this on Aptos. The ledger updates both Alice’s USDC balance and Bob’s USDC balance.

Zooming out, we can visualize how a large number of these transactions appear in a traditional blockchain ledger. Alice’s and Bob’s transaction is one of many transactions inside of one block within the universal ledger which contains all historical transactions for all assets, as shown below:

In contrast, almost all activity on Sui involves changing the data associated with specific “objects”, which can be a token, smart contract, or other on-chain entity. Each object on Sui has a list of attributes, including the address of its owner (or shared ownership attributes), read/write properties, transferability properties, functionality within a dapp/game, etc. In this design, most simple transfers (e.g. Alice pays Bob) require only one update to the ledger: a change to the “owner” attribute of a specific object.

“Alice pays Bob 1 USDC” would look something like this on Sui. The ledger makes one update: a 1 USDC object with Alice listed as its owner would have its owner attribute changed to Bob.

However, certain simple transfers may need to divide an existing object into two objects prior to processing the transfer. “Alice pays Bob 0.5 USDC” might require a transaction creating two 0.5-USDC objects with an owner attribute of “Alice” (green arrows), and a subsequent transaction to change the owner attribute of one of the 0.5-USDC objects from “Alice” to “Bob”.

If we zoom out and try to visualize many Sui transactions, it becomes much easier to understand exactly what Sui’s directed acyclic graph actually is.

Every row in the diagram represents the full transaction history of a specific object. For example, the gray row shows the entire transaction history of one specific USDC token, with the most recent transaction being “Alice paid Bob 1 USDC”. Each arrow in the diagram represents a transaction - a change to the metadata of a specific instance of an object. For most simple transactions, the change will be to the “owner” attribute of a specific token, but the Move programming language allows objects to have many other attributes which can also be changed. Additionally, objects can create other objects (e.g. a smart contract object can issue an NFT object), and new objects can be created and even deleted by transactions. The ability to delete objects can help alleviate “state bloat”, where the ledger becomes too large to easily store on a computer. Notice that the transaction histories move in one direction only and do not return to previous states - this is where the “directed” and “acyclic(al)” part comes into play. The “graph” part refers to the overall diagram that results from performing many transactions on many objects. Sui’s DAG is also referred to as a global “object store” or “object pool”.

This object-centric method of recording transactions in a DAG rather than in a blockchain results in significant downstream differences in transaction processing for Sui and Aptos. Why? Because transactions in a DAG are not inherently linked to one another - each asset essentially has its own separate ledger which can be updated independently from every other asset’s ledger. In a blockchain, every transaction must update one universal ledger which contains every asset’s entire transaction history, and this difference has important implications for transaction ordering and batching.

Transaction ordering and batching

Aptos’ design follows another defining characteristic of blockchains: all transactions must be ordered and batched into blocks by validators before being written to the single universal ledger. This dual process of ordering and batching requires momentarily pausing the state of the universal ledger to record groups (i.e. blocks) of transactions. It also requires that validators achieve consensus on the ordering of every transaction written to the ledger, which can introduce additional latency relative to a design which does not require the ordering of every transaction. Having said that, transaction execution and dissemination on Aptos are performed continuously by validators in the background, even if the written state of the ledger is momentarily paused.

In Sui’s design, because each object essentially has its own independent ledger, a significant portion of transactions submitted at any given time do not need to be sequenced at all. The only transactions which require ordering are those which view or alter attributes of the same object(s) as another transaction. If two or more transactions are sent to a validator at exactly the same time and don’t touch any of the same objects, they can be written to the ledger simultaneously. Additionally, writing one of these transactions to the ledger does not require pausing the entire ledger state - it only requires pausing the ledger of the specific object being impacted by the transaction.

The way this works in Sui is through “shared objects”, objects which can be viewed and/or altered by any Sui address. If an object is designated as a shared object, then any transaction which reads/writes to this object must pass through the Narwhal mempool protocol to be sequenced and then be processed by Tusk, a high-performance BFT consensus protocol, to finalize this sequencing. For objects which are not shared, known as “single owner objects'' or “uniquely owned objects,” transactions do not need to be sequenced by validators and sometimes do not to be sequenced at all. This would apply to many simple transfers between addresses. We can visualize this using our diagram from before:

The green and orange transactions highlighted on the right side of the chart are not related to one another, so they do not need to be sequenced at all. They can simply be written to the ledger without achieving consensus on the order in which they occurred. Conversely, the blue and green transactions highlighted at the top center of the chart interacted with the same object (the fifth version of the blue object) so they would need to be sequenced. If the blue object happens to be a “shared object”, the transactions would need to undergo sequencing via Narwhal and consensus via Tusk.

In contrast, Aptos’ blockchain architecture requires all transactions to undergo sequencing, even if they do not interact with the same asset(s), as shown above. The written state of ledger will pause momentarily so all four transactions can be written to the ledger in the same batch (block) of transactions. Transaction execution and dissemination, however, are performed continuously in the background.

On Sui, because it uses an object-centric model, assets owned by the same person are independent of one another - each one is a separate object, even if they are the same type of token. Therefore, many (but not all) transactions involving the same type of token from the same owner do not need to be sequenced.

For example, if Alice owns 2 USDC, what she actually owns are two separate 1-USDC objects which each have an owner attribute of “Alice”. If she sends 1 USDC to two separate people (e.g. Bob and Frank), these transactions do not need to be sequenced. In an address-centric model, these transactions must be sequenced in order to confirm that Alice has a sufficient USDC balance to pay for both of her requested transactions.

We can visualize different examples of related and unrelated transactions on Aptos and Sui to better understand how they each handle sequencing differently.

In an address-centric blockchain, the two transactions above are considered related and must be sequenced because they interact with the same address (Alice’s). One of the transactions must be written to the ledger after the other to make sure that Alice’s address has a sufficient USDC balance to pay both Bob and Frank. The order in which Bob and Frank get paid (or don’t get paid, if Alice’s balance is too low) is determined by the validators of the blockchain via its mempool and consensus protocols.

In an object-centric blockchain, the transactions from the previous diagram (Alice pays 1 USDC each to Bob and Frank) are considered unrelated and do not require sequencing. There is no “balance check” required of Alice’s address - she simply requests to change the owner attribute of two independent objects she currently owns, so both of her requested transactions can be written to the ledger in parallel.

However, let’s say that Alice wants to send 0.5 USDC to both Bob and Frank. In this case, Alice will need to divide a 1-USDC object into two 0.5-USDC objects and change the owner attribute of each of them, for a total of three transactions. In Sui’s object-centric model, the “split” transaction (red arrows) is considered related to the two “send” transactions (green arrows) because the split must be written to the ledger prior to her payments to Bob and Frank, so sequencing is required. However, after the split occurs, the two “send” transactions to Bob and Frank can be written to the ledger simultaneously, as in the previous example. Additionally, there is no need to sequence any of these three transactions via the mempool and consensus protocols because at no point are two transactions interacting with a shared object.

Looking at a different object-centric example, let’s say Alice and Jill both want to send a transaction to a shared object: a liquidity pool, for example. In this case, because Alice’s and Jill’s transactions interact with the same shared object, they do need to be sequenced by validators via the ledger’s mempool and consensus protocols.

Finally, we can consider two transactions which are unrelated in both an object-centric and address-centric model: Alice pays Bob and Jill pays Frank. In an address-centric model, these unrelated transactions still need to be sequenced before they are written to the ledger. In an object-centric model, they do not need to be sequenced and can be written to the ledger simultaneously.

Aptos’ design does include optimizations to more efficiently sequence transactions. Indeed, Alexander Spiegelman, who works as a Blockchain Researcher for Aptos Labs, was a co-author of the original paper describing the Narwhal mempool protocol and Tusk consensus protocol. Aptos’ current ordering mechanism, DiemBFTv4, follows very similar principles as Narwhal & Tusk: simply put, it separates transaction sequencing from the consensus process to increase throughput and decrease latency. The way this works is that both Narwhal and DiemBFTv4 require the leading validator at any given time (the leader) to send only metadata of a group of transactions as a proposed block to other validators. This metadata is just a hash or “digest” of the group of transactions. The metadata also contains the ordering of the transactions within the proposed block. In most existing layer 1s, the leading validator proposes transactions themselves to other validators. Sending only metadata of transactions makes blocks far smaller and faster to download and process for the other validators in the network, improving throughput and latency.

To be clear, all validators continuously create blocks in parallel and broadcast them to other validators, but they are handled and stored separately from the metadata and not used during the actual sequencing process. After sequencing has been agreed upon, validators can access the actual transaction data to execute their associated code. 

Based on their respective designs, Aptos and Sui should perform comparably in terms of transaction sequencing. However, Sui’s design offers the advantage that a portion of transactions do not need to be sequenced at all. If Sui manages to avoid ordering, say, 20-30% of activity on its ledger, it could result in a considerable improvement in throughput and latency. That said, it is important to note that all transactions in Sui, including unsequenced transactions, still require signatures from a sufficient majority of validators in order for the lead validator to write it to Sui’s ledger. The collection of these signatures on a transaction-by-transaction basis introduces additional workload for leading validators compared to Aptos, whose leading validators only collect signatures for each proposed block of transactions. The additional workload may at least partially offset the throughput and latency advantage of skipping the mempool and consensus protocols. Additionally, frequent division of objects in Sui could potentially create complications in transaction processing. We discuss object splitting in more detail below.

Using the characters from our prior examples, let’s say Bob, Frank, and Alice continue exchanging fractions of USDC with one another over a period of time. After just three rounds of these transactions (represented in the diagram below by the different colored arrows), the original single object of 1 USDC may end up split into as many as eight separate objects. Obviously, this can quickly complicate Sui’s object pool and its associated transactions.

Sui transactions which do not “spend” the entire object require splitting the object in two. This can quickly result in a large number of objects. Eventually, Alice, Frank, or Bob may need to request a large number of transactions in order to transfer ownership of a given type of token. In the diagram above, after three rounds of splitting objects, Frank owns four separate USDC objects (highlighted in yellow squares): one with denomination of 0.05 and three with denomination of 0.1. He would need to request four transactions to transfer all of the USDC he owns, instead of just one.

Currently, Sui plans to offer a native wallet API which will allow users to “join” these small-denomination objects into a single larger-denomination object. This should help clean up the object pool. Still, the need to divide and rejoin objects adds a layer of complexity to the ledger’s design and is one disadvantage of Sui’s object-centric approach.

Transaction execution

With respect to the actual execution of transactions (i.e. running the actual code), both Aptos and Sui can execute non-overlapping transactions in parallel. Aptos uses a novel execution engine called BlockSTM (Block Software Transactional Memory) to parallelize execution. As on some other blockchains, if two transactions on Aptos do not touch the same addresses, the code for each one can be run at the same time on different processing cores within a single computer. However, unlike most other blockchains, BlockSTM does not require a transaction’s dependencies to be declared upfront, which enables greater flexibility in the types of transactions that users can request. 

At a very high level, BlockSTM takes a list of sequenced transactions and executes all of them in parallel as if none of them touch the same addresses. For transactions which do happen to touch the same addresses or have the same dependencies, BlockSTM will re-execute them until it does so in the correct order to arrive at the correct output. Very importantly, BlockSTM can continuously estimate the dependencies of a given transaction in order to minimize the amount of time and effort spent on re-execution of transactions. This approach allows Aptos to parallelize transaction execution as much as possible without requiring detailed data about the effects and dependencies of transactions.

On Sui, the code of two transactions can also be executed in parallel as long as they don’t touch the same object. However, it does require applications such as a user’s wallet to declare dependencies and/or objects impacted by a given transaction. The advantage of this approach is that Sui’s execution engine will spend much less time and effort re-executing overlapping transactions, but this comes at the cost of increasing complexity of the data included in transaction requests.

Other typical blockchains, including Ethereum, execute all transactions sequentially, one-by-one. Obviously, parallelizing execution as much as possible increases the potential throughput of a given blockchain, so it’s unsurprising that both Aptos and Sui have made this a key part of their respective architectures. Once again, we can visualize a few scenarios to better understand which transactions can or cannot be parallelized on Aptos and Sui.

On Aptos’ blockchain, the code for the two transactions above cannot be executed in parallel because they interact with the same address (Alice’s). One of the transactions must ultimately be executed after the other to make sure that Alice has a sufficient balance to pay both Bob and Frank. The order in which Bob and Frank get paid (or don’t get paid, if Alice’s balance is too low) is determined by the validators of the blockchain.

In Sui’s object-centric DAG, the above two transactions can be executed in parallel because they do not interact with the same object(s), even though they both come from Alice. Alice is changing the owner attribute of two separate USDC objects which she currently owns. There is no “balance check” required during the execution of these two payments.

However, as before, Sui transactions which require splitting a single object into two are considered related and cannot be executed in parallel. Validators must first execute the split, and then execute any remaining transactions on the resulting object(s). 

Both Aptos and Sui can execute the above transactions fully in parallel because they do not touch any of the same addresses or objects.

In Aptos’ blockchain architecture, each validator must execute every transaction in proposed blocks and vote whether or not to accept the new block, requiring a momentary freeze of the universal ledger’s state. Again though, transaction execution and dissemination are performed continuously in the background, even if the written state of the ledger is momentarily paused.

From the “Ledger Certification” section of Aptos’ whitepaper (emphasis added): 

“At this point in the pipeline, every individual validator has computed the new state for a committed block of transactions. However, to efficiently support verified light clients and state synchronization, the Aptos blockchain implements ledger certification for the ledger history as well as the ledger state. One key difference for the Aptos blockchain is that ledger certification is not on the critical path of transaction processing and can even be run completely out-of-band if desired.

A validator appends the transactions together with their execution output to a global authenticated ledger data structure. Part of the transaction output is the state write set, consisting of the alterations made to the global state accessible by Move. The short authenticator of this data structure is a binding commitment to a ledger history, which includes the newly executed batch of transactions. Similar to transaction execution, the generation of this data structure is deterministic. Each validator signs the short authenticator to the new version of the resulting database. Validators share their recent set of signed short authenticators with each other, collectively aggregate quorum-signed short authenticators, and also share the recent quorum-signed short authenticators with one another. ”

Validators on Sui will also generally execute every transaction on their own computer(s), but due to Sui’s DAG-based architecture, the state of the ledger does not need to be frozen in order to write a given transaction to the ledger. Instead, Sui validators will construct their view of the DAG using the publicly available transaction data (code) and use a checkpoint system to periodically verify that their constructed DAG matches the DAG of a sufficient number of validators in the network. These checkpoints which Sui creates are analogous to blocks in a traditional blockchain architecture. However, unlike in a traditional blockchain, if a transaction happens to move slowly through the consensus process, other transactions can still be written to the ledger without waiting for the slow transaction to be confirmed. Again, the ability to update the independent ledger of each object may provide Sui with a latency advantage in certain cases. One potential disadvantage of Sui is that validators are responsible for tracking and constructing their own view of the object pool. As such, if there are a high number of complex transactions between checkpoints, it could become challenging for some validators to synchronize the state of their object pool with other validators.

Transaction storage

The last difference we want to highlight has to do with how Aptos and Sui handle data storage. In a typical blockchain architecture, all executed transactions remain in the ledger forever. Over a long period of time, this can lead to state bloat and material memory requirements for validators. That said, the Aptos blockchain is represented as a Merkle tree, greatly reducing the storage requirements of validator nodes. Additionally, nodes can prune certain transaction and event data to reduce storage requirements. Both of these optimizations should reduce the storage burden for validators and other nodes.

As mentioned previously, one disadvantage of Sui’s object-centric design is that divided objects can quickly accumulate and take up valuable storage space on validators and other nodes. However, Sui’s economic model includes incentives and penalties designed to alleviate this issue. First, users must pay separate gas fees for execution and storage. Storage fees, which are set by Sui’s governance, are deposited into a storage fund which is used to adjust the stake of future validators and increase their rewards as their real-world storage requirements grow. Basically, the storage fund accumulates an increasingly large stake of SUI tokens and can delegate this stake to validators to pay them more as their storage costs grow. Additionally, Sui allows users to actually delete objects from the ledger. If an object is not specified as “read-only”, then its owner(s) can choose to delete it, if desired. Users who delete objects receive a storage fee rebate, providing an incentive to combat state bloat. Sui’s programming model also includes a native function to wrap objects. When an object is wrapped, it is embedded into another object and essentially becomes an attribute of that object. From a memory and storage perspective, this has a similar effect to deleting the object completely. Finally, the ability to join certain objects using Sui’s wallet API may help reduce memory usage as well. Deleting, wrapping, and joining objects can be used to alleviate state bloat if and when it becomes an issue. 

It’s important to note that because Aptos and Sui are both brand new layer 1s, state bloat is unlikely to become a high-priority problem for either of them in the near future. 

Our takeaway

Both Aptos and Sui represent the culmination of years of distributed ledger scalability research, and their new mempool and consensus protocols provide a material performance boost over existing architectures. As with any layer 1, the actual implementation of Aptos’ and Sui’s respective designs will be a major determinant of their real-world performance. Fortunately, both of these new entrants to the layer 1 landscape have the expertise and capital to execute well on their vision. In our view, Sui’s object-centric DAG appears to provide certain advantages over traditional blockchains in terms of throughput and latency, at least in theory. However, this may come at the cost of easy divisibility of assets and additional workload placed on validators. Either way, both protocols are still in their early stages of development, so we may see their respective performance advantages shrink over time as each one improves. Either way, both of these new layer 1s are highly ambitious undertakings which we expect to push layer 1 capabilities and our industry forward.

Acknowledgments

Special thanks to Jian Wang, Ross Liang, Larry Liu, Andres Acevedo, and others for offering their insight into the research.

About the author

Austin Muñoz is an Investment Partner for Amber Group's Eco Fund, the company's early stage crypto venture fund. Prior to joining Amber, he spent five years building automation tools and covering video games at a large family office hedge fund. It was there that he learned about existing financial infrastructure and markets and became interested in crypto both as a technology and as an asset class. He holds a master's degree in quantitative finance from Yale University and is a CFA charterholder.

Disclaimer

The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.

1. Introduction

Zero-knowledge proofs allow one party to prove to another party that a given statement is true without revealing any additional information. Naturally it could be leveraged to protect privacy, proving some transactions are valid while hiding all the details. Another important property of certain ZK protocols - such as STARKs and SNARKs, is the convenience of verifying a ZK proof. The size of their proofs is small. Verifying these types of proofs is much faster. Both of these properties suit resource-constrained blockchains, and are particularly important for scalability bottlenecks within the crypto industry. Besides these, other use cases of ZK technology include:

• Bridges - using ZKP for state transition or transaction validity, e.g. Alogrand ASP, Mystiko

• DID (Decentralized ID) - prove some account or entity has some ‘features’ without leaking detailed information, e.g. Sismo, First Batch

• Community governance - Anonymous voting, which could be expanded to real-life governance after being battle tested and widely adopted

• Financial statements - entities can prove they meet some particular criteria without revealing exact financial data

• Cloud services integrity - that the cloud service provider is performing tasks properly

  ……

A typical ZK system works as follows: engineers first write out the statements to be verified with a domain specific language, which is then compiled to a ZK friendly format such as arithmetic circuits. After parameters are generated using this format, a proving system takes them along with the secret it witnesses as inputs to compute the proof. A verifier can use the parameters and the proof to decide whether it is acceptable or not via relatively simple computation. For a ZK rollup specifically, the program or contract itself is deployed on layer2, the compiling, parameters and proof generation will be executed off-chain by some layer2 nodes, and the proof will be posted and verified on Ethereum mainnet.

A Typical ZK System

Source: ZK Whiteboard Sessions - Module One, by Prof. Dan Boneh

Multiple excellent proving systems have been developed, such as Marlin, Plonky2, Halo2, etc. Different proving systems adopt different trade-offs among proof size, the length of verifier time, and the necessity of a trusted setup*. After several years of exploration, it is possible to have constant level proof size (a few hundred bytes) and verifier time (several milliseconds) no matter how complicated the statements are. 

(*A trusted setup ceremony is a procedure in which one or more parties jointly generate some data (parameters) that will be used later for running the proving system. These parties are expected to permanently delete or forget their respective secret used during the procedure (hence, ‘trust’) so that the protocol will not be compromised.)

However, the complexity of proof generation is still almost linear to the arithmetic circuit size, which could be several hundred times larger than the original tasks. This is because the prover has to at least read and evaluate the circuit. It could take several seconds to minutes or even hours. High computation costs and long proof generation times have been, and are still expected to be, the main obstacles for mass adoption and the advance of ZKtechnology. 

Hardware acceleration can be used to help solve this bottleneck. Via assigning multiple tasks to most well suited hardware, it is a mutual supplement with algorithm or software optimization.

This report aims to help understand the market landscape, how it differs from previous mining markets, and potential opportunities. The report consists of three parts:

• Use cases from different projects and emerging trends.

• Solutions based on GPU, FPGA, and ASIC acceleration designs.

• Closing Thoughts 

2. Use Cases

Mapping out use cases for ZK will help illustrate how the market is evolving. Different categories have different requirements, which will dynamically interact with hardware solutions’ supply. At the end of this section, we also show a brief comparison between ZKP and PoW (especially for Bitcoin).

2.1 Emerging Chains and Their Differentiated Requirements

Current demands for hardware acceleration are dominated by emerging chains using ZK technology, which can be broadly categorized into scaling solutions and privacy blockchains. ZK rollups or volitions execute transactions off the mainnet and submit a succinct validity proof via ‘call data’ function. Privacy blockchains use ZKPs to ensure transactions initiated by users are valid without publicly disclosing transaction details.

These blockchains use different proving systems to pick between the trade-offs among proof size, verifier time, trusted setups and others. For instance, a Plonk generated proof has constant-level small proof size (~400 Bytes) and verifier time (~6 ms), but will still need a universal trusted setup. In contrast, a Stark system doesn’t need a trusted setup but its proof size (~80 KB) and verifier time (~10ms) are larger and will increase with circuit size. Other systems have different tradeoffs. The upshot is that choices over these proving systems will lead to shifts of the “gravity center” of the computation load.

More specifically, nowadays a proving system can be generally described as PIOP (Polynomial Interactive Oracle Proof) + PCS (Polynomial Commitment Scheme). The former can be regarded as an agreed procedure for provers to persuade verifiers, and the latter mathematically ensures that the procedure cannot be compromised. As an analogy, PCS is the gun and PIOP is the bullet. Projects can modify PIOPs to cater their own needs and choose from different PCSs. 

Georgios Konstantopoulos from Paradigm explains in his report on hardware acceleration that time used for proof generation is dominated by two types of computation tasks: MSM (multi-scalar multiplications) and FFT (Fast Fourier Transforms). However, instead of using a fixed number, establishing different PIOPs and choosing from different PCSs will bring different workload ratios of FFT / MSM. Using Stark as an extreme example, the PCS Stark uses, FRI (Fast Reed-Solomon Interactive Oracle Proofs of Proximity), is RS-code based instead of ecliptic curves used by KZG or IPA, so MSM is totally not involved in the whole proof generation. We show a rough order of the workload ratios for different proving systems as below, with the caveat that 1) It’s hard to estimate the exact ratio of the whole system; and 2) projects usually have their own modifications on the system when implementing.

Workload Ratios for Different Proving Systems*

(*Noting that technically Snark and Stark are not comparable concepts. Snark refers to a class of proving systems that satisfy some particular features, while Stark usually refers to the proving system initially developed by Starware in 2018.)

This will have a direct impact on the project’s preference of hardware types. Nowadays the most widely used hardware is GPU (Graphics Processing Unit) due to large supply and convenience for development. Additionally, parallelizing MSM calculation is quite convenient which suits GPU’s multi-core structure. However, as we will elaborate more on in the second section, FPGA (Field Programmable Gate Arrays) is possibly better at dealing with FFT. Projects who use Stark, such as Starknet and Hermez, could be more in need of FPGA than others.

Another takeaway from above is that this technology is still at an early stage, lacking standardized or dominant solutions. A full commitment to some algorithm-specific ASIC (Application-Specific Integrated Circuit) might be premature as well. As a result, developers are exploring a middle ground, which we’ll also explain more later.

2.2 Trend and New Paradigms

2.2.1 More Complicated Statements 

Following the use cases we listed at the beginning, we should expect multiple purposes and more complicated proofs both for the crypto industry and the real world. Some of them don’t even have to comply with the present proving systems. Instead of following the usage of PIOP and PCS, they can develop new primitives that best suit their needs. In other areas such as MPC (multi-party computation), integrating ZK protocols into some parts of the work will largely improve its practicability. Ethereum is also recently planning on a KZG setup ceremony as part of the preparation work for Proto-Danksharding and further Danksharding in the future, dealing with data availability sampling. Even optimistic rollups could possibly adopt ZKP one day for better security and shorter disputing periods.

While many people may view ZK as an independent sector within the broader crypto industry, we believe that the proper mental model is to view ZK as a technology that can address multiple pain-points. In turn, more flexibility and generality for hardware acceleration will be needed to serve different systems and customers.

2.2.2 Locally Generated Proofs

ZKPs used for privacy instead of compressing information have notable structural differences. In order to hide transaction details, some random numbers will be involved during the proving process. Users will need to generate the proof locally, but most of them don’t have advanced hardware. What’s worse, if most dapps remain as web apps, proofs will need to be generated within browsers, which takes even longer. For example, when Manta started to build high-performance provers for WASM*, they soon realized that “WASM gives users a 10x - 15x performance penalty compared with native speed”. To solve this, they have chosen to be a sponsor and architect for ZPrize, one of the largest ZKP acceleration competitions, and set up a particular track for acceleration for WASM. A client version is a much easier solution for these apps, but the downloading process will block out a non-trivial portion of potential users, and it doesn’t work with current extension wallets or other toolings either.

(*WebAssembly, a binary instruction format and virtual machine that brings near-native performance to web browser applications.)

An alternative way is to partially outsource proof generation. Pratyush Mishra presented this approach during ZK Summit 7. Users first perform some lightweight computing, then give public statements and encrypted witness to several third parties, who take over and finish the rest of the proof. Following this approach, as long as one of those parties is honest, users’ privacy will not be leaked. It combines some toolings used by ZK protocols and MPC. Alternatively, users can trade bandwidth for computation: first generating a proof of large size, sending it to a third party who will compress it and post it on-chain.

Outsourcing Proof Generation

Source: Zero Knowledge Summit 7, by Pratyush Mishra from Aleo

2.3 Comparison with PoW Mining

Though it is natural to think of ZKP as a novel form of PoW, and accelerated hardware as a new kind of mining machine, ZKP generation is fundamentally different from PoW mining in terms of purpose and market structure.

2.3.1 Power Competition vs. Utility Computation

In order to gain block rewards and transaction fees, Bitcoin miners seek for a small enough hash via constantly iterating nonces, which are practically only relevant for reaching consensus. On the other hand, ZKP generation is a necessary procedure to fulfill practical utilities such as information compressing or privacy protection, but no longer necessarily responsible for consensus. Such differences will have impacts on the potential breadth of participation and reward distribution pattern. Below we list three existing designs of how miners will be coordinated for ZKP generation.

• Rates-are-Odds (Aleo): Aleo’s economic design is the closest to Bitcoin and other PoW protocols. Its consensus, PoSW (proof of succinct work), still requires miners to find a valid nonce, but the trial process is mainly dominated by repeatedly generating SNARK proofs that takes hashes of nonce and state root as part of the input, until the hash of some round’s proof itself is small enough. We call these PoW-alike mechanisms the Rates-are-Odds model because the number of trials you can process in a unit period roughly determines the probability you will gain the reward. In this model, miners stock large amounts of machines to gain better odds.

• Winner-Dominates (Polygon Hermez): Polygon Hermez adopts a simpler model. According to their public docs, two main characters participating are Sequencers, who collect all transactions and preprocess them as a new L2 batch, and Aggregators, who indicate their intentions of validation and compete to produce the proofs. For a given batch, the Aggregator that submits the first proof earns fees paid by the Sequencer. Without considering geographical distribution, network condition, and proving strategy, the Aggregator with the most advanced implementation and hardware will likely dominate.

• Party-Thresholds (Scroll): Scroll describes their design as ‘'Layer2 proof outsourcing'', where miners will be arbitrarily chosen to generate proofs after staking some amount of crypto. The one chosen needs to submit the proof within a set time period, otherwise its probability for next epochs will be adjusted downwards. A wrong proof will cause slashing. At first, Scroll will likely collaborate with a dozen miners for the stability or even run their own GPU cluster. As time goes by they plan to decentralize the whole process. We view the time limit as a parameter to adjust trade-offs between efficiency and decentralization. Starkware will likely also fall into this category. In the long run only those with machines that are able to accomplish proving in time can participate in proving.

These coordination designs have different trade-offs. We expect Aleo will have the most decentralized token distribution, Hermez to have the best efficiency, and Scroll with the lowest threshold to participate. But with accordance to the designs above, an arms race of zk hardwares may not be imminent. 

2.3.2 Static vs. Evolving Algorithm

Another difference is that Bitcoin has a single, relatively static algorithm. Bitcoin core developers have always tried to comply with its initial design and spirit, to maintain network stability and avoid serious forks. Emerging chains or projects don’t have such legacy constraints, which gives them more flexibility to adjust their systems and algorithms.

We believe all these differences combined portray a more dispersed and dynamic market structure, compared with the simple and static PoW market. We suggest thinking of ZKP generations as a service (some start-ups name it ZK-as-a-Service), a means to an end, rather than an ultimate purpose in itself. This new paradigm will eventually form new business / revenue models which we will shed more light on in the last section. Before that, let’s first take a look at the multiple solutions.

3. Solutions

A CPU (central processing unit) is the main chip in a general computer, responsible for distributing instructions throughout the components on the motherboard. However, since a CPU is designed to handle a wide-range of tasks quickly, this versatility in turn limits its speed to deal with concurrency or some specific tasks, with GPU, FPGA, and ASIC commonly used as supplements. In this section we will focus on features, optimization process, current situation, and market for each of them.

3.1 GPU: Most Used Hardware at This Moment

GPU was initially designed for manipulating computer graphics and image processing, but its parallel structure makes it also a good choice for areas like computer vision, natural language processing, supercomputing, as well as PoW mining. Both MSM and FFT can be accelerated on GPU, especially for MSM via leveraging an algorithm called ‘pippenger’, and the development process is much simpler compared with FPGA or ASIC.

The idea for acceleration on GPU is quite straightforward: moving these computation concentrated tasks from CPU to GPU. Engineers will rewrite those parts into CUDA, a parallel computing platform and programming model developed by Nvidia for general computing on its own GPUs, or its competitor, OpenCL, launched by Apple and Khronos Group to provide a standard for heterogeneous computing so that users were no longer limited to Nvidia GPUs. These codes will then be compiled and run on the GPU directly. For more fine-grained acceleration, leaving aside algorithm improvement itself, developers can:

1. Optimize memory by using as much fast memory and as little slow-access memory as possible in order to downscale the costly data transfer (especially for those between CPU and GPU).

2. Optimize execution configuration by better balancing work across multiprocessors, building concurrent kernels, and allocating resources for tasks reasonably in order to lift hardware utilization, keeping them as busy as possible.

In short, try everything we can to parallelize the whole work process. Sequential execution, where different parts depend on each other's results, should be avoided as much as possible.

Parrelization Saves Time

GPU Acceleration Design Flow

3.1.1 Large Developer Base and Convenience for Development

Unlike FPGA and ASIC, GPU development doesn’t involve hardware design. CUDA or OpenCL also have larger developer bases. Developers are able to start their own modification very quickly based on open source implementations. As an example, Filecoin published their first implementation for GPU back in 2020. Supranational also open sourced their general-purpose acceleration solution recently, which at this moment may be the best open source solution in class. 

This advantage is even more obvious when taking into consideration works besides MSM and FFT . It’s true that proof generation is dominated by these two problems, but other parts can still take up a ratio of ~20% (source: Sin7Y’s whitepaper), so purely accelerating MSM and FFT will have a limited effect on the final time consumption. Even if time on these two problems are compressed to instantaneous, total time spent will still be one fifth compared with initial. Moreover, since it’s an emerging and evolving space, it is difficult to anticipate how this ratio will change in the future. To accelerate these heterogeneous works, given FPGA will need reconfiguration and ASIC probably needs re-design and manufacturing, GPU is of much more convenience.

3.1.2 Excess GPUs

The GPU market is dominated by Nvidia. According to Jon Peddie Research, its market share by discrete GPU shipments in Q1, 2022 was 78%. Although the prices of many cards are still highly inflated compared to the MSRP (Manufacturer's Suggested Retail Price), their availability is continuing to improve. During 2021, over 50m units of GPUs ($52 billion dollars worth) were shipped. To put that amount into perspective, that was almost 8.5x the amount of FPGAs sold during the same period.

GPU Chip Market Share

Source: Jon Peddie Research

For mining specifically, our conservative estimate is that approximately 6.26M GPUs will be freed from Ethereum PoW mining after Ethereum’s merge. We arrive at this number by multiplying Ethereum’s current hash rate (890 Th/s) by 90%, assuming that GPUs make up the vast majority of Ethereum’s hash rate. The resulting number (801 Th/s) is divided by the mining capacity (128 Mh/s) of the most advanced GPU card, the RTX 3090 Ti. This leads us to our conservative estimate of 6.26M GPUs. With ASIC dominating Bitcoin mining, no other projects using PoW can accommodate this bulk of mining power. Besides mining Ethereum forks or providing cloud services, pivoting to ZKP services is another choice that deserves exploring.

Ethereum Hash Rate

Source: Messari

3.2 FPGA: Balancing Cost & Effectiveness

FPGAs are integrated circuits with a programmable hardware fabric. The circuitry inside an FPGA chip is not hard etched thus it can be reconfigured multiple times by the designer adaptive to specific needs. On one hand, this effectively cuts off the huge manufacturing cost of an ASIC. On the other hand, more flexibility of usage of hardware resources than GPU reserves the potential of further acceleration and electricity saving. For instance, though optimizing FFT on GPU is still achievable, frequent shuffling of data will lead to large communication overhead between GPU and CPU. However, the shuffling is actually not completely random, by implementing the intrinsic logic directly to the circuit design, we can expect an FPGA to perform the task faster.

To achieve ZKP acceleration on an FPGA, a few steps are still required. First, a reference implementation for a particular proving system written in C / C++ is needed. Then, this implementation would need to be presented in HDL (Hardware Description Language) to describe the digital logic circuits at a high level. 

Subsequently behavioral simulation would need to be performed to display the waveform of the inputs and outputs to see if the code ran as expected. This step is where the implementation is most involved. Engineers could compare the two outputs, instead of going through the whole process to identify some trivial bugs. Later on, synthesizer would translate HDL to the actual circuit design with elements such as gates and flip flops, followed by implementing the design to device architecture and more simulation analyses. Once proper operation of the circuits has been confirmed, a programming file will be finally created and loaded into an FPGA device.

FPGA Design Flow

3.2.1 Current Obstacles and Unestablished Infrastructure

Though some module optimization work on GPU can be reused, there are some new challenges:

1. Due to higher level of memory safety and better cross-platform compatibility, open-source implementations for ZK are mostly written with Rust for a long time, but most FPGA development tools are adapted to C / C++, which hardware engineers are also more comfortable with. Teams might have to rewrite or translate those implementations before further actions.

2. When writing those implementations, software engineers will be limited to a narrow scope of open-source libraries for C / C++ that can be mapped into hardware architecture by present development support.

3. Besides those can be done relatively independently by software engineers and hardware engineers, some in-depth optimizations will rely on their close collaborations. For example, some modifications on algorithms will function equivalently as before, while saving a lot of hardware resources, but this can only be based on understanding of both components.

In short, unlike AI or other well-established areas, engineers will have to learn and nearly build from scratch for ZKP acceleration. Fortunately, we are seeing more progress. For example, Ingonyama proposed PipeMSM in their recent paper, an acceleration method for MSM on FPGA or ASIC. 

3.2.2 A Duopoly Market

The FPGA market is a typical duopoly market. According to Frost & Sullivan, in 2019, Xilinx (acquired by AMD in February 2022) and Altera (acquired by Intel in December 2015) contribute ~85% of the global FPGA market by shipments. Early access to the most advanced FPGAs might demand close relationships with Intel or AMD. Additionally, this emerging space has already caught the attention of these industry behemoths. AMD is one of the technology providers for ZPrize.

The FPGA is a Typical Duopoly Market

Source: Frost & Sullivan

Engineers already realized that one single FPGA doesn’t provide enough hardware resources for a complex ZKP generation, so they’ll have to use several bundled cards together for trials. Even after they complete their design, present standard FPGA cloud services offered by AWS and other cloud providers won’t serve them well. In addition, startups tackling acceleration solutions are usually too small to let AWS or others to host their customized hardware, and they don’t have enough resources to run their own servers either. Better alternatives might be collaborating with large miners or some Web3 native cloud providers. However, this relationship could be subtle considering in-house engineers of these mining firms will likely develop their own acceleration solutions at the same time.

3.3 ASIC: The Ultimate Weapon

An ASIC is an integrated circuit (IC) chip customized for a particular use. Typically engineers still use HDL to specify the logic function of an ASIC in a similar way as in the case of FPGAs, but the resultant circuit is eventually drawn into silicon permanently, whereas in FPGAs the circuit is made by connecting thousands of configurable blocks. Unlike purchasing from Nvidia, Intel, or AMD, firms have to manage to host the whole process themselves, from circuit design all the way to fabrication and testing. An ASIC will be limited to some specific function, but inversely it enables designers with maximum freedom for resources allocation and circuit design, and thus large potential for performance and energy efficiency. Designers can eliminate wasted space, power and functionality, having the exact number of gates needed, or adjusting different blocks’ size best adapted to the intended application, etc.

In terms of the design flow, compared with FPGA, ASIC involves detailed pre-silicon verification (as well as DFT*) between HDL writing and synthesis, and floor plan before implementation. The former is for engineers to test the design in a virtual environment with sophisticated simulation and emulation tools, and the latter is to determine the size, shape, and locations of modules in a chip. After implementation of the design, all the files are sent to foundries such as TSMC or Samsung for test tape-out. If that succeeds, the prototype is then sent for assembly and test.

(*Design for test, adding testability features to the design.)

ASIC Design Flow

3.3.1 Relatively Generalized ASIC for ZK

A common critique for ASIC is that once the algorithm is changed, the previous chips will be totally useless, but it’s not necessarily the case.

Coincidentally, all those companies we talked with that are having a plan for ASIC are not betting on a specific proving system or project. Alternatively, they prefer to develop some programmable modules on top of the ASIC, so that different proving systems can be dealt with through these modules and only MSM and FFT tasks are assigned to ASIC. This will inevitably be suboptimal to a specific chip when used for a particular project, but sacrificing performance for better generality could be better than task-specific designs in near term.

3.3.1 Costly but Non-recurring Input

Not only is the design process of ASIC much more complicated than FPGA, but the manufacturing process consumes much more time and capital as well. Startups can directly reach out to foundries for tape-out or through some distributors. Not until waiting in line for around three months or longer, could they actually execute it. Mask and wafer constitute the main cost of tape-out. Masks are used to produce the pattern on the wafer, a thin slice of silicon. Startups usually choose MPW (multi-project wafer) arrangements that allow them to share mask and wafer fabrication cost with several other projects. However, the conservative estimate of a tape-out will still be as high as a few million dollars, depending on the process and amounts of chips they choose. Tape-out, along with assembly and test, will take another few months. If that works, they will finally get started preparing for mass production. However, if anything goes wrong, debug and failure analysis will take an unexpectable length of time, and another tape-out will be needed. It will take a few dozens of millions and around 18 months from initial design to mass production. Mitigant is that a large portion of the cost mentioned above is non-recurring. Moreover, the performance ASIC provides and energy and space it saves are usually significant, and the price could be relatively low.

4. Closing Thoughts

A general assessment of different hardware solutions is shown below.

Comparison of GPU, FPGA, and ASIC

Source: Amber

For a clearer perspective on possible business models, we show all potential market participants in one chart. Since interactions between them could be mixed and complicated, we categorize them simply by functionality.

Functionality Layers for Hardware Acceleration

Except for developing a new GPU or FPGA chip, startups will be able to cut into this space from nearly any layer. They could choose to design and manufacture ASICs from scratch, packaging the chips into dedicated devices and sell them to miners, or they could sell bare chips to be assembled by downstream suppliers. They could also build their own servers, participating in proof generation or providing cloud services. Alternatively, they could choose to serve as a consultant company, providing design solutions but hands off actual operation. If they have robust partnerships or sufficient resources to cover across the value chain, they can also provide full-stack solutions to zk-applications, from hardware resources all the way to customized system designs.

Mass adoption for ZK is yet to happen, but building acceleration solutions is also a long-term process. We anticipate a tipping point. For builders and investors, the key question is when, not if.

Acknowledgments

Special thanks to Weikeng Chen (DZK), Ye Zhang (Scroll), Kelly (Supranational), and Omer (Ingonyama) for helping us understand all these details. Also thanks to Kai (ZKMatrix), Slobodan (Ponos), Elias and Chris (Inaccel), Heqing Hong (Accseal), and many others for offering their insight into the research.

Disclaimer

The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.

The Merge is coming soon. Ethereum will transition from proof-of-work to proof-of-stake, improving its security and sustainability. Still, questions linger about what the Merge actually does, how it impacts various stakeholders, and when it will actually arrive. This report covers the current state of the Merge, key implications leading up to and after the Merge, and a range of measures to gauge market sentiment.

Quick Takes

• The Merge significantly changes Ethereum’s monetary policy with a ~90% reduction in ETH issuance. For 6–12 months, validators’ principal (32 ETH) and new issuance will also be illiquid and stuck on the Beacon Chain. Circulating ETH supply may significantly contract through deflationary monetary policy and increased demand for staking ETH.

• Commentary from the Ethereum community suggests a soft target for the Merge in September. A range of market measures suggests that the market is expecting the Merge to at least happen by year-end. Pricing on Binance rates suggests that the market expects the Merge to occur by end of September.

• Ethereum MEV changes after the Merge. Most validators will run MEV-boost — free, open-source software that democratizes access to MEV rewards. But validator pools and centralized entities will likely continue to gain validator market share in the near term due to several factors (MEV smoothing, multi-block MEV potential, DoS mitigation). Ethereum developers are working on solutions to fix this on the protocol level.

• Miners have been key stakeholders of Ethereum since inception. Kicking them out is tough. Ethereum Classic, the largest GPU mineable blockchain after the Merge, cannot handle the influx of Ethereum’s hashpower. Facing a lack of alternatives, some miners have signaled support for an ETHPoW fork. We expect that a fork might cause a lot of headlines but would have negligible value in the long term.

Current State of the Merge

Two live testnets, Ropsten and Sepolia, have been successfully merged. In addition, there have been ten largely successful shadow forks on mainnet. These practice runs have exposed multiple small bugs that have been mostly fixed. Goerli will be the last testnet to undergo the Merge, which is expected to occur around August 6 to 12.

If all goes well, the mainnet Merge is expected around the week of September 19. But this is not a set date. The timeline, proposed by Tim Beiko on an Ethereum Consensus Layer Call, is a soft target and not final. Furthermore, estimating the Merge timing is difficult. The Merge activated more quickly than expected on testnets. Nonetheless, the proposed timeline below serves as a good rough approximation.

Note: Goerli Merge has been revised to be slightly earlier after this publication

What the Merge Does and Does Not Do

What the Merge Does and Does Not Do

The Merge will not materially increase transaction throughput and reduce gas fees. It simply changes the consensus mechanism from proof-of-work (PoW) to proof-of-stake (PoS). Fees will be slightly lower, all else being equal, as block production rate will be improved from ~13 seconds to 12 seconds.

Staked ETH cannot be withdrawn after the Merge. Withdrawals of staked ETH and new ETH issuance on the Beacon Chain will be enabled after the Shanghai hard fork, which is estimated to activate 6–12 months after the Merge. However, fees from transaction tips and MEV will be immediately liquid post-Merge. We clarify how withdrawals work later in this report.

The Merge does not enable on-chain governance. Some PoS blockchains have on-chain governance where their rules and upgrades are governed using some form of on-chain voting (examples include Cosmos and Polkadot). But this is not the case for post-Merge Ethereum. Similar to Bitcoin or the current version of Ethereum, protocol changes are discussed and decided upon off-chain through the social layer with a wide range of stakeholders.

The Merge does not mean there is free money for stakers. Under PoW, the Ethereum protocol has to provide enough incentives to compensate miners for operational expenses and a slim margin on top of that. A common take is that, by transitioning to PoS where validators have virtually no ongoing costs, stakers can enjoy easy high yields.

But staking is not free. Validators have opportunity costs on capital, both in choosing to invest their money in ETH and in staking their ETH in the Beacon Chain compared to other ETH yields. If staking were free, people would continue to acquire and stake more capital until a similar equilibrium point. In fact, this played out with the leveraged stETH trade that unwound in May-June. We explain this dynamic in more detail below.

The Merge significantly alters Ethereum’s monetary policy. Ethereum is currently rewarding both miners (at a rate of 2 ETH per block) and validators on the Beacon Chain. After the Merge, rewards to miners will cease, resulting in a ~90% reduction in ETH issuance — termed “the triple halving”. We explore this dynamic more deeply in the section below.

The Merge drastically reduces Ethereum’s energy expenditure and carbon emission. Under PoW, entities acquire energy-intensive mining equipment to secure the Ethereum network, resulting in high electricity use and hardware waste. Ethereum’s current energy consumption is on par with the power consumption of Chile; its carbon footprint similar to that of Hong Kong.

After the Merge, entities stake collateral to secure the network. There is no more arms race in acquiring more powerful mining hardware, significantly reducing energy expenditure. Most estimates suggest that Ethereum’s energy consumption will be reduced by over 99.95%.

Estimated Annual Energy Consumption (TWh/yr)

Source: Ethereum.org, Digiconomist

In Focus — Key Areas

“The Triple Halving”

The Merge is anticipated to significantly alter capital flows into and out of the Ethereum ecosystem.

On the supply side, Ethereum is currently incentivizing both miners (under PoW) and validators (under PoS). Seignorage is paid to miners to produce new blocks at 2ETH per block, and rewards are also being distributed to validators on the Beacon Chain. After the Merge, rewards to miners will cease, reducing ETH’s issuance rate by ~90%. This is why the Merge is also colloquially termed the “triple halving” — a nod to Bitcoin’s halving cycles.

Ethereum can afford to reduce ETH issuance because PoS is a more efficient way to secure a network compared to PoW. Under PoW, Ethereum needs to issue enough ETH to cover miners’ costs (purchasing mining rigs and paying for electricity) along with a slim margin. Under PoS, Ethereum only needs to cover the opportunity cost of capital. Furthermore, whereas PoW can only incentivize correct behavior miners through rewards, PoS allows Ethereum to also disincentivize misbehavior through slashing.

Ethereum Will Be Deflationary After the Merge

Source: Ultrasound.money

Demand for Ether is also expected to increase after the Merge due to a number of factors. First, staking rewards for validators will immediately increase. Validators will receive transaction tips that are currently earned by PoW miners, potentially boosting APRs by ~2–4%. Furthermore, they will also begin to earn MEV (maximal extractable value) due to their ability to reorder transactions. Researchers at Flashbots, an R&D organization that studies the emergent behaviors of MEV, suggest that validator yields could increase an additional 60% due to MEV (assuming 8M staked ETH). Therefore, if the Merge happened today, validators could expect to earn a total of ~8–12% APR due to all the factors mentioned above.

Total Staking Yield if the Merge Happened Today

Note: Estimate of MEV rewards are conservative as it is a lower-bound estimate from Flashbots

Source: @StakeETH, @eth2calculator, Etherscan, Beaconcha.in, Flashbots

Of course, these yields are not sustainable. Therefore, we expect a significant increase in ETH to be staked after the Merge. If the proportion of staked to total ETH is comparable to those of alternative L1s (Solana and Tezos: 75%, Cosmos: 64%, NEAR: 39%), Ethereum staking yields would compress to below 2% APR. Readers can evaluate how staking rewards would play out under varying scenarios in this calculator.

Total Post-Merge Staking Yield Sensitivity Analysis

Source: @StakeETH, @eth2calculator, Etherscan, Beaconcha.in, Flashbots

Other near-term factors that is expected to affect ETH’s demand-supply include:

• ETH de-risks after successfully transitioning from PoW to PoS

• Removal of energy usage criticisms as network energy expenditure will drop by >99%

• ETH will be increasingly seen as a financial instrument, similar to equity or a perpetual bond, due to its staking rewards

• Withdrawals from the Beacon Chain will not be enabled until the Shanghai hard fork, slated to be activated 6–12 months after the Merge

Stuck Until Shanghai

Withdrawals from the Beacon Chain are commonly misunderstood. Withdrawals of staked ETH and new ETH issuance on the Beacon Chain will not be enabled at the Merge. Instead, it will be enabled in the Shanghai upgrade, tentatively scheduled to occur 6–12 months after the Merge.

However, priority fees and fees from MEV (which could make up over half of total staking rewards) will be available for withdrawal immediately after the Merge.

Capital Outflow After the Merge?

Two separate withdrawals will be allowed after the Shanghai hard fork. First are partial withdrawals — allowing active validators to withdraw accumulated rewards and bringing down the balance of their stake back to 32 ETH. These are important as it allows validators to withdraw the income that they have generated without fully shutting down and reactivating their validator. It also allows validators to maximize efficiency, as when the balance of a validator goes above 32 ETH, there is no gain of efficiency in excess tokens. Without partial withdrawals, the earned rewards would sit as idle capital.

The maximum number of partial withdrawals per epoch is currently set at 256. Each day comprises 225 epochs, so 57,600 validators can withdraw their rewards every day. Currently, the average balance of all active validators is 33.66 ETH. We could expect this figure to climb to near 34 ETH at the time of the Shanghai upgrade, which suggests that the market would see partial withdrawals of:

(34–32) x (57,600) = 115,200 ETH per day

(~$173mn if ETH = $1,500)

This could continue to flow for between 7 days (based on the current validator set of 410k) to as high as 14 days (if the validator set increases to 800k).

Validators could instead opt for full withdrawals. Full deposits and withdrawals are limited per epoch to ensure the security of the Ethereum network, currently set at around 6 per epoch. To put this number in context, if all active validators currently wanted to withdraw, it would take over a year.

We expect that most of the rewards collected from partial withdrawals will be to create new validators instead of selling into the market, and that demand for new deposits will outweigh potential sell pressure from full withdrawals. Nonetheless, we point this dynamic out as it operates differently from alternative PoS-based blockchain networks and acts as a source of confusion.

The Upshot

• 90% reduction in ETH issuance

• For 6 months to a year, validators’ principal (32 ETH) and issuance rewards will be illiquid and stuck on the Beacon Chain

• Circulating ETH supply may continue to reduce through deflationary monetary policy and demand for staking ETH

Building Blocks

MEV has grown from a niche topic just a few years ago into a focal point of blockchain research today. MEV impacts all areas of the blockchain, from creating points of centralization to affecting user experience. The full impact of MEV is beyond the scope of this report — instead, we will briefly touch on how MEV affects validators post-Merge.

Maximal Extractable Value, or MEV, broadly refers to the total amount a miner or validator can increase their balance across a series of blocks given the actions available to them. These actions can include the ability to reorder transactions, censor blocks, and even attempt to reorg the chain. Some common forms of MEV include sandwich attacks, arbitrage, and liquidations.

The History and Current State of MEV

In the current state of Ethereum, most users send their transactions into a public mempool via their wallets. Entities called searchers constantly monitor the mempools for potential profit opportunities. In the early days of MEV, searchers captured these opportunities by bidding high gas prices for their transactions to have their transactions prioritized.

Naturally, as MEV became more competitive, this resulted in priority gas auctions (PGAs) that increased network load, created volatile gas prices, and inefficient usage of blockspace. Other negative externalities arose. Teams began building infrastructure across to world to offer quicker and broader access to various mempools. Miners offered services that allowed searchers to bypass the public mempool and execute transactions in private. Cartels between searchers were formed to prevent over-bidding for MEV strategies.

Several solutions arose to mitigate these negative externalities. Most prominently, Flashbots. Amongst other things, they created a sealed-bid auction mechanism for blockspace that allows searchers to privately bid for blockspace without paying for failed bids. Mining pools that plug into Flashbots infrastructure collect all these bids and produce a block that maximizes their revenue.

This largely democratized MEV. Searchers that found unique MEV opportunities could avoid revealing their strategy to other searchers and capture most of profit. For more competitive strategies (such as arbitrage), miners have democratized access to MEV revenue via the bids that searchers submit.

Post-Merge MEV

Validators will replace miners after the Merge. But there is no built-in mechanism at the protocol level to help validators capture MEV. Left unchecked, this structure would allow professional firms and larger entities to better capture MEV by setting up multiple validators and strategies that build optimal blocks. At-home validators would not be able to compete effectively.

Fortunately, Flashbots has also created a post-Merge alternative called MEV-boost. MEV-boost allows validators to auction off their blockspace to an open market and maximize their staking rewards.

The MEV Supply Chain

Source: Flashbots

In this framework, searchers will continue to find profit opportunities from MEV and bid for their bundles to be included. Builders aggregate all these bundles to build the optimal full block which pays the highest. When it is a validator’s turn to propose a block, they query the MEV-Boost relay for a payload that pays the highest and includes that in their proposed block. (We glossed over a lot. Reach out to us if any questions.)

However, there will be variability in MEV rewards. For instance, periods of high volatility often lead to higher MEV fees. Validators who luckily get to propose during these periods will likely see higher MEV rewards. A Flashbots study last year confirmed that the inequality between validators is exacerbated after factoring MEV.

Inequality Between Validators Without MEV (Left) and With MEV (Right)

Note the distance between the green and red lines significantly widens with MEV extraction

Source: Flashbots

Consequently, large institutions and validator pools that can socialize/smooth MEV by running thousands of validators benefit. This dynamic is similar to why at-home GPU miners join mining pools today — stability and predictability of income. The potential for multi-block MEV is a further centralizing force.

Validator Distribution by Staking Pool

Source: Beaconcha.in

Until Ethereum has MEV smoothing built into the protocol layer (something that is currently being worked on), validator pools and centralized entities will likely continue to gain market share.

Miners, Forks, Etc.

Miners are a critical part of Ethereum’s ecosystem. They have collectively spent an estimated $15 billion on GPUs. After the Merge, all their equipment and infrastructure will be idled and look for alternative uses. Already, GPU resale prices have halved from the beginning of this year in anticipation of the Merge.

Thus, what miners do leading up to and after the Merge remains highly uncertain. Some arguably adversarial behavior has already been observed. In May, developers had to re-do testing the Merge on Ropsten, after a miner significantly increased the hashrate to hit TTD before the Ropsten Beacon Chain was live.

The rationale, In the miner’s words, is that “IT’S A STRESS TESTING ROPSTEN NETWORK TO SEE WHAT WOULD HAPPEN IF THE MERGE HAPPENED OUT OF SCHEDULE.”

Sudden Spike in Ropsten Hashrate Caused by a Miner

Source: bordel.wtf

It is possible that leading up to the Merge, miners will become more hostile and severely degrade the user experience on Ethereum.

For instance, miners could steal MEV. When searchers send bundles to miners via Flashbots, searchers are trusting that the miners will not steal/expose/front-run the strategy. There is no cryptographic guarantee that miners won’t steal a bundle. As the Merge nears, miners could begin doing so as the cost of getting caught decreases.

Miners could also theoretically start running clients that reorg the Ethereum blockchain to retroactively capture MEV. These tools have been proposed in the past and largely frowned upon by the community. Large mining pools have not adopted them primarily due to reputation and harming the Ethereum network.

We expect that the largest mining pools such as Ethermine will not engage in malicious behavior. F2pool, the second largest mining pool, has already been planning for the Merge for a long time with its sister company, Stakefish. Ethermine also launched a beta staking pool service.

Nonetheless, smaller miners may attempt to eke out as much revenue as possible before the Merge by behaving maliciously.

Where Will Miners Go?

After the Merge, if these machines attempt to rotate within the crypto ecosystem, the most likely candidate would be Ethereum Classic, a fork of Ethereum resulting from the DAO hack in 2016. Just this week, Antpool, the eighth largest Ethereum mining pool, pledged a $10 million investment to develop the Ethereum Classic ecosystem.

But daily fees for Ethereum Classic are multiple orders of magnitude smaller than Ethereum. No other altcoins come close. Furthermore, the profitability of mining these networks will inevitably shrink if miners flood them with GPU hashrate, especially if prices do not rise.

GPU Mineable Blockchains

Clearly, other GPU mineable blockchains cannot handle the influx of idled GPU after the Merge. Furthermore, Bitpro estimates that for GPU miners to stay profitable within the crypto ecosystem, around 95% of GPUs need to be shut off. It is unlikely that this immediately happens after the Merge.

Thus, there is a possibility that miners attempt to maintain a PoW fork after the Merge. Some miners have already gathered support for an ETHPoW fork. If some exchanges support a fork, and a small group of miners continues a fork, a fork could live on longer than anticipated.

Even if that happens, virtually all users and developers will stick with the canonical, PoS Ethereum. There is no meaningful philosophical or ideological support for an ETHPoW fork. Furthermore, Ethereum’s ecosystem is drastically different now compared to 2016 (when the ETH / ETC fork happened). Real-world asset issuers, such as Circle (USDC) and Tether (USDT), will support minting/redemptions only on the canonical chain. Wrapped assets, such as wBTC, will do so as well. L2s and bridges will also only honor assets bridged from the main chain. DeFi on top of an ETHPoW fork becomes a bizarre situation in which billions of assets are rendered useless overnight.

Therefore, we expect that a fork might cause a lot of headlines but would have negligible value in the long term.

Priced In?

Liquid Staking Derivatives

Liquid staking derivatives can serve as a gauge of sentiment. The largest three are Lido’s (stETH), Binance’s (bETH), and Rocket Pool’s (rETH).

stETH and bETH are rebasing tokens — token balances are pegged 1:1 to the ETH staked and token balances are periodically updated to reflect rewards. Thus, stETH and bETH should converge to the price of 1 ETH after the Shanghai hard fork, as users will be able to arbitrage between ETH and their liquid staking derivatives afterward.

In contrast, rETH is designed as a value accrual token. It acts like a claim to the network’s total staked ETH and rewards. Therefore, the rETH-ETH exchange rate will increase over time. However, trading back rETH to ETH depends on protocol liquidity, which is limited until withdrawals are enabled. As a result, the market price of rETH has fluctuated over the past year.

Price Performance of Liquid Staking Derivatives

Before this May, stETH traded mostly on par with ETH, as there was high demand for staking ETH. This was further reinforced by the (incorrect) idea that stETH is “pegged” to ETH in the same way that 1 USDC is pegged to 1 USD, which gave market participants the confidence to leverage their yields. In this trade, participants would deposit their stETH in a money market protocol (most commonly, Aave) as collateral to borrow ETH, stake the borrowed ETH to receive stETH, and loop the trade again.

Several Products Emerged to Offer Leveraged ETH Staking

Turbulent market events starting in May forced large market participants, notably Celsius and Three Arrows Capital, to sell their stETH collateral. The lack of stETH-ETH liquidity and a crowded leveraged trade resulted in a lot of people trying to exit through a small door.

Crowded Trade Heading Through the Same Door

What The Market is Pricing In

bETH is currently trading at a 2.2% discount from ETH whereas its “flexible” staking yield is 2.4%.

If we were to treat bETH as a zero-coupon bond that is redeemable for 1 ETH when withdrawals are enabled; with the alternative yield at 2.4%, we can think of the market as ‘pricing’ the Shanghai upgrade to occur ~335 days from now.

Developers have guided that the Shanghai hard fork occurs 6–12 months after the Merge. Assuming the mid-range of these estimates, this implies the Merge to occur around September 30, 2022.

Needless to say, taking into account liquidity considerations and market technicals, this approximation is far from perfect but can be used to gauge market sentiment. The same exercise could be run for stETH, but we use bETH and Binance’s flexible earn rate to exclude the impact of counterparty risk and more easily back out the opportunity cost of capital.

ETH/BTC

The ETH/BTC ratio is also often used as a sentiment gauge for Ethereum while stripping out broader macro moves that may affect overall crypto prices. Major crypto events since May — such as Terra and Three Arrows Capital — muddies the pictures as there was allegedly forced selling of either asset over the period. However, ETH/BTC has rallied 20–30% since the beginning of July, spurring further Merge narratives.

Merge Beneficiaries

Price performance of some publicly traded tokens benchmarked against ETH also provides another glimpse into market sentiment.

Some beneficiaries of the Merge include:

Most of the tokens in the above categories have strongly outperformed against ETH since June with a couple of exceptions.

Price Performance of Select Tokens (Benchmarked to ETH)

Polymarket

Polymarket has the largest prediction market for the Merge. Although liquidity is incredibly low, diluting its predictive power, it nonetheless offers an alternative, simpler way of gauging market sentiment for the Merge.

Currently, Polymarket participants are giving a 66% probability that the Merge will happen according to the proposed timeline and a 95% probability that the Merge will occur by the end of this year.

Risks of the Merge

Execution risks. Good communication among all stakeholders is critical to a successful Merge. Validators on the Consensus Layer need to perform multiple actions prior to the Merge, such as updating the correct TTD value and keeping their nodes updated and in sync. User error or misinformation could cause nodes to drop off. Clients for the Consensus Layer may also have undiscovered bugs (although this is unlikely given the amount of testing put into various clients). If enough nodes fail, Ethereum could temporarily halt. There also exists execution risks for applications or exchanges running on top of Ethereum.

The Ethereum community has been actively working to mitigate these risks. For instance, the community rallied together to improve client diversity, reducing Prysm’s validator share from over 68% in April to 41% today. As a result, the consequences of a potential bug are significantly reduced — if a client had a bug with over 66% validator share, then validators cannot return to the real chain without being slashed.

Miner Risks. As mentioned in the above section, miner incentives will change leading up to and after the Merge.

Validator Risks. After the Merge comes a new set of network risks. A significant one is potential Denial of Service (DoS) attacks. Proposers will be known in advance and there will be incentives for some actors to maliciously DOS a validator. This also acts as a centralizing force that favors institutional validator pools that can handle and mitigate DoS risks.

Complexity Risks. Ethereum will effectively merge two separate networks together, expanding technical complexity. To participate on the Beacon chain, individuals need two clients. To run a validator, they need three. To capture MEV rewards, they need four. The risk is that, as Ethereum modularizes and specializes, this trend continues to a point where specialization occurs and it is difficult for any one person to understand the full picture.

Vitalik has also addressed this in his recent EthCC talk, rallying the community to start thinking about reducing Ethereum’s complexity.

Vitalik’s Ideal Long-Term Goal (for complexity, not price)

Conclusion

Appendix I: Overview of Select Tokens

Appendix II: Keeping Track of the Merge

Difficulty Bomb

The difficulty bomb, implemented in 2016, gradually increases the difficulty of mining new blocks such that it eventually grinds to a halt. It was introduced to guarantee a transition to PoS. The difficulty bomb has been pushed back six times, most recently in the Glay Glacier upgrade. Barring any surprises, we expect the difficulty bomb will not be pushed back anymore, so there will be a greater focus on average block times as we near the Merge.

Other Resources

• All Core Devs meetings are where various Ethereum teams discuss the future direction of Ethereum. Tim Beiko and Christine Kim often give excellent summaries of these calls on Twitter.

• Ethereum developers maintain a “Merge Mainnet Readiness Checklist” that periodically updates after major milestones on Github.

• wenmerge.com keeps track of a difficulty bomb countdown and major milestones on the path to the Merge.

Disclaimer

The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.

On the Merge was originally published in Amber Group on Medium, where people are continuing the conversation by highlighting and responding to this story.

Since the success of Axie Infinity, gaming has become one of the most invested verticals in the crypto industry. Many argue that blockchain games have the greatest potential to bring crypto into the mainstream, given the sector’s low barriers to entry and the widespread appeal of gaming. Amber has invested in several crypto games, and when speaking with teams in the early stages of development, we are often asked, “which chain should I build my game on?” Chain selection is a crucial decision for most game projects, and should be carefully considered. In this report, we will go through the history of several crypto games and analyze the pros and cons of different blockchain ecosystems. We hope this report can help current and future game developers with their decision on chain selection.

Axie Infinity: from Ethereum to Ronin

On Feb 18, 2018, Axie Infinity opened for presale, where people could adopt Axies by paying for them in ETH. The team planned to develop mini-games, quests, activities, and events for Axie owners to spend time with their Axies.

The game was initially built on Ethereum, and its three key economic elements, Axies, AXS, and SLP, were all represented as tokens on Ethereum. Axies were ERC-721 tokens (NFTs), while AXS and SLP were standard ERC-20 tokens. Axie Infinity finally captured mainstream attention in the summer of 2021, as shown in the chart below.

Facing more pressure from the community regarding rising Ethereum gas fees, the Axie team announced Ronin, an EVM-compatible Ethereum sidechain built solely for Axie Infinity and future games built by Sky Mavis. It aimed to create a faster, cheaper, and easier user experience. In addition, the sidechain would accrue value from transaction fee payments, instead of players paying gas to Ethereum miners.

However, Ronin was hacked for $600M worth of assets in March 2022. Worse yet, this notorious breach was rooted in a vulnerability specific to Ronin’s security design. The chain was secured by 9 validators, among which hackers were able to take control of 5. The Ronin hack highlighted the important question of whether the benefits of building a sidechain outweigh the potential costs. Building and operating a sidechain requires expertise and careful planning, which may not be achievable for many game studios, even those which are highly crypto-native.

Stepn: from Solana to BNB Chain

Stepn was one of the brightest stars of this year. Not only did its token value increase by ~380x at its peak from the public sale price on Binance Launchpad, it also brought a short-term bull run to SOL as people flooded into Solana to play Stepn.

Stepn is part of the “move-to-earn” subgenre of gamefi that allows users to earn rewards by running or walking. Players need to first buy a pair of shoes in its marketplace before playing. When players walk or run with their shoes, they are rewarded with GST, which can be sold in the open market or used in the game. Players are encouraged to upgrade their shoes with GST so that they can earn GST at a faster rate. Each upgrade is priced higher than the previous one, up until the maximum level of 30. For some higher-level upgrades or shoe mints, users need to use GMT, the governance token, as well. This complex and interesting in-game economic model attracts many players to design their own optimal strategy to maximize yields.

Stepn’s decision to launch on Solana was likely driven by Solana’s significantly lower transaction costs compared to those of Ethereum and other blockchains. Stepn was ranked 4th in the Solana Ignition Hackathon Gaming Track. However, the Solana network has recently struggled with occasional network downtimes and performance degradations, often for many hours at a time. This resulted in asset transfer delays as the Stepn team was not able to communicate with Solana nodes properly. Understandably, most users who didn’t understand Solana’s mechanisms blamed Stepn for the outage. These issues were not caused by Stepn, as they attempted to explain to their users, but it still negatively impacted player experiences.

In order to minimize the risk of running on a single chain, the team made the decision to expand to BNB Chain. Transaction costs on BNB Chain, while not as low as those on Solana, are still relatively cheap when compared with other layer 1 blockchains . Additionally, BNB Chain has a strong community with 970,218 daily active addresses at the time of writing, increasing Stepn’s user base. In April 2022, Binance Labs made an strategic investment in Stepn, further strengthening the partnership between Stepn and BNB Chain.

Although Stepn is technically “multichain”, the game is relatively siloed between the two networks. At the time of writing, there is a material price difference between GST on Solana ($0.14) versus GST on BNB Chain ($0.32) due to the lack of bridge infrastructure of the GST token between the two chains.

In traditional games, it is normal that multiple servers exist and the in-game economies remain separate between one another. However, the openness of blockchain creates new challenges for crypto game developers as they look to balance the interests of existing and new players and manage potential exploit risks inherent to cross-chain asset transfers.

DeFi Kingdoms: from Harmony to Avalanche Subnets

DeFi Kingdoms is an RPG mythical game which originally launched on Harmony. It “gamifies” DeFi by wrapping DeFi aspects into a fun gaming experience (hence the name). Users earn Defi Kingdom’s native token, JEWEL, by completing quests and selling in-game items. Users can also stake JEWEL inside a virtual bank, similar to single asset staking in DeFi.

Notably, DeFi Kingdoms announced plans to build a new realm called Crystalvale using Avalanche Subnets in Dec 2021. The core of DeFi Kingdoms remained the same in Crystavale, but a new token, CRYSTAL, was introducedto power the new realm. Users can bridge their JEWEL tokens from Harmony to the DFK Subnet on Avalanche and stake them to earn CRYSTAL tokens. JEWEL tokens are used for paying gas fees on the subnet, while CRYSTAL acts as the primary in-game currency. The dual token design most likely stems from a compromise between different stakeholders — new players want exposure to the new realm without the baggage of the old, while existing JEWEL holders were concerned about value dilution from the creation of a new token.

The team chose to partner with Synapse as the official bridge to send tokens between Harmony and Avalanche. However, the existence of JEWEL, a unified currency across two chains, brings up potential issues with arbitrage, liquidity, and bridge exploits (see our previous blog post for more details on the risks of bridges).

Although DeFi Kingdoms had found market fit on Harmony, the team’s decision to move to Avalanche was likely motivated by better scalability, security, and community reach. If DeFi Kingdoms were the only game on a given subnet, its users would be able to take full advantage of its TPS of 4,500. At the same time, security and decentralization are not compromised as subnets are validated by Avalanche nodes. In addition to Avalanche’s technical capabilities, Avalanche Foundation launched Multiverse, “an up to $290M incentive program to accelerate growth of a new internet of subnets.” DeFi Kingdoms became the first subnet project to receive a grant from the program, worth $15M.

Illuvium: Immutable X

Illuvium is an NFT collecting combat game, where players can hunt, capture, and play with over one hundred different “Illuvials”, each represented by an NFT. Combining multiple Illuvials allows players to evolve them to improve their stats. It also has plots of land which can be purchased. With the exception of the land-purchasing mechanic, Illuvium is similar to Pokemon-style games, with added features including duels between players and the ability to make bets on the outcome of matches. Kieran Warwick, Illuvium’s co-founder, recently announced in Illuvium’s Discord server that the launch date is August 30, 2022.

The game initially planned to launch on Ethereum’s layer 1, but later decided to move to Immutable X. IMX’s layer 2 platform is entirely designed for and marketed towards play-to-earn games, with zero gas fees for NFT minting. Immutable X also allows for NFTs to be listed automatically via various marketplaces, giving sellers more exposure to potential buyers. By using Immutable X, Illuvium is effectively built into the Ethereum ecosystem while not having to deal with the high gas fees normally associated with it. As a result, Illuvium does not have a high barrier to entry for new users, as most existing NFT users are already on Ethereum or layer 2s of Ethereum. Additionally, by using rollups, Illuvium is able to minimize security risks, especially those related to bridging assets.

Sandbox: from Ethereum layer 1 to Polygon layer 2

Sandbox aims to build a metaverse where users can purchase LANDs, digital pieces of in-game real estate, to build, own, and monetize their in-game experiences using NFTs and Sandbox’s utility token, SAND. However, due to high gas costs being a barrier to entry on Ethereum, Sandbox announced that users could migrate their funds onto Polygon PoS Chain to help relieve high transaction fees.

Polygon PoS chain is the main public chain of the Polygon network. However, Polygon is releasing multiple other scaling solutions, including Edge, which allows developers to build and run their own customizable blockchain. Developers can customize gas costs and define their validator sets, much like they can with Avalanche Subnets.

To enable easy connection to the wallets of their users, game developers can tap into Polygon ID, which helps verify on-chain credentials while preserving user’s privacy. Games can then grant access rights to players based on the assets they hold.

The native Polygon bridge (a.k.a. the Matic bridge) is the main tool used by developers to incorporate pre-existing NFT or ERC20 assets from Ethereum layer 1 to Polygon layer 2. This is what made it so easy for Sandbox to deploy to Polygon. Because the Matic bridge is one of the most battle-tested and general-purpose bridges, it presents less of a security concern than most game-specific bridges. Other games are also adopting Polygon’s architecture, such as Coolcats with their Coolpets game.

Closing Thoughts

Taking lessons from the examples mentioned above, we have summarized the key features of several major chains from the perspective of scalability, transaction fees, chain reliability, user base, and game highlights.

Many games have successfully launched on multiple chains. Some executed a complete migration to a new chain (e.g. Axie Infinity), while others built a new realm with a different economy (e.g. DeFi Kingdoms, Stepn). The expansion to new blockchains comes with risks from bridges and interchain economic stability. As the whole crypto space moves towards a multichain future, games with a thoughtful plan on chain selection and expansion will offer a more seamless experience to their players and stand out from the competition.

Disclaimer

The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.

Crypto Games: Blockchain Selection was originally published in Amber Group on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over the last year, Ethereum’s dominance as the primary smart contract blockchain was challenged by alternative Layer 1s. The multichain world was no longer up for debate; it became a reality. As these new chains gained adoption, their heterogeneous consensus mechanisms, smart contract languages, and community values fragmented Web3 into various ecosystems.

L1 Market Share (% of Aggregate TVL)

These compartmentalized ecosystems individually created value for their respective communities, but much of the synergistic value across chains was lost due to the lack of interoperability. Fragmentation also led to increased tribalism, more attack vectors, and a worse user experience.

For the industry to grow and onboard billions of new users, the friction between these chains must be minimized. This is the primary objective of a crypto bridge.

This report will cover the definition of a bridge, the classifications of different bridge designs, the tradeoffs between different designs, the risks associated with bridges, and our view on the bridge ecosystem’s future.

Defining & Categorizing Bridges

At the most abstract level, a bridge transfers information between two or more blockchains. This functionality is most commonly used to swap an asset on one blockchain (the “source” chain) for an asset on another chain (the “target” chain). However, bridges can also be used to communicate data or messages from the source chain to the target chain. As of this writing, over 100 blockchain bridges are currently used to transfer information across both Layer 1 and Layer 2 ecosystems. This increasingly complex landscape makes the sector difficult to understand for new entrants, so developing frameworks to simplify the various designs can be helpful. Recently, Arjun Chand created a useful framework to organize the many types of bridges into distinct categories. We take a similar approach to classify the various forms of bridges.

Bridges can be categorized by a number of characteristics. These include how they transfer information across chains, their trust assumptions, and the types of chains they connect.

We argue that the most important factor is how they transfer data from one chain to another.

Cross-Chain Mechanisms

Pool-Based Bridges

To understand how Pool-Based bridges work, let’s consider a user who wants to move USDT from Ethereum to Polygon. The user first deposits the Ethereum version of USDT into a designated contract address (the pool) on Ethereum and specifies the recipient address on the Polygon network to which this USDT should be credited. The bridge uses this information to transfer to the specified Polygon address a Polygon version of USDT.

Pool-Based Bridge Mechanism

A major limitation of this design is that the bridge must have sufficient assets in the target chain’s pool for the user to actually move funds. In the example above, if the Polygon USDT pool is empty, the USDT deposited in the Ethereum pool will be “stuck” until another user requests the reverse transfer from Polygon to Ethereum with enough USDT to replenish the Polygon USDT pool. Additionally, these types of bridges only allow a single type of asset transfer across chains (e.g. USDT from Ethereum to Polygon). If you want to exchange USDT on Ethereum for MATIC on Polygon, you can only do so after receiving USDT on Polygon.

The primary advantage of this design is that users do not need to rely on the security of the pool after they have received their tokens on the new chain. The assets they receive are native versions of the asset on the new chain, and therefore do not rely on redemption to the underlying asset in order to maintain their value. This is in contrast to another commonly used bridge design: lock & mint / burn & redeem.

Lock & Mint / Burn & Redeem

Another common type of bridge uses a mechanism known as “locking” or “burning”, followed by either minting or redeeming, respectively. We will once again use the Ethereum USDT to Polygon USDT example from the previous section to describe how the mechanism works. As before, the user begins by depositing the Ethereum version of USDT into a designated contract address owned by the bridge and specifying the recipient address on Polygon. This step is referred to as “locking.” However, unlike before, this type of bridge “mints” or issues its own version of the deposited asset on Polygon and credits it to the recipient account. These minted tokens are often called “wrapped” tokens, and their value is dependent on the ability to eventually redeem them for the underlying asset on the source chain. When the user wants to move back to Ethereum, the wrapped token is simply sent to the bridge contract address on Polygon and “burned”. This allows the underlying asset on Ethereum to be redeemed and sent to the specified recipient address.

Locking USDT To Mint Wrapped USDT

Burning Wrapped USDT To Unlock USDT

Because wrapped tokens rely on their redeemability to maintain their value, holders of wrapped assets are exposed to smart contract risk. If the pool on the source chain is exploited and drained of the underlying assets, the wrapped tokens become worthless. This is precisely what happened during the recent exploit on the Wormhole bridge, resulting in a loss of over $320 million.

That said, the advantage of the lock/burn & mint mechanism is that these bridges can always allow for the transfer of assets from the source chain to the target chain and vice versa. This is because they do not require an available pool of tokens to sit in the bridge’s contract on the target chain. This gives these types of bridges an advantage in terms of scalability.

Native Swap Bridge (with Decentralized Intermediary Chain)

This type of bridge has grown in popularity over the past year or so, in part driven by the growth of THORChain. A native swap bridge allows a user to exchange a native token on the source chain for a different native token on the target chain. For example, a user can swap native BTC for native ETH on their respective chains, without the need for wrapped assets. This is enabled through the use of a cross-chain automated market maker (AMM) and the use of an intermediary chain which monitors and records the states of the source and target chains. Although the ability to swap different native assets across chains is highly useful, this type of bridge uses what is arguably the most complicated transfer mechanism.

To explain how it works in simple terms, let’s walk through an example of a native swap of BTC to ETH, using a basic version of THORChain’s architecture as a reference.

Swapping Native BTC to Native ETH via a Decentralized Intermediary Chain and Built-In AMM

In this example, a user holding BTC would begin by sending this BTC (along with the recipient Ethereum address) to a Bitcoin address, known as a vault. This vault is controlled and monitored by a number of nodes which observe the incoming transaction and record the updated state of the Bitcoin vault on the intermediary chain (e.g. THORChain). Once the nodes have confirmed that BTC was received by the vault, the nodes calculate the appropriate amount of ETH to credit to the user on the Ethereum blockchain. Like any other AMM swap, the price at which the cross-chain swap is executed depends on the size of the swap relative to the respective amounts of BTC and ETH available in the vaults on both chains. A larger swap which “uses up” a larger amount of available liquidity will get executed at a less favorable price than a small swap which uses very little of the available liquidity. Once the swap amount has been calculated, the intermediary chain sends a message to the Ethereum network to send the appropriate amount of ETH from the vault address to the user’s recipient address.

In contrast to a pool-based bridge, a native swap bridge with an intermediary chain offers a higher level of decentralization and censorship resistance. For bridge users, it also avoids the smart contract risk created by wrapped assets, although liquidity providers can still have their assets stolen from the AMM’s liquidity pools via hacks or exploits.

Despite these advantages, the architecture of these bridges is far more complicated than other bridge designs. Creating a credibly decentralized native swap bridge is highly capital-intensive and time-consuming. As an example, in order to enable native swaps from BTC to ETH, every single THORChain node must also run a full Bitcoin node as well as a full Ethereum node. Furthermore, each THORChain node must be incentivized to behave honestly and reliably. All this must be done just to enable a single swap.

Native Swap Bridge (via Stablecoin Swaps)

This type of bridge aims to offer the convenience of native swaps combined with the architectural simplicity of pool-based bridges. Essentially, these bridges work much like a pool-based bridge, but with one additional step added to them to allow users to receive a different asset on the target chain than the one they deposited on the source chain. One example of this type of bridge is LayerZero Labs’ Stargate bridge. We will once again use an example to explain how they work. In this case, let’s consider a native swap of SOL to ETH.

Swapping Native SOL for Native ETH through the Use of Two AMMs and a Cross-Chain Stableswap Bridge

Once again, the user starts by depositing their asset, SOL, into a designated contract address on Solana which is owned by the bridge. However, unlike in previous examples, this deposit actually triggers an AMM swap of SOL to a stablecoin on Solana. For example, it may swap SOL to USDC. From here, the bridge functions much like a pool-based bridge; the stablecoin balance in the Solana contract address is credited by the bridge provider to the user on the Ethereum contract address. Finally, once the USDC has been credited to the user on Ethereum, the bridge executes another AMM swap from USDC to ETH. This ETH is then credited to the user’s specified recipient address. Essentially, these bridges function as pool-based bridges which only transfer stablecoins across chains, in order to provide better price execution during the cross-chain transfer process. As usual, the AMM swap execution prices on both chains are a function of the swap size relative to the available liquidity in both pools.

This architecture avoids the smart contract risk of wrapped assets and offers a simpler cross-chain communication mechanism than the intermediary chain architecture. However, there is a risk of receiving an unfavorable swap price, depending on the available liquidity of each AMM.

Home/Replica Contract Messaging (via Optimistic Fraud Proofs)

This particular type of bridge utilizes two contract addresses located on separate chains, known as the Home contract and the Replica contract, along with four different incentivized off-chain actors, to send messages across blockchains. Perhaps the most notable protocol in this category is Nomad, allowing multi-chain applications to more easily communicate across blockchain ecosystems. Let’s walk through another simplified example of sending a message from Ethereum to Polygon to explain how it works:

Sending a Message Across Chains Through the Use of Home and Replica Contracts Which Are Updated, Monitored, and Propagated by Incentivized Off-Chain Actors

A user on Ethereum would begin by submitting a message to the Home contract address on Ethereum. The Home contract collects this message and puts it in a queue along with other messages it receives. At this point, an off-chain actor known as an “updater” signs the group of messages to update the state of the Home contract. In order to sign these messages, the updater must post collateral to the Home contract which will be slashed if any malicious behavior is later proven to have occurred. A second off-chain actor, the “watcher”, monitors the Home contract as well as the Replica contract on Polygon to ensure that all messages are recorded and sent correctly. Because the bridge relies on optimistic fraud proofs, the watcher is responsible for submitting proof of malicious activity to prevent their processing and to penalize the malicious updater. Otherwise, messages will be assumed by the bridge to have been correctly recorded and sent (hence the name, “optimistic”). Assuming the watcher does not detect an issue with the updater’s actions, a third off-chain actor, the “relayer”, will transmit the messages to the Replica contract on Polygon. Finally, a fourth off-chain actor, the “processor”, propagates the message from the Replica contract to the end recipient(s) of the message.

This architecture is more appropriate for messaging/data transfer between blockchains, but theoretically could also be used to transfer assets, as asset transfers are ultimately just data describing changes to account balances.

One major drawback of this bridge design is that there is a dispute time delay (DTD) that can last ~ 30 minutes where watchers scan for suspicious behavior and contest malicious transactions. Two protocols, Connext and Hop, can shorten this wait time by allowing other market participants to send tokens directly to the end recipient before the fraud proof window has expired. In effect, these two protocols carry the risk associated with malicious transactions in exchange for a fee from recipients who want faster liquidity.

Trusted vs. Trustless

In this classification, bridges fall under two categories. They are either a) trusted or b) trustless. In other words, a user either trusts a third party to maintain the security and operation of the bridge or they rely on software that is designed and run in a distributed manner such that no single entity can alter its state or its operation. Some examples of trusted bridges include xPollinate, Matic Bridge, and Binance Bridge. Some examples of trustless bridges include THORchain, Ren, and Cosmos IBC.

Importantly, the distinction between trusted and trustless is not black and white — rather, it is a spectrum. A distributed software protocol with a smaller or more geographically concentrated set of operators will be more susceptible to single points of failure than a system with a larger, more heterogeneous set of operators. Similarly, a bridge which requires users to lock up assets in a contract address in exchange for wrapped assets also requires them to trust that the code has been written in a way that prevents exploits or theft. Non-custodial bridges do not require this trust, even if they are more commonly run by a centralized entity.

What They Connect

Layer 1 to Layer 1

Layer 1 to Layer 1 bridges allow users to transfer funds from one L1 ecosystem to another. For example, Wormhole’s Portal bridge enables asset transfers from Solana onto Ethereum. By increasing the interoperability amongst these Layer 1 ecosystems, web3 users have the freedom to spend their time and resources on their preferred chain while maintaining the flexibility to switch chains whenever they choose.

Layer 1 to Layer 2

Layer 1 to Layer 2 bridges allow a L1 chain, such as Ethereum, to communicate with Layer 2 chains built on top of the Layer 1 chain. For example, a user may want to bridge ETH from the Ethereum mainnet onto Arbitrum, Optimism, or ZkSync. They could accomplish this by transferring their tokens using each L2’s native bridge, or they could use a third party bridge such as Across. As L2 ecosystems continue to grow, these bridges will play a big role in transitioning Ethereum’s mainnet activity onto L2s.

Layer 2 to Layer 2

As the first half of 2022 comes to a close, Layer 2 roadmaps are becoming increasingly clear. Polygon’s various Layer 2 scaling solutions (Miden, Hermez, Nightfall), Starkware’s ZK-rollup Starknet, and Matter Lab’s ZkSync 2.0 will provide the core building blocks necessary for developers to build applications that are not bugged down by exorbitant gas fees. However, these various L2s are not natively compatible so there is a risk that they could become fragmented versions of what we have seen with L1s. The goal of L2 to L2 bridges is to ensure that L2 ecosystems reap the benefits of high throughput, low gas fees, and strong security while reducing potential fragmentation across L2s. Some projects actively working to accomplish this goal include Hop Protocol and Orbiter Finance.

Bridge Trade-offs

Despite the dozens of bridge designs, no bridge has been able to obtain all three properties of the interoperability trilemma. The interoperability trilemma, a term coined by Arjun Bhuptani, states that bridges can only possess two of the following three properties: generalizability, extensibility, and trustlessness.

1. Generalizability: ability to pass arbitrary data between two chains

2. Extensibility: ability to rapidly deploy on heterogeneous chains

3. Trustlessness: minimization of trust assumptions

The Interoperability Trilemma

Similar to the scalability trilemma, when a bridge chooses two of these properties, the last one suffers. As an example, Connext is a trustless bridge that enables token transfers between two EVM-compatible chains. At the moment, it cannot pass arbitrary data, which implies that it has prioritized the extensibility and trustlessness properties over generalizability. Other bridges such as ZetaChain prioritize extensibility and generalizability at the expense of trustlessness by requiring an additional layer of trust through the bridge’s validator set.

Because the primary use case for bridges has been token transfers between two blockchains, most projects have chosen generalizability and extensibility to quickly deploy on heterogenous chains and maintain the flexibility to pass arbitrary data. This has allowed these types of bridges to deploy faster than many of their competitors and satiate the market’s need for token transfers. While this comes at an unbeknownst cost to many of their users (to be covered in the risks section), these types of bridges can expand their use cases from executing simple token transfers to becoming more comprehensive developer platforms.

An analogy that describes a bridge’s transition from a token transfer mechanism to an application platform can be illustrated by comparing a bridge to a toll road that connects two highly congested cities. Every time a user wants to travel from city A to city B, the toll road earns fees. Bridges have been slowly moving away from this toll road model towards a town model where developers build applications on top of the bridge to create a town in between City A and City B.

Sprawling Towns (Ecosystems) Will Eventually Develop on the Toll Booth (Bridges) that Connect Different Cities (Blockchains)

Because some bridges have tens of thousands of unique users and have transferred billions of dollars in volume, they can use their existing user activity to incentivize developers to build applications on top of their bridges. Continuing with the toll road analogy, developers can be compared to ambitious entrepreneurs who decided to move into the small town after witnessing an influx of wealthy citizens (users). After seeing more activity occur in this town, other entrepreneurs move into the town and start creating bigger businesses (applications). Before long, this small town grows larger, and the toll road that was used as a transportation medium between the two large cities is now a gateway to this booming town.

Bridges as Application Platforms or “Layer Zeros”

There are some notable projects that are trying to become the booming town illustrated in the previous analogy. These projects focus on creating novel ways to link data across chains, while providing the foundation for a dapp ecosystem. They include:

RenVM

An example of the aforementioned toll-road & town analogy is RenVM & the Catalog protocol. RenVM supports cross-chain transactions using the lock & mint / burn & redeem mechanism described previously. Right now, this allows users to move BTC to and from both Ethereum and Polygon via wrapped BTC tokens called “renBTC”. Bridging can be thought of as one application that is built on top of RenVM. In addition to this, Catalog is a protocol taking the first step in generalizing RenVM modules to build an automated market making (AMM) solution within RenVM itself. Catalog is built using the first ever “boundless liquidity” mechanism. This AMM design not only uses Catalog’s own liquidity pools, but also leverages the liquidity pools of third-party DEXes, regardless of which chain they exist on. In this example, Catalog is working with RenVM and its existing ecosystem of users to enable more complex transaction types in a familiar user experience.

LayerZero

LayerZero is a communication primitive that allows for data and information to be sent across EVM chains that have a LayerZero endpoint. A LayerZero endpoint is essentially an on-chain client. A chain with a ZRO endpoint can conduct a transaction with any other chain with a ZRO endpoint. A third-party oracle service such as Chainlink is needed to sit between the endpoints and acts as the transactional and messaging security mechanism.

LayerZero ensures the validity of cross-chain communication by requiring that two independent entities, the Oracle and Relayer, corroborate the transaction

Applications that deployed on the various Layer 1 blockchains will find this approach very simple. For example, if a Dapp was built on Polygon, it is a fairly straightforward task to use the endpoint and quickly onboard your dapp onto LayerZero. Decentralized applications such as Stargate use the communication standard set forth by LayerZero to create decentralized exchanges/bridges.

ZetaChain

ZetaChain is a Layer 1 blockchain that does not have a need for wrapped assets to transfer value cross-chain, and does not need bridges for every pair of blockchains. This is enabled by Zetachain’s use of cross chain messaging, which allows for data and values to be sent across chains and layers. Utilizing omnichain smart contracts, developers can program ZetaChain to listen to and act upon events on connected blockchains. ZetaChain relies on consensus of validator nodes to secure itself and a distributed threshold signature scheme to secure the private keys on connected chains to avoid a single point of failure. PoS provides incentives for validators to act correctly.

What separates Zetachain from other competitors like LayerZero is that even blockchains without smart contracts, such as Bitcoin, can be incorporated into the multi-chain network.

These bridge platforms allow for interoperability between chains and allow for new ecosystems to be built upon them. This enables new use cases beyond sending a token from chain A to chain B. That said, each unique mechanism of a bridge/bridge platform has a degree of risk.

Risks Associated with Bridges

Given the technical complexity involved in navigating cross-chain message passing, there are various risks involved when using bridges. Some of the main risks include:

Bridge Risks

To mitigate censorship risks and halting risks, users can simply limit their use of trusted bridges and optimistic bridges. However, security risks can never be completely avoided, so it is important to understand the possible attack vectors to assess which security systems are more robust than others.

The two main attack vectors that are used to undermine a bridge’s security are 1) smart contract exploits and 2) root of trust exploits.

Two Main Attack Vectors for Bridges

A smart contract exploit occurs when a malicious actor successfully attacks a bridge at its application layer. Because most bridges must deploy secure smart contracts on all the chains that they connect, newer blockchains are easier targets for attacks. Languages such as Rust, CosmWasm, and Substrate all have growing developer communities but they do not possess the same number of developer tools and auditing firms as mature languages like Solidity, so the likelihood of a bug slipping through to mainnet is higher. When one factors in the elements of speed and competition when developing a bridge, it is easy to understand why smart contract exploits are the most common attack vector for hackers.

As for root of trust exploits, these hacks require a malicious actor to successfully attack the underlying verification method used by a bridge. In the case of the Ronin hack, the malicious actor attacked the honest majority assumption by accessing 5 out of 9 of Sky Mavis’, the studio behind Axie Infinity, private keys. Once the hacker breached Sky Mavis’ centralized security system, the rest was history.

As one can see, the vulnerabilities are not easily seen from the outside in, but the costs associated with poor security systems can be enormous. Over the last year, the cumulative cost of bridge exploits has exceeded $1.5 billion dollars.

Notable Bridge Exploits Over the Past Year

To make matters worse, unaware web3 users could easily feel safer when using higher TVL/TVB bridges because it appears that these bridges are robust enough to handle large volumes of token transfers; however, there is not a clear correlation between TVL/TVB and security. In fact, one could argue that the security of the bridge is at a greater risk as the TVL/TVB increases given the larger economic incentive for a malicious actor to find a vulnerability.

Therefore, understanding the underlying security system of the bridge one uses should be considered when transferring funds. If a retail trader needs to send 0.5 ETH quickly to ensure a NFT mint, then security does not need to be the top priority. However, if a DAO plans on transferring 10,000 ETH to a contract on a different chain, then the underlying security of the bridge should be carefully examined.

Closing Thoughts

As the crypto industry continues to develop, new bridge designs will be explored, new security models will be experimented with, and novel bridge-based applications will emerge. The success of a few secure, flexible, and efficient bridges will allow greater interconnectivity amongst protocols and communities. While there may be some short-term pain as the insecure bridges get filtered out, the sector’s future looks bright.

Disclaimer

Amber Group has invested in Nomad, Orbiter, Catalog, ZetaChain, and we provide routing/bonding/liquidity services for many of the protocols listed above. The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.

A common saying within the crypto community is that a month in crypto is like a year in traditional industries. Headlines and announcements — of fundraisings, protocol upgrades, governance proposals, airdrops, hacks, NFT mints, acquisitions, and more — barrage users seemingly every hour. Complicating this, the growth in the adoption of hundreds of blockchains and decentralized applications has made it difficult for even the most ardent Web3 user to navigate the industry.

Roadmaps are helpful guides for users to parse signals from a sea of noise and evaluate a protocol’s future goals. For instance, Vitalik Buterin’s post “a rollup centric Ethereum roadmap” in October 2020 marked a clear shift in the Ethereum ecosystem, providing a strong cue that users and developers should pay greater attention to Layer 2 platforms.

In this report, we summarize the roadmaps and key upcoming events that most crypto users should be aware of. We focus primarily on large-cap Layer 1 blockchains — as changes on L1 platforms affect all applications built on top of them.

Ethereum

Soon™

All eyes are on the Merge. Since 2015, Ethereum developers have been planning Ethereum’s transition from proof-of-work (PoW) to proof-of-stake (PoS). Ethereum seeks to move to PoS for many reasons, including improving security, increasing decentralization, and reducing energy usage. PoW is reliable, battle-tested, and secure, but it is also extremely energy inefficient. The Merge is expected to solve this by reducing energy expenditure by up to 99.9%. A shift to PoS also improves economics for ETH hodlers as the network no longer needs to pay hardware miners for security. Urgency for the Merge increased since the emergence of PoS-based alternative L1s, such as Cosmos, Solana, and Avalanche, all of which have demonstrably proven the ability to secure billions of dollars with PoS.

The Merge will occur once the Ethereum network hits a scheduled difficulty threshold, called Total Terminal Difficulty (TTD), which tracks accumulated mining difficulty. The mechanism for this threshold was implemented in 2015 but the difficulty bomb has been delayed five times. The next scheduled difficulty bomb will occur sometime this June but will likely get pushed back as developers seek more time to stress test the Merge.

In March, Ethereum developers completed their final merge testnet — called Kiln. The goal of Kiln was to identify any final bugs or issues on a test network before moving to public testnets. It also enabled the community to practice running their own nodes, deploying contracts, and checking tooling and infrastructure. The three public testnets to be forked now are Ropsten, Goerli, and Sepolia.

But Ethereum testnets have substantial usage and activity as well. So before fully forking these public testnets, Ethereum developers are currently running “shadow forks.” Shadow forks launch an upgrade on an existing network but only using a small number of nodes that the testing team controls. These nodes fork off from the main branch, allowing developers to stress test the Merge upgrade without bringing down the entire testnet if there are errors.

Both Ethereum mainnet and Goerli testnet have been shadow forked most successfully. Blocks continued to produce and finalize post-fork. But developers identified several issues to work on before going forward with running public testnets through the Merge.

On April 23, Every Client Combination Survived the Transition in a Mainnet Shadow Fork

Only after testnets are successfully upgraded and stable will a definitive time for the Merge be set. Currently, it seems like the Merge could occur in Q3 of this year if testing goes smoothly — however, do not be surprised if that timing gets pushed back a quarter or two.

What Does the Merge Do?

The Merge simply turns transaction validation from PoW to PoS. With it, Ethereum’s economics and demand/supply ratio drastically change (as explained in the next section).

The Merge does not directly improve scalability nor fix the high gas fees of the Ethereum network [fees will probably be slightly lower, all else being equal, as block production rate will be improved from thirteen to twelve seconds]. However, it does pave the way for Ethereum developers to focus on scalability solutions post-Merge.

In particular, developers will likely turn their key focus to pave the way for danksharding. Danksharding is a type of sharding design that provides more space for blobs of data instead of transactions. This is aligned with Ethereum’s rollup-centric roadmap, which envisions most user activity occurring on roll-ups. For now, developers are considering EIP-4844 (“proto-danksharding”) which implements most of the full danksharding logic without actually implementing any sharding. More specifically, it creates a new type of transaction, called blob-carrying transactions, that can carry extremely large amounts of data.

Ethereum developers are also contemplating several changes to further improve scalability and decentralization. For instance, the implementation of proto-danksharding would significantly increase disk space requirements, increasing the cost to run a full node. Hence, the community is exploring history expiry to reduce disk load. Other proposals being actively discussed include data availability sampling, statelessness, and simplifying the EVM. Vitalik Buterin collective names these proposals “the Merge, Surge, Purge, Verge, and Splurge.”

Vitalik Explains the Updated Roadmap for Ethereum Protocol Development

Eth-conomics

With PoW, seigniorage is paid to miners to produce new blocks at 2ETH per block. Rewards are also being distributed to validators on the Beacon Chain. After the Merge, rewards to miners will cease, reducing ETH’s issuance rate by ~90%. For context, based on the last 30 days, Ethereum is net inflationary at +3.1% per year; assuming that it already moved to PoS, it would have been net deflationary at -1.0% per year.

At the time of this writing, nearly 12 million ETH are staked on the Beacon Chain, resulting in a ~4.5% gross APR. Furthermore, after the Merge, validators will receive transaction tips that are currently earned by hardware miners, which could boost returns by another ~4–6%.

In addition, nodes will begin earning MEV (maximal extractable value) due to the ability to reorder transactions. Researchers at Flashbots, an R&D organization that studies the emergent behaviors of MEV, suggest that validator yields could increase an additional 60% due to MEV.

In sum, if the Merge happened today, validators could expect to earn a total ~16–17% APR due to all the factors mentioned above.

Revenue Distribution From Miners to Validators

Supply Sink

The Merge will increase the demand/supply ratio of Ethereum. After the Merge, not only will Ethereum’s supply issuance contract, but demand for $ETH will most likely improve as:

• $ETH de-risks after successfully transitioning from PoW to PoS;

• Removal of energy usage criticisms as network energy expenditure will drop by >99%; and

• $ETH will be increasingly seen as a financial instrument, similar to equity or a perpetual bond, due to its staking rewards.

Therefore, we expect a significant increase in ETH to be staked after the Merge. If the proportion of staked to total ETH is comparable to those of alternative L1s (Cardano: 72%, Solana: 75%, Avalanche: 66%), Ethereum staking yields would compress to below 2% APR. Readers can evaluate how staking rewards would play out under varying scenarios in this calculator.

Furthermore, for at least six months after the Merge, validators’ staked $ETH and rewards from new protocol issuance will remain locked on the Beacon Chain. Only after Ethereum undergoes the Shanghai hard fork will validators be allowed to withdraw their stake and rewards. Validators will only be able to freely use earnings from transaction fees and MEV fees before the Shanghai fork. Thus, we could see a period of serious demand/supply imbalance, where there is a sustained demand for staking $ETH and minimal new supply of $ETH.

Risks of the Merge

The Merge is not without risks. Although most Ethereum developers agree that there is a clear path to the Merge this year, tail risks remain as to unforeseen issues during the actual event.

There are also open questions as to how Ethereum miners will react close to and after the Merge. For instance, miners might coordinate their own fork and maintain PoW on another chain. However, the likelihood and impact of this risk are perceived to be low: Ethereum has signaled an intent to transition to PoS since 2015, and it is more likely that miners simply move to another PoW chain instead.

#L222

Another key focus for the Ethereum community this year is rollups. Many expect this year to be a pivotal year for rollup adoption — dubbed “L222” — as optimistic rollups mature and multiple zkEVMs launch on testnet and mainnet.

Activity on optimistic rollups — such as Arbitrum, Optimism, Metis, and Boba — is gradually increasing this year after a period of muted activity at the end of last year. One catalyst is the growing anticipation of a token launch and corresponding airdrop among the two largest optimistic rollups, Arbitrum and Optimism.

TVL on Optimistic Rollups

On April 27, Optimism took a step forward in progressively decentralizing through launching both a fungible token ($OP) and non-fungible tokens. Subsequently, Optimism will be governed by two houses:

• Citizens’ House, governing retroactive public goods funding to drive protocol development. Membership in the Citizens’ House will be conferred as non-transferrable NFTs.

• Token House, governing protocol upgrades, project incentives, and redeployment of treasury funds from sequencer revenue. Holders of $OP are members of the Token House.

Around 19% of total token supply is allocated for user airdrops, rewarding prior Optimism users and contributors. There will be future rounds of airdrops — according to the team, the best way to earn eligibility for future airdrops is to get involved in the Optimism collective by building on Optimism, being active in the community, and bridging assets to Optimism to try new projects on the platform.

$OP Token Allocations

On the heels of Optimism’s announcement, we expect there could be capital inflow to both Optimism and Arbitrum as users attempt to qualify for future airdrops.

Outside of token launches, the user experience on optimistic rollups (OPR) has also drastically improved since the beginning of last year. Each OPR has developed a strong community and ecosystem of applications. For instance, Arbitrum boasts 79 applications on its platform today — more than alternative L1s such as Solana, Terra, and Harmony. Optimism, Metis, and Boba also have thriving communities. Other statistics and catalysts that are signal positive trends for OPRs include:

• Metis, originally a hard-fork of Optimism, is the cheapest L2 network on Ethereum at the time of this writing.

• The upcoming Arbitrum Nitro upgrade is estimated to improve execution speeds by 20–50x along with a ~50% decrease in costs.

• The introduction of EVM equivalence — meaning complete alignment with the EVM specification — by Optimism. EVM equivalence allows every existing Ethereum stack to seamlessly integrate with Optimism’s L2 system.

EVM equivalence is a notable and clear differentiating factor for optimistic rollups. It provides developers with fast execution speed, low transaction fees, and strong security, all while preserving the strong network effects of the EVM. It is not the same as EVM compatibility, which requires modification of the underlying code that Ethereum’s infrastructure relies on.

In addition to optimistic rollups, the community is eagerly anticipating the mainnet launches of multiple general-purpose zero-knowledge rollups, colloquially called zkEVMs.

StarkNet, StarkWare’s zkEVM whose Alpha version is currently live on mainnet, is tentatively expected to launch mainnet Q3 to Q4 of this year. Despite its early development, over 55 projects are building on StarkNet’s alpha with several projects such as Oasis (NFT marketplace) and StarkSwap (AMM) already live. Users can play around with these apps through the Argent X wallet.

zkSync 2.0, Matter Labs’ zkEVM, launched its public testnet this February. No official timeline or roadmap is provided, but the Matter Labs team has been active in integrating its ecosystem partners. In addition, Matter Labs have stated that they will be launching a token that will be used by validators for staking. The token will likely be retroactively airdropped for testnet users.

Polygon’s suite of scaling solutions will also hit major milestones this year. Polygon Hermez, a zkEVM built by emulating the exact EVM opcodes, is expected to launch a public testnet during H1 2022. Polygon Avail, a data availability-focused blockchain most comparable to Celestia, is also expected to launch testnet around the same timeframe, and both teams have hinted at an upcoming collaboration with each other. Polygon Zero, a zkEVM built on recursive SNARKs, plans its testnet for Q4 2022. Polygon Miden, a STARK-based zkEVM, aims to launch testnet for Q3 2022 and mainnet after Q1 2023.

In addition, Polygon announced several new products and initiatives since the beginning of this year, such as:

• Polygon ID, a ZK-based identity solution that offers self-sovereign, private identity with on-chain verification. A public release of limited features is expected in Q2 2022.

• Polygon Supernets, application-specific blockchain networks that can leverage existing MATIC validators.

• A $100 million fund for the development and adoption of Supernets.

• A liquidity mining program based on key performance indicators such as weekly average users, total value locked, etc.

• A token redesign that could possibly launch this year. Details of the token redesign have not been revealed, aside from changing the token symbol and mechanics.

Scroll officially announced its zkEVM this April. Its goal is to create a zkEVM that achieves bytecode-level compatibility with Ethereum, allowing for seamless integration with existing Ethereum applications and infrastructure. Developers should expect their code to behave the same on Scroll and Ethereum mainnet. Scroll expects to launch an initial testnet release later this year.

Comparison of Various ZK Rollup Architecture

Solana

Network Degradation

At a protocol level, Solana continues to work on improving network performance. Since the beginning of this year, Solana has experienced thirteen separate occurrences of prolonged network degradation that resulted in reduced TPS, long transaction times, and outright failed transactions. Reasons for network degradation include increases in high compute transactions, excessive duplicate transactions, and an issue that overestimated the compute units used by transactions per block. Even at the time of this writing, block production on Solana has completely halted.

Block Production on Solana Halted Due to Flood of Transactions

Network instability is fatal for DeFi activities on Solana. For instance, during one period of network degradation, users were unable to repay loans or deposit more collateral on Solend, a money market protocol, resulting in a wave of liquidations.

The root cause of these issues boils down to the lack of an auction mechanism. In Solana, the ability to write to a block state is limited. Without a way for users to bid for it, users will be incentivized to spam the network with transactions to increase the likelihood that their transactions get included in a block. This is particularly the case in a low-fee environment where the costs of spamming the network with write attempts are virtually nil. Hence, the biggest anticipated upgrade to Solana is the introduction of an auction market for transaction fees (similar to Ethereum) or for bandwidth. Not only would this type of market disincentivize duplicate transactions, but it also provides users confidence that they can get high-value, urgent transactions executed if needed.

The contours of these solutions to improve network performance are still being worked out, but some soft consensus is forming around some combination of the following features:

Integration of Quic to avoid a single entity spamming transactions. Solana currently uses UDP, which does not require a two-way handshake between nodes. This improves speed. However, it also means that the network cannot tell if the source IP of a transaction is genuine. Malicious entities could use different IP addresses to spam the network or spoof the IP of another user to get them throttled. Quic (Quick UDP Internet Connections, a network protocol developed by Google) allows the network to discern and prevent an entity from flooding the network with requests. It won’t solve all of Solana’s issues, but it would significantly alleviate congestion.

Quality of Service (QoS) by stake weight. When the network load is high, QoS kicks in and throttles inbound traffic according to the stake weight of traffic from staked validators. In this way, important protocols such as Pyth (oracle network) or Serum (order book DEX) can get guaranteed throughput.

Fee prioritization by state. There will be slightly lower fees for low-compute transactions and higher fees for high-compute transactions, ensuring that the highest bidders cannot box out all other bidders. Developers are also exploring allowing applications to set their own fee structure.

Priority transaction propagation. Congestion fees will be charged to bots saturating the network, with tips directed to validators.

Interested readers can follow Solana’s progress in implementing some or all of these changes by following its testnet releases and announcements.

Wen Mainnet?

The problems mentioned above emphasize one point: Solana is still in beta. The community has been clear that Solana is still a work-in-progress with several kinks to be worked out. No official date has been released yet for mainnet launch. An announcement will likely be made after network performance issues have been improved and Solana can demonstrably maintain stability even under adverse or challenging situations.

Another key event to keep an eye on is the Breakpoint conference this coming November. Last year, Solana developers announced a flurry of partnerships with important web3 infrastructure and services, such as Render Network (rendering), The Graph (indexing), Brave (browser), Nansen (data analytics), Neon Labs (EVM development environment), and more. This year, we expect there will be a whole host of announcements building on top of last year’s momentum.

Other Things to Look Out For

• Neon EVM — Neon Labs is an organization bringing the Ethereum Virtual Machine to Solana. It is currently running Alpha on Solana’s devnet and aims to transition to Mainnet Beta afterward.

• Solana x OpenSea — OpenSea recently integrated a limited set of Solana NFT collections into its marketplace, using Phantom as the default Solana wallet. Unfortunately, OpenSea’s launch coincided with network performance, leading to several user complaints. Full launch will likely occur sometime this year.

• Solana Pay — Earlier this year, Solana Labs announced Solana Pay, which allows merchants to accept crypto payments directly from customers through the Solana network. In theory, this eliminates the middleman and saves merchants and purchasers 3–4% in credit card processing fees. Over 600 merchants have already integrated with Solana Pay in a month. Further announcements of integrations and partnerships would be particularly positive for Solana’s organic user growth.

Avalanche

Ever since Avalanche announced Avalanche Rush, a $180 million DeFi incentive program, and Avalanche Blizzard, a $200 million ecosystem fund, user traction on the network has surged. Avalanche Rush kickstarted user growth by funding important DeFi primitives, such as stableswaps (Curve), money markets (Aave, Benqi), and DEXes (Trader Joe). Blizzard effectively retained users afterward by supporting protocols built around those primitives. Hence, whereas projects launching on Avalanche last year were primarily forks of existing Ethereum projects, we have seen new ideas and innovations launching first on Avalanche today, such as Platypus, Alkimiya, and Yeti Finance.

Daily Transaction Count on Avalanche Network On Par with Ethereum’s

Subnets — Horizontal Scaling

Avalanche aims to capitalize on this momentum through the recently announced Avalanche Multiverse, a $290 million incentive program to accelerate the adoption of subnets.

Subnets are Avalanche’s core scaling technology, allowing developers to build application-specific networks separate from existing Avalanche chains. Subnets can have different execution environments, gas tokens, control over the validator set, and more, providing developers greater control over their applications. Most importantly, they allow hundreds of transactions to be processed in parallel, allowing Avalanche to scale horizontally. They are conceptually similar to the concept of Cosmos Zones and Polkadot Parachains.

Topology of Cosmos, Polkadot, and Avalanche

The first recipient of the Multiverse incentives was Defi Kingdoms, which successfully deployed a subnet this March. Because Defi Kingdoms was on a separate subnet, at one point it cleared more transactions than both Ethereum and Avalanche’s C-Chain, while offering cheap network fees.

DFK Chain Proved Out Subnet Technology

The value proposition of subnets is particularly compelling for blockchain gaming. Game developers can have greater control of their game economy by having a separate network. Furthermore, developers do not have to worry about bootstrapping their own virtual machine or validator set. Not only that, developers can optimize subnet performance by requiring their custom validator set to run high-spec hardware. This sacrifice in decentralization is generally seen as acceptable for use cases such as gaming where most of the transactions are high-frequency and low-value. Thus, many of the subnets slated to go live in the next few years are gaming-related.

There are currently 414 subnets on Avalanche’s testnet. Some notable projects building their own subnets are:

• Crabada, a play-and-earn idle game currently on Avalanche’s C-Chain but planning to migrate to its own subnet, called the Swimmer Network.

• Shrapnel, an AAA first-person shooter game that enables players to create, trade, and own their player-created content on the chain.

• Ascenders, an adventure RPG aiming to build an open world with a crypto-driven economy.

• WAGMI Subnet Demo, a high-throughput EVM-based subnet that has supercharged parameters (2.5x higher gas limit and 6.7x the gas target of Avalanche’s C-Chain). It allows for complex VM testing on a live network without affecting the stability of C-Chain.

• SpacesVM, an Avalanche-native VM optimized for storage-related operations. A working demo is currently live and allows users to create authenticated, hierarchical storage of keys/values.

Crabada’s subnet is highly anticipated, as the application currently consists of ~64% of total transactions on the C-Chain. Its migration to a separate subnet would likely alleviate congestion on C-Chain.

Crabada Dominates Recent C-Chain Activity

Most of the attention this year will be focused on the deployment and subsequent performance of subnets. Furthermore, we expect greater cross-subnet functionality down the line. Subnets currently cannot send arbitrary messages to each other. In the future, Ava Labs expects to implement features in which one subnet can not only send messages but also invoke a smart contract on another subnet, improving the interactivity within the Avalanche ecosystem.

Other Things To Look Out For

• Launch of Core, a free, non-custodial wallet with native Avalanche bridging functionality.

• Implementation of on-chain governance where participants can vote on changes to the network.

Cosmos

Cosmos itself is not a blockchain, but an ecosystem and framework to enable sovereign and interoperable blockchains. The Cosmos SDK powers large L1 blockchains, such as Terra, Osmosis, Juno, Cronos, and Secret Network. However, Cosmos’ native token, ATOM, has often been criticized for not capturing the value that it creates within the Cosmos ecosystem.

Cosmos’ Technology Powers Multiple Blockchains With Total FDV of $150bn+ but There Is Minimal Value Accrual to $ATOM

This is primarily by design. $ATOM currently only secures the Cosmos Hub, a hub that connects application-specific blockchains (called Zones). Cosmos preaches hub minimalism, arguing that it 1) simplifies the code base, increasing security and reliability; 2) conducts a limited set of functions such as processing cross-chain transactions, reducing overhead costs; and 3) enables Zones to specialize in other functions, leading to efficiency gains. In line with this philosophy, Cosmos does not require any Zone to pay $ATOM for fees or security. Hence, for now, $ATOM’s value accrual primarily comes from governance, airdrops, and securing the Cosmos Hub.

Interchain Security

The introduction of interchain security provides another path for value accrual. In contrast to Polkadot, where every parachain inherits the validator set of the relay chain, Cosmos currently requires Zones to run their own validator sets. This encourages sovereignty as each blockchain can decide on its level of security. But also creates hurdles for new Zones, which have to bootstrap their own set of validators. Interchain security allows Zones to lease security from Cosmos Hub (or other Cosmos chains).

Cosmos’ Lambda upgrade, expected in Q3 2022, will implement the first version of interchain security that allows Zones to secure their chain using Cosmos Hub validators. For example, Gravity Bridge plans to adopt Interchain Security, so $ATOM stakers would receive $GRAV rewards on top of $ATOM rewards. Next year, Cosmos’ Gamma upgrade will enable partial interchain security, in which Zones could use a combination of their native validator set and Cosmos Hub validators.

Interchain security indeed bolsters the case for hodling and staking $ATOM both by lowering the barriers of entry for new chains as well as more efficiently capturing the value that Cosmos Hub creates. But it could take a few years for the thesis to fully play out. Full interchain security will mostly be niche, long-tail chains that end up using the feature. If larger chains, such as Osmosis, choose to adopt interchain security, they would probably prefer partial interchain security. After all, a key value proposition of building a Cosmos chain is sovereignty over validator sets.

Interchain Accounts

Cosmos’ Inter-Blockchain Communication (IBC) protocol, introduced last year, unlocked interoperability across the Cosmos ecosystem by enabling token transfers and oracle data across Cosmos chains. Along with NFT transfers and queries to be launched this year, IBC will allow full-blown asset/information transfer between different Cosmos chains.

But IBC allows “read-only” features. The recent Theta upgrade along with the upcoming Rho upgrade brings Interchain Accounts to Cosmos, allowing chains to also “write” state. Interchain accounts enable any Cosmos chain to perform transactions and interact with any contracts natively on other Interchain Account-supported chains. For instance, an Osmosis user could swap $ATOM for $UST and deposit that $UST into Anchor Protocol, all without leaving the Osmosis application. As another example, we previously touched on Sommelier Finance, a protocol that optimizes yield generating strategies for liquidity providers. If Sommelier wanted to deploy vault strategies on Osmosis today, each chain would require a full upgrade to deploy appropriate modules. They would both have to undergo full upgrades afterward for any module developments. With Interchain Accounts, messages can simply be sent from one side to another, drastically improving efficiency.

We expect Interchain Accounts will drastically improve composability across the Cosmos ecosystem, akin to how applications and smart contracts on Ethereum L1 can all frictionlessly interact with each other.

Other Things to Look Out For

Native liquid staking is also coming to Cosmos Hub. Cosmos team is planning to add CosmWasm to enable smart contract functionality so that teams like Lido can create liquid staking solutions.

Celestia public testnet in Q2 2022. Celestia is a modular consensus and data availability layer currently running in devnet. It aims to launch an incentivized testnet in Q3 2022 before a full mainnet launch by end of this year. Celestia’s mainnet launch would significantly widen the design space for blockchain architecture, such as enabling interoperable execution and Celestiums.

Can Evmos rebuild trust? Evmos is an EVM chain compatible with the Cosmos ecosystem. It built strong hype since the beginning of this year by offering airdrops to a wide range of Cosmos, Ethereum, and Osmosis users. Evmos launched on mainnet beginning of March amidst strong hype, but the chain halted only a couple of days after launch due to a failed network upgrade intended to patch a critical security vulnerability. A minority of users were able to claim and stake their Evmos airdrops early, gaining what other community members believe an unfair advantage. The Evmos team ultimately decided to continue the chain where it last halted instead of a full chain reset, alienating some users. Combined with delays in getting the chain back online, excitement for Evmos has died down. Nonetheless, Evmos still hold strong potential to become Cosmos’ de facto EVM Hub that can natively interact with other Cosmos chains. Evmos went live on April 28 — users can bridge to Evmos using Nomad.

Upcoming Chains and Airdrops. New up-and-coming projects on Cosmos abound. Several are planning to go through testnet -> incentivized testnet -> mainnet this year, including Gnoland, Archway, Tgrade, Pylon, and more.

Select Upcoming Cosmos Projects

One new project to look out for is Gnoland, created by Cosmos founder Jae Kwon. Gnoland’s primary value proposition is being programmed in Gnolang, a fork of the popular programming language Golang. The founder argues that because Gno is deterministic, intuitive, and resource-effective, it is superior as a smart contract platform compared to Solidity. And using a fork of Golang could draw in new developers as there are globally more Go developers than Rust developers. Right now, Gnoland is going through testnet with the community focusing on building basic DeFi infrastructure such as a DEX and stablecoin implementation.

New Cosmos chains typically provide airdrops to $ATOM stakers to incentivize validators, bootstrap community members, and gain goodwill from the wider Cosmos ecosystem. Expected airdrops from Cosmos chains this year include: Evmos, Gravity Bridge, Game, Legendao, Bitsong, Lum Network, Raw DAO, and more. A few resources that check current and upcoming airdrops:

• Cosmos Analytics by Smart Stake

• Cosmos Pug Airdrops

• Cosmos Airdrop Chat

NEAR

We previously wrote about NEAR’s sharding design, Nightshade, and the roadmap to fully implementing it. Since then, the timeline has been slightly modified. NEAR plans to focus on:

• Implementing challenges and adding some form of synchronous execution by Q3 2022. Challenges protect the protocol against invalid state transitions, a particularly salient threat in sharded blockchains. Fully synchronous execution would provide drastic improvements for NEAR developers, particularly those building DeFi applications. For instance, Aurora runs an EVM environment on a separate shard — enabling synchronous executions between NEAR-native applications and Aurora applications would drastically improve composability within NEAR’s platform.

• Implementing general re-sharding by Q1 2023, allowing the protocol to balance network loads between each shard.

• Launching full Nightshade by Q2 2023.

Since we wrote the article, NEAR experienced a step-change in adoption. TVL has skyrocketed from nearly $600 million to $1.7 billion, mostly driven by the launch of money-market protocols Aurigami, Bastion, and Burrow. Sweatcoin, which aims to build a movement economy, saw over 400,000 wallet creations just one week after launch. The number of daily active contracts and transactions continue to grow.

Block Space Demand and Utilization Continue to Grow

NEAR Protocol also announced a $350 million funding this April. Along with a $150 million fundraise this January, the team has a substantial war chest to fund protocol development and adoption. We expect a wide range of new applications to be launched on top of NEAR and Aurora, including orderbook exchanges (Orderly, Tonic, Spin), wallet providers (Sender), games (Aboveland), and more.

Another noteworthy protocol development is the recent launch of NEAR’s native stablecoin, $USN, by Decentral Bank. $USN is soft-pegged to the US dollar and has a multi-currency backing of $NEAR and $USDT. $USN is overcollateralized, so Decentral Bank has “protocol-controlled value” to generate income, such as offering staking, lending, stableswaps, etc. Hence, the minimum lending APY for $USN is NEAR’s staking APY, which is currently ~11%. However, Decentral Bank suggests that yields will be over 20% through additional incentives to bootstrap $USN usage, which would likely spark significant capital inflow into NEAR’s ecosystem.

Eventually, $USN is expected to be integrated on a protocol level, where it can be used to pay for transaction and storage fees. Validators could also receive rewards directly in $USN instead of $NEAR, improving income stability. Look out for $USN integration with DEXs, CEXs, wallets, and other protocols as another measure of user adoption.

Mina

Mina, an ultra light-weight blockchain using recursive zk-SNARKs, has an ambitious and packed roadmap for this coming year. Since its mainnet launch early last year, Mina has been focused on refining its protocol, building out the ecosystem, and laying the foundation for applications to be built on top of Mina protocol (zkApps).

This year, a key focus for Mina is pushing zkApps to mainnet. Currently, zkApps are undergoing several phases of testing until Q2 2022. Furthermore, the community is actively developing a software development kit, which includes a TypeScript (a form of JavaScript) library called “SnarkyJS”, to make it easier for developers to create zkApps. SnarkyJS could ease the friction for onboarding new Web3 developers, as ~65% of developers globally know how to code in JavaScript.

In addition, Mina plans to introduce non-native token support at the protocol level, similar to the ERC-20 standard of Ethereum. This would be particularly beneficial for native DeFi protocols built on top of Mina, unlocking new DeFi use cases of zk-SNARKs and strengthening Mina’s value proposition amongst other L1s.

After zkApps launch on mainnet, Mina will shift greater attention to scalability as the protocol currently only supports 1 TPS (compared to Ethereum’s 12–15 TPS). In particular, with the introduction of SnarkyJS, rollups will become possible on Mina, paving the way for zkApps to be built as rollups on top of Mina.

Another catalyst for Mina’s ecosystem is the upcoming Mina to Ethereum bridge being built by =nil;Foundation, an ecosystem partner. The bridge’s goal is to enable full Mina state in-EVM verification, meaning that it would be possible to bring everything that happens inside the Mina Chain to Ethereum. Some possible use cases that the bridge would enable include:

• Creating a trustless bridge between Mina and Ethereum to send assets, such as wrapped Mina ($WMINA);

• Proving that a particular trade order was filled on Uniswap with Mina, without actually revealing details of the actual trade; and

• Using Mina to prove the identity of an individual for Ethereum-based actions.

The project is coming close to its final steps; a production-ready version is expected in Q2 2022.

All these catalysts combined would showcase the features and uses cases uniquely enabled by Mina’s protocol design. For instance, Teller Finance is planning to leverage Mina’s blockchain to create a decentralized borrow/lending market. Through Mina, users can prove that their credit score via CreditKarma meets a certain threshold. The proof is submitted on-chain. If Mina’s blockchain accepts this transaction, it proves that the credit score is valid. Afterward, Teller can provide a competitive loan rate, confident that the borrower meets its scoring criteria. And because the user’s interactions occur locally within the web browser, the user maintains privacy.

Other products currently in development include zkOracles which connect real-world data to the blockchain and login credentials that allow users to access websites without handing over personal information.

Rapid Fire Notes for Other Protocols

Zcash pushed back its Network Upgrade 5 upgrade to around mid-May after experiencing a consensus bug in its testchain in March. One of the largest upgrades to Zcash since project launch, NU5 consists the deployment of the Halo 2 proving system on the protocol. Halo 2 removes the need to have a trusted setup and enhances scalability through recursive proof compositions.

Subsequently, core developers are expected to shift their attention to possibly transitioning Zcash to a PoS consensus mechanism. CEO of Electric Coin Company, Zooko Wilcox, argued that PoS eliminates selling pressure and improves productivity on $ZEC. Initial discussions have proposed using the Cosmos stack to support proof-of-stake due to its interoperability and existing developer community. The shift to PoS is expected to optimistically occur within three years with targeted efforts.

Polkadot’s parachain auctions continue. The near-term focus is on enabling greater cross-chain messaging within the Polkadot ecosystem. XCM, Polkadot’s protocol for cross-chain transactions, will be launched in its next upgrade. XCM was previously launched on Kusama, Polkadot’s canary network. However, due to a mismatch of versions between the Kusama relay chain and Karura parachain, an attacker was able to exploit ~11k $KSM (~$2 million).

XCM v3, Polkadot’s upgraded cross-chain messaging system, is currently being audited and should be released later this year. The new version of XCM will support NFT transfers across parachains, providing a needed boost to Polkadot’s NFT ecosystem.

Cardano deployed smart contract functionality last September, but applications on Cardano still suffer in user experience. After SundaeSwap, an AMM-style DEX, went live on Cardano, users reportedly had to wait hours or even days for their trades to clear. Therefore, Cardano’s focus is primarily on scalability now. This summer, it is expected to push an upgrade that would enable larger block size and higher transaction throughput.

Chainlink has three key areas for this year:

Crosschain Communication Interoperability Protocol (CCIP). Chainlink is doubling down on CCIP as user activity continues to surge across multiple blockchains. CCIP gives developers the ability to build cross-chain smart contracts. In theory, these smart contracts will be composable across multiple blockchains. By providing this universal communication protocol, developers will have additional flexibility to build applications that utilize different blockchains for specialized purposes.

Staking. Chainlink has developed an Explicit Staking mechanism. Unlike traditional staking mechanisms, this staking model uses quadratic functions to reduce the likelihood of any single attacker exploiting its system. As a result, the Chainlink ecosystem can expect an increased level of robustness for its 900+ decentralized oracles once staking is rolled out. The exact date of the launch is uncertain.

Enterprise partnerships. In 2021, Chainlink partnered with several large institutions including Deutsche Telekom, Associated Press, and Swisscom. As technical complexity across L1s and L2s remains high, Chainlink’s CCIP rollout will allow traditional enterprises to enter the industry without narrowing their focus to a few blockchains.

New blockchains to look out for this year:

• Espresso — Layer 1 PoS blockchain that is EVM compatible focused on scalability and privacy. It uses Configurable Asset Privacy for Ethereum (CAPE) to enable customized privacy guarantees for users.

• Aleo — Blockchain for private applications using Proof-of-Succinct-Work (PoSW) to maintain state and verify proofs. Aleo transactions are processed off-chain, and only verified (rather than executed and re-executed) by the network nodes.

• Aptos — Layer 1 blockchain backed by some members of the team behind Diem, Facebook’s attempted project. The team states that Aptos can execute over 160k TPS. Aptos uses coding language Move and aims to launch mainnet in Q3.

• Mysten Labs — Founded by four former Facebook employees that worked on Diem, Mysten Labs is launching Sui, an L1 platform with horizontal scalability. Unlike most current L1s, Sui forgoes consensus for most transactions, allowing it to parallelize transaction execution and reduce latency. Like Aptos, Sui is coded in Move.

Disclaimer

The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.

Roadmaps was originally published in Amber Group on Medium, where people are continuing the conversation by highlighting and responding to this story.

Summary

Automated market makers (AMMs) form the backbone of decentralized finance. They allow users to trade assets, create new markets, and earn yields, all available 24/7 and without a central entity. Since their inception, they have grown to execute over $180 billion of trading volumes.

DeFi moves fast. In this report, we review important AMM designs and market trends, highlighting some of the projects we find most interesting. We also discuss emergent behaviors that arise from AMMs, such as impermanent loss (“IL”), concentrated liquidity management, and just-in-time liquidity (“JIT”).

AMMs: Versioning Up

Automated market makers (AMMs) form the backbone of decentralized finance. They allow users to trade assets, create new markets, and earn yields, all available 24/7 and without a central entity. Bancor first introduced the constant product AMM in 2017, but its platform saw only modest adoption because each token was paired with Bancor’s native token. Only when Uniswap launched its v2, which by default paired tokens with ETH, did AMMs really take off. Total DEX volumes have skyrocketed from monthly volumes of $1 billion in May 2020 — when Uniswap v2 launched — to $186 billion in December 2021. Now, DEX volumes consist of ~12% of those from centralized exchanges.

DeFi moves fast. Since Uniswap’s maiden whitepaper, a whole range of new AMM designs has been launched to improve upon Uniswap’s initial design. In this report, we review important AMM designs and market trends, highlighting some of the projects we find most interesting. We also discuss emergent behaviors that arise from AMMs, such as impermanent loss, concentrated liquidity management, and just-in-time liquidity.

Uniswap v2 — Zero to Infinity

We first briefly introduce Uniswap v2’s constant product formula. Uniswap v2 consists of liquidity pools — smart contracts that hold reserves of two tokens and allow anyone to withdraw and deposit funds according to the formula x * y = k, where x and y are the reserves of two tokens, A and B. In order to withdraw token A from the pool, a user must deposit an appropriate amount of token B to maintain the constant k before fees. A deeper dive into how the protocol can be found in Uniswap’s documentation.

Uniswap v2 immediately gained market traction. It introduced permissionless creation of any liquidity pool, allowing anyone to trade a long-tail of assets generally not available on centralized exchanges. Compared to DEXs that attempted to replicate limit order books on-chain, Uniswap provided a superior user experience with an intuitive user interface and significantly lower gas costs.

Perhaps most importantly, it enabled composability with other DeFi protocols. Users can use their LP tokens as collateral, developers can query liquidity pools as price oracles, protocols can create liquidity mining programs to spur liquidity for their native tokens, etc.

As a testament to its importance, Uniswap’s v2 codebase is perhaps the most forked smart contract in crypto. And when a new Layer 1 or Layer 2 platform is created, often the first primitive launched is a version of Uniswap v2.

Uniswap v2 — One of the Most Forked Contracts

Curve — One to One

But despite its elegance, there are several drawbacks to Uniswap’s constant product formula. One inefficiency of Uniswap v2 is that the model doesn’t appropriately suit swaps between different types of pegged assets that should theoretically have a 1:1 exchange rate, such as stablecoins. The DAI-USDC pool in Uniswap v2, for instance, utilizes only ~0.5% of total capital available because most trading occurs at a rate between 0.99 and 1.01. Furthermore, swappers experience a high price slippage on these trades. At the time of this writing, a trader looking to swap 1 million USDC tokens into DAI would incur 2.4% price slippage and only receive ~976k DAI through Uniswap v2.

A more appropriate pricing function for these stableswaps would be a constant sum formula (x + y = k), in which the price of one asset in relation to another is always one. In a constant sum USDC-DAI pool where k=10,000, a user that deposits 500 USDC into a pool would receive 500 DAI in return (excluding fees) so that k continues to equal 10,000.

The problem with this model, however, is that the pool can be completely drained. A pool initially consisting of 50% USDC and 50% DAI could eventually consist of solely one token. In contrast, a benefit of applying the constant product formula to stableswaps is that it is impossible for reserves to be completely drained in a liquidity pool.

Curve’s stableswap formula finds the middle ground between these two approaches. The stableswap formula contains a dynamic variable that modifies pricing based on a liquidity pools’ balance. The pool can slide up and down the constant sum formula when pools are approximately balanced, providing a stable price close to $1. When the pool becomes imbalanced it behaves more like a constant product formula, making it more expensive to move the pool out of balance and incentivizing liquidity providers to balance the pool. This can be seen visually in the chart below, where Curve’s Stableswap invariant is “in the middle” between Uniswap’s invariant and the constant sum formula.

Curve Stableswap Invariant

Consequently, Curve’s stableswap formula is significantly more efficient for swaps between perfect or highly correlated assets, such as pairs between stablecoins, liquid staking to underlying assets (e.g., stETH — ETH), and wrapped assets (e.g., wBTC — renBTC). For the same 1 million USDC swap proposed above, Curve returns 999.7k DAI, a price slippage of only 0.03%.

USDC-DAI Rates on Ethereum

Uniswap v3 — The Universal AMM

Another drawback of Uniswap v2’s design is its capital inefficiency. Pools offered liquidity from a price range of zero to infinity, but the reality is that most assets do not trade across that wide range; thus, the majority of liquidity in v2 pools remains unused.

Uniswap launched v3 in May 2021 to address this efficiency. Its defining feature is the introduction of concentrated liquidity. Instead of providing liquidity across the full price range, users can specify the ranges in which they would like to provide liquidity. For instance, LPs can provide capital for the DAI-USDC pool between 0.999 and 1.001, offering a ~2000x improvement in capital efficiency.

Uniswap v3 also introduced custom swap fees for each pool at 1%, 0.3%, and 0.05%. These swap fees allowed liquidity providers to better tailor their margins to expected pair volatility. For swaps between perfectly correlated assets, such as stablecoins, pairs converge to the lowest fee tier. In contrast, pairs for long-tail assets often calibrate to 1% due to greater uncertainty.

Yuga Lab’s recent airdrop of Apecoin illustrates this behavior. For the first few trading days after Apecoin’s airdrop, DEX liquidity was primarily executed on Uniswap’s 1% fee tier during initial price discovery. After prices settled in a range between $8 to $15 and price uncertainty lowered, volumes moved to Uniswap’s 0.3% fee tier.

Uniswap LPs Migrating to 0.3% Fee Tier After Initial Price Discovery

Uniswap governance later added a 0.01% fee level, which is now the canonical fee tier for stablecoins. Combined with concentrated liquidity, volumes for USD stablecoin swaps on Uniswap are now on par with Curve’s.

USD to USD Stableswaps Concentrated At 1bps Fee Tier

USD Stableswap Volumes — Uniswap Volumes On Par With Curve’s After Introduction of v3 and 1bps Fees

Finally, v3 also allows users to provide range orders. These are similar to limit orders on traditional limit order book exchanges, except that they could be partially filled or re-crossed if the price changes direction.

In addition to unlocking capital efficiency, Uniswap v3 greatly expands the design space for liquidity provisioning with customized price ranges. For instance, Dan Robinson from Paradigm illustrated how any static AMM can be replicated using a series of Uniswap v3 liquidity positions. In addition, Uniswap v3 range orders can be used to mimic options strategies — an interesting area for further exploration but out of the scope of this report.

However, with greater complexity comes greater headaches for LPs. Because Uniswap v3 positions are reflected as NFTs instead of ERC-20 tokens, they break the widely used convention of fungible LP tokens. Major money markets, such as MakerDAO and Aave, still do not directly accept Uniswap v3 tokens as collateral. Liquidity providers also do not get the benefit of compounding returns. Instead, they have to manually collect fees if they want to redeploy liquidity. Moreover, whereas LPs could not outcompete each other in Uniswap v2 — everyone was being rewarded for sharing the same dumb strategy — the introduction of Uniswap v3 tilts the playing field in favor of market makers, professional traders, and whales who can constantly rebalance positions at the expense of retail LPs who may wish to “set and forget.”

And perhaps the biggest issue LPs are still grappling with is the risk of magnified impermanent loss.

Impermanent Loss

Impermanent loss (“IL”, sometimes called divergence loss) describes the phenomenon in which the value of a liquidity provider’s stake can go down despite income from fees. More specifically, it is commonly defined as the difference between the value of a liquidity position in an AMM and the value of an equivalent HODL position. The intuition behind IL is simple: a constant product AMM consistently purchases the underperforming token and sells the outperforming token. Therefore, an investment that would have appreciated 1000x outside the AMM is limited to a mere 14x within the AMM.

Impermanent Losses Can Be Quite Permanent

This IL can be reversed if the token in question returns to its original value — hence the name impermanent loss. Trading fees are meant to compensate liquidity providers for IL risk, but multiple studies suggest that generated fees are not sufficient to cover IL, and liquidity providers generally end up only profiting when a trading pair eventually reverts to its original rate.

Concentrating liquidity also concentrates impermanent loss. It is akin to providing leveraged liquidity — and similar to trading on leverage, both gains (from fees) and losses (from impermanent losses) are magnified. Intuitively, as one token moons, liquidity providers that defined narrower price range deplete their reserves of the appreciating token faster than those with wider ranges, hence accruing greater IL. But if correctly done, those LPs also earn a greater share of trading fees.

Tighter Ranges Have Greater IL Risks

Concentrated Liquidity Managers

Because of the added complexities in managing concentrated liquidity, a whole host of concentrated liquidity managers (CLMs) have been launched. CLMs offer several benefits, such as:

• Determining optimal ranges for providing liquidity by attempting to find the right balance between fee generation and impermanent loss;

• Adjusting ranges when liquidity moves out of range;

• Automatically compounding earnings back into liquidity positions; and

• Providing gas savings from rebalancing.

CLMs typically offer vaults in which users can deposit their tokens. Positions in these vaults are typically reflected as ERC-20 tokens, reintroducing fungible LP positions back into the DeFi ecosystem. For instance, although Aave does not directly accept Uniswap v3 positions, it does recognize G-UNI vault tokens, ERC-20 tokens reflecting a vault position in Sorbet Finance’s liquidity manager, as collateral. Additionally, protocols and DAOs can also outsource liquidity strategies and mining programs to these vaults instead. Instadapp, Liquity, OlympusDAO, and several other projects all leverage the composability of CLM vault tokens in their liquidity management strategies.

Some CLMs, such as Charm Finance and Sorbet Finance, adopt a passive rebalancing strategy in which rebalancing rules are set initially and published on-chain. Keeper bots are used to monitor the pool’s condition and rebalance if necessary. Others, such as Gamma Strategies, take an active rebalancing approach in which strategies are determined off-chain and often kept proprietary. Teams are also experimenting with letting the market decide the optimal strategy. Steer Finance and Sommelier Finance, for instance, plan to allow anyone to create and run their own strategies.

Overview of Concentrated Liquidity Managers

Based solely on yield generation, the effectiveness of CLMs is still questionable. Judged on ETH-USDC vaults, Gamma’s Hypervisor has underperformed a comparable Uniswap v2 strategy. Charm’s equivalent Alpha Vault only marginally outperformed. Furthermore, vaults that publish their rebalancing rules on-chain are vulnerable to being front-run — akin to a professional market maker that broadcast its strategy to the market before executing its trades. This is a low risk for now given their relatively modest TVL, but will likely become a concern if they continue to grow.

USDC-ETH Vault Performance

Research from the Bancor team also found little evidence that active liquidity management strategies perform better than passive LPs. In fact, it found that the only consistently profitable LP strategy — one where fees generated outweigh impermanent loss — is providing just-in-time liquidity, which we touch on in the next section.

More research needs to be done, but the outlook for meaningful outperformance is not positive. Sommelier Finance, a blockchain protocol built on the Cosmos SDK focusing on Ethereum DeFi strategies, originally focused on automating Uniswap v3 positions before pivoting to another direction. According to the team, even by running backtests where the team knew the future price of the token in advance, automated strategies were still unprofitable due to rebalancing costs (crystallizing impermanent loss and transaction costs).

Nonetheless, CLMs provide other benefits, such as enabling DAOs to more efficiently run liquidity mining programs and provide liquidity on DEXs. Therefore, they will likely continue to grow alongside greater adoption of concentrated liquidity.

Flash in the AMM

One of the arguably pernicious emergent behaviors from the introduction of Uniswap v3 is just-in-time (JIT) liquidity. JIT liquidity occurs when a trader (or more accurately, a trading bot) sees a pending swap transaction in the mempool that has yet to be included in a block on-chain. The bot carefully adds concentrated liquidity around an incredibly narrow range prior to the swap, allows the swap to occur, then removes liquidity, typically all in a single block. By doing this, the bot is able to capture a high percentage of fees for the “sandwiched” swap while virtually eliminating the risk of impermanent loss.

We provide a recent example of JIT liquidity below for a user looking to swap ~$80k worth of Apecoin. The trading bot minted a Uniswap v3 position consisting solely of $ETH (range order), allowed the user to swap $APE for $ETH in the next transaction, then removed liquidity afterward. Note that in this example, in addition to capturing an inordinate proportion of the swap fee (94%), the bot also profited from different prices listed on Uniswap (~$12.80 per $APE) and on centralized exchanges like FTX (~$13.19 per $APE).

Some argue that JIT liquidity improves the experience from the perspective of a swapper, who gets a reduction on expected price impact due to the spike in liquidity. In the above example, the bot added ~$40 million of liquidity into a pool that only had ~$18 million of TVL prior, improving depth.

However, passive liquidity providers lose out. They get their income from swapping fees diluted while still being exposed to impermanent loss and high market impact trades.

Fortunately, the impact of JIT liquidity is relatively muted for now as activity is mostly limited to two MEV bots. But profits attract competition, and these two bots have cumulative racked up ~$1.3 million of profits since last June. Greater growth of JIT liquidity could gradually disincentivize passive liquidity provision, and taken to its extreme, would result in a request-for-quote market in which users place limit orders and active LPs compete to fill them with JIT liquidity. In this scenario, price discovery is limited and users bear greater uncertainty about their expected execution price. And philosophically, this situation goes against one ethos of decentralized finance where users operate on a (relatively) equal footing as market makers.

Curve v2 — Concentrated Liquidity for Risky Assets

As mentioned above, Curve v1 concentrated liquidity at a 1:1 exchange rate for perfectly correlated assets, such as stablecoins and liquid staking tokens. Curve v2 aims to introduce this dynamic to volatile asset pairs by using a dynamic peg. It calculates an internal price peg for each liquidity pool based on the trading within the pool and concentrates liquidity around that peg.

Curve v2 Compared to Other AMM Invariants

The internal price is based on a running exponential moving average, which is similar to a simple moving average but places higher weights on most recent prices.

Curve v2’s Internal Price Oracle vs. Spot Price for CRV-ETH

Sometimes, an asset’s sudden price movement may warrant concentrating liquidity around another price. However, much like adjusting an out-of-range Uniswap v3 position, this makes an impermanent loss permanent. Therefore Curve’s internal price peg can readjust, but only when it is profitable to do so (i.e., when accrued profits from trading fees since the last re-peg outweighs the crystallized impermanent loss).

Moreover, trading fees within Curve v2 pools are dynamic. During periods of low volatility, trading fees are low (as low as 0.04%). In volatile times, trading fees are increased to harvest volatility and compensate liquidity providers for impermanent loss that occurs in directional moves.

The (Other) Curve Wars

Curve v2 could be appealing to liquidity providers as it offers the capital efficiency of Uniswap v3 without the active management of positions. Furthermore, because all LPs deposit into the same pool with the same price range, there are no JIT liquidity issues.

For now, Curve v2 is still limited to only a handful of pools. Its Tricrypto pool (USDT + wBTC + wETH) is its most popular, with ~$3 billion of monthly volume. Tricrypto volumes have significantly grown since last year, achieving nearly 40% of Uniswap’s volumes for the same pairs.

Tricrypto Volumes Stabilizing Around 40% of Comparable Uniswap Volumes

Tricrypto only sees between 20–30 daily active traders and 477 total unique users since inception — volumes are driven primarily by MEV (miner extractable value) bots running arbitrage strategies, DEX aggregators, market makers, and whales.

Activity Largely Driven by MEV Bots and Aggregators

Curve also offers v2 pools for a handful of other assets, such as CVX-ETH, CRV-ETH, and EURT-USDT. In practice, Curve v2 pools are often as competitive as rates offered by Uniswap and other DEXs.

Competitive Rates for Curve v2 Pools