Lido for Avalanche – Joint Proposal by Hyperelliptic Labs and RockX

Hello everyone! We’re Hyperelliptic Labs and RockX, and to continue the monumental success of the LEGO Initiative, we propose an expansion of the family of Lido liquid staking protocols into Avalanche. We welcome you to read our joint proposal and give feedback over the next few days, and then vote on it at Snapshot.

About Avalanche

Avalanche is a proof-of-stake blockchain, whose aim is to be the fastest “L1” smart contract platform, with the ability to process thousands of transactions per second (TPS), at low cost. Avalanche intends to scale horizontally through the creation of independent blockchains running on dedicated subnets. Avalanche’s TVL currently stands at around $12B, making it a top-4 DeFi chain.

Staked AVAX (Avalanche’s native token) is illiquid until unstaked. Avalanche requires a minimum staking period of two weeks, and a minimum stake of 25 AVAX if delegating, or 2,000 AVAX for a validator (at current prices around $200k USD).

The staking yield for two weeks’ tenure is very low. Hence our solution of liquid staking can allow customers to stake for longer tenure with higher yield, and without sacrificing the liquidity (a one year tenure is similar to the status quo of ETH2 with double digit yield).

Avalanche is thus an ideal candidate for liquid staking: users get liquidity while staking to take advantage of DeFi opportunities on the Avalanche chain, and are no longer forced to trade off staking periods with opportunity cost. The high TVL makes the revenue opportunity for Lido extremely high.

High-Level Technical Overview

Avalanche’s multi-chain architecture presents interesting challenges to any team wishing to bring Lido to the platform. It is made up of three distinct blockchains: the Exchange Chain (X-Chain), the Platform Chain (P-Chain), and the Contract Chain (C-Chain).

Limitations of Current Avalanche Technology

Smart contracts are executed on the C-Chain, however staking is performed on the P-Chain, which cannot run custom smart contract code.

Because Avalanche does not yet enable smart contracts to transfer AVAX between chains or to perform staking on the P-Chain, it is not currently possible for a smart contract to move tokens between these chains, meaning that some amount of the process must be custodial to begin with.

We propose a two-stage roadmap, combining the best of what is possible today, with a path to improvements in automation and trust minimisation as Avalanche grows. Both stages assume the creation of an Avalanche C-Chain token (stAVAX), representing staked versions of AVAX. At all stages, code will be open sourced and shared with the community.

Interim Solution: Semi-Custodial Liquid Staking

As with Lido stETH, tokens will accrue rewards as a function of time, removing the need for users to sacrifice liquidity or meet minimum staking value requirements to be able to participate in Avalanche’s growing DeFi ecosystem. Additionally, governance over selected validators, fees, other parameters, and matters such as upgrades to the protocol will be carried out by LDO holders.

In the initial version, the subset of operations which cannot yet be managed by smart contracts (such as cross-chain transfers and staking) will be carried out via operations requiring multi-party approval. These approaches will then be phased out as the Avalanche blockchain matures.

Long-Term Solution: Trustless Liquid Staking

The next update to Avalanche (Blueberry) intends to improve cross-chain transfer functionality, with work commencing in Q4 2021. We intend to work closely with Ava Labs to build on this and help add functionality to enable automated cross-chain staking with minimized trust.

This will require a number of improvements to Avalanche to better support cross chain messaging and querying, interchain accounts, remote transfers, and ultimately staking from contracts on the C-Chain.

Timeline estimates

Preliminary work:

  • Research and development (October-January 2021)
  • Initial tech spec (January 2021-February 2022)

Phase 1: semi-custodial liquid staking

  • Development: includes custom MPC solution (January-May 2022)
  • Fuji testnet deployment and audit (April-May 2022)
  • Mainnet deployment (June 2022)

Phase 2: trustless liquid staking

  • Avalanche protocol development
  • Trustless staking development
  • Fuji testnet deployment and audit
  • Mainnet deployment


  • Migration of v1 users / custodied funds to v2; maintenance, upgrades and support for v2 and planning for further iterations

Competitive Landscape

