1Hive's Conviction Voting app is used to allocate funds on proposals based on the conviction an entire organization has on them. Conviction can be signaled by staking organization tokens on proposals, and it is not fully activated until a certain period of time has passed.
The Conviction Voting app has been published to open.aragonpm.eth
. If you experience any issues or are interested in contributing please see review our open issues.
The code in this repository has not been audited.
The Conviction Voting template requires the use of 1Hive's Tokens app, so please follow the instructions in the README to deploy the app in the local devchain. Many devchains can coexist in the same computer, make sure you are deploying the Tokens app in the same devchain that is going to be deployed Conviction Voting.
To use the Conviction Voting application, you can simply do:
npm install
npm start # It actually starts `npm run start:ipfs:run`
If everything is working correctly, your new DAO will be deployed and your browser will open http://localhost:3000/#/YOUR-DAO-ADDRESS. It should look something like this:
NOTE: What the script npm run start:ipfs:run
does is running npm run start:ipfs:template
, kill the devchain, and reinitiate it with a block time of 15s, so we can see conviction growing over time.
Conviction Voting has been published to APM on Rinkeby at conviction-voting.open.aragonpm.eth
.
A newer version with the latest functionality is available at conviction-beta.open.aragonpm.eth
To deploy an organization you can use the Aragon CLI.
aragon dao install <dao-addr> conviction-voting.open.aragonpm.eth --app-init-args <org-token> <vault-addr> <funds-token> 9999599 2000000 20000 200000000000000000
This are the initalization parameters you can use:
0x0000000000000000000000000000000000000000
to set it up for conviction signaling (without money allocation).0x0000000000000000000000000000000000000000
to set it up for conviction signaling (without money allocation).decay = 0.9999599
, which sets up conviction halftime to 3 days.maxRatio = 0.2
, which sets the threshold formula to only allow proposals that request less than 20% of the funds. rho = 0.002
, which fine tunes the threshold formula.minThresholdStakePercentage = 0.2
, which sets the minimum percent of stake token active supply that is used for calculating the thresholdOnce the app has been installed, we can create permissions for anybody to create proposals on conviction voting, and for conviction voting to transfer funds from the vault/agent:
aragon dao acl create <dao-addr> <conviction-voting-app> CREATE_PROPOSALS_ROLE 0xffffffffffffffffffffffffffffffffffffffff <voting-app>
aragon dao acl create <dao-addr> <vault-app> TRANSFER_ROLE <conviction-voting-app> <voting-app>
The process of allocating funds in DAOs that are being used today feels very clunky, typically requiring a series of yes/no votes evaluated independently. These organizations also suffer from a number of challenges like 51% attacks, low participation, and overall inability to effectively prioritize and decide when there are many potential options all competing for consideration at once.
Conviction voting as proposed by Commons Stack and Block Science provides an interesting solution, that feels more organic and DAO-like than other methods we have seen proposed.
Our implementation of Conviction Voting as an Aragon application is intended to be used to collectively allocate funds from a shared treasury, or to signal priorities when used over proposals without money allocation.
Proposals can be submitted for consideration at any time and do not have an explicit expiration.
A user can vote for a single proposal at a time, when they do their token-weighted balance adds conviction to that proposal. In this way we can think of voting for a proposal a bit like the emission of a signal directed towards a specific proposal, when the signal is moved it takes time to fully arrive on the new proposal, and at same time the remnants of the signal can still be felt at the previous proposal for some time after the source of the signal has been redirected.
Proposals can be executed only if there is enough accumulated conviction. The threshold at which a proposal can be execute is dependent on the proportion of the funds requested relative to the available funds in the shared treasury. This relationship between the funds requested and available funds means that the threshold at which a proposal can be executed depends on the state of the system at any given time. As proposals pass and remove funds from the treasury, the remaining proposals will become harder to pass (because they now represent a larger proportion of the shared treasury), conversely, as new funds are added to the share treasury the threshold for passing existing proposals will decrease. This provides some natural self regulation to the spending rate of the organization relative to its income.
The time based accumulation forces voters to prioritize where they place their conviction and may encourage members to more effectively converge on a mutually acceptable compromise to most effectively leverage their influence on the DAOs fund allocations.
This app has the following structure:
root
βββ app
β βββ src
β βββ package.json
βββ contracts
β βββ ConvictionVoting.sol
β βββ Template.sol
βββ migration
βββ test
βββ arapp.json
βββ manifest.json
βββ truffle.js
βββ package.json
ConvictionVoting.sol
: Aragon app contract.Template.sol
: Aragon Template to deploy a fully functional DAO.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 #conviction-voting 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.
Thanks goes to these wonderful people (emoji key):
This project follows the all-contributors specification. Contributions of any kind welcome!