Safe multisig as a treasury control: what auditors will ask to see

How Safe owners, thresholds, modules and the transaction service work, and how to turn approvals into internal-control evidence.

2026-10-17 · 6 min read

If your treasury sits in a Safe, the approval rule written into the contract is one of your most important financial controls. Treat it like one: document who can sign, how many must agree, what can bypass them, and keep the history that proves it worked.

How a Safe works

A Safe is a smart contract account rather than a wallet controlled by one private key. It has a list of owners and a threshold: the number of owners who must confirm a transaction before it can execute [1]. A two-of-three Safe needs any two of three owners; a three-of-five needs three of five.

The contract itself enforces sensible limits. The threshold must be at least one and cannot exceed the number of owners [4]. Changes to the owner list or the threshold are made through dedicated functions such as adding, removing or swapping an owner and changing the threshold, and these can only be called by the Safe itself [4]. In practice that means a signer change is just another Safe transaction that has to clear the existing approval rule.

Each of those changes emits an on-chain event, for example when an owner is added or removed or the threshold changes [4]. That gives you a tamper-resistant change log for your signer list.

Modules and guards: the parts that change the control

Modules are optional contracts that extend what a Safe can do, such as spending allowances, recurring payments or recovery schemes [1][2]. They matter for control design because a module can execute transactions without going through the normal owner confirmations. Safe's own documentation warns that modules can run arbitrary transactions and that a malicious module can take over a Safe [2].

Guards work the other way. A guard is a contract that checks a transaction and can reject it based on its own logic [1]. Used well, a guard adds restrictions on top of the owner threshold. Used badly, a faulty guard can block legitimate access to the Safe [1].

For a controller, the lesson is simple: the threshold alone does not describe the control. Any enabled module is a second path to move funds, and any guard is a rule that sits in front of the first path. Both belong in your control narrative.

The transaction service and approval history

Safe operates a Transaction Service, an API that tracks transactions sent through Safe accounts, lets owners collect signatures off-chain before anything is broadcast, and keeps records of pending and completed transactions [3]. This is where proposals wait while signers review them, and it is a convenient source for approval history: who proposed a payment, who confirmed it, and when.

Keep in mind that off-chain signatures collected before execution are records held by a service, while the executed transaction and owner-change events live on the blockchain. A robust evidence pack reconciles the two.

Why this is internal-control evidence

COSO's 2020 paper on blockchain applied the Internal Control — Integrated Framework to blockchain risks and noted that the technology creates new risks and the need for new controls, even as it can reduce some errors [5]. A multisig maps naturally onto familiar control objectives: authorization (a payment needs approval by the required number of people) and segregation of duties (no single person can move funds alone).

Auditors look closely at private keys because ownership of digital assets follows control over the keys; one CPA firm's guidance stresses confirming that the entity has exclusive control, and notes the extra complexity when multiple keys are needed to authorize a transaction [8]. The AICPA's training on its digital asset practice aid covers testing controls and audit procedures for self-custodied assets, alongside existence and rights and obligations [7].

If you use a third-party custodian or signing provider, its SOC 1 report becomes relevant. A SOC 1 examination covers controls at a service organization that are likely to be relevant to its users' internal control over financial reporting [6], and auditors commonly request such a report and assess the controls it describes [8]. A self-hosted Safe has no SOC 1 behind it, so the evidence has to come from you.

Signer rotation and leavers

Signer rotation is where good multisig set-ups most often drift. Staff leave, devices are replaced, and the signer list quietly stops matching the org chart. Because swapping an owner needs a Safe transaction under the existing threshold [4], plan rotations before people leave, not after. Remove access promptly, record who approved the change, and confirm the on-chain owner list afterwards.

Also check the threshold after each change. Removing an owner from a three-of-five Safe leaves three-of-four, which is still workable; removing two leaves three-of-three, where one lost device can lock the treasury.

What to do

• Keep a signer register per Safe: owner address, named individual, role, device type, date added, approver.
• Reconcile the register to the contract's owner list and threshold at each month-end.
• Inventory every enabled module and guard, who approved it, and whether it was audited; disable what you do not need.
• Export approval history for the period and retain it with the executed transaction hashes.
• Write down key management: hardware devices, backups, recovery and the leaver process.
• If a provider signs or hosts on your behalf, obtain its SOC 1 report and map its complementary user controls to your own.

Sources

1. How do Safe Smart Accounts work? (Safe)
2. Safe Modules (Safe)
3. Safe Transaction Service API (Safe)
4. OwnerManager.sol (safe-smart-account repository) (Safe (GitHub))
5. Evaluating blockchain and internal control through a COSO lens (Journal of Accountancy (AICPA & CIMA))
6. SOC 1 - SOC for Service Organizations: ICFR (AICPA & CIMA)
7. Auditing Digital Assets: Considerations for Existence and Rights and Obligations (AICPA & CIMA)
8. The Key Considerations for Auditing Digital Assets and Cryptocurrencies (CBIZ)

General information for finance teams, current as of publication. Not legal, tax or accounting advice.

All Newsroom explainers