This is almost equal to the proposed amendment and acknowledges the existence of vote splitting (by partially enforcing options from the same provider to be together). I truly believe that the proposed amendment is still a better fit. This has slight differences that create more work by all parties involved (SPs, delegates, …) and changes in game theory:
Vote splitting concerns for extended scopes: Under this alternative mechanism, extended scopes would compete not just against the basic scope of the same provider, but also against all other providers’ budgets. This creates a disadvantage for extended scopes that doesn’t exist in the current amendment. Service Providers would naturally respond by concentrating more work in their basic budget to avoid this penalty.
For instance, if Blockful were to adapt to this mechanism, we would likely restructure our application to place more work in the basic scope rather than using extended as intended - a nice-to-have addition. This seems to be different from the original purpose of the two-budget approach, which was more about the basic budget as a fallback rather than extended as a nice to have.
Implementation and voting complexity: The current amendment introduces minimal complexity for delegates - simply asking “After ranking providers, which budget do you prefer (basic or extended)?” The alternative would require additional UI changes and create a more complex voting experience, when many delegates have already expressed concerns about the effort involved in evaluating proposals.
Two-year stream considerations: The possibility of varying budgets across years (e.g., 600k for year one, 400k for year two) would require more detailed breakdowns in proposals and complicate stream management.
I’m only judging the mechanisms and their externalities—nothing else than that.
The current amendment already addresses delegates’ needs effectively: it’s straightforward, introduces no negative game theory changes compared to the original proposal and has achieved consensus during discussion calls. It’s already implemented, tested, and being adopted by UI providers. I see no compelling reason to pursue a different solution when we have one that works and requires minimal effort from all involved parties.
About the voting UI, blockful is happy to build toward whatever solution the DAO decides, but we are also focusing on our other deliverables as well while reallocating the team to solve and test this asap, from our resources. I believe I shared my perspective based on extensive simulations and consideration of the different mechanisms, and I appreciate everyone’s thoughtful engagement on this topic. At this point, I’ll be engaging only when the DAO has decided which mechanism to use, as Blockful needs to direct our attention to other deliverables.