Ratification of Emergency Actions Taken on Sunday 19th June (UTC)

DAO Archive (SUBMITTED)
1

This proposal is a ratification vote for emergency actions taken on Sunday 19th June (UTC) to prevent damage to the Bancor Protocol. The purpose of this vote is for the BancorDAO to determine whether the measures taken will remain in place until a long-term solution is proposed.

Voting Instructions:

A vote FOR will result in the emergency measures being left in place until a long-term solution is presented.

A vote AGAINST will result in the steps taken to protect the protocol being reversed, thus returning the system to its vulnerable state.

Preamble

A culmination of factors resulted in an emergency requiring special intervention to protect users of the Bancor protocol. The changes were applied at approximately 23:00 Sunday 19th June, 2022. Due to the emergency of the situation, these actions were taken without a prior DAO decision. The BancorDAO previously approved a proposal acknowledging that such emergency powers were necessary so that protective actions could be expedited ahead of the formal voting process, subject to a subsequent vote. Such an emergency presented itself, and actions were taken with the understanding that the BancorDAO would subsequently vote on whether the protective measures remained in place.

BNT minting, normally used to cover impermanent loss insurance and deficits in withdrawals, was halted. The reason being, at the time, pending withdrawals in combination with the impermanent loss protection (see below) could have crashed the BNT price to essentially zero, leading to a situation in which the recovery of funds for all liquidity providers would have been in peril.

The route to irreversible damage, regardless of BNT printing rates (including zero inflation), can be illustrated as follows.

  1. A non-BNT liquidity provider exits from the protocol during a deficit - such as the case with LINK, ETH and wBTC prior to the emergency intervention.
  2. The protocol returns their tokens, including an amount of BNT as per the constant product portfolio evaluation alone, or with further compensation in newly created BNT (it makes little difference).
  3. The non-BNT liquidity provider then immediately swaps their BNT for the preferred TKN.
  4. Therefore, the relative deficit is further exacerbated; the rate of the deficit increase is faster with IL insurance (i.e. with additional BNT printing), but not contingent on it.
  5. Steps 1-4 can be executed by multiple users, and inadvertently affect the situation for others. During a sustained cascade, the downwards price pressure on BNT can move the market farther from equilibrium with each iteration.
  6. Taken to its natural conclusion, those leaving in a panic would have trampled those who were slower to react, or simply remained patient.

During the week leading to the emergency decision, the following actions and protocol behavior were observed:

  1. A clear pattern in which big withdrawals were made, received BNT compensation and immediately sold the BNT tokens leading to suppression of the BNT price.
  2. A growing short position on the token as evidenced by the open interest on FTX and OKEx, that happened to coincide with these withdrawals, suggesting an opportunist was seeking to benefit from the oncoming cascade.

The forecasted effects in a worst case scenario for Bancor liquidity providers, and the protocol itself, were severe enough to warrant an emergency intervention. It should be highlighted that Bancor V3 already has changed behavior to V2.1, and many of its features were not given sufficient time to take effect. However, the lack of resilience to a mass-panic event is underscored, and mechanisms to protect the system from similar market conditions in the future will be required at the smart contract-level.

The Threat Identified

The Bancor Network offers its liquidity providers impermanent loss insurance, in return for a portion of the trading fees earned on the protocol. The impermanent loss insurance mechanism operates by reimbursing apparent losses with the BNT token, while offsetting the inflationary costs realized by destroying BNT, paid with fees collected over time.

A series of events transpired that undermined the time assumption, and challenged the notion of a market at equilibrium. Some of the largest rewards accumulators disposed of the tokens hastily and irresponsibly very recently, into a market that was ill-equipped to handle the selling pressure. This created a fast deficit on the protocol with respect to its impermanent-loss protected evaluations of user positions.

Therefore, at the time of intervention there was a significant relative deficit for major tokens on the Bancor protocol, and a large number of active withdrawals in cooldown. Under these conditions, the impermanent loss insurance mechanism was expected to have produced a runaway effect. The large relative proportion of the TVL of the network departing in a short time period, as projected from the withdrawals in active cooldown, had a very credible and substantial risk of resulting in an unsustainable cycle. As the relative balance of BNT inside the network continues to increase, the number of BNT tokens required to compensate liquidity providers also increases. This feedback loop had an unacceptably high probability of coming to fruition, which would have threatened not only user funds, but the protocol as such.

