Proposal: Move v2.1 liquidity to v3

Community Chatroom (DISCUSSION)
192

That’s not acceptable, because for a lot of LPs, their opinion in vote#1 would depend on the outcome of vote#2.

I propose instead to vote on what the user @infoparity has proposed 10 days ago in Proposal: Move v2.1 liquidity to v3 - #172 by infoparity

In more detail, I think we should

  • open withdrawal for 2 weeks on 2.1 without IL protection, i.e. each v2.1 LP will be subject to their individual respective IL
  • close withdrawals
  • migrate remaining v2.1 liquidity and all of v2.1 surplus to V3

Vote FOR: accept above steps
Vote AGAINST: remain status quo

edit: as others have rightfully pointed out, a force migration of V2.1 to V3 is a very sensitive topic and should be voted separately.

1 Like
193

If we just close v2.1 withdrawals forever after the 2 week period, what’s the point of voting on a force migration? v2.1 LPs will be in a situation where they either migrate and get access to their funds, or leave them in v2.1 forever getting 0% fees and not having access to their principal, which is equivalent to completely losing it. In that case forcefully moving it would be beneficial both for them and the protocol, as they would get 10% fees in V3 and their position would help the deficit.

194

There is transparency that voting FOR in Vote #1 will conclude with Vote #2 being the next logical evolution. Whether or not it’s acceptable would be judged on the merit on Vote #1 meeting quorum. Your counter proposal is targeted toward binary acceptance of the ‘sunset clause’ being enacted. Given how many competing opinions there have been in this thread (now nearly 190 postings), the logical cascade I’ve presented will allow people to have their voices heard and we can be done with this.

195

Assume in your proposal vote #1 fails and vote #2 passes, what would you do with the remaining surplus of V2.1?

196

Let’s vote for #1 and get bancor back on track, no more bank runs.

197

To be clear on the proposed “allow v2.1 withdrawals without IL protection”:
The withdrawn amount must be subject to Impermanent Loss, and Impermanent Loss only.
Example:

  • LP deposited 100 LINK on August 15, 2021 at a price of $27 per Link
  • The protocol matched with 635 BNT at a price of $4.25 per BNT
  • Current price of LINK is $9.
  • Current price of BNT is $0.60
  • The pool currently consists of 65 Link and 974 BNT.
  • According to multiple resources, e.g. Impermanent Loss Calculator (Examples + 3 Versions) - WhiteboardCrypto or Impermanent Loss Calculator, the Impermanent Loss in this case is around 8.5%.
    The IL is not 100 - 65 = 35 LINK. The 35 is the token fluctuation due to the nature of tokens being traded in the pools.

1
1715×865 58.7 KB

As such, why don’t we make a compromise where v2.1 LPs take a cut, thereby increasing the v2.1 surplus which will then be used to reduce v3 deficit? I propose to vote on:

  1. allow V2.1 withdrawals without IL compensation for a period of time (by IL I mean true IL according to above calculations.) Average IL would be ~12%, I assume.
  2. This grows the v2.1 surplus by +12%.
  3. after said period of time, move the grown v2.1 surplus to v3
  4. in a second vote, the DAO could then decide to possibly force all v2.1 liquidity to v3.

What about numbers?
According to the analytics presented by @yudi on July 15 in Proposal: Move v2.1 liquidity to v3 - #41 by yudi, the v2.1 link vault has a surplus of 97%. Assuming withdrawing v2.1 LPs accept to swallow ~12% IL, the surplus will grow to ~109%. Transfering these Link to the v3 pools will reduce the V3 deficit from 46% to 31%.

Benefits:

  • v2.1 LPs suffer a fair IL, which even grows the surplus that will be moved to v3.
  • reduce V3 deficit instantly to 31%
  • avoid socializing debt
  • burn BNT equal to v2.1 TKN withdrawals, thus stabilizing the BNT price
1 Like
198

I’ve tried to incorporate your comments and idea into my vote hierarchy. Here is my revision.

Record of Revision:

  • Added ‘fail to meet quorum’ pathways.
  • Removed ‘current status quo’ from Vote #1 Against given it initiates a follow-up vote which could open withdrawals from 2.1, which is not the status quo.
  • Explicitly added that 2.1 withdrawals are to incur IL and that migration will occur after the one week sunset clause.
  • If migration is voted to not occur yet 2.1 withdrawals are opened, surplus is stated to explicitly stay with 2.1 until further deliberation is had.

Vote #1:
FOR = migration of 2.1 (surplus + positions) will occur;
AGAINST = migration of 2.1 (surplus + positions) will not occur.
FAIL TO MEET QUORUM = no further action taken.

