[BIP351] Funding Proposal for the Balancer OpCo - Product Team - FY23 Q3 through FY24 Q1

PR with Payload

Authored by: @gareth & @Tristan345

Service Provider / Organisation Name & Overview:

Balancer OpCo Limited (or the “Balancer OpCo”) is a wholly-owned operating subsidiary of the Balancer Foundation. It is an integral element of the Balancer Foundation corporate structure supporting the Balancer DAO. It serves two primary functions (1) Administrative and Operational; and (2) Product Development.

This proposal deals with the Product Development element housed in the OpCo. The initial discussion is at draft BIP for year 2 funding and the comments there related to Product should be considered as a part of this proposal. This proposal has been adapted to incorporate feedback from that forum discussion and includes more details around the evolution from Front-end and Design to a more holistic Product model. In particular, a Product Vision section has been added and the Goals section has been updated to align our work more closely with protocol objectives. The proposal period has been reduced from 12 months to 9 months, and the budget has been tightened.

For reference, the Administrative and Operations element of OpCo is dealt with in a separate proposal here.

The revised proposal for Product seeks approval for 723,525 USDC, compared with 1,139,544 USDC for the previous version. The table below shows the bridge between the previous proposal budget and the revised proposal. Reducing the period to 9 months cut the forecast by 316k USDC down to 824k USDC. This also reduces the BAL request from 38,020.83 BAL to 28,958.33 BAL. We have further trimmed the proposal by 100k USDC to a final figure of 724k USDC.

The $100k reduction for the 9-month period comprises:

  • Dropping the FX buffer for non-USD payroll from 5% to 3%. Note that I have updated the FX rates from the mid buy/sell on xe.com to the rate used by the payroll provider in June, which moves against us slightly.
  • Cutting the allowance for unconfirmed increases in January of up to 5% down to 0%.
  • Cutting the payroll buffer for variances from 10% to 1%, which includes cutting staff allowances for phone, internet, co-working, and hardware to zero.
  • Cutting the budget for TRM API calls of $20k to $0. The team is working on a lower-cost in-house solution to be implemented ASAP.

Product Development Workstream

The Balancer OpCo continues to house the Front-end team, being evolved into the Product Development team for the Balancer DAO. This evolution is at an early stage. As part of framing this proposal and to determine the focus for year two, the Product Development team prepared a Retrospective of year one. The Retrospective examines the delivered outcomes and evaluates the effectiveness of the year one, strategy. Combining this analysis with our vision for year two has informed the content of this proposal. Moreover, the Product Team has actively sought input from key members of the Balancer Ecosystem to shape this suggested approach.

In year two, the Balancer OpCo plans to retain the Product Development Team, which will serve the Balancer DAO either as employees or contractors. The Product team has always worked in close collaboration with the Design team. As part of our proposal, we aim to include Pon (Product Designer) in the Product Team at Balancer OpCo, starting from 1 August 2023. (Note that the payroll management company requires a 1-month refundable deposit, so costs are estimated from July.) Since Pon is transitioning from another service provider within the Balancer Ecosystem, this change will have a net-zero impact on DAO costs but will result in increased staffing and costs at the Balancer OpCo.

Balancer OpCo will continue to hold the software subscriptions for the necessary UI and marketing tools, and will host all the official Balancer digital properties:

The team identified to fill these roles is drawn from top talent who have a proven track record performing development for the Balancer Ecosystem backed with senior-level experience. They are passionate about the project and committed to its long-term success. The team currently consists of 4 FTEs: 1 Lead Engineer, 2 Front-end Engineers, and 1 Full-stack/Infrastructure Engineer. As mentioned above, we plan to add 1 Product Designer effective 1 August 2023. This is the staffing level determined necessary to maintain and improve the existing Balancer app and build out any future iterations to support the changes and improvements of the Balancer protocol. Should strategy or circumstances change creating a call for increased staffing levels, a separate proposal will be brought to the forum.

Lead for the Product Development Workstream

Balancer OpCo’s Product Development is led by Gareth Fuller (@garethfuller).

