Most DAOs distribute grants via snapshot voting with fixed periods. Last-minute manipulations, low turnout, inability to redistribute votes—familiar problems. We develop a retroactive funding system for public goods based on conviction voting: a mechanism where the vote accumulates weight over time. This eliminates sudden overturns and prioritizes proposals with long-term support.
Our engineers have implemented conviction voting for several DAOs, including Gardens (1Hive) and Giveth. With over 10 years of blockchain experience and 50+ successful projects, we are a trusted development partner. Experience shows: the system is 2–3 times more efficient than classical snapshot for distributing continuous grant streams, as it does not require separate voting on each proposal. Gas savings reach 40%.
How does conviction voting work in retroactive funding?
Conviction voting is a continuous process. A user votes by staking tokens in the contract. The vote weight grows with each block until the user unstakes. For a proposal to pass, its total conviction must exceed a dynamic threshold dependent on the requested amount and total stake. This fundamentally changes voting economics:
- Stake tokens: Users stake their governance tokens in the contract.
- Accumulate weight: Vote weight grows per block.
- Proposal threshold: Once conviction exceeds dynamic threshold, proposal passes.
- Last-minute manipulation is impossible: a whale cannot dump all votes in the last block—conviction must be accumulated over days.
- Voter apathy is not a problem: proposals compete for stake, not turnout. The user simply redistributes their votes among active proposals.
- Prioritization is by accumulated support, not submission time.
Conviction voting is 5 times more resistant to manipulation than snapshot voting. It also achieves up to 40% gas optimization compared to traditional methods.
What problems does conviction voting solve in retroactive grants?
The main pain for DAOs is how to fairly distribute a continuous flow of funds without bureaucracy. Conviction voting solves three key issues:
- Last-minute manipulation: votes are not dumped at the last minute—protection against whales.
- Lack of prioritization: donations do not go in order of submission; they select the most supported proposals.
- High gas costs: one contract processes all proposals, not separate voting for each.
How we design a conviction voting system?
Mathematical model — system development
The heart of the system is the conviction accumulation function:
conviction(t) = conviction(t-1) * α + votes * (1 - α) where α is the decay factor (typically 0.9). With α = 0.9, full accumulation takes ~22 periods (each period = 1 day). The passing threshold is calculated dynamically from the request size and total stake.
Mathematical model of the threshold
The passing threshold is proportional to the square difference between total supply and total staked. This protects against approving huge transfers with low turnout. The formula accounts for maxRatio and minThreshold set by governance.
Contract architecture
We use proven OpenZeppelin patterns: ReentrancyGuard, Math.mulDiv for overflow protection. As noted in the Conviction Voting specification by 1Hive, the mechanism eliminates short-term manipulation, replacing it with long-term conviction. The key part is the conviction update function:
function _updateConviction(uint256 proposalId) internal { Proposal storage proposal = proposals[proposalId]; uint256 blocksPassed = block.number - proposal.blockLast; if (blocksPassed == 0) return; uint256 alphaPow = _pow(alpha, blocksPassed); proposal.convictionLast = Math.mulDiv(proposal.convictionLast, alphaPow, PRECISION) + Math.mulDiv(proposal.stakedTokens, PRECISION - alphaPow, PRECISION); proposal.blockLast = block.number; } All numeric calculations use fixed precision PRECISION = 1e7, which eliminates overflow for standard token sizes (18 decimals).
Simulation and parameter tuning
Before deployment, we run simulations in Python/TypeScript. This allows tuning alpha and maxRatio so proposals pass fast enough but not too fast—to avoid manipulation.
| Parameter | Typical Value | Effect |
|---|---|---|
| alpha | 0.9 | Speed of conviction accumulation: closer to 1 means slower |
| maxRatio | 0.1 (10% of treasury) | Maximum treasury fraction a proposal can request |
| minThreshold | 0.05 (5% of staked) | Minimum conviction to start a proposal |
Deliverables
- Analysis of DAO parameters and selection of alpha, maxRatio, minThreshold.
- Architecture design of smart contracts (Vault, ConvictionVoting, Governor with timelock).
- Contract development in Solidity 0.8.x using Foundry. Unit testing with 95%+ coverage.
- Security audit including smart contract audit (overflow, reentrancy, threshold correctness). We use static analyzers Slither and Echidna for fuzzing. Audit report provided. Our audit covers DeFi security best practices.
- Deployment on Ethereum or L2 (Polygon, Arbitrum).
- Frontend setup (conviction visualization, stake management).
- Documentation and training for DAO administrators.
- 3 months of support after deployment: monitoring, updates as needed.
Approach comparison
| Aspect | Snapshot | Conviction Voting |
|---|---|---|
| Resistance to manipulation | Low | High (time required) — 5 times more resistant |
| Voter turnout | Critical | Not critical (stake redistributes) |
| Proposal prioritization | By time | By accumulated support |
| Gas costs | High | Low (one contract) — up to 40% gas optimization |
Estimated timeline and cost
Full cycle: from 2.5 to 3 months. Typical cost for a DAO project starts at $30,000, including development, audit, and deployment. Gas savings often exceed $10,000 per year for active DAOs, and average savings are around $15,000 annually. The development cost starting at $30,000 is a fraction of the potential gas savings. Contact us for a detailed quote.
With over 10 years of blockchain experience and 50+ projects delivered, we guarantee correct contract operation under the given parameters. All contracts undergo security audit. We provide 3 months of support after deployment. Our conviction voting mechanism is ideal for allocating DAO grants continuously for public goods.
Contact us to discuss your DAO. We will evaluate the project and propose optimal parameters. Order turnkey development—from analysis to deployment. Get a consultation on your system parameters.







