Preventing a future black swan event:

Community Chatroom (DISCUSSION)
1

Preventing future black swan events:

A simple solution would be to introduce an ILP protection withdrawal fee that triggers ONLY during extreme market conditions. This withdrawal fee mechanism would be dynamic and would monitor the potential ILP minting in cooldown. In extreme market conditions, a potential ILP threshold would have to be met (like a bank run). If met, the withdrawal fee would max out at 99%. Meaning almost no ILP. The withdrawal fee could burn BNT or Vortex it. This mechanism would then slowly wind down the withdrawal fee by 1% per day IF the potential ILP minting didn't increase by more than 2.5% per day (need to study this number). Essentially, if the potential ILP minting remains the same or increases a small amount, then ILP payout will reduce 1% per day. We could ramp down faster IF potential ILP minting in cooldown drops back below the threshold. 

 

Why this method?

This creates a scenario where during a bank run type event. Users are incentivized to stay in the protocol & users who exit provide direct benefit to the protocol & all users. This also disincentivizes a bank run by large entities. As in our current environment, each day, more potential IL minting enters the cooldown, because of the bank run scare. So, if this mechanism was in place today, ILP fee would remain at 99% for a long time. Bank-run parties would know this in advance and wouldn't want to engage in the activity, because their ILP could become "locked" for a long time. This would incentivize VERY large withdrawals to space the behavior out over time.

This also creates a scenario, where the only way a VERY large bank-run entity could withdraw would be to do so over time. If they triggered the mechanism I propose, they'd likely have to re-enter the protocol with a large portion of their LPs in order to receive ILP on a smaller portion once ILP withdrawal fee ramped down. 

 

 

2 Likes
2

I support this, EIP-1559 for Withdraw Fee basically.
This should drive data analytics that determine outstanding ILP owed, and Burn-down rate of potential ILP payments based on deficit to surplus.
I believe the Withdraw fee is DAO controllable as well so should go to Snapshot as soon as required data is available

2 Likes
3

Tldr bancor needs to tie more deficit to fees rather than time (because with time, fees earned during bear market =/= during bull market).

4

Just putting some of my thoughts and this idea into points for better clarity:

  1. The security withdrawal fee is something that is calculated when you enter the cooldown phase and it is currently set to .25% of your position. This fee is not collected until 7 days later when you actually withdraw.
  2. This idea is suggesting that the .25% security withdrawal fee be dynamic based on the current positions that are queued in the cooldown state and any potential minting that will need to be done should they be in deficit.
  3. Typically, BNT compensation for positions is calculated at the actual point of withdrawal because deficit/surplus could change from block to block.
  4. The security withdrawal fee can be as high as 99% depending on the amount of $BNT minting that will have to be done due to any deficit that exist in the queue positions. A formula would have to be derived for how the security withdrawal fee will be set dynamically.
  5. The security withdrawal fee which is normally collected to strengthen the protocol and bring back TKNs that are in deficit for certain pools is being suggested to be use to buy BNT and burn or to swap for vBNT and burn. This would have to be elaborated upon as I don’t think using the entire fee for burning $BNT or the vortex is wise.
  6. The mechanism would slowly wind down the security withdrawal fee per day by some percentage depending on how much $BNT minting will have to be done for what is left in the queue. I am not sure this is necessary since the formula that calculates the security withdrawal fee for when you enter cooldown can just run again to figure out the current state of the queue and provide a fee at that point in time. That is, if everyone was queued the day before and now they are no longer there then anyone that decides to withdraw can do so at the lowest security withdrawal fee (will have to be established)
5

I agree with this. Unfortunately, Bancor is not an over collateralized protocol like Maker/Aave, and UNI doesn’t have to cover anything at all. All of the data that V3 was designed on, was fee based ILP. It didn’t work. All of my numbers/times are purely examples. But when a bank run event happens, the protocol deficit is such that a death spiral can occur.

When a potential death spiral is happening, we have no control over fees, and we’re in a situation where fees could rapidly diminish in a short period of time. By tying ILP to time, we create a waiting game where ILP is slowly increasing…but as people opt in and take the loss, it’s benefiting those who stay. There more people who take the loss…the less likely others will be to leave. Essentially, they’ll see the mechanism working and seeing themselves directly benefit as protocol deficit decreases.

6

What I meant is, the % LP earned should be consistent with the % of ILP. Irrespective of time, as a constant time may or may not make the fee enough to cover ILP.

That said we need data of fees vs IL owed to identify the difference

1 Like
7

You’re saying is we keep the system as is, but not offer 100% ILP coverage if the fees don’t warrant it.

That’s basically the same as LPing on any other AMM. Where is the value prop?

In my proposal, time is used to force action and avoid a stalemate.

1 Like