This article is one of a series of component explainers for the Commons Stack infrastructure. One of the least understood yet most talked about pieces of the Commons Stack is the Conviction Voting (CV) governance module. We’ll take a closer look at this decision making mechanism, discussing why we need it, how it works, and where it fits into our tech stack for scalable commons stewardship.

The ultimate governance question: how do we make good decisions as a collective?

As we move into a future of automation, we want to ensure that human needs remain a key input of the socio-technical systems we are creating.

As we explored in our introduction to the Commons Stack, commons stewardship starts with managing shared resources in order to achieve mutual community goals. But how do we, as a collective, decide how those resources should be allocated? **Conviction Voting offers a novel decision making process that funds proposals based on the aggregated preference of community members, expressed continuously. In other words, **voters are always asserting their preference for which proposals they would like to see approved, rather than casting votes in a single time-boxed session. A member can change their preference at any time, but the longer they keep their preference for the same proposal, the “stronger” their conviction gets. This added conviction gives long standing community members with consistent preferences more influence than short term participants merely trying to influence a vote. Conviction Voting sidesteps sybil attacks, provides collusion resistance, and mitigates many of the attack vectors of time-boxed voting mechanisms.

An early conviction voting display prototype, demonstrating the growth and decay of aggregated conviction for a proposal from several members in a community.

As we move into a future of automation, we want to ensure that human needs remain a key input to the socio-technical systems we are creating. We’re generating an ever-growing deluge of data and relying on complex algorithms to analyze it and make suggestions for us, but so far we’ve struggled to capture human needs in these rich temporal data flows. Continuously sampling preferences through Conviction Voting will provide us with instantaneous data that allows us to account for people’s needs in our future decision making processes — especially as we use DAOs to experiment with new forms of real-time ‘cyber-physical’ governance.

The concept of Conviction Voting is designed from mathematical first principles specifically for the allocation of funds. It was derived from the paper on ‘Social Sensor Fusion’ by Dr. Michael Zargham, where humans are the “social sensors” reacting to proposals in their communities, each broadcasting continuously evolving preferences that are “fused” into an aggregated social signal. The design and functionality of our Conviction Voting module draws on decades of research on multi agent coordination problems and behavioral economics, with all the mathematical rigor that BlockScience is well known for.

Turning group decision making into a streamlined, continuous process would allow for the real-time feedback of human needs into our governance systems.

We need to be thinking outside the ‘time-box’ with complex system design.

Conviction Voting differs from other decision making mechanisms in that it does not order proposals in an A vs B fashion (like pairwise comparisons in Colony’s Budget Box, for example) — instead, the community entertains all nominated proposals at any given time. So a person could put half of their voting power behind proposal A, a quarter behind proposal B, and divide the remaining quarter between proposals C and D. You can think of each proposal as a bucket and your token-weighted opinion as a tap, pouring your preferences into selected proposals in the proportions that you choose.

A sketch demonstrating how a member might allocate their preference between 5 tabled proposals.

The longer you hold a preference for a certain proposal, the more that bucket fills up with your conviction. Your conviction grows according to a half life decay curve, giving more weight to that preference over time, up** **to a certain limit. If you decide to switch your preference to a new bucket, your conviction drains out of the previous proposal according to the decay function, as if there were a small hole in the bottom of each bucket. By using decay curves to define the accumulation and reduction of conviction, we introduce temporal dynamics into these systems, moving us closer to how systems work in nature. By dampening abrupt token movements, we eliminate the need for arbitrary token lock periods to avoid last minute vote swings. To get a grasp on how conviction accumulation would work, play around with our basic Conviction Voting applet we created to test out some initial system parameters, or check out this math-oriented HackMD created for ETHParis by DappLion.

As with all of our components, we took a biomimetic approach to the design of Conviction Voting. The analogy of the human brain can be used to understand the CV mechanism, where the increasing collective preference for a proposal can be compared with increasing action potential in a neuron. When the collective preference for a proposal reaches a preset threshold, the proposal is approved, just like the neuron fires when its action threshold is reached. This is how we can transform a continuous data stream of individual preferences into discrete acceptance of proposals in a manner similar to that found in nature. When we aggregate the opinions of a community in this way, we create a rich temporal data stream of collective preference for use in group decision making.

