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:

• : The token address of the DAO's token. The supply for tokens with 18 decimals should not exceed 34,028,236,692, a supply bigger than that can cause errors (more details).
• : The DAO's main vault/agent address. It can be 0x0000000000000000000000000000000000000000 to set it up for conviction signaling (without money allocation).
• : The token address that is going to be allocated. The token must be in the vault/agent. It can 0x0000000000000000000000000000000000000000 to set it up for conviction signaling (without money allocation).
• The rest of the parameters are:
  • 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 threshold

Once 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

• app: Frontend folder. Completely encapsulated, has its own package.json and dependencies.
  • src: Source files.
  • package.json: Frontend npm configuration file.
• contracts: Smart Constracts folder.
  • ConvictionVoting.sol: Aragon app contract.
  • Template.sol: Aragon Template to deploy a fully functional DAO.
• migrations: Migrations folder.
• test: Tests folder.
• arapp.json: Aragon configuration file. Includes Aragon-specific metadata for your app.
• manifest.json: Aragon configuration file. Includes web-specific configurations.
• truffle.js: Truffle configuration file.
• package.json: Main npm configuration file.

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):

Luke Duncan 🔍 🤔 📆	Patricia Davila 🎨 🤔	David Llop 💻 🤔 🛡️	Yalda Mousavinia 🤔	Deam 💻	Fabrizio Vigevani 💻 🛡️	Javier Alaves 🎨
Viviane Dias 💻	Sabaun Taraki ⚠️	The Commons Stack 📝 🤔 🔧	1Hive 💵 🚇	Aragon 💵	P2P Models 🚇	fioreb 🎨
Paulo J. Colombo 💻

This project follows the all-contributors specification. Contributions of any kind welcome!