Trends / Conversations

1. Data

   Been seeing more talk around cloud and data - case in point here with Georgios

   Comprehensive data ecosystem map can be found here - useful to identify some potential tokens - thinking of $POKT as a strong contender

   Co-processors might also benefit from this narrative, given its ‘data access’

   Others would be DePIN x AI plays like $MOBILE / $HONEY / $DIMO etc.

2. Solana L2

   Discussion can be found here

   Very interesting to see that the community is almost exactly 50/50 split at the idea of Solana L2

   Think the play here could be $NEON - since it is an EVM that capitalizes on Solana tx ordering mechanism to increase throughput - similar to the concept of L2s improving execution

   Areas that might be interesting to keep an eye out for should Solana L2s come to fruition would be composable solutions like shared sequencers (Rome Protocol), and perhaps bring some attention to ZK in Solana (Light Protocol)

3. L3s

   Market seems to be looking towards L3s for more use cases - is it a natural progression to L2s / is it a narrative - maybe it’s both

   Projects to keep a look out for would be $XAI and Stack, the recent L3 built using OP Stack for maintenance of points systems

4. State Bloat

   Discussion thread here

   Hasu and Jon discussed this topic in-depth in Uncommon Core podcast - will need to revisit it to find opportunities within this space

5. Execution Tickets

   Something is going on here but I have yet to figure out what is going on here

6. RWA

   $ONDO condo strong after BlackRock announces tokenizing of a fund with $BUIDL token. Clearpool has been performing very well

   We still have more to see from RWA chains like Plume and perhaps more from Avalanche

Upcoming Events

1. Electra Upgrade

   MaxEB will likely affect DVTs and LSTs, perhaps LRTs as well. - will have to listen to Jungle by Christine Kim to figure out opportunities there

   It is a 6 - 9 months timeframe before the upgrade rolls around - an opportunity to see price action similar to $OP and $ARB before EIP-4844 rolled around

2. Arbitrum Gaming Fund

   $400 mil gaming fund approved - $XAI seems to be the low-hanging fruit

   High-hanging fruit might be… actually playing the game and farming?

   A list of Arbitrum games can be found here

3. Liquid Staking / Restaking on Solana

   Sanctum launched - I see it as an opportunity to serve as liquidity layer of Solana - which is huge considering the amount of airdrops coming to the ecosystem soon (e.g. Kamino, Tensor, Parcl etc.)

   $JITO might catch a bid after they announce StakeNet - which is likely a piece of infrastructure for restaking

Picture this: A world where earning yield with ETH is less of a maze and more of an express lane to rewards. This is the world that Vector Reserve is building by offering vETH, an asset that amplifies the economic security of Ethereum, while offering users higher yield opportunities that are easily obtainable.

This article breaks down the various components of vETH, highlighting the core benefits brought about to users in particular. We will then dive deeper into the role of vETH and Vector Reserve’s native token, VEC, in the broader DeFi landscape. Welcome to the new chapter in DeFi's story, penned by Vector Reserve and vETH.

vETH - The Engine for Diversified Yield

What is vETH?

Vector Reserve aims to be the first Liquidity Layer to provide optimized staking and  restaking yield strategies. This is achieved by issuing the first Liquidity Position Derivative (LPD) token, known as vETH.

vETH blends Ethereum (ETH) and its derivatives: Liquid Staking Tokens (LSTs), Liquid Restaking Tokens (LRTs), and Liquidity Pool Tokens (LP), into a singular token.

Where does the yield come from?

The variety of assets backing vETH allows yield to be generated from multiple avenues. Let’s take a look at each of them.

• ETH LSTs generate yield natively from the Ethereum beacon chain which averages 3-4%

• ETH LRTs generate yield from rewards provided by other protocols that utilize ETH LSTs for cryptoeconomic security and have a variable yield

• ETH LPs would include ETH/LST and ETH/LRT pairs and generate yield from fees received from LPing, as well as emissions when applicable

Thus, vETH holders have the opportunity for exposure to a diverse set of yields coming from a variety of DeFi activities. This increase in yield sources allows users to manage their risk better amongst the different LST / LRT / LP offerings, while being able to receive a superior return on their assets compared to singular ETH derivatives.

Thus you can think of vETH as ETH that provides you with a diversified and sustainable source of dividends, similar to an Exchange-Traded Fund (ETF).

Introducing Superfluid Staking

Superfluid Staking uses Liquidity Position (LP) tokens, like those from Uniswap, Curve, and Balancer for staking on EigenLayer. Typically LP tokens have faced a lack of liquidity and composability with DeFi use cases, reducing the amount of potential yield that can be earned, all while exposing users to the downsides of impermanent loss and loss-versus-rebalancing (LVR). Superfluid Staking brings about the following advantages:

Key Advantages

• Dual Income Streams: By using LP tokens for staking, it unlocks liquidity and staking rewards, significantly boosting overall yield.

• Maintaining Liquidity: Unlike traditional staking, Superfluid Staking keeps assets accessible, enhancing investor flexibility with liquid, yield-bearing vETH.

• Market Leadership: As an early adopter, Vector Reserve sets itself apart, attracting investors looking for cutting-edge ETH yield opportunities.

Maintaining vETH’s Peg

Keeping vETH's value aligned with ETH is crucial for Vector Reserve, underpinning the platform's credibility and ability to maintain the value of user funds. To achieve this, Vector Reserve employs a nuanced strategy blending responsive arbitrage, strategic liquidity management, and risk-diversification tactics. This ensures vETH remains a reliable and stable investment in the face of market fluctuations.

Responsive Arbitrage

At the core of maintaining the peg is responsive arbitrage, adjusting for price variances between vETH and ETH swiftly to preserve the peg's integrity. Vector Reserve actively manages liquidity positions, tweaking strategies based on market conditions to maintain vETH's value.

Backed by Yield

Vector Reserve's diverse yield sources from DeFi activities can be used to bolster vETH's stability during times of volatility. By diversifying yield, vETH is exposed to a lower level of concentration risk, reinforcing its peg to ETH.

Responsive Liquidity Provision

The protocol adjusts its liquidity positions in response to market changes, optimizing yields and mitigating risks. These dynamic adjustments help stabilize vETH's value relative to its underlying assets.

Collateralization and Redemption

vETH's solid backing by ETH and its derivatives ensures a stable foundation. In extreme conditions, Vector Reserve may activate redemption mechanisms, aligning vETH's market value with its intrinsic worth through direct asset exchange.

If you would like to check out vETH, click here to learn more.

The VEC Flywheel

VEC is Vector Reserve's native token, designed to serve as a reserve currency that promotes the protocol's sustainable growth. While VEC also has governance utility, its primary function is to capture value from the protocol's revenue streams and treasury management strategies. This design ensures that VEC accrues value over time, making it an attractive asset for long-term holders.

Tokenomics

VEC's strategic distribution creates a strong community through a fair token launch. In addition, with a significant portion of the tokens being allocated to incentives, it helps to maintain sustainable usage and engagement over time.

VEC Value Accrual

Firstly, VEC holders are entitled to vETH revenue sharing. This means that a percentage of the yields received by the assets backing vETH (LST, LRT, LP tokens) will be shared with VEC holders.

In addition, VEC will also accrue value from the team’s management of the treasury. Vector Reserve's treasury team actively manages the vETH portfolio to maintain the desired beta equivalence with ETH. This involves close monitoring of market conditions and making informed decisions about asset allocations to effectively manage risks. The treasury diversifies holdings across various Superfluid Staking opportunities to optimize yield while mitigating potential risks.

The team's risk management strategies and portfolio diversification efforts are crucial in ensuring that vETH remains a stable and reliable asset, even in the face of market volatility. By carefully balancing yield optimization and risk mitigation, Vector Reserve aims to provide users with a robust and reliable investment vehicle.

Introduction of veVEC for Governance

VEC holders have governance rights, influencing protocol decisions and shaping its future. With sufficient liquidity, Vector Reserve will introduce veVEC which can be earned by locking/staking the gVEC/ETH Balancer LP(an 80/20 LP concept acquired from Balancer), enhancing token stability and governance influence, including directing liquidity and managing incentives.

The details of governance participation have not been released yet, but it could potentially be the following:

• % revenue share to VEC

• Treasury management strategies

• Directing LRT liquidity to certain pools

• Bribery mechanism for liquidity direction (bribe wars)

Bribery and Liquidity Direction

veVEC holders will vote on strategic liquidity allocations to the various protocols, which will be beneficial in enhancing the TVL of such protocols. VEC will probably see a Curve war-like trajectory where integrated protocols that want more liquidity for their LRT tokens, can bribe veVEC holders with voting incentives, to vote to direct VEC token emissions to their LRTs. By increasing token emissions to their LRT pair, it increases the APR for LPs, attracting more liquidity to that LRT, boosting the confidence of that LRT.

This kicks off a flywheel effect where the integration of protocols makes Vector Reserve an even more attractive product and attracts more users. This will then be translated to greater yields being earned, which will once again be returned to users.

The Future Path - Vector Reserve's Roadmap

vETH Integration into Metis Ecosystem

Vector Reserve’s proposal to integrate vETH into Metis was recently approved, which will allow for the creation of vMETIS. The Metis community can keep a lookout to tap into the various yield opportunities available.

Introducing gVEC

Currently, sVEC uses a rebasing model which means that rewards are distributed to users constantly, increasing their sVEC balance overtime. However, this makes sVEC less composable with other DeFi protocols, as the rewards may not go to the user if it’s used in another protocol.

To solve this, gVEC is introduced which utilizes a reward bearing or yield bearing mechanism, where the underlying gVEC increases in token value instead of token quantity. This allows gVEC to become more composable with both cross-chain infrastructure, as well as omnichain protocols, expanding its utility and user base.

vPoints System

The vPoints system is a game-changer for users, as it aggregates both EigenLayer Points and various LRT reward points, including ezPoints, Ether.fi's Loyalty Points, Kelp Miles, and Puffer Points. By holding vETH and svETH, users can accumulate vPoints and receive a proportional share of all the points accumulated by their capital. sVEC holders will also be able to gain vPoints, which are accrued through the VEC treasury.

With the constant introduction of new LRT protocols, not to mention the various point systems each of them carry, vPoints provides users with a seamless restaking experience by streamlining the management of LRT points. This allows the users to have a good exposure to prominent liquid staking protocols while keeping track of both EigenLayer and LRT points.

In the future when EigenLayer and LRT protocols go live, it is likely that redemption of points will be a much smoother experience via vPoints, as it takes away the need for users to interact with individual platforms and incur transaction fees across all interactions.

Get started with this seamless restaking experience now by minting VEC here.

Conclusion

Vector Reserve represents a significant stride forward for the DeFi space, offering a robust solution to fragmented liquidity and yield optimization challenges. Its innovative approach and strategic mechanisms position it as a platform with the potential to reshape the landscape of decentralized finance, promising enhanced yields and greater liquidity for the community it serves.

As Vector Reserve continues to develop, its future stands bright. The plentiful integrations will be able to attract more users on board and kick off the fly wheel of enhanced liquidity, volume, yield, and user acquisition.

Vector Reserve stands at the forefront of a new chapter in DeFi, one where innovation, stability, and community come together to create a more accessible and rewarding financial landscape. As we look to the future, the potential of Vector Reserve and its contributions to the DeFi world remain boundless, promising a journey worth watching—and joining.

Resources

Mint vETH: https://www.vectorreserve.com/dapp/veth

Mint VEC: https://www.vectorreserve.com/dapp/vec

Website: https://app.uniswap.org/swap?&chain=mainnet&use=v2&outputCurrency=0x1bb9b64927e0c5e207c9db4093b3738eef5d8447

Twitter: https://twitter.com/vectorreserve

Low Fees and MEV-Resistant Trades: Made possible through intent-based architecture

Special thanks to Anna and Alex for feedback and input on CoW Swap and its novel design mechanisms

Key Takeaways

• CoW Swap is an intent-based application that allows users to leverage signed messages to express their intent to trade (e.g. swap token A to token B)

• A batch auction mechanism is utilized, in which a network of solvers compete amongst each other to maximize user orders surplus, via Coincidence of Wants (CoWs) discovery and routing of trades to the best available liquidity on-chain

• The unique architecture employed allows CoW Swap to offer interesting features including CoW Hooks and Time-Weighted Average Price (TWAP) orders based out of the new Composable CoW Framework

• Additional benefits of using CoW Swap include MEV resistance, low fees / gasless orders and security by having solvers approve new contracts on your behalf

Introduction

Recently, CoW Swap has been gaining the hearts of traders, apparent from the constantly growing monthly trading volume. It’s well known for possessing an intent-based architecture, a narrative that has caught the attention of many with its user-friendly interface. However, under the hood, CoW Swap has a lot more than meets the eye. The CoW Swap team has been building non-stop, delivering prominent features, including (a) MEV Blocker (b) Limit Orders (c) Time-Weighted Average Price (TWAP) (d) CoW Hooks (e) Milkman ERC1271 orders and (f) Programmatic Orders.

This article will dive deep into the fundamentals of CoW Swap, explaining its architecture and the benefits brought about by it. We then end with an overview of the current protocol developments and what to expect from the protocol in the future.

What are AMMs?

To uncover the innovation driven by CoW Swap, one must understand automated market makers (AMM), a type of decentralized exchange (DEX) that allows users to trade one asset for another. AMMs use liquidity pools to match traders with liquidity for their trades, rather than a peer to peer approach typically used in traditional finance. For example, a user that wishes to swap ETH for USDC can do so in a ETH/USDC liquidity pool. Upon the swap, the ratio of ETH to USDC changes, to which the AMM will re-price the ETH remaining in the pool. To understand more about AMMs, you can refer to this link here.

AMMs typically require traders to submit a transaction from their wallet to be able to interact with the liquidity pools for swapping. As a result of this necessary interaction with the pools, AMMs settle trades in a sequential manner, based on the change in liquidity upon each swap. CoW Swap employs an intent based design which innovates on the traditional AMM design, connecting traders directly (when possible) with each other without using pools. Benefits of this innovation include lower fees and better execution prices, which will be explained in the later part. To understand the core innovations one must understand what intents are to begin with.

What are Intents?

Intents refer to the desired goal of a user, for example ‘I wish to swap USDC for ETH’. An intent-based protocol facilitates on-chain activities by abstracting the complex processes associated with it. A user can declare the end goal they wish to achieve ‘I wish to receive ETH’, and specify certain parameters ‘I wish to receive ETH by swapping USDC’. This message can then be signed to authorize sophisticated third-parties known as solvers to execute the intent, eventually delivering ETH to the user.

Here’s a visualization of an intent-based system:

Intents help make the process of achieving on-chain goals easier and less technical. Instead of going through a complex process to complete a transaction, a person can set their goal and some rules, and let others handle the technical details to make it happen. In practice a user can define the terms, and sign a message that other parties fulfill. This makes completing transactions on-chain simpler and more user-friendly, especially when multiple goals can be grouped together in one go, saving time and resources.

To learn more about intents, you can refer to this article here.

Introduction to CoW Swap

CoW Swap emerges as a premier example of intent-based applications, where users indicate their desired trade outcome, delegating the execution to third-party, permissionless agents called solvers. The core mechanism utilized by CoW Swap is known as batch auctions, which aggregates users’ intent (the orders they wish to carry out). Solvers compete to offer the most optimal execution route for these orders, which will maximize the user surplus (the amount of asset received by user after swap). The execution methods used by solvers can be a combination of both off-chain matching and on-chain swaps. Solvers are rewarded upon successful execution of orders within the batch auction.

The key difference between CoW Swap and other AMMs is the utilization of Coincidence of Wants (CoW), where overlapping user intents can be matched without being routed through a pool. This offers higher gas efficiencies and lower cost for users. In addition, given that user orders are not being routed through a public mempool, CoW Swap mitigates Maximal Extractable Value (MEV) problems, further contributing to a more optimized swap for users.

CoW Swap Transaction Execution Mechanism

Batch Auctions

CoW Swap’s batch auction mechanism aggregates orders and settles them together at once, in comparison to the traditional sequential execution of orders. Batch auction serves as the core pricing (price discovery) mechanism for CoW Swap. Orders are grouped together, where solvers (off-chain counterparties) compete to execute these orders either through off-chain matching or on-chain DEXs.

Solvers utilize advanced computations to customize trading routes for all orders in the batch auction, based on the user inputs (e.g. price, slippage tolerance etc.). Orders that fulfill Coincidence of Wants can be executed off-chain, while the remaining orders can be routed to other AMMs or DEX aggregators for execution. Thereafter, the settlement logic is passed on to protocols for execution, who are responsible in validating the execution legitimacy (approval of transaction etc.).

Let’s visualize the workflow of a batch auction:

1. A group of 4 users on CoW Swap submitted their orders off-chain via intents

2. These orders are aggregated into a batch and forwarded to the solver network

3. Solvers compete to provide the most optimal execution:

   (a) They will use their respective algorithm to identify the best execution route possible

   (b) Coincidence of Wants: Where orders match, the trade will be executed off-chain directly between the traders

   (c) Remaining orders that did not managed to be matched will be settled on AMMs / DEX aggregators

4. Solvers submit their settlement solutions to the protocol who then ranks them based on surplus maximization and proceeds to push on-chain the winning settlement

The main motivation of utilizing a solver network is to maximize the amount of assets that users can receive. This is achieved through the competition amongst solvers to source for the most optimal trading route with their fulfillment algorithm.

Solvers

Essentially, solvers compete to provide the best batch auction settlement by first identifying Coincidence of Wants within the batch. Thereafter, solvers will take note of any remaining trades that did not manage to be settled, and search through AMMs or DEX aggregators to settle them with the lowest slippage.

A detailed look into the workflow of solvers:

1. At the start of a batch, all off-chain orders are considered for inclusion

2. Selected off-chain orders will be aggregated into a batch auction by the protocol.

   Note: After a batch closes, no new orders will be included

3. Solvers receive the orders in a batch and proceed to optimize the order with the goal of having their respective order settlement solution pushed on-chain

4. The solution that offers the best clearing price, maxizming traders’ returns, will be selected

5. Winning solver will receive rewards in the form of COW tokens which are granted by the protocol to incentive solver competition

   At the moment, the entirety of the fee charged to users is used to cover ethereum gas fees. That said, it's been proposed on the CoW DAO forum, that the protocol may experiment with different fee models

At this current stage of the protocol, CoW Swap utilizes an allow-list authentication contract to determine the addresses that qualify as solvers. In addition, an address can qualify as a solver if they provide a bond stated on CoW DAO CIP7 (CoW Improvement Proposal). Upon discovery of malicious behaviour (deliberately not providing users with the best execution route etc.), the bond will be slashed. Thus, this bond is meant to ensure that solvers are aligned with both CoW Swap and users. Nonetheless, most solvers do not have such a hefty amount of upfront capital. In these scenarios, solvers can be vouched by any existing bonding pool owner.

The competitive landscape of CoW Swap's solver network is rapidly evolving. Initially, DEX aggregators like 1inch and 0x dominated, settling over 50% of transactions. However, their market share has declined, now accounting for less than 4% of transactions. In contrast, advanced solvers such as Barter and Otex have risen to prominence, now handling the majority of solver volume.

Sophisticated solvers can source liquidity from intricate places, which are generally not accessible by DEX aggregators. This might’ve caused existing DEX aggregators’ market share to decline, tipping the scale in favor of independent solvers.

Now that we have understood the general concept of batch auctions and the role of solvers, let’s take a deeper look into Coincidence of Wants and how they play a critical role in CoW Swap.

Coincidence of Wants (CoWs)

For traditional finance incumbents and even non-crypto natives, it might be eye opening to see a protocol named “CoW” Swap, transacting hundreds of millions of dollars of digital asset volume. CoW refers to Coincidence of Wants, which is an economic phenomenon where two parties each hold an item the other wants, allowing them to carry out a direct exchange.

To understand this better, let’s take the example of Alice and Bob:

• Alice wants to swap 1000 USDC to ETH

• Bob wants to swap ETH into 1000 USDC

In the above scenario, it is clear that CoW exists. This allows for trades to be settled directly between Alice and Bob, without the need for external market makers or liquidity providers (LPs) to provide the liquidity for trade execution.

Coincidence of Wants can vary in their complexity, these figures are a good depiction of simple, batch and intermediate Coincidence of Wants.

Ring Trade

What happens when there are more than 2 orders involved in a batch, and there isn’t an exact Coincidence of Wants to allow for these orders to be settled directly amongst each other?

