SLURP-15 | Insurance Pool

SLURPs
1

Abstract

With this SLURP comes the definition of an Insurance Pool for the stake.link protocol. The goal of this pool is to insure all stLINK slashing events resulting from the underlying Chainlink Staking v0.2 economic protocol.

Rationale

With the stake.link protocol growing in both LINK staked and TVL, it’s important to consider how an insurance mechanism would be defined that both incentivises those providing collateral as insurance and the end-users who stake within the protocol. Even though the risk of slashing events within stake.link and v0.2 are very minimal due to only securing the ETH/USD feed, we need to prepare and plan for expansion with a highly collateralised insurance pool that mitigates any potential risk to encourage further growth.

If any stLINK slashing event occurred, this would result in a negative rebase of stLINK which would lower the amount of stLINK held in all wallets based on the amount slashed. This SLURP is to define an Insurance Pool so if a negative rebase did occur, then LINK would be transferred to the LINK pool resulting in a positive rebase which would negate the previous losses.

Specification

The high-level specification of the insurance pool is: allow those who LP for SDL or stLINK pairs to stake their LP tokens in the insurance pool to receive incentives. On any slashing or exploit event, the protocol would raise a claim event where an amount of LP tokens that equaled the amount lost would be redeemed and then reimbursed to stakers, mitigating any loss.

Currently, the stake.link protocol has ongoing incentives for two secondary markets, they are: stLINK/LINK on Curve and SDL/LINK on Uni v3. The insurance pool would seek to unify and simplify all incentives governed by the protocol, moving incentives from directly within these protocols to only the insurance pool.

Even without the insurance mechanism, this provides multiple benefits.It simplifies governance of the amount of SDL incentives per epoch; it completely negates the engineering complexity of working with numerous protocols on providing incentives while making the provision of new incentives for new pairs much easier.

The benefits above were apparent with the migration of SDL/LINK liquidity to Uni v3 as there were unknown at the time issues with incentive claiming on incentive pools while there not being any “official” UI within Uni v3 that allowed LPs to directly stake their NFTs. This resulted in 2+ weeks of engineering resources from the stake.link core contributor team, taking time and spending money on building out features for 3rd party protocols that shouldn’t be needed.

To add the insurance mechanism on-top is relatively trivial, while incentives would be adjusted over time to reflect the current risk of providing insurance. This mechanism is relatively similar but builds on top of the insurance modules seen throughout DeFi.

Insurance Pool Parameters

Within the insurance pool there would be several parameters:

  • Whitelisted LP/NFT tokens
  • % split of SDL incentives between LP token buckets
  • Overall SDL rewards per second distributed across all buckets
  • Maximum % of tokens that can be redeemed per claim
  • Withdraw period

The parameters would need to be defined and re-evaluated for every incentive epoch or every time a new LP/NFT token gets whitelisted within the pool. These parameter reviews would replace proposals such as SLURP-10, replacing incentives to 3rd party protocols in favour of the insurance pool.

Since the insurance is provided in the form of liquidity provision, it’s important to set a maximum percentage threshold of the tokens that can be redeemed per a given claim. If the threshold was too high, then the protocol would be liquidating significant amounts of platform liquidity which would have a large overall impact on protocol health.

A withdrawal period would need to be defined in the Insurance Pool to avoid a mass exit event if a slashing event did occur. The withdrawal period would need to be long enough to ensure that the insurance pool can process the claim before people exit but short enough to not deter staking into it.

Slashing/Loss Events

In the case of any slashing/loss event where the insurance pool is required to make up losses, the existing council governance process will be used to determine whether a claim from the insurance pool is valid. Claims will be raised on the governance forum, then voted on by the council members.

If the claim is deemed to be valid, then the required amount of LP tokens from the pool will be withdrawn by the protocol multi-sig for them to be redeemed and then transferred into the required contracts to mitigate losses. Since the redemption of the LP tokens would be dual-sided, for example SDL/LINK, it would be preferable for the LINK side of the LP position to be used solely to mitigate losses versus requiring to swap SDL to LINK. In the case of only using single side tokens, the remaining unused tokens would be transferred back to the insurance pool and distributed proportionately.

A manual process rather than a contract based redemption has been chosen as the redemption and transferring of tokens would add complexity and risk to the contract implementation that in my opinion is not worth the benefit as the tokens will be managed and transferred by the protocol multi-sig which consists of numerous Chainlink Node Operators.

Node Operator Slashing

The Insurance Pool would build upon the slashing mechanisms introduced with the stake.link upgrade for the v0.2 staking implementation. Currently, if there’s a slashing event for a Node Operator part of the stake.link protocol, that NOP would not earn any stLINK fees until the delta of the slashing versus fees earned since is positive. To expand on that, the Insurance Pool would add the following:

  • Allow to define NOP stLINK fee slashing for a specified period
  • Transfer NOP slashed stLINK to the Insurance Pool
  • Slash vesting NOP SDL and transfer to the Insurance Pool

By doing this it creates a balanced relationship between those providing insurance and the Node Operators. Improving and enforcing the crypto economic guarantees for the Chainlink Staking protocol.

The amounts to be slashed and whether stLINK/SDL or both are slashed would be determined within the claim raised. Upon the passing of this proposal, we would also specify some form of algorithm and guidelines for NOP slashing in more detail to avoid any imbalances between slashing events if occurred.

Development & Release Process

The development of the insurance pool at the time of writing has not started, I think it’s important for this to be raised first to gauge opinion that has the potential to dictate development as this SLURP marks a rather significant addition in the protocol itself and requires the opinion of those currently providing liquidity and earning incentives.

If passed and developed, a further SLURP would be raised closer to the time that would attempt to ratify the parameters listed in the section above as it’s currently too early to do so.

Conclusion

I look forward to reading the feedback on this proposal, as if passed and released, it marks a large milestone in which the protocol is insured against losses based on insurance pool size, installing user confidence. Even though the risk of slashing is very minimal now, we’re still in the early stages and it’s important to develop solutions to these problems before staking is considerably expanded.

3 Likes
2

Slashing is an extraordinary event. We want to be flexible in case of outliers, but it should not happen. It should not be so common that must consider overloading the LPs, or collateralizing every single NOP with the slash amount.

It is a feature of the stLINK pool that stakers will be covered in the event of a slash. Slashing is a NOP error. It must have NOP consequences. This insurance exists to protect stLINK stakers from NOPs, not NOPs from themselves.

NOPs however have a “safety net” in the form of their vesting SDL, as a way of raising capital they would otherwise not possess.

What I would propose is a pooled insurance fund, provided by NOPs, large enough to cover the cost of a slash. If plain LINK is not capital efficient enough, perhaps it could be held as an LP. But the sole purpose of this fund is to cover what should be an exceedingly rare event.

The size of the pool can be adjusted as more agreements are entered. But ultimately it is the performance and reputation of NOPs that will dictate whether stakers want to delegate funds here, not the size of the insurance fund.

In the event of a slash, the lost funds must be immediately replaced by the protocol. This would take the form of a loan to the offending NOP. This NOP would enter probation, and must earn back the full slash minimum before they may again withdraw rewards.

NOPs may exit probation by providing the new collateral in full by themselves. They may also raise collateral by diverting their vesing SDL. This would likely be an OTC process.

Successive slash or multi-slash events represent a failure of the protocol. They are the failure of the repeatedly slashed NOP(s), and a failure of SDL to properly vet NOPs or agreements.

If it is not possible to correct the behavior, a repeat offender would be removed from the protocol, and would lose their vesting SDL. This would be used to cover outstanding costs. And we would need to adjust our processes to insure this does not happen again.

3

I disagree with solely using vesting SDL as the insurance collateral, just even in regards to mechanism design and UX, consolidating the SDL incentives to an insurance pool is a much better experience.

By collateralising insurance with just SDL, at least at this point in time, would be setting up for failure with too many negative effects. The only way to compensate any slashing would be to swap SDL to LINK. If that occurred and with any size, it would hurt the protocol more.

