Governance and treasury systems.
On chain voting, delegation, timelocks, and transparent reserves. We build governance infrastructure that communities can actually use without it becoming either paralyzed by complexity or exploitable through careless design.
What we build.
Governance gets treated like a philosophy problem and shipped like a weekend hackathon project. That mismatch is where most protocols lose their communities. We build the technical infrastructure that makes governance actually work.
On Chain Voting Contracts
The core proposal and voting infrastructure that lets a community make binding decisions on chain. This covers the full lifecycle from proposal creation through voting periods to execution, with configurable parameters that match how the community actually operates rather than how a template assumes it should.
- Proposal creation with configurable submission thresholds
- Voting periods with adjustable duration and quorum requirements
- Execution logic that triggers on chain actions after successful votes
- Proposal state management from draft through active to queued and executed
Delegation Systems
Most token holders do not vote on every proposal. Delegation systems let them assign voting power to representatives who will, without giving up token custody. This requires tracking delegation graphs, handling partial delegation, maintaining delegate registries, and recalculating voting power as tokens move between wallets.
- Token weighted delegation with full and partial delegation support
- Liquid democracy patterns where delegates can re delegate
- Delegate registries with on chain profiles and voting history
- Voting power snapshots that prevent double counting during active proposals
Treasury Management Contracts
A treasury that lives in a single wallet with no structure is a governance story waiting to collapse. We design treasuries as structured balance sheets with separated buckets for operating funds, long term reserves, and grant programs. Each bucket has its own execution path, its own spending rules, and its own transparency requirements.
- Spending proposals with tiered approval thresholds based on amount
- Budget allocation across operating, reserve, and grant categories
- Grant distribution with milestone based disbursement and clawback
- Reserve management with transparent on chain accounting anyone can verify
Timelock and Safety Mechanisms
Every governance system eventually faces the question of what happens when something goes wrong and the normal vote cycle is too slow. The wrong answer is a quiet admin key nobody mentions. The right answer is a clearly labelled emergency role with narrow powers, a short expiry, and a public log of every time it is used.
- Execution delays that give the community time to review passed proposals
- Veto powers with scoped authority and transparent usage logs
- Guardian roles with narrow permissions and automatic expiry
- Emergency pause functionality for critical contract vulnerabilities
Multi Signature Operations
Multi sig wallets are the operational layer of most DAOs. They handle day to day spending, contract deployments, and parameter changes that do not justify a full governance vote. This requires careful design of signer sets, threshold configurations, and role based access so that operational speed does not come at the cost of security.
- Safe and Gnosis style multi sig deployment and configuration
- Threshold signing with configurable signer requirements per action type
- Operational spending limits with automatic enforcement
- Role based access control separating treasury, protocol, and emergency actions
Community Incentive Infrastructure
Governance participation does not happen by default. Most communities need incentive structures that reward active participation without creating perverse dynamics where people vote carelessly just to collect rewards. This requires careful mechanism design that aligns participation incentives with governance quality.
- Staking for governance weight with lockup tiers and voting power boosts
- Participation rewards distributed proportionally to active voters
- Reputation systems that track contribution history on chain
- Contributor compensation through streaming payments and milestone grants
Problems we solve.
These scenarios reflect the types of governance engagements we take on. The politics vary, but the engineering challenge is consistent. Build systems that survive the transition from comfortable consensus to genuine disagreement.
A DeFi protocol launching community governance
A DeFi protocol is transitioning from a core team making all decisions to community driven governance. This requires a Governor contract with carefully tuned quorum thresholds, a delegation system that makes voting accessible to passive token holders, and a timelock that gives the community a window to review passed proposals before execution. The quorum needs to be high enough that decisions carry legitimacy but low enough that proposals can actually pass.
A DAO managing a shared treasury transparently
A DAO holds significant assets across multiple tokens and needs transparent on chain accounting that any member can verify independently. This requires structured treasury contracts with separated buckets for operations, reserves, and grants. Spending proposals route through tiered approval workflows where small operational expenses need fewer approvals than large strategic allocations. Every outflow is logged on chain with purpose tags.
Progressive decentralization from admin keys
A protocol currently controlled by a single admin key needs to transition to community governance without breaking anything along the way. This requires a phased approach. First, the admin key migrates to a multi sig. Then governance contracts are deployed alongside the multi sig with increasing authority over time. Finally, the multi sig role narrows to emergency actions only while the governance system handles routine decisions.
An investment DAO pooling capital with on chain voting
An investment DAO pools capital from members and needs on chain voting to approve allocation decisions. This requires deposit and withdrawal contracts, proposal workflows for investment opportunities, voting weighted by contribution size, and execution logic that moves funds into approved positions. Rage quit mechanisms let dissenting members exit before a contentious allocation executes.
A gaming guild managing shared assets and revenue
A gaming guild holds shared NFT assets and earns revenue across multiple games. Members need governance over which assets to acquire, how to deploy them, and how revenue gets distributed. This requires asset custody contracts, proposal workflows for acquisition and deployment decisions, and automated revenue distribution proportional to each member's contribution and participation level.
How on chain voting actually works.
Voting sounds simple until you start designing it. Quorum too high and nothing passes. Quorum too low and decisions lack legitimacy. Voting periods too short and people miss them. Too long and the protocol cannot react to anything urgent.
Proposal Lifecycle
A proposal moves through distinct states. It starts as a draft, optionally passes through an off chain discussion phase, then enters the on chain submission stage where it requires a minimum token threshold to create. Once submitted, a delay period allows the community to review before voting opens. The voting period runs for a configured duration, after which the proposal either passes quorum and enters a timelock queue, or fails and is archived.
The execution phase is where the proposal's payload actually runs. This might be a contract call, a parameter change, a treasury transfer, or a batch of actions. The timelock between passing and execution is the community's last chance to react if something looks wrong.
Quorum Design and Calibration
Quorum is the minimum participation threshold required for a vote to be valid. Setting it correctly requires understanding the token's distribution. If a large percentage of supply sits in dormant wallets, exchange custody, or locked vesting contracts, the effective circulating supply for voting purposes is much smaller than the total supply. Quorum thresholds need to account for this.
We design quorum as a percentage of votable supply rather than total supply. We also implement adaptive quorum mechanisms where the threshold can adjust based on historical participation rates, preventing governance from stalling as participation patterns change over time.
Voting Period Calibration
Voting periods need to be long enough for token holders across time zones to participate, but short enough that the protocol can respond to urgent matters. Most governance systems use a standard period for routine proposals and an expedited path for emergency actions, with the expedited path requiring a higher quorum or supermajority to compensate for the shorter window.
We also design proposal delay periods, the gap between submission and voting start, which give delegates time to review proposals and form positions before votes open. Without this buffer, early voters disproportionately influence outcomes.
Snapshot Voting vs On Chain Voting
Snapshot voting happens off chain using signed messages, which means zero gas cost for voters. The tradeoff is that execution is not automatic. Someone still needs to manually execute the result on chain, which introduces a trust assumption. Snapshot works well for signaling votes and temperature checks where the result informs a multi sig action rather than triggering automatic execution.
On chain voting is more expensive but fully trustless. The proposal, the votes, and the execution all live on chain with no intermediary. For binding decisions that control treasury funds or protocol parameters, on chain voting provides stronger guarantees. Many protocols use both, with Snapshot for early stage discussion and on chain Governor contracts for final binding votes.
Gasless Voting and Meta Transactions
Gas costs create a real barrier to governance participation, especially on Ethereum mainnet. A voter who holds a modest amount of governance tokens may find that the gas cost of casting a vote exceeds the value of their stake. This creates plutocratic dynamics where only large holders participate regularly.
We implement gasless voting through EIP 712 signed messages and meta transaction relayers. Voters sign their vote off chain and a relayer submits it on chain, covering the gas cost. This can be funded by the DAO treasury or subsidized through protocol revenue, removing the financial barrier to participation without compromising the on chain verifiability of the vote.
Vote Delegation and Liquid Democracy
Delegation lets token holders assign their voting power to a representative without transferring token custody. Simple delegation assigns all voting power to a single delegate. Partial delegation splits voting power across multiple delegates. Liquid democracy allows delegates to further re delegate to specialists on specific proposal categories.
The engineering challenge is tracking delegation graphs efficiently. When tokens move between wallets, delegation relationships need to update. When a proposal creates a voting power snapshot, the delegation state at that block needs to be captured accurately. We implement checkpointed delegation that records state changes at specific blocks, enabling gas efficient lookups of historical voting power.
Transparent treasuries and legible spend.
A treasury is not a wallet. It is a structured system for holding, allocating, and distributing community assets with full accountability at every step.
On Chain Treasury Accounting
Token holders and committee members need a view that answers three questions at all times. What do we hold. Where is it sitting. What is scheduled to leave. We build treasury dashboards on top of the same on chain data a stranger would use, because anything else eventually drifts away from reality.
Every inflow and outflow is tagged with a purpose and linked to the governance proposal or operational approval that authorized it. This creates a complete audit trail that does not depend on anyone maintaining a spreadsheet.
Spending Proposal Workflows
Not all spending decisions deserve the same process. Small operational expenses like paying for infrastructure or reimbursing contributors should not require a full governance vote with a week long voting period. Large strategic allocations absolutely should.
- Tiered approval thresholds matched to spending amounts
- Committee based approvals for recurring operational budgets
- Full governance votes for large or strategic allocations
- Streaming payments for contributor compensation and grants
Budget Period Management
DAOs that operate without budget periods tend to spend reactively, approving one off proposals without a coherent strategy. We design budget period contracts that establish spending envelopes for defined time windows. Teams and committees receive allocated budgets at the start of each period and operate within those limits without needing per transaction approval.
Unspent allocations can roll over, return to the general treasury, or follow whatever policy the community defines. The point is that the policy is encoded in the contract, not in someone's memory.
Diversification Strategy
A treasury that holds its entire value in the protocol's native token is one market downturn away from insolvency. When the token price drops, the treasury's purchasing power drops at the exact moment the protocol needs resources most. We design treasury diversification workflows that convert a portion of native token holdings into stablecoins and other uncorrelated assets.
This requires governance approved diversification proposals, execution through on chain swaps or OTC mechanisms, and transparent reporting on the resulting asset mix. The goal is a treasury that can fund operations through a bear market without emergency token sales at the worst possible prices.
Grant Program Administration
Grant programs are how most DAOs fund ecosystem development. The engineering challenge is building systems that distribute funds based on milestone completion rather than upfront trust.
- Milestone based disbursement with on chain verification
- Grant committee multi sig with delegated authority from governance
- Clawback mechanisms for grants that fail to deliver
- Public reporting dashboards showing grant status and outcomes
Revenue Distribution
Protocols that generate revenue need a mechanism to distribute it back to token holders or reinvest it into the treasury. This requires on chain accounting of revenue sources, governance decisions about allocation between distribution and reinvestment, and distribution contracts that handle claims efficiently without requiring every holder to submit a transaction for every distribution event.
We implement accumulator based distribution patterns that let holders claim accrued revenue at any time, avoiding the gas inefficiency of push based distributions while maintaining accurate per holder accounting.
Governance systems that are honest about their failure modes.
The goal is a system that does not pretend to be more decentralized than it actually is, and that has clearly labelled safety paths for the situations where normal governance is too slow.
Timelock Contracts
A timelock creates a mandatory delay between when a proposal passes and when it executes. This delay is the community's window to review what is about to happen and react if something looks wrong. Without a timelock, a malicious proposal that passes a vote can execute immediately, before anyone has a chance to exit positions or raise an alarm.
We design timelocks with configurable delays based on action severity. Routine parameter changes might have a shorter delay. Treasury transfers and contract upgrades get longer delays. Critical protocol changes get the longest delay and may require additional confirmation steps.
Guardian and Veto Roles
A guardian is a designated role, usually a multi sig, with the narrow power to cancel proposals during the timelock period. This is the safety valve for governance attacks where a malicious proposal passes through voter apathy or a temporary concentration of voting power.
- Veto authority scoped to cancellation only, not proposal creation
- Public logs of every veto action for community accountability
- Sunset clauses that automatically revoke guardian powers over time
- Community override mechanisms that can overrule a veto with supermajority
Emergency Pause Mechanisms
When a critical vulnerability is discovered in a protocol's contracts, the normal governance cycle is too slow. An emergency pause lets a designated role freeze specific contract functionality while the community decides on a fix. The key is scoping the pause narrowly. A pause role that can freeze everything is effectively an admin key. A well designed pause role can only freeze specific functions and must be renewed or revoked through governance within a defined time window.
We design pause mechanisms with automatic expiry. If the governance process does not renew or resolve the pause within the window, it lifts automatically. This prevents a compromised pause role from permanently disabling a protocol.
Flash Loan Governance Attacks
Flash loans allow an attacker to borrow a massive amount of governance tokens for a single transaction, vote with them, and return them before the transaction completes. Without protection, this lets anyone with access to a lending pool pass any governance proposal regardless of their actual economic stake in the protocol.
- Voting power snapshots taken at proposal creation, not vote time
- Vote escrow mechanisms that require tokens to be locked during voting
- Proposal submission thresholds that require sustained token holding
- Time weighted voting power that discounts recently acquired tokens
Proposal Spam Prevention
Without guardrails, governance systems can be flooded with low quality or malicious proposals that exhaust voter attention. A submission threshold requiring a minimum token holding to create proposals is the first line of defense. Beyond that, proposal deposits that are returned on successful votes and forfeited on failed votes create an economic cost to frivolous submissions.
We also implement rate limiting at the contract level so that no single address can create more than a configurable number of active proposals simultaneously. This prevents attention attacks where a bad actor floods the system to slip a malicious proposal through while voters are overwhelmed.
Vote Buying Detection
Vote buying is the governance equivalent of a 51% attack. Dark DAOs, bribery markets, and financial incentives to vote a specific way undermine the integrity of any governance system. While on chain vote buying is difficult to prevent entirely, we design systems that make it more expensive and more visible.
- Private voting with commit reveal schemes that hide votes until the reveal phase
- Shielded voting using zero knowledge proofs to prevent vote verification by third parties
- Monitoring infrastructure that flags unusual voting patterns and large last minute delegations
- Time locked voting power that makes it expensive to acquire tokens just to influence a specific vote
Tools we use daily.
We choose governance tooling based on the community's needs, not convention. These are the frameworks, contracts, and platforms we work with across governance and treasury engagements.
Governor Contracts
OpenZeppelin Governor is the standard framework for EVM governance. It provides modular components for voting, quorum, timelock integration, and proposal execution. For protocols that need compatibility with existing tooling, Compound Governor Bravo remains widely supported. We extend both frameworks with custom modules for partial delegation, adaptive quorum, and gasless voting.
Multi Sig and Safe Infrastructure
Safe (formerly Gnosis Safe) is the industry standard for multi sig operations. We deploy and configure Safe instances for treasury management, emergency actions, and operational spending. We integrate Safe with governance contracts so that certain actions require both a governance vote and multi sig execution, providing defense in depth.
Off Chain Voting and Signaling
Snapshot provides gasless off chain voting using signed messages. It is ideal for temperature checks, signaling votes, and early stage proposal filtering before a proposal moves to binding on chain governance. We integrate Snapshot with on chain execution through SafeSnap and other bridge modules that connect off chain votes to on chain actions.
Timelock and Access Control
Timelock contracts provide the execution delay between proposal approval and action. OpenZeppelin TimelockController is the standard implementation, supporting role based access for proposers, executors, and cancellers. We extend it with variable delays based on action type, batch execution support, and integration with monitoring systems that alert the community during the delay window.
Adjacent work we do.
Tokens & tokenization
The instrument your governance actually votes with, designed backwards from your incentive goals.
Operational automation
The keepers and agents that execute routine treasury operations without waking anyone up.
Smart contract systems
The executor, the timelock, the access control. The code your governance ultimately runs on.
Tell us how your community makes decisions today.
A short description of your governance needs, your token distribution, and the decisions your community needs to make is enough for us to say whether we can help.