IF Vote #1 passes (and meets quorum)—
Vote #2:
FOR = migration of 2.1 (surplus + positions) will occur instantaneously and current deficit is socialized;
AGAINST = migration of 2.1 (surplus + positions) will occur with a one week sunset clause – withdrawals will be open for a one week duration with an explicitly announced start/end.
2.1 withdrawals are subjected to impermanent loss. After one week, remaining surplus and positions are migrated.
FAIL TO MEET QUORUM = invalidates Vote #1.

IF Vote #1 fails (and meets quorum)—
Vote #2:
FOR = 2.1 is open to withdrawal without delay, other than implementation; 2.1 withdrawals are subject to impermanent loss. Surplus remains with 2.1 for the time being.
AGAINST = 2.1 remains closed to withdrawal without first migration to v3 [status quo].
FAIL TO MEET QUORUM = invalidates Vote #1.

I think this presents us with the competing alternatives as four separate options captures as FOR/FOR, FOR/AGAINST, AGAINST/FOR, and AGAINST/AGAINST [status quo].

I’m trying to keep it as simple as possible.

199

uh, no just move it all over to version 3 and focus on saving bancor

200

Can someone explain to me why any action that breaks end user agreements and the upgradeability clause is something that is actually being discussed as a potentially going up for vote?

One sensible reason would be that it helps v3 recover (like halting ILP did), but this has already been disproven.

We are therefore left with two reasons:

  1. Rekt LPs who aped into v3 want all LPs to suffer as they have, even though they took excessive, uncalculated risks. Only a miniscule percentage of that pain will go back into the pockets of v3 voters, but they will still take it if they can.

  2. Members don’t want devs to allocate any time to solving a technical obstacle, because time is a precious resource right now.

Are we really going to act as if there won’t eventually be a point in time in the near future where devs CAN afford to allocate time to solving this relatively straight-forward challenge? It’s not as though the protocol will suffer when time is temporarily allocated to updating contracts to re-enable withdraws - which as has been prevously stated, is basic functionality of v2.1

So again, I ask, what is the reason some feel it is acceptable for this to go to vote. Yes, we know there is a disagreement about the forced migration issue - but why? Why do some users feel it is appropriate for this to go to vote? Is it because reason #1, #2, or #3?

It is my opinion that reason #2 constitutes the majority. Instead of admitting this fact, focus has been placed on inflating reasons #1 and #3, even though it is clear that these are not valid.

Just because there is disagreement on a topic doesn’t mean it should go to vote. Ordinator’s test case of stealing from the top 5% wallets has clearly proven that out. Why then, is this any different?

Socializing losses directly benefits the majority of users, as the majority of users failed to realize the shortcomings of v3 and got rekt. Further, it is also in their interest to define this as a “Bancor wide problem and not a v3 problem” even though it is clear that unlimited staking in v3 is what exacerbated this mess.

V2.1 users did not consent to v3, and per the Upgradeability Clause (which HAS ALREADY been voted on by DAO) CAN NOT be forced to migrate without a withdraw option, regardless as to what some members would like. The only thing that could possibly override this is if such an action could save the protocol from a death spiral (like pausing ILP did), but this has already been disproven.

So why are we still talking about this as if it’s reasonable proposal? A vote to migrate the surplus is fine…it belongs to the protocol. The LP positions being force migrated with no withdraw option? Not fine. Force migrations after a 2 week withdrawal window? Hardly reasonable but an acceptable compromise.

Michaelbanar’s vote hierarcy needs to be revised once again to reflect this.

3 Likes
201

appears to me that technically it is in fact possible for the DAO to decide on this, making your “CAN NOT” just a moral opinion.

either way, i’d suggest adding another option into the vote hierarchy dealing with whether to move surplus only or surplus + LP positions.

additionally, rather than increasing the possibility of having nothing happen in the end by making subsequent votes failing to meet quorum invalidate the first vote, establish a standard on the first vote with subsequent votes fine-tuning the details. so in case of my addition-suggestion above, that’d mean for example the first vote by definition moving the surplus only and a subsequent vote dealing with whether or not to move LP positions as well. same thing for a potential X week withdrawal window.

the other proposed vote (the one in case the first one fails and meets quorum) can also exist independently, and could just be pushed to vote in sequence after the votes regarding migration are dealt with. combined with the other restructuring i proposed, a possible scenario for example would be having it run even if the first vote goes through but a subsequent one fails, leading to only the surplus being moved over in the end.

202

Yes it should be easily possible to force a migration. The DAO has control over everything protocol related kinda. Also the Upgradeability Clause has been disproven many times by core contributors, so not sure how people can still base their whole argument on that

203

