Dandelion Voting
"The Dandelion Voting App is like god-mode for the TEC." - Griff Green
This is the initial voting application that sets some foundations for the advanced voting templates and is used to settle the 2nd phase of the Hatch.
It will have the power to upgrade the Commons, adding new applications and changing existing parameters. The first decision the Commons will have to make will be whether or not to upgrade to include the Conviction Voting and Augmented Bonding Curve apps. After that however, it will continue to be used for general Commons operations managing future upgrades, parameter adjustments, role/permissions adjustments, and any other decision besides which TE public Good projects to fund.
Token-Weighted Voting and 'Voting Power'
In Dandelion Voting and most other voting templates a member's vote is valued a bit different than ad-hoc voting. Rather than one person - one vote, votes are weighted based on your contribution to the Commons. These contributions are assesed on the merits of work and/or liquidity put into the TEC and you are vested tokens proportionate to these aforementioned contributions. Your 'Voting Power' is a reference to the amount of eligible tokens you hold versus the total supply of eligible tokens. In effect this mechanic provides weight to your tokens for the purpose of voting. During the Hatch phase of the TEC these tokens are TECH tokens; post-hatch in the upgraded TEC Commons these become TEC tokens.
In the latter part of the Hatch process once the funding goals are met and TECH tokens are distributed it is Dandelion Voting which will be used by the Hatchers to set the values of parameters for the upgraded TEC Commons.
Specific to Dandelion Voting Instances, if a Hatch member disagrees with a proposal that's been passed they will have the option to leave the Hatch thereby burning their TECHtokens and be reimbursed a porportionate amount of the liquidity they provided (wxDai). The "Rage Quit Period" is the space of time where people can rage quit before the passed proposal is executed.
For instance, if a Dandelion Voting instance is used to change the Exit Tribute from 5% to 30%, many people may want to sell their tokens before the proposal is executed. But the people that voted to raise the Exit Tribute to 30% would not be able to sell their tokens, because their tokens would be locked until the Vote Execution Delay is up.
If you however voted "Yes" on a passed proposal your tokens will be locked in until after the vote is executed.
Minimum Quorum - the percent of the total supply of the token that needs to participate in a vote in order for it to be able to be passed. Deep Dive
Support Required - the percentage of tokens needed to vote yes (of the tokens that were used to vote) for a proposal to Pass in the Dandelion and Disputable Voting Apps. Deep Dive
Tollgate Fee - This is a token fee a member must deposit before executing an action. Useful for when an organization wants to make actions public, but impose a customizable cost to prevent spam. Deep Dive
Vote Proposal Buffer - the amount of time that must pass between each subsequent vote. This parameter will determine the number of votes that can take place within a period of time and whether or not we can have votes run concurrently. Deep Dive
Vote Execution Delay - the period of time after a vote passes before the vote can be executed. Deep Dive
Last modified 2yr ago