Instead of having to wait for an exact match between 2 parties, ring trades allow for liquidity to be shared amongst various parties as shown in the figure below.

From the figure above, it's clear that participants don't need to have exactly what the other party wants to complete a trade. They can leverage the broader network of participants in the batch auction to acquire the desired asset. On the contrary, execution of these 4 orders on traditional DEXs will take place in a sequential manner, exposing all participants to potential price slippages and MEV. We'll delve deeper into the concept of MEV later in the article.

It is important to note that every ring trade is considered as a Coincidence of Wants, but not every Coincidence of Wants is a ring trade.

CoW Swap Features

Now that we have understood CoW Swap’s core architecture, we can dive into the unique features made possible.

CoW Hooks

CoW Swap utilizes ‘hooks’, which are custom code attached to an order that can be executed before and/or after a trade. Hooks are useful because they can save users time and gas by turning multiple transactions or intents into a single intent.

This is the crux of CoW Swap’s intent-based architecture. CoW hooks make it possible for users to string together a series of complex actions, which may include bridging, staking, swapping, provision of liquidity and many more, and execute this series in a single transaction.

CoW Hook Architecture

1. Pre-hooks

   Pre-hooks are intents that can be encoded into an order, and will be executed prior to a swap on CoW Swap.

   These actions are executed prior to an order’s signature being checked or tokens being sent from the user's address to CoW Swap.

2. Post-hooks

   Post-hooks on the other hand, are actions that are executed after the swap has completed, where the swapped tokens have been transferred to the user's address.

Let’s take a look at a specific example, where a user stakes on Lido, after closing a loan position on Aave.

1. Pre-hook: Close an open position on Aave by repaying the loan collateralized by USDC

2. Swap: USDC will be converted to ETH through CoW Swap

3. Post-hook: Stake ETH through Lido

Fees associated with hook execution are charged in the sell token of the swap, and cover 100% the execution costs. For example, when closing an open position on Aave, any additional fees will be paid in USDC. There is no need for users to hold onto additional ETH for the orders to be successful. This is beneficial as the process becomes more seamless, and prevents users from being unable to execute transactions due to lack of gas tokens.

CoW Hooks Use Cases

Some of the potential use cases made possible by CoW hooks include

1. Repaying a debt → Staking

   As mentioned in the above example for pre-hooks and post-hooks

2. NFT sniping → Selling the NFT → Swapping tokens

   Upon selling a sniped NFT, the amount received can be immediately swapped into the desired token. This reduces the asset volatility experienced by users

3. Claiming airdrops

   Sell airdrop tokens, while using airdrop tokens as gas

4. Automated LP position management

   a) Collect LP rewards

   b) Convert LP rewards into 50/50 of each asset in the LP pair

   c) Deposit both assets back into the liquidity pool to increase LP position

The image above shows that CoW hooks aren't just for DeFi activities, rather, they have a broad range of use cases. Various users, including NFT snipers and airdrop farmers, can also benefit from hooks. Over time, CoW hooks will likely introduce more nuanced and sophisticated use cases, catering to a wider range of users.

Time-Weighted Average Price (TWAP) Orders

What is TWAP?

Time-weighted average price (TWAP) is one of the most common algorithmic strategies used for executing trades. It is typically utilized when traders have a large order size and wish to reduce the impact on the market, as well as the slippage they suffer from it. For example, if a trader buys $1 million worth of $COW all at once, the price impact can be significantly high on AMMs due to the lack of liquidity. To prevent the price impact, a TWAP order would split the large order into smaller orders, which are executed over regular intervals, for a set period of time. Put simply, traders using TWAPs orders spread trades over time based on the average price in the TWAP calculation.

Mechanism of TWAP Orders [In Beta]

With CoW Swap, users can make a TWAP order by simply specifying the following metrics

• Asset of choice (e.g. USDC/ETH)

  • Users choose the asset they wish to swap out of and the asset they wish to swap into

• Total order size

  • Total amount to be swapped

• Number of parts

  • This is the number of times the order will be split into

• Duration

  • This refers to the length of time over which the order will be executed

The amount to be executed per swap can be calculated by total order size / Number of parts. And the intervals at which the swaps will be executed can be calculated by Duration / Number of parts.

In addition, users will also be able to specify the price protection. The TWAP order placed will not execute should the price of the asset drop beyond the percentage set for price protection. This is meant to protect the user’s capital and prevent them from buying into a potential black swan event (e.g. cascading liquidation) that could result in them entering a position with disadvantageous prices.

Benefits of TWAP Orders

There are multiple benefits that users can gain through TWAP orders:

1. Reduced Price Impact

   Users typically have to pay a higher price when executing large orders on automated market makers (AMMs). This is due to the price impact of the order, where the inflow of large volume causes the price within the liquidity pool to spike up. In addition, big orders are also prone to sandwich attacks by MEV bots, essentially inflating the purchase price for users.

   With TWAP, the orders made each time are of smaller sizes. As apparent from the above figure shown for TWAP’s mechanism, instead of executing a $1000 order, it is split into 5 x $200 orders. This effectively reduces the price impact that users suffer, allowing them to swap at a fairer price.

2. Reduced Slippage

   With bigger orders, users generally have to account for a higher slippage for the order to be filled. This is due to the price impact it brings to the market, which requires the slippage to account for the difference.

   With smaller orders, users can set a lower slippage. This allows them to execute the order at a price point closer to what they desire. In addition, it also helps them to reduce the amount lost to slippage, in turn receiving more of the desired assets.

3. Increased Flexibility

   Users are able to customize the various metrics to decide how much they want to execute over each interval. In addition, since the order is submitted off-chain, users will be able to make changes to their TWAP orders based on market conditions, without incurring additional fees.

CoW Swap’s Unique Benefits

MEV-Resistance

Maximal extractable value (MEV) refers to the profit that validators can earn through arbitrage, which includes inclusion, exclusion and re-ordering of transaction sequence while building a block.

Often, MEV is seen as a negative externality as they result in users suffering from unfavorable prices or failed transactions. Broadly speaking, there are 3 types of MEV: (a) Front-running (b) Back-running (c) Sandwich Attacks:

• Frontrunning: Attacker places a transaction before a targeted user’s transaction to benefit from the upcoming transaction.

• Backrunning: Attacker places a transaction after a trade to benefit from the already placed transaction.

• Sandwich Attack: Attacker places a transaction before and after a user's transaction to manipulate the asset price, thus profiting from arbitrage.

To understand more about MEV and examples, you can check out this article here.

With CoW Swap, there are 2 main mechanisms that minimizes the level of MEV users are exposed to:

1. Coincidence of Wants: No Exposure to Transaction Order Manipulation

   Traditionally when trading on a DEX, users will submit their orders, which will be sent to a public mempool, which is where transactions sit before being confirmed by validators. This public mempool is heavily monitored by bots looking to profi from arbitrages. On CoW Swap, user orders are submitted and matched off-chain through solvers. Hence, the orders are not routed through a public mempool, preventing any other users from potentially front-running the order.

   Here’s an example of MEV that could occur in a typical DEX. Claire wishes to make a swap 10,000 USDC into ETH, a user that is monitoring the mempool will attempt to insert their own transaction (swap 10,000 USDC for ETH) before Claire. This increase in ETH demand will cause the ETH price to increase. When it’s time for Claire’s swap to execute, she will be faced with a higher ETH price, resulting in her receiving less ETH than what she originally had.

2. Batch Auction: Uniform Clearing Price (UCP)

   Typically, orders on a DEX are executed in a sequential manner. This creates the opportunity for MEV as builders can re-order the transaction ordering to generate profits. However, this change in execution order results in users receiving different prices for their trades. For example, an order executed later might have to pay a higher price, causing the user to receive less assets than what would have been the original case.

   With CoW Swap’s batch auction, a mean settlement price will be calculated for all orders within a batch. Hence, there will be no MEV available for extraction since reordering of orders will be pointless.

   You can learn more details about the different types of MEV here.

Gasless Transactions and Low Fees

One other key value proposition is the fee optimization made available to users, which comes from various aspects:

1. Off-Chain Signing

   Since the orders are submitted off-chain, there is no need for the users to pay gas with the chain native token. In addition, it is impossible for users to be faced with failed transactions, preventing them from paying unnecessary gas.

   In addition, since the orders are submitted off-chain, users are free to make as many orders as they wish, and are also able to cancel the orders as and when they want.

2. Coincidence of Wants Transactions

   Through direct matching of transactions, there are no additional fees charged to the users, which would have been the case should users have traded on other DEXs such as Uniswap.

CoW Swap’s Future Outlook

CoW Swap has laid down plans to further decentralize the protocol in the future. One aspect in which they do so is through a permissionless solver model which encompasses 2 main components:

1. Logic for solvers to be deemed suitable will be encoded into the smart contract

2. Staking of assets by solvers to disincentivize malicious behavior

WIth a permissionless model, we can anticipate CoW Swap’s solver network to become highly robust. This eventually translates to better settlement for users, as the competition amongst solvers will strive to bring the best terms to users.

Conclusion

CoW Swap was one of the pioneers in experimenting on intent-based architecture and bringing it to the masses back in 2021. Since then, more projects have embarked on this field to optimize the various aspects. Anoma, is working on integrating intents into a chain. Propeller Heads, is working on fine-tuning the solver elements and searching for ways to make it more robust. With such a level of interest and research by the broader industry, it is certainly exciting to see how CoW Swap will continue to develop.

Sources

• Introduction - CoW Protocol

• CoW Swap Dune Dashboard

• CoW Hooks

• An Introduction to Intents and Intent-centric Architectures | Blog - Anoma

• Intent-Based Architectures and Their Risks

• How CoWs Will Save DeFi Swaps

• Introducing the Programmatic Order Framework, from CoW Protocol

Investment Disclosure: The authors hold material positions in the assets discussed in this article. The content presented is for informational purposes only and should not be construed as financial or investment advice. Please perform your own due diligence before making any investment decisions.

In this article, I bring you through the framework I used to value the FDV of Restake Finance ($RSTK).

Disclosure: Author holds $RSTK. Nothing expressed in this article is considered as financial advise. These are just the author’s thoughts and personal views.

Framework

Note: Calculations in Appendix

1. Project the growth in LST TVL over the year of 2024

2. Calculate the current LRT TVL / LST TVL ratio - 3 scenarios

   This ratio is taken as the bear case for the TVL that LRT protocols can achieve

   The neutral and bull case are taken as 5% and 10% respectively - Speculating that the proportion of staked ETH that gets restaked will increase over time

3. Calculate the potential market share that Restake Finance can have - 3 scenarios

   The current LRT market share distribution is taken as the bear case for Restake Finance’s market share - Calculated by taking mainnet and testnet figures

   The neutral and bull case are taken as 5% and 15% respectively - Speculating that Restake Finance will be able to attract a higher volume of staked ETH compared to other LRT protocols

4. Calculate Restake Finance’s revenue in each of the cases

   Revenue = 5% x EigenLayer Yield x Restake Finance’s Market Share

   Note: 5% is the revenue cut that Restake Finance takes from the yield to users

   There will be 9 distinct annualized revenue

5. Calculate weighted revenue for various Restake Finance market share scenarios

6. Calculate weighted revenue for various LRT / LST ratio scenarios

   Once this step has been completed, there will be 1 single annualized revenue

7. Find industry P/S ratio

   Using the LST market as a proxy

   Industry P/S ratio = Avg weighted (individual LST protocol P/S ratio x market share)

8. Find Restake Finance valuation

   Industry P/S ratio x Restake Finance’s annualized revenue

Conclusion

The eventual valuation I calculated for Restake Finance = $310,346,354

Current Restake Finance FDV = $220,000,000 (as of 11 January, 2024)

This projected FDV corresponds to a price of $3.24.

Hence, it can be argued that there is still growth potential for $RSTK.

It should also be noted that the valuation for Restake Finance can be even higher should we factor in additional yields, as it would increase its revenue. For example, AVS might incentivize restakers on Restake Finance to secure their protocol by offering extra yields to a particular vault (something similar to Curve wars).

In addition, the calculations were done over a 1-year period. Extrapolating it over a longer period of time will likely yield much higher annualized revenue.

To meme it, we apply a 3x multiple because of:
(a) 1st liquid restaking token to be launched
(b) Hype from the launch of AVS

And that would be a price of $9.72. NFA. I’m a Cookie that can’t count.

Appendix

1. Traditional Consensus Mechanisms

2. What is Proof-of-History (PoH)

3. Technical Dive into PoH

4. Delegated Proof-of-Stake (DPoS)

5. High Level Overview of Solana’s Consensus Mechanism

6. Conclusion

A blockchain’s consensus mechanism is responsible for validating transactions’ validity and adding them to the blockchain in an accurate sequence. Depending on the consensus mechanism chosen, the efficiency of the validation and ordering processes differs, resulting in different levels of throughput. In the realm of blockchains, Solana is a high-performing chain, with a 400ms block time and transactions per second (TPS) averaging between 2,000 to 3,000, with a theoretical peak TPS of 65,000 (for reference, Ethereum’s TPS is roughly 12).

This article aims to highlight a couple of Solana’s architectures that play a critical role in contributing to it’s high throughput, namely it’s Delegated Proof-of-Stake (DPoS) consensus mechanism and Proof-of-History (PoH) mechanism.

1. Traditional Consensus Mechanism

Let’s begin by understanding one of the key existing bottlenecks of blockchains: scalability.

Each node in a decentralized blockchain network has its own internal clock that it operates by. When a transaction occurs, nodes will timestamp the transaction according to this local system clock.

The eventual confirmation or rejection of the transactions will also be timestamped according to this local system block. With traditional consensus mechanisms such as Proof-of-Work (PoW) and Proof-of-Stake (PoS), all the nodes will have to communicate with each other to establish that time has passed.

For a decentralized blockchain with thousands of nodes all over the world, discrepancies between the nodes’ local system clocks are bound to surface, resulting in the timestamps of transactions differing between nodes. This emerges as a problem when nodes have to reach a consensus with regards to which transactions have taken place and the order of these transactions in the block. This is known as the timestamp synchronization problem and becomes more severe and complex when a network enhances its decentralization by increasing the number of nodes.

Eventually, this creates a possible path for malicious attacks. The discrepancy in time allows malicious actors to broadcast fake transactions that are similar to the real timestamps in an attempt to take over the network. To prevent this manipulation of transactions, a lot of time and processing power need to be spent to verify the timestamp accuracy. This can potentially result in a delay in block confirmation or even block rejection (nodes might vote for the block to be invalid because of the different timestamps).

2. What is Proof-of-History (PoH)

Proof-of-History (PoH) is used in Solana to prove that transactions are placed in the correct sequence, and this can be easily verified by validators in the network.

Contrary to what was mentioned in section 1, where nodes have their individual clocks, PoH can be thought of as a global block that all nodes use to verify the passage of time between two events. With this universal clock, nodes view the same historical record of transactions, abstracting away any potential disagreement on transaction ordering. This allows for consensus to be reached quickly and significantly reduces the time taken for a transaction to be verified and added to the blockchain.

PoH relies on a cryptographic method to create a continuous, chronological record of transactions. Let’s dive a bit deeper into this.

3. Technical Dive into PoH

Each transaction is processed through SHA-256, a cryptographic hash function known for its ability to take any input and produce a unique, unpredictable output. When a transaction is hashed, its output becomes the input for the next transaction's hash. This process results in an inbuilt order of transactions within the hashed outputs, creating a long, continuous chain.

PoH leverages Verifiable Delay Functions (VDFs), which are essential in verifying the passage of time within the blockchain. VDFs are computationally intensive functions that not only depend on the previous hash but also incorporate the time elapsed. This mechanism allows Solana to demonstrate, cryptographically, that real time has passed in generating sequential outputs. As a result, there's a clear, verifiable order of transactions, ensuring one consistent timeline of events. Validators can thus easily verify how much time has passed, further enhancing the network's trustworthiness.

The use of PoH in Solana adds a robust layer of security and integrity. Tampering with any part of the hash chain would necessitate recalculating all subsequent hashes, an effort-intensive endeavor that safeguards the network against alterations.

PoH significantly reduces the amount of information validators need to process per block. By using hashed versions of transactions' latest state, block confirmation times are drastically shortened. When validators (or replicator nodes) receive a block, the PoH sequence provides them with a cryptographically reliable transaction order, which they can trust without re-verification. This efficiency is vital in expediting the consensus mechanism, as the network can swiftly select and move on to the next validator for block validation.

4. Delegated Proof-of-Stake (DPoS)

With a better understanding of PoH, this section explains how PoH is utilized in Solana’s consensus mechanism - DPoS.

​​In DPoS, every validator that stakes $SOL will be able to participate network governance - voting on the validity of blocks and whether it should be added to the blockchain. $SOL holders (me and you) who prefer not to directly engage in the staking process can delegate their tokens to other validators, effectively making them delegators. This delegation process allocates delegators’ voting rights (proportional to the amount of $SOL they have) to these validators. In return for staking $SOL, the delegators will receive a portion of the block reward.

The DPoS system operates on the principle that nodes with larger stakes have a higher likelihood of being chosen to validate transactions and add them to the blockchain. This opportunity to earn block rewards incentivizes nodes to maintain a high level of performance and integrity.

Given an understanding of both DPoS and PoH, let’s put the knowledge together to get an overview of what a typical block confirmation will look like on Solana.

5. High Level Overview of Solana’s Consensus Mechanism

1. Selection of a Leader Node

   The leader node will be responsible for generating a PoH sequence (ordering transactions) and creating blocks.

   This selection process is based on the stake weight a node has, which is increased by having token holders delegate to them. The leader role will be rotated among validators.

2. Timestamping Transactions

   The leader node will receive transactions, and timestamp them using PoH to give rise to a transaction order.

3. Block Creation

   With the sequence from PoH, the leader node then proceeds to create a block

4. Block Propagation

   The newly created block will be sent to replicator nodes (the other validators within the decentralized network)

5. Transaction Validity Verification

   Replicator nodes will verify the following two components:

   Transaction Order: Verify that the transactions are in the right order by using the PoH sequence. Since it is an universal clock, this verification does not require back-and-forth communication between nodes (as with common consensus mechanisms like PoW and PoS).

   Transaction Validity: Check that transactions adhere to network rules and are valid.

6. Block Finalization

   Upon verification of both transaction order and validity, the block will be added to the blockchain. The next leader node will be selected, and the process starts again.

6. Conclusion

Solana has been working tirelessly to improve the architecture of its blockchain, with recent developments including QUIC, stake-weighted QoS and localized fee markets. In addition, the ecosystem is anticipating a significant improvement to its efficiency with the launch of Firedancer. It is worth keeping a lookout for the new use cases that can be built on top of Solana with its unique architecture - OPOS (Only Possible on Solana).

In the meantime, do check out the protocols built on Solana here and try interacting with them!

References

• Helius | Proof of History, Proof of Stake, Proof of Work - Explained

• Anatoly | Proof of History: A Clock for Blockchain

• Gemini | Solana (SOL): Scaling Crypto to the Masses

1. 1inch Fusion offers users the most favourable swap rates while being MEV-resistant

2. A dutch auction model is utilized, where the swap rate is decreased over time

3. Orders are filled by resolvers, which are professional market makers, to give the best rates

4. Users get to swap gas-free, as gas is paid by the resolvers

What is 1inch?

1inch is a decentralized exchange (DEX) aggregator that aggregates liquidity across the various DEXs. This contributes to deep liquidity on 1inch, offering users better rates and minimizing the slippage incurred.

1inch Fusion

1inch Fusion was launched, with the goal of further improving the cost efficiency and security of swaps for users. This is achieved by utilizing a dutch auction order matching model, where users are able to customize order inputs (price range, time period for swap etc.). These orders are filled by parties known as resolvers, which are sophisticated market makers that source for the best settlement rates for swaps.

Through this model, users are able to get better rates while saving on gas fees (paid by resolvers). They also benefit from MEV-resistance from the batching mechanism utilized by resolvers. More details on the benefits can be found in the later part of this article.

In this article, we will explore the following:

1. 1inch Fusion Stakeholders

2. 1inch Swap Engine | Dutch Auction

3. 1inch Fusion | Order Filling Mechanism

4. 1inch Fusion Benefits

1inch Fusion Stakeholders

Let’s first begin by understanding the stakeholders involved in 1inch Fusion.

Resolvers

What are Resolvers?

Resolvers are the key to order-filling in 1inch Fusion. They are fully automated algorithms developed by professional market makers and comprises of the following components:(a) Resolver’s Backend: Server app that determines which orders and when to fill(b) Resolver’s Account: EOA that is whitelisted by staking $1INCH(c) Resolver’s Workers: Execute swaps received from resolver’s backend

