“DAO Treasury Multisig,” “ExecutionSuccess,” and Governance Attack News: Lessons for DAO Governance Consultancy

Summary: The safest DAOs treat a treasury multisig as an instrumented, policy‑enforced machine—not a wallet. This guide turns recent governance‑attack news and on‑chain event telemetry (“ExecutionSuccess,” module events) into a concrete blueprint you can apply today.

Why this matters now

In 2025–2026, DAO treasuries crossed tens of billions in value, while a new wave of governance incidents reminded everyone that “votes” are only as safe as your execution paths and monitoring. Compound’s 2024 proposal controversy, Tornado Cash’s 2023 governance hijack, and multiple “zombie‑DAO” drain attempts show how easily a single rushed weekend vote, inattentive delegates, or misconfigured modules can put nine‑figure war chests at risk. (coindesk.com)

This post distills what 7Block Labs recommends to founders, CFOs, and protocol leads designing or hardening DAO treasury operations on EVM chains—using Safe (formerly Gnosis Safe), Zodiac modules, and modern monitoring.

Part 1 — “ExecutionSuccess” isn’t just a log line: it’s your ground truth for treasury actions

If your DAO uses Safe for its treasury multisig, every on‑chain execution emits an event. The two you’ll live by:

ExecutionSuccess(bytes32 txHash, uint256 payment) — emitted when a standard multisig transaction is executed. Topic0: 0x442e715f626346e8c54381002da614f62bee8d27386535b2521ec8540898556e. You can see it on any Safe tx log page on Etherscan; many major DAO treasuries (e.g., Frax) emit this on execution. (pkg.go.dev)
ExecutionFromModuleSuccess(address module) — emitted when a module executes a transaction “on behalf of” the Safe (bypassing owner signatures). This is critical for governance pipelines that use modules to automate execution. (gnosisscan.io)

Why you should care:

These events are the most reliable “source of truth” that money moved or authority was exercised. They are the hooks you alert on in your SIEM, and the breadcrumbs auditors will follow. Safe’s Events Service and API streamline this for you. (github.com)
The distinction between owner‑signed ExecutionSuccess and module‑initiated ExecutionFromModuleSuccess is the difference between “humans signed this” and “automation executed this.” Your guardrails and alerts should differ accordingly. (gnosisscan.io)

Practical telemetry checklist

Wire the following event/topic monitors across your treasury Safe(s):

ExecutionSuccess and ExecutionFailure — page the on‑call if value or token approvals exceed preset policy. (pkg.go.dev)
ExecutionFromModuleSuccess/Failure — track the module address; alert if it’s not in your allowlist. (gnosisscan.io)
ChangedThreshold, ChangedGuard, ChangedModuleGuard — configuration drift alarms; these three events tell you if your signing rules or guards silently changed. (docs.safe.global)
EnabledModule/DisabledModule — modules can take over your Safe; treat enable/disable as a critical change. The Safe contracts themselves warn that a malicious module can completely take over a Safe. (gnosisscan.io)

Tools that make this easy

Safe Transaction/Events Service for normalizing txs and webhooks. (github.com)
OpenZeppelin Monitor (Defender is moving to maintenance mode; migrate monitors) with Slack/Telegram/PagerDuty notifications and policy filters. (docs.openzeppelin.com)

Part 2 — What recent governance attacks actually teach us

