Execution
DAO proposal execution: turning a passed vote into an onchain transaction
Most governance tooling stops the moment a vote closes. The transaction still has to be encoded, verified against quorum and timelock rules, signed by a multisig and broadcast. That gap is where DAOs lose weeks.
What execution really involves
Execution is the sequence that starts after approval: encode the calldata, confirm the vote met quorum and threshold, queue the action in the timelock, collect the required multisig signatures, then broadcast to the target chain and record the hash.
Each step has a different owner in most DAOs - delegates vote, a core contributor encodes the payload, and a signer set executes. Handoffs between those roles are the single biggest source of delay.
Why passed proposals stall
Calldata is written after the vote instead of before it, so what passed and what executes can diverge.
Signers are in different timezones and the timelock window expires before the last signature lands.
Nobody owns the audit record, so the DAO cannot prove which transaction implemented which decision.
The execution-first model
Define the exact transaction at proposal time. Voters approve the payload itself, not a description of it.
Verify conditions programmatically: quorum, approval threshold, signature count and timelock maturity are checks, not opinions.
Execute and record in one motion so the transaction hash is attached to the proposal forever.
A worked example of a proposal reaching the chain
Imagine a lending protocol votes to raise a collateral factor. The decision is one line of English, but onchain it is a call to a risk parameter contract with an encoded argument, sent from an address the protocol trusts. If that call is written after the vote, the DAO is trusting a contributor's transcription rather than the result of the vote itself.
In an execution-first flow the calldata exists before voting opens. Delegates see the exact function, target address and argument they are approving. When the vote closes, the only remaining questions are mechanical: did quorum pass, has the timelock matured, are enough signatures present. Those answers are checks a machine can make, which is why the last mile can be automated end to end.
How to measure whether execution is healthy
Track time to execution, the gap between a vote closing and the transaction confirming. Most DAOs never measure it, and most are surprised when they do. Anything beyond a few days usually points at signer availability rather than at the governance rules themselves.
Track the execution rate too: the share of passed proposals that actually settled onchain. A DAO with a ninety percent approval rate and a sixty percent execution rate is not governing, it is publishing intentions. Pair both numbers with a permanent record of transaction hashes so the community can verify each claim independently.
Keep the execution path connected: this guide pairs well with dao meaning, dao crypto and multisig wallet setup, which cover the neighbouring steps between an approved vote and a settled onchain transaction.
Key concepts explained
New to this topic? These are the core terms you will meet again and again in governance work. Understanding them makes every proposal easier to read.
- Calldata
- The encoded instructions a transaction sends to a smart contract - the function to call and its arguments. In governance, calldata is the actual decision: if it is wrong, the wrong action executes.
- Payload
- The complete onchain action a proposal approves: target contract, calldata and value. Voting on the payload itself means what passed is exactly what executes.
- Executor
- The address or contract with permission to run the approved transaction. Because it is the final privilege, it should only act after quorum, threshold and timelock checks pass.
- Settlement
- The point where the transaction is mined and irreversible. A proposal is only truly executed once its settlement hash is recorded.
Frequently asked questions
- How are governance proposals implemented in blockchain DAOs?
- A passed proposal is implemented by broadcasting the transaction it authorised. A governor contract stores the encoded call, verifies that quorum and the approval threshold were met, waits out any timelock delay, and then allows the queued call to be executed against the target contract.
- Who executes a DAO proposal after it passes?
- Usually a multisig signer set or a permissionless executor role. Governor contracts commonly let anyone trigger execution once conditions are satisfied, which removes the single point of failure of waiting for one contributor to act.
- Can a DAO proposal pass and still never happen?
- Yes, and it is common. If the calldata was never prepared, if the timelock window lapses, or if signers do not gather in time, the approval expires without any onchain effect.