What you’re presenting might be correct, it’s a question of who owns the surplus.
If historical migrations would have been migrated along with the respected surplus, rate changes inside the pools could have push pools that are now in surplus into a deficit.
So that’s one way to look at it, but I also heard some arguments against that option, so I guess it all comes down to what other community members think.
If my understanding is correct, the protocol owned surplus remains protocol owned regardless if an 2.1 LP were to directly withdraw w/ no ILP or migrate, it is a separate bucket of tokens that exist in the protocol, created by the LPs who participated.
Thankfully ILP is turned off on both versions of the protocol, so this becomes irrelevant to the decision making process. This is a matter of does the team/DAO find it advisable to break more promises to the LPs, the lifeblood of the protocol, like they did by turning off ILP.
I feel like everyone here is gung ho about attracting new LP deposits to increase liquidity and trading fees… how does one expect to attract new LPs if all terms from the v2.1 are revoked?
As a potential depositor I would look at the previous version to understand there is significant risk to any terms I consent to in v3, if forced migration becomes the only path for v2.1. This is a complete breach of obligations by the protocol, while the LPs fulfilled their obligations.
This is not some minor difference in protocol terms that could be rationalized for forced migration - the terms of IL-specific LP positions vs. socialized IL is drastic. Seeing those terms be revoked would lead any rationale new LP to stay out of the protocol and put their liquidity elsewhere.
2 Likes
Any thoughts about “equalizing” the surplus/deficit between the 2 versions?
1 Like
I’d be fine with it if it took minimal development time. Do you think it would be difficult?
I would be totally fine enabling withdrawals for v2.1 depositors with the following conditions:
- They receive a balanced amount vs V3 deposits (IE equalizing between versions)
- It would take minimal development time to implement
It just seems impractical to create a complex solution to this when - in my opinion - the fairest solution is to migrate all liquidity.
Correct me if I’m wrong but I believe your intention is to maximize the amount you receive when you withdraw (which is totally legitimate).
2 Likes
So I’m currently looking at the proposal to limit on-curve liquidity (all please look it up, really interesting) and it says only v3 has the ability to set a cap on trading liquidity. This proposal is really good imo, especially since it will remove a lot of the exposure to IL. If this gets fledged out and some real simulations show it will work (examples look really promising), I think the whole liquidity of v2.1 should be force migrated! Let me tell you why I think this:
Let’s just look at the technical risks that v2.1 still brings to the table then and forget about whoever thinks what is morally acceptable. (This depends on individual persons anyway) If we let v2.1 coexist without a migration, the fees will never cover the IL that is probably occuring in the meantime. This unmigrated liquidity will supposedly keep taking unlimited IL that will eventuell be dumped into B3 as fresh deficit. (see thedavidmeister comment)
So if I understand this correctly, the v2.1 pools are just a real risk right now to collect even more IL if they get stalled, since they dont have the ability to set a cap on trading liquidity. So the whole liquidity is exposed to possible IL.
5 Likes
Other reasons for a force migration are:
- V3 offers much easier tracking of deficits and surplusses and will greatly improve future data analytics such as simulations. These simulations are important to determine if a proposal will bring the described effect and will be worth putting development time in. With v2.1 still being around I think tracking the IL on their positions will waste preciously needed time, because of the harder way to calculate the IL.
- V3 then being the only version removes unnecessary complexity regarding the finding of possible solutions. Also will greatly improve the productivity and security of developing.
- “All future versions supersede current ones”. So I think it would be unfair for people who already migrated to take a bigger hit than people who didn’t. This especially wouldn’t put a lot of good light on the V3 codebase in the community and would probably harm the protocol longterm
4 Likes
You make some fantastic points.
Given it seems to be the fairest, simplest to implement, and lowest risk - I’m for the full migration.
1 Like
So all in all explained with an example of the LINK or ETH pool. (v3 pools with biggest $ deficit)
- We would limit the on-curve liquidity for v3 pools and migrate all v2.1 positions over. All of the v2.1 positions would be net positive capital, because it won’t be part of the on-curve liquidity in this case. This would give us a lot more off-curve capital that has no exposure to IL and could be utilized to native staking (3-5% APR).
- This would be a win & win situation for every LP and the protocol because it will fill the deficit faster. If we however let v2.1 liquidity withdraw, this capital is missing to generate revenue and thus v3 LPs will need much more time to get compensated and the protocol also needs more time to recover to a healthy state
3 Likes
None of these points actually address the moral question though.
If it’s just about “most practical” you might just as well suggest all depositor’s funds are simply slashed to match the deficit. It doesn’t actually do anything to make anybody whole, but it is “more practical”.
I don’t think that practically should be the main goal here.
4 Likes
Please explain how it is a complex solution to honor the terms v2.1 LPs agreed upon to participate? This is essentially just the protocol performing its obligations. This is a breach of the smart contract terms between LP and the v2.1 protocol.
Equalizing the deficit doesn’t make much sense to me because it is gaming the two systems. The v2.1 LPs never consented to socializing IL, hence why they have not moved their capital. Equalizing is forcing socialization of IL, and breaking the protocols obligations.
The most important thing is saving face both externally and internally with LPs who believed the protocol obligations would be fulfilled if Bancor ever wishes to attract new LPs.
DeFi was supposed to be about trustlessness- being able to trust the code as the facilitator of the obligations between counterparties. Unfortunately, the solutions of equalization of deficit and forced migrations to a completely different system design inherently put the need to trust back into the equation. This is a step backwards, not forwards.
5 Likes
I would support a migration of all liquidity from v2.1 to v3 after reading the comments here. It’s the implementation with the least path of resistance and puts everyone on equal footing. As I have mentioned before, I have trust that the Bancor DAO will do what’s best for the protocol and ALL its users.
2 Likes
Agree with alphavalion above.
It gets very complicated if you try to treat v2.1 LPs differently. Since many v2.1 depositors were told they need to transfer to v3 after the ILP pause in order to be eligible to withdraw.
If you give current v2.1 LPs special treatment, you’d also have to give v2.1 LPs that migrated after ILP Pause annoucement similar special treatment. Which opens up a can of worms for others to get special treatment, etc.
1 Like
Regarding breaching the expected terms → this ship sailed when the DAO turned off BNT minting. Now we need to be fair & practical.
I don’t see a reason why it would be fairer for v2.1 LPs to be able to withdraw more than v3 LPs, therefore equalizing is the only fair solution. The only reason v2.1 LPs would be able to withdraw with no IL right now is due to the surplus generated largely from V3 LPs. Because the simplest way to implement equalization is likely to just migrate all liquidity - that’s why I’m in favor of it.
I disagree that the most important thing is saving face. I think the most important thing is doing everything we can to fix our current situation - this is why I want any solution to take the least amount of development resources possible.
7 Likes
I agree that saving face shouldn’t be a criteria now, the only way to do that is to roll out solutions that could make LPs whole again.
We should go with whatever is the easiest to execute so that the team can focus their tech/engineering bandwidth on the solutions instead of giving v2.1 LPs special treatment. Also agree that the v2.1 LPs who migrated already, would also want some special treatment. Better to just do this once and for all.
-
I’m not sure about the actual technical expense for letting v2.1 LPs withdraw, but I’m quite sure it is much much more work than a migration. You would need to keep different scenarios in mind, if you atleast want to make it a bit fair. What about the people that have migrated to v3 or the ones that still were in v2.1 after the announcement and only migrated to withdraw? This just opens more issues that need to be solved and implemented. (And this of course needs much needed time)
-
Also I would go as far as saying that letting v2.1 LPs withdraw directly will damage the protocol hardly, especially shortterm. You miss out on a lot of off-curve capital that can be put to work elsewise and would greatly improve protocol health. Not even mentioning the damage that is done to the V3 protocol (future of Bancor) image within the community. Kinda would feel like a slap in the face for a lot of people who believed in V3.
2 Likes
The ship actually didn’t sail w/ turning off ILP… that was approved in BIP21: " 7. The DAO isn’t allowed to intervene with the withdrawal of funds, save for the adjustments to the protection mechanism."
All solutions to fix the current scenario require a massive influx of liquidity or an external entity bailout.
Saving face is important in this context, as the protocol needs to prove through its actions that it can fulfill its obligations to LPs in the hopes of ever attracting new liquidity. Without new liquidity we don’t get out of this situation. I find it hard to believe new liquidity will ever be sourced with moves like this. No rationale individual would trust this protocol with their money.
In regards to your comments about v2.1 tapping into the surplus to achieve no IL - this is false. An LP would only be able to leave w/ no IL depending on the their time of deposit vs current TKN/BNT price, this is the position specific IL design of v2.1. The surplus is owned by the protocol. It’s one of the biggest flaws of v2.1, LPs don’t get to share any upside on the surplus created, like one would as an LP in a standard dual-sided AMM.
3 Likes
Replying to your comments:
-
I would argue this isn’t intervening with the withdrawal of funds. v2.1 LPs currently need to migrate to v3 to withdraw anyway.
-
Only immediate solutions require an influx of capital or a bailout. Long-term technical solutions do not.
-
Regarding saving face - I think it would be foolish to waste weeks to months of precious development time to look -slightly- better right now. The DAO needs devs working on solutions, not appeasing a specific segment of users who are incentivized to withdraw and can’t feasibly consider coming back until the protocol has recovered from the deficit.
-
Regarding the v2.1 positions being calculated differently - I see what you’re saying here. It seems like it would take a lot of work to change the contracts to create a solution that would let v2.1 LPs withdraw from v2.1 though. At the end of the day, the DAO would be dedicating a ton of resources that can’t be spared right now to create a special solution for users who are leaving the protocol. It just doesn’t make sense.
I really get where you’re coming from - but it seems like the easiest solution is likely also the fairest.
4 Likes
having everyone migrate to v3 is the right thing to do, and this should be the first fix that gets implemented.
it will help by reducing the majority of the deficit, will help give a better understanding of bancors current true state and will make the issue at hand significantly easier to manage.
A good chunk of the reason why we are in this mess is because of the users who remained in v2.1. I hope that the developers update the v2.1 portfolio page and help those users realize that they do no longer have ILP and that their positions have also been just as negatively impacted by the recent events as the v3 users.
It’s important for us all to get on the same page so that we can tackle this problem easier and faster.
5 Likes
hey everyone, here’s a snapshot of the current state of surplus/deficit from 2 days ago, that can be used as data point for this discussion -
4 Likes