Tornado Cash (May 2023): A “look‑alike” upgrade proposal with hidden logic gave an attacker 1.2M fake votes and temporary, total control over governance. They withdrew and sold governance assets; later, a proposal restored control. Lesson: bytecode‑level diffs and simulation are required; never trust descriptions alone. (cointelegraph.com)
Compound (July 2024): A whale‑backed proposal to direct ~$24M in COMP into a controlled yield wrapper passed on thin turnout; the community and market makers called it a governance attack and the plan was walked back. Lesson: weekend quorums and dormant delegations are liabilities; introduce structural brakes and participation SLAs. (coindesk.com)
Indexed Finance DAO (Nov 2023): A neglected “zombie DAO” nearly lost its remaining ~$90K via a self‑paying proposal; only public blackmail exposure stopped it. Lesson: even tiny or dormant treasuries are targets; build wind‑down guardrails and spending caps. (blockworks.co)
Arbitrum (2023): The AIP‑1 omnibus and 700M ARB treasury politics weren’t an “attack,” but showed what happens when off‑chain intent, treasury control, and multisigs fall out of sync. Lesson: split “coin and state” cleanly; bake transparency about what is already executable. (coindesk.com)

Two positive counter‑examples

ENS DAO: created a Security Council (4‑of‑8 Safe) with a narrowly scoped veto to cancel malicious proposals, plus a professionally managed endowment with public performance metrics. This pairs community votes with an emergency brake and disciplined treasury management. (basics.ensdao.org)
Optimism Collective: published a Multisig Security Policy for council‑managed multisigs, formalizing standards for membership, dissolution, and security as they move more treasury actions on‑chain. (gov.optimism.io)

Part 3 — Designing a DAO treasury multisig that resists real‑world failures

Principle A — Separate “coin” and “state”

Balancer’s 2025 proposal is the model: split governance power from asset custody so a governance executor can’t accidentally—or maliciously—reach every asset. This reduces blast radius and lets you optimize operational spends without compromising governance latency. (forum.balancer.fi)

Concrete split:

Governance Safe: controls protocol upgrades and the list of modules/guards, but holds minimal assets.
Treasury Safe(s): hold assets; only accept actions from an allowlisted “executor role” via modules/guards; never accept delegatecall.
Working‑Capital Safes: capped daily limits; separate signers and keys for grants/ops.

Principle B — Enforce policy in both planes (owner‑signed and module‑executed)

Modern Safe supports Guards and Module Guards. Use both so every execution path is policy‑checked: “no delegatecall,” “only these selectors/targets,” “per‑day cap,” etc. Your risk model should assume a module might be misconfigured or upgraded. (docs.safe.global)

Principle C — Serialize with delay and human veto

Timelocks and Delay Modifiers (Zodiac) add a cooldown between proposal pass and execution; pair them with a limited Security Council that can cancel during the window. ENS’s approach is a pragmatic balance. (github.com)

Principle D — Make off‑chain signal binding the right way

Snapshot is convenient but off‑chain; if you rely on it, you still need manual execution—an attack window. If you must use Snapshot, run it through a hardened execution pipeline such as Zodiac Reality (arbitrated) → Roles/Delay → Safe, and keep human kill‑switches for truly extraordinary cases. (daotimes.com)

Principle E — Know exactly what you’re alerting on

Configure monitors that trigger on:

Any ExecutionFromModuleSuccess where module ∉ allowlist OR selector ∉ policy. (gnosisscan.io)
ChangedThreshold < baseline, ChangedGuard/ChangedModuleGuard to 0x0 (disabled), or any new EnabledModule. (docs.safe.global)
ERC‑20 approvals from the treasury to unknown spenders or unlimited approvals; these often precede drains and can be blocked by guards. (docs.openzeppelin.com)

Principle F — Publish and practice the runbook

A great config still fails without muscle memory. Write your incident playbook and rehearse it quarterly:

Disable module X, restore guard Y, raise threshold to N, revoke approvals on token Z, pause upgrade proxies, and move excess liquidity to cold Safe.
Assign who pages which signer in which time zone and how you rotate keys post‑incident.

Part 4 — A hardened reference architecture (2026‑ready)

Below is a production‑grade configuration we deploy for clients managing $25M–$1B treasuries on Ethereum + L2s.

Control plane

