How to Architect a Governance Model with Conviction Voting

Conviction Voting, pioneered by projects like Commons Stack and 1Hive, is a governance model designed for continuous funding proposals. Unlike one-time snapshot votes, participants signal their preference by staking governance tokens into a proposal's pool. Their conviction—the voting power—accumulates over time, proportional to the stake duration and size. This creates a system where popular, long-supported proposals naturally gain the momentum needed to pass, while fleeting interests are filtered out. It's particularly effective for retroactive funding, grants programs, and ongoing operational budgets where funding needs are recurring rather than one-off.

The core mechanism is governed by a mathematical decay function. A user's conviction for a proposal starts at zero and grows asymptotically toward their full staked amount over a defined half-life period (e.g., 7 days). If they withdraw their stake, the conviction dissipates. The total conviction for a proposal is the sum of all supporters' time-weighted stakes. A proposal executes automatically once its total conviction surpasses a dynamic threshold, which is typically calculated as a percentage of the total token supply. This threshold often decreases as the treasury size grows, making it easier to fund proposals when resources are abundant.

Architecting this system requires careful parameter selection. Key variables include the spending limit (maximum treasury outflow per period), the conviction growth half-life, and the threshold decay formula. For example, a DAO might set a half-life of 5 days, meaning a voter's conviction reaches half of its maximum value in that time. These parameters are often tested using cadCAD or other simulation frameworks before mainnet deployment to model economic outcomes and attack vectors. The smart contract logic must handle continuous conviction calculations, which can be optimized using exponential decay formulas to save gas.

A basic implementation involves a ConvictionVoting contract that manages proposal pools. Users call stake(proposalId, amount) to add support. The contract must track each stake's timestamp to calculate its decayed weight. The critical function calculateConviction(user, proposalId) might implement a formula like conviction = stake * (1 - e^(-lambda * time)), where lambda is derived from the half-life. Proposals are executed via a executeProposal(proposalId) function that checks if the current total conviction exceeds the dynamic threshold, which is recalculated on-chain based on the treasury's token balance.

When designing the governance model, integrate conviction voting with other modules. It often pairs with a proposal factory for creating funding requests, a treasury manager for holding funds, and a dispute resolution system (like Celeste or Kleros) for challenging malicious proposals. A common pattern is to use conviction for signaling and funding, while reserving token-weighted snapshot votes for major protocol upgrades. This hybrid approach, as seen in 1Hive's Gardens, balances agile community funding with secure, deliberate decision-making for high-stakes changes.

Successful deployment requires ongoing governance of the governance system itself. Parameters will need adjustment. Establish a clear process—often using a separate, more conservative voting module—for updating the half-life, spending limit, or threshold formula. Monitor key metrics: proposal passage rate, average conviction time, and treasury outflow. By treating the governance architecture as a dynamic, upgradeable system, a DAO can maintain a resilient and effective funding mechanism that aligns long-term community interest with operational agility.

The core prerequisite is a governance token with a clear distribution model. This token, often an ERC-20, represents voting power. You must decide on its initial allocation—whether through a fair launch, airdrop to early contributors, or a combination—and ensure it is widely distributed to prevent centralization. The token contract must be non-upgradeable or have clearly defined, community-controlled upgrade paths to maintain trust. For example, many DAOs use a locking mechanism like veTokenomics (inspired by Curve Finance) to align long-term incentives, where tokens are locked for voting power.

Next, you need a secure treasury contract to hold the DAO's assets, typically built using Gnosis Safe or a custom multi-signature wallet. This treasury is the source of funds for proposals that pass. The conviction voting smart contract must have permissioned access to this treasury to execute funded proposals. You'll also require a proposal factory contract that standardizes how proposals are created, ensuring they include necessary metadata like the recipient address, requested amount, and a link to detailed discussion (often on forums like Discourse or Commonwealth).

Technical setup involves deploying the conviction voting logic itself. This is often implemented using a fork of the Conviction Voting app from the Aragon OSx framework or building a custom solution using libraries like OpenZeppelin. Key parameters must be configured at deployment: the decay rate (how quickly conviction dissipates), the max ratio (maximum percentage of the treasury a proposal can request), and the minimum conviction threshold for passage. These parameters require careful economic modeling and should be initially set by the founding team, with a clear governance process to adjust them later.

Finally, establish off-chain infrastructure for community discourse. Conviction voting relies on sustained, informed discussion. Set up a forum (e.g., Discourse) for proposal ideation and a snapshot page for temperature checks before proposals move on-chain. Integrate tools like Tally or Boardroom for user-friendly voting interfaces. Ensure your front-end can interact with the deployed contracts, typically via a Web3 library like ethers.js or viem, and display real-time conviction accumulation for active proposals.

