Conviction voting asks a different question: what if commitment over time mattered?
The premise is intuitive. Someone willing to stake their vote on a proposal for weeks probably cares more than someone who clicks and forgets. Long-term community members should perhaps carry more weight than drive-by participants. Patience might be a reasonable proxy for genuine investment in outcomes.
This intuition has real merit. It also creates vulnerabilities that naive implementations miss entirely.
How Conviction Voting Works
The basic mechanism is straightforward.
Instead of casting a vote that counts immediately, you allocate voting power toward a proposal. That allocation accumulates weight over time according to some function—often exponential growth toward a cap. The longer your votes stay committed, the more influence they carry.
Proposals pass when accumulated conviction crosses a threshold. This threshold might be fixed or dynamic, often scaling with how much of a shared resource the proposal requests. Asking for 1% of the treasury requires less conviction than asking for 50%.
You can withdraw your votes at any time, but withdrawal resets your accumulated conviction. Switch from Proposal A to Proposal B and you start from zero on B. This creates switching costs—you pay in lost conviction for changing your mind.
The system rewards sustained attention. It penalizes fickleness. It makes capturing a vote expensive in time, not just money.
What Conviction Voting Gets Right
Several genuine benefits emerge from this design:
Sniping resistance - There's no deadline to exploit. Proposals don't close at midnight. Conviction accumulates continuously, and passing thresholds can happen at any moment. Waiting until the last minute doesn't help because there is no last minute.
Whale resistance - Time can't be bought. A billionaire has the same 24 hours per day as everyone else. If you need sustained commitment over weeks, wealth advantages compress. Someone with 10x your tokens but one-tenth your patience might end up with equal influence.
Drive-by resistance - Coordinated attacks that mobilize brief attention lose effectiveness. If a thousand bots show up, vote, and leave, their conviction never accumulates. The attack dissipates before crossing thresholds.
Deliberation encouragement - Because commitment costs something (locked votes, lost flexibility), participants have incentives to consider carefully before allocating. The system rewards thoughtfulness over reflexive reactions.
These are real advantages. Conviction voting addresses vulnerabilities that plague simpler mechanisms. The question is what new vulnerabilities it introduces.
The Patience Attack
Here's the problem: what if your attacker isn't impatient?
Conviction voting assumes attackers want quick results. Many do. But a sophisticated adversary might plan in months, not minutes.
Consider a hostile actor who accumulates tokens over time—slowly, to avoid detection. They stake those tokens on governance months before any controversial proposal. They wait. Conviction builds. They participate in routine votes, appearing to be a normal community member.
Then, when the moment is right, they already have massive accumulated conviction to deploy. The community faces a sudden shift that looks like it came from nowhere but was actually months in preparation.
This is worse than standard plutocracy. In a simple token-weighted vote, the community at least sees the whale entering. In conviction voting, the whale was already submerged, conviction building silently, invisible until they strike.
Defenders have no warning because there's nothing to warn about. Holding tokens and accumulating conviction is legitimate behavior. The attack is indistinguishable from engagement until the moment it isn't.
Lock-In Dynamics
Conviction voting penalizes changing your mind. This is a feature—it prevents fickleness. It's also a vulnerability—it prevents adaptation.
Imagine you've staked conviction on Proposal A for three weeks. You've built significant accumulated weight. Then new information emerges: Proposal A has a flaw you hadn't considered, or Proposal B turns out to be better designed.
Switching costs you those three weeks of accumulation. You start over from zero. The rational choice might be to stick with the inferior proposal rather than pay the switching cost. Your accumulated conviction becomes a trap.
This creates path dependency. Early commitments get locked in not because they're best but because abandoning them is expensive. Communities can find themselves stuck with suboptimal decisions because the cost of changing course exceeds the cost of continuing on a bad path.
Attackers can exploit this deliberately. Propose something superficially attractive, wait for conviction to accumulate, then reveal problems only after supporters are locked in. The sunk cost fallacy does the rest.
Threshold Gaming
Dynamic thresholds create their own attack surface.
If the conviction required to pass a proposal scales with what's being requested, strategic actors will game the request size. Ask for slightly less than a threshold breakpoint. Bundle multiple requests to stay under limits. Split large extractions into smaller pieces that individually seem reasonable.
This is familiar from any system with thresholds—tax brackets, regulatory limits, procurement rules. Wherever lines exist, optimization against those lines follows.
More subtly, threshold systems can be probed. Submit proposals you don't care about to measure how much conviction the community can muster. Learn the defense's capacity. Then design your real attack to just barely exceed it.
Liquidity Costs
In token-based conviction systems, staked tokens are typically locked. They can't be traded, used elsewhere, or easily liquidated.
This creates asymmetric costs. Wealthy actors can afford to lock significant resources indefinitely—it's a rounding error on their portfolio. Average participants face real opportunity costs. Locking tokens for governance means not using them for anything else.
Over time, governance participation concentrates among those who can afford the liquidity cost. Conviction voting started as a check on wealth; through liquidity dynamics, it can reconcentrate wealth's advantages.
Some systems try to mitigate this with rewards for participation—essentially paying people for the liquidity cost of locking tokens. But rewards create their own incentives: mercenary voters who participate for rewards rather than outcomes, reward farming through minimal engagement, and potentially reinforcing concentration as large holders earn larger rewards.
The Conviction Decay Question
Should accumulated conviction decay over time?
Without decay, someone who staked votes years ago and stopped paying attention still carries influence. Their conviction remains locked in, possibly on proposals or positions no longer relevant, definitely reflecting preferences that may have changed.
With decay, conviction becomes a treadmill. You have to keep showing up to maintain influence. This filters for sustained engagement but exhausts participants and privileges those with unlimited time.
Different systems choose different decay functions. Some use no decay—accumulated conviction persists until withdrawn. Some use continuous slow decay—you have to periodically reaffirm commitments. Some use triggered decay—conviction resets under specific conditions like proposal completion.
Each choice shapes who participates and how. There's no neutral option. The decay function encodes assumptions about what kind of engagement you're optimizing for.
Interaction With Other Attacks
Conviction voting doesn't exist in isolation. It interacts with every other attack vector we've discussed.
Sybil attacks - Conviction compounds the Sybil problem. A hundred fake accounts each accumulating conviction separately creates far more damage than a hundred fake accounts voting once. The time dimension multiplies identity vulnerabilities.
Vote buying - Instead of buying votes, you buy conviction. Pay someone to lock their tokens on your proposal for a month. The transaction is harder to detect because there's no discrete voting moment—just ongoing stake.
Collusion - Cartels in conviction systems coordinate not just how to vote but when to shift conviction. Synchronized reallocation by a bloc can swing outcomes without adding new resources. The timing attack and the collusion attack combine.
Defense requires addressing conviction voting's vulnerabilities alongside, not instead of, the foundational vulnerabilities we've already discussed. Conviction is a layer, not a replacement.
When Conviction Voting Works
Despite these vulnerabilities, conviction voting genuinely helps in specific contexts.
Resource allocation from ongoing pools - When you're distributing a continuous flow rather than making one-time decisions, conviction's time dimension maps well to the problem structure. Grant programs, streaming payments, and ongoing funding fit naturally.
Communities with stable, engaged membership - When participants know each other and maintain long-term involvement, conviction rewards what's already present. The patience attack is less viable when the community would notice a new actor slowly accumulating suspicious positions.
Low-stakes, high-frequency decisions - Routine governance where the cost of any single bad decision is limited gives conviction systems room to self-correct. Problems surface before they become catastrophic.
Defense against specific known threats - If your primary concern is drive-by attacks from external actors seeking quick captures, conviction voting directly addresses that threat even if it opens others.
When Conviction Voting Fails
The mechanism fits poorly elsewhere:
High-stakes binary decisions - When you need a definitive yes/no on something irreversible, conviction's continuous accumulation creates ambiguity. Did the proposal pass? When? What's the cutoff? Binary decisions want binary mechanisms.
Rapidly changing contexts - When the right answer changes frequently—market conditions, emergency response, evolving technical landscapes—conviction's switching costs become pure drag. You need flexibility, not commitment.
Anonymous or pseudonymous systems - When you can't constrain Sybil attacks through identity, conviction multiplies rather than mitigates the damage. Time becomes another axis for fake accounts to accumulate illegitimate influence.
Communities with high turnover - When participants come and go frequently, conviction privileges old-timers regardless of their continued relevance. Newcomers face structural disadvantage no matter how valuable their perspectives.
Implementation Nuances That Matter
If you're building a conviction system, details determine whether it works:
The accumulation function - Linear growth, exponential growth, logarithmic growth—each creates different incentive landscapes. Exponential growth rewards early commitment heavily. Logarithmic growth compresses advantages for the patient.
The cap, if any - Uncapped conviction accumulation lets patient attackers build unlimited influence. Capped accumulation limits this but also limits legitimate long-term engagement. Where you set the cap, and how, shapes everything.
Withdrawal penalties - Instant withdrawal with full conviction loss versus gradual withdrawal with partial retention create very different strategic environments. The harsher the penalty, the more lock-in you create—for good and ill.
Proposal lifecycle - Can proposals be modified while conviction accumulates? Can they be withdrawn? What happens to staked conviction if a proposal is abandoned? Every edge case is an attack surface.
Visibility and transparency - Can participants see accumulating conviction on proposals? Real-time visibility enables coordination and gaming. Opacity prevents informed participation. Neither is safe.
The Honest Assessment
Conviction voting is genuinely clever mechanism design. It addresses real problems with real solutions. The time dimension adds something valuable that pure token-weighted or one-person-one-vote systems lack.
It is not a solution. It trades one vulnerability profile for another. Patient attackers, lock-in dynamics, threshold gaming, and liquidity costs create failure modes that simple voting systems don't have.
The question isn't whether conviction voting is good or bad. It's whether its specific tradeoffs match your specific context. Sometimes they do. Often they don't. Using conviction voting because it sounds sophisticated without understanding its failure modes is worse than using simple mechanisms you actually understand.