Governance Safe (3‑of‑5)
- Owners: 5 independent entities (e.g., Foundation, top delegates, ecosystem orgs), all hardware‑wallet backed.
- Modules: none by default.
- Guards: Transaction Guard enforcing “no asset moves >$10k” and “no delegatecall.”
- Responsibilities: upgrades to guards/modules; permissioning the Execution Role address only.

Asset planes

Treasury Safe (4‑of‑7)
- Modules:
  - Roles Modifier with a single “proposal_executor” role. Allowlist only:
    - stablecoin.transfer/approve to vetted counterparties,
    - protocol‑approved staking/unstaking calls,
    - Multisend from known address,
    - cap max outflow per 24h.
  - Delay Modifier: cooldown 24–48 hours; expiration 7 days.
- Guards:
  - Transaction Guard: blocks delegatecall, unknown ERC‑20 approvals, approvals > N days, re‑entrancy‑prone targets.
  - Module Guard: mirrors Transaction Guard checks for module calls.
- Monitoring:
  - Webhooks for ExecutionSuccess/Failure and ExecutionFromModuleSuccess/Failure with policy filters.
  - Drift monitors for ChangedThreshold/ChangedGuard/ChangedModuleGuard; EnabledModule/DisabledModule.
- Off‑ramps:
  - Cold Safe (3‑of‑5) for long‑term holdings with zero modules; only batched, timelocked moves.

Governance bridging and veto

“Security Council” Safe (4‑of‑8) with a single power: cancel malicious queued txs (not propose). Document scope, conflict‑of‑interest policy, and sunset review. ENS’s public write‑up is the model. (basics.ensdao.org)

Automation and observability

Safe Events/Transaction Service for decoding and webhooks; OpenZeppelin Monitor for alerts and automated response playbooks (e.g., auto‑raise threshold or auto‑revoke approvals on suspicious patterns). Note: Defender’s legacy “Sentinel” product is being migrated—use Monitor going forward. (docs.safe.global)

Organizational guardrails

Signer SOP: all signers on HSM‑backed or hardware keys, no browser extensions on signing laptops, mandatory passkeys/MFA on dashboards.
Rotation: quarterly rotation drill; document “prevOwner” for Safe owner list changes; use CLI tooling (Ape‑Safe) to programmatically verify state before/after. (docs.apeworx.io)

Part 5 — Emerging practices you can adopt in Q1

“Coin vs. State” separation as policy

Balancer’s “Separation of Coin and State” proposal captures the philosophy: stop trying to optimize governance speed and capital safety in one place; do the split, then tune each side for its job. We now recommend this split for every treasury >$5M. (forum.balancer.fi)

Delegation health checks and quorum design

Compound’s scare showed how inactive whales invite weekend surprises. Add auto‑redistribution of delegated voting power after N missed votes (social or code, depending on your stack), increase quorums for treasury moves, and avoid short voting windows. Uniswap’s 2024 RFC is a good template for discussing veto councils and proposal staking to raise attacker costs. (coindesk.com)

Formalizing multisig standards

If your ecosystem has many council‑managed safes, adopt a published Multisig Security Policy the way Optimism did (membership, dissolution, reporting). It makes audits and incident response faster and removes ambiguity. (gov.optimism.io)

Endowment‑style treasury with controlled risk

ENS’s endowment shows how to turn idle assets into a predictable runway without surrendering control: public IPS, professional asset managers via Safe, limited veto council for emergencies, and monthly performance disclosures. If your DAO relies on cyclical fees, this stabilizes budgets. (basics.ensdao.org)

Module hardening

Treat modules as privileged code. Safe’s own docs and comments warn that a malicious module can take over a Safe. Audit modules, lock versions, forbid delegatecall from modules via guards, and alert on any EnabledModule/DisabledModule change. (gnosisscan.io)

Part 6 — Turn governance “news” into execution safeguards

Translate incident patterns into concrete controls:

