How to Implement Conviction Voting for Budget Allocation

Conviction voting is a governance mechanism designed for continuous, fluid funding decisions, popularized by projects like Commons Stack and 1Hive. Unlike traditional one-time snapshot votes, it allows participants to signal their preference for a proposal by staking tokens on it over time. The "conviction" for a proposal accumulates based on the amount and duration of the stake, creating a time-weighted sentiment graph. This model is particularly effective for recurring budget allocations like grants, operational expenses, or ecosystem funding, as it surfaces community priorities without requiring frequent discrete voting events.

The core algorithm calculates a proposal's conviction score using a logistic growth function. When a user stakes tokens on a proposal, their conviction contribution starts at zero and asymptotically approaches their full stake weight over a configurable half-life period (e.g., 7 days). The total conviction for a proposal is the sum of all contributors' time-weighted stakes. A proposal passes and receives funding when its conviction score surpasses a dynamic threshold, typically defined as a percentage of the total tokens staked in the governance system (alpha) multiplied by the requested budget amount. This creates a market-like mechanism where proposals compete for a limited treasury.

To implement a basic conviction voting system, you need a smart contract with key state variables: a mapping of staked amounts per user per proposal, a record of last update timestamps, and the proposal's parameters (requested amount, beneficiary). The critical function updates a user's conviction using the formula: conviction = stake * (1 - e^(-lambda * time_elapsed)), where lambda = ln(2) / half_life. This must be called whenever a user stakes, unstakes, or when checking if a proposal has passed. The Conviction Voting API by 1Hive provides a practical, audited reference implementation built for Aragon OSx.

When integrating conviction voting, several parameters must be carefully tuned. The half-life controls how quickly conviction builds; a shorter period makes the system more responsive but volatile. The alpha ratio (often between 0.2 and 0.5) sets the spending threshold relative to the staked supply; a higher alpha makes passing proposals harder. You must also decide on a proposal enactment delay after passing to prevent flash loans from manipulating outcomes. For treasury management, it's common to use a hatch or streaming pattern, where funds are released gradually to the beneficiary rather than in a single lump sum.

Effective front-end design is crucial for user adoption. The interface should clearly visualize: the conviction growth curve for each proposal, the current threshold line for passage, and the real-time impact of a user's potential stake. Tools like The Graph can index staking events and conviction scores to power these dashboards. For developers, the primary integration points are the staking/unstaking transactions and listening for Stake/Unstake/ProposalExecuted events. Remember that conviction voting is often combined with other modules, such as a proposal curator (e.g., a token-weighted threshold to list proposals) or a rage-quit mechanism for dissenting voters.

In practice, successful implementations like 1Hive's Celeste or Gardens pair conviction voting with dispute resolution systems to handle malicious proposals. For ongoing budget allocation—such as a developer grant program—conviction voting creates a prioritized backlog where the most consistently supported proposals rise to the top. When implementing, start with a testnet deployment using a mock token, simulate long-term staking behavior, and adjust parameters based on the desired proposal passage rate and treasury runoff. This mechanism shifts governance from periodic, high-stakes votes to a continuous, engaged signaling process.

Before writing any code, you must establish your development environment and understand the core dependencies. The primary tool for building a conviction voting system is a smart contract framework like Hardhat or Foundry. You will also need Node.js (v18 or later) and a package manager like npm or yarn. For blockchain interaction, set up a wallet such as MetaMask and obtain testnet ETH from a faucet (e.g., Sepolia). This environment allows you to compile, test, and deploy your contracts locally and to testnets before a mainnet launch.

The smart contract logic forms the backbone of the system. You will need a basic understanding of Solidity (v0.8.x) and key contract patterns. Essential contracts include a Voting Token (often an ERC-20 or ERC-721), a Proposal Registry to manage funding requests, and the core Conviction Voting contract that calculates and stores conviction scores. For gas efficiency and security, consider using established libraries like OpenZeppelin Contracts for token standards and access control. The conviction formula itself, typically integrating time and token weight, must be implemented in a way that is resilient to reentrancy and manipulation.

