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.
TL;DR – OpenBox will acquire some TLDs and wants ENS DAO to invest in this in return for 10% and will develop the Open Domain Protocol for other TLDs to essentially become ENS-aligned/compliant.
It was suggested to invite @Brandley to the calls next week and discuss and do a Q&A
2.4. Executable Proposal Process and Call Data Verification
The goal is to create a more robust and documented proposal lifecycle
Optimising and coordinating the process of Call Data Verification
Proposal validation improvement – We need to figure out how to validate what goes onchain.
Discussion was led on how to properly do this potentially using Tenderly links for validation.
Onchain data should be the single source of truth to avoid errors from duplicating information.
The idea is to build this as a permissionless open-source system in a public way so that anyone can spin up their own frontend.
3. Open Discussion
Next call is the all-delegates call
MetaGov will start reaching out to major delegates to invite them
Last week’s notes were not posted because @cap, nor anyone else, was able to post in the MetaGov meeting thread.
Will be fixed promptly
SPP2, counsel is doing due diligence, there’s an ongoing talk about ToS… things are moving forward.
The main focus has been on integrating the Web2 side of domains to Web3
Runs the very first ENS-native Web2 TLD on the market with .box
ICANN TLD auction is set for next year.
Proposal aims to position ENS as the identity layer for tokenized TLDs.
Key Points
Mission: Build a global standard for TLD tokenization, issuance, and management.
.box is token-wrapped and ENS-compatible – a lot of lessons learned and experience gained through running .box domains.
Namechain will be the hub for tokenized DNS domains (switching from Optimism).
Others are trying to do the same thing and are direct ENS competitors.
OpenBox, together with Labs, will be working on partnerships with others like Coinbase, Ethereum foundation, etc, to help them with their own TLDs and tokenize them through ODP.
A comprehensive technical breakdown of how these things work together was discussed to determine the technical relationship between: ENS, Namechain, ODP, 3DNS, etc.
ODP needs to handle its own registrars
The relationship between all of these components is still not clear, so more questions will be in the Discussion forum.
Legal compliance required with Cayman regulations; ENS Foundation directors will be involved; More to be discussed by addressing the questions in the forum post posted by other Delegates.
It’s going to be open-source as much as possible, and OpenBox charges a fee for registrations.
Decision making is at the operational level by Josh and the Board of Directors for some other high-level decisions.
ENS is choosing OpenBox to be its official non-exclusive registrar with this deal.
DAO revenue will come from onchain economic activity / transaction volume.
ENS has very good cooperation with ICANN already and is best positioned to tokenize domains.
People are generally supportive of the proposal – from the TLD, technical, and Investment perspectives.
Next Steps
More detailed technical discussion to follow on the forum.
A social proposal is expected next.
Idea raised: vesting ENS tokens to align OpenBox long-term and have more skin in the game.
Follow-up live discussion planned during the next MetaGov call.
ENS team attending ICANN event in Prague next week.
Vision: grow from 300M domains to 3B usernames.
Need to stay competitive – many others are entering this space.