Multiple companies have signaled their intention to build liquid staking for Avalanche. These include:

  • BENQI, a newcomer to the DeFi scene who currently offer borrowing and lending capabilities similar to Compound.
  • Ankr, an established blockchain infrastructure company who aim to offer products, such as staking, on multiple chains.
  • Lavax, which appears to be an effort by independent developers, but with little detail on architecture or timelines.

Of these, only Ankr appears to have already launched their liquid staking solution, albeit with little apparent market liquidity.

Despite not being the first to market with liquid staking on Avalanche, Lido has many advantages over potential competitors, including being a trusted, well-known name in DeFi. If Lido were to bring their liquid staking product to Avalanche, they could potentially capture a share of the market on brand name alone. However, that isn’t the endgame.

All companies building liquid staking solutions on Avalanche right now face the same challenges regarding custodianship and trustlessness; none have been open about the architecture of their solutions; and many may feel that their current product is good enough to continue with in the future.

We are certain that Lido entering the market as an established competitor, with its characteristic transparency on current solutions and signaling intention to work towards a better solution with the Avalanche team, will help capture a majority of market share.


We believe in the long term success and value proposition of Lido, and are therefore eager to propose a two-part incentive structure that shows our commitment both to this project and to the alignment of our respective interests.

This proposal contains a significant amount of development work, including an interim MPC solution, which contributes to the Lido codebase as a general purpose secure custodial solution, as well as protocol-level development to enhance the cross chain communication on Avalanche.

In this particular implementation for Avalanche, we will tackle the full complexity of the threshold ECDSA, which is more difficult than other setups such as BLS. We foresee a lot of learning and development from this proposal can be applied to other blockchains in the future since these are common challenges for a secure liquid staking solution.

We have modelled our proposal somewhat on Shard Labs’ (Polygon) proposal, whose grants were 1M LDO (LDO was trading between $3 and $7 USD during this period).

First, we would propose incentives of LDO tokens with the following terms:

  • The initial grant is issued immediately. Subsequent grants are issued when Lido for Avalanche captures % market share, based on the table below.
  • A grant given on the basis of delivering Phase 2 of the proposal, which represents a significant amount of potentially uncompensated work on the Avalanche protocol in tandem with the Ava Labs team.

We strongly believe this latter phase will benefit Lido, due to the optics of giving back to the Avalanche developer community and improving the protocol (i.e. supporting trustless inter-chain movements) for all teams working in Avalanche DeFi.

Milestone LDO
Initial grant, covering delivery of Phase 1 350,000
1% market share 200,000
2% 200,000
3% 200,000
4% 200,000
5% 200,000
10% 500,000
Delivery of Phase 2 150,000
Total 2,000,000 LDO

We define “market share” as the ratio between the amount of staked AVAX tokens via Lido vs. that of all staked AVAX tokens (currently around 60% of supply), based on Avalanche’s Validator Stats page. To qualify, the given market share must be held on average across at least 30 days, to account for variability in the data.

In addition, we propose that audit during the initial grant phase be compensated separately by Lido, and that the Hyperelliptic Labs x RockX team receive 20% of the ongoing Lido treasury fees from this solution, in order to align both parties’ incentives.

An ongoing revenue share plays many roles, including rewarding the team for the success of the project, and in order to cover the costs of ongoing maintenance, improvements, and integrations, both of the solution itself, and of a secure MPC key management system.

Project Team

The project will be jointly carried out by the Hyperelliptic and RockX teams, both of whom will bring their respective strengths to bear on this project.

RockX is an institutional staking service provider, which has been a node operator of stETH and stSOL under Lido. Besides offering institutional staking services and stable access nodes. The team has a research arm X-matrix labs, which specializes in improving defi protocols and developing MPC key management (including DKG, resharing and signing)

The Hyperelliptic Labs team specializes in infrastructure, security and cryptographic key management. The team comes from both crypto and tradfi backgrounds, having built products used by millions of people around the world.

We are in close contact with both core Avalanche and Lido development teams, and look forward to collaborating with them to deliver this solution.


I’ve talked a lot to both Hyperelliptic and RockX and I’m impressed with the technical prowess and business acumen of both teams. I think we should seriously consider the proposal.


Gald to hear Hyperelliptic and RockX and more teams joining LIDO ecosystem.

