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.

What it does

Our implementation of Conviction Voting as an Aragon application is intended to be used to collectively allocate funds from a shared treasury. It does not currently support voting on other types of proposals.

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.

Unfortunately, we were not able to complete the application during the hackathon, we were able to get the basic contract into a mostly complete state as an Aragon App. We are confident the approach will work at this point, but some cleanup still needs to be done, and the threshold function still needs to be implemented. On the front-end we were able to come up with a design and start to implement using mock data.

What we learned

The UX requirements for conviction voting are significantly different than other more standard voting processes because it is important for users to be able to 1) see all the proposals and assess them as a group rather than individually 2) understand the dynamics of conviction accumulating (or decaying) from proposals 3) See which vote they are currently signaling for and 4) be made aware of the current threshold required for proposals to be triggered as the state of the system changes over time.

As a result we ended up spending longer than we expected on UX and frontend implementation but are very pleased with our results.

What is next for Conviction Voting

We plan to complete the app in the near future, and as suggested by the Common Stack team, feel that the continuous nature of conviction voting will complement continous fundraising mechanisms like bonding curves quite well. We look forward to connecting Conviction voting with Aragon Fundraising to support more permissive, continuous community organizations.

Built With

Share this project: