What is a DAO?

A decentralized autonomous organization (DAO) is a way of organizing in which several people make decisions, manage funds or maintain a project together under rules agreed in advance. It often records membership, proposals, voting results or fund permissions on a blockchain, so participants can check both the rules and how they were carried out, instead of handing every decision to one administrator.

A DAO is not a fixed software product, and it does not mean "nobody is responsible". Some DAOs mainly use onchain voting to control smart contracts — programs deployed on a blockchain that perform operations according to preset code. Others first discuss and vote offchain, meaning in forums or voting tools that do not write directly to a blockchain, after which several people sign jointly to execute. A development team, a trusted group or an emergency administrator may also retain specific permissions. Understanding a DAO means looking separately at who can propose, who holds voting rights, how results are executed, and who ultimately holds the funds and system permissions.

What a DAO coordinates is people, rules and resources

An ordinary organization can coordinate members through articles of association, meetings, bank accounts and internal systems. A DAO places some of those rules and records into a publicly verifiable technical system. Common components include:

• Membership rules: who can join, propose, vote or take on a particular role;
• Governance process: how a proposal is submitted, when voting opens and closes, and what conditions it must meet to pass;
• Execution permissions: whether a passed decision is executed automatically by a smart contract, or completed by designated accounts or signers;
• Shared resources: funds, protocol parameters, domain names and other permissions managed by a contract account or jointly by several people;
• Communication tools: forums, chat tools or web interfaces used to discuss, present proposals and notify members.

Different DAOs may adopt only some of these, and the same name does not mean they share the same member rights, voting methods or control over funds. These common elements can also be cross-checked against Ethereum.org's introduction to DAOs.

A decision moving from proposal to execution

DAO governance usually starts with a proposal. A proposal can simply express community preference, or it can carry an onchain operation ready to execute, such as adjusting a protocol parameter or paying out from shared funds.

Next, the system determines who may vote and how much voting weight each participant has, under the established rules. Some systems fix each address's voting power at a specified past block or point in time; this basis for calculation is often called a snapshot. Transferring tokens afterwards therefore usually does not change the weight available for that vote; whether the same address can vote more than once is instead limited by the particular voting contract's or system's counting rules. Once voting closes, the system then checks participation, the share in favour and any other conditions for passing.

A vote passing does not necessarily mean the decision has been executed. A proposal may first enter a waiting period, giving participants time to check the result or respond to risks. After that period, in systems where execution is open to anyone, any party may send the execution transaction; other systems may require confirmation from several signers, or have an administrator carry it out offchain. If a proposal is only intended to gather opinion, it may not produce an onchain operation at all.

When examining a governance decision, therefore, distinguish at least three stages: proposed, voted through, and actually executed. OpenZeppelin's Governor documentation shows one onchain flow: after a proposal passes voting and the checks for passing conditions, it can be queued and then executed by a contract holding the relevant permission. It is one common implementation, not a uniform process for all DAOs.

Membership and voting rights can come from different rules

A DAO does not have to give every participant the same number of votes. Common arrangements include:

• Token-weighted: voting power relates to the amount of a governance token held;
• Membership or identity-based: approved members each have one vote, or receive different permissions by role;
• Contribution or reputation-based: voting power is allocated by participation record, assessed contribution or non-transferable standing;
• Multi-signature: a group of signers is designated in advance, and an operation can only be executed once the required number confirm;
• Hybrid: a broad membership expresses an opinion, which a committee, signers or an onchain contract then implements.

A governance token is usually used to calculate voting power under a particular set of rules, but holding one does not automatically mean the holder owns an organization, project assets, a right to revenue, or every operational decision. The actual rights depend on contract functionality, governance rules and other arrangements.

Voting power can also be delegated. Delegation means a participant assigns their voting power to another address to use on their behalf, rather than transferring the tokens themselves. It can concentrate participation among those more willing to study proposals, but it can also gradually concentrate power among a few representatives.

Quorum and the passing threshold solve different problems

Governance rules usually set both a participation requirement and a requirement for passing.

Quorum is the minimum participation needed for a vote to be valid. Rules can, for example, require that at least a certain share of total voting power takes part, so that a very small number of people cannot make a major decision while other members are absent.

The passing threshold determines how many votes in favour are needed among valid votes. It can be a simple majority, or a higher share for matters such as upgrading contracts or spending large sums. Some systems also set a proposal threshold, requiring the initiator to hold a certain amount of voting power or gather enough support, which reduces spam proposals.

Reaching quorum only shows that participation was sufficient; it does not mean the proposal has enough votes in favour. A majority in favour may equally fail to pass because total participation fell short. Readers need to look at the counting method at the same time: whether abstentions count towards quorum, whether not voting has an effect, and at which point in time voting power is calculated.

Onchain and offchain voting have different execution power

Onchain voting submits votes as blockchain transactions, so a contract can check voting power directly, count votes and connect to subsequent execution. Its records are easy to verify publicly, but participants may have to pay network fees, and the voting logic and contract security also affect the outcome.

Offchain voting usually has participants sign messages, which an independent system then collects and tallies without writing every vote to a blockchain. A signature helps establish which address made a choice, but the voting result may not automatically control funds or contracts. If the result has to be executed by a multi-signature account or an administrator, readers should also check whether those executing act in line with the vote.

"Being onchain" does not guarantee fully distributed governance either. A web page can hide proposals, a data service can display incomplete information, and a contract can retain a cancellation or veto role. Conversely, offchain discussion and voting can also be publicly recorded and form a dependable process; what differs is the execution constraint they rely on.

Shared funds are determined by the permission structure

A DAO's shared funds are often called a treasury. A treasury can be controlled by a governance contract, a multi-signature account or another permission system. Multi-signature means an operation requires confirmation from a set number of pre-designated signers, and no single signer can complete it alone.

There are three common relationships between voting and the treasury: a passed onchain proposal calls the treasury directly; the voting result enters a waiting contract before execution; or the vote only produces a decision, with signers completing the payment manually. In the third arrangement, those voting and those actually holding the fund permissions are not the same group.

Assessing a treasury means looking beyond the balance or the number of participants. Also check who can add or remove signers, change the confirmation threshold, upgrade the controlling contract, cancel a queued operation, and pause the system in a security incident.

"Autonomous" does not mean free of human participation

The word "autonomous" in the DAO name usually means part of the rules can be enforced continuously by software, not that all the work is done automatically by code. Members still have to put forward plans, assess information, develop software, handle disputes and complete offchain tasks. Code can also only enforce conditions that have been written into it; it cannot confirm by itself whether a real-world commitment was honoured.

Likewise, "decentralized" is not a black-and-white conclusion. A DAO can spread voting power across many members while letting a few signers control the funds; it can also let anyone view and execute passed proposals while only a few addresses can initiate them.

A more practical check is to judge layer by layer:

• whether the right to propose is open, or controlled by a few addresses;
• how voting power is distributed, and whether it concentrates among a few members;
• whether voting participation is high enough to reflect member opinion;
• whether results can be executed by contract, or depend on trustees cooperating;
• who holds the treasury, upgrade, pause and veto permissions;
• whether the main web pages, forums, nodes and data services have a single dependency.

Together, these answers describe a DAO's actual control structure. Member count, number of token holders or an "onchain governance" label are each insufficient on their own to judge how distributed it is.

DAOs, DApps, smart contracts and governance tokens

A DAO is a way of coordinating decisions and resources; a decentralized application (DApp) is an application that lets users work with onchain programs and related services. A DAO can use a DApp to provide a proposal and voting interface, but an ordinary DApp does not necessarily have member governance.

A smart contract is a program on a blockchain that executes according to its code. A DAO can be made up of several contracts, web pages, forums and human roles together, so a governance contract itself cannot be treated as the whole DAO.

A governance token is one tool for allocating or recording voting power. A DAO can do without a tradable token and use membership, reputation or multi-signature instead; and a project with a governance token does not necessarily hand treasury, upgrade or operational permissions to token voting.

Main limitations and risks

Making rules public does not remove governance risk. Common problems include:

• voting power or delegation concentrates, letting a few participants sway results;
• most members do not vote, so low turnout decides important matters;
• a proposal's description does not match the code it will actually execute;
• a malicious proposal uses contract permissions to move funds or change key rules;
• the governance contract, treasury or web interface contains a defect;
• administrators, veto holders or signers have permissions beyond what members expect;
• the waiting period is too short for members to spot risks, or too long to respond to an emergency in time;
• offchain information is wrong, so participants vote on a false premise.

A blockchain can help participants verify voting records and onchain execution, but it cannot guarantee that a proposal is sound or that participants are adequately informed, and it cannot automatically establish that offchain action was completed. When reading DAO material, cross-check promotional phrasing such as "community owned" or "fully autonomous" against the actual contract permissions and execution flow.

FAQ

Must a DAO issue a governance token?

No. Membership status, contribution records, non-transferable standing or multi-signature can all be used to allocate decision-making power. A token is only one common tool.

Will a passed vote always execute automatically?

Not necessarily. A result may be executed automatically by a contract, or it may require a waiting period, an extra transaction, multiple signatures or manual work. Check how the voting system connects to the final permissions.

Do DAOs have no administrators?

Not necessarily. A DAO may retain roles for upgrading, pausing, vetoing, cancelling proposals or managing the interface. Whether those permissions exist and who holds them matters more than the name "DAO".

Does whoever holds the most tokens control a DAO?

That depends on the voting rules, token distribution, delegation, quorum and passing threshold. In a token-weighted system, holding or acquiring substantial voting power usually increases influence, but other limits and participants' behaviour also change outcomes.

Is all of a DAO's activity public?

Not necessarily. Onchain transactions and contract state can usually be queried publicly, but discussions, membership, development work and offchain agreements may not be. Results shown on a web page also need checking against the onchain record.

Related concepts

Continue with smart contract, decentralized application (DApp), blockchain, non-custodial wallet and crypto token, or return to the Crypto Glossary.

Sources

• Ethereum.org: introduction to DAOs — common membership forms, proposals, voting, delegation, multi-signature and shared funds in DAOs.
• OpenZeppelin Docs: onchain governance — voting power snapshots, quorum, proposal thresholds, voting periods, waiting and execution flow.
• OpenZeppelin Docs: Governance API — governance modules, counting rules and the proposal and execution roles in a timelock contract.