Lido for Solana — Project Roadmap

Lido for Solana Mainnet will launch soon. Here’s what we have been up to!

Rishi Sidhu
Aug 6 · 8 min read

Roadmap

Background

Lido, the largest liquid staking project on Eth2 and Terra, is looking to expand its offering to the high-performance blockchain Solana. Chorus One is building this service for Lido. 3 months ago we submitted the proposal to build Lido for Solana. The proposal received support from an overwhelming majority of LDO holders.

Over the last 3 months, we have made rapid progress behind the scenes. This is the story of our journey in building the liquid staking solution for the fastest blockchain in the world

‘Lido for Solana’ is a Lido-DAO governed liquid staking protocol for the Solana blockchain. Anyone who stakes their SOL tokens with Lido will be issued an on-chain representation of their SOL staking position with Lido validators, called stSOL. This will allow Solana token holders to get liquidity on their staked assets which can then be traded, or further utilized as collateral in DeFi products

Proposal

On the 30th of April, 2021, Chorus One submitted a development proposal to the Lido DAO as a snapshot vote. The proposal was to build a Lido-operated liquid staking protocol for the Solana blockchain

The proposal was put to vote on the 6th of May and every LDO holder was invited to participate. The proposal received overwhelming support. 79 LDO holders holding 96.85m LDO voted exclusively in favor of the proposal.

Design

The proposed design is centered around a liquid staking token, called stSOL, that will accrue staking rewards and represent staking positions with Lido validators on Solana.

The stake deposited to the Lido contract on Solana will be distributed to these validators following a logic similar to the Lido Ethereum liquid staking solution. Lido on Solana will have a fee mechanism similar to that on Ethereum which allows splitting of fees between node operators and the Lido treasury (e.g. to be used for the insurance fund). Lido node operators, as well as parameters such as the fee, will be controlled via the governance of LDO holders on Ethereum. Additionally, in the initial version, governance decisions will be carried out via a Multisig controlled by Lido stakeholders on Solana.

Lido for Solana Development

We started building Lido for Solana in April 2021. Towards the end of June, we made the codebase audit-ready and we got it audited by Bramah Systems. We have now made the source code public for the whole world to review. In line with the design, we are performing a Multisig ceremony with 7 participants on the Solana testnet. Soon we will be announcing a bug bounty on Lido for Solana.

The Lido Program

Lido’s first design was inspired by the Stake Pool program in the Solana Program Library (SPL). In fact, our first version wrapped over the SPL stake pool. However, over time we swapped out the Stake Pool program for a different approach. The end result is a Lido program — similar to the Stake Pool program — but with key differences.

  1. In the Solana stake pool program, the stake pool owner can distribute the stake either manually or algorithmically. In certain cases, a manual distribution might require manual rebalancing when there is a change in stake. However, the Lido program always does this balancing algorithmically, eliminating the need for manual rebalancing.
  2. The SPL stake pool has no restrictions on the validators and the validators receive their commission directly through the normal commission mechanism. The Lido program uses 100% commission vote accounts, so all rewards first go to Lido, and then the fee is distributed to validators. This ensures consistent rewards for all validators in the form of stSOL

#2 — By doing so all validators get the same fee percentage, which may be lower than that of the node they operate publicly, and by making it 100% commission, we encourage delegations to Lido.

Audit

After extensive in-house testing, we commissioned an audit from Bramah Systems. We addressed all issues identified during the audit and re-enforced the security of the Solana program. However, in order to hold Lido to the highest security standards, we are looking for an additional audit.
In a nutshell, the audit covered the following aspects

  • The possibility of an attacker stealing or freezing tokens.
  • Whether the Rust code matches the specifications
  • Possibility of interfering with the contract mechanisms.
  • The trustworthiness of the arithmetic calculations.

Publishing the Source Code

In order to trust any program with your funds, two things need to be true:

  1. You need to trust the source code, and
  2. You need to be sure that the program was actually built from that source code.

A prerequisite for these is having access to the source code. Therefore, we have made our codebase public for everyone to view. Anyone can visit the Lido for Solana repository, where we have published the source code under the GPL V3 license — https://github.com/ChorusOne/solido

The documentation for the project can be found here.

Bug Bounty

To make our project even more robust, we are going to announce a bug bounty for developers to test the project for exploits.

We will be announcing the exact scope, prioritized vulnerabilities, and rewards categorized by threat level on our web page and on Twitter in the coming weeks.

Multisig Ceremony

We decided on using multisig governance for the Lido program. Before we get to the details of our Multisig program, let us see why we need it in the first place.

Programs on Solana can be upgraded unless upgrades are explicitly disabled, and this gives the upgrade authority (the address that can sign upgrades) a lot of power. After all, it could upload a new version of the Lido program that withdraws all Lido funds into some address and runs away with the funds. On the other hand, if we don’t allow the program to be upgraded at all, and then if it turns out to contain a critical bug, we can’t fix it. A multisig is a good middle ground, where no single entity can take control over the programs and their funds, but we can still enable upgrades.

Multisig Programs/addresses require multiple signatures to approve a transaction. These are smart contracts that enable multiple signers to review an action on the blockchain before it is executed. This allows for decentralized governance. Chorus One used the Serum Multisig program to introduce decentralization in Lido for Solana. This multisig has N=7 participants and requires at least M=4 of them to sign for a transaction to be approved.

The complete multisig ceremony will be covered in a later post dedicated to just that.

It is important to note that the role of the multisig is not to make independent decisions regarding Lido for Solana, but only to execute decisions made by the Lido DAO. The 7 parties that comprise the multisig are

  1. Staking Facilities
  2. Figment
  3. Chorus One
  4. ChainLayer
  5. P2P
  6. Saber
  7. Mercurial

Validator Selection

Node operators are crucial to the success of this project. Evaluating and onboarding a responsible node operator is an important step. Shortly after the Lido DAO was initiated, the Lido Node Operator Subgovernance Group (LNOSG) was formed. This group was tasked to onboard and represent node operators in the DAO structure.

With the announcement of a proposal for Lido for Solana, we also announced the onboarding of operators for it. Any node operator that wants to apply could do so by filling up a form.

Ecosystem Integrations

The frontend for interacting with Lido for Solana (currently pointing to Devnet) is here. We have integrated 5 Solana wallets with the frontend — Phantom, Solflare, Ledger, Solong, and Sollet.

Apart from that, we are exploring integrations with the following DeFi applications to utilize stSOL’s liquidity.

  • Saber Stableswap — is a decentralized exchange. It is a cross-chain stablecoin and wrapped assets exchange on Solana
  • Serum — Serum is a permissionless decentralized exchange (DEX) built on Solana that brings unprecedented speed and low transaction costs to decentralized finance.
  • Raydium — is an automated market maker (AMM) built on the Solana blockchain which leverages the central order book of the Serum decentralized exchange (DEX) to enable lightning-fast trades, shared liquidity, and new features for earning yield.
  • Mercurial Finance — Mercurial is building new liquidity systems to maximize the utility and yield of stable assets on Solana.
  • FTX Pay — FTX Pay allows users without any SOL tokens to quickly purchase SOL from within the Lido widget. We have integrated it into our application and anyone with a Solana wallet can quickly fund it using FTX.

Any projects that want to reach out for integration can do so by sending us an email at support@chorus.one

Path Forward

Going ahead we are looking for another audit of our code. That coupled with the results of bug bounty will put us on the path to the mainnet launch. Stay tuned for the latest announcements at https://twitter.com/ChorusOne

Disclaimer

Our content is intended to be used and must be used for educational purposes only. It is not intended as legal, financial or investment advice and should not be construed or relied on as such. The information is general in nature and has not taken into account your personal financial position or objectives. Before making any commitment of financial nature you should seek advice from a qualified and registered financial or investment adviser. Chorus One does not recommend that any cryptocurrency should be bought, sold, or held by you. Any reference to past or potential performance is not, and should not be construed as, a recommendation or as a guarantee of any specific outcome or profit. Always remember to do your own research.

About Chorus One

Chorus One is offering staking services and building protocols and tools to advance the Proof-of-Stake ecosystem.

Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Telegram: https://t.me/chorusone
Newsletter: https://substack.chorusone.com

Chorus One

We offer staking and interoperability solutions for over 20 decentralized networks.