Blog

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Tezos Governance Milestone: Quebec Proposal Approved
An overview of the Quebec upgrade and its impact on Tezos governance, staking, and network dynamics
December 3, 2024
5 min read

Tezos governance has been very active lately. In June 2024, the Paris upgrade introduced important changes, including a new locked staking model and adaptive issuance that ties rewards to the ratio of staked XTZ.

Just a few months later, on November 24, 2024, another significant governance milestone was achieved with the approval of the Quebec proposal during Proposal Period 135. Quebec is anticipated to go live on Tezos in early 2025.

A Vote Between Two Proposals

Two proposals were up for consideration:

  1. Quebec – Proposed by Nomadic Labs, TriliTech, and Functori, with backing from the Tezos Foundation.
  2. Q3NA – A community proposal by Tez Capital.

Both proposals built upon the Paris changes but had no differences in approach besides in the adaptive issuance schedule. Ultimately, Quebec won with 187 million votes to 104 million, with a 33% participation rate among bakers.

Changes Introduced by Quebec

Lower Block Times

Reducing block times from 10 seconds to 8 seconds will enhance performance and improve UX by offering faster finality.

Increased Delegation Limit

Bakers can now accept delegations up to 9x their stake, up from 5x. This benefits bakers, allowing them to earn higher rewards by accommodating more delegated stake.

Reduction in Voting Power for Delegators

Paris introduced locked staking, incentivizing users to stake rather than delegate their XTZ, and reducing delegated voting power by 50%. Quebec takes this further, reducing the voting weight of delegated XTZ to 33% of staked XTZ.

This adjustment encourages delegators to transition to staking for full voting power and rewards.

If you're currently delegating your XTZ to a Chorus One baker, visit this website to learn how to start staking and maximize your rewards!

Adaptive Issuance

Quebec implements a more aggressive reduction in baking rewards to address sell pressure on XTZ. Under Quebec, if 50% of XTZ is staked, the yield is reduced to 1%, compared to 3% in the Q3NA proposal, as depicted on the graph below.

Some validators and community members raised valid concerns:

  • Can the network thrive with a 1% issuance rate if only 50% of XTZ is staked?
  • Smaller validators may face challenges as rewards decrease, potentially consolidating stake with larger validators.
  • Lower yields might drive some stakers to explore alternative networks with higher returns.

Supporting Quebec: A Long-Term Vision

While these concerns are noteworthy, the focus remains on the network's long-term health, and the community has clearly shown its preferred choice.

Despite some reservations about the steep reduction in issuance, Chorus One and other supporters voted for Quebec. This decision reflects confidence in the Tezos Foundation’s long-term vision and its alignment with the ecosystem's core contributors.

Action Required

If you're currently delegating your XTZ to a Chorus One baker, visit our guide to learn how to start staking and maximize your rewards!

About Chorus One

Chorus One is one of the largest institutional staking providers globally, operating infrastructure for over 60 Proof-of-Stake (PoS) networks, including Ethereum, Cosmos, Solana, Avalanche, Near, and others. Since 2018, we have been at the forefront of the PoS industry, offering easy-to-use, enterprise-grade staking solutions, conducting industry-leading research, and investing in innovative protocols through Chorus One Ventures. As an ISO 27001 certified provider, Chorus One also offers slashing and double-signing insurance to its institutional clients. For more information, visit chorus.one or follow us on LinkedIn, X (formerly Twitter), and Telegram.

Transaction Latency on Solana: Do swQoS, Priority Fees, and Jito Tips Make Your Transactions Land Faster?
Exploring Solana's updates—stake-weighted QoS, priority fees, and Jito MEV—and their impact on transaction prioritization and landing latency.
December 3, 2024
5 min read
TL;DR
  • Transaction inclusion is one of the biggest challenges for Solana today.
  • We’ve explored how different solutions impact transaction inclusion times:
    • Priority Fees minimally affect landing times.
    • Jito Tips also have negligible latency benefits.
    • swQoS is the most effective at reducing latency for all transaction types.
Introduction

Solana processes thousands of transactions per second, which creates intense competition for transaction inclusion in the limited space of a slot. The high throughput and low block time (~400ms) require transactions to be propagated, prioritized, and included in real-time.

High throughput on Solana comes with another advantage: low transaction costs. Transaction fees have been minimal, at just 0.000005 SOL per signature. While this benefits everyone, it comes with a minor trade-off—it makes spam inexpensive.

