Back to the roots: Utilising $SWISE for Insurance in StakeWise V3

[kiriyha]

StakeWise DAO has looked at many different $SWISE tokenomics proposals in the past 2 years, but never has the opportunity to make a dramatically positive change felt more tangible than today.

With StakeWise V3 migration on the horizon, we’ve prepared a tokenomics proposal that, in our opinion, ties up the loose ends that stopped some of the previous proposals from going through, and helps StakeWise V3 become a more robust product.

The TL:DR is that we propose to allow $SWISE holders to stake their tokens as collateral for various Vaults in exchange for a share of protocol revenue. In our opinion, StakeWise V3 significantly reduces the risk that a slashing event(s) experienced by one or more node operators will have a negative effect on the $SWISE price, making it suitable for use as an insurance asset.

Our goal with this change in the tokenomics is to bring additional safety to StakeWise V3, prompting more deposits into Vaults of all kind, and generating more rewards for insurers over time, kickstarting the flywheel. However, the proposed change is not meant to be definitive - we invite everyone to weigh in and build a strong model from the ground up.

Let’s examine the mechanism in more detail.

Fundamentals

The key innovation of StakeWise V3 is the creation of a staking marketplace that is united by a composable token, osETH. With Vaults expected to carry different perceived slashing risks, stakers are likely to flock to the Vaults that exhibit the most safety qualities & marketing prowess. For example, they could be Vaults run by established staking companies that have the resources and reputation necessary to buy slashing cover, market the Vault to their user base, and grow large enough to establish a network effect.

We’ve seen this story play out before and believe that the StakeWise DAO should limit the extent to which trust (or lack thereof) gives rise to a centralising dynamic in StakeWise V3. We expect solo stakers, who are more than capable of running validators to an enterprise-grade standard, to open Vaults too, and would like to see them receive delegations. The more delegations solo stakers can reach, the greater benefits Ethereum (and stakers) will experience.

With trust the key barrier to receiving delegations, one solution used by DeFi protocols is to require a bond to be posted by solo operators before accepting deposits. We agree with the bonding solution but find that it is not scalable enough. Hence, we see the need for the bond to be placed by external parties. But how should they be compensated, and how much bond should they provide?

As with the open marketplace approach, we believe that the invisible hand should determine both the size of the bond and the premium for it. Pair this with the thirst for a “real yield” narrative and more utility for $SWISE, and we could be onto a winner.

Proposed Mechanics

What we are proposing is to allow $SWISE holders to provide bonds to the Vaults of their liking, in form of $SWISE. This means that if the Vault is slashed, the $SWISE provided as a bond would go towards compensating the minters of osETH who incurred losses, capped by the Ether value of the loss.

In return, StakeWise DAO would distribute the ETH revenue it accumulates from letting users mint osETH to those who bonded $SWISE. However, there is a caveat - the total value of rewards that can be earned by $SWISE bonders within a particular Vault is capped by the share of osETH that was minted from any given Vault.

For example, if a Vault represents 10% of the total amount of osETH minted in StakeWise V3, then the $SWISE bonders in that Vault are entitled to max 10% of the total revenue distributed by the StakeWise DAO.

With a fixed amount of compensation available, it will be up to the $SWISE holders to assess the merits of providing a $SWISE bond to any given Vault. Their decisions will inform the APR earned from bonding, reflecting the willingness to underwrite the risk of the Vault at the level of compensation they receive.

In the example above, Vault Y has only $20K worth of $SWISE staked as a bond, despite offering a very lucrative revenue share. The annualised yield that results from receiving this revenue is close to 300%. In this case, $SWISE holders looking to bond their $SWISE would need to conduct due diligence into the Vault operator(s) to determine whether such a high APR is a reflection of its high risk, or the lack of attention paid by other bonders to the market conditions. Similar logic applies to other Vaults.

Driven by this competitive dynamic, the equilibrium APR for riskier Vaults will likely settle higher than the APR of the Vaults that are considered less risky. However, the availability of at least some reward in each of the Vaults means that some amount of insurance will likely reach all of the Vaults that have some osETH minted in them, reducing the amount of trust it takes them to attract more delegations. $SWISE bonders will undoubtedly need to conduct extensive due diligence into the Vaults they are planning to underwrite. Yet the beneficiaries of their bonds will likely see an improved Vault Score and a perception of offering more safety, leading to more delegations and the consequent network effect.

Ultimately, V3 is about increasing the ability of Solo stakers to participate in liquid and delegated staking. The $SWISE bonding mechanism will not only help them to get their Vaults off the ground, but also reward the underwriters who believed in them.

Important considerations

