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

DAO-Wide Temp Check
22

You mean someone could post a $300k project and a $500k project and the DAO could either fund 300, 500 or both at 800?

I think it would require applicants from changing their applications fundamentally, and also it’s a lot more cognitive load from delegates to have them rank individual projects from each team. I also think it’s good to give leeway for teams to adapt their work, build new things that weren’t clear were necessary or stop building something that becomes irrelevant as the market evolves. That’s why I prefer to think in terms of teams, not “build this thing to spec”.

1 Like
23

This is not true. This is not what the rules we voted on say, it’s not how Alex has talked about the program over the last year and a half, it’s not how season 1 functioned, and it’s not how most people conceive of the program.

If you’d like a program to exist more as you’ve described, that’s fine but you’ll need to create that program, rather than claiming the existing program is already that when it’s not.

The downside is that, as @AvsA says above, it would be different program and require a complete restructuring of every application and every group’s plans.

1 Like
24

I agree with @simona_pop’s comments that significant changes should be off the table for this cycle. The projects vs. companies discussion will be good for next year.

Focusing on the text of this temp check, I agree that providing the level of granularity suggested here would be an improvement, and it would achieve this with a relatively small deviation from the original specification.

While there are two less-than-ideal aspects to consider - the additional delay for applicants and the rushed timeline for UI development - I believe the benefits of this additional granularity outweigh both of these concerns. The previous Season 1 streams always had extra runway to specifically allow for delays in this vote. We can afford to take a moment on this if we want to.

1 Like
25

Yes; each budget would be independent.

My description of it as “projects” is a poor one - I should have said “independent budgets”. Each entry does not need to correspond to a single project; it simply gives teams the flexibility to split up their offering if desired.

Teams are also free to leave room for that in their objectives or deliverables. But the SPP is is for funding specific deliverables that ENS or the DAO needs. We should expect teams to describe what it is they intend to do in concrete terms.

Allowing teams to request multiple budgets is a smaller change than the proposed change, and comes with less technical risk because it doesn’t alter the voting process. If teams want to, they can still use it to replicate the effect of a basic/extended scope, too.

I continue to believe that the proposed change to the voting process is high risk, as it involves further complicating an already complex voting process, with multiple UIs, on a short timeline, and thus comes with the possibility of bugs that materially affect the voting process or its outcomes. If the options put forward are to leave the process as-is or to adopt this new change, I will accordingly be voting for the lower risk and safer option. I won’t be investing any further energy into trying to convince people that this is a bad idea, however.

1 Like
26

This would also require a vote for us to amend the SPP process as far as i understand right? But i support this as a way to solve for the primary ask from the MetaGov delegate all hands which was to allow delegates to vote on basic vs extended scopes.

Agree that we don’t want to rush this process and create bugs/risks. However we do not need to rush this process, this vote is regarding 25% of the entire DAOs yearly revenue, ensuring a low risk voting process where delegates can make a clear vote on this budget is the goal here. I would strongly lean towards prioritising impact at the expense of time.

1 Like
27

Yes, but any proposed change will require this.

28

Options

Proposed

The proposed mechanism is essentially “UI-as-truth”.

I think it would be fair to say that the nuances of the algorithm are not simple/quick to grasp. Without the custom built interfaces, delegates would be voting in an opaque manner through the snapshot interface which is, in my opinion, not great for democratic legitimacy or transparency.

Whilst it’s additional work I think these interfaces need to allow delegates to simulate how their vote will impact the result in advance of the vote being cast. If someone modifies their rankings, UIs should show exactly how that would change the outcome - interactive comprehension.

Bonus points for some sort of open-source implementation of the algorithm that produces deterministic outputs given raw inputs such that the UIs can essentially be audited.

Original

The original format was also unclear to delegates (as outlined in the various Metagov facilitated calls). The custom interface developed by Agora was not expressive enough for the manner in which a number of delegates stated that they wanted to vote.

The UI was also new, and as I understand there was only a singular implementation. It is similarly not battle-tested.

Thoughts

The approach thus far has been for potential Service Providers to tell the DAO what it needs.