As mentioned in the post, having LPs provide insurance but reimbursing insurers with NOP SDL if there’s any gross negligence is a better way of implementing it. SDL doesn’t have to be swapped, and insurers I would presume would be happy with the rewards as the main incentive to stake LP in that pool at this point in time would be SDL incentives.

With the new tokenomics, NOPs have traded LINK yield and fees for the vested SDL that is more available to them. I’d then say requiring that to then be placed as collateral would be overloading the NOPs where as LPs aren’t overloaded and are just incentivised for providing liquidity. Especially where there’s minimal risk say with stLINK/LINK.

As you say with any slashing event being extraordinary, then the risk adjustment for the incentives is more minimal whereas the tradeoff for NOPs is more significant. I just don’t think loading that onto the NOPs vs LPs is fair especially when you consider the improvements of UX and having the primary asset to reimburse the pool if any slashing events occur.

1 Like
4

To clarify, I’m suggesting a reserve of LINK as the backstop, not SDL. This LINK would be provided by NOPs, pooled together as a collective “stake”, with the explicit understanding that you will refill it if one of you gets slashed. If this sounds precarious, I’ll point out that the protocol is already in this state, where the error of any one node will cause a negative rebase of the entire pool.

It would be the responsibility of NOPs to keep the insurance pool funded. It is the responsibility of NOPs to keep each other honest, which means if one of you slashes the other, the slashed NOP should still face a penalty, even though no negative rebase occurred.

Refilling the pool after a slash represents a loan to the slashed NOP. If they wish to pay off their loan more quickly, they have the option of redirecting vested SDL OTC for LINK, or organizing some diversion of future stLINK yield in exchange for LINK now.

If a NOP were not part of SDL, they would have no similar option to quickly reraise collateral or repay their stakers after a slash. They would also have no supporting nodes to buffer their loss of reputation (and exodus of stakers) after being slashed.

By sharing a collective “slash stake”, which you are obligated to fill, you have a greater incentive to avoid slashing that will negatively affect your fellow NOPs. You will not have a pool of liquidity providers to absorb the cost of your error — you must absorb it together.

SDL, both the token and the platform, should only directly bear the cost of a slash in the event of a delinquent node, as part of their termination from the cohort. It should only be possible to reach that state if we make a mistake in which nodes we allow to be here, or fail to properly audit a service agreement.

Likewise, the platform should not have to pay for this insurance. The obligation to pool LINK for the fund should be a proviso of NOP membership, just as avoiding slashing in the first place is their obligation. The benefit here is that a single collective stake can cover all of them at once.

NOPs’ ability to keep the insurance fund solvent is reflective of their reputation. And it will heavily incentivize them to remove nodes that cannot meet basic standards of performance.

5

Some thoughts on this in addition to @Fox 's idea of the node operators funding it which I broadly agree with.

(Alternative account as had some email issues).

First Principles

What is the aim of the Insurance Pool? Is it to provide short term cover for the slashing penalty to maintain stLINK rewards? Or is it to also socialise some of the slashing amount for node operators? Should node operators be responsible for cover any slashing event? Or some events?

The current approach is complex and would require subjective judgement on the risk of providing insurance.

Alternative approaches

  • We could accept an extra 2100 LINK (enough to cover three slashing events in v0.2) into the protocol as a slashing buffer. This would come at the cost of slightly diluting rewards. This stLINK would still be backed but by deposited LINK rather than LINK deposited in Chainlink Staking. The Council would then investigate the event and the amount would be remedied by the node at fault. The buffer could be simply increased (or decreased) as needed. This would mean that node operators wouldn’t have to put up their own LINK in the Insurance Pool.

  • Alternatively, a percentage of protocol revenue could be taken to build the Fund, potentially solely from the node operator fee. This is the approach that Lido uses (Does Lido have an insurance fund? | Lido: Help). This fee could cease being taken after an amount (such as 2100 LINK) is reached. While this would take some time to build towards, slashing events are currently highly unlikely to occur.