For end-users, spam means slower transaction finalization, higher costs, and unreliable performance. It can even halt the network with a DDoS attack, as in 2021, or with an NFT mint, as in 2022.

Against this backdrop, Solana introduced significant updates in 2022: stake-weighted quality of service (swQoS) and priority fees. Both are designed to ensure the network prioritizes higher-value transactions, albeit through different approaches.

Another piece of infrastructure that can help reduce transaction latency is Jito MEV. It enables users to send tips to validators in exchange for ensuring that transaction bundles are prioritized and processed by them.

This article will explore these solutions, break down their features, and assess their effectiveness in transaction landing latency.

Solana Transaction Anatomy

Let’s start with a basic building block—a transaction.

Solana has two types of transactions: voting and non-voting (regular). Voting transactions achieve consensus, while non-voting transactions change the state of the network's accounts.

Solana transaction consists of several components that define how data is structured and processed on the blockchain¹:

  1. Accounts, which represent the state of Solana.
  2. Instructions, which define the operations to be executed in the transaction (e.g. transfer SOL, read account state, write account state).
  3. Message, which includes:
    • Information on accounts invovled in the transation.
    • The most recent blockhash at the time when the transaction was created.
  4. Signatures, which cryptographically guarantee the authenticity of the transaction.

A single transaction can have multiple accounts, instructions, and signatures.

Below is an example of a non-voting transaction, including the components mentioned above:

On Solana, a transaction can be initiated by a user or a smart contract (a program). Once initiated, the transaction is sent to an RPC node, which acts as a bridge between users, applications, and the blockchain.

The RPC node forwards the transaction to the current leader—a validator responsible for building the next block. Solana uses a leader schedule, where validators take turns proposing blocks. During their turn, the leader collects transactions and produces four consecutive blocks before passing the role to the next validator.

Validators and RPC nodes are two types of nodes on Solana. Validators actively participate in consensus by voting, while RPC nodes do not. Aside from this, their structure is effectively the same.

So, why are RPCs needed? They offload non-consensus tasks from validators, allowing validators to focus on voting. Meanwhile, RPC nodes handle interactions with applications and wallets, such as fetching balances, submitting transactions, and providing blockchain data.

The main difference is that validators are staked, securing the network, while RPC nodes are not.

Transaction flow on Solana

After reaching the validator, the transactions are processed in a few stages, which include²³:

  1. Fetch, where the validator parses incoming packets for valid transactions.
  2. Verification, where the transaction signatures are verified.
  3. Banking, the core stage of the entire pipeline, where:
    • Accounts are locked to ensure no conflicting transactions execute simultaneously.
    • The transaction is executed in SVM, which processes program instructions and updates account states.
    • The results of the transaction (success or failure) are validated.
    • Transactions are processed in parallel in two voting and four non-voting threads using Solana's runtime.
    • Based on the leader schedule, a validator handles transactions as follows:
      • Process, if it is the leader.
      • Hold if it is two slots away from being the leader.
      • Forward to the current leader and next two leaders if more than two slots away.
  4. Proof of History, where transaction data and previous hash are hashed to determine the transaction ordering.
  5. Broadcast, where valid transactions are shared with the networks in groups called shreds.
Based on the Solana documentation

The transaction is considered confirmed if it is voted for by ⅔ of the total network stake. It is finalized after 31 blocks.

In this setup, all validators and RPC nodes compete for the same limited bandwidth to send transactions to leaders. This creates inefficiencies, as any node can overwhelm the leader by spamming more transactions than the leader can handle.

To improve network resilience and enhance user experience, Solana introduced QUIC, swQoS, and priority fees, as outlined in this December 2022 post:

  • QUIC Protocol: The QUIC protocol transfers data between two network nodes. It enables parallelization of data streams and requires establishing a connection between validators and RPC nodes.
  • Stake-weighted Quality of Service: swQoS is a mechanism that prioritizes network traffic based on the stake held by validators. It ensures that validators with more stake can send more transactions to the leader.
  • Priority Fees: In addition to the base fee of 5K lamports per signature, users can include an additional priority fee, to speed up the inclusion of their transactions.

Stake-weighted QoS⁴

With the adoption of the QUIC protocol, trusted connections between nodes are required to send transactions. The swQoS system prioritizes these connections based on stake. In this framework, non-staked RPC nodes have limited opportunities to send transactions directly to the leader. Instead, they primarily rely on staked validators to forward their transactions.

Technically, a validator must configure swQoS individually for each RPC node, establishing a trusted peer relationship. When this service is enabled, any packets the RPC node sends are treated as though they originate from the validator configuring swQoS.

