The Dandelion Voting app is a fork of the Original Aragon Voting app. It serves the same purpose as the original Voting app but also enables organizations to restrict actions to members who have expressed approval in recent votes. It basically means that by voting yes on a proposal you are committing to a decision in the Org.
The main changes that have been implemented which differ from the original Voting app are:
- Removed the ability for a user to change their vote.
- Added a buffer period which determines how much time in blocks must pass between the start of each vote.
- Added an execution delay period in blocks (this means that the
full vote duration+
full execution delay periodmust pass before being able to execute a vote in case it passes).
- Removed the early execution functionality.
- Changed the vote duration to blocks. The main reason for this is that since proposals are queued we do not necessarily know which block number to use for the vote snapshot (since we are not necessarily processing the transaction right when the vote starts).
- Keep track of the latest vote ids users have voted yes on.
- Make the app an ACL Oracle.
The code in this repo has not been audited.
How does it work?
It has the same funcionality as the regular voting app with some exceptions:
- Proposals are now queued with a minimum number of blocks between the start of each one.
- Users cannot change their decision after they have already voted.
- Votes are delayed a configurable period of time since when they are closed till when they can be executed (in the case they pass).
- Votes cannot be early executed. This means that the
full vote duration+ the
full delay periodhas to pass in order to be able to execute a vote (in case it passes).
It also acts as an ACL Oracle. ACL Oracles are small helper functions that plug in to Aragon's access control list (ACL) to do more sophisticated permission evaluation. This Oracle is intended to restrict actions to members who have expressed approval in recent votes.
The app keeps track of the latest vote ids users have voted yes on. This way when the Oracle function is queried, it can properly evaluate whether a member can perform a certain action or not within the Organization.
In the context of Dandelion Orgs, the redeem functionality will be guarded by a role set behind this ACL Oracle. This means that whenever a user wants to redeem some tokens, it will first call the ACL Oracle function to check whether s/he can perform the action or not.
Users will be able to redeem tokens if one of this conditions is met:
- The latest vote in which the user voted yea failed (did not passed) and the execution delay for this vote has already passed.
- The latest vote in which the user voted yea passed and has been executed.
- The latest vote in which the user voted yea passed and the fallback period has passed.
What's the fallback period ?
The fallback period is intended to ensure users are both locked in for votes they voted yes on, but still have an opportunity to exit before the next vote that they didn't vote yes on gets executed. The idea here is that it gives other members an opportunity to execute the vote before anyone who voted yes on the proposal has the opportunity to exit. It also takes into account the possibility of a vote to fail its execution due to reasons that are outside of the Org's control.
The Dandelion Voting app is initialized with a
uint64 _bufferBlocks and
MiniMeToken _tokenrefers to the token that will be used to vote
uint64 _supportRequiredPctrefers to the support required to pass a vote
uint64 _minAcceptQuorumPctrefers to the quorum required to pass a vote
uint64 _durationBlocksrefers to the number of blocks that a vote stays open
uint64 _bufferBlocksrefers to the minimum number of blocks between the start block of each vote
uint64 _executionDelayBlocksrefers to the number of blocks that a vote will be delayed from when is closed to when it actually can be executed (in case it passes).
The Dandelion Voting app should implement the following roles:
- CREATE_VOTES_ROLE: This allows for changing the Aragon app that can create votes
- MODIFY_SUPPORT_ROLE: This allows for changing the amount of support required to pass a vote
- MODIFY_QUORUM_ROLE: This allows for changing the quorum required to pass votes
- MODIFY_BUFFER_BLOCKS_ROLE: This allows for changing the minimum number of blocks between the start block of each vote
- MODIFY_EXECUTION_DELAY_ROLE; This allows for changing the number of blocks that votes are delayed from when they are closed till when they can be executed (in case they pass).
The interface is pretty much the same as the original Voting app with the exception that now you can see when future votes will start (upcoming votes).
How to try Dandelion Voting app immediately
If you would like to see the Dandelion Voting App in action, we recommend the Dandelion Org template available in the Aragon templates directory. Just go to https://preview.1hive.org/, then create a new organization, and choose Dandelion from the template options.
How to run the Dandelion Voting app locally
Git clone this repo.
git clone https://github.com/1Hive/dandelion-voting-app.git
Navigate into the
Install npm dependencies.
Deploy a dao with Dandelion Voting app installed on your local environment.
npm run start:template
Aragon DAO Installation
For a detailed step by step guide you can see our installation guide
To deploy to an organization you can use the aragonCLI.
aragon dao install <dao-address> dandelion-voting.open.aragonpm.eth --app-init-args <token-address> <supportRequiredPct> <minAcceptQuorumPct> <durationBlocks> <bufferBlocks> <executionDelayBlocks>
We welcome community contributions!
Please check out our open Issues to get started.
If you discover something that could potentially impact security, please notify us immediately. The quickest way to reach us is via the #dev channel in our team Keybase chat. Just say hi and that you discovered a potential security vulnerability and we'll DM you to discuss details.