Resolver Whitelist

For resolvers to participate in swap execution, they have to be whitelisted.

Whitelist criteria:(a) The amount of unicorn power held must be among the top 10 of all resolvers(b) Resolver has to hold 5% or more of the total unicorn power in 1inch protocol

Unicorn power is received by staking $1INCH to receive $st1INCH. Resolvers can accumulate sufficient unicorn power through the following approaches:(a) Stake more $1INCH / Lock $1INCH for a longer period(b) Attract delegators to delegate their unicorn power

Resolvers are prioritized for order filling based on the total amount of unicorn power held (resolvers’ own + delegates’).

Dynamic whitelist

The unicorn power distribution among resolvers will change over time, based on the amount of $1INCH resolvers themselves stake, as well as the unicorn power received from delegators.

Resolvers who no longer meet the whitelist criteria will be removed from the whitelist, removing their rights to fill orders.

Fee Bank

In the process of filling orders, resolvers pay for the gas fees. This fee is automatically deducted from the resolver’s fee bank, a smart contract that escrows the deposit made by resolvers. Should there be insufficient balance in the fee bank to pay for transaction gas fee, users’ order will be reverted.

Setting Up a Resolver

The process of becoming a resolver can be summarized in these steps:

1. Gain enough unicorn power to be listed among top 10 registered resolvers

2. Pass through a verification procedure

   This is required to ensure that resolvers are trustworthy actors. The verification procedure involves KYC (know-your-client) / KYB (know-your-business) by Synaps as well as a wallet screening by TRM Labs to ensure that the resolver is not involved in illicit activities.

3. Register as a solver and set up wallet address for trade execution

4. Deposit $1INCH into FeeBank to cover resolving fees

5. Start resolving swaps

Delegators

What are Delegators?

Users who have staked $1INCH to receive $st1INCH will be eligible to earn unicorn power. This unicorn power can be delegated to resolvers, helping resolvers qualify for the whitelist. In return, delegators will earn rewards, which differ based on the resolver they delegate to.

Delegation Process

1inch Fusion has created a default farm for each resolver, allowing users to delegate their unicorn power with a single click, as shown below.

The rewards provided by the resolver will be distributed proportionally to the delegators based on the amount of unicorn power and period they have delegated. Rewards received by delegators can be staked on 1inch again to receive more unicorn power, which delegators can choose to delegate to their choice of resolver once again.

Note: Delegators can only delegate their unicorn power to 1 resolver at a time.

1inch Swap Engine | Dutch Auction

The crux of 1inch Fusion lies in its swap engine, which features an order-matching mechanism known as the Dutch Auction model.

In this model, users will place a gas-less order with a certain price range (users decide the maximum and minimum they are willing to receive) and time range (the time users are willing to wait for order fulfilment). Upon the start of the auction, the swap rate will decrease over time to the minimal return amount (stipulated by users) until it becomes profitable for resolvers to fill the order. Multiple resolvers will be competing to fill the orders, increasing the chances of users receiving a favourable rate on their swaps.

Execution Options

There are 4 options for users to choose from:

1. Auto

   The price and time range is automatically selected, based on market conditions and swap size, to provide users with the maximum return amount.

   This is a suitable choice for users looking to swap a large amount.

2. Fast

   The auction time is reduced to 3 minutes for the order to be filled within the 1st few blocks.

   Users that choose this option are willing to accept slightly less desirable rates in order for their orders to be filled as fast as possible.

3. Fair

   The auction time is increased to 6 minutes. This gives more time for the users to potentially receive a more desirable swap rate based on how the market conditions change during the auction period.

4. Custom

   The price and time range is fully customizable by users.

   Note: Users have to be careful while choosing the minimum price range as it could potentially result in a large slippage.

1inch Fusion | Order Filling Mechanism

In this section, we will dive deeper into the order-filling mechanism.

Order Filling Mechanism

1. User enters order details into the 1inch UI: (a) Token (b) Amount (c) Auction type

2. Order details are sent from 1inch UI to quoter

3. Quoter requests for the current market price from the pathfinder

4. Pathfinder will return the current market price to quoter

5. Based on user order input and current market price, quoter calculates price curve and returns it to 1inch UI

6. 1inch UI displays the expected return amount to users

7. User signs order with their wallet

8. Signed orders are sent from the 1inch UI to 1inch relayer (backend)

9. Resolver backend polls 1inch relayer for orders

10. 1inch relayer will provide resolvers with available orders

11. Resolver backend determines the orders to be filled and sends execution instruction to resolver worker

12. Resolver worker executes the trade

Price Curve Calculation

The quoter mentioned above is a sophisticated backend service that is designed to maximize the return amount for users. Based on the input supplied to it, the quoter defines a proper limit price curve.

The price curve provided by the quoter is a piecewise linear function which is dependent on parameters including network swap volume, gas costs, order details (token type, price range, time range) etc. An example of the price curve can be seen in the following diagram:

Blue Line: This is the price curve which determines the amount users will recieve at each block. As auction time elapses, the amount received by users will decrease, increasing the profitability for resolvers to fill the order, and thus the chances of user order being filled.

Top Horizontal Dotted Line: Marks the auction start amount. This corresponds to the maximum price set by the user, and returns the highest amount to the user should it be executed.

Middle Horizontal Dotted Line: Represents the amount returned to user should the order be executed at the market price (retrieved from pathfinder)

Bottom Horizontal Dotted Line: Mark the auction end amount. This corresponds to the minimum price set by the user, and returns the lowest possible amount to the user (within the order details inputted by users)

Blue Diamonds on Curve: These represent block timestamps. In each block, the minimum amount that the resolver has to return to users differ. If a resolver is able to execute the trade and receive an amount higher than the minimum, they get to keep the excess as profit.

Pink Diamonds on Curve: These represents the key points where the price curve will change its gradient, and determines the drop in swap rate.

1inch Fusion Benefits

Cost-Efficient

Users are able to benefit from gas-free transactions as it is paid for by the resolvers.

In addition, resolvers can divide the token amount to be traded into smaller batches for execution at several price points over the auction period. This can potentially reduce the price impact and users can have their orders filled at their desired price.

MEV-Resistant

Resolvers bundle the orders prior to sending them to the mempool. This prevents MEV attacks in the form of front-running and sandwiching, which traditionally has led to significant loss of user funds.

Deep Liquidity

Given that the 1inch swap engine powering 1inch Fusion is built on top of 1inch’s Aggregation Protocol and Limit Order Protocol, users benefit from deep liquidity at all times.

Thoughts & Questions

Thoughts

The resolver competition is very beneficial to users. Resolvers that have the best algorithm and execution will be able to return the greatest amount to users and also maintain high profitability. A portion of profits can be channeled to rewards for delegators, further increasing the unicorn power held by these high performing resolvers. They will then be prioritized for order filling based on the quantity of unicorn power held, creating a flywheel effect.

Resolvers are able to run incentive programs to attract delegators. This shows some resemblance to that of bribe markets such as Convex. It is an interesting mechanism, but I am curious with regards to resolvers’ profitability should this be a significant cost for them.

Questions

Is it possible to expand the number of resolvers to more than 10? With greater resolver competition to fill orders, users can potentially benefit from even more favourable rates. Is the cap on the resolver quantity meant to maintain resolvers’ profitability?

In the case of insufficient deposits in the fee bank, the user’s order will get reverted. Does this result in latency for user order fulfilment? Is it possible to integrate an auto top-up mechanism for resolvers, in order to reduce the frequency of such order reversion.

Is there any possibility to rehypothecate the unicorn power delegation?

Conclusion

All in all, 1inch Fusion features a suite of benefits for users with the increased cost-efficiency, as well as the MEV-resistance.

Stay tuned for a comparison of 1inch Fusion, CowSwap and UniswapX!

Key Takeaways

1. High Performance | Solid stats

   10,000 TPS. 1 second block time. 1 second finality.

2. EVM Compatible | Building is a piece of cake

   Full EVM Bytecode Compatibility: Applications built for Ethereum can be deployed on Monad with no code changes

   Full Ethereum RPC Compatibility: User-facing infrastructure (e.g. MetaMask) can be used seamlessly

3. Unique Architecture | The core to high performance

   2 main fundamental architecture employed by Monad to allow for high performance: (1) Parallel Execution (2) Superscalar Pipelining

1. Introduction

The blockchain landscape has constantly been evolving and we have seen numerous contestants attempting to improve upon Ethereum’s architectures. Teams provide more sophisticated technology aimed at attracting more builders to create better protocols, with the eventual goal of gaining more users. Despite all the competition, Ethereum has remained as the dominant blockchain, with the greatest amount of total value locked (TVL) residing in the ecosystem.

Due to the scalability issues faced by Ethereum (i.e. network congestion, high gas fees etc.), many teams have come forth to build their solutions, contributing to the competitive blockchain landscape. Some of the more prominent contestants to Ethereum include:

• Ethereum virtual machine (EVM) layer 1 (L1s) including Tron, BSC, Avalanche, as well as non-EVM L1s including Solana, Aptos, Sui and many more

• Layer 2s (L2s), with Arbitrum and Optimism currently leading the race, alongside more optimistic (i.e. Base, Mantle etc.) and zero-knowledge (ZK) L2s (i.e. zkSync, Starknet etc.) being built

Blockchains tend to strive for EVM-compatibility, which allows for applications built on Ethereum to easily port over while maintaining a familiar user experience. This is viewed as important for teams as it serves as a gateway to access the mammoth TVL available in Ethereum.

To have a better understanding of the changing blockchain landscape, you can refer to this really well written article by Xpara from Four Pillars Research.

Monad joins the playing field, building a L1 aimed at optimizing the efficiency of blockchains beyond what EVM chains can currently achieve. This article will be diving into Monad’s architecture, with technical concepts explained with graphics as far as possible, and a detailed look at the benefits brought about.

2. Monad’s Architecture

The key to Monad’s high performance lies it its parallel execution, to which superscalar pipelining is a complementary concept.

Pipelining: Breaking down an instruction set into successive steps. In turn, these steps can be executed concurrently (in parallel).

Let’s understand pipelining through the example below, where the task of laundry has been split into 4 successive steps: (1) Wash (2) Dry (3) Fold (4) Store. As a result of this, the steps can now be carried out in parallel. When the first basket of clothes are placed into the dryer after washing, the washer becomes available for basket 2.

Now that we have understood parallel execution and superscalar pipelining, we can move on to learn more about Monad’s consensus and execution mechanisms.

3. Monad’s Consensus

There are 4 key areas to Monad’s consensus, here’s a brief introduction before diving deep into each:

• (a) MonadBFT: Consensus mechanism

• (b) Shared Mempool: Block propagation through hashes

• (c) Deferred Execution: Decoupling execution and consensus

• (d) Carriage Cost and Reserve Balance: Prevent spam from deferred execution

3.1 MonadBFT

Definitions

• Byzantine Nodes: Malicious nodes

• Quorum Certificate (QC): 2f + 1 validators (majority) votes for ‘yes’

• Timeout Certificate (TC): 2f + 1 validators (majority) signed timeout messages

Default Assumptions

• Total Number of Nodes: 3f + 1

• Maximum Number of Byzantine Nodes: f

• Non-Byzantine Nodes Required: 2f + 1

Flow

Let’s understand the MonadBFT mechanism with a specific example.

(1) round k

• Leader Alice will send out a new block (k) and a QC from the previous round k - 1

• Validator nodes will review the block (k) for adherence to protocol rules → Vote

• Signed votes will be sent to the leader in the next round k + 1

(2) round k + 1

• Leader Bob will propose block (k + 1) and the QC from round k

• Validator nodes will review the block (k + 1) for adherence to protocol rules

• Validator nodes see the QC for round k in block (k + 1)

  • But Alice’s block (k) might not be finalized yet

  • This is because the leader Bob might be malicious and have sent block (k + 1) to less than 2f + 1 validators

• Validator votes → Signed votes will be sent to the leader in the next round k + 2

(3) round k + 2

• Leader Charlie will propose block (k + 2) and the QC from round k + 1

• At this point, upon QC from round k + 1, validators can affirm that block (k) has been finalized

In summary, a block takes 2 rounds to be finalized. The first is a consensus on the transactions within the block. The second is a validation of the consensus. The graphic below depicts the flow:

3.2 Shared Mempool

As of this current stage, block propagation on Ethereum is still a significant bottleneck. When block leaders proposes blocks that are of big sizes, the propagation of these blocks to the validator network for consensus requires extremely high bandwidth from validator nodes, resulting in slower block propagation.

With MonadBFT, instead of propagating the entire block for consensus from the validator network, it propagates blocks using its hash. You might be wondering, if there is only a hash available, how will nodes know the details of the block which they are voting on for consensus? Let’s take a more detailed look.

User transactions that are submitted (but not yet executed) go to the RPC node. The pending transactions are then forwarded to validators’ local mempool. Individual validators might each have a certain set of transactions that are included in the block. In order for validators to know what is the exact block they are voting on, they need to know all transactions included in the block. This can be achieved through:

(a) Erasure-coding Transactions: Individual validators can share their respective pieces of transactions with each other

(b) Broadcast Tree: This is an efficient communication method for validators to share the various pieces of transactions

With the above 2 mechanisms, it becomes possible for validators participating in the consensus to reconstruct the entire block referred to by the hash given by block leader.

Let’s take a look at the potential improvement that can result from block propagation using hashes:

• Traditional Block Propagation: If a block has 10,000 transactions, with each transaction having a size of 500 bytes, the total block size will be 5MB. This size can be even bigger should the transactions be more complex, and thus having a bigger size

• Monad’s Block Propagation: Hashes are only 32 bytes in size. Instead of having to propagate all 5MB worth of data, straining the various stakeholders (validator notes, block leader, network), block propagation becomes orders of magnitude lighter and more efficient

P.S.: Erasure-coding has not been implemented yet as of this stage of development.

🍪’s thoughts: Despite all the benefits mentioned, particularly with regards to efficiency, it remains to be seen whether the architecture might result in possible attack vectors (perhaps through broadcast tree) or inaccuracies in consensus.

3.3 Deferred Execution

Before we begin looking into deferred execution, here are some definitions:

• Consensus: Nodes agree on official ordering of transactions

• Execution: Transaction executed and state is updated

• Gas Usage: Different types of transactions (differing levels of complexity) use different amounts of gas

• Gas Limit: Total amount of gas that can be consumed for each block

• Block Time: Will be set based on the gas limit

  • Time Budget: Gas limit allocation

Currently on Ethereum, execution has to be completed before consensus.

The gas limit on Ethereum has to account for:

• (1) Execution by block proposer

• (2) Execution by validator nodes

• (3) Consensus of validator nodes

As a result, the time budget for execution becomes extremely limited, given that there needs to be sufficient time for both executions and consensus. This puts a cap on the number of transactions that can be executed in one block, limiting the scalability of Ethereum when there is high network volume / large amount of complex transactions.

With Monad, execution takes place after consensus, as explained in the above section 3.1 MonadBFT. This means that during consensus, nodes will agree on the official ordering of transactions, but neither the leader nor validator nodes will be required to execute the transactions at this point. This also goes to say that when the leader proposes an ordering and validator nodes vote on the ordering, both stakeholders do not yet know the result of the transactions (whether they can be executed (e.g. sufficient gas) or will be reverted).

The key concept in such an architecture is: The true state is determined upon official ordering of transactions. Monad leverages on this, which is why in MonadBFT, nodes are able to come to consensus on ordering of transactions in round k, and concurrently execute transactions from round k - 1.

In this scenario, the entire gas limit of a block will be dedicated to execution, allowing Monad to increase the number of transactions that can be executed in each block, achieving its high throughput.

However, there is a potential issue associated with deferred execution.

As mentioned, execution is carried out after consensus. This results in a situation where nodes participating in consensus do not have an up-to-date view of the state (the nodes don’t know whether the transactions can actually be executed). In such a case, there is the possibility of certain users spamming the network, attempting to get their transactions to be included in consensus, causing other transactions to be pushed out. To have a better understanding, you can refer to the bakery analogy below:

3.4 Carriage Cost and Reserve Balance

To tackle the potential of spam and denial-of-service attacks, Monad has implemented carriage cost and reserve balance.

(a) Carriage Cost

For a transaction to be included into a mempool and subsequently included into a block for consensus, users will be charged a carriage cost (can be thought of as a deposit). This serves as a cost to deter users from spamming the network.

(b) Reserve Balance

Carriage costs are deducted from the reserve balance of each account. Upon successful execution of transactions, carriage costs will be returned to users (with a delay). It is targeted that the reserve balance will be ~200x that of the carriage cost. This is to allow honest users to submit multiple transactions concurrently / subsequently. This is necessary to maintain composability of transactions for DeFi applications, where transactions need to be executed one after another.

🍪’s thoughts: Just a random thought, but, what are the chances of carriage cost being outsourced. It becomes a sort of ‘service’ where instead of each account having a reserve balance, there is a smart contract that holds balance for all other accounts. Something of a similar mental model could be paymasters in ERC-4337. The main idea here is to maintain capital efficiency by not requiring users to have idle assets sitting in the reserve balance.

4. Monad’s Execution

One of the key architectural difference that allows for Monad to achieve high performance is its parallel execution. In this section, we will take a brief look at the mechanism and necessary component to achieve this: MonadDb.

4.1 Parallel Execution

With parallel execution, multiple cores and threads are utilized to execute transactions in parallel, while still committing the results in the original order. This means that the end result obtained from parallel execution (e.g. account balances) will be the same as the sequential execution.

An analogy we can think of would be the drive-through to Shake Shack

• Serial Execution: There’s only 1 lane available for drive-through. Drivers 2 and 3 will have to wait for driver 1 to finish ordering and collect his order before they are able to start their order.

• Parallel Execution: With parallel execution, there are now more than 1 lane available in the drive-through. All 3 drivers can order concurrently, and will still be able to get their respective order. This is the exact same outcome as serial execution, except that the speed at which customers receive their burgers will be increased.

Specifically in the context of Monad, optimistic execution is utilized. This means that the network can start executing transactions before earlier transactions in the block have completed. Results from optimistic execution will be akin to that of serial execution of transactions.

Nonetheless, it should be noted that with optimistic execution, there might sometimes be incorrect execution. This is especially the case when the transactions executed in parallel include the same accounts. This graphic below depicts how an incorrect execution might happen.

Routing back to the Shake Shack drive-through analogy above, imagine if all 3 cars that were waiting in line originally wanted a cheeseburger. However, there is only 1 cheeseburger left. The following graphic depicts what would have happened if serial execution was utilized.

Essentially, cars 2 and 3 won’t be able to make an order for cheeseburgers as the system has already been updated after car 1 makes and receive their order. Should it have been a parallel execution, with all 3 cars ordering concurrently, the system will register all orders. However, due to the lack of cheeseburgers, the 2 other customers that didn’t manage to receive their order will have to re-order.

Thus, it is important for Monad to be able to capture such instances of incorrect execution and re-execute it with correct data. This is done by checking for the condition shown in the graphic below:

4.2 MonadDb

One critical architecture that allows for optimistic execution to take place is the MonadDb, which is Monad’s custom database for storing blockchain state.

Particularly, optimistic execution is made possible with asynchronous I/O, a form of input / output processing to allow for concurrent execution while communication is in progress. MonadDb fully utilizes the latest kernel support to achieve asynchronous I/O.

Assuming there are 2 transactions, A and B:

• Execution of transaction A begins when the input is entered

• Execution of transaction B can begin even without output from A

  • This is feasible due to asynchronous I/O

5. Monad’s Benefits

5.1 Performance

The table below compares the TPS, block time and block finality between Ethereum and Monad. As shown, Monad features a much higher TPS, alongside with 1 second block time and finality.

With these metrics, Monad tackles the scalability issues that have been plaguing Ethereum. This allows more users to be accommodated on the Monad network, and maintains low fees as far as plausible for users.

5.2 Portability

Monad features high portability due to the following architecture:

• Full EVM Bytecode Compatibility

• Full Ethereum RPC Compatibility

With bytecode-equivalent to Ethereum (all Ethereum opcodes is supported), applications built on Ethereum can be ported to Monad without requiring any code changes. Developers will be able to port their existing work, develop with ease given the familiarity and users will be able to access their desired applications (presuming that the protocol ports over). In addition, infrastructure e.g. MetaMask, Etherscan and others can be used seamlessly on Monad.

6. Conclusion

