[BIP-XXX] Funding Proposal for the Balancer OpCo - Year Two

Service Providers Funding Proposals
1

Authored by: Tristan & Gareth.

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.

  1. Administrative & Operations

Serving as the operating entity with which third-party Service Providers to the Balancer DAO will contract, submit invoices to, and from which they will be paid whether that be in fiat or in tokens. This role is integral to the decentralised operations of the Balancer ecosystem, and in practice supports the healthy long term functioning of the DAO and the Balancer Protocol, and helps the DAO achieve its goals.

The Balancer OpCo will operate under the direction of the Balancer Foundation, which will oversee / have responsibility for governance, corporate administration and operations. This includes hosting and managing software subscriptions and login credentials for the OpCo team and certain ecosystem-wide platforms and social media accounts. An addition for year two is in-house Governance, Legal and Compliance (GRC) that the Ecosystem Council proposes be retained by OpCo as a new addition to the OpCo budget. As a reminder, the Foundation operates under the governance of the DAO.

A little more on GRC: given their experience with the Balancer Ecosystem, we are proposing Warburton continue this role. Hours are reduced under this proposed budget. In terms of scope, Warburton will provide GRC advice to support the Balancer Ecosystem Council which includes major service providers (SPs). Warburton will provide reporting to the Ecosystem Council as requested and protect confidentiality so Balancer has the ability to defend itself from unnecessary disclosure in litigation or government inquiries.

GRC services will be focused on protecting the resiliency, and facilitating the growth, of the ecosystem through the Council members (and major SPs). GRC efforts will protect Balancer by focusing on further decentralization strategy and implementation, US regulatory risks and Balancer objectives to understand and proactively protect against potential threats from legal/regulatory changes. GRC will also include keeping the Ecosystem Council current on matters of regulatory changes and sentiment, monitoring the GRC program including review of marketing/comms, conflicts of interest, VASP, sanctions and exemptions/exclusions from other evolving global requirements, assessment and negotiation of material contracts for disclosed council members and SPs and management of regulatory inquiries, investigations and/or litigation and strategy for Ecosystem Council with external counsel as needed. GRC will be handled “in-house” to extent practical to minimize external counsel costs and time. Please note that this is an internal facing role that will report to the Ecosystem Council including OpCo, not directly to the DAO. The scope of hours may be expanded to cover needs as pre-approved by OpCo. Warburton would operate on a 30-day notice period.

  1. 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 Kattera (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 Kattera 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 are 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.

Product Development

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

2.3 Y2 Goals

Balancer OpCo’s goals for year two have been carefully crafted based on our experience and strategic insights gained during year one. In order to provide a comprehensive understanding of the process behind setting these goals, we encourage you to review our year one Retrospective. This Retrospective document lays out the contextual background necessary to appreciate the rationale behind our year two goals. We have outlined below the specific goals that Balancer OpCo aims to achieve in the upcoming year.

Build out and leverage supporting infrastructure

We propose that the best path forward to most effectively support the Balancer protocol, as it evolves, is to fully leverage supporting infrastructure such as the API. This means that we can drastically simplify the front-end codebase by moving and refactoring much of the logic into the API and read-only helper contracts. 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. An additional benefit to this approach is that, once the front-end is a dumbed down UI layer, focus on UX becomes easier. In order to achieve this goal we will work on the following:

  • Refactor any remaining complex logic in the front-end to the API, helper contracts or other supporting infrastructure.
  • Consolidation of all API endpoints into single Beets/Balancer API. That includes the SOR and pools endpoint currently used and hosted separately.
  • Refactor front-end to take advantage of this new architecture and improve UX.

Support development of a micro app that can be self-hosted.

One of the reasons the existing front-end is restrictive is that we simultaneously tried to build a good UX and support decentralized hosting/access. We propose that these are opposing concerns and as such should be built out separately. If the canonical Balancer app is unavailable for any reason, it should be possible to perform core protocol actions like exiting a pool via a UI without the need for centralized dependencies like the API. This micro app should be accessible on decentralized hosting providers like IPFS and/or Arweave, and we should point to those deployments from the Balancer ENS name.

Launch a refreshed brand

A brand refresh initiative is currently underway. Our team will lead this effort in collaboration with Beethoven X marketing contributors and attempt to gain community consensus around a final visual direction. This involves design exploration around a number of concepts, and the execution of sample UI which could be used on the marketing website, web app and for social graphics. Once community consensus is reached, we’ll create official brand assets and guidelines to give partners a better experience around co-marketing. We will also roll out the new aesthetic across Balancer properties.

User feedback system

As part of our commitment to improving UX and transparency we will implement a system for receiving user satisfaction feedback. This may be used to generate a KPI to measure user sentiment, e.g. an NPS score.

2.4 Y2 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:

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 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 permissionless-ness, 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 repositories we are not directly responsible for but contribute to:

2.5 Y2 Reporting

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 for Y2 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 for Y2)

  • Audience: Public
  • A high-level written report of work done over the past 30 days, including how that works relates to our stated goals for Y2. 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 Y2 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 around the team and it’s performance and any changes to 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 potential KPIs and systems as we explore this path:

  • Home page Lighthouse Score.
  • User satisfaction score (To be established).
  • 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.

