DAO Governance Tools: Snapshot, Tally, and Governor

Snapshot, Tally, and Governor often appear together in DAO proposals, but they operate at different layers. Classic Snapshot is an off-chain voting platform built around wallet signatures. Tally has long served as an application interface for viewing, delegating, and operating on-chain governance, while its official product is transitioning toward Cactus On-chain Operations. Governor refers to governance contracts deployed on a blockchain that actually define proposal, voting, quorum, and execution rules.

Calling all three “voting tools” hides the most important distinction: one gathers opinions, one helps users interact with contracts, and one is itself the code that holds execution authority. A successful Snapshot vote does not necessarily change a protocol automatically. Tally/Cactus displays results from the underlying Governor, and a Governor can keep running through another interface or direct contract calls even if one front end disappears.

When choosing tools, do not compare only cost or interface design. Confirm where voting power comes from, whether results are binding, who can execute them, whether a Timelock exists, and whether governance can be reconstructed from on-chain data if the front end fails. For the complete governance structure, start with the Complete Guide to DAOs.

What Problems Do DAO Governance Tools Solve?

DAO governance includes at least six stages: discussing an issue, forming a proposal, determining voter eligibility, recording choices, deciding whether the proposal passes, and executing treasury or contract operations. A single product rarely handles every stage.

Forums, meetings, and research reports build consensus. Snapshot gathers opinions at low cost. Tally/Cactus helps members read and operate a Governor. Governor and Timelock provide on-chain rules and execution. Safe multisigs are also commonly used for early treasuries, operating expenses, and emergency permissions.

The way these tools connect determines whether governance is credible. If a community votes on Snapshot but an unrestricted multisig decides whether to execute, final power still belongs to its signers. If a Governor can execute automatically but its parameters or permissions are wrong, moving on-chain can make the error permanent.

What Is Snapshot?

Classic Snapshot is an off-chain voting platform. After connecting a wallet, a user signs a message for a proposal instead of sending a normal on-chain transaction, so voting usually requires no Gas. The signature verifies the voter address and message, and the platform calculates voting power and results according to the Space's configured strategies.

A DAO can create its own Space and configure its name, administrators, authors, network, proposal rules, and voting strategies. Proposals may cover product direction, ecosystem grants, member selection, parameter preferences, or temperature checks before formal governance.

“Off-chain” does not mean unverifiable or worthless. The key questions are whether the DAO constitution recognizes Snapshot results and how those results reach a multisig or on-chain contract.

How Does Snapshot Calculate Voting Power?

3.1 Snapshot Block

When a proposal is created, the system records a particular block or state snapshot and calculates voting power from the assets and delegations at that time. Tokens purchased only after voting starts usually cannot be used for that proposal, preventing the same assets from being moved between wallets and counted repeatedly.

3.2 Voting Strategy

A Voting Strategy determines how many votes each address has. Common strategies include ERC-20 balances, ERC-20 Votes delegation, ERC-721 or ERC-1155 holdings, allowlists, minimum balances, contract calls, and external APIs. Multiple strategies can also be combined.

The more complex a strategy becomes, the more important it is to verify its data source, network, block height, and external dependencies. RPC, indexer, or API failures may show a user as having zero voting power. If a small group of administrators maintains an allowlist, governance also depends on those list controllers.

3.3 Voting Type

A Voting Type determines how ballots are expressed and aggregated. Snapshot supports single choice, weighted, approval, quadratic, ranked-choice, and For/Against/Abstain voting. It differs from a Voting Strategy: the former calculates the result, while the latter calculates each person's weight.

For example, a DAO can use token balances as voting power while allowing members to distribute that power across five budget items. It can also give every verified wallet one vote and use ranked choice to select an option.

What Are the Advantages of Snapshot?

First, participation is inexpensive. Ordinary members do not have to pay an on-chain fee for every ballot, which suits frequent community surveys and low-risk decisions.