Monad represents a significant leap forward in blockchain technology. The combination of high performance and EVM compatibility opens doors for developers and users alike, ensuring a seamless experience. With parallel execution, the potential of blockchain scalability paints an exciting landscape of protocols that can be built.

With that being said, there are still aspects that will likely undergo more iterations to become even more efficient. One example would be the carriage cost and reserve balance, where it takes time to study transaction data before being able to analyze what might be a suitable amount to charge for carriage cost, and how much the reserve balance should contain to sufficiently counter against denial of service attacks.

If you would like to see more of such works, do follow me on Twitter @jinglingcookies and join my Telegram group here where I share my daily reads. For more quality research, I recommend my good friends over at Four Pillars who share research reports in various verticals: Modularity, L1s, Games and more!

Annex

Additional Resources

Website.

Twitter.

Documentation.

To understand about how the transaction life cycle works, @analyticalali on Twitter has provided this insightful flowchart.

Hardware Requirements

Hardware requirements expected to run a Monad full node (as of October 2023)

• CPU: 16 core CPU

• Memory: 32 GB RAM

• Storage: 2 TB NVMe SSD

• Bandwidth: 100 Mb/s

In this article, I highlight the key points brought up by Nick, and give my thoughts on it, while extrapolating some points to identify potential innovations.

Next-gen L1 is bullshit

Nick believes that social innovations are more critical. In Nick’s point of view, in order for L1 to achieve new social innovations, there needs to be a radical approach to on-chain governance / a sovereign chain approach where there is not just a single chain to settle on, but instead there will be multiple app-chains for settlement, all while being interconnected.

🍪’s thoughts: I’ve been thinking about this concept of ‘Governance-as-a-Service’ (disclaimer: It’s a very very bare-bones idea at this stage). The idea originated from a couple considerations:

• There are many stakeholders participating in governance (protocol founders, protocol operators and users), and these stakeholders all have very diverse perceptions of what they think might benefit the protocol / themselves

• When we look across the broader landscape, the interconnectedness of existing protocols is apparent: LST CDP, lending markets, yield farms and many more

Judging from the above 2 points, I believe there is a need to have a common platform of sorts with universal governing metrics. This allows for stakeholders to better understand how their choice affects the outcome and also to pre-empt how passing of proposals for certain protocols could affect other partner protocols.

With a common framework put in place, it could plausibly allow for tracking of protocol data based on proposal history. For example, how did volume of a protocol change following a certain proposal being passed. More metrics can be tracked, including that of users etc. Eventually, with more and more information being collated into a database, it could be used for backtesting. In the future, new protocols can refer to such back-tested results to understand what proposals to push forth and possibly use available data to create a simulation framework.

Nonetheless, I believe the starting point will have to be an incentive program of sorts, that can resolve the cold-start problem of participation. Thereafter, it becomes a fine-tuning game of slowly removing the incentives to maintain a market equilibrium.

Solana

Nick brought up the example of Solana where the narrative was clear: (a) cheaper (b) faster. It’s intuitive and makes sense to people but over the long term it is not something that matters.

🍪’s thoughts: Nick didn’t delve deeper into why it does not matter over the long term, but I would assume its because Solana is a base layer that people do not visibly and tangibly interact with, which I agree with. Nonetheless, I would say that the base layer confers advantages that will be presented in the application layer, which is directly interacting with users. One example would be DePIN, the reason why it is able to perform better on chains like Solana is due to the exact nature of it: Fast. So would it actually matter in the long term? Perhaps perhaps.

Cosmos

Nick then brings up the example of Cosmos, which as of this point does not seem to have a clear narrative as it is not relatable to anything existing. And by Cosmos, he refers to the concept of sovereign chains.

The stronger the narrative, the further it is from the truth

The truth is nuanced and most people do not appreciate nuance. To have a narrative indicates that a lot of people believe in something, which indicates a lack of nuance and statement of something far from the truth.

🍪’s thoughts: Are narratives in some sense, necessary before people are able to identify nuances?

Does the best product always win?

Santiago brought up the the point that sometimes the best product does not win. For example, Osmosis has folks like Zaki steering the ship, building out products that are very interesting with nuanced takes on existing landscapes. However, there is no BD and marketing team to attract market attraction and thus, adoption for the products.

When asked how the above phenomenon plays into 1confirmation’s investment thesis, Nick mentioned that he is focused on authenticity, which will win over time, and that aspects such as BD and marketing will not matter that much in the long term, but perhaps in the short term products with good BD might lead the crowd. In terms of authenticity, Nick briefly mentioned that it refers to products that are innovative from the social perspective and effectively pushing the space forward.

🍪’s thoughts: In the early phases of a new technology, it is typically highly nuanced and not intuitive for the market and users. My belief is that there needs to be combination of both good UI/UX and BD to attract the initial wave of users. Perhaps in the long term, indeed, the stickiness and usefulness of an actually beneficial product / technology will fade the need for excessive BD / marketing, but that doesn’t seem to be the case for early stages.

This is also one of the reasons why I have been keeping my eyes on to see whether there’s any automation tool for UI/UX, not just to design, but also to evaluate the response received from users for the various designs.

Prediction markets: The next to capture mainstream attention

Jason asks Nick what he thinks about prediction markets being the context of disillusioned public trust in institutions, where truth for society used to come from governance and institutions, but in recent times it has become difficult to find this truth for society. And following this train of thoughts, a global super liquid prediction market at scale could be the best way to reveal true information.

Nick agrees with this take and highlighted that markets are fundamentally a better source of truth compared to media and narratives. This is because prediction markets are not solely about narratives, the participants are people with skin in the game speculating on outcomes, which can bring truth to the society.

🍪’s thoughts: But in this case what are the chances for groupthink / peer pressure? People might sub-consciously make a choice based on what they are seeing / what majority of the crowd is choosing.

A very interesting point brought up by Nick was the potential for prediction markets as a business model for creators. This idea stems from the mention by Polymarket’s founder, where he stated his thesis that NFTs succeeded because of its brilliant business model for creators. The same could be said for prediction markets, where every influencer creates their own pool and generate revenue by collecting fees.

Thesis for DAOs

The question to be pondered upon by the market is ‘Can we get products beyond the primary aspect bring speculation and reliance on investment capital’. Nick’s bet for DAOs is for it to develop in human organization to the extent where it allows people from different regions of the world to contribute resources to the same / various organizations. Nick also highlighted that he has yet to see products that make it easy for people to participate in DAOs.

Thesis for NFTs

There were several points made by Nick with regards to the NFT vertical

1. NFTs in 5 years have the potential to be a bigger market than crypto

• NFTs as an investment category is going to keep growing

• More people care about culture than purely finance

• NFTs: Intersection of money and culture

🍪’s thoughts: It’s quite a curious case as to how these investment opportunities could potentially present themselves. As of this point, I would think that projects exploring with ERC-6551 might be interesting to look at, as they are working with nascent design boundaries and might be able to introduce new design forms.

In addition, defi has always been touted to decentralize finance and grant financial access to everybody. The NFT scene is in some sense reminiscent of this, with the traditional art scene being highly gated.

2. NFT valuation framework

A point was mentioned regarding how both crypto and NFTs were valued based on belief, given that there is no cash flow available for valuing them in the traditional manner. Nick mentioned that the approach taken in this case is relative valuation, e.g. Bitcoin to Gold, CryptoPunk to Dogecoin etc.

3. The idolism play

Nick quoted ‘Desire is not based on ourselves, but based on others’. This is apparent with NFTs, when a particular NFT collection is minted by a famous individual, or perhaps even a prominent figure posting a meme of the NFT collection, it could result in significant increase in user demand for that particular collection.

🍪’s thoughts: Very similar to how existing fan behaviour is. For example, fans tend to go to cafes that are visited by idols. Similar concept can be achieved with NFTs.

4. NFT fractionalization

This results in transfer of ownership from strong hands to weak hands. Theoretically it is sound and promotes inclusivity, but time will be required to achieve the right balance.

5. Future of OpenSea… token?

Santiago asked about the future of OpenSea amidst diminishing marketshare due to strong competitors like Blur. Given that crypto marketplaces with tokens tend to be able to align users and investors better, will it make sense for OpenSea to eventually have a token?

Nick finds that OpenSea is the best product to bring new people into crypto. He acknowledges that there are indeed crypto native products that are more appealing to traders due to token incentives. However, he feels that as retail users come on, OpenSea is well positioned to capture these users, as the other platforms are not geared towards mainstream users, in terms of how they work and their interface.

Nonetheless, Nick finds that for marketplaces, giving users the ownership is important and would love to see OpenSea have a token in the future.

🍪’s thoughts: The dominance of OpenSea might have something to do with market cycles as well:

(a) OpenSea’s market share rises very significantly, assuming to 70%

(b) Competitors enter, leading to OpenSea’s market share dropping to 45%. OpenSea still maintains its market leader position despite reducing its market share

(c) New users enter the space and gravitate towards the market leader, in this case, still OpenSea. This increases OpenSea’s market share once again

This could be a loop, and as long as OpenSea maintains the position of a market leader, the market cycle and entrance of new users will help to keep their market share within an equilibrium range. Can be thought of as first mover advantage

Thesis for RWAs

Nick indicated that he doesn’t fancy RWA as much and the main reason it won’t work will be because of user demand. Crypto natives demand innovation, but bringing real estate on-chain is not exactly innovation. In addition, more often than not, RWAs require trust to a certain extent and a third party to be involved e.g. underwriter to underwrite borrowers / lenders.

However, Nick acknowledged that RWAs will eventually work when everybody comes on-chain and seeks portfolio diversification. This is when people will start to diversify into asset classes such as real estate.

🍪’s thoughts: By nature of the North Star of having more people exposed to cryptocurrencies, it does make sense that people will want more diversification into safer assets.

The potential for innovation here might be asset management dapps that maintain the composability of the portfolio assets. As of this point, most defi activities do not require KYC, whereas the contrary can be said for users who wish to participate in RWA. Hence, there needs to be infrastructure that allows users to pivot from one asset type to another seamlessly, and at a low cost. Or for example, being able to use assets within RWA protocols in defi protocols, and because of the KYC component, potentially receive better terms, e.g. lower collateralization ratio for lending markets.

But the above mentioned composability feature might come further down the road. The infrastructure layer might mature to allow for easy access to both defi assets and RWA through a single platform. There could also be, as mentioned above, asset management dapps that have ‘default portfolios’ that can be invested by users, e.g. for users with a higher risk appetite they can opt for one that has 80% defi assets + 20% RWA, for users with a lower risk appetite they might opt for something with a higher percentage of RWA.

Nick mentioned that he would prioritize music NFTs over RWA in terms of potential. And the justification for this is the difficulty in getting people to understand RWA since it is not physical.

🍪’s thoughts: Indeed it might not be physical. However, with the current efforts being pushed in the RWA vertical, including T-bills, there might be a possibility that the onboarding of users to access RWA is highly probably within a shorter timeframe as they are able to draw parallels with existing activities in their life. In addition, with protocols such as MakerDAO including RWA into their product offering, crypto natives will also be seamlessly introduced to such ‘new’ asset classes which they have previously not engaged so much in. Eventually, with both the web2 users and crypto natives adopting RWA, Lindy effect can be established over time, easing the entrance of big institutions.

Nick mentions that the Wall Street crypto narrative is likely something along the lines of ‘It’s interesting and experimental, but there is nothing real going on’.

🍪’s thoughts: This is where RWA might help right? When Wall Streets analysts are given something that they already know how to calculate, such as MakerDAO’s treasury which contains quite a significant amount of RWA, and with the onset of more RWAfi, it could actually help with TradFi adoption.

UX may not be the answer to onboarding more users

Despite acknowledging that smart contract wallets is going to help with onboarding, Nick’s thesis with regards to user onboarding is compelling new user behaviour. This could come in the form of NFTs, DAOs, both of which gives true ownership to users.

Thesis for stablecoins

There is a clear PMF for stablecoins as a trading vehicle, this is the main use case currently i.e. usage in defi protocols. However, we haven’t seen the prevalence of stablecoins being used as a medium of exchange. Case in point, NFTs can be considered e-commerce in some sense, yet they are mostly transacted in $ETH and $SOL.

The main reason that stablecoins have yet to take off as a medium of exchange could be because of the lack of developer tooling. The focus has been on stablecoins issuance, not so much on creating a good developer experience. One of 1confirmation’s portfolio companies, Bridge.xyz, has APIs for FinTech companies that want to utilize stablecoins for their backend. Another use case could be for DAOs that wish to pay taxes, but do not wish to manually carry out the process of having to interact with fiat or the banking system. Bridge.xyz can facilitate this process, converting the DAO’s stablecoins to USD and paying for taxes through a FinTech company that has integrated their APIs.

Guests: Alex Gluchowski, Anthony Rose

Co-hosts: Sam Martin, Dan Smith

Matter Labs: Introducing ZK Stack

Introduction of ZK Stack

Matter Labs, the team behind zkSync Era, has published the ZK Stack, a more interoperable and modular solution for building L2s and L3s based on Ethereum.

Vision: Achieve hyper scaling with chains built using ZK Stack, that can be part of a big interconnected ecosystem with (a) shared liquidity (b) seamless interoperability (c) fully trustless (d) minimal cost

ZK Stack centers around Hyperchains, which are rollups with broad design space:

• Validium: Uses centralized DA provider, giving it a different set of security guarantees

• Pure ZK-rollup: Inherits Ethereum’s security

• Many more types by experimenting with the design parameters

Hyperchains can be:

• L2s: Settle down to Ethereum or;

• L3s: Settling down to L2s

Hyperchains come with out-of-the-box interoperability solution (native communication between Hyperchains): Hyperbridges. Essentially, Hyperchains have the same prover (through shared prover tech) allows seamless and trustless bridging between different Hyperchains.

ZK Credo

Has been used internally by the Matter Labs team. It is now shared to the community for discussion and formalization of the North Star, the framework for ZK powered networks.

One of the core fundamental properties of ZK Credo is the ‘right to exit’. Hyperchains can have the control over whether they wish to share their resources with others, or be siloed.

What is ZK Stack?

Open-sourcing of the codebase that has been developed for zkSync Era, and consist of the key components which includes:

• Sequencer

• Circuits

• Prover

• System contracts

• Bridging interfaces

• Compiler

• SDKs

The above mentioned are essentially the core components for deployment of a Hyperchain that is very similar to zkSync Era. Over time, these components can become more flexible and designed in different ways to support more use cases, while reamining configurable and composable.

Why ZK Stack?

Problem with existing stacks used to build rollups is the use of older technologies. This makes it very difficult for transition to newer technologies in the future. The transition is possible, but there will be a limitation to the leverage of ZK. This is because certain design decisions have to be taken from the start, if these are not included from the start, it will be really hard to change.

Analogy: This is evident with technological shifts in the past. Going from cars to airplanes, it is not possible with just an engine replacement. You need to change the entire infrastructure.

When applications build off a certain set of standards, and the ecosystem forms around these standards, it is difficult to change in the future. An example is Ethereum, EIP-4844 is required because of how difficult it is to change Ethereum at the core protocol layer. There were attempts to build EIP-4844 (the concept) in a manner that will natively support account abstraction, but this would have broken the conventions that applications were built on, removing backwards compatibility.

Extension of chain is possible. For example, building an EVM compatible design, but later adding on other languages. This does not affect anything that was deployed previously and is thus unproblematic. However, changing the fundamentals is difficult and there are certain key components such as call data and data availability that can’t really be changed after deployment.

Architectures Available with ZK Stack

ZK Stack: Modular framework which allows customization of different aspects of the chain. It is possible to start with all the defaults, which is just copying the configuration of zkSync Era. However, there are multiple configurable components.

1. Sequencer

   There is the choice of opting into a centralized sequencer, which is easier to maintain initially. It is possible to decentralize the sequencer through a consensus mechanism in L2, which requires validators and token staking. All of these parameters (consensus algorithm, choice of token used for staking etc.) are customizable.

2. Data Availability (DA)

   ZK-rollup is an architecture in which DA is published through the Ethereum network, that means relying on Ethereum L1 as the DA layer. This gives the rollup 100% of Ethereum’s security as they rely on the entire network and not individual validators. As a result, the validators do not have the power to withhold data from the rollup. This is the most secure and centralized option.

   However, there is a tradeoff for this. All rollups on Ethereum, optimistic and ZK alike, share the same data bandwidth (same limited blockspace) to be utilized for data. This bandwidth is currently limited, but will be extended after proto-danksharding and eventually danksharding, which will potentially accommodate 1000s of txns per second across all rollups.

   Once rollups gain traction and user volume increases significantly, DA will become a bottleneck, increasing the cost. Before Ethereum reaches full sharding on DA, rollups have to consider alternative DA solutions, which includes:

   (a) Validium

   One / multiple parties hold the DA for a given rollup. State transitions are secured by Ethereum but DA is managed by these other parties. These parties abide by rules enforced by Ethereum, and thus the order of txns will still be preserved. They offer out-of-the-box privacy as they have the power to not disclose certain txns. However, this comes at the expense of decentralization as DA is controlled by the parties.

   (b) zkPorter

   Also a Validium, but the DA is secured by the users who stake their tokens. Risks of zkPorter is thus lower than a pure Validium.

   Rollups and zkPorters can seamlessly interact with each other synchronously within a single txn. zkPorter users will be able to interact with the dApps built on other rollups.

In the future there can be more configurations, such as for the prover etc. At this state, configurable sequencer and DA will be the most interesting as its where users will be able to customize the stack the deepest.

It is also possible to put restrictions on the stack. Such as having a chain host only one single application, to prevent cluttering of sequencer space. In addition, privacy is also customizable.

Characteristics of Hyperchains

1. Composability

   Even with all of these customizations available, the Hyperchains still remain plugged within the ecosystem where liquidity is shared.

2. Full Sovereignty

   All Hyperchains have full sovereignty, they do not depend on each other or zkSync Era, they are only dependent on Etheruem.

3. Low Latency

   Txns can be made between any Hyperchains in the network, regardless of which layer of the stack they are. The team is working on building the tree of recursive proofs, which will prove the blocks in parallel (regardless of the block size), reducing the latency significantly.

   Analogy: Email. Users don’t have to worry about the email hosting infrastructure when they send an email.

ZK Stack’s Account Abstraction (AA)

Design of AA in zkSync Era is reliant on the fact that calldata comes for free. The system can include any number of inputs (a lot of parameters), which do not have to tap into Etheruem’s DA layer (expensive). The inputs only have to be computed which is cheap due to efficient ZK proofs and GPU provers.

It becomes possible to have inputs such as biometric data from mobile, and the system can take a lot of parameters and invariants for the txn. There is a higher level of security for the users as the parameters can be customized to indicate the users’ needs. For example: In this txn I only authorize for spending of a particular token up to a certain limit. This will still be as cheap as a single txn on Ethereum.

🍪’s thoughts: The UI of such parameters customization remains to be seen. We have to bear in mind that the UI has to be sufficiently friendly for users to benefit from it. Otherwise, more often than not, users will choose to go for the default choices.

Matter Labs team has designed the AA in a way where developers will have freedom to customize their payment interface so that it makes sense for them at scale.

Co-host, Sam Martin, makes an analogy to Chase mobile banking account which has checking account, savings account and brokerage account. User might choose to have their funds to remain within zkSync Era, which has strong security guarantees, and this would be similar to the savings account. When the user wishes to use a dApp like Uniswap, they will swap to an exterior account that has a certain sum stored within it. The AA comes into play by allowing the users to easily interchange between different accounts on the various Hyperchains with different security assumptions.

Based on the previous analogy, this is how we can view it:

• Rollup Account = Savings Account

  Rollup account gives users the ability to maintain control of all their assets from L1. This has the highest security. This account would in some sense, be more difficult to maintain. This is where most funds should be maintained.

• Porter Account = Checking Account

  Carry out txns, interact with the game etc.

  This account does not have full security in the same way due to the different approach taken towards DA. The benefit here would be cheaper txn fees.

The use of accounts is likely up to individual risk tolerance.

It is possible for rollup account and porter account to be on the same Hyperchain. This means that on one single chain there is instant seamless synchronous connectivity between them.

Who Would Build a Hyperchain?

The building of a Hyperchain is warranted by the need to customize certain aspects of the chain: Application specific chains. In addition, having a single chain has higher capacity and higher throughput.

Enterprise chain, gaming chains, app-chains that do not wish to have decentralized sequencers given the higher latency, social network chains etc. For example, Reddit which has 500,000 daily active users. They will likely require multiple Hyperchains for the different categories. It might look something like Hyperchain for the Reddit category itself, and then L3s for sub-reddits.