Gareth brings over 10 years of engineering experience to the table, with a strong background in the crypto space. Previously, he served as a Senior Full-stack Engineer at Bitbond, where he played a key role in the development of the P2P Bitcoin lending platform. Notably, in 2019, Gareth was instrumental in the launch of Bitbond’s STO (Security Token Offering), which was among the first in Europe. Gareth has been actively involved in the crypto space since early 2017.

Gareth first got involved in the Balancer ecosystem in March 2021. He swiftly assumed leadership of the front-end team, spearheading the successful launch of Balancer’s V2 app. As part of this role, Gareth took charge of building and nurturing the front-end team, fostering its growth to its current state. Throughout his time at Balancer, he has consistently led and actively participated in major changes, guiding the team through new feature development and refactoring efforts.

Product Vision

Historically, the Balancer Product direction has been a reactive process driven by developments in the protocol such as the launch of V2 then supporting veBAL and boosted pools. As the protocol and product have evolved, it is becoming clearer what the canonical app will be used for and who it will be used by. It now makes sense to shift to a more proactive, user-centred, product process.

Our vision is to create a powerful and intuitive platform that primarily caters to the needs of LPs and veBAL holders, enabling them to maximize their participation in the Balancer ecosystem and facilitate the growth and adoption of the Balancer Protocol.

By aligning our product vision with the needs of LPs and veBAL holders, we are committed to creating a user-centric platform that fosters growth and innovation within the Balancer ecosystem. Our product development efforts will be driven by the desire to deliver an exceptional user experience, promote active community engagement, and contribute to the long-term success and sustainability of the protocol.


The Product team will contribute to the ecosystem’s core goals of increasing protocol revenue, TVL and Volume. As Product Owners for the web app, marketing site and docs site, the best way for our team to contribute to these goals is to:

  • Increase LP engagement and satisfaction.
  • Increase veBAL adoption and holder engagement.
  • Increase awareness and adoption of the Balancer protocol.

These goals have been crafted by leveraging our experience and strategic insights gained from building and maintaining the V2 product since its launch. To gain a comprehensive understanding of the process behind setting these goals, we highly encourage you to review our year one Retrospective. In the following section, we present the specific goals that we will strive for in the next cycle.

  1. Increase LP engagement and satisfaction

The Product team aims to provide the best possible experience for LPs. This involves improving the UX for existing LPs as well as improving the onboarding flows for new LPs. It also involves encouraging existing LPs to increase the size of their positions on Balancer.

To improve the UX for LPs, we plan to:

  • Build out and leverage supporting infrastructure such as the API - This will allow us to drastically simplify the front-end codebase. Taking the app in this direction allows us to restructure the front-end as a ‘dumb’ UI layer that can be adapted and changed to meet future requirements of the protocol, quickly. It will also allow us to iterate more quickly on user flows for better UX and optimization.
  • Refine and optimize the join/exit flows to make them more intuitive, less error-prone, and user-friendly.
  • Provide valuable insights on both the pool and user levels. Our first point, leveraging supporting infrastructure, will facilitate more detailed reporting capabilities. This shift will enable LPs and veBAL holders to make data-driven decisions, gain a deeper understanding of their portfolio performance, and ultimately enhance their returns and engagement.
  • A refreshed brand will be launched to enhance the appeal and visibility of Balancer.
  • To gather valuable user feedback and insights, Balancer OpCo will implement a user feedback system, allowing LPs to contribute their thoughts and suggestions for continuous improvement.

In addition to attracting new LPs with improved UX, we recognize the importance of retaining existing LPs. Continuous efforts will be made to enhance the LP user experience (e.g. improve insights around an LP’s performance) to ensure LPs find value and satisfaction in participating in the protocol.

We will also seek to increase the usage of L2s. To achieve this, seamless multi-network support will be implemented, allowing users to:

  • Easily browse and filter pools across all networks in a single table.
  • Understand and gain insights from their Portfolio across all networks in a single view.
  • Easily review and claim their current rewards across all networks.