Validators are allocated a portion of the leader’s bandwidth proportional to their stake. For example, a validator holding 1% of the total stake can send up to 1% of the transaction packets during each leader’s slot.

From the leader’s perspective, 80% of available connections are reserved for staked nodes, while the remaining 20% are allocated to RPC nodes. To qualify as a staked node, a validator must maintain a minimum stake of 15,000 SOL.

While swQoS does not guarantee immediate inclusion of all transactions, it significantly increases the likelihood of inclusion for transactions submitted through nodes connected to high-stake validators.

Priority Fees

Priority fees serve the same role as swQoS by increasing the chances of transaction inclusion, though they use a completely different mechanism.

There are two types of fees on Solana⁵:

  • Base Fee: This is a fixed 5,000 lamports (0.000005 SOL) per signature, typically one per transaction. It does not depend on the compute units (CUs) required to process the transaction.
  • Priority Fee: This fee is optional and specified by users for each transaction. It depends on the CUs requested by the transaction. CUs are used to estimate the computational cost, similar to gas on Ethereum.

Of the total fees from a transaction, 50% is burned, while 50% is received by the leader processing the transaction. A proposal to award the validator 100% of the priority fee has been passed and is expected to be activated in 2025 (see SIMD-0096).

Priority fees help validators prioritize transactions, particularly during high congestion periods when many transactions compete for the leader's bandwidth. Since fees are collected before transactions are executed, even failed transactions pay them.

During the banking stage of Solana’s transaction processing, transactions are non-deterministically assigned to queues within different execution threads. Within each queue, transactions are ranked by their priority fee and arrival time⁶. While a higher priority fee doesn’t guarantee that a transaction will be executed first, it does increase its chances.

Jito MEV

The final puzzle of transaction prioritization is Jito. This modified Solana client allows searchers to send tips to validators in exchange for including groups of transactions, known as bundles, in the next block.

It could be argued that the Jito infrastructure prioritizes transactions using a tipping mechanism, as users can send a single transaction with a tip to improve its chances of landing fast.

For a deeper explanation of how Jito works, check out our previous article on the Paladin bot, which provides more details.

swQoS, Priority Fees, and Jito Tips in Action

We now have a clearer understanding of how all three solutions contribute to transaction inclusion and prioritization. But how do they affect latency? Let’s find out.

Methodology

To calculate the time to inclusion of a transaction, we measure the difference between the time it is included in a block and the time it is generated. On Solana, the generation time can be determined from the timestamp of the transaction’s recent blockhash. Transactions with a recent blockhash older than 150 slots—approximately 90 seconds—expire.

The latest blockhash is assigned to the transaction before it is signed, so transactions signed by bots will be included faster than transactions generated by normal users. This method is not perfect, but still allows us to collect valuable information about latency and user topology.

Other factors beyond the swQoS and priority fees, such as the geographical proximity of nodes to the leader or validator and RPC performance, also impact inclusion times—we are not fully accounting for those.

To reduce the possible biases, we consider only slots proposed by our main identity from November 18th to November 25th, 2024.

Time to Inclusion

The time to inclusion across all transactions, without any filtering, has a trimodal distribution suggesting at least three transaction types. The highest peak is at 63 seconds, followed by another at 17 seconds, and a smaller one is at 5 seconds.

The second and third peaks are likely from regular users. This double peak could occur because general users don't set maxRetries to zero when generating the transaction. The first peak, at around 5s, is probably related to bots, where the delay between generating and signing a transaction is marginally zero.

We can classify users based on their 95th percentile time to inclusion:

  • Fast: Less than 10 seconds.
  • Normal: Between 10 and 40 seconds.
  • Slow: Greater than 40 seconds.

Most users fall into the “normal” and “slow” classifications. Only a small fraction of submitted transactions originate from “fast” users.

Let’s now break down transactions by source.

Priority Fee

Transactions can be categorized based on their priority fee (PF) with respect to the PF distribution in the corresponding slot. Precisely, we can compare the PF with the 95th percentile (95p) of the distribution:

  • Cheap: PF is less than 10% of the 95p PF within the block.
  • Normal: PF is between 10% and 50% of the 95p PF within the block.
  • Expensive: PF is greater than 50% of the 95p PF within the block.

The size of the priority fee generally doesn’t influence a transaction’s time to inclusion. There isn’t a clear threshold where transactions with higher PF are consistently included more quickly. The result remains stable even when accounting for PF per compute unit.

Jito Tippers

