Did you know? A DAO can hold a vote, announce that a proposal passed and still make no change to the blockchain. The vote result and the action it recommends are not necessarily the same event. Some governance systems run off-chain polls that signal community preference; others use smart contracts that authorise executable calls—but even there, queuing, timelocks and separate execution steps may be required.
Imagine a fictional school science club with 100 voting credits. Members vote to spend 40 credits on a new telescope. The results page says “Passed.” Alicia celebrates, Kai Kai orders the telescope and Tricia checks the club treasury. Nothing has been spent. Why? Because the club’s governing rules say a passed vote must still be checked, approved for execution and acted on by the person or contract that controls the funds.
Blockchain governance involves the same separation. The technology can record voting power, tally choices and restrict who may call certain functions. It does not automatically turn every poll, discussion or proposal headline into a transfer of assets.
Quick answer: A DAO vote establishes a result under a particular voting process. Execution occurs only if the DAO’s authorised mechanism subsequently performs the proposal’s actions under the relevant rules. An off-chain vote can be non-binding or require a later transaction. On-chain Governor-style processes may require a successful proposal, an optional queue, a timelock and a valid execute call. A passed proposal can therefore remain unexecuted, be delayed or fail for reasons outside the original tally.
This guide shows how blockchain technology works when communities try to govern shared resources. It uses paper examples and official documentation rather than assuming every DAO uses one model. For the foundation, see What Is Blockchain? and the more technical DAO Voting: Check the Snapshot, Denominator and Execution.
Choose Your Reading Route
- What does a DAO actually mean?
- A proposal, a vote and an action are three different objects
- Off-chain voting can express a preference without moving tokens
- On-chain governance can encode the action and the conditions
- Quorum asks a different question from majority
- The snapshot determines which voting power counts
- Voting power is not always one person, one vote
- Frequently asked questions
- Primary references and next lessons
What does a DAO actually mean?
DAO is short for decentralised autonomous organisation. The term is used broadly for groups coordinating through blockchain-related rules, member participation, software and governance processes. Different DAOs vary substantially in who can propose, who can vote, what the votes mean and who controls assets.
Some organisations use tokens as voting weight. Others use reputation, membership badges, delegates or a specified committee. Some actions are carried out by smart contracts, while others depend on legal organisations or teams completing work off-chain.
The word “autonomous” can make a system sound as though no people remain involved. In practice, communities still need to decide policy, write proposals, manage keys, handle disputes and maintain infrastructure. A smart contract can automate defined steps but cannot guarantee that a promised telescope physically arrives at the school.
Our fictional club might call itself a DAO because members use a shared vote and an on-chain treasury. Yet the school may still have ordinary rules regarding purchase authorisation, safeguarding students and accounting. Code and real-world governance interact rather than cancel each other.
The important first question is: what decisions can this DAO actually enforce through code, and which decisions remain requests to people or institutions?
The Ethereum governance guide distinguishes on-chain and off-chain decision-making. Its general explanation is useful, although Ethereum’s core protocol governance is not itself identical to the governing rules of every application-based DAO.
A proposal, a vote and an action are three different objects
A proposal describes a requested decision. In a simple club it might say “purchase one telescope for 40 credits.” A vote records eligible participants’ choices under agreed rules. An action is the later step of using treasury authority to make the purchase.
The proposal can be written in plain language without executable code. A voting system may record only an expression of preference. After the vote, authorised people must interpret the result and make the operational changes if those were intended.
Other systems embed machine-readable target contract calls in the proposal. For example, a governance mechanism might specify the target account, value and function data needed to transfer a treasury grant. Even then, the call must execute successfully under the network’s rules and the relevant governance authorisation.
Suppose a proposal passes with 60 votes in favour and 40 against. That tells you a tally, assuming the voter eligibility and weight rules are correct. It does not tell you whether the treasury contains enough assets, whether the target contract accepts the call or whether the proposer used an executable governance format.
A helpful status system would distinguish “drafted,” “voting open,” “vote succeeded,” “queued” and “executed,” with separate evidence for each. A single banner saying “passed” conceals essential information.
For readers, this is the most important habit: a successful vote is evidence about a decision process; a successful blockchain execution is evidence about an accepted state change. They need not happen together.
Off-chain voting can express a preference without moving tokens
Some DAO platforms support off-chain voting. Members sign votes or use other methods to record preferences without requiring each voter to submit a separate on-chain transaction and pay the associated network gas. This can reduce cost and make participation easier.
However, an off-chain vote result may function as a community signal rather than an automatically executable instruction. A committee, multisignature treasury, subsequent on-chain proposal or another approved process may be needed before anything changes in the ledger.
Imagine the science club collects student votes through an online survey. The result is authenticated and carefully counted. The school’s finance officer still needs a valid purchase request to release money. Calling the poll “successful” does not mean the finance officer has executed the purchase.
The ERC-4824 DAO interface proposal describes how off-chain decision systems can be used as signalling mechanisms or prerequisites for later governance steps. Its terminology reinforces the distinction between a vote and execution.
Snapshot is one widely known off-chain voting approach. Particular Snapshot-based communities may integrate additional execution systems, but a reader must check whether that specific proposal has an authorised bridge from the vote result to executable action.
Do not assume “off-chain” means fake or useless. Off-chain votes can be legitimate governance tools. Their consequence simply depends on the organisation’s defined rules, just as an ordinary school referendum may be advisory or binding under different institutional policies.
On-chain governance can encode the action and the conditions
An on-chain Governor-style governance contract can receive proposals, record or verify voting power and determine whether proposals satisfy the conditions for success. Some implementations can then execute contract calls associated with successful proposals. The relevant steps are defined by the deployed contracts, not by the website’s visual theme.
OpenZeppelin’s Governor documentation describes a standard governance architecture for Solidity smart contracts. It includes proposal creation, voting, successful outcomes and execution, with optional timelock integrations.
A key distinction is that an eligible proposal does not necessarily execute itself immediately when the voting deadline ends. The implementation may require someone to submit an execute transaction, and the authorised execution route must be valid.
In the fictional club, imagine its treasury is a locked equipment cabinet with a rule: only the approved governance key may authorise a purchase after a valid majority vote. The cabinet does not purchase the telescope spontaneously at the end of the ballot. Someone must use the proper instruction under the club’s rules.
A DAO’s design can automate some parts of that instruction path. But the software only enforces what it actually implements. A badly configured treasury owner or admin role may bypass expected governance, while missing roles can leave a successful proposal impossible to execute.
Before reading a passed vote as a completed decision, identify the specific governance contract, proposal state, executable actions, controlling authority and final transaction outcome.
Quorum asks a different question from majority
A proposal can attract more votes in favour than against and still fail if the governance rules require participation by a minimum amount of eligible voting power. That minimum is commonly called quorum. It prevents a tiny minority from making certain decisions under rules intended for broader participation.
Consider the science club’s 100 voting credits. Six credits vote in favour and two against, leaving 92 credits uncast. The vote among participating credits is three quarters in favour. Yet the club may require at least 20 voting credits to participate for a proposal to be valid. In that case, the apparent favourable majority does not meet quorum.
Some systems count abstentions toward quorum; others use different formulas. Approval thresholds might require a simple majority, a supermajority or specific categories of consent. One DAO’s rules should not be substituted for another’s.
A user interface that prominently displays “75% yes” without revealing the participation denominator can mislead readers. A proper result reports which addresses or voting units were eligible, how their weights were determined and which conditions were satisfied.
For a technical Governor implementation, the OpenZeppelin governance documentation describes quorum and voting options. The values and rules in that tutorial are examples for a particular implementation, not universal DAO law.
The best conclusion is precise: “The proposal received X votes for, Y against, met the specified quorum and satisfied the decision threshold.” That is much stronger evidence than a large green percentage.
The snapshot determines which voting power counts
Many governance mechanisms take a voting-power snapshot at a defined block or relevant time. This can prevent voting weights from changing unpredictably during a decision or from being counted in multiple places because tokens move between accounts.
Imagine Alicia holds ten voting credits on Monday. She transfers five to Kai Kai on Tuesday. If the DAO took the voting-power snapshot on Monday, the relevant vote may still evaluate weights based on Monday’s holdings or delegations rather than on whatever the wallet displays today.
This matters because a current portfolio balance is not necessarily the correct voting denominator. A reader who counts only today’s token balances can reach a different result from the protocol’s actual eligibility and snapshot rules.
Delegation can complicate the picture further. A holder may permit another account to cast votes using delegated voting power without transferring the underlying tokens. That is not automatically the same as transferring funds to the delegate.
The governance report should therefore name the snapshot block or reference, token and delegation scheme, eligible supply and tally rules. Without them, a vote percentage can be detached from the authority that produced it.
The detailed eduKateSG DAO voting guide walks through snapshot, denominator and execution. This reader article emphasises what the public result means: a precise vote must be tied to the correct basis before its outcome is trusted.
Voting power is not always one person, one vote
People hear “community governance” and may imagine each human participant receives one equal vote. Some DAOs do use membership-based processes, but token-weighted systems can give larger holders more voting power. A public address is not one verified human identity.
For a fictional example, Alice holds 50 governance credits, Kai Kai holds ten and Tricia holds five. One address each does not imply one equal vote each if the contract measures token weight. Likewise, Alice could operate several addresses, or a company could delegate votes to one account.
The governance system needs to state what is being represented: persons, capital, stake, membership roles or some other entitlement. A token-based mechanism may be transparent and correctly executed while distributing influence very unevenly.
A smart contract can accurately count voting weights without evaluating whether the resulting decisions are fair, wise or legal. Fairness and institutional legitimacy depend on the organisation’s purpose and rules.
This is why no student should hear “DAO” and automatically assume there is no leadership, no concentration of power or no ability for administrators to override certain actions. Those properties must be assessed in each real system.
For the related identity issue, read Why a Blockchain Address Is Not a Verified Identity. It explains why addresses, signatures, people and roles are not interchangeable.
Delegation separates token holding from voting authority
In some governance systems, a token holder can delegate voting power to another address while keeping control of the token itself. The delegate participates in votes under the protocol’s rules; delegation does not necessarily grant spending authority over the holder’s assets.
Return to our club: Alice has ten votes and asks Tricia, who follows club policy closely, to cast her votes. That delegation may improve participation when Alice cannot attend the meeting. Tricia’s increased voting weight is not equivalent to receiving ten ART credits as a spendable balance.
Delegations can change, and when a change takes effect depends on the governance system’s rules and snapshots. An explorer showing who holds tokens today may not reveal every historical voting-power relationship at the relevant block.
A proposal result can therefore contain delegated voting power rather than a simple count of individual wallets. The report should clarify whether weights came from balances, delegated votes or other credentials.
This also creates accountability questions. Who can be a delegate? Are delegates known to their constituents? Can holders revoke delegation? Does one powerful delegate represent many small holders? These are governance questions, not just arithmetic exercises.
The take-home lesson is that asset control, voting power and execution authority are three distinct capabilities. A system that describes all three as “ownership” makes it harder for readers to understand who can actually change what.
Why successful proposals may need to be queued
A DAO can require an additional queue step after a proposal succeeds but before it can execute. Queuing registers the exact approved operation for a later permitted execution. The rationale can include operational review, notice to users and separation between decision and action.
Some systems use a timelock so that an approved operation cannot execute until a specified delay has elapsed. The delay may give participants time to inspect the pending change, decide how to respond or identify a dangerous proposal before it takes effect.
Imagine the school club votes to change the rules for spending 40 credits. Its constitution says approved spending changes become actionable two days later. The approved vote is real, but the cabinet remains locked until that waiting period ends.
A timelock does not guarantee the action is safe or that everyone will notice it. The powers of administrators, cancellers and executors matter. If an authorised party can bypass the queue, the process may be weaker than a website’s description suggests.
OpenZeppelin’s Governance guide explains Governor-to-Timelock integrations and the separate queue and execute calls. The general model is straightforward, although not every DAO uses a timelock.
A useful status statement is: “Proposal P passed under the specified voting rules, was queued with execution permitted after the defined delay, and has not yet executed.” That status is meaningful without falsely claiming that the underlying action has already happened.
Who is allowed to execute the approved proposal?
Passing a governance vote does not necessarily grant every account permission to transfer treasury assets. The governance and timelock contracts usually have specific authorised roles or function conditions controlling execution.
Some systems allow any caller to trigger an already permitted action, while the smart contract ensures the approved parameters and conditions are satisfied. Others restrict execution to a particular role or operator. Both approaches can be valid when clearly designed.
Imagine the club’s treasury requires a valid proposal identifier and a permitted execution window. Kai Kai may be allowed to submit the final instruction, but he should not be able to change its destination or amount. The authority to press “execute” and the authority to choose what will execute are different.
If the wrong administrator holds the controlling role, governance expectations can be bypassed or blocked. If nobody has a usable execution path, a successful proposal may remain stuck. These are operational governance failures even when every vote was tallied correctly.
A good audit maps who can propose, vote, queue, cancel and execute, as well as who can grant or change those roles. The same exact contract address may represent an organisation with complex control relationships rather than one trusted person.
For a detailed example, the OpenZeppelin Governor tutorial explains how the Executor role and timelock interact. Readers should treat those as examples of configurable authority, not universal powers granted by the word DAO.
An execution can fail after the vote succeeds
A passed proposal may contain valid-looking executable calls but encounter a failure when submitted. The treasury might lack the required balance, the target contract might reject the operation or the network state might change in a way that makes the call invalid.
Suppose the school members pass a plan to pay 40 ART credits for a telescope. Between the vote and execution, the treasurer settles a different authorised bill, leaving only 30 credits. The approved payment instruction may now fail because the treasury lacks enough funds.
A software bug or unexpected upgrade in an external contract can also affect whether execution is possible. A protocol may revert a transaction if one of the required conditions is not met. The exact handling of failed and partial operations depends on the code and network.
A vote-success notification is therefore not a receipt for the treasury change. The execution transaction, its outcome and the resulting contract state must be checked separately.
The same applies to off-chain actions. A committee might pass a vote to hold a public event, but the venue could be unavailable. The actual meeting remains a separate institutional obligation requiring confirmation.
The lesson is familiar across technology: authorisation is not completion. Approval can make an operation permitted without ensuring all resources and external circumstances will still support it when the operation happens.
What about a proposal that cannot execute by design?
Some proposals are deliberately advisory. A DAO may vote to express support for a community goal, elect a committee or endorse a policy for human implementation. There may be no executable contract call attached to the proposal.
That does not make the vote meaningless. An advisory decision can guide administrators, signal community preferences or satisfy an organisation’s internal governance requirements. Its binding effect depends on the group’s agreed constitution, terms and applicable law.
Consider a vote asking the school club to adopt a more inclusive event schedule. The vote can express member support, but someone still needs to coordinate classrooms and teachers. No smart contract can automatically schedule every real-world room merely by counting votes.
Confusion arises when a website labels advisory and executable proposals in the same style. A reader may see “passed” and assume an immediate blockchain change even though the proposal has no on-chain payload.
The ENS DAO governance process provides a real example of distinguishing types of proposals and their routes. It describes social or constitutional proposals separately from executable proposals that go through on-chain governance and later execution.
The reader’s essential question is: what was the proposal asking the organisation to do, and what makes the result effective? The meaning of a successful vote is defined by the actual decision process.
A DAO website and its contracts can display different statuses
A governance dashboard may read vote results from an off-chain service, index contract events and construct a simplified status label. Like a block explorer, it is an information interface that may lag, omit conditions or apply a presentation choice.
One website could say “Passed” because the voting period ended with favourable tallies. Another may say “Queued” because the on-chain timelock has registered an operation. A third may report “Executed” after the accepted transaction changed state. All three may describe different stages of one proposal.
To reconcile them, identify the proposal ID, governance contract, network, vote or snapshot reference, relevant queue operation and execution receipt. Check which fields each interface is actually showing.
A stale browser could continue displaying “Passed” after execution, or a proposal may have been cancelled while an old cached card remains visible. A reader should not assume the status is current without knowing the update source and time.
More fundamentally, a governance proposal can refer to several distinct external actions. One execution receipt may not establish that physical equipment was delivered or that an off-chain policy was properly implemented.
The Why Two Block Explorers May Disagree guide teaches the same evidence habit for explorer displays: identify the data layer, status definition and actual accepted record before resolving a disagreement.
A worked example: the science club treasury
Our fictional club has 100 voting credits in its governance system and 80 spendable ART credits in its treasury. Members propose purchasing a telescope for 40. The proposal contains an explanatory paragraph and, under one implementation, a separate encoded treasury transfer.
The voting snapshot gives Alicia 35 votes, Kai Kai 15 and Tricia ten; the remaining 40 votes belong to absent members. The club’s rules say a proposal passes if more valid participating votes favour it than oppose it and quorum is at least 30 voting credits.
Alicia and Tricia vote yes, casting 45 credits. Kai Kai votes no with 15. Total participation is 60. Favourable weight exceeds opposing weight and the quorum requirement is met. The vote has passed under these fictional rules.
The club also requires a one-day timelock. The proposal enters a queue. A student reading the result that evening can correctly say the decision is approved, but not yet executed. A second student reading the treasury sees all 80 ART credits still present.
The next day, an authorised execution request transfers 40 to the specified supplier account, and the treasury balance falls according to the ledger. Now the code-level payment action has happened. Whether a real telescope was delivered is still an external fact requiring separate proof.
This one example shows why tally, quorum, queue, execution and real-world fulfilment should be separated rather than hidden under one banner marked “DAO voted yes.”
A paper exercise: follow a proposal through six stages
Give students six cards: draft, eligible for vote, vote active, vote successful, queued, executed. Ask them to arrange the cards in a plausible Governor-and-timelock process. Then remove the queued card to illustrate that some systems do not require a timelock.
Next give the class a second set of cards: off-chain discussion, signed community poll, result published, committee instruction, real-world purchase. This process can also be legitimate governance, but it is not the same as an automatically executable on-chain flow.
Ask what evidence belongs beside each stage. A draft might have a proposal text. Voting eligibility may require a snapshot and threshold. The active vote needs records of eligible choices. Success needs tally and quorum proof. A queue needs a timelock operation. Execution needs an accepted transaction and effect.
Now introduce a failure: the executor lacks permission or the treasury cannot fund the action. The vote’s earlier success remains a fact even though the final action fails. Students can learn to report two states without calling the whole system contradictory.
Finally ask which human promises remain after execution. An equipment purchase might require shipping, warranties and accounting. The ledger cannot inspect the delivered telescope on its own.
No cryptocurrency or live wallet is required. The exercise makes DAO governance understandable as a sequence of accountable steps with different evidence and authority at each stage.
Seven questions that reveal whether a DAO decision really happened
Which governance system? Identify whether the decision uses an off-chain poll, on-chain Governor, legal committee or another mechanism. The word DAO alone does not define the result.
Which proposal and payload? Find the exact proposal and distinguish explanatory text from executable contract calls or human instructions.
Who could vote and with what weight? Check snapshot, delegation, quorum and approval threshold. A percentage without a denominator is weak evidence.
Was the vote binding? Determine whether the result is advisory, triggers another governance step or authorises a directly executable operation.
Was queuing required? Identify any timelock, pending dependency, cancellation possibility and earliest permitted execution condition.
Who controlled execution? Check the contract’s or organisation’s executor role and whether the required authorised action actually occurred.
What changed? Inspect the resulting on-chain state and any independent real-world fulfilment evidence. Passing a vote does not automatically purchase goods, deliver services or repair a system.
A strong summary might read: “Proposal P passed the voting rules with quorum, entered a timelock queue, and later executed transaction T, which changed the treasury state. The promised goods remain awaiting delivery.” It is precise and useful because every clause refers to its own evidence.
Frequently asked questions
Does a passed DAO vote automatically send funds?
Not always. Some systems require a separate queue or execute step, while off-chain polls may need human or contract actions later. The DAO’s actual rules determine the result.
What is an on-chain governance proposal?
It is a proposal handled through a blockchain governance mechanism, potentially including machine-readable calls and voting records under smart-contract rules.
What is an off-chain DAO vote?
It is a decision or preference recorded outside the blockchain’s normal transaction execution, often using signed messages or a governance platform. Its binding consequence depends on the community’s process.
What does quorum mean?
It is a minimum participation or voting-power condition, defined by the governance rules. A favourable majority can fail when quorum is not met.
Is one token always one vote?
No universal rule exists. Voting can use token weight, delegation, memberships or other mechanisms. Even one address does not necessarily represent one person.
Why does governance use a snapshot?
A snapshot provides a reference for eligible voting power under a defined rule, reducing confusion from balances or delegations that change during the vote.
What does a timelock do?
It delays an authorised operation until specified conditions are met. A delay can support notice and review but is not a guarantee that the action is safe.
Can a passed proposal fail to execute?
Yes. Permission problems, insufficient funds, invalid calls, missing dependencies or changes in relevant network state can prevent successful execution.
Is an on-chain vote always binding?
Not necessarily. Some votes are signalling-only or feed into another process. The governing design and applicable rules determine their effect.
Can anybody execute a passed proposal?
It depends on the governance contract’s executor rules. Some systems permit a broad set of callers to trigger already authorised actions; others restrict that capability.
Does execution prove the real-world promise was fulfilled?
No. An accepted treasury transfer does not by itself prove delivery of a telescope, publication of a report or completion of an off-chain agreement.
What should readers remember?
Vote success concerns a decision rule; execution concerns an authorised action; real-world fulfilment requires evidence beyond the vote and often beyond the blockchain.
Primary references and next lessons
Ethereum Governance explains differences between on-chain and off-chain decision processes. OpenZeppelin’s Governor guide shows voting, quorum, executable proposals, queueing and timelocks in a common smart-contract architecture. ERC-4824 describes signalling roles that off-chain DAO proposals can serve. ENS DAO Governance provides a concrete public example of distinct proposal types and execution processes.
For deeper eduKateSG study, continue to DAO Voting: Check the Snapshot, Denominator and Execution, Reconcile a Blockchain Timelock Queue, Why a Smart Contract Audit Is Not a Safety Guarantee and Why a Blockchain Address Is Not a Verified Identity.
The memorable question is this: What did the members approve, which rule gave that decision authority, and where is the evidence that the approved action actually took effect? That is how a governance announcement becomes an accountable record rather than an unexplained green badge.