DAO security audit: follow proposals from voting power to treasury execution

Named governance incidents: the vote and the payload are different evidence

A DAO security audit examines how voting power becomes executable authority over a protocol or treasury.

The historical record shows why those steps must be reviewed together. A valid count can authorize an unsafe operation, and a proposal description can fail to represent the code that ultimately executes.

Beanstalk's primary account identifies a flash loan used against governance on April 17, 2022.

The protocol team reported approximately $77 million stolen in non-Beanstalk user assets. That asset definition should remain attached to the figure. The account supports the connection between temporary financing and governance authority; it does not justify treating every later Beanstalk configuration as the same system.

The May 2023 Tornado Cash governance incident illustrates a different path.

Halborn's technical explanation describes a proposal whose code could be replaced before delegated execution. Its account connects that execution to attacker-controlled governance power. The historical mechanism matters because the code voters thought they approved and the code that changed governance were not equivalent.

Keep the fork context attached to that case.

Historical behavior involving contract destruction and replacement should not be presented as a universal current EVM capability. The durable review question is whether the payload and code reachable at execution remain the action that was reviewed and authorized.

This is not a complete incident census.

The cases were selected as verified illustrations of different authority boundaries. We do not combine their losses, infer a governance failure rate or use an incident to claim that an unrelated current implementation is vulnerable.

The investigative sequence starts with the state change that mattered: treasury movement, altered voting balances or replacement of protocol logic. Trace backward through the execution transaction, proposal and voting record. A screenshot of a successful vote is only one piece of that chain.

Proposal execution paths: bind intent to the final call

A proposal can carry a list of targets, values and encoded calls.

Its human description may be useful context, but the executable payload determines what the chain permits. Review the complete batch and every indirect call it can trigger. A benign first action does not make later actions benign.

Record the code and configuration that each target will use at execution.

An upgradeable target may change behavior between a proposal's creation and execution. A delegated call can operate in the caller's storage context. A helper contract can introduce another layer of authority even when its own address remains unchanged.

The audit should define which parts of the proposal are bound into its identifier and which dependencies remain mutable. Inspect the implementation instead of assuming a familiar governance framework supplies the intended binding. Also establish whether execution can occur more than once or whether a partially completed route leaves a new opportunity.

Simulation is useful evidence about a specified state.

It can reveal asset movements, role changes and unexpected calls before the proposal executes. It is not a guarantee that the same result will hold after target configuration or chain state changes. Preserve the simulation block and the inputs that determine the result.

For a release decision, compare three artifacts: the human intent, the reviewed executable payload and the observed execution result. An inconsistency needs investigation even if the vote passed. Governance authorization cannot make an incorrectly described payload equivalent to the community's stated decision.

1. Decode the full proposal and identify every target and transferred value.
2. Resolve the implementation and relevant configuration for each target at the review state. Follow delegated and indirect calls.
3. Simulate the intended execution in an isolated environment and record meaningful state changes.
4. Check replay, cancellation and failure behavior for the whole proposal, including batched actions.
5. Compare the final executed payload and resulting state with the approved record.

The upgrade-path review supplies the storage and implementation checks when a proposal changes code. Include those checks in the governance scope rather than treating the upgrade as an opaque administrative action.

Delegation and borrowed voting power

Voting balances and token balances need not be identical. A token may track delegated votes, historical checkpoints or a distinct governance unit. The review must identify the unit actually counted and how transfers, delegation and supply changes affect it. A token described as a governance token may not even contain the proposal executor.

OpenZeppelin's governance guidance uses past voting snapshots to retrieve power rather than relying on the current balance. That distinction addresses reuse and movement of voting weight around a proposal. The implementation still needs compatible clocks and checkpoint behavior across its token and governor.

Test delegation as a state transition. Moving tokens after delegating should not leave the original voting weight available where the model says it must move. Redelegation and signature-based delegation introduce additional inputs and authorization checks. A successful ordinary vote test will not exercise all of those transitions.

The fixed report sample provides a concrete disclosure example: 0xGuard's Boltr-Farm report names a delegation double-spend concern and records removal of the voting mechanism as the response. That is a historical finding and remediation record. It does not establish that the current project retains the same mechanism or that an attacker exploited it.

Borrowed voting power requires a time model. A past snapshot can prevent power acquired later from affecting that snapshot, but it does not automatically defeat an actor who acquires power earlier and holds it through the required period. Distinguish an atomic flash loan from longer financing and from an ordinary concentrated holder. The audit should state which threat each rule addresses.

OpenZeppelin voting checkpoints explains the reference model. The Boltr-Farm report supplies the project-level delegation example.

Timelock bypass via privileged roles

A timelock delays only the operations that must pass through it. Trace the target's permissions to determine whether an administrator, guardian or another controller can execute the same action directly. The existence of a timelock contract is not evidence that it governs every treasury or upgrade path.

Identify who can propose, execute and cancel operations, then follow who can change those roles. A governance-controlled target may also retain an original deployer or a separate owner. An emergency exception may be intentional, but its scope and decision process need to be visible in the authority model.

