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 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 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 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 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 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 — 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).
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, and formally modelled and parameter-tuned in cadCAD simulations 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). 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'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). 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 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 is still the right tool. It is also slow by design (urgent decisions fit it poorly), and its base weighting is still token-weighted: 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. Communities that also want to blunt whale dominance pair it with, or weigh it against, quadratic funding and Sybil-resistance 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 does not run a continuous conviction accumulator; it uses discrete, executable proposals whose weight is the canonical formula w = (t · v) / (V · T), where t is your governance-token balance and v your accumulated participation.
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 — 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.