Currently 4 people, 2 from Kleros (Federico and myself), 2 from democracy earth (Santiago and Herb) are able to put proposals to vote in the snapshot interface.
Proposals once accepted are to be executed through the governor where anyone can submit a list of transactions corresponding to proposals which passed with a bond. In case multiple lists are proposed, it creates a dispute in Kleros technical court to choose the list properly implementing the result of the proposal.
Consequently it is not obvious who can decide to put a proposal to vote, as let’s imagine that all us 4 would become malicious and censor proposals (i.e. not putting them to vote on snapshot interface), someone else could come with a new snapshot interface and Kleros could rule the implementation of proposals passed from this interface to be valid.
We also saw with HIP1 (which is technically unsound and cannot be implemented) that having one of us 4 supporting putting to vote a proposal (note that supporting putting to vote is different from supporting a proposal in itself) is not sufficient to filter from “bad” (technically unsound, spam, etc) proposals.
Potential ways forward
We could continue this way and only deal with the issue after proposal are passed (as they would not be executed by the governor).
The advantage being that in practice putting a proposal to vote would be quite easy.
- This gives Kleros a significant subjective power (in case a proposal is technically unsound, should it not be implemented or should we implement something matching the proposal the “best” way possible).
- It can dilute voter attention and discourage voters who voted on proposal not implemented.
Have in-forum procedural rules
We could for example require a poll before putting a proposal to vote. If the proposal receive a significant share of the poll votes (like 25%), it would be put to vote directly, if it doesn’t we would require some set amount of registered parties to support the proposal.
This would have the advantage of allowing consensual proposal to be put to vote in a easy way.
The drawback would be:
- Extra work on gathering signature for proposal not winning forum polls (despite the fact that they can win the vote).
- Risks of having a lot of fake accounts playing with polls which could lead to proposal spam.
We could make a curate TCR of proposals and define some criterion that proposals need to fulfill before being put to vote.
The advantage would be that putting proposals to vote would be more objective (instead of relying on polls) and not require much work (submitting on curate is quite easy).
The disadvantage would be that someone would have to put a deposit to put a proposal to vote and risk losing its deposit if the proposal is shown not to respect the define criterion.
Is it possible to make a non-binding poll in the forum which only verified humans can vote?
That would eliminate the fake accounts problem.
I’m in favor of “in-forum” procedural rules:
We need some velocity for consensual proposals in these first few weeks/months of the DAO.
Fake account spamming in polls has not been a common issue in most of the successful DAOs I have been part of and you can easily set up trust level for accounts in Discourse to set up some minimal barriers.
This would allow for kickstarting the first proposals while exploring a way to link forum accounts to PoH profiles to consolidate the system in the future.
N.B.: If the community really insists on polls Sybil-resistance even from the start, it can always be done through Snapshot by distinguishing" [Non-binding signalling polls] WDYT about X" from '[Binding proposal] HIP-X".
[Non-binding signalling polls] WDYT about X" from '[Binding proposal] HIP-X".
Non-binding Snapshot votes I think can be quite useful… and a very simple approach.
We can also use techniques like token burning to signal preferences. There’s a project I’m working with Auryn to build a
burnAndPost service using UBI.
Well actually snapshot polls (that anyone can create but would not be displayed in the UI) would be better than forum polls. In this case we could turn the poll question into:
“Should this proposal be put to vote?” and require a majority of yes.
How could we implement this surverying polls today to see if an idea deserves to be put to a vote? How could we allow anyone to signal these on Snapshot? Maybe a sub-DAO?
The same snapshot interface can be used (proposal created by addresses others than the 4 main ones would not be listed but can still be created).
is that already setup? cuz then i have a proposal to put up tomorrow morning!
If you make a proposal from an address other than the one of the multisig, it will not be listed but you can link to it.
I might have a look at how complex it would be to amend snapshot with a rolling snapshot block #, as only humans can get the vote token anyway there doesn’t seem to be a need to limit the vote to people who were humans at a certain block number?
For example, as of today i am registered on PoH (yay!) but as the snapshot polls were started a few days ago they are also pinned to vote token allocations a few days ago, and so I am unable to vote on them despite the vote being open until the 16th and being registered.
This token snapshot makes sense for projects where people may move tokens around to manipulate voting, but seems like a needless limitation for PoH gov.
It is just an edge case, and not so important, but something to think about.
Yeah, I think snapshot was made with preventing people from moving tokens to get extra votes in mind but here the registrations are not transferable.
For me, the simplest way to democratize for now would be to make ‘board member’ an elected position.
I suggest creating a 3-person elected board for a period of 1 year with the power to decide the way proposals are put together, curated, and put to vote.
This would likely end up being the same people doing it now, but now with formal, rather than informal power. That way you can make the decisions (such as using Kleros curate) without feeling guilty.
Sure, this may be automated in the future, but the future may be pretty far away.