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.
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.
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.
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.
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.
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.
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).
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 - balancer/frontend-v2: Frontend app for the Balancer protocol
- GitHub - balancer/balancer-api
- GitHub - balancer/tokenlists
- GitHub - balancer/marketing-site: Marketing site
- GitHub - balancer/frontend-e2e
Github repositories we are not directly responsible for but contribute to:
- GitHub - balancer/balancer-sdk
- GitHub - balancer/docs: Documentation for Balancer
- GitHub - beethovenxfi/beethovenx-backend
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:
- 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.
- 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).
- 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.
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.
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:
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
Q3 FY23 - 28,958.33 BAL - for transfer after the snapshot vote, if successful.
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 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 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.
0x3B8910F378034FD6E103Df958863e5c684072693, a multisig controlled by 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.