---
title: "Conviction Voting"
url: "https://caper.network/wiki/dao-governance/concepts/voting/conviction-voting"
updated: 2026-09-07
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Conviction Voting

|  |  |
| --- | --- |
| **Topic** | Continuous, time-weighted fund allocation for DAO treasuries |
| **Core rule** | Support ("conviction") on a proposal charges up the longer tokens stay staked, and decays when they leave |
| **Passes when** | Accumulated conviction crosses a dynamic threshold scaled to the share of treasury requested |
| **Origin** | Michael Zargham (Social Sensor Fusion) → [Commons Stack](https://github.com/commonsbuild) + [BlockScience](https://github.com/BlockScience), 2019 |
| **First in production** | [1Hive Gardens](https://github.com/1Hive/conviction-voting-app) on Gnosis Chain |
| **Best for** | Steady grant/treasury outflows — not binary yes/no protocol votes |
| **Related** | [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting), [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management), [Quadratic voting & funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) |

**Conviction voting** is a continuous-funding mechanism in which a voter's influence over a proposal grows the longer they keep tokens staked behind it, and fades once they withdraw. There are no ballots and no voting deadline: supporters signal a preference at any time by staking [governance tokens](/wiki/dao-governance/concepts/voting/token-weighted-voting) on the proposals they want funded, their **conviction** charges up over days according to an exponential curve, and a proposal executes automatically the moment its accumulated conviction crosses a threshold set by how large a slice of the [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) it asks for. It is one of the most mature alternatives to periodic, quorum-gated voting, and it is aimed squarely at the problem it solves best — a steady stream of grant and treasury-allocation decisions that a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) does not want to marshal a fresh vote for every time.

## How conviction accumulates

When a member stakes tokens on a proposal, that support does not count at full strength immediately. Instead conviction builds up over time toward a ceiling set by the staked amount, following a discrete exponential-decay update — each block, existing conviction is multiplied by a decay parameter _α_ (just below 1) and the current stake is added on top. The same α that charges conviction up also bleeds it away: pull your stake and your conviction on that proposal decays back toward zero at the same rate. The parameter is usually described by its **half-life**, and that is where the mechanism is most often misread, because the decay is applied **per block rather than per day**: [`calculateConviction`](https://github.com/1Hive/conviction-voting-app/blob/master/contracts/ConvictionVoting.sol) documents its own first argument as the “number of blocks since last conviction record” and raises α to that power. A half-life quoted in days is therefore a claim about the chain's block time, not about conviction voting. 1Hive's reference Aragon app shipped with a decay of `0.9999599`, and its [README](https://github.com/1Hive/conviction-voting-app) glosses that as “conviction halftime to 3 days”: ln 0.5 / ln 0.9999599 is 17,285 blocks, which is three days only at **fifteen-second blocks** – the block time that same README has its local devchain restart with, so that conviction can be watched growing. On Gnosis Chain, where the first production deployment ran, the identical constant would be closer to a **one-day** half-life: Gnosis averaged 5.11 seconds a block over the ten thousand blocks ending at 47,879,331, read from a public RPC on 23 August 2026, which puts 17,285 blocks at about 24.5 hours. The parameter is reported faithfully in both places; only the duration moves.

The consequence is that **sustained commitment, not a single-block snapshot, is what moves money**. A whale who borrows capital to swing a vote at the last minute — the standard attack on deadline-based [token voting](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) — gains almost nothing here, because conviction cannot be bought instantly; it has to be _held_. A small group that keeps its tokens parked on a proposal for a week can out-decide a larger holder who shows up briefly.

## The dynamic passing threshold

Conviction voting has no quorum and no fixed pass bar. A proposal executes when its conviction exceeds a threshold that **scales with the fraction of the common pool it requests**: a proposal asking for a sliver of the treasury needs relatively little sustained support, while one asking for a large share needs far more, and beyond a configured maximum ratio (1Hive used `maxRatio = 0.2`, capping any single proposal at ~20% of funds) no achievable amount of conviction can pass it. Because the threshold is a function of the request size and the total pool, many proposals can be "open" and accruing conviction at once, and the community's finite total stake naturally rations itself across them — you are always implicitly trading off support for one proposal against another ([parameters: maxRatio, rho, decay](https://github.com/1Hive/conviction-voting-app)).

## Origin and production use

Conviction voting grew out of **Dr. Michael Zargham's** doctoral research on multi-agent coordination, where it was first framed as _Social Sensor Fusion_ — treating each staker as a noisy sensor whose signal you integrate over time rather than sampling once. From 2019 it was developed into a governance mechanism by the [Commons Stack, BlockScience, Aragon, and the 1Hive community](https://medium.com/commonsstack/announcing-the-conviction-voting-cadcad-model-release-8e907ce67e4e), and formally modelled and parameter-tuned in [cadCAD simulations](https://github.com/1Hive/conviction-voting-cadcad) before deployment. **1Hive's Gardens** framework, built as an Aragon app on Gnosis Chain and used to allocate its HNY common pool, was the first production system to run it ([1Hive wiki](https://wiki.1hive.org/)). It has since been picked up by other Commons-style and public-goods communities as a treasury-allocation layer. The largest live instance is [Giveth](/wiki/daos/public-goods/giveth)'s **GIVgarden**, also a Gardens deployment on Gnosis Chain, which publishes its parameters openly: a **30-day** conviction growth, a **2.50%** spending limit per proposal, **5%** minimum conviction, and **5,000**/**10,000** GIV action and challenge deposits, with challenged proposals escalating to the **Celeste** court ([GIVgarden docs](https://docs.giveth.io/givgarden)). It is a useful worked example of how the abstract parameters above get set in practice — and of the deposit-plus-court layer a production Garden adds around them, since conviction voting on its own has no mechanism for rejecting a proposal that is simply illegitimate.

## Where it fits — and where it doesn't

Conviction voting is deliberately narrow. Its strengths are real: it removes the "everyone must show up on the same day" attention tax of deadline voting — the same problem of [scaling collective attention](/wiki/dao-governance/concepts/voting/holographic-consensus) that DAOstack met with a prediction market — it makes rented-capital and flash-loan swings structurally useless, and it lets funding flow continuously instead of in lumpy voting cycles. But it is a **fund-allocation mechanism, not a general governance system** — it answers "which of these spending requests should the treasury pay?", not "should we upgrade the protocol?", for which a binary, timely, executable [proposal vote](/wiki/governance/proposals) is still the right tool. It is also **slow by design** (urgent decisions fit it poorly), and its base weighting is still [token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting): a large holder who commits for the long haul still dominates, so conviction voting mitigates timing attacks and apathy without escaping the underlying [plutocracy critique](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks). Communities that also want to blunt whale dominance pair it with, or weigh it against, [quadratic funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) and [Sybil-resistance](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) layers.

## How Caper approaches this

Caper shares conviction voting's core instinct — that **a claim on a decision should reflect more than a moment's balance** — but reaches it by a different route. A [caper](/wiki/foundations/what-is-a-caper) does not run a continuous conviction accumulator; it uses discrete, executable [proposals](/wiki/governance/proposals) whose weight is the canonical formula _w = (t · v) / (V · T)_, where _t_ is your governance-token balance and _v_ your accumulated [participation](/wiki/governance/voting-mechanisms).

The second term is where the comparison is interesting, and it is worth stating precisely rather than flatteringly. Participation is earned rather than held: one _v_ per ballot cast, and 0.01 _v_ per XRD of gross value on each leg of a trade, at deliberately identical rates so neither surface out-farms the other. So _v_ can be bought — but only by transacting with the caper itself, at the caper's own price, which is a different purchase from acquiring somebody else's accumulated weight. The record is soulbound: the vote token's `depositor` role admits only the caper's own state component, so participation cannot be bought off a holder, delegated, or lent, and the stake term is separately clamped at settlement to `min(balance at cast, balance now)`, which is what stops a rented position voting and leaving. Conviction voting gets its “you have to earn it over time” property from a decay curve on a staked position; a caper gets a weaker version of it from a non-transferable history, and the honest cost of the weaker version is that a large enough purchase buys a large enough history in one block.

And because that identical weight also sets a member's pro-rata claim on the treasury at [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) — `exit()` derives the redemption share from the same `compute_vote_weight` call the tally uses — the incentive to accumulate participation honestly is built in rather than exhorted. Where conviction voting keeps many funding requests open and lets sustained stake ration a common pool, a caper resolves each proposal to a definite outcome and then makes the market ratify it inside the market window: different mechanics, aimed at the same failure of one-block, capital-only voting.