Off-chain components are critical for a functional user interface and data indexing. You will need a way to listen for on-chain events and calculate real-time conviction scores. This is typically done using The Graph for indexing or a custom indexing service built with ethers.js. The frontend can be built with a framework like React or Vue, using a Web3 library such as wagmi or ethers.js to connect wallets and interact with contracts. Prepare to handle wallet connections, contract function calls (propose, stake, withdraw), and display dynamic data like proposal history and live conviction growth.

Testing is non-negotiable for a financial governance mechanism. Write comprehensive unit and integration tests using Hardhat's testing environment, Foundry's Forge, or Truffle. Test critical scenarios: proposal creation, token staking over time, conviction decay, successful funding when thresholds are met, and security edge cases like flash loan attacks. Use forked mainnet simulations to test interactions with live price oracles if your formula uses them. A well-tested system prevents catastrophic bugs in a live treasury environment.

Finally, plan your deployment and initial configuration. Use environment variables (via a .env file) to manage private keys and RPC URLs securely. Script your deployment process for reproducibility. Key initialization parameters must be set carefully, including the decay rate (alpha), maximum ratio for fund allocation, and minimum stake duration. These parameters dictate the system's responsiveness and security; their values should be simulated and debated by the community before launch. Once deployed, you will verify the contracts on a block explorer like Etherscan and prepare documentation for end-users.

Conviction voting is a quadratic funding mechanism designed for decentralized, continuous budget allocation, popularized by projects like Commons Stack and 1Hive. Unlike one-time snapshot votes, participants signal their preference for a proposal by staking tokens over time. The "conviction" for a proposal grows as a sigmoid function of the total stake and its duration, simulating a gradual build-up of community support. This design favors proposals with sustained, organic backing over fleeting popular votes, aligning long-term treasury management with demonstrated, ongoing demand.

The core smart contract must manage several key states: a list of active funding proposals, a ledger of user stakes per proposal, and a continuously updating conviction score for each. The conviction formula is typically calculated as y = x^2 / (x^2 + a^2) * S, where x is the time staked, a is a tunable decay factor, and S is the total stake. This S-curve ensures conviction starts slowly, accelerates, and eventually saturates. The contract must recalculate scores on-chain, often using an accumulator that updates with each stake, unstake, or periodic heartbeat transaction to avoid excessive gas costs.

A basic implementation involves three primary functions. First, stake(uint256 proposalId, uint256 amount) allows a user to lock tokens in support of a proposal, triggering a conviction update. Second, unstake(uint256 proposalId, uint256 amount) releases tokens, reducing that proposal's conviction. Third, an execute(uint256 proposalId) function allows any user to trigger the funding transfer if a proposal's conviction surpasses a dynamic threshold, often based on a percentage of the total treasury or a predefined budget. Events should be emitted for all state changes to enable off-chain tracking.

Critical design considerations include attack vectors and parameter tuning. Without safeguards, a whale could stake a large amount just before execution. Mitigations include enforcing a minimum stake duration or using a vote escrow model where voting power decays linearly over a fixed lock period. The decay factor a in the conviction formula determines the proposal's "half-life" and must be calibrated to the community's desired decision speed. Testing with simulation frameworks like cadCAD or ArchiMate is recommended before mainnet deployment.

For developers, integrating with existing frameworks accelerates development. The Conviction Voting API by 1Hive provides audited Solidity contracts and a subgraph for querying state. A typical architecture involves the core contract, a token wrapper for the staking asset (e.g., wxDAI), and an external data provider (oracle) for price feeds if threshold calculations use USD values. Front-end clients can use the subgraph to display real-time conviction scores, stakeholder data, and proposal history.

