Safety Module and EUL Staking

Archive
1

Authors: Skycatcher
Related Discussions: N/A
Submission Date: 21st / Nov / 2022

Summary:
An open discussion about EUL staking and deploying safety module

Abstract:
Currently, Euler does not yet have a safety module implemented – see here: https://docs.euler.finance/security/vault.

In other leading money-market projects across DeFi, these staking modules are used to further collateralize the system. The same is true for other leading CDP protocols, where the native token is used to further collateralize the system, increasing overall security for both borrowers and suppliers using the protocol.

Given the heightened sensitivity right now that markets have towards both overall security and fundamental value, this discussion may be timely. Implementing a safety module can ignite a flywheel of value creation - where more value is created for everyone (token holders, borrowers, lenders) and further adoption is encouraged across these user cohorts.

Motivation:

Specifically, implementing a safety module can achieve the following:

• Enable EUL token to be utilized for purpose of further collateralizing the system. In case of bad debt e.g., EUL tokens from module could be sold on market to cover said debt. This creates value for users.
• Governance and revenue distributions could be made to EUL tokens staked in the security module, increasing overall token utility, and establishing long term alignment between protocol and EUL holders with skin in the game.

This post is to open discussion around the staking module and source community feedback.

Implementation:

The actual design of a staking module here remains an open question. AAVE’s staking module could be viewed as a solid benchmark.

There is also the additional consideration of current state of EUL’s on-chain liquidity and whether further action would be required on this subject as well.

1 Like
2

Hello there! My company recently did research on dYdX’s safety staking module. Although I’m not a part of the Euler ecosystem, I think all of the ideas from my research are just as applicable to Euler as dYdX.

tl;dr: if insurance is what you really want, the last thing you should use is the native token, EUL, to insure against Euler shortfall event. Use something like USDC or DAI instead, since they’re uncorrelated to shortfall events and have much more liquidity.

Links: forums, blog post, and full research paper.

3 Likes
3

Hey! The proposal seems interesting, taking into account especially the experience of other lending protocols.
At the same time, I would prefer to keep the EUL function as a governance mean only, so that its price/supply etc would not affect the protocol itself. In this respect, I have some doubts that selling EUL for covering debt would be a good way. Instead reserves should deal with that, imo, as it is now.

4

In addition, while the reserves are small at the moment, do they serve a similiar purpose? Obviously they need time to grow more. I’m not sure if I follow - would you want a safety module on top of these reserves?

5

thanks @maxholloway - will definitely check out your research! I also wonder if the implications are different for a perps protocol vs Moneymarket protocol.

@Raslambek @river0x - totally hear where you guys are coming from. This wouldn’t eliminate any governance functionality in the token, rather it might vest it in holders taking on risk to protect protocol users, rather that just holders who bought it and keep it in their wallet. This also makes the token more resistant to governance attacks in the future - where actor can just buy bunch of tokens someplace and propose changes that benefit them uniquely.

The idea here is that in some cases, a protocol can actually be manipulated or otherwise adversely affected by market volatility such that the reserves deposited by users are *not enough to cover the outstanding debt.

just the other day, this happened with Aave, and while the reserves covered most of the debt issued, the protocol was left with ~ 1m of bad debt. This was covered by the protocol by selling tokens from the staking module. So the mechanism does work in that sense and that’s the potential use case here to clarify. This, as in the aave case, serves to create further protection for all users that today don’t have that same protection that other projects might offer / provide with their native token. MKR for example is bought and burned with revenues paid by DAI minters (borrowers), and is designed to inflate if the underlying reserves ever become compromised by market volatility, for example. So there’s some precedent there as well…

6

yep safely module on top of reserves is idea here

1 Like
7

am thinking that ultimately native gov tokens need more utility / mechanisms around them than just voting whenever gov proposals get posted, otherwise market can just buy when gov vote is posted and sell when it’s done. leaves door open to attacks in this way as well…

8

Thanks for the proposal @phoenix . I generally agree that a safety module is something we should dive deeper into. I especially like the ability to add a time component here similar to CRV.

a. This incentives lenders to lock EUL for longer time to gain max interest and borrowers to lock EUL to get min interest on their position.

b. Governance to be operated by (illiquid) veEUL and boosted governance power based on lock duration, thus aligning token holders to long term protocol value

@maxholloway raises a good point here. Especially when it comes to corr 1 events. Maybe part of the fees can flow to the saftey module, so we have both the native token and some stables in the saftey module as a backstop.

9

Safety modules have been quite popular in the past for lending protocols. Aave has a very similar security module to what is being proposed here, but Maker also has some variation of this, by introducing MKR minting in the unlikely scenario that DAI becomes under-collateralized in some way.

I think for the most part however, this is not a viable strategy for back stopping liquidity. There are some clear conflicts of interest which arise as a result of using the protocol’s governance token to prevent insolvencies. The most notable issue being that the gov token holders them selves would need to vote to slash, or in some cases dilute, them selves.

A past example of conflicting interests between a protocol and its community/users, is the Maker DAO vote to compensate the bad debt as a result of the March 2020 crash. @monet-supply made a summary thread which I’ll post here for reference. In that case, MKR holders were adverse to diluting their token by compensating vault owners with a relatively minor amount of debt in comparison to the MKR marketcap at the time. Now there are some nuances in regards to the Maker incident since there wasn’t a clearly codified rule that improperly functioning liquidations should result in MKR being used to cover the shortfall.