This graph shows community conviction growing for different proposals, each represented by different colors. The data comes from a cadCAD simulation of a Conviction Voting environment. Proposals are triggered once they reach the dotted line threshold, and have been live for 7 days.

It is important to note several key differences between traditional voting and on-chain voting. In the absence of identity in blockchain networks, we cannot utilize one-person-one-vote systems, nor would we want to, as they can lead to a tyranny of the majority. Instead, we see one-token-one-vote systems, which allows voters to display the intensity of their preference. At this point in the crypto space, that means total plutocracy — this is a recognized problem and can be ameliorated by several mechanisms, among them Quadratic Voting, which reduces the impact of wealth on voting power. Alternatively, community members could be granted some set number of votes per month allocated to them via a token drip, to even out the distribution of voting power.

Pioneers in the blockchain space are experimenting wildly with new tools for human collaboration, but we must always question whether we are carrying unnecessary baggage from our legacy voting systems. What further assumptions can we drop to further streamline distributed decision making at scale? How about the assumption that voting needs to be time-boxed at all?

1. Vote buying**, ****plutocracy ****and **sybil attacks are tactics that a wealthy bad actor can use to unfairly influence a voting process. Respectively, these terms refer to 1) bribing other voters to vote a certain way, 2) purchasing a significant amount of tokens to amplify one’s vote, or 3) splitting up their token holdings among many accounts to gain undue influence over a decision. These issues plague many of today’s on-chain voting systems.

2. Last minute vote swings** — as seen in multiple on-chain voting scenarios, time-boxed voting is particularly susceptible to manipulation in the moments before it ends. Strategic voters wait to view early results before weighing in with their vote at the end of the session to tip the balance in their favor. This is partially addressed through mechanisms such as wait for quiet voting, **which extends the duration of a vote in case of a last minute change in outcome (though this approach is vulnerable to filibustering as an attack vector) or PLCR voting, which keeps the results of a vote secret until polls close, but also introduces extra UX difficulties and potential liquidity complications caused by arbitrary token lock periods.

An early concept design for a Conviction Voting interface

1. With a continuous voting mechanism, attackers will find that ‘vote buying’ becomes ‘vote renting’. To significantly influence a continuous stream of preference broadcasting, an attacker would need to continually expend funds to bend the system towards their desired outcomes, rather than purchasing the votes once to obtain their desired outcomes indefinitely. In other words, CV significantly raises the costs of influencing the system over long periods of time, thus reducing the vote buying attack vector and increasing collusion resistance. Conviction Voting also empowers token holders who have been persistent in their preference, since votes for a proposal gains ‘conviction’ as time passes. This ensures that long standing minority opinions are given additional weight to reduce the volatility introduced by new inflows of wealth into established communities. What’s more, Conviction Voting is sybil-resistant, as it removes the opportunity for large token holders to gain undue influence by splitting up their token holdings into multiple accounts.

2. Most last minute vote swings are caused by frictionless token movements, i.e. the ability to allocate large amounts of tokens at any point during the time-boxed vote. By restricting preference/token allocation using decay curves, we eliminate large token holders’ ability to influence votes at the last minute, and instead reward voters who display consistent, long held preferences. Through this design we can eliminate the necessity of clunky token locks that threaten system liquidity, and instead replace them with dynamic flows represented by these decay functions.

3. To address on-chain voter apathy, we want to make voting as easy as possible. When a member joins the community, they will be requested to assert percentages of their preference towards existing proposals, adding up to 100% in total. Using something like the ERC-888 token standard, we can **allow tokens to be automatically asserted towards proposals, without affecting token liquidity with staking locks. Since your preferences are expressed as a percentage of your token holdings, any change to your token holdings (through buying or selling) automatically updates the weight of your preference. Conviction Voting also **eliminates the need for **