We can restrict the analysis to users sending transactions via the Jito MEV infrastructure, excluding addresses of known swQoS consumers. Interestingly, most Jito transactions originate from “slow” users.

We categorize tippers by siże of tips in the block, analogously to what we did for PF:

  • Cheap: Tip is less than 10% of 95p in the block.
  • Normal: Tip is between 10% and 50% of 95p in the block.
  • Expensive: Tip exceeds 50% of 95p in the block.

When we compute the probability density function (PDF) of time to inclusion based on this classification, we find that the tip size doesn’t significantly impact the time to inclusion, suggesting that to build a successful MEV bot, one doesn’t have to pay more in tips!

Within the Jito framework, a bundle can consist of:

  • A single transaction that includes the user operations along with the Jito tip (e.g. here).
  • Separate transactions, where one of them is a payment to the Jito program (e.g. here).

In both cases, the time it takes for the entire bundle to be included is determined by the inclusion time of the tip transaction. However, when a tip is paid in a separate transaction, we don’t track the other leg. This reduction in volume explains why the PDF of tippers differs from that of Jito consumers.

swQoS

It’s impossible to fully disentangle transaction time to inclusion from swQoS for general users, meaning some transactions in the analysis may still utilize swQoS. However, we can classify users based on addresses associated with our swQoS clients.

When we do this and apply the defined user topology classification, it becomes clear that swQoS consumers experience significantly reduced times to inclusion.

The peak around 60 seconds is much smaller for swQoS consumers, indicating they are far less likely to face such high inclusion times

The highest impact of using swQoS is seen in the reduction of the time to inclusion for “slow” users. By computing the cumulative distribution function (CDF) for this time, we observe a 30% probability of these transactions being included in less than 13 seconds.

When comparing the corresponding CDFs:

  • For Jito, “slow” users have only a 10% probability of being included in less than 13 seconds and 60% in less than 50 seconds.
  • For swQoS, “slow” users have 25% of probability of inclusion within 13 seconds and 86% in 50 seconds.

'Normal' users also benefit from swQoS. There's an additional peak in the PDF for these users between 9s and 13s, showing that some of “normal” users process transactions in less than 20s. Additionally, another peak appears around 40s, indicating that part of the slower users now see their 95th percentile falling in the left tail end of 'normal' users. This suggests that the overall spread of the time-to-inclusion distribution is reduced.

There is no statistically significant difference between the analyzed samples for “fast” users. However, some Jito consumers may also use swQoS, which complicates the ability to draw definitive conclusions.

Despite this, the improvements for “slow” and “norma”' users highlights swQoS's positive impact on transaction inclusion times. If swQoS explains the PDF shape for “fast” users, it increases the likelihood of inclusion within 10s from ~30% to ~100%, a 3x improvement. A similar 3x improvement is observed for “slow” users being included within 13s.

Summary

Transaction inclusion is arguably Solana's most pressing challenge today. Efforts to address this have been made at the core protocol level with swQoS and priority fees and through third-party solutions like Jito (remembering that the main Jito use is MEV).

Solana’s latest motto is to increase throughput and reduce latency. In this article, we have examined how these three solutions improve landing time. Or, more simply, do they actually reduce latency? We found out that:

  • swQoS delivers the highest latency reductions. This is evident for all types of transactions, but, especially for “slow”. For "fast" transactions, swQoS and Jito have similar performance, though comparing them can be tricky as overlapping use is hard to detect.
  • Priority fees, while helpful for transaction inclusion, have a minuscule effect on landing times.
  • Jito tips’ impact on latency is insignificant, especially for slow transactions.

Among the three, swQoS is the most reliable for reducing latency. Jito and priority fees can be used when the time to inclusion is less important.

References:

  1. Solana documentation: transactions
  2. Solana documentation: TPU
  3. Helius, Stake-weighted Quality of Service, Everything You Need to Know
  4. Solana documentation: swQoS
  5. Solana documentation: fees
  6. Umbra Research, Lifecyle of a Solana Transaction

About Chorus One

Chorus One is one of the largest institutional staking providers globally, operating infrastructure for over 60 Proof-of-Stake (PoS) networks, including Ethereum, Cosmos, Solana, Avalanche, Near, and others. Since 2018, we have been at the forefront of the PoS industry, offering easy-to-use, enterprise-grade staking solutions, conducting industry-leading research, and investing in innovative protocols through Chorus One Ventures. As an ISO 27001 certified provider, Chorus One also offers slashing and double-signing insurance to its institutional clients. For more information, visit chorus.one or follow us on LinkedIn, X (formerly Twitter), and Telegram.