In practice, conviction voting is deployed for community grant programs, like GnosisDAO's ecosystem fund, or continuous funding of public goods. When implementing, start with a testnet deployment using a mock token. Use a scripted simulation to model stakeholder behavior and fine-tune parameters. The final system creates a more resilient, demand-driven treasury where funding flows persistently to initiatives with proven, enduring community support, moving beyond simple majority votes.

The conviction decay function is the mathematical engine behind conviction voting, a mechanism for continuous, non-binary funding decisions. Unlike one-time snapshot voting, conviction measures a voter's stake-weighted commitment over time. A user's conviction on a proposal starts at zero and grows as their tokens remain staked in support, but it also continuously decays when they are not actively voting. This decay prevents the system from being locked into past decisions and ensures liquidity for new proposals. The function is typically implemented as an exponential decay model, where conviction decreases by a fixed percentage at regular intervals.

The core formula calculates current conviction c_t based on previous conviction c_{t-1}, a decay rate d, and any newly added stake s_t. A common implementation is: c_t = (c_{t-1} * d) + s_t. The decay rate d is a number between 0 and 1 (e.g., 0.9 for a 10% decay per period). This is applied at each discrete time step, or "block," in the system. The newly added stake s_t represents tokens a voter deposits for a proposal at that moment. If no new stake is added, the conviction simply decays: c_t = c_{t-1} * d.

Here is a practical Solidity-esque example of a state update function. This would be called periodically (e.g., per block or epoch) to update a user's conviction for a specific proposal.

solidityCopy
function updateConviction(
    uint256 previousConviction,
    uint256 addedStake,
    uint256 decayFactor // e.g., 9e17 for 0.9 (90% retained)
) internal pure returns (uint256 newConviction) {
    // Apply decay to previous conviction, then add new stake
    newConviction = (previousConviction * decayFactor) / 1e18 + addedStake;
}

Note the use of fixed-point arithmetic (1e18 as a scaling factor) to handle fractional decay rates precisely on-chain.

Setting the decay rate is a critical governance parameter. A high decay (e.g., d = 0.5, 50% retained) makes conviction volatile, favoring rapid reallocation but potentially discouraging long-term commitments. A low decay (e.g., d = 0.99, 99% retained) allows conviction to build steadily, favoring persistent projects but slowing the system's response to change. Most implementations, like those in Commons Stack's Conviction Voting module, use a half-life analogy. For instance, a decay factor of 0.999 per block might result in a half-life of ~693 blocks, meaning conviction halves if no new stake is added in that period.

To integrate this into a full system, you must track conviction per voter per proposal and trigger the decay update on a regular schedule. This is often done by storing a last updated timestamp with each conviction balance. When a user interacts with a proposal (staking, withdrawing, or when checking total conviction), you first calculate the elapsed periods, apply the decay repeatedly or via a compounded formula, update the stored conviction and timestamp, and then process the new action. This ensures conviction is always current relative to the chain's clock.

The final output is a dynamic score for each funding proposal—the sum of all voters' decayed convictions. Proposals can be funded once this aggregated conviction surpasses a threshold relative to the available budget. This creates a continuous approval process where support must be actively maintained, automatically reallocating funds from completed or less-popular proposals. For a complete reference, review the 1Hive's conviction voting implementation on GitHub or the CadCAD simulation models used to test system parameters before deployment.

Conviction voting is a novel governance mechanism for continuous, non-binary funding decisions. Unlike one-time snapshot votes, it allows community members to stake their governance tokens on proposals they support. The "conviction" for a proposal grows over time as tokens remain staked, simulating a signal of sustained demand. This system is designed to fund public goods and operational budgets in a way that is resistant to flash loan attacks and better reflects long-term community sentiment. It was pioneered by projects like Commons Stack and is often integrated with platforms such as Aragon.

