Migrate the AAVE/WETH aBPT Safety Module to Balancer v2.
There is currently ~$370 million staked in the Safety Module in the form of AAVE/WETH 80/20 aBPT on Balancer v1. This recently passed proposal allocated 12,500 BAL per week to this pool until September 20th, after which the rewards may be removed at the discretion of the Balancer liquidity mining committee. Migrating the AAVE/WETH pool to Balancer v2 will enable access to the new features of v2 and make it possible for the liquidity mining committee to potentially continue allocating BAL rewards to aBPT stakers.
Balancer v2 brings a myriad of advantages and technical innovations compared to v1. The most pertinent ones to this discussion are significantly reduced gas costs on trades, more trading opportunities thanks to the Vault architecture, and more visibility on the new v2 interface. It is reasonable to expect an increase in TVL as users will be able to easily find the pool and see accurate reward calculations. It’s also likely to see increased volume/swap fees as more trading opportunities will be available due to the Vault’s gas optimized multi-hop capability.
A new two-token oracle pool could be created on Balancer v2 with the help of Balancer Labs. The specifics of how the migration will take place requires some input from the Aave dev team so this can be fleshed out in the future as discussion evolves.
Note: I am here as a Balancer community member and not part of the Balancer Labs team. Happy to answer any questions about this though
Fully agreed - right now v2 is live and the fact that AAVE is pointing to a v1 Pool is confusing and is forcing the Balancer side to split their incentives between v1 and v2 when they are trying to encourage more people to move to v2. If the security of v2 smart contract is concerned, I say we get all the details ironed out NOW and then both set’s of code changes will have plenty of time to be looked at.
This is for sure something that needs to be handled although i think we should iron out the security concerns around the vault model being used in balancer V2. Balancer V1 provided isolated pools that, while i agree offer less flexibility and capital efficiency, have for sure a smaller attack surface.
There is certainly a larger attack surface in Balancer V2, but it has been audited by three reputable firms who all concluded that there is no issue in the proper segregation of asset ownership across pools. Balancer V2 has over $700M in TVL today and we’ve had a $2M+ bounty up for the last three months, and no one has emerged to drain the Vault and/or claim the bounty. What exactly are your concerns and how do you intend to “iron them out”?
By the way, not trying to be defensive at all, just want to understand what it would take to alleviate security concerns. The typical answers are audits, bug bounties, and time. Is time (Lindy effect) the issue here, or is it something else?
If it’s helpful at all, here is some info about the Balancer V2 audits and bug bounties (none claimed yet):
Just wanted to give this a bump to see what next steps are, or if there’s anything more I can do.
How can we bring this up to date? Moreover there is no more $BAL reward on v1 pools, a migration on v2 will allow to get rewards again
@kwizfreak I’m involved in the development of a migration solution from the community.
From now, is still a work in progress, and considering that the migration should not cause liquidity disruptions, the amount of funds deposited and the need to pass a long-executor proposal, it will still need a bit more time to be ready.
Oh great thanks a lot! Can’t wait to see it when it’s available :)
Hello everybody. One of the tasks included on the development scope Aave <> BGD Labs was the migration of ABPT/stkABPT to Balancer v2, discussed on this thread.
We are glad to announce that this particular task is part of the initial priorities, and there will be more detailed updates in the following 2 weeks.
You can check out more details about the initial steps of BGD on Aave HERE
Great to hear! The Balancer team is here to help in any way we can.
Hello community. Related to this thread, we had published a more detailed execution plan of this migration.
You can check it out HERE. We really appreciate your feedback