🍪’s questions: It seems that building a Hyperchain has a lot of outsized benefits, including the customization ability and higher throughput, all while being plugged into the zkSync Era ecosystem where all Hyperchains are highly interoperable and dApps built are composable. In this case, what is deterring builders from developing their own Hyperchain? Could it be the expenses of building it or the overhead cost of maintaining a chain? The security levels remain the same given that both rollup accounts and Porter accounts can be created within any chain.

User Experience (UX) on Hyperchain

Scenario:

• Uniswap launches its own Hyperchain. It is completely separate with its own sequencer

• User has funds on zkSync Era and wish to interact with Uniswap

• The UX will be entirely same as if Uniswap was built on zkSync Era

• Once user authorizes the txn, txn will bridge from zkSync Era over a Hyperbridge to Uniswap chain

• Txn is executed on Uniswap chain and the results will be sent back to zkSync Era

All of the above will happen asynchronously but atomically. All txns that are scheduled cannot be stopped. There is no trust assumptions, and there is no additional capital requirements.

This is possible because all Hyperchains will have to use a single Hyperbridge on L1. Hyperchains are deployed on a smart contract (Hyperbridge) that will keep the states and balances for all chains, and offer an option for shared prover.

UX: Moving Assets to L1

Question: How can a txn be force included into the L1 should there be problems with zkSync Era? What are the security assumptions of the users?

Every Hyperchain will have its own set of tradeoffs. For example, if Validium decided to freeze the data, since centralized parties control the DA, there’s nothing that can be done by users. However, a user can request for an exit from the Hyperchain, and in the case that the request is not respected, the entire chain has to halt.

ZK-rollups have a mechanism called the priority queue. A user can always go onto the L1 to submit their txn: there is no need to generate any ZK proofs, it’s basically a self sequence (this however might become expensive based on activity on the L1, e.g. congestion). Users sequence their own txns and it is supposed to be included in the next block by the validators of zkSync Era. If the txn is not included, the protocol will halt and enter the priority mode where anyone can sequence txns: anyone that’s in the priority queue HAS to be processed. Priority queue will have a predefined sequence of txns, it will be easy for anyone to generate these blocks and produce the proofs.

The design of the priority queue is extended so that users can come together to submit a collective claim: starting sequencing txns together.

Scenario:

• A group of users are censored

• They get together (there is a leader that organizes this)

• Someone deploys another Hyperchain (new instance) that will not censor the users

• Many txns will be collected using the front-end of the other chain

• Leader collates the signatures and submits the batch to L1

• These users are moving from 1 Hyperchain to another through Hyperbriges

🍪’s questions:

• Genuinely curious, if we allow self sequencing without generating any ZK proofs, does the txn still inherit the characteristics of ZK?

• If the protocol is halted until the priority queue is empty, wouldn’t the liveness of the chain take a rather huge hit?

• Who is the leader to lead the collective claim, how do we know that this leader is trustworthy?

• It was mentioned that based on ZK Credo, if one user is censored, the rest of the users will have to all exit and deploy a new instance. This seems to be a too optimistic view on the demographics of users and their willingness to participate in this. Even though on the users’ end all they have to do is to sign a txn, the technical expertise of users to be able to know what is happening (deploying a Hyperchain) is also in question

• Sounds like quite a bit of fragmentation to me should there be manual interference required to create and participate in the new instance (new Hyperchain)

Decentralized Sequencer

zkSync Era’s design is such that the sequencer has to be decentralized, the team is close to having their decentralized sequencer be ready for public testnet. Important for chain liveness, which is required to achieve reliability metrics.

The decentralized sequencer is part of the ZK Stack. Builders using the ZK Stack can choose to opt into implementing this.

On top of this, there is a need to decentralize the prover. This is more challenging as a lot of work has to be orchestrated for merging. There is also a need for recursion of the work done in a timely manner. The core component to this is to build a prover that can run on the consumer hardware.

🍪’s thoughts:

• If this is the case, it seems like from the get go, builders using the ZK Stack won’t actually have a lot of optionality. This means that the first iteration of Hyperchains will be very similar to that of zkSync Era’s architecture and characteristics

• In addition, how backward compatible are these opt-in architecture customizations going to be? For example, once the decentralized sequencer is released, it is incorporated by the Hyperchain, but after a period of time the decentralized sequencer is upgraded (perhaps say a different kind of consensus algorithm), what kind of changes will it have on the Hyperchain?

• Will changing the consensus algorithm be akin to the ETH Merge, this is considering the point mentioned above that the entire zkSync Era ecosystem is interconnected

Potential Alpha: Should there be a zkSync token, it will be integral in decentralizing the prover and sequencer, and also securing the data of ZK Porter chains. This is because staking of token is currently the best mechanism to decentralize permissionlessly.

Modularization

Anthony mentioned that there were ideas of allowing the community to contribute modules to the ZK Stack, which might not be in the manner that Matter Labs had implemented things into zkSync Era, but provides flexibility for different use cases, expanding the space for innovation.

🍪’s thoughts: The community contributed modules sound like a marketplace. In Empire’s podcast on Uniswap v4, it was mentioned that in web2 companies tend to converge towards becoming a marketplace. Applying this concept, such community contributed modules could potentially become the ‘products’ to be bought and sold, creating a robust marketplace, with constant feedback loop from both the demand and supply side.

State of Proving Format

Hyperchains are built around the idea of a common standard: Achieved through hyperbridges.

Hyperbridge: Smart contract that serves as a shared bridge hat that Hyperchains can deploy on. There needs to be certain common circuits that they trust from each other that certain actions were performed correctly. It is a challenge to find the minimum set of circuits that are required to be common.

However, the necessity of this shared smart contract means that the hyperscalability can only be built out in one particular ecosystem. It is not possible to do hyperscalability across multiple ecosystems

• It is possible to trustlessly bridge between different rollups (optimistic and ZK), but this is not going to be seamless. Bridging from optimistic to ZK-rollups might have delays that goes up to days

• Bridging native assets between ZK-rollups will require payment to Ethereum. There will be no benefit of scaling

🍪’s thoughts:

• Alex’s (Co-founder and CEO of Matter Labs) point of view over here is that users and developers both have to choose the correct ecosystem to be in. I do understand why this might be the case because the whole concept of Hyperchains is to allow customizations of chains deployed, allowing the ecosystem to host all kinds of applications and use cases (as mentioned earlier on, DEXs, games, social media etc.). By theory, if the ecosystem is already able to accommodate all of these use cases, there is no need for other ecosystems

• However, does this mean that there is monopoly in some sense? And if this is the thesis, it sounds like investments into ZK-rollup ecosystems is a binary one, the ecosystem either takes off, or it flops

• In addition, Alex mentioned that developers building using a different stack from ZK Stack will not be able to achieve migration into the Hyperchain ecosystem, and will instead have to build from scratch. But why is this the case?

• In the current landscape, there are quite a handful of teams working on products such as compilers to be able to deploy EVM projects into zkEVMs (albeit it might not be entirely seamless and there will need to be some manual changes). There are also teams working on zkEVMs that are EVM compliant / equivalent from the get-go, so why is it that the outcome is so binary in the sense that the choice of an ecosystem is a definite and irreversible one?

• Should this actually be the case, it seems like there will be a high level of fragmentation and developers might be faced with tougher choices to build (which are not related to the technical aspects)

Proof Systems | Innovation vs Standardization

There is tension between reaching standardization and the speed of innovation.

When innovation is moving at such a fast pace, there is a lot more improvements and optimizations that could come to the design and implementation of proof systems.

ZK Stack vs Other Stacks

Key differentiator: How the bridge works.

Bridges determine the properties of the ecosystem

• Trusted Bridges

  These are no different from standard multi-sigs as trust assumptions have to be introduced. It is not possible to continuously bridge amongst multiple chains as there will be accumulation of trust assumptions. This is not scalable and not trustless

• Hyperbridges

  Derived from the internet idea of ‘hyperlinks’, which are able to take users from any page on the page to any other page in exactly one click with 0 trust assumptions. This is seamless, cheap and trustless

  The reliance here is on Mathematics, Cryptography and Ethereum

ZK Stack Partners

Likely to be highly institutional

Choice of DA Layers

Hyperchains are able to use alternative DA layers without losing interoperability benefits. It’s just that the security level will differ.

Make it easier to read L1 from L2, L2 from L1, or L2 from another L2

• Necessary to implement asset / keystore separation architecture

• Can be used to optimize reliable cross-L2 calls

Goal

When L2s become more mainstream → Users will have assets across multiple L2s and L1s

When smart contract wallets become mainstream → Keys needed to access some account are going to change over time (old keys will no longer be valid)

Once both of the above occurs → User needs to find a way to change the keys that can access many accounts which live in many different places → Without making extremely high no. of txns

• This is essentially saying that they are allowing the users to access the different smart contract wallets (accounts) they have on the different networks with specific keys. And there is a need to implement an architecture to achieve this without creating a complex UX

Need a way to handle counterfactual addresses which are:

• Addresses that have not yet been ‘registered’ in any way on-chain → But need to receive and securely hold funds

• Necessary for all: When using Ethereum for the first time → A user generates an ETH address that someone uses to transfer assets to → This address is not registered on-chain yet

• Registered on-chain: Require paying of txn fees → Which requires the wallet to already hold onto some ETH

  • We can think of this as a sort of ‘kick-start’ mechanism → Where the address will be registered once they have started making txns → Active wallet instead of passive wallet (purely receiving, not making txns and paying gas fees)

• All EOAs start off as counterfactual addresses

Possible for smart contract wallets to be counterfactual addresses

• CREATE2: Allows ETH address to only be filled by a smart contract that has code matching a particular hash

Challenges of Smart Contract Wallets

Possibility of access keys changing

Smart contract wallets have an address (unique identifier for the wallet) → Generated based on initcode → Only contain initial verification key (password for wallet)

Current verification key (might be different from the initial verification key) → Stored inside wallet’s storage

• This is not propagated to other L2s

User might have multiple addresses on different L2s → Should there be counterfactual addresses that are not known yet by the L2s (since they are not registered) → Changing the access keys becomes a challenge

Solution: Asset / Keystore Separation Architecture

2 main components:

1. Keystore Contract

   Can be on a L1 / L2

   Stores verification key for all wallets owned by user

   Stores rules for changing key

2. Wallet Contract

   Exist on both L1 and L2

   Communicate with each other across different systems to retrieve verification key stored in keystore contract

Summary: User has a main contract (keystore contract) that holds all the keys and rules, and separate contracts (wallet contracts) on different systems that talk to each other to get the correct key from the main contract

Implementing Asset / Keystore Separation Architecture

1. Light version: Check only to update keys

   Each wallet stores the verification key locally

   Each wallet contains a function that can be called to check a cross-chain proof of the keystore’s current state → Update its locally stored verification key to match

   When a wallet is used for the first time on a specific L2: Necessary to call the function to get current verification key from keystore

   Upside:

   (a) Minimizes use of cross-chain proofs (expensive)

   (b) Since all funds can only be spent with current keys → Wallet security is maintained

2. Heavy version: Check for every txn

   Cross-chain proof showing key currently in keystore is necessary for every txn

   Upside:

   (a) Less systemic complexity

   (b) Keystore updating is cheap

   Downside:

   (a) Expensive per txn

   (b) Not easily compatible with ERC-4337 → Does not currently support cross-contract reading of mutable objects during validation

Summary:

• Light version checks for key updates periodically, reducing the reliance on cross-chain proofs but incurring higher gas costs for key changes

• Heavy version checks the keystore for every transaction, which is cheaper for keystore updates but requires more engineering effort to optimize cross-chain proof costs and may face compatibility challenges with certain standards

What Does Cross-chain Proof Look Like?

Scenario: Keystore is on Linea, wallet is on Kakarot

• Full proof of the keys to the wallet consists of

  • Proof proving current Linea state root → Given the current Ethereum state root that Kakarot knows

  • Proof proving the current keys in the keystore → Given current Linea state root

• 2 challenges for implementation

  • What kind of proofs to use

  • How does the L2 learn the recent L1 (Ethereum) state root + How does the L1 learn the L2 state root → What is the delay for this

Potential Proof Schemes

1. Merkle proofs

2. General-purpose zk-SNARKs

3. Special-purpose proofs (e.g. with KZG)

4. Verkle proofs (between KZG and zk-SNARKs for infrastructure workload and cost)

5. No proofs and rely on direct state reading

Aggregation <> Cross-chain Proofs

Aggregation: Aggregate all proofs supplied by users within each block into a big meta-proof that combines all of them

Possible for SNARKs and KZG

Not possible for Merkle branches (can be combined but the cost is not worth)

Aggregation is only worth it when the scheme has a substantial number of users → Realistically it’s okay for v1 to leave aggregation out

Direct State Reading

• Only for L2 reading L1

• Modify L2s → Let them make static calls to contracts on L1 directly

• Can be done with an opcode or precompile → Allows calls into L1 → Provide destination address, gas, and calldata → Return output

  • This essentially allows the L2 to understand what the L1 state is by specifying the information that they require

• Static calls → Cannot change any L1 state

• If keystore is on L1 + L2s integrate L1 static-call functionality → No proofs are required at all

• If L2s don’t integrate L1 static-calls → If keystore is on L2 (which it may eventually have to be) → Once L1 gets too expensive for users to use → Proofs will be required

How Does L2 Learn the Recent Ethereum State Root?

• All L2s have some functionality to access the recent L1 state

• This functionality is needed to process messages coming in from L1 to L2 (most notably deposits)

• If an L2 has a deposit feature → Use that L2 as-is to move L1 state roots into a contact on L2

  • Have a contract on L1 call the BLOCKHASH opcode → Pass it to L2 as deposit message

• Full block header can be received + state root extracted on the L2 side

• It is however, better to have every L2 have an explicit way to access either the full recent L1 state / L1 state roots directly

Methods for L2s to Read L1s

Main challenge with optimizing how L2s receive recent L1 state roots → Simultaneously achieving safety and low latency

• L2s implement ‘direct reading of L1’ functionality in a lazy way → Only reading finalized L1 state roots → Delay will normally be 15 mins

  • In extreme case of inactivity leaks → Delay can be several weeks

• L2s can be designed to read much more recent L1 state roots

  • But if L1 reverts (which can happen during inactivity leaks) → Even with single slot finality → L2 need to be able to revert as well → Technically challenging from a software engineering perspective

  • Optimism has this capability

• Use deposit bridge to bring L1 state roots into L2

  • Simple economic viability might require a long time between deposit updates

• Oracles are not acceptable

  • Wallet key management: Very security-critical low-level functionality

  • Should depend on at most a few pieces of very simple, cryptographically trustless low-level infrastructure

Methods for L1s to Read L2s

• Optimistic rollups: State roots take 1 week to reach L1

  • Because of fraud proof delay

  • On zk-rollups: Takes a few hours → Still slow due to proving times and economic limits

• Pre-confirmations from sequencers, attesters, etc.

  • Not an acceptable solution for L1 reading L2

  • Level of security of L2 → L1 communication must be absolute

  • Only state roots that L1 should trust → State roots that have been accepted as final by L2’s state-root-holding contract on L1

Duration for L1 <> L2 Communication

• Some of the methods mentioned above for trustless cross-chain operations are unacceptably slow for many DeFi use cases → These need faster bridges with more imperfect security models

• For the use case of updating wallet keys → Longer delays are more acceptable → It’s not the txns that are getting delayed by hours → It’s the key changes

  • Just have to keep the old keys around longer

• If user is changing keys because the keys are stolen → There is a significant period of vulnerability → Can be mitigated by having a freeze function

• Best latency-minimizing solution → For L2s to implement direct reading of L1 state roots in an optimal way → Each L2 block (or state root computation log) contains a pointer to the most recent L1 block → If L1 reverts → L2 revert

• Keystore contracts should be placed either on mainnet / on L2s that are zk-rollups and can quickly commit to L1

For chains that hold wallets with keystores that are rooted on Ethereum / L2: How much connection to Ethereum is needed?

• Answer: Not that much

• Not limited to rollup → Wallets can be held on L3 / validium too

• As long as keystores are either on L1 / zk-rollup

• Requirement: Chain needs to have direct access to Ethereum state roots + Technical and social commitment to be willing to reorg if Ethereum reorgs + hard fork if Ethereum hard forks

• Research problem: Identify to what extent it is possible for a chain to have this form of connection to multiple other chains

  • Node operators and community will have double the technical and political dependencies

  • Sounds similar to spillover effects from leveraging the same set of resources for multiple applications (similar to the concept of rehypothecation)

  • End of the day: Can use the technique to connect to a few other chains → But at increasing cost

Preserving Privacy

• If a keystore manages multiple wallets, we want to make sure that:

  • It is not publicly know that those wallets are all connected to each other

  • Social recovery guardians don’t learn what the other managed addresses are

• A few issues

  • Merkle proofs cannot be used → They do not preserve privacy

  • KZG / SNARKs: Proof needs to provide a blinded version of the verification key without revealing location of verification key

  • Aggregation: Aggregator should not learn the location in plaintext

    • It should receive blinded proofs

  • Light version cannot be used

    • It creates a privacy leak

    • If many wallets get updated at the same time due to an update procedure → Timing leaks the information that those wallets are likely related

    • Can’t really comprehend why this might be the case

  • SNARKs: Proofs are information-hiding by default

    • Aggregator produces recursive SNARK to prove SNARKs → Currently, this process is quite slow

  • Direct reading L1 from L2: Does not preserve privacy

Additional Resources

• The Three Transitions | Vitalik

• Holding assets across multiple chains | Safe

• The need for wide adoption of social recovery wallets

• zk-SNARKs

• Privacy applications of zk-SNARKs

• KZG commitments | Dankrad

• Verkle trees

For more information, here’s the Uniswap history link

Uniswap’s Iterations

v1: Anyone can be a liquidity provider (LP) and open any sort of liquidity pool for any token. LPs could provide full-range liquidity, which supports any price from 0 to infinity

• Problem: Most assets don’t trade at 0 and infinity simultaneously. Stablecoins for instance, usually trades between $0.99 and $1.01

v2: Optimized for LPs to be funds

v3: Introduced concentrated liquidity, which allows for LPs to customize the liquidity provided in a narrow range. This moves the entire reserve curve upwards, improving liquidity efficiency by having more liquidity for swaps within that range

• This provided a much better execution for traders

• Problem: LPs could hardly profit, as they experienced significant increase in impermanent loss (IL), more commonly known as loss versus rebalancing (LVR) these days. The increase in IL was largely due to MEV leakage from MEV bots and arbitrageurs that were carrying out CEX to DEX arbitrages and backrunning transactions. However, this arbitrage value was not returned to both swappers and LPs

v4: Aims to increase profitability for LPs by solving MEV leakage. In addition, it provides more customizability for creators of liquidity pools, allowing them to own the liquidity

Summary of Uniswap Iterations

v1 and v2: Provided x * y = k

v3: Added price granularity

v4: Added time and fee granularity

Current Uniswap LP Situation

The LPs that are profitable from providing liquidity on v3 are mostly professional capital allocators. This dynamics indicate the complexity of Uniswap and liquidity provision

Uniswap v4 Introduction

1. Hooks

   Allow owners to customize the liquidity pools they have created

   A key feature of it is MEV internalization:

   • Appchains, such as Osmosis, leverage appchain architecture to achieve state awareness. Being aware of the transaction order within a block allows appchains to calculate MEV opportunities and capture the value for themselves through arbitrage or backrunning. They can then decide whether to provide this protocol revenue back to Osmosis holders

   • With hooks, Uniswap can internalize MEV and allow for transaction ordering preference

   Shortcoming of hooks:

   • Hooks are SCs that are not built into the protocol layer, unlike that of Osmosis where the MEV preferences are baked into the chain. Uniswap sits above Ethereum and does not own the underlying blockspace. As a result, Uniswap can be ‘begin block’ aware, but not ‘end block’ aware. This means that it can timestamp the first transaction in the block, but is unable to know the last transaction of the block. Hence, the level of MEV value capture from ordering is limited as it does not know exactly the full contents of the block

