DAO governance
DAO governance due diligence: trace the real authority
A DAO proposal can be a discussion, a signal, a contract instruction or one step in a larger approval process. Governance research asks who can cause which action, under what rules, and what evidence would show it happened. This guide follows authority from a proposal to execution. Its examples describe invented systems and do not assess AlfaDAO’s own governance or endorse a governance token.
Educational research methods, without recommendations to buy, sell or hold an asset. Crypto assets can lose all their value. Read the risk disclosure.
By AlfaDAOPublished Updated
1. Map the decision system and the assets it controls
Start by listing the forum, voting interface, governance contracts, treasury addresses and implementation administrators that the organization publicly identifies. Record the network and source of each address. Draw the intended path from discussion to a binding action, marking every step that needs a separate person or contract. Do not assume that a forum poll or an off-chain signature directly moves funds.
OpenZeppelin’s Governor framework is one example of modular on-chain governance, rather than a rule all DAOs follow. Its documentation distinguishes voting, counting, settings and execution-related modules. Match the deployed system to its own implementation and configuration. If there is no documented link between the vote and the account holding the assets, keep that gap explicit instead of filling it with the organization’s branding.
Source references
2. Measure voting power at the relevant point
Find the source of voting weight, proposal threshold, quorum definition, voting period and the clock or snapshot used. Identify delegation where applicable. Current token balances may differ from the voting weight used for a particular proposal. Check how abstentions and other vote choices are counted, rather than assuming that all participation contributes to the same threshold.
Use a hypothetical illustration: a system reports one million units of voting weight and a quorum requirement of 100,000 units. A proposal receiving 90,000 favorable units is not automatically successful; abstention treatment, opposing votes and other rules still matter. The arithmetic describes only invented inputs. For a real proposal, preserve the actual rules and the values at its snapshot, together with the block or timestamp used to reproduce them.
Source references
3. Compare the proposal text with the executable payload
For a contract proposal, inspect each target address, function call, argument, native-currency amount and dependency. OpenZeppelin’s governance guide describes proposals as a collection of executable actions plus human-readable text. The description helps explain intent, while the encoded calls determine the requested on-chain action. Record when the interface does not provide enough information to reconcile them.
Imagine a proposal described as a 50,000-token community grant. The review should identify the token contract, recipient, amount in the token’s units and every additional call. A second permission-changing action deserves its own explanation, even if the title mentions only the grant. This is a read-only review: there is no need to execute a proposal or sign a transaction to compare the declared purpose with its payload.
Source references
4. Trace timelocks, multisignatures and alternate powers
Identify who can queue, execute, cancel or change an operation and whether a delay applies. A passed vote is not the same as an executed transaction. OpenZeppelin documents timelock roles and warns that extra authorities can change the effective governance path. Read the actual assignments, especially any account that can upgrade contracts or administer roles outside the ordinary vote.
If a Safe account holds the treasury, record owners, the confirmation threshold and enabled modules. Safe documents both owner-confirmed transactions and module transactions; a threshold alone is therefore an incomplete control map. A nominal three-of-five arrangement also does not establish that five owners are independent people or organizations. Describe observed controls and disclosed relationships without inventing identities from wallet activity.
5. Reconcile approval, execution and the resulting state
Collect separate evidence for the discussion outcome, voting result, any queue operation, execution transaction and resulting state. Check whether an approved action expired, was canceled or remains unexecuted. For a parameter change, identify a read-only observation that confirms the new value; for a treasury transfer, reconcile the correct asset and recipient with the executed transaction.
In the fictional grant example, a successful vote followed by no execution supports the statement approved but not yet paid. A transfer to the named recipient supports payment, while it says nothing by itself about whether the recipient completed the promised work. Preserve milestone reports and spending evidence as separate research questions. Keeping those stages distinct prevents a governance dashboard from being mistaken for an outcome audit.
6. Summarize who can act and what happened
List the accounts that can act, the approval steps, any bypass powers and the transactions observed. State whether the finding applies to one proposal or to the wider contract configuration, and record the block or date. Owner lists and permissions can change after the review.
Disclose any participation or interest relevant to the proposal. An unexplained permission is a question to investigate; it does not by itself establish misconduct. Likewise, a large treasury or high turnout does not establish that execution is secure.