As always, the devil is in the details. The finer print on these mechanics would emerge closer to the V3 launch, once the final parameters around osETH, liquidations, and Vaults are agreed upon by the DAO (provided this proposal resonates with the community in the first place). However, there are some rules to the $SWISE bonding mechanism that we already anticipate today:

1. Setting a minimal un-bonding period. To stop underwriters from pulling their bonds right when they’re needed, un-bonding should take some time, e.g. 5 days.
2. Ensuring $SWISE liquidity remains intact. The $SWISE bonding mechanism incentivizes locking $SWISE away in a contract(s), which could lead to less liquidity being available for low-slippage trading. We could consider requiring to add $SWISE to a Balancer liquidity pool with 90/10 weights between $SWISE and ETH, for example, and then bond using the LP tokens. Keen to hear your thoughts.
3. Not all Vaults are created equal, and their “security budget” could differ from the share of osETH they minted if they are more / less risky. We could look to introduce additional considerations for revenue distribution between the Vaults, subject to this making technical and economic sense. Discuss.

Modeling

The team has conducted its own analysis of the potential impact of these mechanics on the $SWISE price & benefits it could offer to stakers, and was satisfied with the results. This is not financial advice - we encourage everyone to conduct their own due diligence (like you would on Vaults) before acting on the proposal.

Discussion

With the StakeWise V3 announcement, the stakes for getting the $SWISE tokenomics right have substantially increased. However, any proposals to introduce changes is preliminary and is not enforced top-down on the DAO members; instead, it is subject to scrutiny and debate.

We invite everyone to analyse the proposal in that spirit. Let us know your thoughts, concerns and opinions, and we’re sure we will get the best tokenomics that StakeWise could land on. LFG

PS. The figures for $SWISE value, DAO Treasury revenue and APRs used throughout this post are completely illustrative and are not projections or expected values.

[dreth]

conceptually simple but very well thought out and designed insurance system, making SWISE a much more compelling hold

v3 shaping up to be the top staking product in the market in terms of staker and operator profitability + driving utility and real revenue to token holders beyond token inflation without any harsh token contract swaps