2. Singleton

   Back in v3, every single liquidity pool that was created on Uniswap needed its own smart contract (SC). In v4, all liquidity pools will be housed in a single contract, known as the SIngleton, optimizing gas expenditure for users

   Multi-hop example:

   • A user wishes to swap from $ETH to $ARB

   • There is however, no $ETH/$ARB pool

   • Uniswap first finds the optimal route to go from $ETH to $USDC through a $ETH/$USDC pool

   • Afterwards, the $USDC is swapped into $ARB through a $USDC/$ARB pool

   • Since all of these pools are housed in 1 SC, gas cost is reduced drastically. Comparing that to v3, the hopping between different pools will require additional computation and gas

   Based on whitepaper, cost of creating a new liquidity pools on v4 can be reduced by 99%.

3. EIP-1153 | Transient Storage

   EIP-1153 is a proposed Ethereum Improvement Proposal that was supposed to be included in the Cancun upgrade. It is similar to flash memory for computers, allowing complex calculations to be performed in a transaction without needing to be saved to the state of Ethereum after the transactions are completed. This optimizes gas usage and reduces costs

v4 Use Cases

Open source innovation typically leads to the most capital efficient financial systems over time

1. Developer Tooling

   In some sense, v4 is putting the tools in the hands of developers, liquidity pool owners and LPs to leverage the best possible way to profit. However, one concern would be liquidity fragmentation. Given that only a few LPs are profitable, around 80% of Uniswap’s liquidity is made up by less than 10 LPs. This could result in bulk of the liquidity on Uniswap being in permissioned pools, which is unaccessible to users that have not undergone KYC

   Drawing context from web2, there is a tendency for everything to become either a platform or a marketplace. It seems that this trend is slowly maturing within the web3 space, where v4 is acting more like a platform, rather than a siloed protocol. This is because prior to v4, developers have to create a customized SC architecture to build their own DEX. However with v4, it is possible to have a plug and play hook contract

2. Use of Out-of-Range Liquidity

   Capital that lies out-of-range are idle and not being used. With hooks, this liquidity can be used in lending markets. By this theory, it might be possible for Uniswap to become a DeFi super-app, where it leverages out-of-range liquidity to create new financial primitives, with the process being simplified by v4. There is value in exploring this concept given the decent number of protocols being built on v3 currently: Panoptic, GammaSwap, Infinity Pools

   Prior to v4, utilization of out-of-range might look something like this:

   • Create LP NFT on Uniswap

   • Pass LP NFT to DeFi protocol

   • Deposit liquidity into DeFi protocol

   With v4, the above process can be simplified where liquidity can be directly deposited into the DeFi protocols building on Uniswap. The logical execution will then be handled by the hook that points to the SC

Risks of v4

With greater customization and flexibility, the question arises as to whether there is an increased surface area for potential of back-firing. For example, should the hook be faulty, does the consequences of it failing ripple to the broader ecosystem of liquidity pools built within Uniswap?

1. Rugging Risk

   This is not a confirmed risk, but this is what it might look like:

   A liquidity pool deployed can be built with a hook that points to a certain SC. Once the liquidity pool has acquired a certain level of liquidity, it will then amend the hook to point to another SC, which could for instance have a logic where the withdrawal fee is 100% of capital, preventing people from withdrawing

2. Lack of Expertise

   It seems that the architecture will require developers to write a lot of custom logic within the SC for the hook. This might be complex and not all teams will have the expertise to do this

   This however, opens up the potential for a new kind of service: Hook templates

Changes to LP Landscape

With the increased customizability and complexity of v4, Jason was concerned that the barrier would be too high to allow all users to provide liquidity. Santi mentioned that this is actually an existing left curve which is the belief that v2 was the best version with ease of liquidity provision

Nonetheless, given the significant gas optimization provided by v4, it becomes way cheaper to provide liquidity. This opens up the possibility for users to provide only a small sum of liquidity and benefit from low cost. At the end of the day, IL is an opportunity cost, and it is hard to conceptualize and track for most users

Cookies thoughts: Should this be the case, does it eventually spell demand for LP vaults (user deposits into vaults, which automates the liquidity provision for users and collects a fee in return for the service). Despite the fact that the returns might not be attractive given the level of IL, should there be sufficient demand for users to try out the vaults, or initial liquidity mining campaigns, the revenue that these protocols can make it rather sizeable, as they do not take on the IL, and can pass on the costs to users (since these are costs that would have been incurred either way should the user decide to become a LP themself). Examples that I can think of include Arrakis Finance, Gamma Strategies and Charm Finance

David thinks that hooks may eventually allow for passive concentrated liquidity pools. This democratizes market making and serves all users, spanning from professional market makers, institutions etc.

Understanding Uniswap Invariant

Uniswap’s AMM is based on the constant product formula: x * y = k. The invariant (slope of the curve), x * y, looks like a logarithmic curve, and ranges are created on this curve for concentrated liquidity provision. This was highly innovative as it allowed for trading of tail end assets

Curve created a stableswap invariant. This slope is much flatter because stablecoins have extremely low volatility and do not fluctuate in prices significantly

v4 adds a a new layer of flexibility, where the slope can be changed + curve can be shifted. The whitepaper indicated that v4 will allow for multiple invariants. Instead of creating a hook that builds a new AMM, one can specify for the hook to build a liquidity pool that is able to mimic other functionalities based on market changes. This opens up the opportunity for passive retail users to provide liquidity, where the pool moves the liquidity based on asset price movement.

Cookies thoughts: What does the value accrual and cost structure look like for this? Who, Uniswap or the protocol built on it, gets access to the fees paid by users?

Curve vs Uniswap v4

Ren highlighted that it’s likely Curve will still have a significant role to play in the DeFi landscape given its robust ecosystem with veCRV, Convex, the recently launched crvUSD and LLAMMA (borrowing and lending protocol for crvUSD). In addition, Curve has also been undergoing updates, example of which is the launching of v2 pools to significantly reducing the gas fee needed to rebalance pools

• crvUSD: Has been performing relatively well with ~20 - 25 million crvUSD minted

• LLAMMA: Innovative soft liquidation model

With this being said, Uniswap has also started boosting their gas efficient methods, especially through Singleton contracts, which can theoretically reduce pool deployment cost by 99% and allow for cheaper multi-hop transactions. Curve may still be able to complete, however, the investment thesis revolving Curve’s v2 pools, its stablecoin crvUSD and LLAMMA might not be as strong. Nonetheless, it is likely that Curve will remain the de-facto home for stableswaps

David, on the other hand, is a firmer believer of Curve’s ability to retain its market share. This belief primarily stems from the fact that a lot of DeFi protocols are dependent on Curve through two aspects: (1) protocols hold $CRV (2) protocols rely on Curve’s liquidity. Hence, David believes that unless Uniswap starts offering a liquidity mining program and cater to individual protocols, Curve will still retain its use cases and service the existing protocols

Uniswap + Appchain Thesis

David highlighted that Uniswap started with consumer facing applications but is moving more towards the protocol layer (with hooks customization etc.). This puts ahead the precedent that the next step for v5 might be to launch an appchain, given that they are already doing most things an appchain can possibly do, except for being fully state aware

Appchain thesis: When developers / community owns the entire stack (blockspace, middleware and consumer facing applications), there is the potential to monetize every layer of the stack. In addition, it is possible to build fully customized application and ultimately, have the application and chain be aware of each other

Right now, there is a lack of full customizability for Uniswap. For example, for Singleton contracts to achieve the most optimal gas routing and pool creation, there is a need for EIP-1153 (transient storage), which is potentially going into the Ethereum Cancun upgrade. However, it is difficult for Ethereum to prioritize this simply for Uniswap, as this will cause it to lost its credible neutrality

Should Uniswap adopt an appchain thesis, it is possible for them to prioritize the aspects they wish to build, allowing them to innovate at a faster rate, a function of full ownership

Ren, on the other hand, is of the view that v4 itself might be a signal that Uniswap is not heading for an appchain model. The driver for moving to an appchain model is to capture value, which typically comes from either MEV internalization or turning on the fee switch. However, v4 allows MEV internalization through hooks (to a certain extent, not forgetting that it is not end block aware), which already contributes to value capture. In addition, hooks allow potential value capture by LPs through withdrawal and swap fees, supporting the point that it does not have to pivot to an appchain model to achieve value return

Cookies thoughts: In this case, given the potential of Uniswap moving to an appchain model, we might see some activity migrate over to Cosmos, particularly the key protocols including Osmosis and Stride Zone.

Impact on Fee Switch

Context: This is the fee switch proposal that had been submitted previously

The fee switch discussion has become even harder as there is an additional layer of complexity. Previously, the stakeholders affected by this proposal were limited to that of LPs and $UNI holders. With hooks, protocols that are building on v4 will also be a stakeholder affected by the fee switch. In particular, it could switch the scene back to protocol owned liquidity (POL) instead of having to pay LPs.

Cookies thoughts: Olympus?

Digital Monopolies

David believes that over time, crypto will have digital monopolies. Such monopolies will be able to expand indefinitely, given the significant Lindy effect they have

Uniswap Licensing Concerns

There has been suspicions raised regarding Uniswap copying CrocSwap and Balancer v2 models

The main issue was the ‘open source narrative’ painted by Uniswap, yet underlying it there is a more restrictive license that limits open innovation

There was a common consensus amongst the co-hosts that this is the power of brand and clout. David, in particular, mentioned that this will also be a contributing factor to the monopolies in the future

Multichain Thesis: Uniswap’s Role

Context: Given the myriad of both EVM and non-EVM chains, what role does Uniswap take, and how will this role manifest from a connectivity / interoperability standpoint (e.g. bridging liquidity)

Uniswap has been deploying across L2s. Eventually, there will be a need for the entire crypto space to converge on 1 interoperability standard. This is where the main innovation for Cosmos: Inter-Blockchain Communication (IBC) comes in. IBC is essentially an interoperability standard which makes it possible to remove trust assumptions, and it is one of the most battle tested interoperability standard existing. With efforts to make L2s IBC-compatible (e.g. Polymer Labs), the DeFi vertical is moving towards a super-chain, where it’s possible for all chains to communicate

How this will potentially look like for Uniswap: Front-ends deployed on all L2s. These front-ends will be able to communicate asynchronously, made possible by IBC (or other interoperability standards). Users could be making their swap on a single front-end, when in fact the liquidity is being routed through other chains as well

IBC’s Upcoming Updates

It is likely that IBC will see a lot of interesting developments in the next 12 months, contributing to making the entire cross-chain experience seamless. Brilliant teams are working towards this, including Strangelove and Stride

Migration from Uniswap v3 to v4

The migration from v2 to v3 was slow, and it is anticipated that the migration from v3 to v4 might be even slower, given the complexity of deploying concentrated liquidity pools. It remains to be seen whether Uniswap might run a liquidity mining campaign to incentivize liquidity migration over to v4

Disclaimer: Some content has been rephrased for better understanding.

Santiago: Let’s start off with some brief introduction.

Josh (Astria): The CEO and co-founder of Astria. Prior to Astria, Josh was at Celestia, working mostly on how to deploy rollups more generally on Celestia, taking a slightly distinct model from existing L2s in the existing known paradigm (i.e. Optimism & Arbitrum). Prior to Celestia, Josh worked at The Graph and Google. The bulk of the research in crypto was focused on scalability and Josh saw shared / decentralized sequencers as a continued extension of this scalability research.

Ben (Espresso): Got introduced to crypto through academic research, while doing a PhD in applied cryptography in Stanford. Started working on applications of cryptography to blockchain since 2015, focused on these areas:

• Alternative ways of doing consensus in a permissionless network (Proof-of-Work, Proof-of-Space, Proof-of-State)

• Using cryptographic tools to scale blockchain performance

Was previously at Filecoin, where he worked on problems related to randomness beacons which is incorporated into present day Ethereum. Building Espresso Systems is a long term passion to discover blockchain scaling without compromising on what they are supposed to do and their core principals of decentralization and fault tolerance.

Jason: What are sequencers and validators?

Ben (Espresso): Sequencer is a term that has arisen from this more modular description of blockchain.

The original concept of a blockchain is as follows: There is a distributed virtual machine (VM) and it has to order transactions (txns) to a state machine and execute them.

Even with some roles outsourced to L2s, mainly proving and execution, which is the core of how rollups achieve scalability or remove computational bottlenecks in blockchain, there are still other roles and functions that have to be taken care of. To elaborate on this, if rollup is proving the result of executing some sequence of txns → How do these txns get ordered? Do they get ordered and not executed by the L1? Or is there an external system to handle the ordering? This is similar to how the data availability (DA) layer has been outsourced to DA layers.

All of the above mentioned functions are required for consensus. First is to make data available, which has to be ordered by the sequencer (whether it is a single sequencer or a decentralized consensus protocol). These txns are then executed in the order they have been ordered to derive the resulting state of the machine. Afterwards, all other clients connecting to the system have to be convinced of that current state.

Jason: What is the state of how sequencers work on rollups today?

Josh (Astria): Rollups today generally conflate two components

(1) Sequencing: Ordering of the blocks. Find the given fork of a chain and append the block onto that based on the canonical ordering. Sequencing can be seen as the act of taking a set of txns in a mempool (or whichever other way the unordered txns are gathered) → Producing the ordered block → Attesting to the ordering, which is also known as validation.

(2) Execution: This involves generating the state root. The given state machine transition function is applied over an ordered set of blocks on top of the previous state root at the end of previous block.

The existing state of rollups is as follows: Centralized sequencers are run by Optimism or Arbitrum who gives the order of the block → These txns are batched → Txns are executed → Submitted to call data on the contract they have on Ethereum → Followed by a second step of attesting to a given state root and actual state of state machine for L2.

Key distinction to shared sequencing is separating the sequencing into just ordering. Whereas currently, rollups do both the ordering and the validation and attestation of the given state root.

Jason: There are 3 layers today: DA, sequencing and execution. Is it fair to say that right now sequencing, determining the state, and execution are all happening in 1 layer. But in the future, these will be owned by different folks that specialize in each of the layers?

Ben (Espresso): Today, most L1 blockchains are doing all 3 of these. Most rollups on Ethereum use Ethereum for DA but are taking ownership of, and centralizing the sequencing, execution and proving. Ben expects to see these roles become more modular.

However, it is not clear as to whether proving needs to be decentralized. Once the txn order has been determined in the state machine, anyone can submit a proof, it is not a permissioned role. Same thing goes for fraud proof. But the determination of which txns get to be included and in what order should not be centralized to retain blockchain’s original properties.

Sequencing was centralized initially for performance, mainly because it was too expensive or not user experience (UX) friendly to use Ethereum for both availability and ordering.

Santiago: How complicated is it, in the shoes of Arbitrum and Optimism, to integrate decentralized sequencing? Is it fair to say that they intentionally punted this, hoping for someone to fix it. Or are the teams employing a sort of progressive decentralization where it is more of a technical problem and they hope that the UX will get vastly better at some point.

Ben (Espresso): Ben highlighted that almost all projects today have decentralization in their roadmap. It is difficult for a scalability solution to brand themselves if they were to say ‘we solved the scalability problem by centralizing the process of ordering your data’ because this loses the core principals of:

1. Credible neutrality of the system

2. Anti-monopolistic behavior of the system

It is likely that existing rollups see decentralization as an iterative process. Given that it is already difficult to build zkEVMs and optimistic VMs, teams are likely to prefer starting with a centralized sequencer as it is simpler and can kick start the product. Eventually, these rollups are either planning on building their own decentralized solution for sequencing, or hoping for someone to come up with a solution to which they can plug in.

Santiago: From a user’s perspective, what’s the worst that can happen in today’s environment? Where it’s centralized, what are the biggest risks and the difference between Arbitrum and Optimism?

Ben (Espresso): This question applies to blockchain in general. What are the drawbacks of a centralized system, and what are the advantages of blockchain? The answer to this is not straightforward; it's rather nuanced. We can look at the evolution of how apps have been built on blockchain and explore whether decentralization has played a role in that.

When comparing centralized and decentralized systems, there are two important aspects to consider: credible neutrality and the economic perspective. One of the incredible thing about blockchain is that it achieves services with network effects without monopolization. One of the reasons as to why internet services are so monpolized is because of the extremely strong network effects, e.g. it would be hard to compete with Facebook. It becomes challenging for users to switch to a new system because all the data, users, and liquidity are concentrated in one place. Similarly, it's difficult for another blockchain to compete with Ethereum because liquidity, users, and apps are already established there.

However, due to the decentralization of its validator set, specifically the set of nodes that determine what gets included, how it's priced, and how it's ordered, competition among different nodes is fostered.

Centralization leads to short-sighted and myopic behavior from participants, rather than engaging in long-term strategies to price out users who are not willing to pay enough. In a centralized blockchain, we might see pricing strategies that limit txns to only one party willing to pay a significant amount, potentially setting the price above the market-clearing price (where supply meets demand) in an attempt to maximize revenue.

The scalability problem arises when we want to increase the supply side without compromising decentralization. If we increase supply but lose decentralization, it essentially results in a monopolistic system that uses monopolistic strategies to determine resource allocation.

Jason: To summarize, it seems that the risks of having a centralized sequencer are:

• Censorship (Risks of re-ordering)

• Risks of sequencer going down

• Monopolistic behavior

Santiago: Are users’ funds ever at risk? Is there a backdoor where a rug could occur? A lot of projects claim that the worst is a delay but users will always get their funds back because there’s no ability for the team behind the project to rug users and take assets.

Josh (Astria): With the fundamental structure, the only party allowed to append new blocks to the chain is the centralized party (sequencer). However, this does not mean that Optimism and Arbitrum have access to users' private keys to sign messages that move funds from one account to another. They can, however, hard fork the chain and zero out user funds. This action is detectable, and users can connect to the RPC and submit fraud proofs to prove an invalid state transition has occurred.

Assuming there is no possibility for bad actors to hard fork the chain in an undetectable manner, the team behind the platform cannot steal the funds. From a censorship perspective, there is an escape hatch that forces withdrawal txns to L1 by submitting txns directly through L1 smart contracts, inheriting the censorship properties from Ethereum L1. However, the concern arises during congested network times which degrades quality of service. If, for any reason, a user is censored by the sequencer and the sequencer does not submit and batch the transaction, the user will have to go through L1 and pay the associated L1 cost, which could be high when the network is congested. This raises questions about the cost savings of submitting txns to L1 versus L2.

Moving on to the discussion of Miner Extractable Value (MEV), there is a question of whether Optimism and Arbitrum, as sequencers, have the exclusive ability to extract MEV, while all the other MEV has a first-come, first-served (FCFS) model, which is basically just probabilistic spamming to get txns in. Detecting this fault is one of the major concerns. It is likely possible to detect if Optimism is front-running all txns, but it is inherently difficult in blockchain to ascertain if Optimism controls a pool of addresses or any other entity involved in front-running. Verifying credible neutrality becomes challenging.

In existing platforms like Arbitrum and Optimism, funds can be withdrawn using an escape path mechanism. The centralized sequencer is not capable of signing a transaction through a private key.

Ben (Espresso): When it comes to security, it’s easy to oversimplify. Comparing centralized and decentralized systems is like comparing apples to oranges; one is not inherently more secure than the other. We need to unpack the details. In the case of rollups, for example, bridging from Ethereum and depositing ETH into a rollup, the question arises: can those funds be stolen? The answer is no, as there are escape hatches and ways to withdraw. Ethereum continuously verifies the state of the rollup, and there is a commitment on the Ethereum smart contract to the definition of the VM.

However, if we look at VM in the way that it is defined by the company running the VM, where the company can change the way it works and update the smart contract, the question becomes more complicated as we are now looking at the security and finality of txns within the rollup itself. While proofs are verified by Ethereum every few hours, if the rollup provides soft confirmations through a centralized sequencer and users rely on those for finality, there is a risk of the txns being reversed.

Jason: To summarize, there are three roles to the blockchain:

(1) DA Layer: Guaranteeing the availability of the data

(2) Achieve consensus on txn ordering

(3) Executing the txn

Why do rollups even need a sequencer? Why can’t rollups use L1 for both DA and ordering of data?

Ben (Espresso): As a matter of fact, L1 can be used for making data available and ordering it, but not for executing it. The role of the rollup would then be to report the result of state execution. It can either post the result and wait for someone to challenge it with a fraud proof, or it can immediately prove that its correct using SNARKs. Essentially, rollups are just separating ordering from execution. This raises the question of whether Ethereum, as L1, is ideal for making data available and ordering it, or is there room for improvement.