In general, the user or pool’s network will only really become relevant at the end of a transaction flow, i.e. when the user needs to confirm a transaction. Cross-chain boosts will also be improved and optimized to highlight the advantages of liquidity provision on L2 networks, thereby encouraging more LPs to participate.

Furthermore, we aim to increase the average liquidity provision size per LP. To achieve this, UI/UX strategies will be developed to encourage LPs to allocate larger amounts of liquidity to the Balancer protocol.

  1. Increase veBAL adoption and holder engagement

The Product team recognizes the importance of increasing the adoption of veBAL and therefore the amount of veBAL held in the Balancer ecosystem. This involves increasing the number of veBAL holders and also the size of veBAL holdings per holder. We will undertake initiatives to attract new veBAL holders, promoting the benefits and opportunities associated with veBAL ownership. Additionally, efforts will be made to increase the size of veBAL holdings per holder, encouraging existing veBAL holders to increase their stake and actively participate in the Balancer ecosystem.

To increase veBAL adoption and holder engagement, we plan to:

  • Introduce new features and functionalities that enrich the veBAL experience.
  • Simplify veBAL management UX.
  • Explore and implement tactics to encourage users to extend their veBAL locks. One example may be to show people how much veBAL power they are missing out on by not max extending.
  • Explore and implement tactics to encourage veBAL holders to vote on pools that contribute the most to protocol revenue.
  1. Increase awareness and adoption of the Balancer protocol

Our ecosystem becomes stronger and generates more protocol revenue as more independent developers build compelling protocols, applications and pools on Balancer. As Product Owners for the web app, marketing website and the UI/UX of the docs site, increasing adoption of the Balancer protocol is a key goal for the Product Development team. To achieve this, we will explore opportunities to:

  • Refresh the marketing website
    • New developer-focused content will be created to inspire builders. This includes highlighting the most compelling reasons to build on Balancer, showcasing the most interesting features of the protocol and creating better case studies of partners.
    • Lead an initiative (along with the Beets content team) to refresh the Balancer brand, including a new visual direction. This new branding will be incorporated into the refreshed marketing site.
  • Improve the docs site
    • Improve the landing page and create better diagrams and graphics to help explain complex protocol concepts.
  • Improve pool creation
    • Pool creation by third-party partners is also an important driver of increased protocol adoption. We plan to optimize the existing pool creation flow in the web app and explore tactics to nudge pool creators to pair pools with yield-bearing tokens that contribute to protocol revenue.

Note: We have chosen to focus on the LP experience over the swapper experience within the web app. This is because aggregators like 1inch and CoW dominate swap volume (with the Balancer UI contributing less than 5%) and we expect this trend to continue. Setting goals more closely aligned with liquidity provision keeps the team laser-focused on improving the core join/exit flows and increasing protocol revenue from token yield. Volume should definitely be an ecosystem goal—stewarded by those with the most control, like the Smart Contracts team (who can create more efficient pool types) and Business Development (who can foster relationships with key aggregators).

Continued Commitments

