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.
Concerns around the vote going live with only a 24-hour room for testing.
Not enough time to do testing before the real vote.
If no bugs arise in the next 24 hours, the live vote could proceed in theory.
Allowing more room for testing would allow for:
testing with multiple UIs
confirmation with Netto’s spreadsheet
observation of finalized results after the vote ends.
Concerns are more focused on the algorithm showing the right results rather than general bugs that may occur during voting.
The proposal has gone up, and people can vote, but the rendering of final results after voting closes hasn’t been tested yet.
If there are discrepancies in results with different UI providers, we postpone. Otherwise, we can proceed. (temporary consensus)
Live communication will be provided in the ENS SPP group by the MetaGov.
Test Vote, Official Vote, and Timeline
Suggestion to reach out to delegates and test these UIs so they understand how the process works and get familiar with the UIs.
Plan is to communicate the updated timeline in the forum and on Telegram.
Testing will continue, with updates from UI providers.
The official vote will be postponed to the following Wednesday (May 7th).
Direct voters to Lighthouse and Blockful UIs with clear voting instructions.
Consider video tutorials and highlighting the Agora interface as read-only.
Final
The test vote starts this Wednesday (April 30th)
The official vote starts next Wednesday (May 7th)
We should have plenty of time for testing like this.
Next MetaGov call will be one day before the vote officially opens, and it’s Delegate all-hands call – good for last-minute demos, feedback, Q&As, fixes, etc.
SPP is inefficient, delegates aren’t equipped, have no time to review 25+ applications, no incentives, or are misaligned.
Solution: Create a paid technical committee to review and guide funding. This would be properly compensated, it would bring more accountability, and better capital allocation.
Delegates are overwhelmed, lack time/context, burnout is real, no technical expertise in some cases to asses what’s best for ENS.
No one calls out bad work; no accountability or cancellations for SP stream for underperforming projects.
Solution: Add an admin layer, improve transparency, allow iteration, etc.
Agreed that these changes are too big to do for this year’s program.
Overall sentiment: SPP is valuable, but there’s room for improvement.
Metagov will retroactively reward all contributors who helped make this program and vote move forward, and go smoothly.
MetaGov will collect feedback from applicants and participants of the SPP to improve it for the next season.
An anonymous feedback mechanism was suggested.
Need to optimize the SPP for ROI for the DAO and results for ENS
Thomas’s idea of a committee with market understanding, capital allocation expertise, and technical know-how is mentioned as a potential future improvement.
Important to set a direction/mission for the DAO and ENS protocol
Delegate experience, redelegation, or “retirement” was discussed, highlighting that most active delegates are the best voting body for ENS DAO.
All undelegated votes pose a governance risk.
A culture of open talk, feedback, and criticism needs to be created where people talk openly and even attack proposals, highlighting concerns and areas for improvement.
Incentivizing delegation and rewarding active delegates with more votes is crucial.
Many other ideas and suggestion were bounced around such as:
liquid democracy,
filtering applications to decrease the time investment,
‘conviction voting’ to show if they are happy or not happy with how the funded project is doing,
panel of experts to go through applications and allocate funding,
private voting,
and many, many other ideas…
All of these will be collected through feedback forms and upcoming forum discussion posts, and temp checks, and put up for further discussion.