The use of consensus protocols for both DA and ordering involve fundamental trade-offs. A system can be dynamically available but have long latency, or it can provide optimistic responsiveness for faster confirmation but may not be dynamically available. Ben's perspective is that the same validator set can run multiple ordering services, allowing users to choose which one to use. This is the approach taken by Espresso, which uses EigenLayer to enable Ethereum validators to run an optimistically responsive protocol, giving users more options. However, users can switch back to using Ethereum once Danksharding is implemented and Ethereum improves its way of handling data availability in a more scalable manner (which it is not currently optimized for). At that point, Ethereum can become a reliable service for ordering and data availability.

Cookies: Given what Ben has mentioned, I am curious as to the longevity of decentralized sequencer networks. Reason being that if users can opt back to using Ethereum eventually, it seems that decentralized sequencers network are just a momentary fix, and not a permanent one.

Hence, protocols in the modular blockchain ecosystem, such as Celestia and Espresso, are working on building systems that are optimized for data availability and ordering. These protocols focus on these specific functions without the need to handle execution, which is outsourced.

Jason: Why would a L2 want to use an external sequencer given that a centralized sequencer can be seen as a honeypot for MEV. The concerns that Ben mentioned, such as censorship resistance and monopolistic behavior, are challenges that protocols aim to address and protect users from. However, from the perspective of L2 solutions, these aspects can actually be advantageous. So, what incentives exist for L2 solutions to use an external sequencer?

Ben (Espresso): In order to accrue value, a rollup needs users. Thus doing things that are better for users does indeed lead to value accrual to a rollup. This is especially so in a competitive environment where multiple rollups exist and users have the freedom to choose which to use. It's important for rollups to align with user preferences.

Moving sequencing to another system, whether it's Ethereum L1 or another system in the modular stack (such as Celestia, Espresso, or Astria) for handling data availability and ordering, doesn't mean that the value won't be shared back to the rollup. In fact, there is a strong incentive for communities like Celestia, Astria, Espresso, and their stakeholders to retain rollups because rollups can easily migrate elsewhere if they feel they are not receiving their fair share of value. This poses an economic allocation problem, which is not just present in blockchains but also in other verticals. For example, when multiple phone companies share a common infrastructure, how do they price services and allocate revenue. However, this problem is solvable. If the system as a whole is better for users, more interoperable, and creates more economic value overall, it results in a larger pie to be shared.

Josh (Astria): The decision of whether to use Ethereum L1 for sequencing ultimately boils down to user demand. For example, one could execute txns through Arbitrum or Optimism and post it to L1 → The L1 will provide availability → There will then be an off chain process to give state root → Followed by attestation to the validity of txn → And eventually a challenge mechanism.

However, fundamentally, users prefer faster block times and wants faster soft commitments. One reason decentralized sequencers might be valuable is the general perception that users gravitate towards solutions that offer a higher-quality UX visually and tangibly. They will choose the 2-second option over the 20-second option, without visually seeing and understanding the underlying tradeoffs that result in the speed difference.

One of the difficulties of cryptography and security is that users only become aware of it when catastrophic failures occur. Prior to that, users typically assume that everything is running smoothly. This poses the question of ‘If a system fails catastrophically, is it too late to inform users that they had unknowingly accepted certain tradeoffs?’

Decentralizing sequencers essentially aims to maintain decentralization and taps on the modular thesis. By focusing on specific roles or a smaller set of blockchain functionalities, sequencers can optimize performance. Decentralized sequencers provide decentralization guarantees. Even though it might not necessarily be as strong as the one provided by Ethereum since they do not have that larger validator size or economic weight, they still provide soft commitments that are more credible neutral than a centralized provider. This offers both an improvement in the decentralization aspect and a higher quality UX desired by users, serving as an alternative to centralized systems. It should be noted that if the only way for users to experience the high-quality UX is through a centralized system, it is likely that a portion of the users will still opt for that. Thus, providing decentralized alternatives with good user experiences is essential.

Jason: There is this concern that rollups using shared sequencers may not experience the same level of value accrual as rollups with their own sequencers. However, it seems that both Josh and Ben are of the view that consumers and users will eventually prefer rollups that decentralize their sequencers. As a result, these rollups are expected to attract more users and, consequently, accrue more value.

Josh (Astria): The above point of view by Jason is a rather optimistic one. Josh has a more cynical take and believes that users don’t actually care about decentralization

The assumption is that as the user base expands, new users may be less ideologically aligned with the decentralized ethos compared to early Bitcoin adopters in 2011. It becomes the responsibility of technology creators to reinforce the importance of decentralization and provide a good UX, even for users who may not prioritize decentralization.

Simply promoting decentralization alone is not enough to attract users. Active marketing campaigns are necessary to highlight the significance of avoiding points of centralization within rollups. This prevents users, who may not have the time or inclination to thoroughly consider these aspects, from accepting centralization as the norm simply because it has been in place for a certain period of time. Effectively addressing this issue requires a combination of marketing and public relations efforts to advocate for changing the unacceptable status quo. However, it is crucial to approach this in a way that does not force users to make significant trade-offs in terms of UX. Ultimately, it is the responsibility of technology creators to strike the right balance.

Santiago: Would regulation be the main catalyst here?

Josh (Astria): From an external perspective, it certainly plays a role. Internally, the community should be pushing for decentralization. If, for instance, the founder of Arbitrum or Optimism were to be arrested, there would be a strong push to decentralize sequencers. However, we can also altruistically move towards the industry's ideals without being directly threatened by external regulatory bodies.

Ben (Espresso): It's not that users don't care about decentralization or that decentralization is solely for regulatory arbitrage. Users like and value the benefits that stem from decentralization. Even if they don't explicitly mention that they care about decentralization, users appreciate the fact that all apps on Ethereum are interoperable and composable with other apps, which is made possible because Ethereum is a decentralized system where everyone shares the same platform. This is not feasible if all rollups use a centralized sequencer. Hence, if decentralization is indeed a pre-cursor for greater interoperability between rollups, then users do value decentralization as they value shared liquidity and the ability to seamlessly transact across different ecosystems. Otherwise, users might have funds on zkSync (or any other ecosystems) and won’t be able to transact anywhere else.

Cookies: We can take the example of the subway / train. Without composability, when passengers switch from one line to another on the subway, they would be required to use a different card, despite all bring the same form of transport. In that case, I would have to keep so many different cards on me all the time to be able to take the subway smoothly. This taps into a point that Santiago and Jason mentioned in one of their earlier podcasts, where technological effects have to be apparent and tangible for users to notice it, with the example brought up being ChatGPT. In this case, given that users experience this composability and seamless txns upfront, it is likely that they will value this benefit of decentralization.

Ben (Espresso): PBS (proposer-builder separation) doesn't work with centralized sequencers, as there is no incentive for a centralized sequencer to collaborate with a block builder. This results in myopic behavior where validators prioritize immediate gains over long-term strategies to maximize gains. To put things into perspective, a service like Flashbot guarantees users that their transactions will not fail. A centralized sequencer, on the other hand, may charge users for failed transactions, as it can be more lucrative for them.

Santiago: To be fair, centralized sequencers do compromise the UX over the long term. Should users be interacting with Arbitrum and Optimism, and at some point these networks start getting greedy, users will migrate to other L2s. It is a quasi competitive market that is fragmented at the moment. Hence, when a L2 acquires users they can get away with some slack until it becomes a critical issue where bulk of the users migrate over to other L2s.

Ben (Espresso): Can competition among blockchains alone achieve decentralization? Perhaps decentralization wouldn't be necessary if all blockchains were perfectly competitive and offered the same functionalities. For instance, if Solana was a perfect substitute for Ethereum, competitive pressure on miners would discourage front-running of users. However, the fundamental challenge lies in the fact that internet services are prone to centralization due to network effects. If we aim for long-term resilience, it becomes crucial to decentralize the operation of internet services.

Santiago: What is the state of your development? Specifically, in terms of the UX changing once the sequencer has been decentralized, where are you guys in this process to make this happen. How does UX get impacted in the beta phase?

Josh (Astria): Astria’s code is public, but there is no public testnet yet. Currently, the focus is on internal developer network to test how users can submit their transactions within the testnet. The process is structured to be somewhat similar: Users submit transactions → Connect to an Ethereum node's RPC endpoint (Customizations are made to the Ethereum node to ensure compatibility with the shared sequencer) → Their transactions are included in a shared sequencer → The node can then read when a block is included, which operates based on the block time of the sequencer, determined by factors like the consensus algorithm and MEV timing tradeoffs. In terms of UX, it is largely the same as the current experience.

However, the main tradeoff occurs within the rollup itself. Once decentralization is implemented, there is a higher coordination overhead required for ongoing development.

For instance, if Optimism wants to make changes to their system, they can quickly and easily update the single sequencing node defining the canonical chain. This is similar to how any centralized service can roll out a hotfix within minutes. In contrast, incidents like the Dragonberry exploit on Cosmos impacted the general Cosmos SDK, requiring a significant coordination effort among all affected chains to update. While the UX can still have a structurally similar flow, it will differ from a first-come, first-served (FCFS) approach. Overall, the UX is expected to be relatively similar to the current process from an end user's perspective.

Santiago: Who are these sequencers? Are these the same folks that are behind Lido doing validation or are they enterprises, or typical single sophisticated developer out there. Are they industrialized validators or individuals?

Ben (Espresso): Building a decentralized sequencing layer is comparable to building a decentralized L1. Although the validator set is not yet established and is still being developed, the team at Espresso is excited to collaborate with EigenLayer. It's impressive that Ethereum already has 30,000 validators, although the actual number of distinct validators may be around 10,000 or fewer.

The key point is that Espresso's approach begins with the premise that Ethereum has a decentralized validator set, which is ultimately what Espresso aims to scale. Two different protocols building on Ethereum can share the same physical node set. It makes perfect sense to involve Ethereum validators in operating the protocols that runs on L2s. Otherwise, there could be an economic misalignment between the L1 and L2.

EigenLayer and restaking, in general, provide a clever way to subsidize users entry into the system. If they already have ETH staked, there is no need to invest in new tokens or capital to participate in the new service. It serves as a brilliant bootstrapping mechanism for acquiring a decentralized physical node set to run a new protocol that offers different properties from Ethereum. This novelty is not due to a modification in the physical nodes themselves but rather a shift in how the protocol operates and what it optimizes for.

Espresso’s focus is on developing a decentralized sequencing layer that can be utilized by various rollups, whether they are sovereign or existing major L2s. The approach Espresso is taking involves leveraging the Ethereum L1 for ordering and availability. In fact, Ethereum is actively working on improving its functionality as a DA and ordering layer. However, Ethereum is bound by a specific set of principles and tradeoffs in its consensus design. One of these tradeoffs is extreme dynamic availability, meaning the system remains operational even if only 10% of the nodes are online. While this ensures liveness, it results in minutes-long latency.

One reason why rollups have centralized sequencing is because users prefer the experience of a centralized server. This is in contrast to dynamic availability, where if the single server goes down, the entire system is affected. However, a centralized server offers low latency and fast confirmations. Therefore, we are striving to develop a decentralized consensus protocol that can still scale to the same physical node set as Ethereum but optimize for features typically associated with centralized sequencers, such as optimistic responsiveness. We aim to engage the Ethereum validator set to run this protocol as an alternative. Different rollups may choose between running on the Ethereum base layer for sequencing and availability or utilizing the protocol we are designing, called Hot Shot, which offers optimistic responsiveness but requires Hot Shot nodes. The progress of this protocol will depend on achieving a 75% online participation rate.

Jason: Josh, given that you spent 4 or 5 years in Google, are there any analogies to Web2? It seems that everyone is trying to do everything in-house right now. You see a world where there is specialization and it’s almost like paying amazon for AWS, where everyone used to run their own data centers but eventually we will all live in a world where there is AWS and Azure. What are these analogies that we can perhaps look towards?

Josh (Astria): We can think of it as a decentralization as a service that can be easily integrated into existing systems, similar to buying something off the shelve. The goal is to avoid the scenario where a rollup starts as centralized and only considers decentralization as an afterthought, prioritizing other aspects in a rapidly evolving ecosystem. By offering decentralization as a readily available solution, we hope to foster innovation and solve problems more effectively. This approach is similar to cloud services, which come with tradeoffs (centralization, paying hefty fees etc.) but allow companies to focus their efforts on specific areas. It enables smaller players to achieve comparable uptime to large corporations without the need for extensive infrastructure teams.

Ben (Espresso): The analogy of AWS works to some extent when it comes to companies using scalable database systems. They can leverage AWS instead of building their own distributed system. Similarly, rollup companies can utilize Astria or Espresso instead of building their own consensus protocol and decentralizing their sequencers. However, the analogy breaks down when we consider the bigger picture of the blockchain concept.

In the past, people questioned why they should build their own blockchain for their app instead of building on an existing blockchain. This is where the AWS analogy does not apply as people don’t use AWS to communicate with other services that are running on AWS. The success of Ethereum, where applications can plug into a shared VM and interact with other applications, highlights the value of shared infrastructure and state. This shift led to the boom in DeFi and NFTs, where economic value is derived from the shared state. If every rollup operates on its isolated system without interoperability, it resembles the early days of competing L1 blockchains building custom solutions for their specific apps. The potential for economic value lies in sharing infrastructure, state, and the sequencing layer, although this step alone is not sufficient, it significantly facilitates collaboration and value creation.

Jason: What are the economic implications of decentralized sequencers?

Josh (Astria): In a centralized sequencer system like Optimism or Arbitrum, users have to trust that they are not being front-run. With a decentralized sequencer set, there is a credible neutral system, where the nodes in the sequencer network compete with each other to some extent, almost like an intra network competition. Each validator or sequencer aims to be the most profitable and maximize returns for staking or delegation. This competition leads to MEV as a means to capture more rewards. Since there is inherent value in transaction ordering, it is in the sequencers best economic interest to extract that value. The question then becomes whether they keep the value for themselves or return it to delegates. How this dynamic plays out is a larger question, especially when there are multiple rollups, each claiming to contribute economic value to the chain. There are discussions on whether any MEV extracted should be returned to the rollup or distributed to the users. Determining the allocation of rewards and establishing clear boundaries between different rollups to determine their share of the rewards are open questions that require further investigation and evaluation.

Ben (Espresso): What if every rollup operated on the same sequencing layer without interoperability or cross-rollup transactions? Ben believes that it's not the shared sequencing layer itself that complicates matters, but rather the existence of cross-rollup activity. Assuming each rollup used the sequencing layer for ordering transactions (as they would with the DA layer), there would be infrastructure costs incurred. While the sequencing layer determines the transaction ordering, it is clear that transactions from one rollup are isolated from another. The value extracted through user bids on ordering preferences, known as MEV, represents a form of fee accrual based on combinatorial preferences rather than simple demand for gas. This value can be allocated entirely to the rollup, and it is up to the rollup to decide how to distribute it among their stakeholds: proofers etc. This forms an economic contract between the sequencing layer and each rollup. Complications arise when rollups leverage the infrastructure that enables cross-domain activity, which is what users want and is inevitable. Shared sequencing makes it easier for this cross-domain activity to occur. Even without shared sequencing but with bridging, challenges would arise when bridges handle transactions that should be executed on both ends. Determining how to divide the fees paid to the two parties becomes trickier in terms of economic allocation, this is a fascinating economic research question.

Jason: Nick White tweeted about the shared sequencer paradox:

• Option A: Extract MEV but be less attractive for rollups to use

• Options B: Don’t extract MEV but lose value capture

What do you guys think about it?

Josh (Astria): There’s the question of real-time calculation and how to determine the distribution of MEV across multiple rollups. When only one rollup exists, the MEV is specific to that rollup, and the same applies to another rollup. The messy economic questions arise when considering how much of the extractable MEV is created by the existence of both rollups and how to calculate their respective contributions. Determining the percentage of MEV extracted across a sequencing layer becomes challenging.

The question of whether an auction mechanism for ordering is morally illegitimate comes into play. If you don’t think that it’s morally illegitimate, then you would rapidly accelerate towards all MEV being extracted. The factors to consider are MEV share, order flow auctions, and MEV walls, which empower users to specify their preferences upfront and avoid significant slippage caused by front-runners and sandwich attacks. Negotiation can occur in this market, where users can submit low slippage transactions, knowing that they may take longer to be included. Shared sequencers are expected to extract the majority of profitable MEV for builders and searchers. However, the bigger question is still how the revenue will be shared after being extracted.

Ben (Espresso): Ben doesn't think that there is a paradox. He believes that sequencing layers, similar to other decentralized systems like Ethereum, can profit from users who pay for their ordering preferences, which is essentially what MEV is. The key question is how this MEV is allocated among the rollups that have chosen to utilize these sequencing layers.

Jason: Are rollups with different block times still composable if they have a shared sequencer?

Josh (Astria): This is an important point to note. Astria takes the view that the shared sequencer determines the block time for rollups that utilize it. The shared sequencer operates by creating mega blocks, and when a rollup utilizes it, they extract a subset of that mega block, thereby using the shared sequencer’s block time.

Ben (Espresso): Ben shares the same perspective. An application can choose to build on top of the shared sequencer and introduce a different level of latency. For example, a builder for a specific rollup could choose to take longer to build a block by buying up the slots to process for a designated period of time. This would result in a longer block time for the rollup. These kinds of guarantees and restrictions can be implemented at the application level as well. For instance, an application on Ethereum could have a longer block time to accommodate certain actions within the app. Ben gives an example of a voting protocol where votes are submitted for a day, causing the app running the selection to have a latency of a day. However, this app would still operate on a data availability and ordering layer that might even have instant finality.

Jason: Its a small space and its so early that you guys (Ben and Josh) are doing podcasts together. You guys are trying to push the narrative of shared sequencers together. Eventually the pie will grow larger and Astria and Espresso will end up competing with live products in the market. What is the working model of the timeline?

Ben (Espresso): Having been in the industry for a considerable time, the good thing is that many builders in the space have a positive sum attitude. These are the early stages of technology development, in particular for the scalability of L2s. Even if shared sequencers become competitors in the future, they continue to collaborate on a shared mission of promoting the idea and convincing others of its benefits. This cooperative spirit extends to research questions, fostering a sense of friendly competition among them.

Josh (Astria): There is the important question of ‘Is there a technical blocker of existing centralized sequencers adopting decentralized sequencing?’ Josh’s answer to that is ‘not really'. Tapping on what Ben said, setting up a decentralized sequencer network resembles the process of setting up a new L1, where there is a need to acquire validators (in this case this will be achieved by leveraging on Eigenlayer) → Establish a new network → Coordinate network operations → Run network and produce blocks. This process is not a novel problem, as evidenced by the numerous Tendermint chains launched in a year.

Astria is looking to launch within a year.

Drawing from his experience in big tech and open source domains, Josh highlights the benefits of a competitive environment. With industry giants like IBM, Google, AWS, and Azure building similar solutions and constantly presenting their solutions, it can be observed that competition is beneficial for the industry as a whole. This healthy competition will play a role in driving innovation and pushing the boundaries of functionality in the crypto and decentralized network space. This competition acts as a catalyst, urging participants to improve their offerings and drive progress throughout the industry.

Jason: Josh mentioned that restaking is exciting but something will get blown up because of restaking in the next cycle. Could you expand on this?

Josh (Astria): Restaking is essentially rehypothecation of risk. The concept here is that a certain amount of economic stake is used to carry out multiple things, which all has the potential of going into failure mode. When this happens, there is the ideological question of did they mess up (fault) or were they actively malicious (fraud). The system is tested as we do not know how many layers of applications will be restaked with the same amount of economic weight.

Josh has a cynical take that over a longer timeframe, the system will be stretched to limit, experience failure mode and thereafter enter a pendulum (back and forth) phase, essentially consistent testing.

While restaking offers the potential for new development opportunities with strong economic guarantees, there is a possibility of certain applications pushing pass the boundaries and messing up, which will necessitate parameter adjustments. This phenomenon is similar to adjustments made in other economic markets, where the change in interest rates will lead to certain level of economic engagement. However, this might eventually lead to a collapse which will then require a new adjustment of the deposit ratio and other metrics.

However, he also acknowledges that decentralized networks are inevitable, and no one can prevent their implementation. If the system is desirable, it will be embraced by the ecosystem, which will navigate the challenges and dynamics that arise.

Ben (Espresso): Ben disagrees with the point of view brought up by Josh. He believes that restaking is fundamentally different from bring overleveraged in other economic scenarios. On the contrary, Ben thinks that restaking subsidizes participants who have already locked up capital to one protocol, giving them the right to participate in another protocol.

There are multiple factors to consider when assessing the risks involved. It’s important to first distinguish whether its a

• Personal risk taken by individual validators who are now participating in multiple protocols or

• Systemic risk with a potential contagion that could lead to multiple validators experiencing errors and being slashed when they should not be.