Again, these are tentative KPIs that will be tested in the upcoming monthly and quarterly reports to assess if they effectively convey the current state and progress made on the front-end app, which is our primary responsibility.

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

Yes.

Pledge to abide by the Accountability Guidelines 3 1:

Yes.

Length of Engagement & Budget:

One year - July 2023 (Q3 FY23) through June 2024 (Q2 FY24) divided into four quarters.

The summary below reflects the proposed budget for these four quarters, to be sent in quarterly payments from the DAO. Each quarter an update will be provided via Community Hall calls and via 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 returned to the Balancer Treasury, 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 in USDC by quarter, followed by descriptions of their make-up.

882×492 49 KB

A breakdown of the Product Dev People costs in USDC is here:

879×366 44.9 KB

Requests for USDC transfers:

The OpCo holds funds due to the reduction in spend achieved by OpCo and Orb vs their original budgets. 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. We propose that USDC funding needs for OpCo be supplied initially from these funds, which are estimated to cover the first three quarters of the OpCo budget based on current information.

Q3 FY23 - USDC 375,158 - cover with funds held at OpCo

Q4 FY23 - USDC 343,458 - cover with funds held at OpCo

Q1 FY24 - USDC 359,554 - cover with funds held at OpCo (might require top-up from the DAO)

Q2 FY24 - USDC 394,212 - for transfer 25 March 2024

Request for BAL transfer:

Q3 FY23 - 38,020.84 BAL - for transfer after the snapshot vote, if successful.

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 5% buffer on FX rates, and 5% for potential and unconfirmed salary increases in January 2024.

There is also a buffer to cover unexpected variances in employment costs along with phone, internet, coworking and hardware costs at capped levels. Any unused amounts will either be rolled into the next funding proposal, or returned to the DAO.

In addition, the Balancer OpCo is requesting 38,020.84 BAL for year two that align 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 four 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. TRM is $30,000 for the annual subscription and an estimated $20,000 will be needed for a top-up bundle of API calls, which equates to a combined total of $50,000 for the period. The “API calls’’ fluctuate fairly significantly over time. This is a ballpark based on current and expected use of the UI. Should usage change significantly, the estimates may need to be revisited.

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 will monitor 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.

Non-People Costs - Operations & Administration

The main items in this section are legal and compliance costs (more below), monthly bookkeeping service (we continue to perform the “CFO” element in house for the foreseeable future in order to keep costs down). We have included a $20,000 estimate in Q3 for Directors and Officers insurance - actual costs could be materially different. Software subscriptions included here are for operations (G-suite, QBO) and ecosystem-wide services such as Dune Analytics, Discourse, Slack, Notion and Asana. Q3 2023 includes a one-off amount of $10,000 in case a deposit is required for a new bank account.

The largest increase relates to in-house Governance, Legal and Compliance (GRC) that the Ecosystem Council proposes be retained by OpCo as a new addition to the OpCo budget, effective 1 August, 2023. As mentioned, we are proposing Warburton continue this role. Hours are reduced under this budget compared with year one, to a fixed monthly fee of $10,500, or $115,500 for 11 months. Given the reduction in hours, we are budgeting some flex at $7,500 per month should the need arise for additional support. That combined with the external counsel budget gives a total GRC line item of $222,000 for the year. Any unused amounts would be available for reallocation by the DAO. If this needs to be revisited it will be dealt with in a future proposal.

ETH Address to Receive Funds:

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 Front-End Development 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.

Voting

