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; 1Hive's reference Aragon app, for example, shipped with a decay of 0.9999599, giving conviction a roughly three-day half-life (1Hive/conviction-voting-app).

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.

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, 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 durable commitment should count for 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 is your accumulated participation. The time dimension lives in that v term: participation is earned by showing up to vote and is not something you can buy in a block, so a long-standing contributor carries structurally more weight than a large holder who just arrived — the same "you can't rent it, you have to earn it over time" property conviction voting gets from its decay curve, expressed as a soulbound participation record rather than a staked-duration integral. And because that identical weight also sets a member's pro-rata exit share, the incentive to accumulate participation honestly is built in. Where conviction voting keeps many funding requests open and lets sustained stake ration a common pool, Caper resolves each proposal to a definite executed outcome — different mechanics, aimed at the same failure of one-block, capital-only voting.