How to Design a Conviction Voting Model

Conviction voting replaces snapshot-based voting with a fluid system. Instead of a one-time vote, participants signal their preference by staking tokens on proposals. Their voting conviction—the influence of their stake—grows according to a time-based decay function, often modeled as y = 1 - (1 - α)^t. Here, α is a growth rate constant (e.g., 0.05) and t is the time the stake has been committed. This creates a cost for rapid reallocation of support, as conviction resets when funds are moved, favoring long-term, considered proposals over fleeting popular opinion.

The primary mechanism involves two key functions: staking and withdrawing. When a user stakes tokens on a proposal, the contract records the stake amount and timestamp. The contract's getConviction function then calculates the current conviction for that stake using the decay formula. The total conviction for a proposal is the sum of all individual convictions. A common implementation uses a half-life parameter, where conviction reaches 50% of its maximum after a defined period, making the system's responsiveness configurable.

A critical design choice is the threshold function that determines when a proposal passes. This is often a dynamic threshold based on the total funds available in the communal treasury (T). A simple model sets the required conviction C_required = k * T, where k is a threshold ratio (e.g., 0.2). This ensures larger funding requests require broader, more sustained community support. The 1Hive Gardens framework popularized this model, using an α of ~0.05 and a threshold of 20% of the treasury for maximum requests.

When implementing, you must manage state efficiently. For each stake, store amount, timestamp, and proposalId. The contract should update a proposal's total conviction in a view function by iterating through stakes, calculating each one's decayed weight. To optimize gas costs for on-chain execution, consider using a conviction snapshot updated at regular intervals or upon key actions, rather than recalculating in real-time for every transaction.

Designers must also configure parameters for their community's needs. A higher α (growth rate) leads to faster conviction accumulation, making the system more agile but potentially less resistant to manipulation. A higher threshold ratio k makes passing proposals harder, favoring conservatism. These parameters should be tested through simulation using historical proposal data before mainnet deployment. Tools like CadCAD can model the economic dynamics of different parameter sets.

In practice, conviction voting is used by DAOs like 1Hive and Commons Stack to manage community funds. It excels for continuous funding of ongoing initiatives (like developer grants) rather than binary yes/no decisions. The final system should include a clear interface for users to stake, withdraw, and view proposal conviction, creating a transparent and deliberate funding pipeline for decentralized communities.

Conviction voting is a continuous decision-making mechanism for decentralized governance, where voting power accrues over time as tokens are staked on proposals. Unlike one-person-one-vote or snapshot voting, it uses a conviction score that increases the longer funds are committed, modeling a community's sustained interest. The primary system design goals are to prevent flash loan attacks, encourage long-term participation, and surface proposals with genuine, persistent support. Key prerequisites include a native governance token (e.g., an ERC-20), a smart contract framework for proposals, and a clear definition of the treasury or resource pool being allocated.