Second, strategies are flexible. A DAO can calculate weight from tokens, NFTs, delegation, allowlists, or custom data and set different rules for different subspaces.

Third, it supports richer expression. Weighted, ranked, and multiple-choice voting fit budget allocation and candidate selection better than forcing every question into simple support or opposition.

Fourth, results are auditable. Wallet signatures, choices, and voting power can be verified, and the community can export results for analysis.

Fifth, it supports progressive governance. A new DAO can use Snapshot to observe participation and disputes before deciding which permissions should move to automatically executed contracts.

What Are Snapshot's Limitations?

The greatest limitation of classic Snapshot is that a signed result normally does not directly call a protocol or transfer treasury assets. A multisig may respect the result, but it may also delay, reject, or execute it incorrectly. A DAO must state whether a vote is advisory, a temperature check, or a binding formal decision.

An off-chain system also depends on front ends, messaging services, indexers, and strategy data sources. A verifiable signature does not guarantee that the interface will always be online, and complex API strategies may be affected by external services.

Low cost also lowers the proposal threshold, creating spam proposals, voter fatigue, and superficial participation. Projects should establish proposal validation, discussion periods, templates, and author permissions instead of allowing any wallet to launch high-risk decisions at any time.

Finally, phishing pages can imitate wallet-signing screens. A normal Snapshot voting signature does not directly transfer assets, but users must verify the domain, Space, and signature type rather than treating every “free signature” as safe.

How Is Snapshot X Different From Classic Snapshot?

Snapshot X is a fully on-chain voting protocol. According to its official documentation, modular smart contracts implement its Spaces, voting-power calculations, proposal results, and execution logic across EVM networks and Starknet. Its fundamental difference from classic Snapshot is that core governance no longer depends only on off-chain signatures and human execution.

Snapshot X lets proposals configure a Voting Strategy and an Execution Strategy. The voting strategy determines weight, while the execution strategy evaluates proposal status and performs predefined calls after passage. Simple quorum, optimistic governance, emergency quorum, Safe modules, and Timelocks can all become part of an execution design.

“Fully on-chain” does not mean the user experience contains no off-chain services. Relayers can lower interaction barriers, but they are not mandatory for the protocol to operate. On-chain governance also introduces deployment, Gas, contract-audit, and upgrade complexity, so it is not always suitable for a small community.

What Is Tally, and Why Is It Now Called Cactus?

Tally has long been an on-chain governance application centered on Governor. Its interface lets users browse proposals, view voting power, delegate, create proposals, vote, queue, and execute. It makes complex contract states readable but does not replace the underlying governance contracts.

Tally's official documentation now explicitly uses the Cactus brand and says that Cactus is built on the Governor standard. The platform indexes on-chain data and helps users call independently operating Governor contracts. Some documentation and industry material still use the Tally name, so this article retains the original title while treating it as a product and brand in transition.

The change does not automatically alter any DAO's governance contract. Even if the interface is renamed, proposal, delegation, voting, and execution permissions remain controlled by the Governor, Timelock, and token contracts on the relevant chain. Users should rely on the DAO's website, verified contract addresses, and current official documentation rather than search ads that may lead to imitation governance pages.

What Does Tally/Cactus Provide?

8.1 Proposal Discovery and Status

The application indexes Governor events and displays proposal content, voting periods, quorum, support, executable actions, and current status. Users do not have to parse block logs themselves, but they should still verify executable calls and target addresses.

8.2 Delegation and Delegate Profiles

Token holders can delegate voting power to themselves or a representative without moving assets out of their wallets. Delegate profiles help compare governance positions and historical behavior, although the completeness of disclosures and conflicts of interest still depends on community governance.

8.3 Creating and Submitting On-Chain Proposals

Addresses that satisfy a proposal threshold can use the interface to construct target contracts, transferred values, and calldata. The interface reduces technical difficulty, but it can also make incorrect addresses and malicious calls look like ordinary form entries, so every formal submission should be simulated and independently reviewed.

8.4 Voting, Queuing, and Execution