The Product Development team ensures Balancer has a high-quality UI available everywhere that allows users to interact easily with the Balancer protocol, as well as providing UI components and software tools for developers to easily build their own UI’s for Balancer related projects. In addition, the UI serves as a branding tool where people can better understand what the Balancer Protocol allows. The team will:

  1. Build, Improve and Optimize the canonical UI for interacting with Balancer
  • The Product Development team is responsible for the main Balancer website and application. We aim to provide the best possible experience for users to provide liquidity, swap, lock veBAL, vote on gauges, and claim earnings using Balancer.
  • We ensure this UI works across all modern devices including desktop and mobile browsers.
  • We will continually work on the stability and reliability of the UI by covering its critical functionality with unit and E2E (End to End) tests.
  • We will continually optimize and improve this app so users have a great experience no matter how many features or how much data Balancer introduces in the future.
  • Whenever new features or improvements are made to the Balancer smart contracts we will implement the primary UI for users to interact with them on launch.
  • This also includes responsibility for all copywriting across the app.
  1. Support the development and maintenance of the shared Beets/Balancer API
  • The Product Development team currently maintains the Balancer API at https://api.balancer.fi, which provides quick access to Balancer pool and token information, as well as providing a SOR interface that services such as CowSwap use to calculate the best trade routes through Balancer pools.
  • The existing API mentioned above will be migrated into the shared Beets/Balancer API at https://api-v3.balancer.fi.
  • Additional functionality will be added to the shared Beets/Balancer API to support a simpler UI layer.
  1. Integrate the app with other app stores and services
  • As wallets and DeFi app stores (such as Coinbase wallet, Sia Skynet, or the ethOS phone) become a more common way for users to interact with DeFi applications, we will work with providers to ensure Balancer is available in requested and approved locations.
  1. Provide tools that allow anyone to self-host minimal Balancer UIs
  • As Balancer is about maximizing decentralization and permissionlessness, we seek to avoid the front-end being a centralized point of failure or control. As such we will support the development of micro apps and UI components that provide simple ways to perform core protocol actions, for example, exiting pools. We will help continually maintain these and make them easier to use over time.
  1. Provide documentation, resources and help to allow others to implement their own custom UI’s for their project
  • Many projects integrate with Balancer smart contracts, such as Aave, Element Fi, CopperLaunch, Aura Finance, Olympus DAO, Gyro Protocol and more. Many more are constantly requesting integrations. We provide them with the UI elements and tools they need to be able to quickly create their own custom UI for their application, accelerating Balancer’s growth in the DeFi space.
  1. User support
  • We will monitor relevant channels in Discord, Slack and Github issues for any reported problems and aim to respond within 24 hours and fix the problem as soon as possible.
  1. Brand building via design systems
  • After community consensus has been reached for the above-mentioned brand refresh project, we will create a design system which can be applied across the web app and marketing site. The design system will consist of reusable components with variants which can easily be used across the site to achieve consistent UI and consistent interactions.
  • This will foster consistent brand graphics and interactions across Balancer properties, including the web app and marketing website.
  1. Refresh the marketing website
  • We will design and build the next version of the website, which is primarily aimed at builders. In particular, this will focus on developers who want to build custom AMMs.
  • The new site will also apply the refreshed branding.

Github repositories that we are directly responsible for:

Github repositories we are not directly responsible for but contribute to:


The Product Development team is committed to transparency and openness in all our work. The majority of our day-to-day activities can be followed via the previously mentioned repositories. We are also committed to providing higher-level reporting on our work in the relevant calls and on the forum. Our reporting commitments will be as follows:

Weekly engineering roadmap call (Continued from Y1)

  • Audience: Internal, engineering and ecosystem leadership.
  • Here we share status updates on our latest work and take note of any urgent requirements or future work for our team.

Monthly forum update (New)

  • Audience: Public
  • A high-level written report of work done over the past 30 days, including how that works relates to our stated goals. We will also include reflections on challenges that may be standing in the way of progress on those goals.
  • Relevant metrics that the Product Development team’s work has a direct impact on, e.g. KPIs (see proposed KPIs below).

Quarterly community call update (Continued from Y1)

  • Audience: Public
  • A higher-level update on the work done over the last quarter and work planned for the next quarter, including KPIs and visual content if relevant. This update will also include reflections on the team and its performance and any changes to the overall direction described in this funding proposal or previous quarterly reports.

Proposed KPIs

Over the next quarter, we will aim to incorporate more metrics and KPIs to enhance our understanding of our impact, guide our decision-making, and foster greater transparency for the community. While integrating this kind of thinking in a quarter may be ambitious, we plan to experiment with systems for collecting metrics and try to provide at least a couple of initial test KPIs with some loose targets going into Q4, and further continue in this direction over the coming year.

Below are some initial considerations regarding KPIs that tie into our previously stated goals:

  • Ratio of fatal errors in transaction flows / total successful transactions.
    • “Fatal” here is a reference to the Sentry error level that we tag errors with that block a user from finishing a transaction flow.
    • “Total successful transactions” is pulled from event analytics used in the UI. So it’s the total number of transactions successfully submitted through the UI.
  • User satisfaction score (e.g. NPS, to be established).
  • Home page Lighthouse Score.

