[Temp Check] [Social] Service Provider Season 2 Vote Amendment Proposal

[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

  1. 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.
  2. 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.
  3. “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.
  4. Scoring and Ranking:

    • Candidates are ranked by their Copeland score (descending), with average support as a tiebreaker.

Allocation Process

  1. Budget Type Determination:

    • Each provider’s budget (basic or extended) is determined by their internal head-to-head match result.
  2. 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.
  3. 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).
  4. 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! :unicorn_face:

7 Likes

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.

The parts quoted were from @AvsA’s post so ill let him reply :slight_smile:

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.

2 Likes

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.

3 Likes

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.

3 Likes

Given how complex this is, it would be great to see a live demo of “Voting Experience A” vs. “Voting Experience B,” then vote.

I suspect I’m not the only one who isn’t confident that they fully grok what’s being proposed.

2 Likes

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.

1 Like

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?

2 Likes

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.

2 Likes

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.

3 Likes

Service provider here:

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?

8 Likes

I’ve compiled this table which might be helpful for the discussion. It’s useful to know what we are debating about in practice.

Company Basic Scope Extended Scope Delta
AlphaGrowth $400,000 $800,000 $400,000
ZK.Email $400,000 $800,000 $400,000
Blockful $400,000 $700,000 $300,000
Unruggable $400,000 $700,000 $300,000
3DNS $500,000 $700,000 $200,000
Ethereum.Identity.Foundation $500,000 $700,000 $200,000
JustaName $400,000 $600,000 $200,000
NameHash.Labs $1,100,000 $1,300,000 $200,000
Namespace $400,000 $600,000 $200,000
Agora $300,000 $400,000 $100,000
dWeb.host $300,000 $400,000 $100,000
EthLimo $700,000 $800,000 $100,000
Wildcard.Labs $300,000 $400,000 $100,000
Curia.Lab $300,000 – –
Decent $300,000 – –
Enscribe $400,000 – –
GovPal $300,000 – –
Lighthouse_Labs $400,000 – –
Namestone $800,000 – –
PYOR $300,000 – –
Tally $300,000 – –
Unicorn.eth $300,000 – –
Web3bio $500,000 – –
WebHash $300,000 – –
x23.ai $300,000 – –
1 Like

From blockful’s side as a service provider:

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.

3 Likes

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.

3 Likes

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

2 Likes

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.

2 Likes

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.

1 Like

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.

2 Likes