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