PR with Payload
Service Provider Name & Overview
Despite the dissolution of Orb Collective, the engineers of the Integrations Team desire to continue contributing to the Balancer Ecosystem. We believe that our ongoing involvement within the Ecosystem is critical in driving both the growth and widespread adoption of the Balancer Protocol in alignment with its core mission to be a platform and not a product. As such, we are seeking support and funding to establish a new, independent service provider, to be known as Three Rocks. Our goal is to continue providing valuable partner engineering services as well as continue to work towards refining and enhancing the Developer Experience of building on Balancer.
Leadership and Team
Our organization consists of four dedicated and talented engineers: Rab, Bailey, Greg, and Mkflow. We have consciously chosen a lean team structure and focused scope of work, which we believe will allow us to operate with maximum efficiency.
Rab previously worked as the Head of Integrations at Orb Collective and will continue to lead the engineering team of Three Rocks. He originally contributed to the Balancer DAO as a community member in May of 2020, and he began working full-time for Balancer Labs in January of 2021.
Bailey, while continuing to provide engineering services to the team, will broaden his scope of work by handling all business-related operations. He has been with the team since November of 2022. Prior to his time at Balancer, Bailey spent the previous two years working on both the business and engineering side of a fast growing automation startup.
Greg previously worked as a Senior Integrations Engineer at Orb Collective and will continue contributing to the Three Rocks team in a similar capacity. He originally contributed to the Balancer DAO during V1 as a community member beginning in August of 2020, and he began working full-time for Balancer Labs in March of 2021.
Mkflow previously worked as a Solutions Engineer at Orb Collective, and will continue providing engineering services to the integrations team. He began contributing to the Balancer DAO in September of 2021 as a Baller, initially as part of the opsSubDAO. He later served as a Board member of the Balancer Foundation and has worked full-time with Orb Collective for the entirety of its first funding year.
Pledge to abide by the DAOâs Code of Conduct
Yes
Pledge to abide by the Accountability Guidelines
Yes
Domains of Operation
Our primary operating domain centers around external integrations. This entails writing and peer reviewing code with strategic partners as well as providing assistance and advice. We also support the ecosystem internally by providing development tooling, contributing to core Balancer work, and advising the Balancer Maxis on technical matters related to DAO operations.
Key Objectives & Success Metrics
The Integrations Life Cycle
The integration pipeline can be broken into three primary, chronological stages: bespoke integrations, developer experience, and generalized infrastructure. Each stage is critical in its own right, but it is important to recognize that these stages represent different points in the life cycle of a Balancer product area. As such, the ultimate goal is generalized infrastructure. Once this is established, the given product area self-sustains; integrations are both well understood and trivial to implement.
The Integrations Team recognizes that generalized infrastructure has historically been overlooked. Throughout the teamâs history, weâve mostly dealt with bespoke integrations, and more recently weâve pushed focus towards the broader developer experience. We believe it is critical for Balancerâs long-term adoption that we take the final step to generalized infrastructure. We also acknowledge that this cannot be tackled prematurely, and so we describe our full approach below.
Bespoke Integrations
In the early days of a product area (e.g., Boosted Pools, Managed Pools, BPT as Collateral), no singular entity possesses full context as to both how the product works and how it will be used in the wild. Third-party developers lack knowledge of how it works, and the core protocol team lacks insight into its future usage. In this stage, bespoke integrations dominate, and a hands-on approach is required from the Integrations Team to bridge the gap.
Developer Experience
As the Integrations Team facilitates more and more bespoke integrations in a given product area, it can start to distill its findings with the goal of enhancing the developer experience. Each subsequent integration should be easier to execute than the last. This stage emphasizes documentation, example code, and possibly additional tooling such as simulations. The approach to partner support becomes progressively more automated as the common ground across various integrations starts to take shape.
Generalized Infrastructure
After a wealth of knowledge is accumulated for a given product area, it is often beneficial to roll out generalized infrastructure to facilitate future integrations. At this stage, the product area is so well understood and its usage patterns so well documented that the generalized form looks obvious in hindsight. Finally, it is time to develop peripheral smart contracts or other tools to approach one-click integrations in the given product area. After this work is completed, the Integrations Team can switch to hands-off as third-party developers now have all they need to build their integrations unassisted.
An example of generalized infrastructure is canonical smart contracts to perform a common task. Consider that each of a dozen third-party teams has developed its own custom BPT oracle to solve the BPT as collateral problem, and all of these implementations display very similar patterns. The Integrations Team is responsible for peer-reviewing each implementation, and so this represents a highly inefficient use of the teamâs time and the Balancer Ecosystemâs capital, not to mention the duplication of work across the entire DeFi sphere. It would be better for the Integrations Team to recognize this trend and ship a canonical oracle contract for this purpose.
The same system can be applied to factories. Consider that a canonical contract already exists, but it is repeatedly deployed with small tweaks to parameters and/or logic each time. If each customization requires a dedicated review, this is highly inefficient. It would be better to craft a factory for this contract which provides the levers necessary for specifying those parameters and/or logic in a safe and self-evident way.
Examples
For illustrative purposes, we present a few known examples of the Integrations Life Cycle in action, some actual and some hypothetical.
| Product Area | Bespoke Integrations | Developer Experience | Generalized Infrastructure |
|---|---|---|---|
| Boosted Pools | Bespoke linear pools, peer-reviewed or developed in-house | Documentation and central linear pools repository for external contributions | Coalescence on the ERC-4626 standard |
| BPT as Collateral | Bespoke oracles, peer-designed and/or peer-reviewed | Documentation and code snippets for developing oracles | BPT oracle contracts or factory, formally audited |
| LST Stable Pools | Bespoke rate providers, peer-reviewed or developed in-house | Documentation on rate providers, some full contracts available | Rate provider factories: Chainlink, LiquidStaking (used by Coinbase, Binance), LayerZero |
Conclusions and Goals
This life cycle, and its culmination in generalized infrastructure, serves to reduce the error surface of external integrations. Even when thorough documentation is available, the same errors show again and again in third-party code, and the Balancer Ecosystem wastes time and capital on manual support. Generalization also reduces the time, effort, and expertise required to launch an integration, thus amplifying the rate of adoption and further saving time and capital for the Balancer Ecosystem.
We believe that the Integrations Team is uniquely suited to overseeing this pipeline from start to finish given the symbiotic relationship among all three stages and the teamâs historical role in the first two. The Integrations Team has always been positioned at the start of the funnel and dealt with a plethora of bespoke integrations but previously lacked a deliberate framework for disseminating its conclusions more broadly and usefully.
With this framework now in mind, we request autonomy to manage the pipeline effectively, including to decide when a given product area is ready for generalization and how that effort should be prioritized in light of demand from partners. On the flip side, we also commit not to over-budget for any one product area or prematurely escalate to full generalization. We believe these were the key failings of the Managed Pool project last year; we prematurely generalized our solution which led to roadmap delays, and we committed too many of our limited resources towards one product area which didnât showcase sufficient diversity of demand.
Vulnerability Response
One of the Integrations Teamâs key responsibilities in the Ecosystem is to maintain contact with all known partners building on top of the Balancer tech stack. These lines of communication are useful for day-to-day interactions but are particularly critical for vulnerability response.
When a core Balancer vulnerability is discovered, such as the read-only reentrancy bug from earlier this year, the Integrations Team must first work with the Balancer Labs Smart Contracts Team to understand the scope of the issue. We then must determine all vectors via which it may impact known partners and discreetly work with partner dev teams to secure their production code. To date, the Integrations Team has helped to secure over $4,000,000 of at-risk funds prior to public disclosure of core vulnerabilities.
In other cases, a partner project may be exploited and set up a war room in which the Integrations Team participates. We help the partner to determine if the exploit was related to a known or yet-unknown Balancer issue and develop a plan for patching the issue.
In either case, vulnerability response is a time-critical function that overrides existing priorities. It is expected that these events occur quite rarely but that when they do, all other work is suspended until all known issues are resolved. For safety reasons, it may not always be possible to communicate outwardly when an incident is in progress, and so some trust - that the Integrations Team will take this responsibility seriously and execute efficiently before returning to other work - is required.
Focus Areas & Goals
In summary, we derive the following core responsibilities of the Integrations Team from the philosophy outlined above:
- Bespoke Integrations
- Q&A with partners in Telegram
- Iterative design with certain high-value partners
- Code implementation with highest-value partners
- Code review for anything to be deployed and used by the Balancer Ecosystem
- Partner projects
- Balancer Maxis projects
- Balancer Grants projects
- Developer Experience
- Documentation
- Code Examples
- Tooling and Simulations
- Generalized Infrastructure
- Medium-term smart contract development
- Formal audits - funds sourced from the DAO on a case-by-case basis
- Vulnerability Response
- Analysis and investigation with BLabs
- Coordination with Partners
GitHub Repositories
In pursuit of the goals defined above, the Integrations Team is directly responsible for the following GitHub repositories:
The team also contributes to several additional repositories:
- Balancer V2 Monorepo
- Documentation
- SDK
- Scaffold
- Various partner code bases
Continued Commitments
For the past few months, we have continued to execute according to the commitment defined in our May-July roadmap. Our goal is to complete all of this work by July 31, and we have already provided an update on our progress for May, with another update for June to follow soon after this proposal. In the event that any work is left unfinished at the end of July, we will carry that forward into our next funding period.
Metrics
Identifying and tracking metrics for success has been a struggle for the Integrations Team in the past. We recognize that this is an important aspect of business that helps the DAO make necessary decisions on the effectiveness of a Service Provider. In order to promote this effort, we outline several key metrics that will enable us to track and report on our organizational performance.
The core on-chain metrics needed to establish a sufficient indicator of Integrations performance are Total Value Locked (TVL), swap volume, and protocol revenue. Tracking these variables for deployments that are direct results of our contributions will allow us to conduct a time tracking analysis that we expect will help us quantify the cost/value proposition of specific types of integrations.
We plan to utilize Dune Analytics to perform this study by tagging Factories, Pools, Rate Providers and other production contracts to which we contribute. For off-chain tools such as Balpy, we plan to monitor volume by inserting a minimal calldata identifier into each transaction. We hope this allows us to get a better understanding of the value added for partner integrations and uncovers hidden areas of improvement to make the integration process more profitable for the DAO.
Additionally we plan to produce vulnerability metrics to highlight the value of funds secured during exploits.
Reporting
Weekly roadmap sync
We will continue to send the team lead to a weekly roadmap sync with other engineering leads and ecosystem leaders. The purpose of this session is to provide internal progress updates, synchronize on strategy, and field incoming requests from other ecosystem participants.
Monthly forum update
We will also continue to provide monthly updates on the governance forum. Though we still intend to use these posts to inform the community on completed work and describe any changes to our internal strategy, we will now focus more on the hard metrics defined above. Our goal is to provide a framework for the DAO to evaluate the teamâs performance.
Length of Engagement & Budget
Five months - August 1, 2023 through December 31, 2023 - divided into two quarters.
The table below shows the applicable expense categories in USDC by quarter, followed by descriptions of their make-up.
Requests for USDC transfers
- August 1, 2023: 125,961 USDC
- October 1, 2023: 180,211 USDC
USDC Budget Breakdown
Previously within this proposal, we highlighted the lean structure of our organization and team, which is designed to alleviate any financial pressure on the DAO. This enables us to have a minimalistic financial outline, as shown above.
Each Engineer on our team operates as an independent contractor, a factor that is reflected in the budget by only requiring the organization to handle a contractorâs base pay. Operational costs are kept at a bare minimum and contain insurance, software subscriptions and tax/accounting services. Because this is a new organization, we also have onboarding costs which encapsulate all startup expenses for the company. These expenses include required insurance down payments, company formation/registration and licenses, as well as branding and initial technology costs.
Legal expenses are not included in our budget, as we are also proposing to be granted a seat on the Ecosystem Council as well as reasonable access to legal support and guidance from GRC resources.
Requests for BAL transfers
- August 1, 2023: 62,230.58 BAL
BAL Budget Breakdown
In addition to USDC, the Integrations Team is requesting 62,230.58 BAL to cover commitments made in previous employment packages with Balancer Labs and Orb Collective. These BAL tokens would be awarded as compensation to current team members on a 4 year vesting basis, with a 1 year cliff, starting from each employeeâs initial employment date in the ecosystem.
The funds will be held in on-chain vesting contracts. These are currently under development, and the source code will be provided at a later date. We are building upon OpenZeppelinâs VestingWallet contract and adding two features:
- A vesting cliff to respect the existing incentive format.
- An owner who is distinct from the recipient. The owner has the power to claw back the unvested balance.
The full amount of BAL tokens will be required up front and used to seed the vesting contracts for each individual contributor. It can be repossessed by the OpCo and returned to the Balancer Treasury upon termination of a contributorâs contract.
Impact on the Treasury
The Treasury currently holds ~4.5M USDC. Funding the Integrations Team for the remainder of FY2023 would cost around ~6.8% of the treasuryâs USDC, which annualizes to ~16%. The 62,230.58 BAL requested in this proposal are currently in possession of Orb Collective and will soon be returned to the Treasury, so the Integrations Team does not require any net new BAL.
ETH Address to Receive Funds
Three Rocks wishes to be funded via the OpCo, whose multisig address is:
0x3B8910F378034FD6E103Df958863e5c684072693
Link to SLA
Three Rocks will enter into an agreement with the OpCo in the event that this proposal is accepted. At that time, we will edit this post with a link to the agreement for posterity.