Users send transactions to Governor through the application. After voting, eligible proposals enter the Queue and execute once the Timelock expires. The interface is only a transaction entry point; success still depends on on-chain state, permissions, and Gas.

8.5 Data and Governance Operations

Indexing, APIs, notifications, delegation relationships, and historical analytics help DAOs operate governance. Current Cactus documentation also places governance settings, token launches, delegation, and incentives within a broader On-chain Operations system.

What Is Governor?

Governor is not a single website. It is a class of smart contracts that manages on-chain governance. Compound Governor Alpha and Bravo strongly influenced the industry, while OpenZeppelin provides a modular Governor framework that lets projects select voting power, counting, quorum, proposal thresholds, and execution delays.

A typical Governor accepts a proposal, fixes the voting-power snapshot, opens voting, evaluates quorum and majority conditions, and sends approved operations to a Timelock. After the delay, an address with execution permission can trigger the preapproved contract calls.

Community voting directly controls critical assets only when protocol upgrade authority, the treasury, and administrator roles are truly assigned to the Timelock. If the team retains a separate administrator, Governor may provide only partial governance or a symbolic interface.

What Are the Core OpenZeppelin Governor Modules?

10.1 Votes

GovernorVotes reads historical voting power from a token or credential that implements IVotes. Holders usually need to delegate to themselves or a representative before their balance enters the governance-power calculation. Assets remain in the original wallet; delegation only changes where voting power is assigned.

10.2 Counting

Counting modules determine how For, Against, and Abstain votes are counted. OpenZeppelin also offers extensions such as fractional and overrideable delegation so delegates and original holders can vote under different rules.

10.3 Quorum

Quorum is the minimum participation or support needed for a proposal to be valid. It can be calculated as a percentage of total token supply, while Super Quorum can allow a proposal with unusually high support to reach a successful state sooner.

10.4 Settings

Governance must configure a Voting Delay, Voting Period, and Proposal Threshold. The delay gives members time to delegate and review, the voting period defines the participation window, and the proposal threshold reduces spam and malicious proposals.

10.5 Timelock

A Timelock adds a waiting period between passage and execution. It should hold the governed funds and permissions, Governor queues the operation, and an executor can call only an approved operation after its waiting period ends.

10.6 Security Extensions

PreventLateQuorum stops large holders from reaching quorum at the last moment and ending a vote immediately. A Proposal Guardian can cancel proposals under deliberately designed permissions. Every guardian and cancellation power needs clear boundaries so a safety mechanism does not become a permanent control backdoor.

What Is the Governor Proposal Lifecycle?

The first step is Propose. A proposal contains target contracts, values to send, calldata, and a written description. The proposer usually needs to meet a voting-power threshold.

The second step is Voting Delay. The proposal is published but voting has not begun, giving members time to read, delegate, and identify malicious calls.

The third step is Active. The voting window opens, Governor reads voting power at the snapshot, and records For, Against, and Abstain votes.

The fourth step is Succeeded or Defeated. Only proposals that meet quorum and passage rules can continue.

The fifth step is Queue. Governance systems using a Timelock queue the proposal's operations and begin the execution delay.

The sixth step is Execute. Once the waiting period ends, contract calls run according to their original payload. If an address, parameter, or permission is wrong, the on-chain result will not automatically reverse itself because the “community intended” something else.

How Do Snapshot, Tally, and Governor Work Together?

The most common workflow is for a forum discussion to produce a draft, classic Snapshot to run a temperature check, and the proposer to generate Governor calls from the feedback. Tally/Cactus is then used to submit, vote, queue, and execute. This approach combines low-cost discussion with strongly binding execution.

Another approach is Snapshot plus Safe. The community votes through off-chain signatures, and multisig signers execute payments based on the result. It suits early DAOs and operating budgets, but its trust boundary remains the multisig.

SafeSnap connects Snapshot results to transaction execution through a Safe module and Reality.eth, reducing trust in purely manual execution. Snapshot X instead puts voting and its Execution Strategy directly on-chain.

