[BIP-352] Funding Proposal for the Integrations Team (Three Rocks)

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


Pledge to abide by the Accountability Guidelines


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.


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:

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.


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.


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:

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.


We had some nice chats with Rab, Bailey, and Mk. They’re a great group of guys with their heads on their shoulders. I support this proposal.


Hello! Thanks for your proposal! It is visible that it was well-thought and already provides much information.

My comments here are related to metrics/budgeting/planning:

In your previous reports, there was some discussion about metrics and deliverables. While it is understandable the nature of your process/work requires space for adjustments, I believe it would be beneficial for the team and the DAO if it is possible to present something like a visual roadmap / Gantt chart where we can see when the deliverables are planned to be finished/deployed, in addition to the proposed schema.

Preserving the team autonomy to decide how much time, the prioritization and other relevant management aspects of each deliverable, it is understandable that DAO members want to have an idea of what is already in the pipeline and what the plans are for the remainder of the funding period. For example:

  • How many code implementations with partners are you guys doing now? What is the current pipeline? How much time do you guys plan to allocate to this task in the period? Does that take into account the expansion to other chains?
  • The same applies to the Generalized Infrastructure item. Is there any specific project in the works already? What is the time allocated to this “vertical”?

This type of information gives reassurance that a plan/budget was made, even if afterwards, in the monthly reports, we will discuss adjustments in this longer-term plan.

I want to make clear that this is not an attempt to micro-managing the SP, but rather a request to have a better understanding and clarity of what the roadmap/plans/time allocation looks like.


Ehy gm, I’ll be quick and do some napkin math on the budget.

We are talking 60k/m for 4 devs. AKA 15k/m per dev.

In my knowledge this is not a cost savvy amount, but also kinda inline with senior dev work. Especially considering we are talking of mostly (all?) people who have already worked in the Balancer ecosystem, I would gladly pay the overhead to retain this experience.

So, to me, good budget. As long as the team delivers, we should all be good :slight_smile:

First, this looks like a well thought out proposal. Glad to see the integrations team made it well through this restructuring.

I’m reasonably certain that the Maxi’s are the primary/only user of balpy. In cases where we are not the user, we’re in direct contact/advising those who do in almost every case.

We’ve been working a lot to build tooling in both Python and Javascript, and have started also building libraries to handle looking up information about addresses and action_ids in the Balancer Ecosystem.

It would be great together to move balpy and much of the off-chain tooling into some state of mutual support/development between the integrations team who have a lot more available senior dev time, and the Maxis who are using/building this stuff on a daily bases. The Maxis have a very deep understanding of requirements and scope as well as UX considerations around various operations and tooling.

One great example of this is adding new chains. It would be best, if we could make one update to a source of truth and have all our tooling be aware of and able to operate on a new chain we decided to deploy on. Right now we update our address book, and have to make a few patches in other scripts. We’re working to eliminate the need for these extra changes.

Then if we want to use balpy, it’s another reasonable change that looks quite different from all the other changes we made. These get made in forked repos, and the changes are either never submitted back to fork, or likely not accepted because they don’t match the current coding styles/patterns of balpy. Maxi’s work in timeframes that are often days not weeks, so it’s good to be able to extend things in expected ways “system-wide” without having to wait for resources to change/review various repos around the ecosystem.

I think we’ll get more bang for our buck working together to build/connect tooling to our partners than we will trying to find ways to track usage after the fact by packing some sort of tagging into the these tools generate.

Look forward to working together on this over the coming months :slight_smile:

1 Like

To keep these engineers is a no-brainer IMO, fully supportive


This is a team of talented professionals who are collaborative team players.

They care about Balancer’s success. They spend a lot of energy helping outside devs building on/with Balancer, which is core to the growth strategy.

They’re extremely knowledgeable about the protocol and can answer questions and solve problems that possibly no one else can.

They’re valuable assets to the ecosystem and it would be a big win for Balancer to keep them on board.



1 Like

Hi @jameskbh, thanks so much for your comment!

In crafting this proposal, we intentionally avoided language like “roadmap” or “deliverables” because we strongly agree with the spirit of @markus’ comment here.

In short, we interpret this as follows:

  • Grant proposals are for funding projects. A project is a clear scope of work where the end goal is some tangible output for the ecosystem. As such, these have concrete deliverables, and it may make sense for a prospective grantee to provide a roadmap/Gantt chart.
  • Service Provider proposals are for funding teams. A team fits an ongoing role within the ecosystem and has a fundamental mission. An SP should be funded with the expectation that this particular team will fill this particular role in perpetuity - until the team decides to disband or until a better team comes along.

We believe that long-term roadmaps don’t make much sense for an Integrations team. Integrations work is primarily reactive; we observe and respond to trends in the developer ecosystem, fill gaps wherever we see them, and help non-technical teams with whatever they need in close to real time. We prefer to plan over shorter time horizons (e.g., 1 month) because we have found that it is often futile to plan for longer periods (e.g., 5 months).

In January of this year, we were in the midst of several Linear Pool integrations when the read-only reentrancy vulnerability was discovered. We had to put most of that work on hold and spend the better part of a month working with partners to safeguard funds. In the end, we saved over $4,000,000, but it blew a hole in our long-term roadmap. Similarly, over the past couple of weeks, Aave has shown reinvigorated interest in migrating their Safety Module from Balancer V1 to V2. Rather than sticking strictly to our current roadmap, we believe it is best to dedicate significant time to helping one of Balancer’s highest-value partners.

So, moving forward, we prefer to take a more adaptable stance and eschew the notion of a long-term roadmap in favor of a priority-based framing. Each of our monthly community forum updates will inclue:

  • Work completed over the month, so that the community has an opportunity to examine our team’s output.
  • Changes in core metrics, both all-time and month-over-month, to show the community how our output directly impacts the Balancer protocol.
  • Our strategy for the following month, especially highlighting any changes since the previous month, so that the community has an opportunity to provide feedback or ask questions. The strategy will focus on “why” rather than “what” - instead of a list of deliverables to be completed on a timeline, it will be a list of priorities according to which we filter all incoming opportunities. A working hypothesis will accompany each priority.

Tomorrow, we will post our update for the month of June, and we will include a list of the current top priorities for review. We haven’t yet started working under our new SP, but we will try to shift our updates more and more towards the new SP framework over the next few months. We are not yet ready to include the metrics section, as we need time to put together the correct data pipelines, but we hope that can be ready for our July or August update.


It goes without saying, but the integrations team is critical for the weekly operations of the DAO as well as the war room mode needed from all teams under certain circumstances, such as the currently relevant CSP issue. These guys are crucial to have around and great under pressure. In support of them, and respect the commitment from this team after going through the turbulence with Orb.


I absolutely agree with the overall sentiment. The integrations team is considered a core pillar for functional operation of the protocol. In full support.


We are excited to have started work as Three Rocks. Per our funding proposal, we will have our BAL allocations sent to vesting wallets, which can be claimed, by contributors, on a 4-year vesting basis, with a 1-year cliff starting from each employee’s initial start date within the ecosystem. The owner of the wallets, OpCo (eth:0x3B8910F378034FD6E103Df958863e5c684072693), will be able to recover all funds in the event of an employees departure from the ecosystem. The development of these wallets is complete, and we ask the community to review and approve these contracts within the next 7 days.

Once approved, we will deploy the contracts, and OpCo will send funds after verifying all parameters and the contract owners are correct.

Vesting Wallet’s Repo: GitHub - threerocks-defi/EnhancedVestingWallet: Built on OZ's VestingWallet, this contract adds a cliff, a beneficiary-only release guard, and clawback of unvested tokens by an owner.