Conviction voting, pioneered by projects like Commons Stack and 1Hive, replaces discrete proposal voting with a continuous, time-based signaling system. Instead of a one-time vote, participants allocate conviction to proposals by staking tokens. This conviction grows logarithmically over time, representing increasing support. The model is designed to surface community priorities organically, fund public goods without strict budgets, and prevent governance attacks through its time-decay mechanics. It's particularly effective for retroactive funding and continuous resource allocation in DAOs.

The core mathematical function calculates a voter's conviction y for a proposal after time t has passed since their last stake, using the formula: y = x * (1 - e^{-k*t}). Here, x is the staked token amount, e is Euler's number, and k is a decay constant (e.g., k = ln(2)/7 for a half-life of 7 days). This creates an S-curve where conviction builds quickly at first, then asymptotically approaches the full staked amount. The total support for a proposal is the sum of all voters' conviction. A proposal passes when this total surpasses a dynamic threshold based on the DAO's treasury size.

A critical component is the threshold function, which protects the treasury. The required conviction to pass a proposal scales with the requested funds. A common implementation is: threshold = (alpha * funds_requested) + (beta * treasury_balance). Constants alpha and beta are governance parameters; a typical setup is alpha=1 and beta=0.01. This means requesting 100 tokens requires at least 100 conviction, plus 1% of the treasury's total value. This prevents draining the treasury with a single proposal and ensures larger requests demand broader, more sustained community consensus.

Implementing conviction voting requires a smart contract system to track staking events, calculate conviction in real-time, and execute passed proposals. Below is a simplified Solidity function snippet for calculating an individual's conviction. It uses a half-life parameter for the decay constant k.

solidityCopy
function calculateConviction(uint256 stakeAmount, uint256 timeElapsed, uint256 halfLife) public pure returns (uint256) {
    // k = ln(2) / halfLife
    int128 k = ABDKMath64x64.div(
        ABDKMath64x64.ln(ABDKMath64x64.fromUInt(2)),
        ABDKMath64x64.fromUInt(halfLife)
    );
    // exponent = -k * t
    int128 exponent = ABDKMath64x64.mul(k, ABDKMath64x64.fromUInt(timeElapsed).neg());
    // 1 - e^{exponent}
    int128 multiplier = ABDKMath64x64.sub(
        ABDKMath64x64.fromUInt(1),
        ABDKMath64x64.exp(exponent)
    );
    // conviction = stakeAmount * multiplier
    return ABDKMath64x64.mulu(multiplier, stakeAmount);
}

This function uses a fixed-point math library (ABDKMath64x64) for precision. The halfLife is set in seconds (e.g., 604800 for 7 days).

When architecting a governance model, key parameters must be calibrated: the half-life (speed of conviction growth), threshold coefficients (alpha and beta), and a minimum staking period. A shorter half-life (e.g., 3 days) leads to faster decision-making but may be more volatile. A higher beta value makes passing any proposal harder, increasing treasury security. These parameters should be tested via simulation before mainnet deployment using tools like CadCAD or Python-based agent models. Successful implementations, like 1Hive's Gardens, often start with conservative settings and allow the DAO to tune them later via governance proposals.