props for this excellent design to the team, looking forward to v3 (:

[Wiz]

@kiriyha

StakeWise DAO would distribute the ETH revenue it accumulates

Can you provide some clarification on this? Are you referring to 100% of the revenue earn or only a portion of it? It would be great if we get visibility around the distribution (between, say, operation %, and distribution %)

Wouldn’t it be simpler if we allocate a portion of the revenue earned as an insurance fund and distribute the remaining to $SWISE stakers, but with revenue paid out based on how long the user lock-stake? (kind of a ve-style)?

The flywheel effect would be same once we build up initial fund–> Insurance fund up → pay out up → $SWISE staker/buyer up → revenue up → Insurance fund up without the complexity of distribution here.

[rtree]

Great idea and basically I agree to use SWISE as backstop for slashing. This will also boost our tokenomics to open up many yield strategies that includes SWISE because of yield of SWISE.
e.g. ETH → osETH → borrow ETH → SWISE

One thing I would like to add a color is, I think we are more safe with keeping in mind that SWISE price denominated in ETH will be dumped in some events like this:

• Large slashing occurs.
• People are going to sell SWISE (because of unreliability of out staking pool.)
• SWISE price decrease.
• Someone is going to try to remove ETH from LP for SWISE/ETH pool
• SWISE price decrease.
• Looping above.

For this kind of scenario, something like collateral ratio for SWISE might be needed, so that SWISE * (something like collateral ratio) will be true insurance payout, based on situation, because loss from slashing is ETH based.

Or we might need to consider to have 2nd line of defense built by ETH collateral created by selling SWISE beforehand slashing to close slashing impact within a vault.

I have posted this in case there is a little bit of something that would contribute risk consideration within DAO. If I am wrong or completely am in lack of understanding, I am very sorry for my mistake and disturbance due to this post.

Basically I am strongly agree with this plan.

Thanks.

[kiriyha]

I think these are great points with which I agree. However, I think the impact of slashing in individual Vaults on the SWISE price should not be as dramatic as it could be now. It’s actually the reason we think SWISE could finally be the insurance asset we had wanted it to be originally.

In our thinking, the reflexivity of SWISE price to slashing events (the effect that you described above) is a real possibility today when the DAO is responsible for onboarding the node operators and any slashing event means a depegging of the sETH2/rETH2 tokens from baseline. This would not make SWISE a compelling asset for insurance and would require attaching some ETH value to the amount of insurance required for effective coverage. Hence why we shied away from proposing using SWISE as insurance until know.

IMO V3 breaks away from this effect. osETH should not be affected by slashing, so the product will remain intact even if it happens (ie no depegging = no loss of product viability). In such circumstances, I am not sure why the market should punish the protocol for slashing that occurred in an individual Vault. That’s my take at least.

In the interest of considering alternatives, how would you go about defining the collateral ratio? My concern is that it’s difficult to do given we actually want to leave the regulation of APRs from providing insurance to the market’s invisible hand. For example, if we set a fixed value of SWISE (in ETH terms) that must be staked into a Vault before revenue starts flowing and insurance kicks in, how do we ensure that enough SWISE is staked into the Vault to actually start generating some yield? Could you share what you are thinking here?

[kiriyha]

Thanks for the questions! I think we could be flexible here as a DAO and divert a smaller share to start with to see if we are achieving the desired effect. It seems the concern here is keeping enough funds for the development of StakeWise when we’re distributing revenue. I think this concern is valid but also I’d say the multiplier effect on the price from revenue distribution (if it kicks in) should be more valuable than keeping more revenue for development.

As for the locking model, the team’s stance is that requiring to lock the tokens to participate in revenue distribution is too high a hurdle for many whales at this stage of protocol development. Once there is a clear product-market fit and osETH has a massive supply then IMO we could reconsider this. For now, however, our proposal doesn’t feature distribution that’s proportional to how long you’ve locked your tokens for.

[kiriyha]

One consequent thought that I had is that in the event Solo staker Vaults (ie where the depositor and the operator are one and the same) account for a large share of StakeWise’s TVL, insurance may be provided in vain in case there’s protocol revenue allocated as a security budget by default. Therefore, I am thinking of applying a gauge-style selection process, where insurance with SWISE (and hence revenue distribution to Vaults) is opt-in, and SWISE holders have a say in which Vaults receive such security budget and which do not. If this mechanism were effective, we could put more insurance into Vaults that would actually benefit from it to attract external delegations instead of spreading the budget too thin, covering individuals who stake on their own nodes.

My concern with such a mechanism is it has a centralising effect, e.g. where only a handful of Vaults are approved for a security budget, and SWISE stakers in them are incentivised to not expand this set too much because they’d have to split their yield with some new Vaults / move to another Vault to preserve their yield if it were approved. This could be remedied by introducing caps on how much revenue a single Vault can receive as a security budget, meaning that SWISE holders who are not yet staking SWISE would be incentivised to constantly seek out new Vaults to insure and would converge on the safest of options available to them.

What are everyone’s thoughts on this?

[rtree]

@kiriyha

In the interest of considering alternatives, how would you go about defining the collateral ratio? My concern is that it’s difficult to do given we actually want to leave the regulation of APRs from providing insurance to the market’s invisible hand. For example, if we set a fixed value of SWISE (in ETH terms) that must be staked into a Vault before revenue starts flowing and insurance kicks in, how do we ensure that enough SWISE is staked into the Vault to actually start generating some yield? Could you share what you are thinking here?

As per questions you have presented, currently no idea from me, but now I have changed my mind that it’s no need for us to assume such collateral ratio, because expectations for rewards will create good counteraction for down pressure like this:

My previous scenario should have take upward pressure from rewards into account. Rewards will make good upward pressure against the fear for loss of slashing.

And I have also agreed to this perspective. Yes, if we successfully hold diversified nodes and secured quality operation, the event of each Valuts will normalized.

@kiriyha

slashing in individual Vaults on the SWISE price should not be as dramatic as it could be now.

Let’s build for diversification of nodes(Valuts). I think key for diversification is whether we successfully deploy good operational practices which is the same as good SRE, to the nodes that participate Stakewise: ensuring good operation philosophy, shared best practive design from L0[incl. electricity] to L8[human], making quality assured by periodic system audit etc…

It’s pleasure to have discussion with you.

[a_guy]

In such circumstances, I am not sure why the market should punish the protocol for slashing that occurred in an individual Vault.

Depends on why the slashing occurred. It could be a human error or a client bug, affecting multiple nodes.

Would it make sense to think about a model where the revenue generated could be withdrawn under certain conditions ( for example unstaking, though this is less than ideal ).

Then, the revenue would be the first insurance against slashing. Lets say the vault has generated 10 $ETH and the node is slashed for 5. Instead of paying out the insurance in $SWISE, the $ETH from the revenue is used, and if its not enough to cover it, fall back to SWISE.

$ETH is a much more liquid asset and paying it as insurance does not imply that users will sell it immediately. $SWISE might not be a desirable hold for many, which would lead to sell pressure during slashing events, which means that users might not be fully compensated, if the price falls.

Would it make sense for this additional insurance to perhaps be a metric for determining the vault’s score? Ie, all things being equal for two vaults, if one has more $SWISE staked, it should have a different score than the other one, because, for example, its safer in a way

[kiriyha]

Hey, thanks for popping in and leaving your thoughts - lots of great points here.

About the client bug / human error - I agree with you that in such circumstances the tokens of major liquid staking protocols would probably plunge, SWISE included. In such circumstances the insurance provided with SWISE may indeed not be particularly effective. Not sure how to counter this frankly… better not catch client bugs I guess

When it comes to the frequency of collecting the revenue accumulated by staked SWISE, I see your point about making accumulated revenue the “junior tranche” - it would allow to draw on a more liquid asset for insurance. There are two points here:

i) if I put myself in the position of an insurer (SWISE staker) then I wouldn’t like to run the risk of not having earned anything in case slashing does happen (+ potentially lose some of my SWISE to cover the loss fully). If I cannot collect a steady revenue stream from staking SWISE before an insurance “claim” hits, then I take on the underwriting risk and get nothing in exchange. I basically think it would be a tough sell, resulting in higher SWISE yields but less amount of cover.