The Emergency Actions Taken

The protocol’s BNT minting capability with respect to the insurance mechanism was paused, effectively halting the feedback loop and preventing the runaway effects. In addition, the following protective measures were implemented:

  1. Deposits were disabled across the protocol. This measure prevents users from participating in liquidity provision while the protocol is in a stressed state.
  2. Withdrawals from V2.1 require migration to v3 first. This measure prevents a complex contract upgrade for the V2.1 system that would have required a longer development process, and increased the likelihood of bugs and unpredictable behavior.
  3. Withdrawals from v3 remain active, with the following modification: BNT compensation is no longer provided at withdrawal. Therefore users may withdraw their pro-rata share of the vault balance in the TKN denomination of their pool token.

Therefore users may withdraw while the system remains in the paused state without receiving BNT.

These measures were implemented as temporary emergency measures to remain in effect until the DAO votes on this proposal. If this proposal is approved, the protective measures will remain in place for now, to protect the protocol until a longer-term technical solution is proposed and approved by the Bancor DAO. The community is actively investigating solutions to reactivate IL insurance; these solutions will ultimately be proposed to the DAO in order to be implemented.

If this proposal is not approved, the protective measures will be rolled-back at the conclusion of the vote, without any other protective measures in place.

The Ratification Proposal

This proposal asks the BancorDAO to ratify continuing the emergency measures put in place on 19th June, 2022, to protect the protocol from harm until a longer-term solution is proposed. If successful:

  1. Deposits will remain disabled across the protocol.
  2. Withdrawals from V2.1 will continue to require migration to V3 first.
  3. Withdrawals from V3 remain active, without BNT distribution. Withdrawals are pro-rata with respect to the vault balance in the TKN denomination of the pool token.

If unsuccessful:

  1. The system will be returned to its previous state.
  2. Without new technical measures in place to protect the protool, the dangers outlined above will remain a concern.
  3. The system will be vulnerable until an alternative protection mechanism is proposed.
8 Likes
2

When will the proposal go live on Snapshot? Can’t find that in the proposal. @mbr

Do we maybe also have some charts from our upcoming analytics tool to further strengthen the pause of the ILP? Like in how the deficit suddenly sky-rocketed or maybe a forecast of what could have happened?
I know there are some Dune Charts, but I think they’re a bit too cluttered atm.

2 Likes
3

I will be personally voting for this proposal as I am of the opinion that enacting these emergency measures were a necessity to save the protocol and therefore users’ funds.

@AnimaDunk perhaps this chart might help illustrate the situation:

image
image1884Ă—467 27.9 KB

You can see that in a span of a few days, we went from 13m $BNT minted in the lifetime of the protocol for IL insurance to >52m. A lot more would have been minted had the emergency measures not gone into effect and obviously would have depreciated the value of $BNT significantly.

7 Likes
4

Hello,

Trying to find as much information as possible on this but it is quite hard considering it was deemed an emergency action and I think nearly everyone was caught off guard.

I am wondering if you could clarify point 3. in this Ratification Proposal - with an example to illustrate the impact - could you use a smaller protocol such as $THALES for instance.

1 and 2 seem clear enough, the intent is to formalize the actions that were taken last week and also require the V3 migration.

But again an illustration would be helpful for sure. So if you choose to withdraw, but there is no BNT distribution and it is pro-rate, what does this look like in practice, explicitly.

Thank you,

Weston Nelson

2 Likes
5

Data that was used to determine this would help the case.
What % of supply would have been minted in excess of Coinvestment?
What % of supply was being shorted and where that created Adversarial Conditions.
What % of TVL had or was signaling to leave the protocol such that the minting was considered excessive?

1 Like
6

This is point 3:

Withdrawals from V3 remain active, without BNT distribution. Withdrawals are pro-rata with respect to the vault balance in the TKN denomination of the pool token.

For $THALES, the staked balance is “498346” and there is “429504” in the master vault. Meaning that there is a 14% deficit and if you withdraw from this pool then you will roughly be short by 14% THALES tokens. Normally, we would cover the difference to make you whole via $BNT minting but that has been paused since Sunday 6/19 due to the actions taken in this proposal.

4 Likes
7

Understood - thank you for the information.