Again, these are initial KPIs that will be tested in the upcoming monthly and quarterly reports to assess if they effectively convey our progress in facilitating the growth and adoption of the Balancer protocol through the canonical app.

Pledge to abide by the DAO’s Code of Conduct 1 1 (or link to your own):


Pledge to abide by the Accountability Guidelines 3 1:


Length of Engagement & Budget:

Nine months - July 2023 (Q3 FY23) through March 2024 (Q1 FY24) divided into three quarters.

The summary below reflects the proposed budget for these three quarters. Each quarter an update will be provided via Community Hall calls and Discourse. If budget changes are requested they will go to a snapshot vote. If no changes are requested, this proposal will serve as the governing decision. Any unspent amounts at the end of the period will either be available to the DAO, or offset against the next period’s funding proposal.

We note that the Product team are employees/contractors under OpCo. Should DAO Governance vote to restructure the Product team, for example, change who maintains the front-end or for OpCo to cease hosting the front-end, OpCo policy is to provide staff severance equal to the requirements of local labour law in their jurisdiction, subject to a minimum of one month’s notice.

The table below shows the applicable expense categories by quarter, followed by descriptions of their make-up.

A breakdown of the Product Dev People costs is here:

Requests for USDC:

The OpCo holds funds saved due to the reduction in spend achieved by OpCo and Orb vs their original budgets in year 1. Estimated savings at the OpCo in year one have been partially allocated to fund the Foundation for Q3 FY23. The final savings figure will be known in Q3 FY23. We propose that USDC funding needs for Product be drawn from these funds, which are estimated to cover the nine months of the Product proposal.

Q3 FY23 - USDC 240,744 - cover with funds held at OpCo

Q4 FY23 - USDC 241,975 - cover with funds held at OpCo

Q1 FY24 - USDC 240,775 - cover with funds held at OpCo

Request for BAL transfer:

Q3 FY23 - 28,958.33 BAL - for transfer after the snapshot vote, if successful.

Impact on the Treasury

The projected spend associated with this proposal can be covered by projected savings at OpCo and Orb from year 1, since we now have more recent data on those projections. Thus OpCo does not require any funding from the DAO Treasury to fund this proposal.

For objective comparison, the Treasury currently holds ~4.5M in USDC. OpCo holds ~1.4M in unallocated USDC (resulting from the savings mentioned), together ~5.9M in USDC. Funding this proposal for the year would cost around 12.3% of combined current unallocated funds at OpCo, and current DAO Treasury USDC (not including the impact of projected revenue during the period).

People Costs - Product

People Costs are comprised of remuneration and employment costs for the developers. Remuneration is currently denominated in USD, AUD, GBP, and EUR. Exchange rate fluctuations against the US Dollar will impact the actual results. We have built a 3% buffer on FX rates.

There is also a buffer to cover small unexpected variances in employment costs. As mentioned, this has been cut from 10% to 1%, which includes cutting staff allowances for phone, internet, co-working and hardware to zero. Any unused amounts will either be rolled into the next funding proposal or returned to the DAO.

In addition, the Balancer OpCo is requesting 28,958.33 BAL for the nine-month period of the proposal that aligns with the grants included in staff employment packages. These BAL 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.

Should any of these employees leave before the completion of the 4-year vesting period, any unvested BAL would not go to the departing employee and would be available to the OpCo for allocation as incentives to potential replacement staff, or return to the DAO Treasury.

Non-People Costs - Product

Non-People Costs Product consists of software subscriptions to front-end development tools and TRM. These costs have reduced significantly from year one. New additions to the cost structure relate to the design element, proposed to be housed in OpCo from 1 August 2023.

Alchemy is the largest line item at $2,945 per month or $35,340 for the period. The TRM annual subscription runs until May 2024. The annual renewal (est $30k) is outside the period of this proposal and is therefore excluded. In addition, the team is cutting the budget for TRM API calls from $20k to $0. The team is working on a lower-cost in-house solution to be implemented ASAP.