Chorus One Partners with Fragmetric to Pioneer Liquid Restaking on Solana
Chorus One is excited to announce our partnership with Fragmetric, a leading liquid restaking protocol on Solana.
November 28, 2024
5 min read

Chorus One is excited to announce our partnership with Fragmetric, a leading liquid restaking protocol on Solana.

Restaking, one of the most significant innovations in the crypto space in recent years, is now arriving on Solana through Jito Restaking. This platform will leverage Solana native assets to support Node Consensus Networks (NCNs), applications that deliver services to Solana users.

While progress in liquid restaking has been impressive, the space still faces challenges that slow down its growth:

  • Ensuring fair allocation of rewards among participants.
  • Determining proportional penalties for LSTs in the event of slashing.

Fragmetric solves these issues with $fragSOL, an innovative liquid restaking token (LRT) powered by Solana's unique features:

  • Leveraging Solana’s token extension and transfer hook functionalities to enable time-based reward tracking for LRT holders.
  • Using the Normalized Token Program to pool LSTs into a unified economic framework, ensuring slashing events are fair.

Stay tuned as Chorus One shapes the future of restaking with Fragmetric and $fragSOL!

About Fragmetric

Fragmetric is a native liquid restaking protocol on Solana, with a vision of enhancing the Solana ecosystem's security and economic potential. Through implementing advantage of Solana's token extension, Fragmetric has effectively implemented NCN reward distribution. Furthermore, Fragmetric designed practical solutions, the Normalized Token Program for leveraging various LSTs in restaking platforms. Fragmetric’s mission is to build a secure, transparent, and highly efficient restaking infrastructure that empowers users and supports the stability of the Solana's restaking ecosystem.

About Chorus One

Chorus One is one of the largest institutional staking providers globally, operating infrastructure for over 60 Proof-of-Stake (PoS) networks, including Ethereum, Cosmos, Solana, Avalanche, Near, and others. Since 2018, we have been at the forefront of the PoS industry, offering easy-to-use, enterprise-grade staking solutions, conducting industry-leading research, and investing in innovative protocols through Chorus One Ventures. As an ISO 27001 certified provider, Chorus One also offers slashing and double-signing insurance to its institutional clients. For more information, visit chorus.one or follow us on LinkedIn, X (formerly Twitter), and Telegram.

The State of Ethereum Restaking: Economics, Challenges, and Future Directions.
This article presents a comprehensive overview of the Ethereum restaking ecosystem, exploring its key players, economic dynamics, and the challenges ahead for sustainable growth.
November 12, 2024
5 min read

Restaking is an emerging concept that has quickly become a central theme in the current crypto cycle. However, this concept is not new; the earliest example of restaking can be traced back to Polkadot’s Parachain system. Each Parachain can have its own specific use case, governance model, and tokens, but they all benefit from Polkadot’s shared security model, meaning they don’t need to secure their own networks. Instead, they rely on the Relay Chain for security, allowing the stake on Polkadot to secure other chains.

This concept has also been adopted by Cosmos through Interchain Security. The concept of Replicated Security involves one blockchain serving as a security provider for other blockchains. The blockchain that provides security is referred to as the Provider Chain, while the blockchains inheriting the full security and decentralization of the Provider Chain are called Consumer Chains.

More recently, the concept has been brought to Ethereum via EigenLayer, and projects like Symbiotic and Karak have also emerged, actively competing within Ethereum's ecosystem. On Cosmos and Polkadot, restaking is embedded directly within the protocol, in contrast on Ethereum, restaking is facilitated via smart contracts, creating a more open market where restaking marketplaces can operate independently. Here, the idea is to use ETH, ETH LSTs, or ERC20s to secure other networks, known as Actively Validated Services (AVS), in order to earn additional yield while accepting additional risks, such as slashing (which would come in the future). With Ethereum’s rollup-centric roadmap and the growth of Layer 2s, liquidity and dApps are increasingly shifting away from Ethereum Layer 1 to L2s. As a result, the core value proposition of Ethereum Layer 1 will become its economic security and large market capitalization. EigenLayer, along with other restaking marketplaces like Symbiotic and Karak, capitalizes on this by offering economic security to Ethereum-aligned external networks.

In this paper, we will provide an overview of the restaking market on Ethereum as it stands today, explore its business model and economics, and discuss the future of the restaking landscape and its challenges.

Part I. Overview of the Restaking Landscape
  1. An analysis of the market on Ethereum

