DAO Treasury Multisig Risk: Signer Drift and Timelock Bypass

1. "N-of-M multisig plus timelock" is state, not a constant

Most DAO treasury security narratives follow the same template: funds are held in an N-of-M multisig, any transfer requires reaching the signature threshold, and major actions pass through a public timelock window that gives the community time to react or object. This narrative feels reassuring precisely because it sounds like a rule baked into the code that never changes after launch. The reality is different: multisig contracts (Safe, formerly Gnosis Safe, being the dominant implementation) expose standard functions — addOwner, removeOwner, swapOwner, changeThreshold — and both the signer set and the threshold number are mutable state that can be altered at any point in the contract's lifetime by any transaction that reaches the currently required threshold, not constants frozen at deployment. The timelock itself works the same way: it is usually a separate TimelockController contract or governance module, and whether the treasury multisig actually routes every fund-moving action through it, or leaves a side path around it, depends on the specific permission wiring, not on the mere fact that "a timelock is used." Treating treasury security as equivalent to the architecture description from launch day, without continuously re-checking current on-chain state, is the first reason multisig risk gets underestimated.

2. Signer drift: from the original multisig roster to today's actual owners

At launch, a DAO treasury multisig's signer roster is usually accompanied by a public statement — for example "held by 5 core contributors and 2 community representatives" — that typically ends up in the project's docs or website along with specific addresses. Signers do change over time: core members leave, community representative terms expire, an address gets swapped out after a lost key or a security incident, and all of this is normal, necessary governance activity. The problem is whether the replacement itself is disclosed with the same visibility — often a signer swap is just an on-chain swapOwner transaction paired with an easy-to-miss forum post, while the "who holds the keys" copy on the project's own site is rarely updated to match. The check is to call owners() directly on the treasury multisig contract to pull the currently effective address list, then compare each address against the identity and role described in official docs, flag any address added recently with no corresponding governance discussion you can find, and flag any originally disclosed key signer that has quietly disappeared from the list with no public explanation. The bigger the gap between the roster and the disclosure, the further "who actually controls the treasury" has drifted from what the community believes.

3. Threshold quietly lowered: from a real majority to a small handful

The threshold determines how many signatures are needed to execute a treasury transaction, and it's the single most direct numerical measure of the multisig's security model — a 7-signer multisig set to 4-of-7 means at least a genuine majority must collude or be compromised to move funds; if the threshold drops to 2-of-7, the security margin falls off a cliff, since only two colluding signers or two simultaneously leaked keys are enough to drain the treasury. changeThreshold is just another ordinary multisig transaction that executes once the current threshold is reached, which means even when a threshold change goes through a full governance vote, there is still a window between the vote passing and the change actually executing — worth checking that the execution transaction really corresponds to that vote, rather than being bundled quietly into an unrelated batch operation. The concrete check: periodically query getThreshold() on the multisig contract and compare against the last recorded value; if it has changed, trace back the executing transaction hash and confirm it matches a proposal that went through a full, findable governance discussion on the forum or proposal platform; a threshold reduction with no traceable governance record at all is itself a signal that warrants immediate scrutiny.

4. Emergency modules: a bypass door opened for a smaller subset of signers

The value of a timelock lies in the window it gives the community to spot a problem and organize opposition, but plenty of DAO treasuries, out of concern for handling genuinely urgent incidents, deploy an additional Emergency Module — or a similar Zodiac-style module — that can be attached to the multisig via enableModule, letting a smaller "security council" or "emergency multisig" execute actions like pausing a contract, freezing assets, or switching an implementation address, skipping the standard timelock entirely. This design isn't inherently unreasonable — genuinely urgent scenarios do exist, and relying purely on the standard timelock might be too slow to respond to an attack already in progress. The risk is that once this bypass door exists, details like how broad the "emergency" permission scope actually is, which addresses hold it, and whether the trigger threshold has been independently verified, often get far less transparency than the main timelock does. The check is to query the multisig's currently enabled module list (via getModulesPaginated or an equivalent interface), verify the contract code and permission scope for every non-empty module address, judge whether its executable action set is strictly limited to genuine emergency response (like pausing) versus effectively equivalent to a full fund transfer, and cross-check whether the address set holding signing power over this emergency module fully overlaps with the main treasury's signers, or is actually a smaller, more concentrated subset.

5. Read all three checks together — passing any one alone proves nothing

Checking owners, threshold, or the module list in isolation can each individually come back "looks fine," but the real risk in a treasury usually shows up in the combined state of all three. A pattern worth watching for: the signer roster matches the official disclosure exactly, the threshold has never changed, yet a recently and quietly enabled emergency module has its trigger authority limited to just 3 of the 7 signers — in which case the standard 4-of-7 threshold narrative no longer reflects the real attack surface, since actual control of the treasury may rest with just those 3 addresses. Conversely, even with no emergency module in play, if the owners list contains several recently added addresses that show signs of being linked (funded from the same source, deployed in the same window), that alone warrants suspicion of signer concentration or even a single entity controlling multiple nominally-independent signer identities. The correct sequence is to pull the current owners, threshold, and module list as raw on-chain state first, cross-reference each against official disclosures and governance records, and finally check for any combination that creates a gap between the "nominal threshold" and the "actual minimum signatures required" — skipping any one step can miss the real risk.

6. Before trusting a treasury multisig, confirm these first

Before evaluating any DAO treasury, voting in its governance, or judging whether a given pool of funds is safe, it's worth confirming: whether the multisig contract address is publicly known and whether an independent block explorer or Safe management UI lets you call owners() and getThreshold() directly to verify current state; whether the project maintains a continuously updated signer roster page, versus one that was published once at launch and never touched since; whether the history of threshold and signer changes traces back to matching governance proposals, or only shows on-chain transactions with no discoverable discussion behind them; whether an emergency module or similar bypass path exists, and if so, whether its permission scope and holder set have been separately and publicly disclosed; and whether any monitoring or alerting exists that is independent of the project team, capable of surfacing changes to owners, threshold, or the module list as they happen rather than relying on the team to self-report. If these questions can't be answered right now, there is likely a gap — one you haven't found yet — between this treasury's actual security model and the one it advertises.

7. Summary and verification checklist

• An N-of-M multisig plus timelock is not a constant fixed at deployment — owners, threshold, and any timelock bypass path are all mutable state that later transactions can change.
• Signers drift: verify the actual addresses returned by owners() against the officially disclosed roster, and flag additions or disappearances with no governance record.
• Thresholds can be quietly lowered: confirm every historical getThreshold() change traces back to a full, discoverable governance proposal.
• Emergency modules can bypass the standard timelock: check the permission scope and holder set of any enabled module against the main treasury's actual threshold.
• No single check is sufficient — cross-reference the combined state of owners, threshold, and module list together, not one at a time.
• Before trusting a treasury, confirm the signer roster is kept continuously public, changes are traceable, and monitoring independent of the project team exists.

FAQ: Once set, do a multisig's threshold and signer set stay fixed? No — they are mutable contract state, changeable by any transaction that reaches the current threshold, so they need continuous re-verification rather than trusting the description from launch. Does an emergency module automatically mean something is wrong? Not necessarily — genuinely urgent scenarios exist; what matters is whether its scope and holders get the same transparency and verification standard as the main timelock. What's the fastest way to check a treasury multisig's real current state? Call owners(), getThreshold(), and the module-query interface directly on the multisig contract address via a block explorer or the Safe management UI — all of this is public, readable on-chain data. This discusses abstract mechanics only, names no specific DAO or project, and is not investment advice — use your own judgment and take responsibility for your own decisions.