I can’t help but feel that true simplicity happens if:

  • The DAO defines the need - “we need X”

  • People apply to deliver that need

  • The proposals are about how to meet the need, not whether it’s needed

It would minimise the load on delegates with clearly defined categorisations of work - we would avoid the situation where delegates have to compare another subname provider with a team doing something completely different (and novel).

That said, taking Brantly’s words, this idea is also:

Rushing

We don’t need to rush.

As a current Service Provider (and applicant) I am very much OK with this being delayed so as to allow for it to be done properly.

The idea that we would knowingly poorly allocate such a vast amount of money simply to avoid a week/month delay is not cool.

These conversations are also happening on public platforms. Potential applicants have an opportunity to state their positioning and opinions but the large majority have not. I can only work with available information, but thus far no-one (I believe) has explicitly stated that they have an issue with delays.

!!!

The ENS DAO is widely considered a best in class example of a DAO. We should absolutely strive to maintain it’s integrity, and should take the time to do this properly.

1 Like
29

I’ve been following the discussion and have been trying to grok what makes the most sense, but I think this made things clear to me. I’ve been finding it hard myself to understand how the voting process works and how things ‘fall through’ based on getting enough votes for their basic but not their expanded and how it might affect the vote and what gets funded. For instance I might only want to fund the team because I feel the expanded vote is what they should be working on, but because they only got funded based on their basic, it would have changed my vote/endorsement.

I think it’s clearer for me to see “this is a good feature, and this is a good team, therefore this should be funded”. It’s far easier to see what to support based on this too.

Applicants can choose not to restructure their applications if they choose and be considered as a team. I think looking through the projects myself, the hard part about deciding whether a team is worth endorsing/voting for is hard because many of the teams choose to do many different deliverables and I may only feel like 1 of 3 things are the most useful to the DAO/protocol.

Lastly I think lowering the risk to the vote makes the most sense, whatever we decide to do.

Actually this does make quite a bit of sense and is basically an RFP process.

I agree with this sentiment

2 Likes
30

Not only this should be discussed on the scope of a future program (not this specific amendment), but I think it’s fundamentally a different funding philosophy in my opinion. Who would be making these RFPs and deciding them? Would it be something where the DAO ranks some general ideas and then Metagov writes it to spec and then companies compete for the lowest bid? What happens if the market moves in the mean time and what made sense one moment doesn’t make sense the other? What if a company has a very bright idea to pivot that project into something better but outside the spec? What if the people who build it lack the refinement of those who had the initial idea in the first place, and instead of trying to build the best tool they just focus on delivering on their contract?

That’s why I’d rather trust teams. They put forth budgets of stuff they want to work on and they are loosely bound to it, but most importantly what we are saying is not “this thing needs to be built and I think this person will do it for cheap” but rather “I trust this team to continuously focus on finding innovative solutions for these problems and any new ones that might occur in the future”.

1 Like
31

RFPs definitely have their place, and we’ve used them in the past. But I do think there’s a lot of value in teams identifying what they see as a need and proposing to the DAO that they can satisfy that need, which is the space the SPP fills.

What I am less enthusiastic about is this tendency to bundle multiple unrelated offerings together and force people to vote for all or nothing. I would much rather that a team proposing to do three distinct things put forward three separate proposals. The advocates of the current amendment have made it clear that they see this kind of expressiveness as something to be explicitly prevented, however.

3 Likes
32

This isn’t the position. The position is that vote splitting in this manner can adversely affect a company that puts forth many proposals.

Let’s imagine a simplified Scenario in which there are only two companies and three voters (with different tokens amounts). Company A puts forward two budgets and company B only one. Let’s say the proposals are in all aspects identical, so most of the supporters of the company A put these in front, and B in second, while leaves the other budget unranked (in the bottom). Suppose these are the final results of the vote.

Screenshot 2025-04-09 at 12.49.25 PM
Screenshot 2025-04-09 at 12.49.25 PM2098×536 81.8 KB

In this example, even though company A has 75% of the support, it loses both head to head comparisons with company B, and thus loses the vote. Company B is the clear Copeland winner, and it would be the intended result if this was an election with 2 controversial candidates and one who’s everyone’s second best (Copeland rewards consensus and broad support), but for companies applying, they don’t care so much about which of their budgets gets approved, as long as one of them does.