Large protocols may let Governor manage core contracts while assigning low-risk grants to a multisig or committee. Social and service DAOs may need only Snapshot and Safe. For the needs of different organizations, read Types of DAOs: Protocol, Investment, Social, and Service DAOs.

How Should You Choose a Governance Tool?

Classic Snapshot is better when decisions are frequent, values are small, and the community needs several forms of voting expression. It validates community opinion quickly, but the executor and enforcement mechanism must be disclosed.

Organizations managing a core protocol, upgrade authority, or a large treasury should prioritize Governor, Timelock, and audited on-chain governance. Tally/Cactus can improve interaction but cannot substitute for contract security.

An early DAO with few members and rapidly changing rules can begin with a Safe multisig and Snapshot, then transfer permissions to Governor gradually. Giving up every administrator permission at once can make configuration errors difficult to repair.

If censorship resistance, on-chain calculation, and automatic execution are required within Snapshot's modular model, the DAO can evaluate Snapshot X. Its Voting Strategy, Execution Strategy, quorum, and permissions still need testing before deployment.

Tool selection should also consider members' networks, Gas, wallet compatibility, delegation habits, emergency response, and legal enforcement. The product with the most features is not necessarily the best fit.

What Matters When Configuring Governance Parameters?

A proposal threshold that is too low produces spam and phishing proposals, while one that is too high prevents ordinary members from raising issues. A phased process can use a low threshold for discussion and a higher one for on-chain execution.

Quorum should reflect circulating voting power, delegation rates, and historical participation rather than copy another DAO mechanically. If many tokens never participate, an excessive quorum can freeze governance, while an insufficient quorum makes minority control easier.

Voting periods should cover major time zones and give delegates enough review time. Core upgrades need a longer window than routine community surveys.

A Timelock must be long enough for users and security teams to respond but not so long that it blocks vulnerability remediation. High-risk and ordinary proposals can use different delays.

Proposal calls should be simulated, address-checked, and independently reviewed. Written descriptions execute nothing; the actual operations are the Targets, Values, and Calldatas.

What Security Risks Do Governance Tools Create?

The first risk is front-end phishing. Fake Snapshot, Tally, or DAO websites can solicit malicious signatures and approvals. Users must enter through official governance links.

The second is strategy misconfiguration. An incorrect Snapshot network, block, token address, or API strategy can remove voting power from some members.

The third is residual contract authority. Deploying a Governor does not prove that team administrators, multisigs, or proxy-upgrade rights have been transferred.

The fourth is a malicious proposal. An attacker can hide a treasury transfer, role grant, or malicious implementation upgrade behind a normal-looking description.

The fifth is delegation concentration. A few delegates may accumulate enough voting power to dominate governance even without holding the same amount of assets themselves.

The sixth is low participation. Even the safest tool cannot make members read, vote, or supervise execution. For the broader issue, continue with DAO Challenges: Governance Attacks, Voter Apathy, and Efficiency Bottlenecks.

Hotcoin's Six-Dimension VOTING Selection Method

The six-dimension VOTING method can help compare governance tools. It is not a security certification, but a checklist for deployment and participation.

16.1 V: Voting Power

Identify whether power comes from tokens, NFTs, delegation, allowlists, or identity credentials, and verify the snapshot time and data source.

16.2 O: Off-chain or On-chain

Separate off-chain signatures, on-chain counting, and on-chain execution. Do not mistake a verifiable signature for automatic execution.

16.3 T: Threshold

Review proposal thresholds, quorum, passage ratios, and Super Quorum against actual participation rather than copied parameters.

16.4 I: Interface

Confirm whether users can continue through another interface or direct contract calls if the front end fails, avoiding total dependence on one website.

16.5 N: Notice

Voting Delay, Voting Period, and Timelock should give the community enough time to find errors and malicious actions.

16.6 G: Governance Execution