Slashing is not intended for unintentional errors. We don’t slash for liveness as that is fundamentally very risky. Slashing is meant to enhance safety by penalizing nodes that intentionally deviate from the protocol. An example would be double-signing messages, which could occur if the node is hacked / compromised. However, this is something that we want to slash for as it is a form of corruption and is not accidental.

This increases the incentive for nodes to ensure such incidents do not happen. Ben argues that these faults are not independent and uncorrelated across different systems. The measures taken to prevent accidental errors are correlated and interconnected. Restaking, therefore, poses a local risk rather than a systemic one. If a party is slashed due to an accidental incident and their economic stake is redistributed, it does not fundamentally change the security properties of the system.

Conclusion

Santiago: When will we see decentralized sequencers hit the space?

Josh (Astria): we will have significant progress by EthCC. We will have decentralized sequencers within a year. It’s not that challenging from a technical standpoint, it is not wildly unsolved. it is more of prioritization and the burn down of other priorities is the catalyst.

Ben (Espresso): Building any of these systems are hard. Decentralized systems are hard to begin with.

We will have decentralized sequencers within a year but it may take time for the system to fully mature in terms of the after effects:

• Are we going to solve mechanism design for this space?

• Are we going to have fully operational bridges across all rollups running on shared decentralized sequencers?

• Are we going to have PBS perfectly solved?

Note: In each of the following phases, I will describe what it looks like in crypto, and provide one or two real world analogies for ease of understanding.

Disclaimer: Views are my own. I’m just a talking Cookie.

Phase 1: Infrastructure Plays The Catcher

Infrastructure is the starting point, and dApps have to leverage it to be able to build out use cases. When the Ethereum Virtual Machine (EVM) was first launched, there were hardly any dApps built on it. This is a function of the novel infrastructure, which requires time for people to comprehend its potential, play around to understand what’s possible with it, and actually create a working product.

Real-world example: Cookies stands on a big plot of grassland and thinks, I should construct a building here, a shopping mall. Once built, it is just an empty building, and we have to wait for shops to start setting up.

The above real-world example will be used in the following sections of the article.

Phase 2: Infrastructure Catches dApps

Once people have experimented sufficiently with the infrastructure to understand its capabilities, dApps are built and launched for users. Since the dApps build using the infrastructure, in most cases the infrastructure layer flips on their fee switch. With that, economic rewards begin to accrue to the infrastructural layer. Examples include

• dApps paying oracles (e.g. Chainlink) for data

• Transaction fees are paid to base layer infrastructure: e.g. Ethereum

Due to the diverse profile of market participants, there will be a large variety of dApps being created. Case in point, within each L1 blockchain there are various verticals: DeFi, NFT, SocialFi, Games etc. And each of these verticals have a whole suite of specialized sub-categories. DeFi itself, for example, is split into different product such as DEXs, staking, money markets, stablecoins etc.

Real-world example: Business owners begin to rent spaces within the shopping mall to set up their own stores. And evidently, shopping malls have a variety of stores to cater to customers and their different needs: food, lifestyle, entertainment, fashion etc. And within each of these categories, there is usually multiple stores. We can’t expect everyone to come to a shopping mall and want to eat McDonalds right? (Disclaimer: I do love my fillet o fish). But at the end of the day, the shopping mall is now crowded with people.

At this point, we need to make a distinction between user facing infrastructure and non-user facing infrastructure. User facing infrastructure include wallets and bridges, amongst many others. While non-user facing infrastructure could be oracles, data storage, staking hardware etc. Running back to our shopping mall example, user facing infrastructure would be things like the escalators and doors, while non-user facing infrastructure refer to the wiring and air conditioning hardware.

Phase 3: dApps & Users Takeover as Catchers

The good days are numbered.

As more dApps build on the existing infrastructure, coupled with the increasing number of users, the infrastructure layer begins to experience the following problems:

1. Limited Infrastructure Capacity

   A fairly common occurrence with infrastructure projects, which arises due to the architectural constraints. This was evident when Ethereum was unable to sustain increased DeFi and NFT activity, which led to network congestion. This eventually manifested in the form of sky-high gas fees (sometimes my gas fees cost more than my NFTs, but it doesn’t matter because most of my NFTs are worth zero now). At this point, both the dApps and users start demanding more and begin to seek alternatives.

   In the real world, a shopping mall will eventually run out of space if it attracts an excessive number of customers. It becomes difficult for people to move around; lifts become congested, and it takes an extremely long time before people are able to make their way up the levels to the store they would like to visit. One other example would be that as more and more people start driving cars, the roads eventually get congested, increasing travel time.

2. Changing User Demographics

   The market size constantly grows. New users come in, and that’s how an industry is sustained. However, within crypto, there exists a huge barrier to entry: onboarding. The average crypto transaction is too tough for a layman to execute. I remember the first time I tried to get money on MetaMask, I had to keep asking my friends whether I had lost my money or if the funds were just there somewhere. Having to interact with a crypto wallet without prior knowledge is difficult because of the lack of intuitive design (not too much of a design problem, but more of a technological constraint).

3. New User Demands

   As a function of technological advancements, user demands constantly shift. Or rather, the innovation on the dApp layer and the increase in users accelerate far ahead of what the infrastructure has to offer or is able to accommodate.

   This was one of the key reasons why alt L1s such as Solana gained the favor of the market. The high speed that Solana’s architecture featured attracted developers, as it meant that the dApps they built would not be subjected to slow transaction times, which compromise the level of user experience (UX), resulting in user churn.

   On the user front, the low transaction fees were highly appealing. Imagine a few cents compared to a few hundred dollars; which would you rather pay? (Definitely the few hundred dollars because we balling). But no. Spend your money wisely, Anon.

   And there we have it: the combination of dApps and users moving out of the existing infrastructure to elsewhere. The chart below shows Solana’s TVL increasing by 1,870% from $507.5 million in July 2021 to $10 billion in November 2021.

The above paragraphs are indicative of the phenomenon that the technological innovation of dApps and user needs moves at a speed that’s faster than what the infrastructure layer has to offer. And this essentially results in dApps and users leaving the existing infrastructure in search of a new home that has more to offer. And this is where things get interesting.

Phase 4: Infrastructure as Catcher Again. But This Time It’s Different

With the dApps and users now far from home, the infrastructure team has some soul-searching to do to figure out how to attract dApps and users back again.

There are two possible outcomes when infrastructure has to take on the role of a catcher again:

1. Infrastructure Goes Obsolete

   All this running has tired out the infrastructure team. Cardio tough. When this happens, the team stops innovating and improving the infrastructure and leaves it to die out like a candle. Back in the good ol' days, we had Nokia as the dominant phone maker, which has since been replaced by Apple.

2. Accept Its Fate

   Despite the churn, there are still dApps and users on the infrastructure. Some might think that these loyal supporters are sufficient, and there isn’t any pressing need to attract more users. Evidently, we're not preparing for future churn, but it’s okay, live in the present, right?

3. Infrastructure Chases

   Then we have the heavy hitters. These are teams that will look at the current constraints of their infrastructure, and start making innovations. Very evidently, we have Ethereum within this field. Congestion? We change from proof-of-work (PoW) to proof-of-stake (PoS). Still not fast enough? Rollups. Still not fast enough? Sharding. UX sucks? ERC-4337. Evidently, there are a lot of innovations being incorporated to maintain or even grow the market share they can capture.

Wait, wait, but things look a bit different this time around, don’t they?

The first time infrastructure took on the role of a catcher, they didn’t really know who they were catching. They were just running. Infrastructure was built, but the use cases weren’t exactly obvious. This time around, there is a distinct problem that has to be solved. From here, we begin to see a divergence in the type of infrastructure.

1. Generalized Infrastructure

   Building a very generalized piece of infrastructure that does not have an existing market that recognizes its potential use cases. This has sometimes been discounted by investors, who think that the lack of an apparent use case gives it a very slim chance of success.

2. Specialized Infrastructure

   A very apparent product-market fit exists for specialized infrastructure, where they are tackling particular problems that exist within the space. For example, congestion on the Ethereum network: rollups handle the execution and reduce the bottlenecks experienced on Ethereum.

Side Note: Some Infrastructure Die Out

The market is never stagnant. There are some scenarios where the infrastructure innovations occur at a pace that’s too slow. A feature that was demanded by the market just a few months ago to solve a problem might no longer be required due to either market needs changing or other infrastructure innovations having solved the problem.

Mature Industry: Specialized Infra > Generalized Infra

I personally find that as time passes, the infrastructure market finds itself filled with a significantly larger number of specialized infrastructures. This phenomenon is most likely a result of the ease of building when there’s a tangible problem to be solved, rather than working in a white space with no particular direction to work in. We do see this existing in the crypto industry in this day and age, where infrastructure projects tend to solve one, if not all, parts of the blockchain trilemma: speed, scalability, and security.

So How Do We Invest?

I am going to paint rather broad strokes here. But with the market cycle described above, it seems there might be some pirate maps investors can follow to get a general sense of where to invest.

1. Generalized Infrastructure | White Spaces

   If you want to invest in Cookies building a shopping mall, yes, that is possible. This probably comes with the highest risk, given that there is no existing market to tap into, making the potential revenue a question mark and leaving one scratching their head on how it could be monetized. But with this high risk, comes high rewards, as generalized infrastructure can house a lot more dApps and use cases.

2. Specialized Infrastructure | Tackling Existing Problems

   This is the low-hanging fruit. See a problem that exists today? Find a solution to it.

3. Specialized Infrastructure | Tackling Future Problems

   If we believe that, it is indeed a cycle. Every infrastructure solution is eventually followed by a problem. One could scrutinize these solutions and identify areas in which they might be lacking, which would eventually turn into an addressable problem based on certain market changes.

Conclusion

This has genuinely been me rambling on about what I think about the infrastructure landscape. But to summarize, infrastructure and dApp innovation are in a cycle. At times, the infrastructure is waiting for dApps to build using it, and at other times, the dApps are waiting for the infrastructure to improve to accommodate them. We eventually arrive at an equilibrium where projects are broadly split into generalized or specialized infrastructure, presenting various investment opportunities. Remember, a problem represents an opportunity.

Privacy is a necessity. There’s a reason why we set a passcode for our phones. There’s a reason why our bank account details are not easily accessed by others. But privacy, is a double-edged sword. This duality is rather apparent in the web3 space, with the most prominent example being the Tornado Cash sanction in 2022, which left the industry separated into two camps. On one side we have got the supporters of this ‘removal / limitation of privacy’ movement, with the argument that ‘privacy leads to problems such as money laundering’. Not wrong, right?. On the other side we have a group of dissatisfied individuals with the argument of ‘it is my rights to have my data stay private and known only to me’. Once again, seems right.

With the current landscape, I believe we can agree that crypto is way too transparent. By transferring some ETH from my account to another, the recipient is able to figure out that I hold no $PEPE in my wallet and missed out on generational wealth. That would be analogous to me buying a matcha latte at Starbucks and the cashier now knows that I don’t have enough for a latte the next day (because no $PEPE…). For crypto to achieve a money-like state, where peer-to-peer crypto transactions are a norm, privacy is a necessity. Some examples Nocturne brought up include the ability to:

• Receive payroll on-chain without revealing salaries

• Make purchases without divulging spending habits

• Store assets on-chain without disclosing net worth

Within the privacy sector we have seen efforts from multiple players, including Zcash, Monero and Mina Protocol. But it seems that the level of adoption has been rather stagnant. As to why, you can check out this article by @luffistotle from zeeprime.capital on why privacy has failed.

Nonetheless, we still see efforts being put in to achieve a balancing point that could potentially make the industry nod their head and say ‘yes to privacy! i mean, yes to regulated privacy!’. This is where Nocturne steps in with their solution, aiming to address the unmet needs of the privacy-conscious and integrate privacy into existing applications for the average user.

The main aim of this article is to have a better understanding of Nocturne’s architecture, to which I break down aspects of the documentation and provide analogies.

Disclaimer: The article is rather technical. I had to eat chocolate while reading the documentation to stay calm when I didn’t understand parts of it initially. If you don’t want your brain to hurt from reading, scroll to the bottom and read the ‘Conclusion’.

Introduction of Nocturne

Main innovation Nocturne brings to users: Private accounts.

Nocturne allows users to send or receive assets from Externally-Owned Accounts (EOAs) and contracts to private, stealth addresses. This keeps the user’s identity and asset balance a secret. It is possible for users to prove that they own these assets (which are hidden) without having to reveal any private information.

Benefits of Nocturne

Nocturne allows users to

1. Send / receive any token (ERC20/721/1155) to / from existing EOAs and on-chain applications (protocols such as Uniswap etc.) anonymously

2. Confidential payments to other stealth addresses (hidden sender, recipient and amount)

3. Prove asset ownership (solvency) and transaction history (compliance)

Point 2 taps into the earlier mentioned use case of receiving payroll on-chain without having to reveal the salary, net worth or spending habits. This makes absolute sense to a user. In the web2 world, me receiving a salary from my employer does not allow them to identify that I willing pay a million for a picture of a rock.

Particularly on point 3, the possibility of an user to prove their account solvency and compliance status (with no prior suspicious transactions) can open up a whole new set of opportunities for on-chain borrowing and lending. On the borrowers’ end, they will be able to receive a loan without having to disclose private information and on the lenders’ side, they will be able to accurately affirm the credibility of the borrower and offer a suitable level of interest rate. This builds into the increased level of capital efficiency given to users.

Something I would like to bring up here, but not delve deep into, would be the possibility of receiving loans based on income. This could be made possible by the combination of point 2 and point 3 mentioned above. Looking at the bigger picture, this opens up doors to much more robust on-chain protocols, just as how our salary can be used to qualify for mortgages, credit cards etc.

User Interaction with Nocturne

The team at Nocturne is forward looking, building the protocol out with a high level of flexibility that allows its user experience (UX) to take several forms. The following are some potential use cases that the team has highlighted:

1. Private Asset Vault

This is the first user product that will be built on Nocturne. As simple as it is, this vault allows users to privately store their assets over a period of time, while earning yield on the deposited assets. Should users wish to utilize these assets for activities like trading, they can withdraw them to burner wallets.

2. Backend for Private Payments

Instead of sending funds directly to a recipient’s EOA, a user can send the funds into Nocturne, and assign the stealth address to receive funds. By going through Nocturne, the transaction is kept private and secure.

One use case highlighted by the team is the setting up of a private payroll system. Looking at crypto companies these days, this is an aspect that they lack. With Nocturne, it is possible for employees’ salaries to be kept private.

Should users require an even higher level of confidentiality to their transactions, perhaps on an institutional level, they can opt in for confidential payments.

3. Privacy-Preserving Smart Contract Wallet

Here comes the exciting portion. Existing crypto users are reliant on numerous pieces of core infrastructure. The one that’s non-arguably the most important for users, would be the hot wallet, i.e. MetaMask etc. Hence, with any novel infrastructure that aims to impact the user experience (UX), it is critical for it to be compatible with wallets.

Nocturne checks off this box, with an off-chain SDK which can be integrated into existing wallet clients. This integration will allow users to continue using their wallets, but with the added benefit of built-in asset privacy.

Nocturne’s Architecture

The figure below depicts a high level overview of Nocturne’s architecture:

There are a few steps to Nocturne’s system. Let’s go through them one by one.

Deposit of Funds

Deposits into Nocturne have to undergo a screening process to minimize the inflow of illicit funds (more on this in the ‘Compliance’ section below). This is achieved by having a permissioned off-chain actor inspect all deposits, who will then decide whether to approve or reject the deposits.

To this point, I would like to express concerns over the permissioned off-chain actor due to two reasons. Firstly, what are the chances of this actor being exploited? Given that it is permissioned, what will this permissioned process look like? Secondly, given that it is off-chain, would it be difficult to track the approval / rejections that have been issued by the actor?* *

Here’s the step by step flow of how deposits into Nocturne are carried out.

1. User initiates deposit by specifying stealth address to deposit to

2. Funds are escrowed in Deposit Manager

3. Deposit Screener sees the deposit request and screens through wallet

   a. If approved → Deposit Screener signs the deposit hash → Deposit completed

   b. If rejected → User can retrieve escrowed funds

Storage of Funds | Upon Deposit Completion

Once the user’s deposit has been completed, this is the steps that lead to storage of funds within Nocturne.

1. Deposit Manager sends funds to Teller

   Do keep in mind that the escrow of funds in Deposit Manager only lasts for the period between initiation of deposit and approval / rejection of deposit.

2. Teller calls Handler to track note commitment of the funds

   The deposit is inserted as a note commitment in Nocturne’s Merkle commitment tree. This tracks all of the transactions that are occurring.

Let’s understand a little bit more about what notes are.

A note can be considered to be a ‘dollar bill’ that has a owner. There are 3 key characteristics to a note:

• Owner: An anonymous stealth address for the note’s owner

• Asset: Indicates the kind of token the note represents. Could be ERC20/721/1155

• Value: Indicate how much the note is worth

An example to help with understanding. Cookies has a ERC20 token that is worth $1, let’s look at the characteristics this note will have:

• Owner: This will be Cookie’s stealth address

• Asset: The note represents an ERC20 token

• Value: $1

Operation | Usage of Funds

Here is the flow that occurs when a user wishes to carry out an operation with funds in Nocturne.

1. User puts in an order to swap 0.1 ETH for 200 DAI

2. This operation will be collected by the bundler and relayed to Teller, together with the proof

3. Teller verifies proofs

4. User’s 0.1 ETH will be sent to the Handler (operation executor)

5. Handler executes the operation by swapping the 0.1 ETH for 200 DAI on a DEX

6. Once the swap is complete, handler tracks this change by adding a note commitment for 200 DAI

7. 200 DAI is sent back to Teller (storage)

One might be curious as to why the Teller and Handler are separate. The Teller serves as a storage for all of the user’s funds, while Handler only has access to the funds that users wish to transact. Should the Handler have access to all of user’s funds, a single exploit could potentially cause bulk of the funds to be lost. Thus, this segregation of roles helps to increase the robustness of Nocturne’s security.

Privacy Achieved Through Stealth Addresses

The above explains how user transactions are carried out in Nocturne. In this section, let’s take a look at the key innovation that allows for private transactions.

Keys & Stealth Addresses

This concept of stealth addresses holds the key to private transactions.

A stealth addresses comprises of two keys:

1. Viewing Key: Allows viewing of transaction, but spending is not allowed

2. Spending Key: Allows for both viewing and spending

Essentially, a user’s account details can always be kept private regardless of the kind of transactions performed with stealth addresses. With this, when I carry out a peer-to-peer transaction, the recipient will not be able to look into my account history to find out that I bought BTC at $69,000.

I have some questions regarding the differentiation of canonical and stealth addresses. It seems rather redundant for other users to have access to my canonical address, if the main aim is to spin out a stealth address for others. Wouldn’t it be sufficient for other users to have access to a stealth address that I spin out for them, and that can be the address used to pass on to others?

Compliance | Say ‘No’ to Regulatory Clampdowns

Over the past year, we have seen the SEC crack down on the crypto industry, with multiple parties being on the receiving end: stablecoins, centralized exchanges, protocol / company leaders. Privacy protocols, in particular, would intuitively be subjected to a higher level of scrutiny, given the inherent lack of transparency it results in. To steer clear of such regulatory issues, there are compliance features to Nocturne:

1. Deposit Filtering

   High-risk deposits are filtered out using public on-chain metadata and known address blacklists. This by-passes the need for users to share any additional information beyond what is available on-chain.

2. Per-Address Rate Limits

   There is a default rate limit for the amount each address can deposit everyday.

3. Global Rate Limits

   Deposits across all address are limited by the global rate limit.

With the above mentioned features acting as barriers to entry, Nocturne is able to effectively keep malicious funds out of the protocol. Not only does this play a part in keeping it compliant, it also ensures that users of Nocturne are safe-guarded against protocol hackers.

Conclusion

If somehow you are here at the conclusion but didn’t manage to read through the above parts (no worries I honestly wanted to flipped the table a few times when I couldn’t understand Nocturne’s architecture and had to drink some milk to calm myself down), you can read this introductory article by the team themself, and for more details, you can visit the documentation here.

To summarize, Nocturne is looking to enable private transactions through the usage of stealth addresses. With the industry seeking for mass adoption, privacy in crypto is a necessary pillar that has to be strengthened. Through the materials, it is apparent that Nocturne is looking to contribute to this pillar in a manner that does not result in UX tradeoffs, while offering increased level of flexibility and security.