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.
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.
Thanks everyone for your comments and feedback. In summary, the Balancer Foundation Board and Executive register the following sentiment:
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.
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.