In the Ethereum restaking space, 3 prominent platforms have emerged: EigenLayer, Symbiotic, and Karak. EigenLayer has taken the lead as the first restaking marketplace to launch on Ethereum Mainnet and continues to dominate in terms of Total Value Locked (TVL), with over 4.17 million ETH equivalent.

On June 19, 2024, EigenLayer reached its peak TVL, hitting an all-time high of 5.43 million ETH equivalent before experiencing a slight decline.

Symbiotic began accepting deposits on June 11, 2024, quickly reaching its initial deposit cap of 41,290 wstETH in just 5 hours. A second cap of 210,600 wstETH was set on July 3, 2024, and was also reached within 4 hours. The last cap was introduced on August 14, 2024, coinciding with the launch of BTC deposits. These different deposit caps are clearly visible in the graph below.

Currently, Symbiotic has approximately 644,000 ETH equivalent deposited on its platform.

Note: Symbiotic has not yet launched its mainnet, users can only deposit funds at this stage.

Karak successfully launched its mainnet on October 18, 2024, marking a significant milestone for the platform. However, the protocol has attracted slightly fewer deposits compared to both EigenLayer and Symbiotic, with around 205,000 ETH equivalent deposited.

In this competitive market, despite the emergence of new platforms, EigenLayer remains the clear leader, holding approximately 6x more TVL than Symbiotic and 20x more than Karak.

  1. Composition of the TVL
  1. EigenLayer

A significant portion of EigenLayer's TVL is driven by Liquid Restaking Protocols (LRTs). Our analysis of the major LRTs on EigenLayer shows that they currently account for approximately 75.37% of the platform's TVL, with an all-time high of 75.46% in July 2024. This indicates that more than 75% of the TVL in EigenLayer comes from users interacting with Liquid Restaking protocols rather than directly through the EigenLayer application.

The protocols included in our analysis are EtherFi, Renzo, Puffer Finance, Kelp DAO, Swell, and Bedrock.

When examining the composition of each LRT, we can see that EtherFi is the largest LRT contributor on EigenLayer, followed by Renzo and Puffer.

There are several reasons why LRTs have become the primary liquidity source for EigenLayer and restaking platforms in general:

  • They provide additional incentives on top of the restaking platforms’ incentives (or points)
  • They offer a simpler onboarding process for users
  • They issue a Liquid Restaked Token that can be used in DeFi
  • There is no lock-up period, as the LRT can be sold on the open market

  1. Symbiotic

Looking at Symbiotic, a similar pattern emerges, with approximately 61.61% of the TVL coming from Mellow vaults and EtherFi. This highlights that a large portion of liquidity is funneled through external protocols rather than directly through Symbiotic itself.

Only about 38.39% of the total TVL has been deposited directly via the native Symbiotic app.

  1. Karak

For Karak, the situation is a bit different. It appears that there is only one major LRT on Karak, which is EtherFi with around 17% of the TVL, while 83% of the Karak TVL has been deposited on the native app.

  1. Restaking movements

Let’s dive into recent movements in the restaking space. A quick look at the inflows and outflows between EigenLayer and Symbiotic suggests that large inflows into Symbiotic correspond with outflows from EigenLayer.

Based on a recent analysis from Gauntlet, covering the period from June to September 2024, approximately 1,011,000 ETH was withdrawn from EigenLayer during this time. Of this, around 170,000 ETH was moved directly to Symbiotic. However, users didn’t just transfer this amount, they added another 37,000 ETH on top, making a total of 207,000 ETH deposited into Symbiotic.

The 207,000 ETH deposited into Symbiotic accounts for about 42.20% of the 488,000 ETH locked in Symbiotic at that time, meaning that approximately 42.20% of Symbiotic's TVL came directly from withdrawals on EigenLayer.

However, it’s important to note that only 16.5% of the ETH withdrawn from EigenLayer has remained within the restaking ecosystem, while the other 83.5% has exited the market entirely for now.

EigenLayer and Symbiotic flows, Source: Gauntlet

Part II. Economics of Restaking
  1. Restaking, main actors and targeted market

Restaking is supposed to allow networks, commonly known as Actively Validated Services (AVSs) in the restaking ecosystem, to quickly bootstrap a validator set and get a certain level of economic security with minimal time investment.

