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