Recap from the discussion around service providers
@cap from Namespace did a 3-hour livestream last week with people from ENS, including AvsA, who spoke for 40 minutes about the service provider program which will be helpful for everyone to check out.
Similar Proposals Question
What happens with the proposals that are essentially doing the same thing?
Similar proposals are accepted, and all could be funded (it’s up to delegates)
Proposals simply need to meet eligibility criteria
However, delegates are encouraged to include all who they thing provides great service to the protocol or the DAO
Open Source Requirements
Questions about the MIT license and open-sourced codebase.
The idea is that this is the work that benefits the ENS ecosystem and is also a public good.
Concerns that open-sourcing their proprietary client/apps removes the source for any other funding.
Core services can be open source, with peripheral offerings being closed source.
The program may fund an open-source SDK, for example, while allowing private repos for other initiatives.
The work funded by the program should be MIT licensed, focusing on what is planned to be open-sourced.
Copeland Method and Ranked-choice Voting
Snapshot introduced the ranked-choice voting method (see X post)
TWAP has stopped since March 26th because the price broke below $2k
Will wait and revisit this topic to find the best time to resume TWAP
2. General DAO Updates
Open Space for SPP Discussion
Feedback for the amendment for choosing between basic and extended options.
Nick’s comment was discussed that suggested ranking the budget separately, which would simplify the process and align the snapshot vote with current ranking methods, but it would add complications.
The current state of interfaces for voting is looking good, a lot of progress is being made, and they feel confident they will deliver.
The requirement for strong battle-testing before the official vote is acknowledged.
Voting only through Snapshot would be opaque, custom interfaces are much better.
A strong desire to move things forward and define next steps is needed
Governance takes time, and all conversations are valuable
Nick’s proposal has merits, but the current proposal amendments might fail due to Nick’s disagreement with the proposal
Token Delegations concerns are pointed out briefly
There is a Telegram group where UI providers are helping each other.
Excel spreadsheet as a Simulation for vote splitting was shared by Netto.
Demonstrating that providers with two budgets are at a disadvantage if budgets are used for ranking.
Delegates want to express preference via basic/extended budget, but providers may change to one budget due to the voting mechanism.
A suggestion to apply with just one budget has been voiced to mitigate challenges.
It’s pointed out that allowing separate voting for extended vs. basic scope leads to vote splitting, incentivizing everyone to propose one budget.
James summarizes three options: continue without change, proceed with the original proposal with amendments, or propose removing the basic vs. extended scope.
Request to add Brantly’s feedback/suggestion to the existing proposal has been unanimously well-received.
Feedback is requested from service providers and delegates regarding their stance on the proposal.
It’s important to hear from voters and create a better proposal if needed.
Alternative Proposal Suggestion
First, rank the projects and then rank the budgets in a second round.
There is concern about getting caught up in the granular details of voting mechanics, tho.
Priorities: focus on the ideal situation or the most practical solution.
Netto’s algorithm explanation should be in all UIs and should be added to the proposal as a reference.
Blockful is happy to help other UIs with implementation
Decide whether to include specific dates in the proposal
Delegates should vote on the UI during the testing period to find bugs and gather data.
You can drag them up and down to rank them (including their two different budgets)
Unranked candidates kept under “none below”.
A pre-processing step ensures the basic budget is always above the extended budget to avoid vote splitting.
Question about Non-Ranked Projects raised - how are they treated if someone else compares them highly?
Proposal 6.4 allows delegates to choose one of two budgets for applicants
Proposal 6.5 allows delegates to rank their basic and extended budgets separately
In 6.4, extended vs. basic funding is compared against itself, while in 6.5, extra funding competes with all other allocations.
A request is made for the voting UI to show the total cost of ranked items.
Displaying the total budget is considered important and should be included in the final version.
Suggested - showing a running total or single total of votes, with a “none below” option, to help voters understand the program’s scope.
Both proposals on the forum have pros and cons, but “they both do the job.”
Nick had reservations about the implementation complexity of the new voting scheme.
Concerned about potential issues with voting UIs showing different information.
Another reason was UX concerns – the inability to rank a company’s basic budget separately from their extended budget.
Wants to be able to express preferences more easily.
Believes 6.5 is simpler and allows for easier expression of preferences.
With 6.4, voting directly on Snapshot was not possible because.
Candidates could be ranked, but there was no way to enter a preference for basic or extended budgets.
The post-processing in 6.5 is a safety net to ensure that a candidate’s extended budget is not approved without their basic budget also being approved
6.5 is safer if the voter misunderstands something about how the vote works.
In 6.4, if someone misunderstands and puts Project A’s extended budget at the top and Project A’s basic budget at the bottom, the basic budget would be ranked at the top next to the extended, ranking that project at the very top.
In 6.5, if someone misunderstands and puts extended at the very top and basic at the very bottom, the only result is that they would actually be voting for the basic and then also the extended.
The two algorithms have similar trade-offs
The main concern is that 6.5 changes the game theory around service provider applications by comparing service providers versus service providers and extended budget versus all other budgets.
6.5 changes too much from 6.3, requiring service providers to change their applications and delegates to understand the new system.
Focusing on what produces the best capital allocation outcomes for the DAO.
Optimizing capital allocation should be the “North Star.”
There’s a concern about delegates needing to rank all candidates, which is a substantial time investment.
A separate centralized committee was suggested for next year that would review, approve, and ultimately fund applications and teams (pending discussion when the time is right)
Showing the total budget may help delegates prioritize ranking enough candidates for a good outcome.
Noted that the rules last year were confusing, and the original rules for this year were even more so.
The average delegate may not understand the proposals due to other commitments.
Both votes are up, and presumably, whichever one wins will be honored.
Snapshot is capped at 20 unless you pay for the Pro version
ENS might need to pay for it for the SPP vote.
There will be a JSON manifest.
The JSON manifest lists all the choices (basic and extended proposals for each provider) and metadata to group them programmatically.
The intention is to have that included with the Snapshot vote to have onchain reference of the values that will be used to calculate the final results.
There was a discussion about surfacing how much of a provider’s total budget has been allocated in the UI.
The concern is that showing a running total might lead people to stop ordering choices once they hit a certain budget, which could skew the results.
