# Multisig treasury operations: verify the transaction and every path around the threshold Canonical: https://www.web3sec.news/blog/multisig-treasury-security-runbook Author: Raiders (https://www.web3sec.news/about) Format: guide Topic: Treasury & signing Published: 2026-11-08 Updated: 2026-11-08 An operating runbook for signer independence, privileged transactions, modules, monitoring and recovery rehearsal. ### Diagram: Verify transaction meaning outside the interface. A trusted-looking signing screen is not proof of the action being signed. ![A transaction proposal must be independently decoded and compared with intended chain, destination, value, function and permissions before the signer authorizes it on a trusted device. The signing interface alone is insufficient evidence.](https://www.web3sec.news/diagrams/signing-verification.svg) [Full-size SVG](https://www.web3sec.news/diagrams/signing-verification.svg) · [PNG download](https://www.web3sec.news/diagrams/signing-verification.png) Original explanatory control model; not a reconstruction of private incident evidence. ## Inventory authority on-chain and off-chain Assign the treasury a business owner and an operational signer coordinator. Record chain, wallet address, implementation, owners, threshold, modules, guards, recovery mechanisms and assets. Verify that information against chain state through an independently selected source. Safe documents owners and thresholds, but also modules that can execute their own transaction logic. Counting owner addresses without inspecting extensions can miss a separate authorization path. Record who controls each signer, its recovery material and its device environment. Look for correlated failures: several signers using one password vault, the same administrator laptop or a shared browser interface. Keep recovery locations and secret material outside the public inventory. Independence is an operational property to demonstrate, rather than an assumption created by using several addresses. ## Review semantics before signatures Create an approved transaction manifest containing chain ID, source wallet, nonce, destination, value, operation type and decoded calldata. Require explicit treatment for delegate calls, owner or threshold changes, implementation changes, modules and token approvals. Compare the intended business action to the full effects. A zero-value transaction can still grant spending authority or change control of the wallet. Use independent construction or verification for high-impact actions, and confirm what the signing device actually displays. A simulation is useful evidence but has assumptions about state, dependencies and the code presenting its result. Our procedure is to stop when any signer cannot reconcile the manifest with what they are asked to approve. Do not resolve discrepancies by encouraging blind signing under time pressure. ## Connect monitoring to an executable response Monitor execution, owner changes, threshold changes, module activity, significant approvals and unexpected asset movement. Record a responder for each signal and identify the actual pause or containment capabilities of the protocol and wallet. Do not assume that a multisig can reverse a completed transfer or that an alert can stop a transaction already included on-chain. If a signer device is compromised, stop pending signing activity, preserve relevant device and proposal evidence and assess signatures already produced. Rotate authority using the wallet’s supported procedure and trusted signers. Review enabled modules and token permissions as well as owners. Any emergency asset movement needs its own careful authorization; a rushed move through the same compromised frontend can compound the incident. ## Practice with a low-value replica Create a test wallet mirroring the operational setup without production funds or recovery secrets. Propose a normal transfer, an unexpected destination and a privileged module change. Verify that signers detect the exceptional action and that monitoring records it. Test an unavailable signer and the intended recovery path. Track whether the team can recover without reducing the threshold outside its approved policy. Repeat after owner turnover, new modules, wallet migrations and changes in signing applications. Keep a known-good inventory and a documented decision process for moving between operating and emergency modes. Completion evidence includes verified current authority, independent transaction review, an acknowledged alert and a recovery exercise that preserves the intended security boundary. ## Controls to take away - Multiple signatures can share a single compromised interpretation. - Modules and recovery mechanisms need their own authority review. - An alert needs a realistic containment action and an owner. ## Working checklist Assign owners and record supporting evidence in your team's system. - [ ] Verify owners, threshold, modules and guards on-chain. - [ ] Identify shared signer-device and recovery dependencies. - [ ] Review a complete transaction manifest before signing. - [ ] Monitor privileged configuration changes as well as transfers. - [ ] Rehearse rejected transactions and signer loss on a test wallet. ## Sources & further reading - [Safe: smart account owners, thresholds and transactions](https://docs.safe.global/advanced/smart-account-concepts) - [Safe: modules and alternative transaction logic](https://docs.safe.global/advanced/smart-account-modules) Incident facts are attributed to the linked reports. Recommendations are Web3Sec's analysis. [Research methodology](https://www.web3sec.news/methodology) · [Editorial policy](https://www.web3sec.news/editorial-policy) · [Send a correction](https://www.web3sec.news/contact)