Conviction voting excels in specific use cases but has trade-offs. It is ideal for continuous funding platforms (like a DAO's grant program), prioritization backlogs, and signal-driven governance where sentiment evolves. However, it is less suited for urgent decisions requiring immediate execution, as building sufficient conviction takes time. The model also introduces complexity in voter UX, requiring interfaces that clearly display growing conviction and thresholds. When integrated with holographic consensus or quadratic voting, it can form a robust, multi-layered governance stack for next-generation DAOs seeking sustainable and attack-resistant coordination.

Conviction voting is a continuous, preference-signaling mechanism for DAOs, popularized by projects like Commons Stack and 1Hive. Unlike snapshot voting with fixed windows, participants allocate voting power (conviction) to proposals over time. The longer a user supports a proposal, the more conviction accrues, modeled as a logistic growth curve. This design favors proposals with sustained community support and filters out fleeting trends. The core smart contract architecture requires managing three primary states: a registry of fundable proposals, a mapping of user stakes per proposal, and a global pool of staked governance tokens.

The implementation centers on two key functions: stake and execute. The stake function allows a token holder to allocate funds to a specific proposal, which begins accumulating conviction. Conviction for a proposal at time t is calculated as Σ (stake_amount * (1 - e^(-λ * (t - stake_time)))), where λ is the decay rate constant. A separate unstake function allows users to withdraw support, resetting their conviction for that proposal to zero. The contract must track the total conviction for each proposal against a dynamically calculated threshold, which often scales with the total funds requested to prevent draining the communal treasury.

When total conviction for a proposal surpasses the execution threshold, any user can call the execute function. This function validates the proposal's status, transfers the requested funds to the beneficiary, and resets the proposal's conviction to prevent re-execution. A critical security pattern is using a time-lock or governance delay on the treasury itself, allowing a final veto period even after execution. All state changes, especially fund transfers, should be protected by reentrancy guards. The contract should also implement a proposal lifecycle with states like Active, Executed, and Cancelled to manage logic flow.

For development, you can extend existing open-source implementations like 1Hive's Gardens or Conviction Voting by Commons Stack. Key parameters to configure in your constructor include the decayRate (lambda), maxRatio (maximum percentage of the treasury a proposal can request), and minThresholdStakePercentage. Thorough testing is required for edge cases: concurrent staking/unstaking, proposal execution at the threshold boundary, and the impact of a user's total token balance changing due to external transfers. Using a forking test on Mainnet state with tools like Foundry can simulate real economic conditions.

Integrating this system requires a token vault contract (like OpenZeppelin's ERC20Votes) for snapshotting balances and a proposal factory to standardize creation. The front-end must update conviction scores in real-time, which can be done by indexing contract events or using a subgraph. Remember, conviction voting is best for continuous funding decisions (like grants) rather than binary yes/no governance. Pair it with a more traditional token-weighted voting system for protocol parameter upgrades to create a hybrid governance model that balances agility with security.

The primary design challenge is visualizing the conviction accumulation process. Unlike one-token-one-vote systems, a user's voting power grows over time as their tokens are staked. The UI must clearly display the current conviction weight for each proposal, which is a function of the amount staked and the duration. Key metrics to surface include: the user's staked amount, the time elapsed since staking, the resulting conviction score, and the proposal's total accumulated conviction. A progress bar or gauge that fills over time can effectively illustrate this dynamic growth, helping users understand the cost of withdrawing support (forfeiting accrued conviction).

Proposal discovery and filtering are critical for usability. A governance frontend should categorize proposals by status—such as Active, Pending, Passed, Failed—and allow filtering by tags (e.g., Treasury, Parameter Change, Grant). For each active proposal, the interface must prominently show the threshold required to pass and a real-time tally of the conviction for Yes and No outcomes. Implementing a clear, step-by-step modal for the staking action is essential. This flow should confirm the token lock-up period, display the estimated conviction growth curve, and warn users about the withdrawal penalty or cooldown period if they choose to exit early.

To prevent user error and ensure informed participation, the UI should integrate comprehensive tooltips and documentation inline. Hovering over terms like alpha decay parameter or max conviction should provide a brief, clear explanation of how they affect the voting math. For advanced users, consider a toggle to view raw proposal data or a detailed breakdown of the conviction calculation. The design must also account for wallet state; it should gracefully handle scenarios where a user lacks sufficient token balance or hasn't granted the necessary spending approval, guiding them through the required steps before they attempt to stake.

Finally, consider implementing interactive simulations. A powerful feature is a "simulate support" widget where users can adjust a slider for stake amount and duration to see a preview of the conviction they would generate and its potential impact on the proposal's outcome. This empowers strategic participation. All state changes—successful stakes, conviction updates, proposal passage—should trigger clear notifications. The frontend must reliably poll the smart contract or subscribe to events to keep all displayed data synchronized with the blockchain, as outdated conviction totals would severely undermine trust in the system.

Architecting a governance model with conviction voting requires balancing several key parameters: the decay function (often quadratic) that builds conviction over time, the threshold for proposal execution, and the minimum stake required to submit proposals. These parameters directly impact voter engagement, proposal quality, and the system's resistance to attacks. For example, a high minimum stake can deter spam but may centralize proposal power. Your parameter choices should reflect your community's size, token distribution, and desired governance velocity.

When implementing, start with a testnet deployment using frameworks like OpenZeppelin's Governor with a custom voting module. Use a script to simulate voting behavior over weeks or months, analyzing how different parameter sets affect outcomes. Key metrics to track include: - Proposal passage rate - Average time to reach threshold - Distribution of voter participation. Tools like Tenderly or a custom subgraph can help visualize this data. Remember, the initial parameters are a hypothesis; be prepared to adjust them via a meta-governance proposal after observing real user behavior.

Your governance model is not static. The next evolution often involves optimizing for scalability and security. Consider implementing batch processing for vote aggregation to reduce gas costs, or a schelling point mechanism to handle contentious proposals that linger near the threshold. For deeper integration, explore bridging conviction signals to other protocols via cross-chain governance standards like Axelar's Interchain Amplifier or LayerZero's Omnichain Fungible Tokens (OFTs) to allow voting with assets on multiple chains.

Further research should focus on mitigating known limitations. Voter apathy can be addressed with delegated conviction voting or bribe-resistant mechanisms like Hidden Markov Models for vote revelation. Plutocracy risks can be mitigated with mechanisms like quadratic funding matching pools for proposals, or a conviction-weighted sortition to randomly select citizen assemblies for specific decisions. Review academic papers and existing implementations from projects like Commons Stack, 1Hive, and Aragon for proven patterns.

Finally, document your system's rules and parameters clearly for participants. A transparent constitution or governance handbook reduces ambiguity and builds legitimacy. The goal is to create a resilient, adaptive system where conviction translates into legitimate, executable community decisions. Start simple, measure rigorously, and iterate based on data to cultivate a thriving on-chain governance ecosystem.