[BIP-393] Fund Beethoven X DAO - Technical for Aug - Dec

PR with Payload

https://github.com/BalancerMaxis/multisig-ops/pull/430

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:

With the passing of BIP-254, the Beethoven X DAO became a Balancer Service Provider for the period of May 1, 2023 - July 31, 2023. This proposal seeks to extend the technical services and advisory component of the original proposal for an additional 5 month period (August 1, 2023 - December 31, 2023). As outlined in BIP-314, the marketing component of BIP-254 will appear as a separate proposal moving forward.

The following sections present a summary of where we spent our time and energy over the last 10 weeks. As we continue to find the best way to bring value to the Balancer ecosystem, we welcome community feedback.

API

The new Balancer API is production ready, supporting all Balancer and Beethoven X chains. Built to alleviate many of the data sourcing issues plaguing the balancer frontend, this new API leverages the beethovenx-backend codebase and is deployed on unified infrastructure. This joint deployment cuts operational costs and allows us to tap into individual domain expertise more effectively.

As the API will become a critical piece of infrastructure for Balancer protocol, we dedicated substantial effort to enhancing monitoring and ensuring operational resilience. To improve error visibility, we implemented various alerting mechanisms and notification services, enabling us to identify and address any potential issues before they affect users. Additionally, we created a status page (Dashboard) that provides real-time infrastructure status for anyone to monitor.

To strengthen the resiliency of the API, we implemented several measures, most notably integrating caching infrastructure and adding rate limits. Furthermore, the deployment architecture is designed to scale automatically based on demand. These implementations ensure that the API can reliably and efficiently handle requests, leading to a fast and seamless user experience.

Beyond infrastructure changes, we’ve collaborated closely with contributors from OpCo and Balancer Labs to further enhance the API and align it with the requirements of the Balancer Protocol.

• Leveraging the token pricing mechanism of the API, OpCo successfully improved pricing reliability on the frontend. It proved particularly valuable during the ZKEVM deployment, where Coingecko lacked many token prices.
• The API is now used to provide real-time "marketing stats" on the Balancer landing page, aggregating total volume, fees, and TVL across all chains efficiently.
• In collaboration with OpCo, we’ve started integrating the veBAL voting list into the API, leading us to uncover and optimize inefficiencies in the voting gauge addition process. By streamlining and automating these processes, we can significantly enhance their efficiency by reducing manual work.
• Working closely with the SDK team, we’ve started to integrate the new version of the SOR into the API. Leveraging our existing production deployment and the API's capabilities, we are able to test the new SOR algorithm using real-time swap data. This approach allows us to evaluate the efficiency and speed of the swap, helping us improve the SOR code and achieve optimal outcomes.

Through collaboration, enhanced infrastructure, and integration efforts, we have established a robust and reliable API that caters to the needs of both Balancer and Beethoven X. However, we recognize that this is just the beginning of our journey.

Technical Advisory

A key takeaway from the initial engagement period facilitated by Balancer Labs is that the role I (daniel) am best suited to fill is not only as a builder but as an advisor across the technical landscape, working to ensure that the various engineering teams in the ecosystem build cohesive technology that is aligned with the overall Balancer product vision.

Outlined below is where I’ve spent the bulk of my time and energy, although I would emphasize that I am just one part of a larger conversation. I’m hugely thankful for everyone’s openness in engaging with me on these topics.

Smart Contracts

One common criticism of Balancer protocol smart contracts is that they are difficult to interact with and even harder to understand. Although the smart contract team does an incredible job of documenting their contracts, there is a collective agreement that we can improve their ease-of-use and readability.

There is real value in “giving people what they’re used to” as a means to facilitate adoption. While the Balancer V2 interfaces make sense in the context of balancer, they introduce domain specific knowledge that create hurdles for adoption. We’ve started working on a simple set of interfaces that more closely align with the standards set by Uni V2. These interfaces will provide an alternative to the existing full-fledged options (batchSwap, joinPool, exitPool).

While inheritance is the core design pattern available when organizing smart contracts, deep inheritance comes at the tradeoff of readability. The use of libraries has been presented as an alternative to inheritance (where appropriate). When a library function is called, it’s immediately obvious where that function is defined, and thus easier to understand and reason about. It more closely tracks the principle of composition over inheritance.

SDK

To date, the Balancer SDK has been built primarily to facilitate the needs of the Balancer Frontend. The introduction of the B-SDK and Balancer API present an opportunity for us to redefine it’s role in the broader tech stack. It allows us to ask the question: “What role should the Balancer SDK play in facilitating/furthering the overall vision of Balancer Protocol?”

In answering this question, we’ve worked on identifying the various user groups of the Balancer SDK and prioritizing their needs. This has allowed us to more clearly define that the Balancer SDK should be a tool highly focused on facilitating on-chain interactions with the Balancer Protocol. The Balancer API will serve as the data hub for the protocol, allowing us to move much of the data responsibilities out of the SDK and into the API.

Active initiatives:

• The new SOR (implemented in the B-SDK) has been integrated into the API, allowing for side-by-side testing of the routing algorithms without adding additional computational load to the frontend.
• Various read-only helper contracts are in development: 1, 2, 3. These contracts will significantly reduce the complexity of off-chain data processing, providing accessible on-chain tooling for common data requirements. This aligns with an over arching goal to push more data complexity (where it makes sense) on-chain.
• @brunoguerios from the SDK team has started porting additional pool type math to the new B-SDK SOR, leveraging the computationally superior bigint math.

Frontend (Product)

The change from “frontend” to “product” represents a subtle but important shift in how we think about the Balancer frontend. Some general thoughts on a Balancer Product vision are presented here. @gareth and I continue to have an ongoing conversation focused on how we can build a better Balancer Product both technically and within it’s role in facilitating the growth and adoption of the Balancer Protocol.

In an effort to ensure that we are constantly improving the existing UX, we’ve begun to set up a process that creates visibility around issues in the existing balancer frontend. Our goal is to use existing tools to measure user issues when interacting with the balancer frontend, and work towards reducing these occurrences over time.

Composable Stable Pool Vulnerability Support

The vulnerability disclosure on June 25th has impacted protocol fee collection on all composable stable pools, a core revenue driver for the protocol. As resolution of this issue was deemed critically important, I’ve invested a significant portion of the last two weeks supporting @juani and @Fernando in identifying the underlying issue and working towards a resolution. As someone familiar with the composable stable pool protocol fee collection mechanism, my participation here made sense from a resource allocation perspective, and has allowed the remainder of the smart contract team to continue progressing on existing projects.

Marketing Transition Support

Although not a typical technical service, when the Orb Collective abruptly wound down support for marketing services and released all marketing personnel, I stepped in to facilitate a smooth transition of marketing related responsibilities to Beethoven X contributors.

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 is requesting 5 months of funding starting August 1, 2023 and ending December 31, 2023.

We request to continue the budget of $25,000 USDC per month for technical development and advisory.

ETH Address to Receive Funds: 0x811912c19eEF91b9Dc3cA52fc426590cFB84FC86