Determine whether a multisig, Safe module, Snapshot X, Governor, or human team executes the result, and review cancellation and emergency powers.

How Can Ordinary Users Participate Safely?

First, enter governance through the project's website or official documentation and verify the domain, Space, chain, Governor, and token address.

Second, distinguish signatures from transactions. Classic Snapshot generally uses off-chain message signatures, while Governor voting, delegation, Queue, and Execute are usually on-chain transactions. Any token approval requires additional scrutiny.

Third, confirm the voting-power snapshot. Tokens bought or delegated only after a proposal is created may not count in the current vote.

Fourth, read the executable calls. Check target addresses, transferred amounts, role changes, upgrade implementations, and Timelocks instead of relying only on the title.

Fifth, use a separate governance wallet to isolate voting from primary assets, and revoke unused approvals regularly.

Sixth, review a delegate's history, voting rationale, compensation, and conflicts of interest. Delegation should never require transferring tokens to the delegate.

Frequently Asked Questions

18.1 Does Snapshot Voting Require Gas?

Classic Snapshot uses off-chain signatures, so voting normally requires no Gas. Snapshot X is an on-chain protocol whose deployment and operation may incur Gas, although sponsorship or a Relayer can improve the experience.

18.2 Does a Successful Snapshot Vote Execute Automatically?

Classic Snapshot normally does not execute automatically unless the DAO integrates an execution module such as SafeSnap. Snapshot X can automatically execute a successful proposal through its Execution Strategy.

18.3 Are Tally and Governor the Same Thing?

No. Tally/Cactus is an application and indexing layer, while Governor is an on-chain governance contract. The front end helps users interact, but the contract determines authority and results.

18.4 Why Did Tally Become Cactus?

Current official documentation shows Tally transitioning to Cactus On-chain Operations. Historical proposals and industry material still often use the Tally name, so users should rely on the current website and the DAO's official entry point.

18.5 Why Does My Governance Token Show Zero Voting Power?

Common reasons include not holding the token before the proposal snapshot, not delegating to yourself or a representative, connecting to the wrong network, or using an asset that the Space's Voting Strategy does not count.

18.6 Must Governor Use a Timelock?

Not technically, but high-risk protocols should normally add an execution delay. Without a Timelock, a proposal may execute immediately after passage, leaving no response window for the community.

18.7 Does Deploying Governor Make a Protocol Fully Decentralized?

Not necessarily. You must also check whether proxy administrators, treasury authority, Timelock, cancellation powers, security committees, front ends, and other contract permissions are truly controlled by governance.

Conclusion: A Voting Interface Is Not Governance Authority

Snapshot, Tally, and Governor solve different problems. Classic Snapshot lets communities express opinions inexpensively. Snapshot X moves modular voting and execution on-chain. Tally/Cactus makes Governor easier to read and operate. Governor encodes proposal, counting, quorum, and execution rules in smart contracts.

The most practical design is usually not a choice of one tool, but a layered combination: forums support research and discussion, Snapshot builds early consensus, Governor and Timelock execute high-value on-chain decisions, Tally/Cactus provides interaction, and Safe manages early or limited operational authority.

A tool's name cannot guarantee governance security. Parameters, permissions, contract code, delegate concentration, and member participation all shape the final outcome. Define what the organization will govern first, decide who can vote and how results become binding, and only then select front ends and contracts.

After this article, return to the Complete Guide to DAOs to build the broader framework. When you are ready to establish a governance system, continue with How to Create Your Own DAO: From Zero to Launch.

To manage multichain assets and connect to governance applications, use Hotcoin Web3 Wallet. For mobile market and trading tools, visit Hotcoin App. Browse more educational content on Hotcoin.

Risk warning: This article is for education and information only and does not constitute investment, legal, or tax advice. Snapshot, Snapshot X, Tally/Cactus, Governor, Safe, and related contract functions may change. Before participating or deploying, verify the latest official documentation, network, contract addresses, governance parameters, wallet signatures, and actual execution authority.