[Temp Check] [Social] Service Provider Season 2 Vote Amendment Proposal
Abstract
EP 6.3 was passed with a budget of $4.5M for 2025 on the 25th of February and pertains to Service Provider budgets and allocation mechanisms for 2025. After broad discussion between delegates, working groups and service providers, a proposed change to the voting process is now being presented for vote.
Vote
This is a proposed amendment to the evaluation criteria for Service Providers. On April 1st there was an Delegate All Hands meeting in which many delegates expressed the desire to be able to fine tune their vote in order to express preference over not only the teams, but also their respective budgets. This was followed by extensive discussion between delegates, working groups and Service Providers, leading to the below amendment:
The goal here is to propose a new rule change while keeping the same properties as having a single budget be decided in one simultaneous vote.
Current Evaluation Process, as voted on snapshot
Evaluation Process
Projects are assessed in ranked order:
If âNone Belowâ is reached, evaluation stops.
If the candidate has been part of the Service provider program for at least a year AND if the extended budget fits within the remaining two-year stream budget, assign to the two-year stream . Subtract the extended budget from the two-year stream budget.
Assign to the one-year stream if:
The extended budget fits the one-year budget. Subtract its extended budget from the one-year stream.
OR if the basic budget fits the one-year budget, subtract the its basic budget from the one-year stream.
If none of these conditions are met, the project is eliminated.
New proposed rule amendment
The vote will present both extended and basic budgets as separate options and a given voter can pick either budget to rank their candidates. They do not need to rank both budget options separately, as they are considered the same candidate.
The rank of each candidate will be the rank of itâs highest ranked budget option, according to a Copeland methodology (using average support as a tiebreaker). Then a pairwise comparison will be made between the two budget options and the preferred one will be set as its selected budget.
Vote Processing Algorithm
Votes Preprocessing:
For providers with both basic and extended budget options, the algorithm enforces the lowest option to be ranked immediately after the highest option (of the same provider).
If a provider has only one budget option, no special enforcement is needed for that provider.
This grouping ensures accurate pairwise comparisons between different between different providers and then budget options from the same provider.
Pairwise Comparisons (copeland):
For each pair of candidates (provider), we calculate the total voting power supporting each over the other.
A candidate wins a head-to-head matchup if the total voting power ranking them higher exceeds that of their opponent.
Each win contributes 1 point to a candidateâs Copeland score.
The pairwise comparison between basic and extended must also be stored, for defining the preferrence on the budget.
âNone Belowâ Handling:
The âNone Belowâ option serves as a cutoff point in a voterâs ranking.
Candidates ranked above âNone Belowâ are considered ranked.
Candidates ranked below âNone Belowâ are considered unranked by that voter.
A ranked candidate always wins against an unranked candidate in pairwise comparisons.
Scoring and Ranking:
Candidates are ranked by their Copeland score (descending), with average support as a tiebreaker.
Allocation Process
Budget Type Determination:
Each providerâs budget (basic or extended) is determined by their internal head-to-head match result.
Stream Allocation:
Candidates are processed in Copeland ranking order.
Candidates that are in top 5 and were selected in SPP1, are elegible for the 2-year stream.
All other candidates receive allocations from the 1-year stream.
From top to bottom, try to fit projects in the 2 year stream budget, and then on the 1-year stream budget using the standard knapsack algorithm, stopping once budgets are exhausted or None Below is reached.
If a service providers extended scope got a majority vote over basic scope and the extended scope doesnât fit into the remaining 1-year budget but the basic budget does, then the given service providerâs basic budget is included.
If a candidate is ranked below âNone Belowâ, theyâre rejected regardless of budget availability.
Budget Transfer Mechanism:
After processing the top 5 candidates, any remaining 2-year budget transfers to the 1-year stream. Final 1-year budget = (Initial 1-year budget) + (Leftover 2-year budget).
Rejection Criteria:
A candidate is rejected if:
Theyâre ranked below the âNone Belowâ option
Thereâs insufficient budget
Updated Timelines
The initial proposal stated a submission deadline of March 31st, and vote to begin soon after that. Below is the proposed timeline for the amended process:
This vote will be conducted over the next 5 days. Then, if the vote is successful MetaGov will be interfacing with voting UI teams to ensure sufficient testing and timelines before a the final SPP vote.
Conclusion
If this amendment proposal passes, the MetaGov working group, delegates and governance UI providers will enact the updated proposal process.
We would like to thank everyone who has taken the time to be involved in this discussion and have been blown away by the level of alignment & productivity throughout. Extra thanks to AVSA.eth who drafted this updated voting process!
Itâs unclear to me how this algorithm is supposed to work. Is this intended to:
a) Describe how individual ballots are preprocessed before the voting algorithm is executed, or
b) Describe a modification to the Copeland algorithm that changes how ballots are compared, or
c) Describe a postprocessing step on the outcome of the Copeland algorithm?
I think a more thorough and mechanistic explanation of the intended modification is needed here, as the current description seems ambiguous, at least to my uneducated eye.
Likewise I donât understand whatâs being described here; earlier it says that each user should vote for only one of the two options, so wonât any attempt to do a pairwise comparison between them fail to produce a sensible result?
Iâm concerned that this change, coming as it does at the last minute and further complicating an already novel and complex voting system runs a high risk of introducing errors in the algorithm, specification, or implementation in UIs that compromise the integrity of the result. This is further compounded by pushing these changes through under urgency.
I would personally be much more comfortable with a change that preserves the existing voting algorithm such as allowing nominees to separate their proposals into more than one line item, or a decision to take this as input for the next round. We could also choose to institute a âshort roundâ of 6 months under the current rules while alternative options are explored and pursued.
We are inferring two questions from the single ranked choice: the rank of all candidates and which budget they will have.
Let me try a better wording:
A Copeland score will be calculated for every company (NOT their individual budgets). This will be done by considering only the highest ranked budget for each company on the ballot as the intended rank for that company. This, of course, can be abstracted away in the UI.
For each company, we will also make a direct comparison on which of their budget is the most preferred one. This will be their selected budget for the remainder of the algorithm.
Once the overall rank is created and each budget selected, the algorithm runs even simpler than before. We try to fit each company on the two-year stream, then in the one-year stream and if it doesnât we move to the next, until we reach âNONE BELOWâ
Ranking companies on Copeland instead of individual budgets is important because that particular algorithm rewards uncontroversial candidates. This is beneficial in elections if there are two major candidates (call them red and blue) which are loved by nearly half of the population and hated by the other, which require voters to pick the âleast badâ. Copeland in that situation would reward a third candidate which isnât loved by anyone but considered acceptable by most. In a case in which a single candidate is represented on the ballot by two entries who people have strong opinions on, then the algorithm will âseeâ that as a controversy.
I would not push any hard date, but make it dependent on a successful implementation by teams (7 days without finding a bug between two independent implementations, etc). This wonât be happening by April.
This makes a lot more sense, thank you. My concerns about implementing this in a hurry, and the complication it adds to an already novel and complex voting algorithm remain, however.
This doesnât make sense to me. The algorithm doesnât know how strong someoneâs opinion is, only the order they rank things.
Ranking projects is semantically different to ranking companies, for sure - but Copeland should be equally competent at ranking any sort of thing competing for resources. Allowing companies to specify multiple independent projects if they wish to have them evaluated separately adds the expressiveness delegates have asked for, more comprehensively than the proposed change, and doesnât require any changes to the voting algorithm.
Hereâs an example: There are two service providers, and a budget of $1M. Provider one is proposing to use the entire budget to accomplish two projects. Project one is universally agreed to be absolutely essential to ENS. Project two is of niche usefulness at best. Provider two has a single project, and wants $500k for it; the project is important, but not as important as project one.
In this scenario, we have to either choose projects One and Two, or project Three. We canât choose One and Three, even though thereâs budget to cover it. We can almost get this expressiveness with âbasicâ and âextendedâ scopes, but only if Provider One divides their budget up accordingly, and this isnât possible if a provider has more than two projects on offer.
Further, itâs clear that both providers should prefer this system. Provider One has to either take the gamble on asking for the full budget (and get all or nothing), or give up on Project Two to improve their odds. Provider Two sees their more popular project being hedged out by a less popular one because of the bundling. Again, Basic/Extended scopes give a similar result but only in this simplified case.
Iâd be super interested in if any of the other delegates or service providers share Nicks concerns.
I know thereâs been at least 3 independent meetings between delegates and service providers where there was agreement that allowing voters to differentiate between basic and extended scope is a good idea!
I think this is a good idea. I think this is preferential to what was initially proposed. My interpretation was that all delegates on the various calls about this were in agreement.
As I said on Telegram, I also agree with this. Allowing companies to express multiple different products and to split things as deliverables is expressive. There is value in a voting mechanism that does not throw the baby out with the bath water when delegates think that the totality of a companies ask is excessive (in the current setup) but acknowledge that specific elements are a huge value add to ENS.
That said, my understanding of delegateâs opinion (from the calls) was that the proposed modifications are conceptually small enough to not necessitate drastic changes to Service Provider applications that have been prepared and submitted. There will be a period when applicants can change their applications but they do not have to.
My understanding is that more fundamental changes to program design will be iterated on for the next iteration of the program specifically to avoid rushing anything in the here and now.
TL;DR - I am in favour of these proposed changes. They are better than was was previously proposed albeit not perfect.
On both of the last SPP calls thereâs been demonstrations from @alextnetto.eth showing this displayed in a very straightforward way. As well as team members from Lighthouse and Agora stating that theyâre spinning up this UI.
Letâs say someone is the last in line to get funded. Their Extended scope got the majority vote over Basic scope. But their Extended scope doesnât fit in the remaining budget, but their Basic Scope does. In such a case, should we default to someoneâs Basic scope?
To clarify my post after my conversation with @James, what I mean by demo is a place where service providers and delegates can run simulations. This does not need to be a full blown UI. A spreadsheet would do or even a script, where one can enter:
Inputs
Budget: 1,000,000
Applicants: A- basic, A - extended, B-basic, C-basic C-extendedâŚ
Voters: letâs say 10 of them, with varying voting power
Section to simulate the vote.
Section to show the result, that updates based on inputs.
This way we can turn words into code/algos. This would be helpful to game out edge cases.
I also realize this may not be feasible, so this is a comment not a request.
Think of an extreme case in which an election runs in which company A and B presents a single budget and company C presents 3 budgets. Now the total of possible pairwise comparisons is 10, but of these only 3 are between different companies. It means that beating A or B will get 1 point while beating C gets you 7 points. Suppose C1 is considered the strongest candidate but C2 and C3 are the weakest. In this case, A and B get each 2 points for beating these candidates, and now C has to beat its own budgets in order to make up for it.
Itâs not the end of the world, but this might be enough for candidates simply not to put forward a second budget.
Something which is interesting is that the UI that Blockful is working on, is backwards compatible with Snapshot because it enforces those decisions on the front end. When you drag a Company, youâre actually dragging all the budget entries, and the âtoggleâ is really just inverting the order.
It means that in their UI, if you rank project A (extended), B (basic) and then C (single budget), you are submitting a ballot expressing the preference of: A (extended) > A (basic) > B (Basic) > B (Extended), C (single budget).
This matters because if everyone used an interface that did that (or even if the majority of voters did), then the resulting rank shown on snapshot (comparing all budgets as separate entries) or the one proposed in the algorithm (compare all candidates as a single entity) would show the same result. In blockchain parlance, that would be a âsoft-forkâ of the voting algorithm, meaning that if a majority of the voters used the proposed interface, then it would essentially be a change of the rules without having to hard encode them.
This could be a valid option in my opinion. Voters who would prefer to express their votes by ranking all budgets could still go to snapshot. Thereâs a valid concern that the fear of vote splitting on snapshot (regardless if it exists or not) might make some providers put forward a single budget anyway. But this could be a way to allow the extra expressiveness without changing the core ranking algorithm.
This is a valid point. In the proposed algorithm we wouldnât, and this sort of defeats the original intent of having two budgets, right? We could add the option to reduce the scope in this case.
What if teams simply didnât have an extended scope? The extended scope seems to be the most complicating element of this calculation for both service providers and delegates.
As a service provider ourselves we didnât do an extended scope because it felt like a nice to have that added complexity to the decision making process. Maybe itâs too late to make this change, but wouldnât that be simpler?
Letting delegates choose between budgets is positive as long as the changes in the voting mechanism donât create negative externalities (like splitting the votes if the provider has 2 budgets).
The proposed solution above, which was discussed at the 1st April Metagov call (Delegate all-hands), does address this concern and lets delegates express their preference without changing the properties of the initially proposed voting mechanism (well explained by Avsa on the above posts).
Thatâs also an option, but it brings an all-or-nothing situation for providers who want to execute a larger scope because they see the necessity.
If delegates donât see the necessity of this larger scope, by having a basic budget, at least delegates can express they want a smaller budget, and weâll probably have more teams funded.
Supportive of the proposal. It creates better outcomes for capital allocation than just approving all the extended budgets for top-ranked providers and does not change much things (probably nothing) for our SP application.
Also, for full context:
We started Monday night to implement the algorithm for the voting mechanism previously approved on EP6.3. Then after the Metagovâs call, we started adapting toward aboveâs direction, which actually are small changes.
Whatever the DAO decides, for the current and this new voting mechanism, we are on track for the UI to be shipped.
This is a great point, personally I believe it should default to the basic scope.
Our original application only included 1 ask, but after discussing the extended/basic scope with other SP applicants and delegates we felt compelled to represent both.
Appreciate the engagement in this thread â itâs clear thereâs a shared commitment to fairness, clarity in voting, and effective decision making.
A few common themes seem to be emerging:
Clarity & transparency: Thereâs some understandable concern about how the Copeland method and pairwise comparisons play out, especially with so many line items. I think there was already a concern around complexity of this new model even during the first all delegates call. Perhaps some visual explanations and examples could go a long way in making the process more intuitiveâŚ?
Simplicity vs. flexibility: There is a sentiment of itâs best to keep the current voting mechanism, at least for this round. But thereâs also recognition (both on the calls held on the topic and in the responses here) that separating base and extended budget can give delegates a finer tuned voting opportunity and support more nuanced decision making that would perhaps keep the budget allocated to the programme in check.
A phased approach makes sense to many â test improvements first, then consider deeper changes. That is definitely a sentiment worth listening to.
That said, we now have an actual UI built in record time by @alextnetto.eth and his team to support the above logic â and thatâs the best possible ground for meaningful testing in my view. So lets see how this stands up
Thatâs because you are still thinking in terms of funding companies, rather than projects. The point of this program is to fund projects, not companies. If your project is better than 3 other projects, it should get 3 points (not 7 - not sure where that figure is from). If a company is on the cutoff, only their strongest projects should get funded, in preference to their weaker ones.
To be clear, thereâs no âsplitting votesâ in Copeland. If you offer two budgets and all your voters rank them adjacent to each other, the end result is the same as if youâd just offered one budget - except if you end up right on the cutoff, in which case youâd get one project funded instead of nothing.
The results are different if someone ranks other providersâ budgets in between two of your own proposals - but this is as intended, itâs allowing the voter to express their preference between proposals across different candidates. You could bundle them together into one proposal, but in that case youâre making the gamble that the voter wants your more popular project enough to overcome the additional cost of the combined budget. In reality you should expect that a single proposal for $x+$y will rank lower than the better of $x or $y alone.
I would be ok with simplifying the amendment rules to:
Budgets are ranked individually
Once one of your budgets are selected, all lower-ranked budgets are eliminated
I would strongly encourage voters to use the simplified UI that would show individual companies instead of all the budgets separately (and any other alternative UI that is live by then) but we wouldnât need to enforce the reordering by rules. If enough people voted by bundling all budgets from the same company together (as that alternative UI presented enforces), then both methods of counting the votes would end up in similar places.
This way we can get this amendment passed with both Simplicity and Flexibility., like @simona_pop said in her usual beautifully crafted NVC way.
But why? Itâs so much simpler to just let teams post multiple budgets if they want! They can choose if and how to split things up, it gives everyone more flexibility, it doesnât change the voting algorithm and thereâs literally no downside.