Other thoughts

  • As an aside, I wonder if alerting through the SDL frontend could be added. This would be an additional feature of the protocol and enable more eyes on the ETH/USD feed. Part of the rationale of the Community Pool is more decentralised monitoring and alerting and SDL could act as a specialised monitoring layer. The protocol could even fund or develop specalised monitoring tools to check for possible alerts. The protocol could take a 10% fee for a successful alert from a community member through SDL.
2 Likes
6

I see that as a variant on the principle stake seen on various LSD platforms such as RPL. Requiring NOPs to lock up LINK collateral that is at risk of being slashed defeats one of the main purposes of the platform to begin with, liquid staking. I don’t like principle staked amounts, it impacts growth as it is a large barrier to entry. As someone who’s had opportunities to join staking platform that have required principle stakes, we’ve turned it down simple on opportunity cost alone.

Within stake.link there’s a large variance of participation from NOPs, ranging from those who have no LINK staked themselves, to those that have 50k+ stLINK. I just see this idea as an impediment that enforces more of a principle than CLL staking itself with 1k LINK minimum.

It’s putting another burden onto NOPs which is greater than the underlying staking protocol itself while stLINK holders carry less burden while reaping a higher underlying reward rate.

3 Likes
7

Fully agree with this, and should be the approach once the protocol itself can pay for insurance. I’d probably suggest a variance where the Insurance Pool would receive a portion of fees to encourage more deposits into the Insurance Pool.

This is a good point and noted. Worth stating that currently within the stake.link contracts, only the NOP can raise an alert through their own vault that has the 75k LINK staked. To make that available through the platform with a frontend and monitoring stack is a good goal to strive towards.

I’d just say at this point in time, since it’s very unlikely for an alert to be raised, it isn’t worth the engineering time.

1 Like
8

I’m not going to complain if NOPs would prefer to hold their part of the slash collateral as LINK/stLINK LP, and receive SDL for it like any other liquidity provider. I also don’t care what ratio of contribution comes from individual NOPs, that’s up to you all, and can be fluid according to your needs. What matters is that it will be your collective job to cover the loss.

I don’t see the need to create a complex insurance pool, especially when developer time is running at a premium, for an event that 1) should very rarely happen, and 2) can be trivially handled by you simply covering the loss yourselves. Again, this concerns the reputation of the platform, and why stakers should feel comfortable putting their LINK in the pool.

If you want to unify liquidity mining rewards to make things simpler, great. Attaching this secondary goal to an as-yet undeveloped insurance pool seems counterintuitive. If providing slash collateral is for some reason a great burden, EqS’ idea to build the pool from the NOP fee seems reasonable.

1 Like
9

Could also just sell 75,000 SDL from the Treasury and buy 2100 LINK. Then implement a fee from node operators or even the protocol as a whole to add to this. As overall protocol fees increase, the Fund will grow more rapidly.

10

The implementation for the Insurance Pool isn’t complex and would inherit functionality for base contracts such as the LINK & SDL pool. The core team agree with the approach, triggering me to raise the proposal.

To be clear, the ideal end-goal would be the Insurance Pool is funded via stLINK fees but the problem remains that:

  • 100% of the 3% core contributor fee goes to funding the Keepers that automate the protocol.
  • NOPs traded the majority of their stLINK fees in SLURP-8 meaning any portion is not enough to pay for insurance.

There needs to be a synergy between the LINK stakers and the NOPs, and in the protocols current form there is no current solution to providing insurance that doesn’t require either swapping significant amounts of SDL, having a greater impact.

If there’s minimal risk in slashing, then LPs should feel comfortable in a risk-adjusted Insurance Pool. This mechanism is similar to other examples throughout DeFi such as Aave’s safety module, but with less complexity.

11

I don’t understand this part. Does that mean we wouldn’t be incentivizing on OP or is this just mainnet?

What about NOPs locking SDL for this instead that can be sold/forfeit to treasury? Doesn’t selling SDL (whether it be from the treasury or from this NOPs locked fund, depending on governance claim decision) socialize the losses in a similar manner without requiring the need for this kind of pool?

12