This vote will be a single-choice vote. You may vote on the Proposal by selecting “Yes, let’s do it”, or “No, this is not the way”, or abstaining.

The Community voting “Yes, let’s do it” on this proposal means:

You recognize:

  1. The Balancer OpCo is a required element of operating a decentralised Ecosystem
  2. Maintaining and improving the website is a crucial element of the Balancer Protocol, and to keep the front-end, and have it supported by the team that is currently managing and improving the website.

The Community voting “No, this is not the way” on this proposal means:

  1. A separate proposal will immediately be brought to the community regarding the administrative costs of the BVI OpCo, as this entity is necessary to manage SP relationships and ecosystem shared services.
  2. The Balancer front-end will be sunset (unless another team steps forward to take it over) with all the inherent implications to the users of the protocol and impact on the Balancer brand.
4 Likes
2

Hello sirs - would you please clarify the total amount sought in stables, BAL, or otherwise for this funding proposal?

Please also clarify the period of funding. Some portions of the proposal mention 2022, which seems to be a typo, while others mention Q3 2023.

Please also let us know the total amount, in stables, BAL, or otherwise, sought for people costs v. non-people costs, along with breakdowns by department (GRC, etc.).

1 Like
3

Hi! Thanks for your proposal!

Just for clarification: The BAL request for the employment package comes from the execution of the BIP- 282?

In that proposal, it was mentioned:

For transparency, current contracts with existing team members would require 56.818,87 BAL for the next 4 funding rounds (years):

Year 2: 26.562,50 BAL
Year 3: 20.428,08 BAL
Year 4: 8.890,79 BAL
Year 5: 937,50 BAL

The change from ~26k to 38k BAL is due to the addition of the Product Designer?

2 Likes
4

Nice and leghtly proposal.

I have one main question for now about gcr fundings. I understand that a big protocol might need legal advises due to the current reg situation, and I have some difficulties quantify the hours required for this continuous task and the price per hour, but a fixed 10.5k per month, up to 17.5k per month, seems quite an expense.

Can we expect, for the monthly/quarterly reports (or whatever OpCo is going to produce for the public), a detailed breakdown of these activities related to GCR?

2 Likes
5

Hi @Matt_Alfalfa_or_Span,

Thanks for catching the typo, have corrected to show 2023. The period of the proposal is 1 July 2023 through 30 June 2024. Sometimes also written as Q3 2023 through Q2 2024, or Q3 FY23 through Q3 FY24 (or similar variants) where “FY” refers to financial year.

Total amount sought for this proposal over the entire relevant period is USDC1,472,382 and 38,020.84 BAL. Broken down below as requested:

The total amount sought for People Costs (that is, staff on OpCo’s payroll, current and planned) is USDC 954,760 and 38,020.84 BAL. The BAL figure is specific for the staffing on the proposal. The USDC figure includes some estimates as described in the body of the proposal. All people costs refer to the Product team. Any unspent amounts remain available for use at the DAO’s discretion.

The total amount sought for Non-people costs, Product department is USDC 184,784. This amount is all for software related to the Front-end and Design. We continue to benefit from the significant savings negotiated in year one.

The total amount sought for Non-people costs, Operations and Administration is USDC 332,838. This amount comprises:

  • Administrative costs: USDC 11,800 - Registered Office/Agent, Registrar of Companies Fees, Annual Compliance Services, Bank fees, Gas fees, hardware wallet if needed.

  • Directors’ and Officers’ insurance: USDC 20,000 (estimate)

  • Establishment of new banks account(s): USDC 10,000 (estimate)

  • GRC - total for the year - USDC 222,000. To minimise costs to the DAO, we are proposing to structure GRC with a base-level fixed contract totaling USDC 115,500. This represents the minimum internal GRC support required for the items mentioned in the proposal - that is - the day-to-day of the operations. Then there is capacity to call on some level of additional GRC support if required, where internal or external. The estimate for external GRC is USDC 24,000 for the year, and the general GRC buffer is proposed at USDC 82,500 for the year, whether internal or external. In my view it would be imprudent to budget less for an operation of this nature. Structuring the budget in this way allows any unspent amounts to remain at the disposal of the DAO, while allowing scaling if needed. As a reminder, OpCo is directed by the Foundation, which acts under the governance of the DAO and is represented by a majority of directors from the community.

  • Bookkeeping / Accounting services estimated at USDC 24,000 for the year (USDC 2,000 per month). This also is a very low budget given industry comparables, but we are hopeful of achieving this.

  • Software services for the Ecosystem and OpCo administration USDC 45,038