The mathematical core is the conviction accumulation function. A common implementation uses a logistic growth curve, where conviction c for a proposal p at time t is calculated as: c(p, t) = Σ (staked_tokens * (1 - e^(-λ * (t - stake_time))). Here, λ (lambda) is the decay constant controlling the growth rate. This ensures early votes have minimal impact, while sustained support compounds. The total conviction across all proposals is used to determine which one first surpasses a dynamic threshold, often a percentage of the total tokens staked in the system, triggering execution.

Smart contract design must handle several states: Proposal Creation, Staking/Unstaking, Conviction Calculation, and Execution. A typical architecture involves a main ConvictionVoting contract that references a Treasury or FundingPool. Proposals are structs containing metadata, requested amount, beneficiary, and accrued conviction. The contract must track each user's stake per proposal and the timestamp of their action to calculate individual contributions to the total conviction score on-chain or via a periodic update function.

Critical parameters require careful calibration. The decay rate (λ) affects how quickly conviction builds; a higher value leads to faster saturation. The threshold function determines the required conviction to pass; it can be fixed or dynamic based on total staked supply (threshold = α * total_staked). A minimum staking period prevents instant withdrawal gaming. Additionally, a global cooling-off period after a proposal passes prevents immediate reallocation of the same funds. These parameters are often set via governance itself.

Security considerations are paramount. Use a pull-payment pattern for treasury withdrawals to avoid reentrancy. Implement checks-effects-interactions patterns. Guard against proposal spam with a submission deposit. Since conviction is stateful, be mindful of gas costs for real-time calculations; consider off-chain computation with on-chain verification (e.g., using a snapshot of scores updated per block). Always audit the integration with your token contract to ensure proper allowance and transfer handling.

For implementation, you can extend existing battle-tested libraries. The Commons Stack and 1Hive have open-source conviction voting modules for Aragon OSx. Alternatively, you can build on frameworks like OpenZeppelin Governor with custom voting logic. Testing should simulate long-term staking behavior and attack vectors like proposal flooding. A well-designed model creates a robust, sybil-resistant system for continuous resource allocation in DAOs.

In a standard token-weighted vote, a user's voting power is a snapshot of their balance. Conviction voting replaces this with a conviction score that grows as tokens are staked on a proposal and decays when they are withdrawn. The core innovation is the time-decay function, which ensures that long-term commitment is rewarded while allowing capital to remain liquid. This creates a sybil-resistant mechanism where influence is earned through sustained participation, not just wealth.

The function models conviction as a fluid that accumulates in a "bucket" attached to a proposal. The rate of accumulation is proportional to the staked tokens. Simultaneously, a continuous decay process drains the bucket over time. The key parameter is the decay rate, often expressed as a half-life. For example, a half-life of 7 days means a user's conviction score for a proposal would reduce by half every week if they stopped adding support. This creates a predictable, exponential decay curve.

Here is a simplified Solidity-esque example of a function to calculate a user's conviction at a given block. It uses a discrete-time approximation suitable for blockchain state.

solidityCopy
function calculateConviction(
    uint256 stakedAmount,
    uint256 lastUpdateBlock,
    uint256 currentConviction
) public view returns (uint256 newConviction) {
    uint256 blocksElapsed = block.number - lastUpdateBlock;
    // Apply decay: conviction = conviction * decayFactor^blocksElapsed
    // decayFactor per block is derived from a half-life (e.g., 0.999 for a ~7-day half-life at 12s blocks)
    uint256 decayedConviction = currentConviction * (decayFactor ** blocksElapsed);
    // Add new stake
    newConviction = decayedConviction + stakedAmount;
}

The decayFactor is a number slightly less than 1 (e.g., 0.999), calculated offline based on the desired half-life and average block time.

Designing the decay rate is a critical governance decision. A faster decay (shorter half-life) makes the system more responsive, allowing community sentiment to shift quickly, but reduces the cost of proposal spam. A slower decay (longer half-life) encourages long-term strategic planning and increases the cost of attacking the system, but can make it sluggish. Projects like Commons Stack and 1Hive Gardens typically experiment with half-lives between 3 and 30 days, tuning them based on their community's desired pace of decision-making.

To implement this effectively, your smart contract must track several state variables per user per proposal: the stakedAmount, the lastUpdated block number, and the current conviction score. Every interaction—staking, withdrawing, or checking vote totals—must trigger a recalculation using the function above to apply all accrued decay before performing the new operation. This ensures the system's state is always current and prevents users from gaming timing delays.

The final output of this system is an aggregate total conviction for each proposal, which is the sum of all users' decayed conviction scores. The proposal with the highest total conviction that also surpasses a predefined passing threshold can be executed. This threshold is usually a percentage of the total possible conviction (e.g., 10% of total token supply), providing a built-in quorum check and protecting against low-participation outcomes.

Conviction voting, popularized by projects like Commons Stack and 1Hive, replaces discrete voting events with a continuous system. Participants signal support by staking tokens on proposals they favor. Their "conviction"—and thus their voting power—accrues over time, following a logistic growth curve. This design prioritizes long-term, committed support over fleeting sentiment, making it ideal for funding public goods or managing community treasuries where deliberation is valuable. The key components are the stake, the time it's been staked, and a growth function that determines voting power.

To implement a basic model, you must define several core parameters. The half-life dictates how quickly conviction grows; a 7-day half-life means it takes a week for a stake to reach half its maximum power. The maximum conviction caps the voting power a single stake can achieve, often after 4-5 half-lives. The threshold function determines the amount of total conviction required for a proposal to pass, which can be a fixed amount or a dynamic percentage of the total tokens staked in the system. These parameters directly influence proposal velocity and the cost of attacking the system.

A critical design choice is the alpha parameter in the conviction growth formula, which controls the shape of the logistic curve. A higher alpha makes early growth slower, requiring longer commitment to gain significant power, which can deter spam. The formula is typically implemented in a smart contract as: conviction = max_conviction * (1 - e^(-alpha * time_staked)). You can find a reference implementation in the 1Hive Gardens conviction voting contract. Adjusting alpha allows you to balance between responsiveness and stability in your governance process.

The proposal lifecycle must be integrated with this continuous voting mechanism. Proposals typically have a requested amount and a beneficiary. The system continuously checks if a proposal's total conviction exceeds the passing threshold. Upon passing, funds are automatically disbursed from the treasury to the beneficiary, and all staked tokens are released back to voters. To prevent stagnation, many systems include a decay mechanism for inactive proposals or a proposal expiration period after which stakes are returned if the threshold isn't met.

When designing your model, consider these trade-offs: a long half-life and high alpha promote careful deliberation but slow down funding. A dynamic threshold based on treasury size (e.g., using a minimum viable percentage) can prevent large, rushed withdrawals. For security, implement a proposal spam filter, such as a minimum stake deposit to submit a proposal. Test your parameters extensively using simulations or a testnet before mainnet deployment to ensure they align with your community's desired pace and security posture.

Unlike one-time snapshot voting, conviction voting measures the intensity of a voter's preference by accumulating voting power the longer a token is staked on a proposal. This model, pioneered by projects like Commons Stack and used by DAOs such as 1Hive, is designed to surface community consensus on funding requests without requiring synchronous participation. It transforms a treasury from a batch processor of proposals into a dynamic market of competing ideas, where funding likelihood is a function of time and collective conviction.

The core mechanism relies on a mathematical conviction score that grows according to a logistic growth curve. A common formula is: conviction = (total_staked_tokens * time_elapsed) / (total_staked_tokens * time_elapsed + decay_factor). The decay_factor is a crucial parameter that controls how quickly conviction builds; a higher value results in slower growth, requiring longer-term support to reach funding thresholds. This creates a natural cooling-off period and prevents impulsive spending.

To implement a basic model, you need a smart contract system with several key functions. Proposals are submitted with a requested amount and a recipient address. Users stake their governance tokens on proposals they support, and their stake is locked until they withdraw it. The contract must continuously calculate the conviction score for each active proposal, typically by updating state with each new stake, withdrawal, or the passage of time via an oracle or periodic function call.

A critical design choice is setting the funding threshold. This is often a function of the treasury's size and risk tolerance. A simple rule is: threshold = alpha * sqrt(treasury_balance). The alpha parameter acts as a global spending limit coefficient; a lower alpha makes it harder to fund large proposals, conserving treasury capital. When a proposal's conviction score exceeds this dynamic threshold, it can be executed, transferring funds to the recipient.

Effective parameter tuning is essential for system health. Key parameters include the decay_factor, funding alpha, and sometimes a minimum_stake or proposal_duration. These should be calibrated through simulation or historical data analysis before mainnet deployment. For example, a DAO with a $10M treasury might start with alpha = 0.2 and a decay_factor equivalent to 7 days for half-saturation, then adjust based on governance feedback. Tools like CadCAD can be used for simulation.

Consider integrating additional features for robustness. A proposal cancellation function allows voters to withdraw support if new information emerges. Streaming payments can be implemented by funding proposals incrementally as conviction is maintained, rather than in a lump sum. Finally, ensure front-end interfaces clearly visualize the conviction growth curve and threshold for each proposal, enabling informed voter participation. The goal is a system that aligns long-term community interest with treasury expenditure.

A conviction voting model allows DAO members to signal support for proposals by staking tokens over time. Unlike one-time snapshot votes, conviction accumulates as tokens remain staked, reflecting the depth and duration of a voter's preference. The core formula calculates conviction as the integral of staked tokens over time, often using an exponential decay function. This creates a time-weighted preference system where long-term, committed support carries more weight than a sudden, large stake. Key parameters include the decay_rate (how quickly conviction fades), max_ratio (maximum percentage of treasury a proposal can request), and threshold (conviction needed to pass).

The primary security model relies on economic alignment and patience as a sybil-resistance mechanism. An attacker must lock a significant capital stake for a sustained period to influence an outcome, making attacks costly and detectable. However, design flaws can introduce vulnerabilities. A critical risk is proposal spam, where many low-cost proposals are submitted to dilute voter attention and conviction, potentially allowing a malicious proposal to pass with lower scrutiny. Implementing a proposal submission deposit that is slashed if the proposal fails and a minimum conviction threshold are essential countermeasures.

Another major attack vector is the fund exhaustion attack. If the max_ratio parameter is set too high relative to the treasury size, a passed proposal could drain a catastrophic amount of funds in a single transaction. Mitigations include setting a conservative max_ratio (e.g., 5-10% of treasury), implementing a time-lock on executed proposals for community review, and requiring a multi-sig safeguard for large withdrawals. The conviction decay function itself must be secure; a miscalculated decay_rate can lead to "conviction ghosts" where old, unstaked votes continue to influence decisions.

The funding pool mechanism also presents risks. In models where approved proposals draw from a shared pool, a priority gas auction (PGA) can occur. When the pool is nearly depleted, competing proposers may bid up transaction gas fees to be the first to claim the remaining funds, creating a toxic, costly environment. A hatch or budget box pattern, which allocates a fixed, non-competitive stream of funds to each passed proposal, can prevent PGAs. Additionally, using a conviction voting oracle that updates off-chain and posts periodic state snapshots can reduce on-chain gas costs and front-running opportunities.

Smart contract implementation requires careful auditing. The contract must accurately track each voter's stake history to calculate decay. A common bug is incorrect time handling, where conviction does not decay correctly across block timestamps. Use established libraries like OpenZeppelin's SafeCast for time math. Furthermore, the contract should include an emergency shutdown function, governed by a separate, faster mechanism (like a 2-of-5 multisig), to freeze the system if a critical exploit is detected. Always fork and audit existing battle-tested implementations, such as those from 1Hive or Commons Stack, before deploying a custom solution.

Finally, monitor for governance fatigue and voter apathy, which are systemic risks rather than direct exploits. If participation is too low, the system becomes vulnerable to a determined attacker. Design for inclusivity by integrating with sybil-resistant identity systems like BrightID or using delegated conviction, where users can delegate their stake-power to representatives. Continuous parameter tuning via meta-governance is crucial; the DAO should be able to adjust decay_rate, threshold, and max_ratio based on network activity and treasury health to maintain a resilient and active decision-making process.

To design an effective conviction voting model, start by defining your governance parameters. Key decisions include the conviction_growth_rate (alpha), which controls how quickly support accumulates, and the minimum_threshold for proposal funding. For a community treasury, a common starting point is a 50% threshold and a half-life of 5-7 days for conviction decay. These values should be calibrated based on your treasury size and desired proposal velocity. Tools like CadCAD or Token Engineering Commons' models can help simulate different parameter sets before on-chain deployment.

The technical implementation requires a smart contract to track user stakes and calculate real-time conviction. A basic structure involves a mapping of proposals to a staking ledger and a function that updates scores based on the formula: conviction = previous_conviction * decay_factor + new_stake. You must also integrate a mechanism to execute proposals automatically once the threshold is met and conviction is highest, often using a Gelato Network keeper or a similar automation service. Security audits for the conviction math and fund release logic are non-negotiable.

For further learning, study live implementations from leading DAOs. The Commons Stack pioneered conviction voting for public goods funding, while 1Hive's Gardens offer a forkable framework. Recommended next steps are to: 1) Run parameter simulations with your community, 2) Deploy a testnet version using a template like TEC's Conviction Voting app, and 3) Establish clear proposal lifecycle guidelines for your members. Effective conviction voting reduces governance fatigue and creates a dynamic, demand-driven treasury.