I’ve attempted to clarify @nick.eth’s proposal in a form that could be used directly for a Snapshot vote. Nick, let me know if this reflects your intent.
1. Proposals
Teams can propose a basic budget, and optionally an extended budget, which is listed as the extra amount they’d like on top of the basic. The ballot would include all budget options as independent entries to be ranked independently.
Candidates will have a chance to edit their proposal, but as it stands, these are the current asks:
Company
Basic Scope
Extra Ask
AlphaGrowth
$400,000
+$400,000
ZK.Email
$400,000
+$400,000
Blockful
$400,000
+$300,000
Unruggable
$400,000
+$300,000
3DNS
$500,000
+$200,000
Ethereum.Identity.Foundation
$500,000
+$200,000
JustaName
$400,000
+$200,000
NameHash.Labs
$1,100,000
+$200,000
Namespace
$400,000
+$200,000
Agora
$300,000
+$100,000
dWeb.host
$300,000
+$100,000
EthLimo
$700,000
+$100,000
Wildcard.Labs
$300,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
–
2. Preprocessing Ballots
Before counting, each ballot is checked: if a voter ranks a team’s extra budget above its basic, the basic entry is moved directly above the extra. No changes are made otherwise.
3. Creating the Rank
Each entry is treated as a separate candidate and ranked using the Copeland method. If two entries have the same number of match victories, average support is used as a tiebreaker.
4. Budget Allocation
Once ranking is complete, entries are evaluated in order, using a total budget of $4.5 million:
Assign an entry to the 2-year stream if it is a current service provider, ranked in the top 10, and assigning it would not cause the total allocated to 2-year grants to exceed $1.5 million.
If those conditions aren’t met, assign the entry to the 1-year stream if its budget fits within the remaining total budget (regardless of the 2-year cap).
Stop the evaluation if the $4.5M total budget has been fully allocated, if there are no more valid candidates, or if “None Below” is reached.
Yes, that sounds correct. I would expect UIs that support this would prevent users from ranking the extra ask above the basic budget; this makes the new preprocessing rule a safety net for UIs that don’t enforce it.
We could also choose to let candidates specify >2 budgets; I’d be curious to hear if any are interested in doing that.
Finally, the rules should specify that unused 2 year budget gets added to the 1 year stream.
It does. I’ve reworded the rules to simplify them: instead of there being 2 budgets that there are rules to move one to the other, I think it’s easier to think about one big 4.5M budget, but at most 1.5 of these can be used for the 2y stream. The result is the same, but there needs less rules.
I also made an example interface, based on spp.vote website. Votes would start by simply dragging candidates from the bottom of None Below to the top, and then if a user wanted they could click expand on the budget to separate it. The enforcement of the “Basic above extended” could be soft, we allow them to drag anything anywhere and if they accidentally made a non compliant vote we just would fix it on the UI.
Another great UI that some of the teams working on this should look at is the Pairwise Vote app, that has been used to define the Optimism Retro funding. They show two projects and allow the voter to pick one. This could easily be done to make a “pre-ballot” game, in which the user plays the game for a few round, forcing them to be familiarized with the actual proposals, and after they were done, we would show them a ballot based on their choices in which they can then edit.
@nick.eth - I’m worried that having the UIs do an automatic reordering of a voter’s selection because their vote isn’t complaint with the algorithm is evidence that the approach would be too complex.
I also worry this will lead to voter confusion and dissatisfaction with the voting process in general.
James’ amendment maintained the properties of the original process of ordering applicants, while only adding an overlay of the budget selection on top of the applicant. It was backwards compatible to the original plan.
Your approach isn’t without merit, but it doesn’t retain the original properties of ordering the applicants. I’m worried that it crosses a line since the applications have already been received.
Can you help articulate the value of your approach vs. James initial amendment specifically? What would be a sub-optimal outcome scenario that is remedied by your approach?
Personally I think that it makes more sense for UIs to not allow you to create an invalid ballot in the first place, rather than correcting it for you if you do, for exactly this reason.
I think I explained this in my earlier message: if a candidate has a basic scope that includes very high importance work, and an extended scope that has work that is more “nice to have”, I’m forced to either vote for the smaller scope, or to effectively rank the extended scope above other, more important work. Looking at existing proposals I expect this to be a common pattern.
You’re absolutely right about this tradeoff. The current system in SPP Season 2 is designed to rank providers first, not individual projects or budgets. This was the explicit intent stated in [EP 6.3].
The original amendment operates within this provider-first paradigm. Rather than automatically defaulting to extended budgets, it adds the explicit choice between basic and extended budgets on an applicant - while preserving the core principle of ranking providers as the primary selection criteria.
I understand your position that ranking providers first might be sub-optimal in some cases. I can easily get behind the appeal of a deliverables-based system where we vote for tasks with price tags. If that’s what we want, let’s not stop at your suggestion - let’s actually do it by removing the min-max amounts, allowing any applicant to propose any number of tasks that are rankable in the vote, and really coming up with a selection mechanism that works for that system. We could even give them guidance using an RFP method for the desired projects (as has been suggested).
But making it deliverables-based or project-based would require us to rethink some fundamental aspects like KPIs. What if a team learns that their granted project isn’t going to bear fruit? After all, it was the project that was funded, not the team, so do we need to stop the funding of that project? This would also require a different application process than what we just went through.
That’s why I think the original amendment is the way to go. It’s straightforward, people will get it, and it keeps what works within the current system while giving us some of the requested budget choice that was asked for.
Again, I love your suggestions for next year, or for this year if everyone agrees to really run it back and rethink the process holistically.
Final comment - There’s a danger we push this conversation too far, if we haven’t already. Just to reiterate, we’ve had unanimous support for the original amendment in every interactive call that metagov has hosted, so it’s really hard not to believe this is the DAO’s preference. To date, you are the only delegate who has openly stated they don’t support it.
James amendment also reorders votes: the UI (and the algorithm behind it) is always moving the votes so the two budgets are kept together. The difference is that nicks algorithm only does it when basic is under extended. Netto’s UI had a switch that was just reordering votes behind the scenes.
Maybe it’s because “reordering votes” seems bad because people think about altering a ballot. You could say simply that “the algorithm considers that if the top most ranked vote for a project is its extra amount, then it considers there was a vote for the project itself”
Regarding the UI itself, I think it will be quite straightforward. I’ll do my best to get a working demo somehow
In the new proposed UIs for the original amendment, the budget options cannot be separated. There is one row for the provider. You simply also specify you budget preference.
In the example you used as to how we would support Nick’s suggestion, the budgets can be separated but then automatically reordered certain ways that are compliant. You have tool tips of a sort explaining this in your image.
That seems like a different voter experience that includes complexity that will be tough to track if you haven’t been deeply involved in this thread.
I understand that your statement on re-ordering is correct in terms of the interpretation of the results from Snapshot as the source of truth, I was referring to the UI/UX voters will experience in the UIs we’re recommending they use.
Thanks Alex. I’m not doubting your ability to build something great.
I do think we’re jumping the shark with continuing past the consensus we formed on the amendment. I’ll step back a bit from this thread though as I’ve already shared my view above in this post.
Appreciate all the hard work everyone has put into this discussion so far. It’s been awesome to see all the participation.
I hope we see the amendment at the top of the thread go up for a vote.
I made a quick and dirty prototype that can help visualize how it would behave:
I believe Nick’s proposal satisfies the initial demands of delegates for more detailed expressivity but with simpler rules. If this idea had been presented first, I find it hard to believe we would even consider switching to the much more complicated amendment presented at the top of the thread.
The process isn’t a jump the shark but rather the proper way a debate should happen: delegates asked a feature, we came up with a solution, then it became optimized and streamlined into a simpler solution
Just to clear: I have a small amount of votes and I don’t support it. Thomas also stated he would prefer something simpler, which implies not supporting it. And Alex who was at first against, has now come around.
Absolutely agree with this. Saying that because no one initially disagreed in the initial calls that were created with 24-48 hours notice does not mean it’s the “DAO’s preference”. That is exactly what this discussion over many more days on the forums is for.
That is absolutely not what is happening in the version most recently suggested by me and expanded on by Alex. Delegates are still voting for teams, just now with the flexibility to consider the extended budget as a separate line item to the base budget. It doesn’t require any structural changes from metagov or the program, and it doesn’t require any changes from delegates beyond any tweaks they were considering to the allocation between basic and extended scope as a result of the wider discussion.
It seems like a bad idea to me to pick a more complex and risky algorithm that’s less expressive simply because it came first; iteration is how we find the best ideas. Rushing to adopt the first solution seems to me like an organizational version of the risks of doing things under urgency that I raised concerns about earlier.
There was the first ever delegate all hands metagov call where all delegates were encouraged to join that was announced a month in advanced. See here.
On this call it was highlighted that delegates should be able to express a vote on basic vs extended scopes.
This was discussed for the week, the amendment above was created.
There was another metagov call a week after the all hands where again the amendment was discussed and there was agreement that as long as the UI providers were confident/happy this would go to a vote.
Forum discussion has of course continued but that doesn’t change the outcome from the last metagov call, as such the proposal is now live.
@jeff, This amendment was built in 3 different synchronous meetings across an 8 - 10 day period. The meetings were announced a month in advance and open to all. The meetings were hours long, and during that 10 day period we had constant collaborative communication across the multiple teams building prototype UIs to support the amendment, and we supported many teams who were curious how the outcome would change things for them.
A great deal of work was put into it by a lot of people, and it was universally supported. There wasn’t a single conversation participant who had a concern that wasn’t met and/or discussed, and not a single participant in the calls said they wouldn’t vote for it. It was honestly a really impressive show of governance coordination, and I think all who participated were impressed with the teamwork.
That’s the reason for the statement you quoted here, and I still stand by it.
My statement about only Nick dissenting was inaccurate. You’re right, you had expressed a preference for Nick’s plan after he announced it.
Yes, I’m, sure more ideas can be found and proposed, as Alex has now done. But we’re really arguing about some tiny nuance here when we had a perfectly good solution that had consensus.
Are these outcomes really so different that it requires this competition of ideas? Does the 2nd amendment really have so much difference that we’re going through this duel?
The difference is under the covers mostly, which leads me to believe we’re pushing too far in continuing to try to come up with different ways to count the same votes.
To the best of my knowledge, no agenda was published ahead of time, meaning there was no way to know that this would be a topic of discussion. The second meeting was scheduled for the same time the following day, with less than 24 hours’ notice. I’m not sure when this third meeting was, because despite being actively involved in the conversation as soon as I was aware of it, I don’t appear to have received an invite.
So pointing at the 3 week notice that was given for the “All Hands” call with no agenda as evidence that there was plenty of time to participate does not give an accurate picture of the situation.
The process to build out this new UI appears to have started as soon as the first meeting was concluded, without any attempt to determine what people who were not present in the meeting thought of the idea.
I have been present in the Telegram discussions since I became aware this was being discussed. I had concerns that were not met, and said I would not vote for it, so this is untrue.
The distinction between the proposals is far from a “tiny nuance”. The originally proposed solution significantly complicates the voting algorithm and introduces new risks, and the rush with which it has been pushed through really concerns me.
Yes. The alternative proposal better allows delegates to express their preferences in what I expect is a really common situation - where a provider puts their most essential work in the basic scope, and less essential work in an extended scope. More importantly, it’s significantly less complex and risky to implement.
The fact that one idea was proposed a few days before the other should not be material here, and we should not be trying to rush through significant changes without giving them careful consideration. The fact you’re trying to cite the first proposal’s primacy as a reason to bypass discussion on the second proposal demonstrates that your claim this is not controversial is inaccurate, too.
FYI delegates: Last night @James put forward the proposal discussed in this thread to Snapshot for a yes/no vote, bypassing the general consensus amongst participants that both proposals were going to be discussed at the next Metagov meeting.
In response, Alex has written up and put forward the second proposal for its own vote. He has written it such that whichever of the two proposals receives the larger number of votes (presuming both reach quorum) will be accepted.
I’m sorry this has put additional burden on delegates to now evaluate and consider two separate proposals, rather than giving the working group time to either consider and adopt a single proposal, or to put forward a multiple-choice option for voting.
James’s proposal is here.
The proposal from Alex and I is here.
Please vote on whichever of the two you believe should be enacted - or ‘no’ on both if you are happy with the current rules.
Your disagreeing with MetaGov stewards, disagreeing with service providers and delegates that have been engaging in discussion. I think Spence summed it up well here:
If anyone else was engaging in the way you are it would have already been disregarded. We all know you founded ENS, but let the DAO have some ability to engage in genuine discourse (like we have over the passed 2 weeks over multiple open calls that you choose not to join).