ii) the revenue that gets collected by the protocol is not earned in “pure” ETH - instead, it is earned in the StakeWise staked ETH tokens, which are merely a representation of ETH. So while eventually they can be turned into ETH if redeemed, natively they are less liquid than ETH. I don’t think this defeats your proposition, but it’s important to note imo.

Finally, I also think the presence of SWISE insurance should affect the Vault’s score positively; however, we should also refrain from giving it too much weight to prevent the biggest / highest-scored Vaults from winning over and over again due to the network effect.

[a_guy]

i) Even in the proposed model, insurers don’t have a guarantee that they will earn something in the end, because their loss from SWISE can be more than the rewards earned in sETH2, but I do see your point.

If this model is something you are interested in, further tweaks could be explored such that providing insurance remains profitable under some identifiable circumstances

Here’s an example

• $SWISE is not used for insurance, thus, cannot be slashed
• $sETH2 rewards become withdrawable by $SWISE stakers, for example, 2 weeks after it was generated.
• Insurers make a bet that slashing will not occur in the next 2 weeks.
• Insurers cannot unstake for at least two weeks ( or, there could be a penalty, like loss of revenue generated )

The first point addresses your concern about being able to leave with less than you came in, however, something to consider here, $SWISE stakers are a counterparty to users of the platform and counterparties have risk exposure in general - their profits and losses come from taking the opposite side.

The simplicity of the model is also something worth considering, as it should not be overcomplex so that it is hard to implement, with many edge cases, and it should be easily understandable by the users of the platform.

I think that a model where insurance is able to be paid in two different tokens is not a good one.

If the idea behind this feature is that stakers have an insurance against slashing, then it would be best if the insurance is paid out in the same asset.

If its thought to be more of a compensation, then it is perhaps fine if its paid out in another token.

ii) I see your point, however, stakers are assumed to trust sETH2 as a reliable, stable and safe asset, otherwise they wouldn’t be using the protocol. They accept their exposure to sETH2 , but not necessarily to SWISE.

If their insurance comes in a token that they wouldn’t want to be exposed to, it will likely lead to sell pressure in order to get out of it asap.

Since they are already comfortable in sETH2, should a slashing event occur, they will be more likely to just keep it.

Happy new years

[Georg]

Thanks for the proposal. Once again written clearly and one can see that you have thought it through well.

Some comments/ questions from my side:

1. Will insurers still be able to vote with their $SWISE?
2. Is this mechanism intended also for the pool owners to insure their own pools? For this i don’t directly see a problem, as they make their pools more attractive (both in terms of security and the scoring system) for stakers to choose them. They get more rewards but also make their pool a safer choice and benefit the Stakewise ecosystem by bringing order flow and volume to the tokens.

@a_guy

I think that a model where insurance is able to be paid in two different tokens is not a good one.

3. I totally agree with a_guy’s point on this one. Simplicity of systems should not be underestimated, especially when they are consumer facing. i) It is way easier for users to understand and thus should result in more insurers and ii) it leaves less room for bugs in the code.
4. I’m not a technical expert, but one thing that went through my mind: Could it be possible for insurers to notice slashing events before they get slashed so that they can withdraw their insurance $SWISE before it can be used for the actual slashing?

[mcdutchy]

Is there a recent update on this idea. Or has this been completely buried?

[kiriyha]

Not completely buried - everything is still on the table, just a matter of priority we’re pushing to finalize the liquidity piece first, that’s all

[sergei]

will this be implemented with the V3 update?

[kiriyha]

A tokenomics revamp is certainly high up on the agenda based on community’s feedback, however, it will not be implemented in time for V3 release. When the team starts focusing on the tokenomics update, we will make a corresponding announcement on the forums, soliciting feedback to some initial ideas - so keep your eyes peeled!