Hidden‑logic or “identical except” proposals (Tornado Cash 2023) → require bytecode diffs and two independent simulations attached to any executable proposal; enforce a minimum cooldown before ExecutionSuccess is even possible. (cointelegraph.com)
Low‑engagement + whale control (Compound 2024) → raise quorums for treasury‑impacting actions, extend voting periods over weekdays, and add proposal staking or “No with Veto” to punish spam or self‑dealing. (coindesk.com)
Zombie‑DAO drains (Indexed 2023; small treasuries) → add default spending caps, wind‑down playbooks, and auto‑archive modules when activity drops below threshold. (blockworks.co)
Off‑chain votes without binding execution (Snapshot) → either move to on‑chain voting with timelocks or interpose Reality/Delay/Roles and a veto council to narrow the gap between signal and spend. (daotimes.com)

Part 7 — Step‑by‑step: instrumenting your Safe today

Index your Safe

Confirm it’s a Safe proxy (masterCopy) and version; as of 2025, Safe v1.5.0 is widespread. (ethereum.stackexchange.com)

Ship event monitors (1 hour)

Start with ExecutionSuccess/Failure and ExecutionFromModuleSuccess/Failure. Pull topic hashes from Safe ABIs or SDKs to avoid copy errors. (pkg.go.dev)
Add ChangedThreshold, ChangedGuard, ChangedModuleGuard, EnabledModule/DisabledModule monitors. Wire to Slack + PagerDuty. (docs.safe.global)

Enforce policy (half‑day)

Install a Transaction Guard and Module Guard to enforce:
- allowed targets/selectors,
- max per‑tx and per‑day outflows,
- ban delegatecall and unknown ERC‑20 approvals.
Test with a dry‑run Safe and try to violate your own rules. (docs.safe.global)

Serialize execution (1 hour)

Add Delay Modifier with 24–48h cooldown; pair with a Security Council limited to canceling malicious queues. (github.com)

Publish the runbook (half‑day)

Document exact calls to raise threshold, disable modules, setGuard/setModuleGuard back to known addresses, and revoke top‑risk approvals. Use Ape‑Safe to programmatically verify state before/after changes. (docs.apeworx.io)

Appendix — Notes for enterprises and regulated entities

Legal wrappers: Large treasuries like Uniswap have explored formal legal structures for governance participation and treasury operations (e.g., Wyoming DUNA) alongside funding programs; if you’re a U.S. entity, coordinate your treasury architecture and legal wrappers early. (coindesk.com)
Programmatic transparency: Publish a live dashboard that visualizes ExecutionSuccess events, module activity, and configuration changes; most delegates won’t parse logs but will respond to clear signals.
Cross‑chain consistency: Mirror the guard/module policy on each L2 Safe; don’t let “side treasuries” drift.

The punchline

DAO governance isn’t “voting,” it’s secure policy execution. If you monitor the right events (“ExecutionSuccess” and module executions), separate coin from state, and enforce policy in both execution planes with delays and vetoes, governance attacks become noisy, slow, and costly for adversaries—and survivable for you.

If you want 7Block Labs to pressure‑test your current setup, we typically start by:

simulating your last 90 days of ExecutionSuccess/ModuleSuccess activity against a policy model,
running a guard/module misconfiguration audit,
drafting a split‑plane architecture and incident runbook tailored to your treasury profile.

Because the best time to harden your multisig was before the vote. The second‑best time is now.

Sources and further reading

Safe events and execution logs: Etherscan examples; Safe Events/Transaction Service and docs. (etherscan.io)
Module and guard mechanisms, and critical change events. (gnosisscan.io)
Delay/Reality/Zodiac patterns and risks. (github.com)
Governance incidents and policy responses: Tornado Cash 2023; Compound 2024; Indexed 2023; Uniswap RFC on attacks; Optimism multisig policy; ENS Security Council and Endowment metrics. (cointelegraph.com)
“Separation of coin and state” (Balancer BIP‑850). (forum.balancer.fi)
Off‑chain voting risks (Snapshot). (daotimes.com)