There is a question to LIDO DAO.

  1. LEGO encourages more teams to build staking solutions on different chains. Who will be the code owner? LIDO DAO?
1 Like

Owner in what sense? Per proposal, the code will be open sourced; IP for the code will be owned by respective teams; deployment will have Lido governance on it; maintenance will be done by the respective teams.

1 Like

Hello all,

This is Zhuling from RockX ( We welcome any feedback to the proposal and are excited about the opportunity to bring liquid staking on Avalanche to the Lido community! In the coming months together with Hyperelliptic Labs, we will be elaborating more on the design considerations and technical details of the proposal in this thread!


I’m very excited to see a liquid staking solution being proposed for Avalanche. With the current limitations of the P-Chain, I believe that the two-phased approach makes sense. Lido should move now before other parties saturate the market with their own products.


Great proposal and excited to support such strong teams tackle this important ecosystem!

Overall the proposal structure with LDO paid for code delivery and additional incentives for hitting market share milestones are great and amounts are - given the work involved (from experience) -more than fair.


The expansion has been voted “for” on snapshot:

1 Like

Confirming our combined Hyperelliptic + RockX multisig wallet address: 0x3A043ce95876683768D3D3FB80057be2ee3f2814


Confirming our combined Hyperelliptic + RockX multisig wallet address: 0x3A043ce95876683768D3D3FB80057be2ee3f2814


We are including the initial grant payout for today’s omnibus voting (Send 350,000 LDO to the provided multisig address 0x3A043ce95876683768D3D3FB80057be2ee3f2814), stay tuned.

P.S. Also got multisig announcements in Twitter:


Initial grant for 350,000 LDO has been transferred from Lido DAO to the provided multisig 0x3A043ce95876683768D3D3FB80057be2ee3f2814 with the following transaction:


hi @J_Hyperelliptic. Any progress update? thx

Hi @satBalwyn!

Yes, happy to give a progress update :blush:

We’re in a great place, with most of the components of the protocol built: the contracts; the oracle service which transmits data about P-chain validators to the C-chain contracts; the frontend and the Subgraph. The MPC component – which is a necessity due to the current inability for trustless cross-chain transactions between the C-chain and P-chain – is well under way, though taking longer than we had anticipated. But it’s something we definitely don’t want to rush, and it’s something we want to test in full on Fuji since it’s such a critical piece of the design.

We also had a meeting with the Lido team recently to discuss the protocol design as it was once we had actually implemented it, and they gave us some food for thought, particularly around the idea of having permissionless validator onboarding instead of a pre-approved list. We are currently exploring how this might work, what changes we’d need to make to our design, etc. and considering whether it’s feasible to include in phase 1 or if it should be moved to phase 2.

We’ve delayed the Fuji launch until the end of July for these reasons, and of course this means the mainnet launch will also be delayed.

With a large part of the development work out of the way, we’ve turned to ensuring all the other moving parts required for a smooth launch are covered, including biz dev and audits. This week we’ve booked an audit for mid-July, so anticipate that the contracts will have been audited by the time they are deployed to testnet. We’re also in touch with a few firms about booking a more in-depth cryptographic audit for the MPC component once the code is ready so all parts of the protocol are fully covered before we hit mainnet.

tl;dr, as we’ve heard fellow devs say many times: we’ve done the first 90%, just the last 90% to go.

Despite the bear market, we’re still focused on delivering the best protocol possible and consider ourselves extremely lucky to be able to be heads down building alongside the amazing Lido team. We’re excited for y’all to see what we’ve built soon!


Hello, any updates to this ?

Hi @Amit_Shah

Yes, lots of updates to share! Thanks for your question.

With a great deal of support from the excellent Lido team, we’ve made changes to a number of areas compared with the original protocol design. We’ve broken these down below since there are so many areas to cover!

Protocol Design

The original design called for a rebasing token, but after some debate we have chosen a non-rebasing token structure (stAVAX), meaning the token we issue represents your share of the total AVAX pool deposited with Lido. All AVAX deposits accrue staking rewards, increasing the value of your stAVAX against AVAX.

This makes the mechanics of the protocol, especially redemption and unstaking, simpler to implement, and makes it easier to integrate with DeFi protocols. The market has taken to liquid staking tokens being value accruing, keeping with the standards lowers the learning curve and increases the ease of use.


We’ve also done a lot of work towards contract governance since our last update. There will be predefined roles and addresses which are assigned to roles such as upgrading of contracts, updating of oracles, and updating of state variables (such as the minimum amount of AVAX a user is able to stake).

For greater security, we envision having many roles with granular focus on what they are able to control to mitigate any damage should any of these roles get compromised.

Permissionless Validator Onboarding

Promoting more validators in the whole Avalanche ecosystem and pursuing a permissionless on-boarding strategy is the key design consideration. We have decided on keeping on-boarding of validators as fair as possible, and hence, will be developing a permissionless system for our protocol.

All validators will be onboarded as long as they meet a base line of criteria, which includes performance (uptime), sufficient room for delegation based on self stake and total stake, and a reasonable rate of commission.

At the same time, this design does not introduce any risks or performance compromise to staker’s AVAX: the Avalanche does not have the concept of slashing, hence a permissionless validator set does not lead to higher chance of slashing. Full staking yield is rewarded to stakers as long as validators have a reasonable rate of uptime.

Staking Mechanism

The current design aims to generate constant and attractive yield by periodically staking available AVAX onto onboarded validators. To ensure a predictable unstaking waiting period, AVAX will be staked for the minimum period of 14 days, resulting in a maximum withdrawal time also of 14 days.

However, we have run some modeling and believe that by continually rotating the stake, we can reduce the median time to a few days under normal conditions, whilst maintaining the maximum upper bound of 14 days in the worst case.

Partial Claims

To improve liquidity even further, we intend to allow partial claiming of unstake requests. For example, if a user wishes to unstake 1m stAVAX, they are likely to need to wait a longer time for the request to be filled. If, after 7 days, 500k is filled, we can allow them to withdraw 500k and wait for the remaining half to be filled.

Making a partial claim does not reset your queue time, as it is simply withdrawing funds already allocated to you. Users can have multiple unstake requests, but cannot modify existing ones. This prevents users from being able to front-run liquidity arriving in the contract. Subsequent requests join the back of the queue as normal.

Audit Progress

Contracts have now been audited by both the Lido team and Dedaub, our external auditors. Some of the larger concerns warranted deeper discussion and eventually were overhauled to refine the protocol. As such, we are in the process of submitting the code back to Dedaub for a second round of review and expect to receive their final report within 1-2 weeks.

Key findings from the first round of audits included:

  1. Timelocks: we introduced a minimum wait time for unstake requests to be claimed (a “timelock”). This gives us a knob to twiddle to dissuade arbitrageurs trying to stake/unstake quickly (there are other reasons that that might not be feasible but this helps), and helps to delay withdrawals and gives room to pause in times of crisis.
  2. Gas starvation: we introduced changes to how unstake requests are filled. Previously, this occurred during deposit. However, this approach caused two negative outcomes: firstly, that gas starvation is possible when fulfilling unstakes (changes were made to bound this); and secondly, that this pushed gas costs onto the user. Instead, responsibility for triggering unstakes will be handed to an external service.
  3. Balance manipulation: we introduced tracking of buffered vs. unbuffered balances, to ensure calculations only happen across directly deposited funds. Deposit via transfer is disallowed, and explicit tracking prevents counting forced transfers via self-destruct.

As a result there have been a few relatively large changes to the structure and functionality of the contracts and protocol.

Multi-Party Computation (“MPC”)

Our MPC backend consists of:

  1. A server for handling all signing requests and running the Threshold Signing Scheme protocol along with all participating peers;
  2. A controller for interacting with the avalanche network and sending signing requests to the server.

The functionality of the server is complete and undergoing testing. The controller consists of an underlying framework for supporting the definition and execution of workflows on top of it and various types of tasks such as moving tokens from C-chain to P-chain and staking on P-chain, moving rewards from P-chain back to C-chain, etc.

This framework has been completed, and we are now working to complete all the required implementation tasks alongside rigorous testing of each of the components.

As you can see, we’re well on the road to a completed protocol, and are excited to deliver it. We’re extremely grateful for the time and support given by the Lido team, and extremely impressed by their incredible level of knowledge and expertise both in audit and robust technical discussions.