Snapshot Params

đź—Ł Advice Process
1

What should be the parameters for a proposal to pass on Snapshot?

Snapshot is a token weighted voting tool going to be used for:

  1. Large impact cultural decisions
  2. Community signal
  3. Runoff votes (coming from crowd proposal making on Tokenlog)

As of now, only TECH holders can submit proposals. We can’t program params into Snapshot (not that I know of), so the final results of each vote should be monitored by soft gov and transparency according to the params we choose.

What do we need to know before submitting proposals?

  • What is the support required? (the percentage of tokens that need to vote yes)

  • What is the minimum quorum? (the percentage of all tokens from the total supply of TEC that must vote on a proposal in order for it to be valid OR The min number of individuals that need to vote)

  • What is the vote duration? (How long the voting session stays open for? Is there a specific day of the week to submit proposals?)

I’ll add a few signal boxes below to help us start the conversation - Feel free comment other configs.

  • 88% like the hatch params
  • 75% like we had in the early days of the Cultural Build
  • 51%
  • something below 50 %

0 voters

  • min quorum in % of the total token supply
  • min quorum in an x number of individuals that must participate in voting

0 voters

  • 4 days like the hatch params
  • 6 days
  • each proposer is free to select the vote duration of their proposal

0 voters

2 Likes
2

Thanks for doing that Livi! In my opinion regarding the treasury management, 51% with at least 10% quorum should be enough to execute a proposal to move funds I don’t think needs to be very high like TAO voting. I think it would be beneficial to see what kind of decisions are being made and may be on soft gov we could draft different types of parameters for different types of votes.

Would that be a thing we should consider? :thinking:

1 Like
3

Thanks Livia! I voted for options that are similar with Hatch params because I think having consistent params across our different voting tools will make it easier for the community to get familiar with our voting process and avoid confusion (e.g. there’s the risk that they would miss some proposals if some voting periods are shorter than the others). After all, the decisions made around our cultural build are equally important as the decisions made related to funds IMO.

2 Likes
4

having different params for different types of proposal on snapshot might be too confusing.

What we can do is to have something specific for each use case - community signal/ cultural proposal/ runoff votes

I like what Griff always says that having 49% of people unsatisfied and still pass a proposal it’s probably not a good idea.
I don’t think this would happen often, but to give the chance for it to happen doesn’t feel like the best option for me. I would go for the 75% approval

1 Like
5

Interesting survey!)

1 Like
6

My rationale for my vote:
I picked both 88% and 75% because I feel like it’s someplace in between there (like maybe 80%). Setting it high because I don’t want whales weighing in too heavily on cultural issues. But not too high so that we become blocked in making important decisions as a community.

I think allowing proposal makers to determine the vote duration could be dangerous (example “1 day!”). I picked 6 because I think it’s hard to expect people to be tracking proposals all the time and we need to ensure enough time for folks to weigh in.

2 Likes