These and the other software costs depend on certain variables, including, for example, the number of users, log-ins, number of entities in the community that have access, and service calls. Some are billed monthly and others quarterly or annually, hence the changes in costs from one quarter to the next. We have estimated these figures using the best information available as of now, and recognise there will likely be variances during the year as more accurate data becomes available and actual costs become known. The team continues to monitor the usage of these services in order to reduce fees, and where possible negotiate more favourable rates - noting that material negotiations were undertaken in year one that we continue to reap the benefits of.

ETH Address to Receive BAL:

0x3B8910F378034FD6E103Df958863e5c684072693, a multisig controlled by the Balancer OpCo.

Link to Service Provider Agreement (if going through the Balancer OpCo):

Not applicable given this entity is internal. The Product team will be directly accountable to the Balancer OpCo and the BalancerDAO community through the reporting process applicable to all Balancer SPs, primarily with reference to the objectives and KPIs noted above.



Thanks for the new proposal and for taking the time to review where further reductions could be made!

Is it possible to explain with more detail the features and functionalities that you aim to introduce? (like the veBAL power tracking feature you mention later)

Is it possible to present something like a Gantt chart where we can see when the deliverables are planned to be finished/deployed? That will help the team and the DAO to check if any correction needs to be made along the way.

1 Like

I am going to be quick, and drop here the same comment i dropped for the integration team thread: napkin math.

We are talking, if i am correct, of a budget 70k/m for 4 (and soon to be 5) people, to develop the frontend.

So, we are talking about an average of 14k/m each fte. Not cost savvy, but inline with market for a certain level of seniority, and ok if we want to retain people who have already work on balancer and so their experience.

So, as long as the devs do their job, I think is reasonable.

If possible i would like instead a breakdown of non-people costs. I basically see 31-32k/quarter or around 10k/month. In the post you quote alchemy, which is 3k month. Why the surplus of 7k? I guess yes, there could be software licenses costs, but 7k >> 3k. So either these licenses are quite relevant, or you already think alchemy cost might need to scale up due to usage or other factors.
Could you elaborate a bit? if it’s mostly due to alchemy, don’t we have previous month bills to be able to eyeball numbers a bit better? Thanks :slight_smile:

Hi Jojo, yes it’s a busy portfolio - to help expand on the details, there are currently 17 software licenses related to maintaining the front-end. The Alchemy costs are budgeted at current rates, not expecting those to increase. There are additionally 7 software licenses related to the design side. We are continuously reviewing the subs and expect to be able to cut a further $12k over the 9 months and still have cover for likely changes in usage over that period. I’ve added a list of the subscriptions below.

AWS (currently running on credits, so no cost in this budget)
Vercel Pro
Consensys Software (Infura)
Fathom Analytics
TRM API calls
POKT Portal (Gnosis)
Gas fees for test wallet.

Adobe Creative Cloud
Figma & Figjam
Spline 3D


Thank you for taking the time to put down this list. I am no expert in the matter and don’t know some of these, neither I do know the pricing.

What is important, to me, is understanding the flow of the budget and where is going. I can understand that these licenses, and API calls, can be expensive. So, to me the 10k/m for non-people costs are justified here.

If, at some point in future, you and your team will be able to show a bill related to all of this (AKA: software X has taken Y in budget for this quarter), I think it would be quite helpful for everybody here to understand the complexity of managing a product of the size of Balancer :slight_smile:

1 Like

Sure. The most important element is “Build out and leverage supporting infrastructure such as the API” which kind of facilitates a lot of the other features we’re planning. For example, this should allow us to have a network-agnostic app. Meaning that we can have a pools list on the home page that includes pools across all networks that is easily searchable and filterable. It should also enable us to have a combined portfolio and claiming experience for all networks.

Regarding the veBAL features, we are just about to kick off a redesign of the veBAL management interface. Part of that will potentially include this power tracking feature. I can share a screenshot from the pre-implementation designs, but bear in mind this could change.

Some of the other features mentioned are ideas that need to be designed out. I’ll try to provide more detail if you want to know more about something else specifically.

This is good feedback. As we build our internal roadmap, we’ll work towards building a high-level gantt chart that we can present to the community.



1 Like