1 Like
8

I support this proposal.

There is too high of a chance that turning everything back on results in a bank run that doesn’t help BNT LPs or TKN LPs

9

Thank you Glen, I would have liked to see some screens from our internal Dashboards, but seems we have to make due with DUNE for now.

I will be voting FOR the proposal, for obvious reasons.
We just can’t take the risk with how ILP is structured atm to turn it on.
We need to await the Recovery plan from the team where we’re going to expect some drastic changes to be made in the ILP design.

2 Likes
10

The vote as currently structured presents a false choice. Votes should not be orchestrated to provide the illusion of a binary choice in which the only options are political cover or further damage. If the vote passes the team will use this as a shield to say, “well the DAO voted for it”, knowing full well many will not have voted at all.

The against option is a nuclear button. It does not return Bancor to it’s previous state. It puts it into a new, more vulnerable state and would be a remarkable dereliction of a duty of care by the team to put such a vote onto snapshot as-is. The only people voting against will be those who believe they will benefit from the fallout. Given that action was taken on the grounds of hostile action against the protocol I find it alarming that this is an option at all.

Using BIP 21’s terms, reversing the decision in this instance does not equate to reversing the action. Reversing the decision should equate to undoing the harm caused by the action. That harm would’ve occurred without the action is irrelevant: both acting and not acting had harmful consequences to community and DAO members.

As such the AGAINST option should be amended to an action that:

  1. Represents consensus that the action should not have been taken. This is not support for inaction.
  2. Removes the effects of the prior action - with equal care as expected for the FOR vote.
  3. Holds those who took the action responsible for doing so in light of the consensus.

It is reasonable to expect those who pushed for the action to experience consequences, not to consign the protocol to death while they stay in their roles untouched, having delegated their duties to the DAO. Those consequences are better left for the foundation and those employed/contracted by it to decide than the DAO.

Update: Just had a call with Nate, seems like there’s some confusion over what I meant here. BIP21 clause 8 states:

The actions of the operations multi-sig signers must then be ratified with a DAO vote. … The DAO will then vote to uphold or reverse the decision via the normal process.

Note that this refers to ratifying the multi-sig signers actions, and that the DAO votes to uphold or reverse the decision. Some people think reversing the decision means switching everything back on immediately. That isn’t reversing the decision, that’s reversing the multi-sig signer’s actions. Reversing the decision != Reversing the action. Reversing the action (i.e. enabling everything that’s been switched off) should be the ultimate outcome of whatever plan is presented over the coming days.

I’ve identified 3 possible consequences that helped form my view. There are more, but here’s my top 3:

  1. The vote passes, and the nuclear choice is used by various actors to claim this invalidates the vote (which in my view there’s an element of truth to as the vote’s framing influences voting).
  2. The vote fails to reach quorum, everything’s turned back on without a plan (as Nate confirmed to me on the call), and Bancor dies.
  3. Mark’s activist theory holds true: Someone buys a ton of vbnt, stakes it in governance, opens up the mother of all shorts and votes AGAINST.

I was asked what my alternative AGAINST is, and to be honest I don’t have one. As it’s not my proposal I expect to have to come up with one. That’s why I made the 3 original points. I was trying to say what the AGAINST option should consider, not define what it should be.

Given that both implementing a plan and reversing the multi-sig action result in everything being enabled, it would be more responsible to put enabling disabled features to one side for an AGAINST option. That could be held for a vote after the plan has been published and voted on. I believe this could be done so in a BIP21 compliant manner, and would be happy to discuss this probably in a different thread.

My third original point seems to have ruffled some feathers. I made the point on the call with Nate that in a normal fintech company people would’ve been fired after what’s happened. Bancor is not a normal fintech company and firing people won’t resolve anything. So to be clear: I don’t believe heads should roll, that’s just stupid. But the damage is significant, and there needs to be a long navel gazing session at teh foundation after this crisis is over. The DAO/Community should probably be informed of the outcome so that accountability can be seen. What shape that should take should be for foundation to decide, not the DAO.

I said on the call that I expressly wouldn’t want to see people fired because just that’s stupid. There is one condition where my view would change (and it’s just my view, and the DAO has no bearing on foundation hiring). That would be if people employed by the foundation take a deliberate decision that could harm or kill Bancor. If the proposal goes to snapshot as-is and fails (especially under any of the scenarios I outlined) I would consider that condition satisfied, and would expect resignations to follow. I think that’s fair, although I’m sure some wouldn’t.