–“But Alex, if A1 and A2 are identical, why would the voters put their secondary proposal under B? If they prefer company A over B, then they should put both budgets above B!”

And you’re absolutely right, they should! And if they do it this way, then the problem disappears. But the problem is, in practice, not all of them will, specially not when there are 50 entries to be ranked independently on snapshot. So it means that necessarily, some of these budgets will remain unranked, or ranked very much below the others. So it is an UI issue, and if everyone used the “right” UI it wouldn’t be a problem, but we can’t control that.

But more importantly: yesterday we had a governance call and most Service Providers who were there agreed that they feared this effect enough that if the budgets were to be independently ranked then they would only put forth one budget for fear of losing even a bit of a rank because of the effect.

So while I appreciate you’re defending more expressiveness, we have strong reasons to suspect the end result would be less options on the vote overall.

Finally: we could be wrong. Maybe most delegates will use the better UI and the snapshot vote result will match 100% and this whole custom algorithm was completely unnecessary. In that case we will have the data (just compare snapshot and agora+blockful’s rank) and next year can do without it. But if we don’t, and Service Provider candidates only put forth one budget, then we will never know.

2 Likes
33

Company A has 75% support for half the money. If they combined both their proposals together, the ask would be double what either of their split budgets is demanding, and it’s fallacious to assume that people would give the same support to a proposal that costs twice as much.

It sounds like you’re saying you don’t expect users to be able to express their voting intentions accurately under this system. Why do you believe it would be any easier for them to do so under your proposal?

This is effectively arguing that because incorrect information has already been effectively spread to everyone, there’s no point in trying to correct it or to do the right thing. It’s a poor argument for how to design a system.

That’s not actually my main goal; my main goal is to avoid further complicating an already very involved voting system, and the goal of my suggestion is to offer the expressiveness people have asked for without the additional complexity and risk.

34

Hey folks, I ran the convo through AI to get bullet points on where we are right now:

:green_circle: Supporters of the Amendment

These folks support allowing voters to choose between basic and extended budget options per service provider.

Why they support it:

  • More nuanced voting: Delegates can express finer-grained preferences (e.g., “this team is good, but not for that much money”).
  • Avoids all-or-nothing: If extended budget is too much but basic is fine, it won’t lead to full rejection.
  • UI already built: Blockful and Agora teams are working on interfaces to support this logic.

Key supporters:

  • James: Leading the charge to give delegates flexibility and ensure capital is allocated efficiently.
  • AvsA: Proposed the new logic; believes it gives a clearer outcome and mitigates vote splitting via UI tricks.
  • alextnetto.eth: Confirms UI implementation is simple and on track.
  • slobo.eth, simona_pop, 5pence.eth: Like the amendment but suggest more clarity, simulations, and phased approaches.

:red_circle: Opponents or Cautious Voices

These folks are concerned about the complexity, rushed implementation, and potential bugs.

Why they’re skeptical:

  • Too complex: Hard to explain, and Copeland + pairwise logic isn’t intuitive.
  • Too rushed: Making changes close to the vote risks mistakes, UI issues, and delegitimizing the process.
  • Prefer simpler approach: Let teams submit multiple proposals (e.g., “basic” and “extended”) as distinct line items instead of one bundled vote.

Key skeptics:

  • nick.eth: Prefers keeping current system and letting teams post multiple line items. Thinks Copeland is okay but doesn’t need new logic.
  • clowes.eth: Wants more transparency and simulation tools to model outcomes.
  • jefflau.eth: Prefers more explicit “this is a feature, fund it” clarity.
35

Nick you have expressed similar comments before so there might be a misunderstanding on how the budgets work: they are mutually exclusive. The extended budget always contains the scope of the basic budget, and selecting one excludes the other. We could argue if it could be a good idea to have them as separate projects in which you could pick either or both (I disagree) but that’s not how the current budgets were structured by the candidates so changing this now would be a big change and IMHO, inconsiderate to them.

