What I’m stating is that there is no code that let LPs opt-in on upgrades.
The only code that allows anyone to opt-in on upgrades is owners on converters.
Regardless of the readme file.
Just facts, not opinion.
The easiest implementation will require a contract upgrade (the app relies on contract functions that have stopped working when BNT distribution was disabled).
So just FYI, still of course doable.
1 Like
Understood. Both my statement and your reply to my statement are correct.
For clarity, I was replying to your specific comment on the paragraph pertaining specifically to the converter, not your following comments regarding the code mechanics.
I mean that the v2.1 surplus is not going to be taken by the LPs if they leave the v2.1 pool. The protocol keeps it. But the v2.1 LPs should be able to leave with their full amount of tokens if their pool is in surplus or according to the haircut given by v2.1.
1 Like
I’m sorry but the wording of that paragraph in no way lines up with this claim of it being a typo.
It specifically states “systems can be upgraded via new version releases, and token owners can decide to stay in the old system, or move to the new one”. “Staying” and “moving” does not sound like terminology used when describing a contract update.
Apart from that, like Infoparity mentioned, this paragraph is on the landing page of legacy repo from v2.1. Why would it relate to a specific subfolder?
2 Likes
I am not looking at the portfolio page but at the google sheet that Yudi sent around showing the deficits and surplus of the pools. I know how IL works and I know that ILP was shut off.
This statement is not completely correct. Here is a break down:
-
The surplus is not claimable by any existing 2.1 LPs when they withdraw. This is verifiable as users who migrated from 2.1 to 3 after 6/19/2022 migrated 100% of their deposit, not 100%+ (implying surplus moving).
-
The surplus is protocol owned. This can be proven through the smart contracts, audit reports, and basic logic. If BNT is over-performant to TKN in a pool, the internally injected BNT (synthetic BNT) that takes the other side of TKN deposit is in deficit, as BNT was rebalanced into TKN. Therefore the protocol owns the surplus TKN.
-
V2.1 LPs should be allowed to opt-out of the v3 upgrade with a withdrawal with IL-specific to their position. Just because the pool is in surplus does not imply that every LP has no IL. This is dependent on the performance of TKN vs BNT at their time of deposits.
1 Like
I’m simply explaining how the code works, which I think is more important than the readme file, regardless of who whatever statement serves.
The smart contract defines the logic - I wouldn’t put so much emphasis on the terminology of a readme file in a codebase, as the code defines the logic.
And the option that LPs can opt-in to upgrades simply does not (and never did) exist in the code.
I think you are making the argument that smart contract logic is law, but that is not how it works. The intent of the parties to the contract are what matter. And the readme file clearly lays out the intent with regards to upgradeability and clearly lays out that the Token owners have the choice.
By that logic if a Masterchef contract contains a migrator function which can rug all LP funds, then it is completely legal for that to happen. That will never hold up in a court of law.
1 Like
I’m not very good at reading smart contracts, I’m really good at reading words describing their functions and the conditions of using them. I’d say the readme exists exactly for that purpose, hence the other paragraphs about language, and the disclaimer about it being a work in progress.
But I understand your point.
1 Like
Yup, you’re right. But I also say that the specific readme statement does refer to the opt-in upgradeability by the pool owner - that was the intention and that was the design.
After thinking on this, I don’t believe your statement is correct.
There clearly was code for opt-in and opt-out per the Upgradeability Term for Token Owners:
- withdraw function from v2.1 [opt-out]
- migrate function to v3 [opt-in]
Now the only option is opt-out (forced migration).
3 Likes
That “pool owner” vs. “token owner” typo really doesn’t make sense in the context of the rest of the paragraph.
This is v2.1 → v3 migration, not upgradeability.
After a lot of thinking about this, I think the only fair path forward is a complete migration.
Why not enable withdrawals from v2.1
If we reopened v2.1 withdrawals with migrations to v3 still possible, it would be extremely unfair for v3 LPs. This would give v2.1 LPs the ability to select whichever option is most profitable for them at the expense of v3 LPs. If they received more by withdrawing from v2.1, they would take that option, otherwise, they would migrate at the expense of v3 LPs.
Meanwhile, if we were to disable migrations and enable v2.1 direct withdrawals, many LPs would receive far less than if they migrated.
Importantly, only a small group would benefit from reopening v2.1 withdrawals. I analyzed the expected withdrawal amounts for LINK, the pool with the largest surplus in v2.1. I calculated the expected amount of withdrawal based on deposit date as v2.1 tracks individual positions, and depositors on roughly 62.66% of the days elapsed in v2.1 would be worse off withdrawing from v2.1. For depositors in 2021 it’s even higher - roughly 68% of deposit days would be better off migrating.
Note that this analysis is not perfect as it’s not looking at individual positions - just expected IL/loss per day. You can see this here: LINK Withdrawal % by Date - Google Sheets
Summary
I don’t see a viable alternative to full migration.
- Reenabling withdrawals from v2.1 is only beneficial for a small group of LPs.
- If we enabled withdrawal but keep migrations open, it would actively harm v3 LPs
- If we enabled withdrawals but removed migrations, it would actively harm many v2.1 LPs.
5 Likes
It’s the other way around: you’re proposing to improve V3 LP’s position at the expense of V2.1 LP’s. Currently V2.1 LP’s that would benefit from migrating already have that option, so this action would not limit that possibility. You should be advocating for migrations not being possible at all if you want to limit that issue.
Considering your points, I still believe it would the most fair option is to let anybody that chose not to migrate to V3, for whatever reason, retain that right and either withdraw from V2.1, or migrate, at their own accord.
1 Like
I’m fine with either option - v2.1 withdrawals open but migration closed, or a full migration.
I’m not ok with both withdrawals and migration open at the same time, since it would come directly at the expense of v3 LPs - giving v2.1 LPs a distinct advantage.
The problem I have with opening v2.1 withdrawals (and closing migrations) is that it results in a much worse outcome for a lot of v2.1 LPs. It would be much better for v3 LPs.
2 Likes
So my high-level solution was just playing it by the book and not breaching the upgradeability terminology of v2.1 that could serve as determining factor to those 2.1 initially depositing (this clause greatly reduces perceived risk of having the option to opt-out/in of new versions). Totally understand how this can be highly controversial.
My personal opinion is that since its been over 1 month since forced migrations were enacted, and now all fees are being burned, that the actions of v2.1 LPs staying in leads me to believe it is an actionable show of intent to opt-out.
This is where I personally sit, I am actionably not consenting to v3, seeking the protocol to enact my opt-out right, and forgoing any future upside that may occur from upgrading to v3. I can’t speak for any other 2.1 LP, but I am not sure why one would stay in a protocol that is providing no fee generation opportunity to try and game the v2/v3 upgrade migration.
2 Likes
The windows is already open though, there is no solution to reversing the people that already left v2 pools to profit off v3 pools.
Yeah, but thats is not the fault of the v2.1 LPs. It was a temporary measure so as to not block withdrawals. We need to allow withdrawals from v2.1 and block off migration simultaneously. As the author of this post mentioned, this is the most ethical option. Given everything that transpired, we need to uphold our word. Failing to uphold our word for 100% ILP can be seen as acceptable due to the death spiral. But in this case, there is no death spiral. Allow people to withdraw without migrating. We are currently just trapping LPs and dangling carrots or threatening further haircuts to them. So many things wrong with Bancor right now on so many levels. Plus we got the lack of revenue issue which threatens all of us.
2 Likes