I encourage the team to look at the responses in this thread. We’re close to turning this around. Do not propose snatching defeat from the jaws of victory, I beg you.

6 Likes
11

Completely agree with your comment. No sane BNT holder would vote against the proposal. It’s like he simply wants the approval without offering alternate solutions. Voting for this proposal implies that all actions were done perfectly. And you can ask the community if this is true or not.

5 Likes
12

This should definitely be considered as an edit to proposal

1 Like
13

I tend to agree. Voting against or not reaching quorum would basically kill the bancor protocol & BNT/vBNT, as well as make all depositors lose 99.9% of their deposited capital. Hence the vote should be structured in such a way that “dropping a nuclear bomb” on the protocol is not an option. It’s in nobody’s interest to kill the protocol by reverting the emergency measures, apart from malicious actors shorting BNT. Either way, the foundation should take their responsibility and not make a proposal that gives malicious actors the chance to kill the protocol & simultaneously steal all its users funds at the same time. Bancor, we have given you our trust. Don’t disappoint us :wink:

3 Likes
14

Good thing that is what level 1 discussions are for, hopefully

2 Likes
15

I see the logic of the vote being a replay of the scenario the protocol was in before the ILP pause.

1 Like
16

Agree with your points Gera.
This shouldn’t be simple vote of die or live.
We need to always take the health of the protocol (= thus the health of the users) in mind.

3 Likes
17

I fully support the emergency action & plan on ratifying this as I do not like deleting money.

1 Like
18

Personally, I think that the proposal (and possibly BIP21) were badly phrased. I think that the ratification (with defined outcomes) is the wrong framing.

I think that after an emergency decision has been taken, then there needs to be a DAO vote. However, it should be more of a “Vote of confidence” i.e. does the DAO still have confidence in the Multisig signers.

As such, after any emergency action, the DAO vote should be something like:

“Was is reasonable for the Multisig to take action at that time?”

Yes or No.

Note, there are a few key things (to me):

  • I’m not asking if the DAO agreed with the action, just whether it was reasonable to do something.
  • Also, was there good reason not to go though a more normal governance process.
  • Fundamentally, do we trust the multisig to act in good faith towards the protocol and BNT holders.

If vote is YES, then the multisig / team / community / BNT holders should work towards restoring the protocol to normal operations (which could be a simple bug fix, pool re-initiation or a more complex situation as we find now). And as the multisig signers have the confidence of the BNT holders, it is natural for them to take the lead.

If the DAO votes NO, then it would depend on the size of the action.

  • For trivial actions, then there may be no major consequence to the protocol management going forward.
  • For major actions, then we could be looking at replacing members of the multisig etc.

However, (I think) neither a YES of NO vote should specify the next actions. Rather, they should indicate whether, the BNT holders need to step up to lead the protocol (in the event of NO vote), or whether they are happy with the current team to continue.

One final point with regard to our current situation, I think that a Simple “Turn it back on” would never be the best action. So we need to review the data, discuss ideas, write code, vote and work together.

A key part of this is the BNT holders saying “we are happy / unhappy that the multisig took an action on our behalf”. However, while important, it’s only a small part of what we need to decide. And simplifying this vote gives us clarity on the dynamics within the community / DAO / BNT holders and team so we can make progress.

2 Likes
19

either way, the discussion and vote are still the same.
was there a real risk to the protocol → the answer is YES.
should the MSIG pause the BNT compensations and prevent from the risk to materialize → the answer is YES.

for this matter, all vBNT holders should really make sure that they vote and vote FOR this proposal.
the alternative is to force the BNT printing machine back online and see the value goes to zero.

1 Like
20

If you believe there should be changes to BIP21, to allow for greater flexibility in ratifying emergency actions beyond “approve” or “revert”, then there should be a new BIP for that.

But BIP21 says that emergency actions require “approve” or “revert” decisions. To conduct a vote now that creates options outside of those, such as “approve” or “approve… and do XYZ” seems to undermine the BIP21 ratification process. Any proposals presenting options outside of “approve” or “revert” the BNT distribution emergency pause should be pushed following this initial ratification vote.

2 Likes