What a DAO really is: a smart contract that holds the keys

A treasury that obeys code, not a boss

In November 2021 a crowd of strangers on the internet pooled roughly 11,600 ETH — about $47 million — in under a week, hoping to buy one of the few surviving original printings of the U.S. Constitution at a Sotheby's auction. They called themselves ConstitutionDAO. They lost the auction to Citadel's Ken Griffin (a $43.2M hammer price), and afterward token holders could reclaim their share. What is striking is not the loss but the machine: seventeen thousand people who had never met assembled a multi-million-dollar war chest, with no company, no bank account, and no one person able to walk off with the money. The keys were held by code.

DAO stands for Decentralized Autonomous Organization, and the phrase does more to confuse than to explain. So strip it down. A traditional company is, at bottom, a bank account plus a rulebook (the bylaws) plus people the bank trusts to sign. A DAO keeps the first two and deletes the third. Its money sits in a treasury, its rules are written as smart contracts, and instead of a trusted signatory, the rules themselves decide when the money moves. No CFO, no wire-transfer approval, no branch manager — just code that executes when, and only when, its conditions are met.

Two ways to hold the keys: multisig vs token vote

Every DAO has to answer one question before anything else: *who is allowed to authorize moving the treasury's money?* There are two dominant answers, and most real organizations are somewhere on the line between them.

The first answer is a multisig wallet — a contract that releases funds only when M of N named owners sign off, like a 3-of-5 Gnosis Safe. It is simple, fast, and battle-tested; it is also how ConstitutionDAO actually custodied its ETH. The catch: you have to trust those named humans. If 3 of the 5 collude (or get phished), the treasury is theirs. A multisig decentralizes a single point of failure into a handful of points, which is a real improvement — but it is a federation of trusted people, not yet a trustless organization.

// A 3-of-5 multisig "Safe": funds move only with enough valid approvals
function executeTransaction(address to, uint256 value, bytes data, Signature[] sigs) external {
    require(sigs.length >= threshold, "not enough approvals");   // threshold = 3
    address last = address(0);
    for (uint i = 0; i < threshold; i++) {
        bytes32 h    = hashTx(to, value, data, nonce);          // what each owner signed
        address owner = recover(h, sigs[i]);                    // ECDSA: signature -> address
        require(isOwner[owner] && owner > last, "bad or duplicate signer");
        last = owner;                                           // strictly increasing => no double-count
    }
    nonce++;                                                    // burn the nonce: no replay
    (bool ok, ) = to.call{value: value}(data);                 // the Safe itself makes the call
    require(ok, "inner call failed");
}

The second answer is full on-chain governance: authority is spread across thousands of holders of a governance token, and the outcome of a vote is executed automatically by the contracts, with no human signer at all. This is token-weighted voting — one token, one vote — and it is what people usually mean by a "real" DAO. It scales to anonymous strangers and removes the trusted committee, but it is slower, can be captured by whales, and demands far more machinery. The next guide in this rung dissects that voting machinery in detail; here we just need to see where it sits.

The treasury: the one thing a DAO actually controls

Strip a DAO to its load-bearing wall and you find the treasury: a pile of assets — ETH, stablecoins, the DAO's own token, sometimes NFTs — owned by a contract rather than a person. These are not toy sums. Mature protocol treasuries have held the equivalent of billions of dollars (Uniswap and Optimism among them). The defining property is brutally simple: there is no private key that can sweep the treasury. Its owner is a contract, and the only door into that contract is a governance decision.

