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
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
thank you for the answer, the breakdown of the hourly costs + activities is what I was looking for.
3 Likes
@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.
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
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:
- A fixed contract for core GRC at USDC 115.5k for the year - guaranteed outflow
- 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.
- 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
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
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
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
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
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
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
I find the change from “frontend” to “product” to be a subtle but welcome shift in how we think about the Balancer frontend. I would hope that this also represents a shift in thought process and approach to how the Balancer Product is built and how features are (re-)built in a way that more closely aligns with critical user journeys.
@C0_G1 brought up a really interesting point above:
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.
At the heart of this comment lies a question: What is the role of the Balancer Product? If we collectively agree that being a DEX is no longer the primary focus of the Balancer Product, it presents an opportunity for us to redefine its purpose and goals. Generally speaking, I would have expected this proposal to present more information on how the product team plans to better align the development of the Balancer Product with its role in facilitating the growth and adoption of the Balancer Protocol.
To hopefully kick start this conversation, I believe the Balancer Product should:
- Further cement itself as an industry leading UX by:
- Creating cohesive user journeys for critical user flows - Since the launch of
frontend-v2, the landscape of the balancer ecosystem has shifted dramatically, with veBAL and boosted pools representing just two examples of fundamental shifts in direction. IMO, the UX should evolve to serve the changing landscape, as until now most new features have been forced to fit inside of an information architecture that was designed under different requirements than we have today. - Providing a multi-chain native UX - It’s simply a matter of time before Balancer Protocol will be live on 10+ chains. We need to embrace this and develop a mult-chain native UX.
- Providing meaningful and insightful data on both the pool and user level - The adoption of the beets API represents a shift in the amount and type of data that can be sourced performantly. Our goal should be to leverage this new piece of infrastructure to provide data on both the pool and user level that sets an industry standard.
- Creating cohesive user journeys for critical user flows - Since the launch of
- Provide an intuitive and flexible UI for core user actions
- Joining and exiting a pool - In a world where swaps are no longer our focus, joining and exiting a pool is the most important user journey the frontend facilitates. I believe that significant energy should be invested into creating an intuitive UX that is built on a flexible architecture that can “easily” support future pool types and the various types of joins/exits they will introduce.
- Staking in a gauge
- Claiming gauge rewards
- Serve as a vehicle to inform users about ecosystem initiatives and leverage key touch points to reinforce core concepts
- Custom AMM development
- ve80/20s
- LSD/Ts
- Yield bearing BPTs
- Composable pools
9 Likes
Really love your suggestions about what the Balancer product should strive to do, I agree with all points and would love to hear more thoughts by other stakeholders in our DAO.
Also agree we have to change our mindset from “frontend” to “product” and think Pon joining OpCo will be a great step in this direction, combined with the invaluable input from @danielmk and the Beets SP.
4 Likes
this one really stands out to me, i haven’t seen many protocols handle this elegantly. being able to present multichain information without too much clutter or forcing users to switch between networks to see that network’s info. it may sound stupid but i feel like some people may never know about what is available on other networks because they don’t even think about changing the dropdown choice.
5 Likes
Thanks for your input, @danielmk.
I appreciate your feedback, and I agree that the proposal should have provided more information regarding the product direction, as you have suggested. These are all crucial points that we are discussing internally. I apologize for not expanding on our internal vision for the product in the proposal. One reason for this was our intention not to overpromise for the next cycle. A lot of work needs to be done to restructure the app towards this new information architecture. That is why our primary goal is to build out and leverage supporting infrastructure. I see this as the first necessary step in moving towards that new vision.
Following this, as you have also noted, our focus will shift to upgrading and providing the best possible UX, specifically for LPs and veBAL holders. Also, handling multi-chain functionality in a ‘native’ manner is a key foundational feature, i.e. being able to browse/filter through pools across all networks and the network not really being relevant until you need to perform a transaction. We’re excited to work on these features, but there is some groundwork to do as mentioned above.
In general, I think it’s important for us to allocate time to discuss how product direction/vision is determined and communicated. Historically, the Balancer Product direction has primarily been driven by developments in the protocol, such as supporting boosted pools and veBAL. However, now that it is becoming clearer what the canonical app will be used for, it makes sense to shift to a more public, user-centred, product process. I think that process needs to be a joint effort across multiple SPs and I’d appreciate any support in organizing something around that.
2 Likes
Thanks everyone for your comments and feedback. In summary, the Balancer Foundation Board and Executive register the following sentiment:
- Continuing OpCo in its role for the ecosystem infrastructure makes sense.
- Continuing to host the OpCo Front-end/Product team makes sense, however the community believes the costs to be high in the current market.
Some additional context that may not be obvious to new community members: OpCo is not a third-party service provider, nor is it controlled by a tight group of insiders, it is DAO controlled entity with direct oversight from community directors who are fiscally aware and responsible, and in regular contact with the broader community. There is also no profit component in its operating structure - any unspent amounts remain at the disposal of the DAO.
To help make this a little clearer we’re going to split this proposal into its two main components as new and separate proposals: one being the “Administrative & Operations” element, which is DAO ecosystem-wide infrastructure, a required element of operating a decentralised Ecosystem. This proposal will be for 12 months.
The second proposal being the “Product Development Workstream”, formerly the Front-end and Design, and being evolved/developed in real time. This proposal will be trimmed down to a 9 month period. Calling out a relevant item from the proposal - the Product team are employees/contractors under OpCo. Should the needs of the DAO change during the period covered by the proposal, the team can adapt. In addition we are revisiting the budget to tighten it where possible and remove the option to offer increases in January (which were never locked in under the current proposal). The team are also revisiting the larger software line items to see if there are alternatives. For example, the TRM contract renews in May 2024, allowing time to explore options before committing.
A couple of other points to emphasize - the proposal process is intended to allow for discussion and feedback. The description of the outcomes of a yes/no vote in the proposal is to clarify the impact of the choices under the initial draft of the proposal. It does not mean the proposal cannot be changed before going to a vote.
Finally, given the depth of the discussion on this forum BIP, it would lose context if the initial proposal was heavily edited to only show one or the other element, so I plan to leave it as is and create two new proposals that will reference this proposal and all the discussion with it. These new proposals will be a continuation of the discussion and will each have separate votes.
10 Likes
This is a great comment, brother. It really shows that you have a deep understanding of the community and general sentiment these days–awesome leadership overall.
3 Likes
The funding proposal - [BIP-349] Funding Proposal for the Balancer OpCo - Administrative and Operational for Year 2 - FY23 Q3 through FY24 Q2 that covers the “Administrative & Operations” element of the above topic, or DAO ecosystem-wide infrastructure is now posted. Please read in conjunction with the above thread, thank-you.
3 Likes
The funding proposal - [BIP-XXX] Funding Proposal for the Balancer OpCo - Product Team - FY23 Q3 through FY24 Q1 - that covers the revised “Product” element of the above topic is now posted. Please read in conjunction with the above thread, thank-you.
4 Likes