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.