Completed Work
Here’s an update on everything we did last month.
SP Transition
The funding proposal for our new Integrations Team service provider was posted to the forum last week and voting is live on Snapshot now.
A ton of work went into this effort. We estimate that we dedicated nearly half of our June resources to spinning up the new SP, drafting the proposal, and gathering feedback from key ecosystem participants. We’d like to thank everyone who provided input.
We are also actively developing a small vesting contract which will be utilized for our new SP’s contributor BAL incentives. This is derived from OpenZeppelin’s VestingWallet and includes two additional features: a cliff before which no tokens can be claimed, and an onlyOwner clawback function that allows a third-party owner (e.g., the OpCo) to retrieve unvested tokens in the event that a contributor leaves the ecosystem.
Vulnerability Response
Although it is not explicitly included on our roadmap, the Integrations Team is responsible for addressing vulnerability response on an ad hoc basis. Due to the risks present, this is always treated as time-sensitive and given the highest priority regardless of how it impacts the existing roadmap.
On June 24, we became aware of a potential vulnerability impacting certain Balancer pools. Other groups within the ecosystem sprung quickly into action and mitigated the issue by placing pools into Recovery Mode. This means that there are no funds at risk.
Nonetheless, the Integrations Team became involved in the analysis, disseminated information to all potentially impacted partners, and is currently working toward validating all pools individually to determine if protocol fees can be switched back on. There are quite a few pools, and this will take time. We estimate that we spent about 20% of our June resources on vulnerability response and will continue to dedicate time in July.
Engineering
We align all of our remaining work to the May-July roadmap specified in our RFC. This roadmap focuses primarily on Dev UX, a few ongoing partner projects, and engineering services for the Balancer Maxis. The work below is presented in approximate descending order of time spent in the month of June.
Small-scope Engineering Services
Goal: Provide ad hoc engineering services for key ecosystem participants.
Completed work:
- Balancer Maxis
- sDAI Linear Pool feasibility study
- Stafi Rate Provider review (Forum)
- uniETH Rate Provider review (Forum)
- SAvax Rate Provider review (Source Code)
- vETH Rate Provider review (Forum)
- veBalFeeInjector review (GitHub)
- Balancer Grants
- balpy grant review (GitHub)
In progress:
- Balancer Maxis
- ChildChainGaugeInjector review and update (GitHub)
Aave Safety Module Migration
This work was not included in our May-July roadmap but is vital to the ecosystem and has therefore been inserted into the Integrations Team’s priority list.
Goal: Support Aave in migrating the Safety Module from Balancer V1 to Balancer V2. This will bring over $100M of liquidity to Balancer V2, which represents the largest on-chain liquidity for the AAVE token. This move will help generate additional revenue for the DAO.
In progress:
- Code review of the Migrator contract.
- Guidance on best practices for withdrawing and depositing large amounts of liquidity.
BPT as Collateral
This work is directly impacted by the recent vulnerability and has been put on hold as of now. Nonetheless, some work was completed in June, and we intend to continue forward as soon as our comprehensive analysis of the vulnerability is completed.
Goal: Create external demand for BPT, develop business relationships with the lending sector, and improve visibility of Balancer as a premiere AMM platform.
Completed work:
- Preon Money: BPT oracle review
- Sommelier Finance: BPT oracle review
- Sturdy Finance: BPT oracle review
In Progress:
- Aave
- Stable Pool BPT oracle (on hold but almost complete)
- Weighted Pool BPT oracle (in review)
Documentation
Goal: Provide third-party developers with the deep knowledge they need to scale Balancer integrations beyond what is possible with manual partner support.
Completed work:
Example Contracts
Goal: Provide third-party developers with ready-made templates so they can build from 0 to 1 in 1/10th the time.
Completed work:
Strategy
In our recent SP funding proposal, we committed to outlining not just our completed work, but also our forward-looking strategy, in these monthly community updates. We have not yet begun working under the umbrella of our new SP (this will begin on August 1 if our proposal passes), but we would like to slowly adopt this new format in the meantime.
Our strategy takes the form of a list of priorities rather than a list of specific tasks to be completed next month. This allows us to remain nimble but directed as we navigate incoming requests. We will always shape our current work around these priorities in the order that they are presented, and if our overall strategy needs to change for any reason, we will include those updates in these reports.
Remaining Work
For the final remaining month of our engagement with Orb Collective, we remain at least partially committed to the original May-July roadmap. Priorities have predictably shifted since we first published this roadmap, but we still believe that most of it is worth completing, and we will aim to complete it.
A simplified version of the remaining roadmap is presented below. This is compiled from the original roadmap minus any items above marked completed or in the final stages of review.
- Documentation
- Solidity code snippets for swaps/joins/exits
- Managed Pools
- Add/remove tokens
- Circuit breakers
- LP allowlists
- Enable/disable join/exit
- Example contracts
- Custom pools
- BPT price oracles
- BPT as collateral
- Aave integration
- Other ongoing/as-needed support requests
Strategy
After next month, we will no longer have a task-based roadmap to inform our future work. Instead, we will adhere to a list of priorities. These are our current top priorities for the month of July:
1. Vulnerability Response
We must continue our comprehensive analysis of all impacted pools, re-enable fees where possible, and craft a long-term migration plan where not possible. This work will also help to inform our code review processes, as well as documentation around token wrappers, Rate Providers, and Composable Stable Pools.
2. Aave Safety Module Migration
This work will continue into July, and we view this as one of our highest priorities given the potential size of the opportunity. This will bring over $100M of liquidity to Balancer V2, establishing Balancer V2 as the home of the largest on-chain liquidity for the AAVE token. On Balancer V1, this liquidity is not generating any protocol fees, so this migration will create a new source of revenue for the Balancer DAO.
3. BPT as Collateral
We still view BPT as Collateral as a core product area that we want to facilitate. The ongoing vulnerability response will inform how we structure these opportunities moving forward, but we see no reason why they would completely disappear. So, we plan to wrap up our engagements with Aave and other partners, and to then shift focus to the final stage of the Integrations Life Cycle: generalized infrastructure. We can leverage our extensive knowledge of this sector to build official BPT oracles, ensuring that all integrations adhere to the same standard of quality.
4. Code Review Process Revamp
There are lots of code review tasks included in the completed work above, with varying degrees of transparency. Some reviews are published, some are disseminated privately but summarized publicly, and others lack any public trace whatsoever. This is not intentional; it reflects an inefficiency in our current process.
As code review seems to be gaining importance lately, we feel that now is a good time to improve this process. We’d like to:
- Build standard review templates so that all reviews follow the same easily digested pattern.
- Publish all of our reviews somewhere like GitHub and ensure that links to these reviews accompany all relevant proposals (e.g., a gauge vote).
- Establish clearer expectations around how other ecosystem members can request our review, what sort of lead time they can expect, etc.