In this model, platforms like EigenLayer, Symbiotic, and Karak act as marketplaces where restakers, operators, and AVS entities come together. However, their goals are not the same. Here’s a breakdown:

  • Restakers: Their goal is to maximize restaking yields by looking at the best risk-adjusted returns on their positions.
  • Operators: They manage the AVS infrastructure and accept assets from restakers. Operating an AVS incurs additional costs, which vary depending on the AVS architecture. In exchange for providing this service, operators should earn revenue from the AVS.
  • Activated Validated Services (AVS):  The AVS gets its economic security from restakers who deposit collateral and gets operational security from operators who support its infrastructure. In return, the AVS must generate yield to incentivize both operators and restakers to sustain this operational and economic security.

At this point in the market, very few AVSs have clearly defined how much economic security they need or how much they are willing to offer to attract operators and restakers.

Who is restaking meant for?

Restaking has not yet found a clear product-market fit. It isn’t particularly suited for high-value, high-FDV networks, as these networks are large enough to offer large incentives, manage their own validator sets, and provide additional utility for their native tokens (for example, staking the native token to earn a staking yield, rather than paying restakers who hold a different token). It’s difficult to imagine large networks like Monad or others using restaking.

That said, restaking seems more suitable for small to medium-sized projects that don’t yet have the resources to bootstrap a totally sovereign network. Restaking allows them to grow, mature and find product-market fit before being totally sovereign without relying on 'rent' payments to holders of other tokens. However, there are also some AVSs that use restaking for very specific purposes and are not intended to be sovereign, as they bring services and value to the underlying Layer 1.

  1. Restaking Yield and Challenges

EigenDA stands out as the first AVS to distribute yield to both restakers and operators. Currently secured by around $10 billion in economic security, it has become a significant player in the emerging restaking ecosystem. However, the economics of maintaining such a network pose several challenges and require a closer examination.

Yield Distribution and Economic Security

EigenDA currently offers 10 ETH per month in rewards to restakers and operators. With a TVL used for economic security of around $10 billion, the total annual amount distributed to operators and restakers corresponds to $300,000 assuming the price of ETH at $2,500. Assuming an economic security of $10 billion, this represents a gross APR of just 0.003%.

This low yield highlights a key challenge in the restaking model: balancing the need for economic security with adequate incentives for participants.

The Cost of Running an AVS

The cost of operating an AVS varies based on the specific infrastructure and requirements needed for it, but on average, we estimate the monthly infrastructure cost to run at around $400 per AVS. Over the course of a year, this represents approximately $4,800 for a single AVS. With 18 AVSs currently in the market, the annual cost for one operator to run all of them comes to $86,400. It’s important to note that this figure does not account for additional expenses such as the salaries of the DevOps teams required to maintain and secure the infrastructure.

EigenLayer currently has 340 operators running at least one AVS each. If an AVS wants to fully leverage the economic security provided by EigenLayer while ensuring that operators cover their infrastructure costs, the financial commitment grows significantly. The formula is simple:

• $400 per month per operator

• 340 operators

This results in a total annual infrastructure cost of $1.63 million. And that’s just for maintaining the infrastructure by 340 operators, it doesn’t include the incentives that need to be paid to restakers.

Cost for an AVS to cover infrastructure costs

EigenLayer has introduced programmatic incentives to maintain its TVL on the platform. You can track the yield from these incentives here. EigenLayer is distributing 16,736,467 EIGEN to Eigen restakers and operators over one year, and 50,209,400 EIGEN to ETH and ETH LST restakers. This not only supports the restaking economy but also helps AVSs to take the time to find ways to incentivize operators and restakers.

  1. Restaking: Inferior to Traditional Proof of Stake?

In most cases with restaking, AVSs that aren’t yet generating revenue will likely introduce a native token to incentivize restakers. This means they will use their native token to compensate ETH restakers or other ERC20 restakers. As a result, restakers who may simply prefer their rewards in ETH or a specific ERC20 token, are likely to automatically convert these AVS rewards back into their preferred tokens.

Economically, this model is fundamentally weaker than a traditional Proof of Stake system. In traditional staking, participants buy the native token, show commitment to the project, and stake to earn rewards. Since they’ve invested in the native token, they are more likely to hold onto their staking rewards longer than restakers who receive AVS rewards.

In today’s restaking market, there are also auto-compounding products that automatically convert restaking rewards into ETH to boost the restaked position, which encourages immediate selling of AVS tokens.

Part III. What to Expect for the Future of Restaking

  1. AVS Yields as a Catalyst for TVL Growth

As slashing goes live, we expect restakers to pay closer attention to the operators they select, particularly the quality of services offered. Additionally, TVL growth will likely be driven by operators’ ability to deliver the best risk-adjusted returns.