The core mechanism calculates a proposal's funding probability based on the decayed, time-weighted sum of tokens staked in its favor. When a user stakes tokens, their voting power starts low and increases asymptotically towards its full value over a predefined half-life period (e.g., 7 days). If they unstake, that power decays away. This creates a cost of exit (opportunity cost) for voters, aligning incentives with genuine support. The system continuously checks if any proposal's conviction surpasses a dynamic threshold, which is a function of the requested amount and the treasury's total funds, triggering automatic execution when met.

To implement a basic version, you'll need a smart contract system with several key components. First, a Treasury contract holds the communal funds (e.g., in ETH or a stablecoin). Second, a ConvictionVoting contract manages the staking logic, conviction calculation, and proposal state. Each proposal has parameters for requested amount, beneficiary, and a metadata link. The conviction for a proposal p at time t is often calculated as: conviction(t) = ∑ (staked_tokens * (1 - e^(-λ * (t - stake_time)))), where λ is derived from the decay half-life.

A critical function is the threshold calculation, which determines the conviction required for a proposal to pass. A common model sets the threshold proportional to the requested amount squared, divided by the treasury's total assets: threshold = (requestedAmount² * α) / totalTreasury, where α is a sensitivity parameter. This non-linear relationship makes funding large requests significantly harder than small ones, protecting the treasury. The contract must periodically (e.g., every block) evaluate all active proposals against this threshold.

From a development perspective, integrating with an existing framework accelerates implementation. The Aragon OSx platform provides modular governance plugins, including a conviction voting module. Similarly, you can build atop 1Hive's open-source conviction voting contracts. A basic integration flow involves: 1) Deploying the treasury and voting contracts, 2) Configuring parameters (half-life, α, minimum stake), 3) Connecting a front-end dApp where users can submit proposals and stake/unstake tokens, and 4) Setting up a keeper or bot to monitor and execute passed proposals.

When deploying, key security and design considerations include: - Parameter tuning: Setting appropriate half-life and α to balance responsiveness and stability. - Front-running protection: Using commit-reveal schemes for proposal submission if necessary. - Funds escrow: Ensuring the treasury securely releases funds only upon successful threshold crossing. - Griefing attacks: Mitigating scenarios where an attacker proposes and stakes on a malicious proposal to lock others' funds. Conviction voting is a powerful tool for continuous, community-led resource allocation, moving beyond simple yes/no votes to a more fluid and expressive funding model.

You now have a functional prototype of a conviction voting system. The core logic—where a user's voting power grows over time based on the square root of their staked tokens and the duration of their support—is implemented in the calculateConviction function. This model, inspired by projects like Commons Stack and 1Hive, helps prevent flash attacks and encourages long-term, thoughtful participation. The next phase is to move from a standalone script to an on-chain, gas-efficient smart contract.

To deploy this in production, you must address several key considerations. First, integrate with a secure token standard like ERC-20 for the staking asset. Second, implement a time-lock or vesting mechanism for released funds to ensure accountability. Third, add a proposal factory contract that enforces a minimum threshold for support and a formal submission process. Critical security practices include thorough testing with tools like Hardhat or Foundry, and considering an audit from a firm like Trail of Bits or OpenZeppelin before mainnet deployment.

For further learning and advanced patterns, explore existing implementations. Study the Conviction Voting app in the Aragon OSx ecosystem, which provides a modular framework. Review 1Hive's Gardens platform, which uses conviction voting for its funding mechanism. The CadCAD library can be used for complex simulations to model economic outcomes and tune parameters like the decay rate. Essential resources include the Commons Stack Primer and the 1Hive Documentation.

The final step is community onboarding and continuous iteration. Use a testnet deployment with a faucet to allow users to experiment risk-free. Gather feedback on the proposal submission UI and the clarity of the voting interface. Governance is as much about social systems as smart contracts; establish clear guidelines for proposal types and funding ranges. Monitor key metrics like proposal passage rate, average conviction time, and fund utilization to iteratively improve the system's parameters and rules.