Introduction

In recent years, a plethora of liquid staking protocols have surfaced, including notable ones like Lido, RocketPool, Frax, Swell, StakeWise, Stader and others. Naturally, each protocol comes with its own set of advantages and disadvantages. In this discussion, we'll delve into what, in my opinion, constitutes an ideal staking protocol. Of course, it's important to acknowledge that every user has distinct requirements, and I aim to address a broad spectrum of needs within this article.

Basics

In order to construct the ideal liquid staking protocol, it is essential to strike a balance among several key factors: decentralization, security, and scalability. Interestingly, this balance resembles the infamous blockchain trilemma. Let's explore additional pivotal aspects that contribute to a robust liquid staking protocol:

• Seamless DeFi composability

• User-friendly UI/UX for retail

• Implementation of forced exit (after EIP passes)

• On-chain governance with dual-token voting mechanism

• Support for both rebasing and non-rebasing tokens

• Low fees

• Inclusion of both permissionless and permissioned node operators

• Self-imposed protocol limitation at a maximum dominance of 25%

• Variable bond for permissionless stakers

Node operators

In my opinion, the most effective approach to constructing a secure, decentralized, and scalable liquid staking protocol is through the utilization of a hybrid model, similar to Lido's Staking Router. This model enables the protocol to efficiently handle substantial deposits by employing a permissioned validator set, eliminating the need to rely solely on permissionless node operators to set up validators. As time progresses, the protocol can gradually transition the stake from permissioned validators to permissionless solo stakers, promoting greater decentralization and enhancing security measures. This hybrid approach ensures a balanced and adaptable system that combines the benefits of both permissioned and permissionless mechanisms.

Permissioned

The selection of node operators for this specific set is carried out by the DAO, which will be further detailed in the governance section. One noteworthy aspect is that these operators are not required to provide any collateral to initiate the validation process, as their selection is primarily reputation-based. Moreover, validators who demonstrate superior performance may receive additional stake assigned to them. It is crucial for the node operators to be geographically dispersed and diversify their clients to ensure robustness and resilience of the Ethereum network. Additionally, since these operators do not necessitate bonding like permissionless stakers, they would receive a smaller portion of the total fees generated by the protocol.

Permissionless

The protocol would employ these longer-term stakers as validators, with the expectation that they would not undergo constant rotation. Unlike permissioned stakers, these validators cannot be blindly trusted, necessitating the posting of a bond in ETH to validate. The minimum bond amount is subject to debate, but in my opinion, 4 ETH should sufficiently cover any potential tail risks. It would also be beneficial to allow validators to choose a variable bond ranging from 4-16 ETH, providing more flexibility compared to the current solutions. The commission collected on the assigned ETH to these validators could be depend on the performance of the node operators. This way, the protocol can penalize underperforming operators while increasing the yield for LST holders. To ensure a fair distribution of execution layer rewards such as MEV/tips, they would be collected into a pool and distributed equally, eliminating any element of luck. Node operators engaging in MEV theft would face significant penalties corresponding to the amount they stole. Moreover, it would be advantageous for node operators to receive their yield in the form of LST, allowing for compounding and reinvestment of their rewards.

Exit mechanism

I have written a comprehensive article addressing the challenges associated with handling withdrawal requests in a permissionless system. You can find the article here. In essence, unlike permissioned operators, it is not feasible to simply remove permissionless node operators from the validator set, as they have invested significant time and resources into setting up their validators. I proposed a solution focused on incentivizing validators to voluntarily exit, but members of RocketPool raised concerns about potential gaming of this system. As there is currently no superior solution, utilizing market dynamics to incentivize exiting validators remains the best option. However, it is crucial to integrate forced exit as a last resort to provide LST holders with peace of mind, ensuring they can recover their funds if necessary. Additionally, it is advisable to separate the role of arbitraging from validators. Node software should include a parameter that allows setting a specific profit threshold, triggering automatic exit and arbitrage execution.

Governance

It is crucial for a liquid staking solution to possess a resilient governance system to handle potential attacks. Moreover, governance should always happen on-chain, involving a diverse array of voters.

Security and multisigs

Numerous protocols have faced criticism due to their inadequate security measures regarding protocol upgrades. Despite this, many protocols still employ some form of multisig for their upgrades and treasury functions. While this approach can benefit the protocol by enabling multisig members to swiftly intervene in case of protocol issues, it also exposes them to potential attacks. In my opinion, merging on-chain governance with multisigs offers the best risk/reward balance. Although the multisig lacks the authority to directly upgrade the contracts, it can temporarily pause them until governance takes over. This pause can only be initiated once by the multisig, and subsequent usage requires permission from the governance system. An example of such a mechanism is Lido's GateSeal, which acts as a one-time panic button.

Dual token governance

The governance token holders should always serve as the primary decision-makers within the protocol. However, it is important to avoid concentrating all power in their hands. Dual governance addresses this concern by granting the LST holders the ability to veto any decision made by the governance token holders. This concept was initially introduced by Lido and is currently in the planning phase.

Tokenomics

Designing a governance token can be approached in various ways, but recently, the vote escrow model has gained popularity among several new protocols. Without delving into the exact details of the ve(3,3) design, it can be summarised that the amount of rewards and voting power one receives is contingent upon the duration for which governance tokens are locked. In this model, the longer the tokens are locked, the greater the rewards and voting power allocated to the holder. This mechanism incentives token holders to commit their tokens for extended periods, thereby promoting long-term engagement and participation in the governance process. This model also allows the protocol to utilize a portion of the token supply to incentivise stakers and liquidity providers, all while maintaining control over emissions.

Profit sharing

In the early stages of the protocol, profit sharing can be disabled to allow the DAO to bootstrap some funds for expansion. Once the protocol matures, profit sharing can be enabled and the rewards that stakers receive will depend on the duration of the locking period. Any excess rewards can be pocketed by the DAO for future expansion.

Conclusion

Making a liquid staking protocol is not easy, and I'm sure that there will be no one protocol that will tick all of the boxes. In my opinion, the closest protocol to what I described is Stader. They tick most of the boxes, but they still have some things to improve on, such as multisigs/security. It's okay if one protocol focuses on decentralization, even if it charges higher fees and has lower capital efficiency. However, no matter what, no protocol should consume too much of the ETH staked.