1 Like
6

Hi @jameskbh, thanks! You are correct, the change in the BAL request is the addition of the Product Designer.

1 Like
7

I get the sense from the community that there is some desire to have some accountability/oversight on legal spend.

Is there some sort of reporting that can be provided about work that is being done? What level of reporting will be done on discretionary spend beyond the base monthly rate.

I think the thing we all need to start getting used to, is that requests to spend the DAOs money come with the expectation to justify why it is needed before hand. Unless the spend is on a clear plan with a clear cost that is clearly executed well and on-time, some explanation of what happened is a reasonable ask.

I know this is hard, and creates some work and is sometimes uncomfortable, but I do think it is important. So many DAOs just waste money while eschewing oversight until they go bankrupt. Most people I talk to think this is the biggest problem with DAOs and why the whole DAO experiment is likely to eventually fail.

If we want to succeed at this thing we have to figure out transparency and accountability. Even when it’s uncomfortable or creates some extra work.

1 Like
8

Hi Jojo,

I’ll talk to the expense question first with some more detail on the nature of the work and services, and follow with the reporting element.

Expense
The fixed part of the proposed GRC amount represents 20 hours per month (roughly 5 hours per week) at USCC 525 per hour. This is the USDC 10.5k per month. For baseline, Warburton is currently contracted to Balancer at 20 hours per week (not through OpCo) and is fully occupied. This budget is a 75% reduction in time, and therefore yet to be seen how it works. The buffer is if there are issue, or for example additional contracts with SPs to review/agree and we need to go beyond the current spend.

Experience/flexibility/nature of the work
There is a cost benefit of having someone experienced that can cover multiple issues, jurisdictions, entities and topics - for illustration one person’s hourly rates vs having multiple specialists and having two or more lawyers on a call, all charging per hour. With this proposed arrangement, GRC would support the Foundation, OpCo, B Labs, Beets, Maxis and other members of Ecosystem Council as well as major SPs. This resource would not just be dedicated to providing services to one entity.

Reporting
OpCo can report on the GRC spend and activities, and I’ll insert the types of activities here again so the info is all in one place: GRC services will be focused on protecting the resiliency, and facilitating the growth, of the ecosystem through the Council members (and major SPs). GRC efforts will protect Balancer by focusing on further decentralization strategy and implementation, US regulatory risks and Balancer objectives to understand and proactively protect against potential threats from legal/regulatory changes. GRC will also include keeping the Ecosystem Council current on matters of regulatory changes and sentiment, monitoring the GRC program including review of marketing/comms, conflicts of interest, VASP, sanctions and exemptions/exclusions from other evolving global requirements, assessment and negotiation of material contracts for disclosed council members and SPs and management of regulatory inquiries, investigations and/or litigation and strategy for Ecosystem Council with external counsel as needed. GRC will be handled “in-house” to extent practical to minimize external counsel costs and time.

2 Likes
9

Hi @Tritium

Thanks for articulating this. I think the GRC reporting element is covered in the response to @Jojo.

Let me know if any further info would be useful, Cheers.

2 Likes
10

No further questions. If there are regular reports about GRC spend and clear justification for any flex spend, sounds great to me.

The same holds true for every cost center in the DAO.

1 Like
12

thank you for the answer, the breakdown of the hourly costs + activities is what I was looking for.

3 Likes
13

@Tristan345 - thanks for this and your earlier thoughtful and detailed response. My question in relation to the GRC buffer is: why not just provide for a follow-up governance request if it seems like the allotted time of about 20 hours/month is insufficient? If that issue comes up, I would think that a discussion and evaluation as to particular needs and resource allocation, along with appropriate personnel and staffing, would be appropriate for the community to evaluate and consider.

It’s also worth considering if we could perhaps expand the overall GRC focus by starting to develop some type of helper / starter pack, template, or model to transition, onboard and maintain SPs for and with the DAO. An effort like that could prove to be really helpful.

14

I found the cumulative annual burn in relation to protocol revenue and stables in DAO treasury quite high and in the domain of hard-to-justify and unsustainable.