So in the scenario outlined, if a voter expresses their preference as A1 > A2 > B, they’re saying they prefer company A over B and budget A1 over budget A2. Once budget A1 is selected, A2 is excluded from the competition. That voter is NOT expressing they want to fund both A1 and A2, and only then fund B. So in this scenario, if 75% voters are expressing their support for company A they’re not expressing support for both budgets, but to either budget. If A is selected they will only get one of them (and we can consider their difference in value to be small enough that voters are almost identically split on it - but it’s not twice)

1 Like
36

But you presented this scenario as a counterargument to my suggestion of allowing teams to present multiple budgets if they want to. Why would you bake in an unstated assumption that only one of the budgets can be approved, when that’s not what I’m proposing?

In any case, if companies wish to have dependencies between budgets, they can simply say “We can’t accomplish A2 without A1 - so please do not rank A2 above A1”.

If the intention is for the budgets to be connected, then they can simply instruct delegates as I suggested above, and the group of A2 > B > A1 voters in your example disappears, and A wins the vote. Even without the instruction, it doesn’t make sense to expect that people would rank “extra funding for A” budget much higher than the “basic funding for A” budget in the first place.

37

One other problem I see with the current proposal is that I don’t think it works for what I expect to be a very common scenario, where a team puts their most vital work in the basic budget and “nice to have” items in an extended budget.

Let’s suppose a scenario where there is a $1M budget and some teams:

Team Alice wants $400k to build something absolutely vital to the success of ENS. They also propose an extended budget - for an extra $200k, they’ll make it easier to use and prettier.

Team Bob wants $400k to build something else pretty awesome - not quite as important as Alice’s infra, but still really useful to have.

There are a bunch of other teams making various other things, ranging from important to trivial.

As a delegate, I think Alice’s UX improvements are important, but not as important as Bob’s work. However, under the proposed system, I have only these choices:

  1. I rank Alice above Bob, and choose Alice’s extended budget. This reduces the odds of Bob getting funded, even though I believe his work is more important than Alice’s UX improvements.
  2. I rank Alice above Bob, and choose Alice’s basic budget. This gives the best odds of funding Alice and Bob, but Alice’s UX improvements don’t get funded, even though I believe they’re more important than some other things on my ballot.
  3. I rank Bob above Alice, and choose Alice’s extended budget. This at least means the really important stuff is at the top of the ballot, but hurts Alice’s chances and doesn’t reflect what I believe is the most important project.

Here’s an alternative proposal that I think might actually make everyone happy:

  • Allow teams to submit multiple budgets. Each budget is cumulative - eg, builds on the previous one. We can limit this to two, effectively replicating basic/extended scope, or allow teams a little more freedom if desired.
  • Modify UIs to enforce that budgets for a single team must be ranked in ascending order. Thus, I must always rank Alice’s basic budget ahead of her extended budget - but there can be any number of other entries between the two.
  • Modify the voting algorithm with a simple preprocessing step: if a team’s budgets are out of order, move the lower item above the upper item. If all UIs enforce the ordering restriction, this is a no-op, but it prevents inconsistent results if people vote using UIs that don’t enforce ordering.
  • Run the voting algorithm as originally specified, but without the “basic/extended” logic originally described.

This proposal doesn’t have any issue of “vote splitting”, has a simpler UX than asking people to both rank teams and select a budget from each, and allows more expressiveness, eliminating the issue I described above. Further, it requires only minor changes to the existing UIs and voting algorithm, reducing technical risk.

2 Likes
38

I feel like this quote from the Telegram chat explains Nick’s position succinctly. I agree - this is a valid want.

I think, if I am understanding correctly, that this is also aligned with what (I believe) a number of delegates want - the ability to prioritise the basic budgets of many over the extended budgets of few.

It’s a slightly more complicated interface to implement, but totally feasible.

The piece that some took issue with previously was that such an interface would plausibly have close to 70 different options to order. Perhaps the interface could couple both asks together when moving them about with basic above advanced, and then users that want more fine-grained control can decouple them?

Does this pre-processing of votes submitted through other non order-enforcing interfaces not make Snapshot data non-authoritative?