Watch Conviction Voting in action! Pulled from our early CV model in cadCAD, this diagram shows token holders arranged on the left, asserting their preferences towards the various proposals arranged on the right. The darker the line, the heavier the token weight. Blue proposals are acquiring conviction, yellow are live proposals that have been approved, and green are proposals that have been approved and completed.

The Conviction Voting component sits between the Augmented Bonding Curve, where voting tokens are acquired, and the Giveth Proposal Engine, which includes concrete Milestones and fund allocation for an approved proposal, once sufficient support has been accumulated to activate the trigger function.

*A diagram of a cyber-physical commons, built from the Commons Stack library. The Conviction Voting component of the system is displayed in purple, between the Augmented Bonding Curve (black) and the Giveth Proposal Engine (green). *This diagram is explored further in this video.

This design of the Conviction Voting module is being simulated and tested in cadCAD, one of the first times token engineering design tools are being applied to model system behavior in a complex governance process. There are many more details to explore in a forthcoming deep dive article — stay tuned!

This basic implementation of Conviction Voting is an MVP and is by no means a feature complete mechanism, nor are we suggesting it be appropriate for use in all scenarios. The **design space is wide open for alternative governance mechanisms **that mimic how decisions are made in natural systems, and we are excited to explore those design options through future improvements and additions to the Commons Stack component library, pending funding for our build phase. Further additions to the Conviction Voting mechanism could include delegations via liquid democracy and a reduction in the impact of wealthy participants via quadratic voting or an equivalent mechanism, though **these features will depend on (forthcoming) self-sovereign identity solutions **such as iden3.

Continuous voting mechanisms like Conviction Voting offer massive improvements over traditional forms of on-chain voting, and we’re excited to see where an exploration of this design space ends up. **You can help make this research a reality by **funding the build phase of the Commons Stack, so we can all benefit from a library of open source governance modules to be forked and used by projects as appropriate. We don’t believe there is a single answer to the question of governance — instead, we aim to facilitate an open ecosystem of components so that projects can choose what works best for them. We want to see experimentation proliferate in all directions, using robust cryptoeconomic primitives, and allow Darwinian market processes to decide what works best!

Taking the first steps towards real-time collaborative decision making!

This article is one of a series of component explainers for the Commons Stack infrastructure. One of the least understood yet most talked about pieces of the Commons Stack is the Conviction Voting (CV) governance module. We’ll take a closer look at this decision making mechanism, discussing why we need it, how it works, and where it fits into our tech stack for scalable commons stewardship.

The ultimate governance question: how do we make good decisions as a collective?

As we move into a future of automation, we want to ensure that human needs remain a key input of the socio-technical systems we are creating.

As we explored in our introduction to the Commons Stack, commons stewardship starts with managing shared resources in order to achieve mutual community goals. But how do we, as a collective, decide how those resources should be allocated? **Conviction Voting offers a novel decision making process that funds proposals based on the aggregated preference of community members, expressed continuously. In other words, **voters are always asserting their preference for which proposals they would like to see approved, rather than casting votes in a single time-boxed session. A member can change their preference at any time, but the longer they keep their preference for the same proposal, the “stronger” their conviction gets. This added conviction gives long standing community members with consistent preferences more influence than short term participants merely trying to influence a vote. Conviction Voting sidesteps sybil attacks, provides collusion resistance, and mitigates many of the attack vectors of time-boxed voting mechanisms.

An early conviction voting display prototype, demonstrating the growth and decay of aggregated conviction for a proposal from several members in a community.

As we move into a future of automation, we want to ensure that human needs remain a key input to the socio-technical systems we are creating. We’re generating an ever-growing deluge of data and relying on complex algorithms to analyze it and make suggestions for us, but so far we’ve struggled to capture human needs in these rich temporal data flows. Continuously sampling preferences through Conviction Voting will provide us with instantaneous data that allows us to account for people’s needs in our future decision making processes — especially as we use DAOs to experiment with new forms of real-time ‘cyber-physical’ governance.

The concept of Conviction Voting is designed from mathematical first principles specifically for the allocation of funds. It was derived from the paper on ‘Social Sensor Fusion’ by Dr. Michael Zargham, where humans are the “social sensors” reacting to proposals in their communities, each broadcasting continuously evolving preferences that are “fused” into an aggregated social signal. The design and functionality of our Conviction Voting module draws on decades of research on multi agent coordination problems and behavioral economics, with all the mathematical rigor that BlockScience is well known for.

