Safe Modules and Guards for Treasury: Power and Its Containment

Modules are what make a Safe treasury more than a shared button — recurring payroll, automation, recovery. They are also how a treasury gets drained when nobody contained them. This guide is the module/guard model and why modules change what reconciliation must capture.

TL;DR

• Modules extend a Safe (recurring payments, automation, recovery) — powerful, but can execute outside the signer threshold.
• Guards validate/block transactions by rule; Module Guards (v1.5.0) specifically validate module-initiated txs.
• A guardrail/allowlist layer blocks unauthorized delegatecalls.
• An over-privileged/compromised module is a real risk surface — govern it like a signer change.
• Reconciliation must capture module-executed txs as first-class events (see #138) — not just signer-approved transfers.
• Guards = on-chain containment; policy controls + accounting are separate layers.

What Modules do

A Module is a smart-contract extension that can execute transactions on a Safe under its own logic — beyond plain multisig approval. That unlocks recurring payments, automation, recovery flows. The treasury consequence is double-edged: modules add genuine utility, but a module can act without the normal signer threshold. An over-privileged or compromised module is therefore a real risk surface — the power has to be contained deliberately.

What Guards do

A Guard is a contract that can validate or block a transaction by rule before it executes. Safe introduced Module Guards (in v1.5.0) specifically to validate transactions initiated by third-party modules, reducing the risk from a compromised or misbehaving add-on. A separate guardrail/allowlist layer blocks unauthorized delegatecalls. Guards are the containment for the power modules introduce — the on-chain "this is not allowed" layer.

Why modules are a reconciliation problem

This is the part treasuries miss. Because module-executed transactions can occur outside the normal signer-approval path, a reconciliation process that only expects signer-approved transfers will miss or mis-attribute module activity. Treasury accounting must capture module-initiated transactions as first-class events, attributed to the module and its purpose — or the books will not reconcile to on-chain reality (the decomposition/completeness discipline, applied to modules).

Governing modules

Treat enabling a module as a privileged change, like a signer change:

• review the module's scope and code;
• minimise its privileges (least privilege);
• pair it with Guards / Module Guards / allowlists;
• document who can enable/disable modules;
• audit module activity continuously.

Least privilege plus containment plus an auditable record — the same rigor as managing signers.

Three layers, not one

Guards do not classify or reconcile transactions, nor replace policy or the audit trail. A treasury needs all three.

Practical guidance

1. Inventory enabled modules — know exactly what can execute outside the threshold.
2. Apply least privilege to every module; review scope and code.
3. Pair modules with Guards/Module Guards and allowlists.
4. Govern enable/disable as a privileged, documented change.
5. Reconcile module-initiated txs as first-class events, attributed to the module.
6. Keep on-chain containment, policy, and accounting as distinct layers.

How vendor tools handle module activity

Cryptio and Bitwave reconcile Safe activity including module-initiated transactions. Confirm the tool captures module-executed txs (not signer-approved only), attributes them to the module/purpose, and keeps the audit trail — a reconciliation that assumes signer-only flows silently drops module activity.

How Wag3s helps

Wag3s Ledger ingests Safe activity including module-initiated transactions, attributes them to the module and purpose, and reconciles them to on-chain reality with an audit trail — so module automation does not become an accounting blind spot. See the Ledger product page and the Wag3s for accountants page.

Further reading

• Safe Treasury Setup Best Practices
• Multisig Signer Policy and Recovery
• Multisig Treasury Policy Controls
• Multisig Treasury Reconciliation (Safe)
• Crypto Audit Trail and Piste d'Audit Fiable
• Multi-Sig Treasury Accounting

Sources

• Safe — Modules execute transactions under their own logic (beyond multisig approval); Guards validate/block transactions; Module Guards (v1.5.0) validate module-initiated transactions; guardrail/allowlist layer blocks unauthorized delegatecalls
• Module-initiated transactions can occur outside the signer-approval path (reconciliation must capture them as first-class events)
• On-chain containment (guards), operational policy controls, and accounting/reconciliation are distinct complementary layers