In the most common production stack (OpenZeppelin's Governor + Timelock), the assets don't even live with the voting contract. They live behind a separate TimelockController, which is the actual holder and admin of the funds. The voting contract can only ask the timelock to make calls; the timelock makes them after a mandatory delay. Wiring it this way means a single bug in the vote-counting logic can't instantly drain the vault — there is always a waiting room.

// Who owns what, in a typical on-chain DAO (OpenZeppelin stack):
//
//   GovernanceToken     -> mints "weight": balance at a snapshot block = your voting power
//   Governor            -> tallies votes; can ONLY propose & queue calls into the Timelock
//   TimelockController  -> HOLDS the treasury (ETH, USDC, NFTs) and executes the calls
//                          after a mandatory delay; its admin is the Governor, not a human
//
// So the only path to the money is:
//   token holders vote  ->  Governor approves  ->  Timelock waits  ->  Timelock executes
// There is deliberately no shortcut.

The proposal lifecycle: from idea to on-chain execution

Here is the part that makes a DAO feel like magic the first time you watch it. A governance proposal is not a paragraph of intentions — it is the exact transaction(s) the DAO will perform if the vote passes, encoded up front. "Fund the docs team with 50,000 USDC" isn't a promise; it is a literal call to `USDC.transfer(grantee, 50000e6)` that the contracts will make on your behalf. The English description is just a label stapled to the bytecode.

// OpenZeppelin Governor: a proposal IS the list of calls to make if it passes
address[] memory targets    = new address[](1);
uint256[] memory values     = new uint256[](1);
bytes[]   memory calldatas  = new bytes[](1);

targets[0]   = USDC;                       // the contract the DAO will call
values[0]    = 0;                          // no ETH attached to this call
calldatas[0] = abi.encodeCall(             // exactly: transfer 50,000 USDC to the grantee
    IERC20.transfer, (grantee, 50_000e6)   // USDC has 6 decimals => 50_000e6
);

uint256 proposalId = governor.propose(
    targets, values, calldatas,
    "GP-42: Fund the docs team with 50,000 USDC from the treasury"
);
// proposalId == keccak256(abi.encode(
//     targets, values, calldatas, keccak256(bytes(description))
// ));  -> the id is a hash of the calls, so the description can never be swapped out

From there the proposal moves through a fixed sequence of on-chain states. Each transition is enforced by the contract, so no one can skip a step, vote after the deadline, or execute something that lost.

1. Propose. A holder whose voting weight is above the proposal threshold submits the encoded calls plus a description. The contract records the proposal and a snapshot block. Requiring a threshold keeps the queue from being spammed by anyone with one token.
2. Voting delay → Active. After a short delay (so people can prepare and so the snapshot is locked), voting opens. Holders cast For / Against / Abstain, weighted by their token balance at the snapshot block — buying tokens after the snapshot buys you no votes on this proposal.
3. Tally → Succeeded or Defeated. When the voting period ends, the contract checks two things: did For beat Against, and was the quorum (a minimum number of votes cast) reached? A proposal can win the vote yet still fail for lack of quorum — a guard against a tiny, unrepresentative clique deciding for everyone.
4. Queue (the timelock). A succeeded proposal is queued into the timelock, which starts a mandatory waiting period — often 2 days. Nothing has moved yet. This delay is the single most important safety valve in the system, which is why it gets its own step.
5. Execute. Once the timelock delay elapses, anyone can call `execute()` — and the timelock makes the exact calls that were proposed. The 50,000 USDC leaves the treasury. The organization just acted, and no individual signed the transfer. The chain did it because the rules said so.

Why does the timelock matter so much? Because it gives the minority who lost the vote time to react. If a passing proposal would hand control to an attacker or change a rule you can't live with, the delay is your window to withdraw funds, exit a position, or rally opposition before the change lands. A DAO without a timelock is one bad vote away from instant, irreversible damage — a theme the governance-attacks guide returns to in force.

On-chain, or just a brand? The Snapshot question

Now the honest part. The clean propose-vote-queue-execute pipeline above is binding on-chain governance: the vote and the action are the same transaction trail, and code carries it out. But a large share of organizations that call themselves DAOs do not work this way at all.

The most common pattern in practice is off-chain signaling. Holders vote on Snapshot, a free, gasless platform where votes are signed messages stored off-chain, weighted by a token balance read from a past block. It is cheap and inclusive — but a Snapshot vote executes nothing. It is a poll. To turn the result into action, a trusted multisig team still has to go and make the transaction by hand. That is perfectly reasonable, and it is what most projects do — but be clear-eyed about it: this is off-chain governance plus a human committee. The community signals; a small group decides whether to honor the signal.

So the test for whether something is really a DAO is not the logo or the Discord — it is: does a passed vote move the money by itself, or does a human still have to choose to obey it? Most projects sit on a spectrum: pure multisig at one end, off-chain Snapshot feeding a multisig in the middle, fully binding on-chain Governor + Timelock at the other end. Delegation (letting passive holders assign their weight to active, accountable representatives) is how the binding end stays workable at scale, since most token holders never vote.

The limits: speed, plutocracy, and the legal gap

It would be dishonest to end on the magic. On-chain organizations carry real, structural weaknesses, and the rest of this rung exists because of them. Three are worth naming now.

They are slow and rigid. A change that a startup CEO could ship in an afternoon may take a DAO a week: proposal threshold, voting delay, voting period, timelock. That latency is the price of having no boss — and it is sometimes fatal in a fast-moving crisis. They tend toward plutocracy. One-token-one-vote means one-dollar-one-vote; whoever holds the most tokens holds the most power, and apathy concentrates it further as small holders stay home. Worse, voting weight can be rented: an attacker can borrow a mountain of governance tokens for a single block and ram a malicious proposal through — the kind of governance attack the next guides dissect, and a major reason the timelock exists.

And there is a legal gap. "Code is law" is a slogan, not a court ruling. A DAO can hold money and execute votes flawlessly while having no clear legal personality — which raises hard questions about liability, taxes, and contracts with the outside world. Jurisdictions have begun to respond (Wyoming's DAO LLC, the Marshall Islands' DAO statute), letting a DAO adopt a legal wrapper so it can sign a lease or limit its members' liability. Whether on-chain rules and off-chain law can be reconciled is still an open, evolving question.

Hold on to the one idea under all of this: a DAO is a smart contract that holds the keys to a treasury, and a process for deciding when those keys turn. Everything ahead in this rung is detail on that process — how the votes are counted and delegated, how attackers try to subvert them, how to design ballots that resist wealth and sybils, and how a token's economics keep the whole system honest instead of Ponzi-shaped.