Turning group decision making into a streamlined, continuous process would allow for the real-time feedback of human needs into our governance systems.

We need to be thinking outside the ‘time-box’ with complex system design.

Conviction Voting differs from other decision making mechanisms in that it does not order proposals in an A vs B fashion (like pairwise comparisons in Colony’s Budget Box, for example) — instead, the community entertains all nominated proposals at any given time. So a person could put half of their voting power behind proposal A, a quarter behind proposal B, and divide the remaining quarter between proposals C and D. You can think of each proposal as a bucket and your token-weighted opinion as a tap, pouring your preferences into selected proposals in the proportions that you choose.

A sketch demonstrating how a member might allocate their preference between 5 tabled proposals.

The longer you hold a preference for a certain proposal, the more that bucket fills up with your conviction. Your conviction grows according to a half life decay curve, giving more weight to that preference over time, up** **to a certain limit. If you decide to switch your preference to a new bucket, your conviction drains out of the previous proposal according to the decay function, as if there were a small hole in the bottom of each bucket. By using decay curves to define the accumulation and reduction of conviction, we introduce temporal dynamics into these systems, moving us closer to how systems work in nature. By dampening abrupt token movements, we eliminate the need for arbitrary token lock periods to avoid last minute vote swings. To get a grasp on how conviction accumulation would work, play around with our basic Conviction Voting applet we created to test out some initial system parameters, or check out this math-oriented HackMD created for ETHParis by DappLion.

As with all of our components, we took a biomimetic approach to the design of Conviction Voting. The analogy of the human brain can be used to understand the CV mechanism, where the increasing collective preference for a proposal can be compared with increasing action potential in a neuron. When the collective preference for a proposal reaches a preset threshold, the proposal is approved, just like the neuron fires when its action threshold is reached. This is how we can transform a continuous data stream of individual preferences into discrete acceptance of proposals in a manner similar to that found in nature. When we aggregate the opinions of a community in this way, we create a rich temporal data stream of collective preference for use in group decision making.

This graph shows community conviction growing for different proposals, each represented by different colors. The data comes from a cadCAD simulation of a Conviction Voting environment. Proposals are triggered once they reach the dotted line threshold, and have been live for 7 days.

It is important to note several key differences between traditional voting and on-chain voting. In the absence of identity in blockchain networks, we cannot utilize one-person-one-vote systems, nor would we want to, as they can lead to a tyranny of the majority. Instead, we see one-token-one-vote systems, which allows voters to display the intensity of their preference. At this point in the crypto space, that means total plutocracy — this is a recognized problem and can be ameliorated by several mechanisms, among them Quadratic Voting, which reduces the impact of wealth on voting power. Alternatively, community members could be granted some set number of votes per month allocated to them via a token drip, to even out the distribution of voting power.

Pioneers in the blockchain space are experimenting wildly with new tools for human collaboration, but we must always question whether we are carrying unnecessary baggage from our legacy voting systems. What further assumptions can we drop to further streamline distributed decision making at scale? How about the assumption that voting needs to be time-boxed at all?

1. Vote buying**, ****plutocracy ****and **sybil attacks are tactics that a wealthy bad actor can use to unfairly influence a voting process. Respectively, these terms refer to 1) bribing other voters to vote a certain way, 2) purchasing a significant amount of tokens to amplify one’s vote, or 3) splitting up their token holdings among many accounts to gain undue influence over a decision. These issues plague many of today’s on-chain voting systems.

2. Last minute vote swings** — as seen in multiple on-chain voting scenarios, time-boxed voting is particularly susceptible to manipulation in the moments before it ends. Strategic voters wait to view early results before weighing in with their vote at the end of the session to tip the balance in their favor. This is partially addressed through mechanisms such as wait for quiet voting, **which extends the duration of a vote in case of a last minute change in outcome (though this approach is vulnerable to filibustering as an attack vector) or PLCR voting, which keeps the results of a vote secret until polls close, but also introduces extra UX difficulties and potential liquidity complications caused by arbitrary token lock periods.

