Nobody likes to think about the possibility of slashing, but it often pays to be prepared for the worst. StakeWise team would like to introduce the idea of allowing $SWISE token holders to “insure” the protocol against slashing risk by staking $SWISE in a Security Module.
When it comes to the risks associated with ETH2 staking, the risk of slashing occupies the top spot. Ever since its first testnet appearance in May 2020, the StakeWise team spent countless hours on polishing the protocol’s infrastructure setup in order to minimize slashing risk. To further protect our stakers, we have an idea to implement staking functionality for $SWISE that would allow DAO members to offer an extra protection layer against slashing risk to the protocol’s users.
Letting DAO members “insure” slashing risk through the staking of $SWISE could make the StakeWise protocol safer to use and add utility to the token. It could also offer additional revenue streams to the DAO members who stake $SWISE, and act as a deflationary force for the $SWISE supply.
This additional layer of protection could work via the following mechanism:
- Users stake $SWISE in the safety module contract
- StakeWise DAO Treasury allocates rETH2 rewards to the contract
- In the absence of slashing events, users claim rewards proportionately to their share of staked $SWISE
- In case of a slashing event, the safety module contract initiates an open market auction for staked $SWISE, aiming to compensate StakeWise users for any slashing-related losses with the proceeds from the auction
- Any $SWISE remaining in the safety module contract after the auction can be claimed by its owners proportionately to their share of staked $SWISE
There are several variables in this mechanism that require the DAO’s input:
- The amount and type of rewards to be allocated to the safety module contract
The DAO’s Treasury could allocate up to 100% of the staking fees it generates (earned in rETH2) towards this purpose. In addition, the DAO may elect to allocate $SWISE rewards from its reserve to encourage participation in the safety module.
- The duration of $SWISE withdrawal delay
Once staked in the safety module, $SWISE should not be available for immediate withdrawal to prevent users from front-running the auction and avoiding the sale of their $SWISE. Hence, the DAO must choose the minimum withdrawal delay that would prevent front-running yet be sufficiently short to maintain flexibility of staking $SWISE. A delay would be applied from the moment $SWISE staker decides to withdraw their tokens.
- Auction triggers (i.e. definition of a slashing event)
A slashing event that triggers the auction must be clearly defined in terms of % of the funds slashed. Alternatively, the DAO may elect to control the trigger manually.
- Auction parameters
Variables like the minimum bid, auction type, place of the auction etc. could be clarified in advance for the safety mechanism to function properly. Alternatively, the DAO may elect to control these parameters ad-hoc.
On top of these variables, the DAO could decide whether it would like to allocate additional voting power to the staked $SWISE tokens as means to incentivize $SWISE staking and buyers’ participation in the auction.
The news of a slashing event could propagate through the Ethereum ecosystem and impact the $SWISE price before the auction even begins, potentially reducing the effectiveness of the safety mechanism. One way to counteract this effect is to mint more $SWISE tokens to be sold in the auction, using a process similar to Maker DAO’s Flopper mechanism.
Another way would be to hold off on conducting the auction until a full post-mortem has been done and appropriate actions to fix the source of slashing have been taken. This would give the market sufficient time to digest the news and restore confidence in the protocol based on the DAO’s response to the slashing event.
This idea is one of the heaviest conceptually and requires input from as many DAO members as possible. What are your thoughts, folks?