I am also baffled as to why we - in a DEFI forum- even discuss touching the coins of other users. Have we forgotten what DeFi especially (and crypto as a whole) stands for? I tried to outline my opinion on this in Proposal: Move v2.1 liquidity to v3 - #187 by xrx
Doesn’t v3 come with significant other terms than v2.1? How can these terms be forced upon anyone? The DAO doesn’t have unlimited rights over the participants of the protocol.
Why don’t we vote to seize all funds of xy and distribute them to everyone else? Everyone else would surely have more voting power than xy. Or make a new contract that applies a daily 10% tax on all assets. We could then vote to move xy’s coins into this contract.
To be clear: this speaks about LP positions, not the surplus. Even though I argue that simply moving the whole surplus to v3 wouldn’t be fair either.

3 Likes
204

@Ree

The DAO has already voted on the upgradeability clause. Why would we consider something that works directly against it, unless, again, it is something that would save v3 from a death spiral OR provide significant recovery to v3. It does neither!

@Omegagrey777

It was not the sole justification provided in my post, but ok, let’s roll with that anyway…

The upgradeability clause is clear. Where have the contributors disproven it? Are you referring to Yudi’s claim as to a potential “typo”? If so, that claim does not align well with the very specific language that is used in the upgradeability clause. For more specifics, I suggest you re-read #105 by LoverPlaid.

2 Likes
205

Can you explain what you mean by unlimited staking in v3 is what exacerbated this mess?

206

Yes i was referring to no deposit limits in v3 and instant ILP giving rise to more ILP payouts, further tanking the BNT price which was already in a bearish downtrend

1 Like
207

I strongly oppose forcing v2.1 LP’s into v3 for the reasons @JFN88 and @xrx stated. It is not something the DAO should have authority over and it would destroy all remaining trust in Bancor.

1 Like
208

The ILP was just one part of the issue. Blaming it on V3 when v2.1 printed tens of millions of BNT in LM rewards is unfair. Allowing v2.1 LPs to dodge all responsibility for this is unfair.

Both versions are to blame.

209

This clearly shows a complete lack of understanding of the protocol and its mechanics. Bancor v3 did not exacerbate any mess and any issues that were present in v2.1 were also present in v3 (including any apparent deficits and surpluses across the protocol).

  1. No deposit limits in v3 does not mean that all tokens that are contributed to the protocol are exposed to IL or token rebalancing. The Bancor DAO voted on the pool limits as part of the v3 launch for all pools

these limits exist to determine how many tokens are made available for trading (i.e. matched with BNT). Once the BNT is exhausted, any token contributions are no longer made available for trading but they rather sit in the vault unused for now. The limits for the pools in v3 were all carried from v2.1 so there was no change there.

  1. Instant ILP was not quite “instant” as this carried a 7 day cool down when the printer was enabled. Furthermore, this is not an attack vector against the protocol as 7 days was a number chosen to prevent insurance abuse from occurring:

A 7-day Cool-Off Period

If an attack vector exists, either discretely or abstractly, its frequency and potential damage can be effectively nullified with the introduction of a mandatory waiting period, prior to the withdrawal of user’s funds. Compared to the current 100 day vesting period, a 7-day cool-off represents an effective drop of 93% in mandatory wait time prior to full protection. In context, the additional prudency still affords users an improved offering, without conceding any vulnerabilities to the system.

One can make the argument that without the 7 day cooldown being enabled that the entire protocol would have been REKT due to instant withdrawals in v2.1 and not having a 7 day queue to assess the situation. Lastly, it has already been mentioned previously in this thread that this is a protocol wide problem and not a v3 specific problem by a lead developer:

I suggest a complete read of BIP 15 and this entire thread before any further bold claims.

1 Like
210

How can anyone believe that the implementation of v3 did not cause more users to be exposed to IL than what would have been the case with only v2.1?

Further, you’ve stated yourself that v3 users could withdraw with ILP after 7 days. That’s 14x faster than permitted under v2.1’s 100day vesting schedule.

Lastly, exacerbation means to worsen an already negative situation, not to be the sole cause of. I really don’t understand how there is an argument about whether or not v3 made matters worse, for the reasons above.

211

@JFN88 @VictimBurner I thought about this discussion for a while and I had to come to the conclusion that it seems impossible to transfer a fair amount of v2.1 surplus to v3 as long as their are still LPs in v2.1 pools. That is because we cannot calculate a “fair” amount of surplus that should have been migrated with LPs migrating. Even more now that some of these LPs have left the protocol. How would we determine the surplus which has to stay in the v2.1 pool?

As such, what do you think of forcing v2.1 LP into v3 after they had a sufficiently long and fair chance to withdraw from v2.1? With said forced move, one could also move all surplus to v3 and be finally done with this.