[BIP-695] Fund OpCo Product team - Oct - Mar

Payload with PR

github.com/BalancerMaxis/multisig-ops [BIP-695] OpCo-Funding-Proposal-Q4-2024-Q1-2025 BalancerMaxis:main ← BalancerMaxis:BIP-695-OpCo-Funding-Proposal-Q4-2024-Q1-2025 opened Yesterday 8:26 PM Zen-Maxi Zen-Maxi +32 -0 Proposal: https://forum.balancer.fi/t/bip-xxx-fund-opco-product-team-oct-mar/599… Service Provider Name: Balancer OpCo (Product Team)

Core Contributor(s): Gareth, Alberto, Anastas & Pon

Pledge to abide by [BIP-629] Balancer DAO Service Provider & Grantee Standards: Yes

Introduction 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.

Since the passing of BIP-55 and its subsequent extension (BIP-351, BIP-565), the Balancer OpCo product development team has been a core team in the DAO since July 2022. This proposal aims to extend the product development services for an additional 6 months (October 1, 2024 - March 31, 2025). As in the previous proposal, the administrative and operational elements provided by Balancer OpCo are submitted as a separate proposal.

Our primary roles include Frontend Team Lead (Gareth), Frontend Core Engineers (Anastas and Alberto), and Product Designer (Pon).

Balancer OpCo is requesting $333,325 and 1,875 BAL for 6 months of funding.

Retrospective Balancer OpCo product team was previously funded (BIP-565) for 6 months from April 1st, 2024 through September 30th, 2024.

Our high-level goals stated in the previous proposal are as follows:

Increase LP engagement and satisfaction. Increase veBAL adoption and holder engagement. Increase awareness and adoption of the Balancer protocol. These goals have not changed and will continue to guide our focus as we build out v3 of the Balancer canonical app.

Our primary focus in the previous funding cycle was to build and launch the v3 app which we called Project Zen (or the Zen UI). The Zen UI was launched on the 18th of July (4 months into our funding cycle) and was generally considered a great success for the ecosystem.

In the build-out of the Zen UI we engaged the community through the Zentestooor initiative in Discord. A big shout-out is due to Tritium for the work he did to help us get this initiative off the ground and operational. Zentestooors found many bugs and suggested great improvements that were implemented before the launch. It undoubtedly contributed to the successful launch of the new app.

Three weeks after launching the new UI we also launched support for CoW AMM, another resounding success for the ecosystem. The quick turnaround from launching the UI to adding support for an entirely different underlying AMM is a testament to the architectural decisions we have made building the new app. It puts us in a great position to support v3 and any other AMM variant opportunities that develop within the ecosystem.

Objectives Objective 1: Support the launch of the Balancer v3 protocol Team: Alberto, Pon, Gareth

Summary: The next big launch date for the Balancer ecosystem will be the v3 protocol launch. For this, the UI will need to seamlessly support v3 pools and promote them in an effective way. That is, the UI will need to support adding liquidity to v3 pools, which requires Permit2 approvals integration. It will also require work to ensure removing liquidity, staking and unstaking work seamlessly with v3 pools. Finally, we will ensure that v3 pools are findable, distinguishable from v2 pools and promoted effectively to support the ecosystem with the growth of the v3 protocol.

Key results:

The UI accurately displays pool information for v3 pools. The UI supports Permit2 approvals for adding liquidity to v3 pools. The UI supports adding, removing, staking and unstaking of v3 liquidity. The UI makes it easy to find and distinguish v3 pools. Timeline: The launch of the v3 protocol is currently unknown so it is impossible for us to accurately say when the key results will be achieved. However, we have already started work on Permit2 support and our goal is to be ready to go live as soon as the protocol is ready.

Objective 2: New veBAL experience Team: Pon, Gareth, Anastas & Alberto

Summary: veBAL features were deliberately left out of the launch of the new UI (we currently link back to the v2 UI if a user needs to manage their veBAL or vote on gauges etc). This is because veBAL is a huge feature, almost an app in itself. We also recognised that there is a lot we can do better with the veBAL experience to better promote ownership and engagement. So instead of delaying the launch of the new app, it made sense to leave implementation for post-launch.

The new veBAL experience is currently being designed and the majority of implementation will happen in this next funding cycle. The objective for this new experience is to more effectively promote and support the benefits of owning veBAL, including the acknowledgement and integration of incentive markets such as HiddenHand.

Essentially, we want to take learnings from the existing veBAL experience in v2 and community tools for leveraging incentive markets and build a new and improved experience that maximises veBAL utility for holders.

Key results:

A veBAL management UI where users can lock, extend and unlock/withdraw their veBAL. A veBAL syncing UI where users can sync their veBAL balances to secondary networks. A veBAL voting UI where users can see all the available gauges that can be voted on, their current votes, their estimated weekly incentives for their votes, and a vote optimizer. The vote optimizer should use incentive market data to find the maximum return for a user’s voting power. Timeline: As with all large scopes of work, it’s difficult to estimate precise delivery timelines. The design work for each key result is already underway. Some initial development work has been started for (1) and (2). At the time of writing, we estimate that a complete veBAL experience might be live by the end of the year or early next year.

Objective 3: Deprecate v2 UI & supporting infrastructure Team: Gareth

Summary: Now that the new UI is live and supporting core pool actions, swapping and reward claiming, we must continue to migrate and shut down the remaining logic in the v2 UI. Deprecating the remainder of the v2 app will allow us to shut down the v2 API, which will reduce the ecosystem’s infrastructure costs.

Key results:

Shut down the veBAL experience in v2 UI, possible when Objective 2 is complete. Shut down claiming, portfolio and swap pages in the v2 UI. Turn off the v2 API. Timeline: The target is to shut down the v2 API (and therefore the UI) by the end of the year.

Objective 4: Frontend monorepo Team: Gareth, Alberto & Anastas

Summary: The frontend team would like to start to restructure our work such that we can share and build tooling more easily with the wider community, within Balancer and DeFi more generally. In practice, this means converting our core repository to a monorepo and extracting useful logic into packages.

Key results:

A functional monorepo that contains the v3 frontend app. A package that exposes some useful functionality currently contained within the v3 app. Timeline: This is a secondary objective so we will not set hard deadlines. Rather, we aim to do this at some point within the next funding cycle.

Ongoing commitments The Product Development team ensures Balancer has a high-quality UI/UX available everywhere that allows users to interact easily with the Balancer protocol. 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 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 will design, build and maintain the marketing pages for the Balancer protocol. The primary aim of these pages will be to inspire and help onboard potential partners into the ecosystem. We ensure this UI works across all modern devices including desktop and mobile browsers. 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. We will continually work on the stability and reliability of the UI by covering its critical functionality with unit and integration tests. 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. Ecosystem design support We will support broader ecosystem design initiatives. For example, we’ll collaborate with marketing on creative direction and occasional asset production. 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. The existing API mentioned above will be deprecated in favour of the shared Beets/Balancer API at https://api-v3.balancer.fi. 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. OpCo operations Manage DNS for all Balancer DAO domains. Manage 3rd party accounts, upgrades, renegotiations, etc. For example, RPC providers, AWS, and wallet check providers. Github repositories that we are directly responsible for:

GitHub - balancer/frontend-v3: Official UI application for the Balancer protocol. GitHub - balancer/frontend-v2: Frontend app for the Balancer protocol (to be deprecated) GitHub - balancer/balancer-api: Depr...