It feels a bit like "Well, you didn’t tick the box properly, so we’ve interpreted your vote differently” where properly is arbitrarily (albeit reasonably) defined by us, the DAO.

Easily mitigated with a clear ‘This is how this works’ at the top of the on chain proposal with appropriate permalinks, but its worth considering.

39

Yes, but so does the originally proposed amendment. Snapshot is used for the source of voting data, but the ranking displayed is not the source of truth. If most people vote using a compliant UI it would be, which is why it’s important to clarify all that.

40

I find this a very clever solution that achieves similar results with an even simpler algorithm. To clarify:

  • Each candidate proposal is broken down in two independent entries. So if a candidate has a proposal structure that is 400k basic and 600k extended scope, then it’s broken down in two entries in the ballot: “Candidate A - Basic - 400k” and “Candidate A - Extended - 200k” (notice that in the extended proposal we are just putting the value of the difference from the basic)
  • When considering a ballot, IF the vote ranks Basic under Extended, then we modify the ballot such that basic is ranked directly above extended. For teams building a voting UI, we will ask them to enforce that when writing the ballot, but if someone submits a “non compliant” ballot, we simply consider it as if it was changed in this way.
  • The ranking of all entries (including None Below) is then calculated in a standard Copeland method.
  • Once the ranking is complete, from top to bottom, we will try to fit projects in the 2 year stream, and then on the 1-year stream using the standard knapsack algorithm, stopping once budgets are exhausted or None Below is reached.
  • Once we have ranked 5 projects OR if a project’s budget won’t fit in the 1 year stream we will remove any remaining budget from the 2-years and bring it to the 1-year stream.

Nick’s new proposal allows more detailed expressivity, while simplifying the current algorithm by a lot. Some of the properties that needed express rules (like downgrading a project’s extended to basic if it wouldn’t fit) now become inherent properties of the system. As far as I can tell it removes the vote splitting issue (at least in the example I provided), but we need some time to evaluate it.

It presents some UI challenges on ranking 50 different entries, but we might be able to overcome this with better interfaces.

41

This is almost equal to the proposed amendment and acknowledges the existence of vote splitting (by partially enforcing options from the same provider to be together). I truly believe that the proposed amendment is still a better fit. This has slight differences that create more work by all parties involved (SPs, delegates, …) and changes in game theory:

Vote splitting concerns for extended scopes: Under this alternative mechanism, extended scopes would compete not just against the basic scope of the same provider, but also against all other providers’ budgets. This creates a disadvantage for extended scopes that doesn’t exist in the current amendment. Service Providers would naturally respond by concentrating more work in their basic budget to avoid this penalty.

For instance, if Blockful were to adapt to this mechanism, we would likely restructure our application to place more work in the basic scope rather than using extended as intended - a nice-to-have addition. This seems to be different from the original purpose of the two-budget approach, which was more about the basic budget as a fallback rather than extended as a nice to have.

Implementation and voting complexity: The current amendment introduces minimal complexity for delegates - simply asking “After ranking providers, which budget do you prefer (basic or extended)?” The alternative would require additional UI changes and create a more complex voting experience, when many delegates have already expressed concerns about the effort involved in evaluating proposals.

Two-year stream considerations: The possibility of varying budgets across years (e.g., 600k for year one, 400k for year two) would require more detailed breakdowns in proposals and complicate stream management.

I’m only judging the mechanisms and their externalities—nothing else than that.

The current amendment already addresses delegates’ needs effectively: it’s straightforward, introduces no negative game theory changes compared to the original proposal and has achieved consensus during discussion calls. It’s already implemented, tested, and being adopted by UI providers. I see no compelling reason to pursue a different solution when we have one that works and requires minimal effort from all involved parties.

About the voting UI, blockful is happy to build toward whatever solution the DAO decides, but we are also focusing on our other deliverables as well while reallocating the team to solve and test this asap, from our resources. I believe I shared my perspective based on extensive simulations and consideration of the different mechanisms, and I appreciate everyone’s thoughtful engagement on this topic. At this point, I’ll be engaging only when the DAO has decided which mechanism to use, as Blockful needs to direct our attention to other deliverables.

3 Likes