The notice period should support a specific user protection. If users are expected to exit before a risky change, verify that exit remains possible during the delay. A pause can remove that opportunity. Likewise, a change to the target's implementation can alter what a queued operation does without changing the target address.

PeckShield's BabySwap report discusses ownership-related functions bypassing an expected timelock delay. This kind of finding is useful because it connects the bypass to a reachable function rather than merely recommending that a project add a timelock. Read its historical scope before transferring the observation to another deployment.

Include cancellation and recovery in the model. If the only authorized executor becomes unavailable, the system may lose a necessary operating path. If a canceller can indefinitely block a proposal, that is a censorship capability to document. Neither behavior is inherently a defect without the intended governance policy, but both affect the authority users rely on.

Voting decision

Historical power rules.

Delayed operation

Required authority path.

Target state

No alternate bypass.

PeckShield's BabySwap assessment is the concrete report example. Use the admin authority inventory to compare these code paths with the operating team's actual permissions.

Treasury multisig verification

A treasury wallet may execute a community decision without the vote itself being enforced by the wallet. That distinction is especially important when off-chain voting serves as a signal and a multisig carries out the result. The security model includes the signers' procedure, the wallet configuration and every alternate execution route.

Beanstalk current disclosure page, as retrieved for this review, describes community voting with execution by its community multisig. It also documents broad powers and limitations. This later operating model should not be retroactively used to explain the April 2022 on-chain governance exploit. The same protocol name can refer to different authority configurations over time.

Verify the wallet on the intended chain. Record its implementation, owners, threshold and enabled extensions. Safe modules can execute transactions through their own authorized route, while guards can restrict execution and create a recovery dependency. A threshold readout alone omits those parts of the model.

Then review how the decision reaches the signing interface. Signers need a readable payload and an independent way to compare it with the proposal. A trustworthy-looking interface is not a cryptographic binding between a forum discussion and a treasury transfer. Preserve the exact action approved by the required operators.

The review should also cover what happens when the vote and the operating constraints conflict. An off-chain process may require signers to reject an obviously compromised result. If that discretion exists, document it as a trust assumption with an owner. Do not claim that the wallet mechanically enforces a rule that actually depends on human judgment.

Safe module documentation and Safe guard documentation explain why extensions belong in the treasury review.

Our report sample: governance wording is not execution coverage

Governance, delegation, quorum, timelock or voting wording appeared in 15 of 50 freshly retrieved reports. The matching reports came from 10 of the 17 sampled archives. These counts describe text disclosure; a token overview or a timelock identifier can match without documenting a review of proposal execution.

Method

Retrieved

September 5, 2026

Member frame

23 firms in the fixed research roster, including historical names.

Report frame

155 previously sampled archive entries.

Selection

The first 3 entries per firm from the earlier deterministic archive sample, fetched again for this study. No content-based selection.

Readable denominator

50 selected reports.

Archive coverage

17 sampled archives.

Cap exclusions

105 report entries excluded before reading.

Missing archive coverage

6 firms have no report in this frame.

Signal

Case-insensitive term matching in converted report text. Exact expressions and surrounding text are retained in the output.

Results

We therefore used separately read project findings for the delegation and timelock examples. The automatic total should not be interpreted as 15 audited DAOs or 15 governance vulnerabilities.

Limits

• The frame includes multiple languages, non-contract assessments and older reports. It is a disclosure sample, not a random sample of deployed protocols.
• A matching term may be a checklist item, a library identifier or a project finding. Only separately reviewed examples support finding-level conclusions.
• Archive ownership does not establish report authorship. Some archives contain outside assessments of the archive owner's software.
• No live exploit was executed. An absent match can reflect terminology or text extraction and cannot establish that a firm lacks the capability.

Reproduction uses seo/research/security-scope-disclosures-survey.py; its dated output is seo/research/security-scope-disclosures-survey-2026-09-05.json. These files remain in the repository and are not published as downloads. The output preserves source responses, retrieval outcomes and the selection rules for later verification.

What a governance audit covers

The scope should follow authority from acquisition of voting power to the last state-changing call. Include token checkpoints, proposal construction, voting and counting rules, execution controls and the treasury or upgrade target. Where part of that route is operational, name the separate evidence required.

Define acceptance around the protocol's intended rules. The reviewer should be able to state who can create a proposal, when power is measured, what makes the proposal executable and which account ultimately performs it. Any alternate route to the same target should have an explicit disposition.

Request evidence for failure paths as well as normal execution. A batched proposal may revert, an oracle-dependent action may become invalid before execution or a wallet guard may block the transaction. The response should preserve accounting and leave a documented route to cancellation or recovery where the design requires one.

A governance audit cannot establish the quality of every future community decision. It can examine the rules and interfaces through which those decisions become authority. The team still needs a process for reviewing each material payload, especially when it introduces new code or dependencies.

Use the threat-model workbook to specify the goals and assumptions. The audit scope builder and Halborn analysis help prepare a provider discussion around evidence rather than a governance label.

The historical cases leave a practical standard for the current release: preserve the link between the power counted, the action approved and the code executed. When those differ, investigate the specific boundary. Calling a process decentralized does not answer which account or payload can move the assets.