Moving on to a more recent example, dYdX governance passed a proposal just last week to completely wind down the DYDX security module, siting ineffectiveness in serving as an insurance fund. dYdX Governance & Staking

Aave’s security module, which may be the most similar to this proposal, is also not very practical in design. Just this month, Aave suffered from a small amount of bad debt as a result of improper parameterization for the CRV token. During the unfolding of that event we witnessed several stkAAVE holders enter the withdraw queue, or begin withdrawing as they noticed the large CRV position building up. The amount of bad debt Aave incurred was relatively small in that event, so realistically Aave stakers were never really at risk (given how big Aave’s reserves are). One does not need to be a genius however, to see that if the bad debt incurred was significant enough to force AAVE stakers to be slashed, it would motivate for stkAAVE holders to NOT vote to slash them selves or in other words give away a portion of their holdings.

I think a more appropriate form of a “staking module” or “insurance fund” would be a contract which holds a basket of stablecoins (I would advise against using censorable stablecoins like USDC for this), that can be slashed or used to cover liquidity short-falls by way of governance vote. That would draw a clear line between EUL holders and the lack of incentives for covering bad debt.

If the idea of this proposal is to bring some utility to EUL, I think there are much better alternatives like vote-locking incentives for EUL stakers and EUL/ETH LPs.

1 Like
10

To echo what @maxholloway and @Millie said I doubt that a staking module is an effective measure to backstop insolvencies. Accumulating large stablecoin reserves is by far the best defence against such an event.

I agree that a Balancer pool type staking module like Aave could have the added benefit of increasing EUL liquidity. But I would argue that it is probably not the best use of the team time to focus on this when other options like adding EUL liquidity directly might be simpler and just as effective.

1 Like
11

lot of great feedback and points made here!

To clarify because it was brought up specifically - the intent behind this RFC was discussion around safety module specifically and the value it’d create to users, and thus EUL by extension. Matters of EUL liquidity or ‘general utility’ like AMM LP’ing I think may be implied here or can be related, but main focus of this post was intended to be about creating value for users via a safety feature of product / protocol and in aligning EUL with that value creation directly …

@maxholloway @jengajojo @Millie @Shippooor - many thanks for detailed thoughts and feedback here -

For sure agree that it’s possible EUL would be correlated with other assets /markets that are being subjected to the bad debt scenario - not necessarily always the case however. That said, can definitely see how stables alleviate potential risk here of EUL correlation.

The flip side of stables however (I think @Millie mentioned this) is there really isn’t any fully immutable / uncensorable stables (exception LUSD, others?) - for example USDC, and thus DAI, FRAX, USDT and others are all pauseable. Imo, protocol is best off minimizing censorship introduced directly into insurance /safety module, which is (potentially) providing a very fundamental form of protocol collateral. Perhaps it’s possible to even eliminate this risk altogether…

So, I think ETH and/or EUL token itself become the more natural candidates here for using in a safety module, given censorship resistance. And I do think EUL is the more ‘aligned’ asset to be using w/r/t protocol itself.

So re correlation concerns - which seem very valid - I wonder if a safety module could be designed to alleviate these concerns in a way where price is more stable. Something like…

  • Some target amount of coverage against protocol deposits would be established.

  • EUL is staked in the safety module to play key role in said coverage.

  • Module effectively acts as a market mechanism between protocol treasury/revenue and stEUL where DAO treasury is buying covered puts from module itself with strike price of ~ 20% discount to 30d TWAP. Maybe chainlink oracle or something similar could provide simple reliable pricing for premium…

  • Staked EUL is yielding as result….

  • Puts would be executed by protocol only in time of ‘bad debt’ - proceeds of which are used to cover debt.

  • This way regardless of whether or not EUL is correlated with market events that may have created bad debt, the DAO benefits from being able to source decent liquidity without slippage and maximize coverage, and stakers still benefit from solid sale price.

  • The entire time, users of Euler’s current or future products know their usage is covered against more extraneous events than they are today.

^^ This is rly just an example design attempting to address concern of correlation- would be curious what folks here think abt this sort of approach and different / better ways it could be designed.

Regarding points on time lock, voting incentives etc - overall I think there’s a lot of value in systems that align / reward longer term owners / pov. Governance powers etc…

I also think the best case for a system like this where it’s made as autonomous as possible. Governance minimized. Maybe using ve-style timelocks does help to alleviate concern of stakers "backing out” ….

Overall, my POV is that whatever way this were to be built / implemented, stakers should not be able to withdrawal as soon as some event takes place - they should be required to hold up their end of bargain as a function of smart contract-level enforcement.

Idea here is not for free lunch for EUL, rather enable it to express risk appetite and both reward it for taking on risk and enforce it in actually eating that risk when called upon.

To conclude…

As it stands rn, Euler the protocol inherits and manages these risks - natural to a money market protocol like this. But there’s no specific plan for actually dealing with this risks should they materialize…

I do think a safety module benefits the protocol and it’s users - in providing explicit protection against bad events, and allowing protocol itself to explicitly express and transfer that risk to a specific subset of the protocol (EUL token) where it’s deemed most efficient.

I think it’d be awesome to see community come up with design for this which addresses concerns around :

  • Overall execution design and enforcement
  • censorship
  • liquidity,
  • correlations
  • Anything else(?)