Given severe tech layoffs in the past two years (Crypto industry data can also be accessed here: https://layoffs.fyi), why does Balancer OpCo choose to pay US rates for frontend work that can be executed for half the cost with eastern EU rates?

The proposed KPIs and ‘tentative’ nature of them does not inspire a lot of confidence given the fact that this is a Y2 proposal. What are the existing KPIs?

When I pointed out Balancer frontend moving away from DEX frontend to an infrastructure as unjustified in an Orb update, I was greeted with the response of aggregators accounting for the majority of swap fee generation. Does Balancer OpCo share this view? If so, can you justify 1.5m USD burn rate for work with little material impact on business KPIs?

I think it would be more beneficial for all SPs, Maxis, notable delegates to hold a session and define strategic priorities and a budgeting framework rather than reactively vote for proposals from semi-autonomous, self-interested remnants from BLabs.

2 Likes
15

Hi @Matt_Alfalfa_or_Span

We may well have to approach Governance for additional GRC budget should the need arise, and I fully agree with your reasoning there. What I’m looking to solve for is having GRC budget available on short notice with certainly. A basic level of scope in the GRC field is needed at a management level. It’s not guaranteed that OpCo will spend those funds, which is helpful from a treasury perspective. If we don’t need to, we don’t spend it. OpCo is not compelled to to spend it based on a fixed contract for example. Some important but relatively day-to-day issues are likely to arise during the year that may need to be addressed immediately, where pausing work on some issues may pose undue risk to the ecosystem given the two-week process of working through Governance before taking action.

At the end of the day we are talking about a USDC 22.5k cushion per quarter, a fairly small amount that gives very important insurance to the protocol. An idea suggested to me is that OpCo gives notice to the Ecosystem Council with the nature of the need before spending buffer funds. What do you think?

There are in summary three tiers of spending, and in the proposal the first two are covered:

  1. A fixed contract for core GRC at USDC 115.5k for the year - guaranteed outflow
  2. A budget for additional GRC that is hard to predict, but may be urgent, and not generally a major spend at USDC 82.5k for the year, likely some of this will be spent, but with the benefit of retaining any unspent amounts for DAO resources.
  3. A larger unexpected GRC need that is not in the proposal - if needed then present a Governance proposal with discussion and evaluation.

External GRC is similar, without the guaranteed spend, likey a fair portion will be spent, but unspent amounts are available to the DAO.

Regarding an SP starter pack - Great idea. No problem. We worked on that already and we use it for SPs through OpCo. We can create a version for the DAO. It will look like what we created for the legacy Ops SubDAO but with some updates.

4 Likes
16

Hey, thank you for mentioning this. I believe we haven’t had any issues rising against the quality/cost of our frontend team, so nice to have it in a public forum.

First of all, I believe the debate around why we have a frontend at all is needed. I know killing the “swap” feature comes up occasionally, because of regulatory reasons and the real benefit it brings. Like you mentioned, volume/revenue doesn’t come from our frontend and I believe soon we’ll have some more accurate data for that (BLabs had a wip dashboard here). However, atm a UI/UX for LPs would still be needed.

A quick note on the cost: 1,472k is not the frontend burn, but also carries the whole BVI cost structure that holds things together and signs contracts (+ in-house counsel for the whole ecosystem). Product budget is the 1,139k (which is still very expressive sum, ngl).

OpCo is a subsidiary company of the Balancer Foundation, and if this debate builds up to a conclusion that it’s no longer necessary and discontinued, or we should be seeking outsourcing opportunities, then we are free to do so. I’d support it if we have more voices and concerns being raised in this direction.

1 Like
17

Thanks for the clarification Danko.

Just trying to stir debate centred on cost benefit analysis and how we may skew frontend to high cost - high benefit quadrant. I think the following areas could use improvement:

1- Better UI/UX for LPs
2- veBAL automations (see Radiant zap feature)
3- A more informative, dashboard for veBAL holders (Llama Airforce) - APR with all incentives, annualised revenue, treasury holdings, cumulative burn rate etc. Xeonus has already done most of the legwork.
4- User journey mapping for ve8020 & composable pools

2 Likes
18

Hi @C0_G1

For reference we already downsized the OpCo team by 2 earlier this year. My opinion is that if we were to downsize any further we’d impact our ability to build out what’s needed, when it’s needed, as the protocol evolves. As for hiring a team on “eastern EU rates”, my experience so far has shown that to find good remote devs who can communicate well in a fully remote team is challenging, and when you do find them, they know their worth. So for devs like these, rates are not very localized. Something else to consider is that built up dev context on the front-end/infrastructure side of things is valuable when the underlying protocol tech is changing so quickly. Our team now has years in combined experience working with the Balancer contracts, subgraphs, data, etc.

The ‘tentative’ KPIs in the proposal are not tentative in that we won’t have KPIs, just that we need to find the correct ones to accurately represent our teams work. I agree we should have done this for Y1, but our transition into the new structure has been a busy process on top of all the dev work we’ve done.

I also want to point out that ‘front-end’ is a restrictive term for the work that the OpCo team is responsible for. We are essentially building and maintaining a full-stack web2 product. We build and run infrastructure, we are responsible for the whole design flow, including assets and copywriting, and then we also build out the front-end.

Regarding, moving away from a pure DEX front-end to having infrastructure, we’ve outlined the challenges we’ve faced in doing this in our Y1 Retrospective and discussed our thoughts on that there. We believe that to provide the best possible UI/UX for LPs we need to move away from the ideal of a pure decentralized front-end for the canonical app.

I think setting up a session to strategize on the shape and requirements of a ‘Product’ team would be helpful.

5 Likes
19

The OpCo is clearly a key SP for the Balancer ecosystem being the maintainers of the front end (which is an industry leading UI in terms of UX), overseeing SP relationship execution and now hosting the legal department. The proposal is well written and outlines all the major costs and responsibilities.

In terms of the budget specifics, I feel that $1.1M in total comp (USD + BAL) for 5 product/front end engineers is a lot of money given the environment, in addition to the ~$160k for front end costs. I think it’s valid to recognize both points mentioned here for the yes vote (Opco is a required element, and the front end is crucial for Balancer) and also be concerned about a budget of this size and the precedent that sets for other SPs or contributors who are doing an admirable job trying to reduce costs to align with the macro market and the state of the Balancer treasury/revenue, but don’t want to be the only ones.

If the only other option is to sunset the front-end as noted then of course this BIP should be voted through. It would be hard to dispute that whatever the request. I guess I’m just feeling disappointed because even though the UI is explicitly valuable, the high budgets have eaten into the revenue/viability for veBAL holders (and Aura, post launch) with the treasury % increase, redirection to core pools, flash sale of BAL. I’m just generally concerned and hoping it doesn’t continue to do so.

To clarify, I just wanted to say my piece in here and don’t speak for anyone else, would imagine this would get voted through regardless.

3 Likes
20

I would tend to agree with franklin. There is a a bit of a conundrum here, which is

  • OpCo is quite important for balancer ecosystem in general
  • the funding part feels like is very important in term of size.

On one side, I could see a merit in this funding: we are talking, in the way I understand it, about the people who have lifted Balancer over time to where is it now. They have “history knowledge” and the experience on how this should work, and the acquired results over time are a very good resumee. On the other side, these numbers automatically tends to justify some SP costs and evaluation we have seen in the past and that we might see again in future, such the one of Orb. And I am not saying OpCo is Orb, to be clear, but I am saying that if the main SP ask X to do Y, a new SP can be justified to ask X/2 to do Y/2, despite the new SP delivering or not as we have seen in the past.

I have no easy answer for the current situation, I just want for everybody to have a look at this proposal in term of budget, and outlook, for other future SP: setting up this budget standard would intrinsically mean that Balancer would be quite expensive as ecosystem for the management, and this is not too great.

That said, without any specific review, I would personally vote yes to this proposal for OpCo.

4 Likes
21

Thank you @Franklin @Jojo. I don’t think there’s a conundrum, or that we are cornered to approve or sunset the fronted. Sorry if my last paragraph made you think that. I only mentioned these concerns were never raised before, so that we could better realize if this is a real issue the community resonates with.

What would be a fair rate to pay our seniors? I see this same issue is coming up on the Maxis proposal as well. Maybe we can have a better sense of this things in abstract, rather than scrutinizing people individually. The “salary committee” idea isn’t bad, and would be better than backchanneling conversations and putting the voters in this situation to fell like they are micromanaging the SPs.

But also noting building a team is not just about salaries. @gareth pointed out why he makes a choice for this smaller team on the current rates and market (also letting go two engineers). We must be weary if community voices are driving changes that will be hard to hold leaders accountable for in the future, but I think there’s enough competence in this current team to address these concerns while at the same time being thoughful of the product and the people involved.

4 Likes