We would still incentivise OP. I suppose the question would be whether we deploy a new Insurance Pool on OP or whether we bridge the LP tokens to ETH. Bridging to ETH defeats the purpose so I would probably side with a cross-chain Insurance Pool.

Any insurance depending on the selling of SDL in my opinion, at this stage of the protocol, is flawed. NOPs traded the majority of their stLINK fees in SLURP-8 for the new tokenomics so to require the forfeiting of SDL that requires selling while stLINK stakers and LPs earn the lions share of the yield is a lobsided model.

1 Like
13

Is there any estimation of how much the SDL emissions would be under the proposed model?

Also is 75,000 SDL really that significant given that the Treasury has ~40m SDL and that over 1m SDL will be distributed soon through SLURP-10. Seeding the fund with 2100 LINK and then setting a low fee seems a reasonable course. We could even have no fee currently given that the chances of even a single slashing event is so minimal, let alone three.

14

To be blunt, I’d just say that is short term thinking. The protocol needs a design for insurance that is scalable and simply doing that is not, even though the amount needed to cover slashing now is minimal. Selling SDL for insurance is not a pattern that works at scale.

1 Like
15

This discussion frankly is a bit too high level for me. And I don’t want to pollute or interject the way I do on telegram…But I do have a thought I wanted to introduce

I’m getting the sense that in the event of a slashing event, we are in essence, looking to replenish the NOP position with scarce resources, underlying revenue sources, underlying fee routes, and this would of course intermittently halt sources of revenue. Should there also be any thought given to collaborating with on-chain insurance projects to perhaps offset the “hit” the protocol takes in the event of a slashing event. Perhaps, they could decrease the cost of insurance for us, and perhaps, it would invite players who don’t want to participate in the SDL protocol, but want to participate in a lower risk, lower yield endeavor. One such project is etherisc (DIP) // https://etherisc.com/ . They recently deployed a “de-peg” insurance of Tether and have various climate forms of insurance; but in the same way that we are thinking of ways to divert our revenue flow in the event of a catastrophic slashing event, perhaps we could find a way to partner with Etherisc/DIP to at least attempt to continue to have some revenue flow. Spitballin’ here…but perhaps we could consider a LINK-stLINK-SDL-reSDL-DIP liquidity pool, and over the course of months/years divert the funds/fees from such a liquidity pool to an insurance pool reserve. DIP has interesting concepts or projects. One feature is that one can stake DIP, receive returns, but DIP simply maintains the insurance risk pool open, and in the event of a catastrophe DIP itself never gets slashed; it invites others to open and support and augment the catastrophe pool.

My main point is…I think the crux of the discussion is how far and how wide do we spread our revenue sources thin as we attempt to replenish ourselves in the event of a catastrophe? I wonder if we should also get some support from emerging on-chain insurance projects.

thanks.

16

This has had a lot of time to marinate. I’ve concluded that some sort of insurance pool is the best path forward. However, I question the motive for LPs to deposit into insurance pool. Right now, you can LP SDL/Link for 47% rewards and with just IL risk. Now we intend to add in an option to stake your NFT for added rewards, but also include slashing risk? stLink/Link is already 9% too. How do you attract more liquidity? If the plan would be to decrease rewards to those not in the insurance pool, I feel there could be a loss of TVL to go along with the same/increased total emissions.

1 Like
17

It’s a fair point Seth, and one we’ve discussed as a team. In the early stages, the incentives make sense to bootstrap liquidity. If we think longer term, especially when liquidity is more established, the protocol incentivising liquidity doesn’t make as much sense whereas the protocol incentivising insurance is the protocol receiving something in return for the amount it’s paying.

After doing work on the insurance pool, supporting Uni v3 at this stage is too complex as how you’d slash and provide incentives based on liquidity ranges make it unfeasible. The only way to implement it would be by people providing liquidity for Uni v3 directly through the insurance pool and the pool staking it as only full range liquidity.

Due to the above, we think at this point in time it only makes sense to provide the insurance pool for only the stLINK/LINK pairs in stable pools both on ETH and L2’s.

2 Likes
18

Voting for SLURP-15 is now live!