Last week, the Ethereum community learned about a high-profile incident involving a loss of users’ funds by one of the ETH2 staking providers. At least 38,000 ETH have been lost due to the negligent handling of withdrawal keys, once again highlighting the complexity of staking on Ethereum and exposing the security flaws otherwise ignored in the pursuit of growth.
These events throw the key management practices of surviving ETH2 staking operators into the spotlight and invite scrutiny of the solutions they employ to secure users’ capital. As the only non-custodial ETH2 staking pool, StakeWise feels compelled to assure its users of the safety of their funds and share the steps it takes to fully mitigate the risk of similar incidents. Below we explore how StakeWise uses the BLS Horcrux, smart contract withdrawals, and SafeSnap + DAO multisig to maximise the safety of the funds staked with the protocol.
The BLS Horcrux
From its mainnet release in February until April 19th, StakeWise has relied on a tool called the BLS Horcrux to avoid having custody of the users’ funds. The BLS Horcrux is a tool for distributed and trustless withdrawal key generation that was developed and open-sourced by Dmitri Tsumak, the core developer behind StakeWise.
The Horcrux leverages BLS key properties to generate the withdrawal key and split it into m parts without ever revealing the full key to anyone. The generation ceremony is held offline and usage of the key always requires a minimum threshold of signatures to be achieved. Each party to the Horcrux arrangement is then independently responsible for securing their key part.
Here is the comparison between the key management practices that use the BLS Horcrux and those reportedly employed in the incident:
- StakeWise has seven key parts split between seven independent parties. It adheres to the Byzantine Fault Tolerance (BFT) mechanism, which prescribes choosing m parts based on the tolerated number of failures n, where m = 3n +1, to maximize the chance of reaching consensus despite failed signatures (e.g. loss of key parts).
This is in contrast to only four keys split between just two entities involved in the incident. It seems that while these entities intended to adhere to the BFT mechanism when choosing m=4 based on n=1, by splitting four keys between just two parties they effectively chose the 2/2 threshold and set n=0, greatly increasing the risk of failure.
- At StakeWise, the responsibility for holding the keys is clearly assigned to the individual holders, who are experienced with the private key management routines and are aware of the consequences of losing them.
In contrast, the areas of responsibility for holding the withdrawal keys seem to have been defined poorly between the entities involved in the incident, leading to the loss of clients’ funds.
- StakeWise conducts monthly drills for the parties involved in the BLS Horcrux multisig, ensuring that the keys are accessible and secured, and minimising reaction time in adverse scenarios.
In contrast, there is no information whether the entities involved in the incident have ever performed any drills prior to the discovery of the incident, potentially increasing the amount of damage to customers’ funds due to the late discovery.
To conclude, for the validators it handles using the BLS Horcrux multisig, StakeWise has more key part holders, appropriate choices of m and n, dedicated persons responsible for securing each part, and monthly drills to monitor their security status. To date, all 7 key parts continue to be securely stored by their respective holders and remain accessible, and all the drills have been completed successfully.
You can read more about the BLS Horcrux tool and learn about the holders in our documentation.
Withdrawal to a smart contract
On April 18th, StakeWise was the first in the industry to adopt a smart contract as the destination address for validator withdrawals. Instead of utilising the BLS Horcrux multisig to assign a destination address for the withdrawal of validators’ funds (the only point of custody), new validators are created with a pre-defined destination address that is the smart contract StakeWise calls Pool Escrow.
In contrast to the key sharding processes that split the withdrawal (private) key between several parties, StakeWise is no longer required to hold the withdrawal private key at all or determine the destination address for the withdrawals with the BLS Horcrux multisig. This makes the StakeWise Pool the only non-custodial option for liquid Ethereum staking in DeFi.
Pool Escrow contract is very slim and its sole purpose is to store the funds for the withdrawal. The DAO multisig controls the Pool Escrow contract until it can pass the access to the contract that allows the burning of rETH2 & sETH2 tokens and withdrawal of ETH from the StakeWise Pool. Such a contract is currently impossible to write since ETH2 validator withdrawals have not yet been specced out.
The access from Pool Escrow to such a contract can only be assigned by the $SWISE token holders through the Snapshot voting and SafeSnap transaction execution. While our token is relatively young and will be distributed to the community members over time, we have a DAO multisig committee that has the capacity to override the token holders’ vote in case some third-party contract is maliciously assigned and voted on by the $SWISE holders.
StakeWise’s adherence to these withdrawal procedures can be verified on-chain by confirming the destination address used by the new validators, examining the parameters of our SafeSnap module, and looking up the addresses included in the StakeWise DAO multisig.
Conclusion
We sincerely hope that the affected operator will succeed in recovering the deleted key backup and sympathize with the teams and customers whose funds were affected by the incident. However, we also feel it is necessary to highlight the differences in our approach to security.
StakeWise proudly remains the only liquid Ethereum staking protocol to commit to non-custodial staking and maximise the safety of its users’ funds by employing a proprietary BLS Horcrux tool, following strict key management practices, assigning withdrawals to a smart contract, and creating a DAO multisig to act as a backstop against malicious behaviour. We will continue heightening our security standards and pushing the boundaries of what’s possible in ETH2.
Follow us on Twitter to learn more, and do not hesitate to ask us questions on Discord and Telegram.
