Service Provider Name: Beethoven X DAO
Core Contributor(s): franz, groninge, daniel
Pledge to abide by the DAO’s Code of Conduct (or link to your own): Yes
Pledge to abide by the Accountability Guidelines: Yes
Introduction & Domains of Operation:
Since the passing of BIP-254 and it’s subsequent extension (BIP-393 and BIP-394), the Beethoven X DAO has functioned as a Balancer Service Provider since May 1, 2023. This proposal aims to extend the technical services and advisory component for an additional 6 months (January 1, 2024 - June 30, 2024). As in the previous proposals, marketing services provided by the Beethoven X DAO are submitted as a separate proposal.
Our primary roles include API team lead (franz), frontend contributor (groninge) and ecosystem technical lead (daniel). While the past nine months have been turbulent at times, we strongly believe it has once again demonstrated the resilience of the Balancer DAO and the entire ecosystem. Despite a key service provider winding down, several core contributors stepping down, and a critical vulnerability, we are collectively still here, building.
The upcoming release of Balancer V3 presents an opportunity for Balancer to regain narrative and establish ourselves as the platform to empower current and future AMM innovation. We are hugely optimistic in the future of Balancer Protocol and steadfast in our dedication to support the ecosystem to the best of our abilities. As we work towards Balancer V3, it has been inspiring to participate in the development of a more cohesive technology stack to empower the future of the protocol. A technology stack that leverages the collective experiences and expertise of contributors across the ecosystem, avoiding siloed development strategies that lead to unnecessary system complexity in Balancer V2.
As we operate as a small part of a much larger system, our successes are enabled by many across the ecosystem. As such, we present a broader ecosystem update below that touches on our specific contributions when relevant. As we continue to find the best way to bring value to the Balancer ecosystem, we welcome community feedback.
Integrations
Three Rocks recently announced their decision to wind down effective December 2023. Both @rabmarut and @gerg have been long time contributors to the Balancer ecosystem. We’d like to extend a thank you to the entire Three Rocks organization, they are a team of talented engineers who made countless contributions to the protocol as well as serving as the technical interface to external partners, they will be missed.
Over the last few months, there has been ecosystem wide discussions around the future of integrations at Balancer, resulting in with what we see as a very positive outcome to a challenging situation. Effective January 2024, the responsibilities of the integrations team will transition to Balancer Labs under the leadership of John Grant. With John Grant’s extensive knowledge of the entire Balancer ecosystem and the support of existing Three Rocks team member @Mkflow27, integrations will become a part of what is currently the Balancer Labs SDK team. With expertise in both on- and off-chain integrations into Balancer Protocol, we see this team as being well suited to fill the gap left by Three Rocks. While John is on a well deserved parental leave, I have been working directly with mkflow to help facilitate a smooth transition.
We’d additionally like to extend a huge thanks to Fernando and the entire Balancer Labs team for their willingness to take on the responsibilities and costs for integrations moving forward. This significantly reduces the operational costs incurred by the DAO, and is yet another example of Balancer Labs’ ongoing commitment to the long-term success of the Balancer protocol.
Smart Contracts
Balancer V3 has been the core focus of the Smart Contracts team for the majority of the last two quarters. While the feature set has not yet been publicly disclosed, we are extremely excited about the technical direction of Balancer V3. Architecturally speaking, there has been a focus on:
- Interface design - with the overarching goal of making it significantly easier to integrate with Balancer protocol.
- Reducing overall system complexity
- Improved code readability by reducing inheritance depth and leveraging libraries for composition.
Internally, the smart contracts team is on track to complete its second major milestone at the end of this year, a first MVP of the core contracts of Balancer V3. It has been an absolute pleasure collaborating closely with @juani, @endymionjkb and @ylv. I think I can speak for the entire team when I say that we’re very much looking forward to sharing more details on Balancer V3 publicly.
SDK
Progress on the new b-sdk has continued over the past two quarters, and it is fast approaching feature complete for Balancer V2. In contrast to the existing Balancer SDK, the new b-sdk is highly focused on facilitating on-chain interactions with the Balancer Protocol. Data intensive operations are now delegated to the Balancer API, allowing the SDK to be focused in its goals. The SDK team has additionally been a huge contributor in interface design for Balancer V3, their in-depth understandings of V2 integration pain points have been invaluable in the process.
An important initiative worth highlighting is the cross-organizational effort to implement a generalized approach for price impact calculations in the b-sdk. Spearheaded by @brunoguerios from the SDK team and @ZenDragon from the Maxis, their efforts have produced a first iteration of a generalized approach that will reliably calculate price impact for all pool actions, irrespective of the underlying invariant implementation. This is a massively valuable development for the entire ecosystem.
Frontend
The upcoming release of Balancer V3 presents an opportunity for a new take on the existing frontend application. OpCo and Beethoven X contributors have spent the last several months laying the groundwork on a new version of the Balancer Frontend. With a fresh new look, the new Balancer Product will be:
- Multi-chain native to allow for quick exploration of liquidity pools across all Balancer supported networks.
- API powered to facilitate fast loading times, overcoming many of the data challenges plaguing the current V2 application.
- Version agnostic to ensure that any liquidity that stays on V2 will benefit from the streamlined UX.
- Designed with a flexible architecture, with the goal to easily support all current and future pool types.
Led by @gareth, OpCo and Beethoven X contributors are collectively leveraging their extensive Balancer domain knowledge to build a better product.
API
As the limitations of the subgraph have been a constant bottleneck for V2, the Balancer Labs Data team, lead by @mendesfabio, have made the decision that future versions of the Balancer subgraph will be focused primarily on data extraction (E). This is in recognition that the API is better suited for the role of data transformation (T) and loading (L). As the API will play an important role in the Balancer tech stack, former SDK team member Jarek has transitioned to the API team and we expect that there will be a close collaboration between the API and Data teams as we move towards Balancer V3.
Below, we present general API updates, written by Beethoven X DAO contributor franz, API team lead:
Over the last months, our main effort went into getting the API ready for the new frontend-v3 and the b-sdk. As the frontend aims to serve a multi-chain user experience, the API must also support these requirements. Working closely together with OpCo, requirements for queries have been defined and implemented one-by-one as they are needed in the development process.
Many other, smaller changes have also been integrated into the API to support data needs for the new frontend such as specific filters, rate provider data, FX pools support or yield fee specifics.
Additionally, the API is also used in the new b-sdk to “enrich” pool data that is being used for various pool operations. Together with Balancer Labs we defined the requirements for the API and integrated the changes. These requirements mainly comprise specific needs on nested pools, token indexes or other token data.
Additional points of interest:
- In August, BASE chain was integrated into the API which is responsible for serving pricing data to the UI.
- Optimizations have been made to the infrastructure deployment that resulted in a more cost effective solution. In addition, more changes are planned that should further reduce the cost of operating the infrastructure.
- On November 27th, we successfully deprecated the veBal voting-gauges.json file in GitHub in favor of the API. All known partners have migrated and will query the API in the future. With this change we automate a manual operations task, reducing manual work.
- We have helped the community in Discord with questions regarding development, inner workings of the UI and API, to help them understand the liquidity mining or voting processes from Balancer and with general questions.
- We’ve supported the Balancer Maxis with their data needs for the gauge rewards automation program. Also, showcasing the rich data set that the API has on Balancer pools and how to make use of it.
Key Objectives & Success Metrics:
- Make it easier to build on Balancer - Having become domain experts on Balancer tech, Beethoven X collaborators are uniquely positioned to identify and help build solutions for many of the pain points that exist in the current Balancer tech stack.
- Reduce duplicate effort across the ecosystem - A joint API deployment is the first of several projects we see where Beethoven X contributors can leverage their domain expertise to reduce duplicate effort. How do we as an ecosystem invest significantly more energy into the future success of Balancer protocol and spend less time on the problems of today?
- Help drive the direction of the Balancer protocol - We believe Balancer protocol should be a platform that empowers current and future AMM innovation. We will continue to work to align the various parties in the balancer ecosystem around this vision. How do we put a true focus on this goal? How do we empower developers to build the next generation of AMMs on Balancer protocol?
Length of Engagement & Budget:
Beethoven X DAO is requesting 6 months of funding starting January 1, 2024 and ending June 30, 2023.
We request a budget of $29,000 USDC per month for technical development and advisory. The increase of $4,000 USDC per month reflects increased involvement from groninge on the development of the new v3 frontend.
ETH Address to Receive Funds: 0x811912c19eEF91b9Dc3cA52fc426590cFB84FC86