An early concept design for a Conviction Voting interface

1. With a continuous voting mechanism, attackers will find that ‘vote buying’ becomes ‘vote renting’. To significantly influence a continuous stream of preference broadcasting, an attacker would need to continually expend funds to bend the system towards their desired outcomes, rather than purchasing the votes once to obtain their desired outcomes indefinitely. In other words, CV significantly raises the costs of influencing the system over long periods of time, thus reducing the vote buying attack vector and increasing collusion resistance. Conviction Voting also empowers token holders who have been persistent in their preference, since votes for a proposal gains ‘conviction’ as time passes. This ensures that long standing minority opinions are given additional weight to reduce the volatility introduced by new inflows of wealth into established communities. What’s more, Conviction Voting is sybil-resistant, as it removes the opportunity for large token holders to gain undue influence by splitting up their token holdings into multiple accounts.

2. Most last minute vote swings are caused by frictionless token movements, i.e. the ability to allocate large amounts of tokens at any point during the time-boxed vote. By restricting preference/token allocation using decay curves, we eliminate large token holders’ ability to influence votes at the last minute, and instead reward voters who display consistent, long held preferences. Through this design we can eliminate the necessity of clunky token locks that threaten system liquidity, and instead replace them with dynamic flows represented by these decay functions.

3. To address on-chain voter apathy, we want to make voting as easy as possible. When a member joins the community, they will be requested to assert percentages of their preference towards existing proposals, adding up to 100% in total. Using something like the ERC-888 token standard, we can **allow tokens to be automatically asserted towards proposals, without affecting token liquidity with staking locks. Since your preferences are expressed as a percentage of your token holdings, any change to your token holdings (through buying or selling) automatically updates the weight of your preference. Conviction Voting also **eliminates the need for **

Watch Conviction Voting in action! Pulled from our early CV model in cadCAD, this diagram shows token holders arranged on the left, asserting their preferences towards the various proposals arranged on the right. The darker the line, the heavier the token weight. Blue proposals are acquiring conviction, yellow are live proposals that have been approved, and green are proposals that have been approved and completed.

The Conviction Voting component sits between the Augmented Bonding Curve, where voting tokens are acquired, and the Giveth Proposal Engine, which includes concrete Milestones and fund allocation for an approved proposal, once sufficient support has been accumulated to activate the trigger function.

*A diagram of a cyber-physical commons, built from the Commons Stack library. The Conviction Voting component of the system is displayed in purple, between the Augmented Bonding Curve (black) and the Giveth Proposal Engine (green). *This diagram is explored further in this video.

This design of the Conviction Voting module is being simulated and tested in cadCAD, one of the first times token engineering design tools are being applied to model system behavior in a complex governance process. There are many more details to explore in a forthcoming deep dive article — stay tuned!

This basic implementation of Conviction Voting is an MVP and is by no means a feature complete mechanism, nor are we suggesting it be appropriate for use in all scenarios. The **design space is wide open for alternative governance mechanisms **that mimic how decisions are made in natural systems, and we are excited to explore those design options through future improvements and additions to the Commons Stack component library, pending funding for our build phase. Further additions to the Conviction Voting mechanism could include delegations via liquid democracy and a reduction in the impact of wealthy participants via quadratic voting or an equivalent mechanism, though **these features will depend on (forthcoming) self-sovereign identity solutions **such as iden3.

Continuous voting mechanisms like Conviction Voting offer massive improvements over traditional forms of on-chain voting, and we’re excited to see where an exploration of this design space ends up. **You can help make this research a reality by **funding the build phase of the Commons Stack, so we can all benefit from a library of open source governance modules to be forked and used by projects as appropriate. We don’t believe there is a single answer to the question of governance — instead, we aim to facilitate an open ecosystem of components so that projects can choose what works best for them. We want to see experimentation proliferate in all directions, using robust cryptoeconomic primitives, and allow Darwinian market processes to decide what works best!

Taking the first steps towards real-time collaborative decision making!