Marketplaces are expected to become more flexible, with leading AVSs establishing caps on the amount of security they require or incentivize. The evolution of TVL numbers for AVSs is likely to change as soon as the activation of slashing and yield mechanisms will encourage each AVS to set limits on the TVL they incentivize. This implies that delegations to each AVS will be limited, or yields will be diluted, as AVSs aim to avoid paying for excess security they don’t need.

The introduction of a new security model that distinguishes between "unique" and "total" stake will reshape distribution.

We anticipate different methods by which AVSs will compensate operators for providing security:

  • Protocol Token Incentives: Some AVSs may opt to reward restakers with their own native tokens through an inflationary system. This approach is risky because inflationary tokens can become diluted over time, especially compared to ETH, the base token. If the price of the AVS token declines while ETH remains stable, the AVS will need to distribute more tokens per reward epoch, increasing selling pressure or reducing the AVS yield. The advantage of this model is that it’s the easiest and cheapest way to pay restakers for an AVS.
  • ETH Payouts: The protocol keeps a portion of the fees generated, while the rest is distributed to restakers who provide security. Node operators earn a commission for running the infrastructure. This structure aligns the interests of the protocol, operators, and security providers, all of whom are rewarded in ETH for securing the AVS. The downside of this model is that fees can be low if the AVS doesn’t generate substantial revenue, or it can become costly if the AVS uses its treasury to pay out in ETH (similar to EigenDA).
  • Hybrid model: AVSs distribute fees generated from their operations, but if this is insufficient to attract the desired level of security, they may supplement these rewards with their own token. This approach could make restaking yields more appealing to both restakers and operators.

At this stage, we believe the leading node operators will benefit in two key ways:

  1. They will be best positioned to conduct thorough due diligence on emerging AVSs.
  2. They will gain access to top AVSs. Leading AVSs will probably have a permissioned set of professional Node Operators. Restakers seeking exposure to these AVSs will need to restake with professional Operators.

  1. Challenges for LRTs

This change in economic conditions could impact major Liquid Restaking Protocols. They attracted substantial liquidity thanks to their own incentives in native tokens, but they now have billions in economic security to provide to AVSs, which, on the other hand, will be difficult to incentivize given the high amount to incentivize for the AVSs. What we see is the following:

  • Challenges for Large LRTs: Larger LRT platforms may struggle to allocate their TVL efficiently while maintaining attractive restaking yields. For example, EtherFi, with $6 billion in TVL, might need to opt into more AVSs to offer yields comparable to its competitors, while simultaneously increasing exposure to a broader set of slashing conditions once that feature goes live. They will likely face pressure to further decentralize their Operator set to reduce slashing risks.
  • Increased Demand for Top Operators: As the restaking ecosystem matures, top operators are likely to be more and more important, as they will be able to offer better yield by being the favorite choice of top AVSs with capped amounts of economic security. This will shift the balance of power toward operators, as LRT platforms seek partnerships with those capable of selecting and operating top AVSs/Networks.

To be sustainable, the best LRTs must offer at least the Ethereum staking yield and compete directly with Liquid Staking Tokens (LSTs). This is why many LRT protocols accept native ETH (such as EtherFi, Renzo, Swell, etc.). Even if the restaking yield isn’t significant, users still gain exposure to an LST+ protocol, meaning they receive the benefits of liquid staking as a baseline, with potential upside if the restaking yield becomes attractive.

Conclusion

The Ethereum restaking ecosystem has unlocked new possibilities, enabling small to medium-sized projects to leverage Ethereum’s economic security. While restaking offers significant advantages, its current economic model and design face some challenges. As Ethereum restaking continues to evolve to address these issues, we can expect increased collaboration between AVSs and leading operators, fostering a stronger and more sustainable ecosystem for restakers.

About Chorus One

Chorus One is one of the largest institutional staking providers globally, operating infrastructure for over 60 Proof-of-Stake (PoS) networks, including Ethereum, Cosmos, Solana, Avalanche, Near, and others. Since 2018, we have been at the forefront of the PoS industry, offering easy-to-use, enterprise-grade staking solutions, conducting industry-leading research, and investing in innovative protocols through Chorus One Ventures. As an ISO 27001 certified provider, Chorus One also offers slashing and double-signing insurance to its institutional clients. For more information, visit chorus.one or follow us on LinkedIn, X (formerly Twitter), and Telegram.

 Join our mailing list to receive our latest updates, research reports, and industry news.

Want to be a guest?
Drop us a line!

Submit
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.