Safe Multisig Monitoring: Owner, Module and Guard Alerts

By Owen Thurm Published November 6, 2026 6 min read

Quick answer. Alert on every Safe configuration event, such as AddedOwner, RemovedOwner, ChangedThreshold, EnabledModule, ChangedGuard and ChangedFallbackHandler, and on module executions and delegatecalls outside your allowlist. Also watch proposals and signatures before execution, the nonce, and each signer's own address.

Watch: Safe Multisig Monitoring: Owner, Module and Guard Alerts 1:41

Video transcript

A Safe's threshold sets how many owners must sign. It cannot check what they sign, or what else can act on the Safe.

Start with the signer set. Alert on every owner and threshold change, and on the ratio. Three of five becoming three of seven is weaker.

Modules are the blind spot. Safe's own code calls them a security risk. A module executes with no owner signatures. The only check is that it is enabled.

Treat an enabled module as Critical, and check each module execution against its purpose. Alert on every guard change, and rate a fallback handler change High.

Delegatecalls run the target's code on the Safe's own storage. The implementation lives in slot zero, so one delegatecall can replace it.

In February 2025, signers of Bybit's cold wallet saw a masked interface and approved a malicious upgrade, run through a Safe delegatecall.

No owner, module or guard event has to fire. Flag delegatecalls outside your allowlist, prefer MultiSendCallOnly, decode every batch, and watch slot zero.

Most of the risk is visible before execution. Watch proposals, signatures and the nonce: a proposal far ahead, two proposals at one nonce, or a nonce that moves with no proposal.

Guardian's Managed Security watches multisig transactions on every block, and an engineer responds when an alert fires. Read the full guide, or talk to Guardian.

A Safe's threshold sets how many owners must sign. It cannot check what they sign, or what else can act on the Safe.

Owners, modules, guards and the fallback handler all shape what the Safe will do. Changes to them emit events, and transactions proposed through Safe's service are visible before they execute.

This guide lists the alerts to set and what to do when one fires. Event names come from Safe's v1.4.1 contracts.

For the signer policy behind them, see our multisig best practices.

Owner and Threshold Changes

Three events in Safe's OwnerManager cover the signer set:

Event	Emitted by	Alert when
AddedOwner	addOwnerWithThreshold, swapOwner	Any new owner without an approved change
RemovedOwner	removeOwner, swapOwner	Any removal; check how many owners remain
ChangedThreshold	changeThreshold, or an add or remove that moves it	Any decrease, or a threshold below policy

A swap emits RemovedOwner, then AddedOwner, with no threshold event. Read the pair as one change: one key out, a new key in.

Adding an owner emits ChangedThreshold only if the threshold moves. So also alert on the ratio: a 3-of-5 that becomes 3-of-7 is weaker, with no threshold event.

Indexers can miss events. Read the owner list and threshold from the contract on a schedule, and compare them with the state you expect.

Treat every owner event as Critical unless it matches a change your team approved in advance.

Modules, Guards and the Fallback Handler

Modules

Safe's own code is blunt: "Modules are a security risk since they can execute arbitrary transactions."

A module executes with no owner signatures, and it can use delegatecall. The only check is that the caller is an enabled module.

EnabledModule: Critical unless pre-approved. A new party can now act without signatures.
DisabledModule: High. Confirm the removal was planned.
ExecutionFromModuleSuccess and ExecutionFromModuleFailure: every module action, checked against that module's purpose.

Safes deployed with the SafeL2 contract also emit SafeModuleTransaction, with the target, value, data and operation.

Guards

A guard runs checks before and after each owner-signed transaction. In v1.4.1, module transactions skip it.

Alert on every ChangedGuard. A new guard can block your next transaction. A guard set to the zero address removes checks you relied on.

Safe v1.5.0 adds a module guard for module transactions. Setting it emits ChangedModuleGuard: alert on that too.

Fallback handler

The Safe forwards calls it does not implement to its fallback handler. A ChangedFallbackHandler event means the Safe now answers those calls differently.

Rate it High, and check the new address against the handler your team approved.

Delegatecalls and the Implementation

Every Safe transaction carries an operation: 0 for a call, 1 for a delegatecall. A delegatecall runs the target's code inside the Safe, on the Safe's own storage.

That storage holds the implementation. Safe's proxy keeps the singleton address in storage slot 0, so one delegatecall can replace the logic behind the Safe.

On February 21, 2025, Bybit's Cold Wallet 1 executed a Safe transaction with operation 1, Etherscan shows. Our Bybit hack breakdown has the full story.

Bybit's CEO said every signer saw a masked interface showing the correct address, Rekt reported. What they actually approved, Rekt wrote, "was a wallet implementation upgrade containing malicious code."

A delegatecall writes storage directly, so no owner, module or guard event has to fire. Alert on the operation itself:

Alert on any delegatecall whose target is not on your allowlist.
Allowlist batching libraries by address.
Prefer MultiSendCallOnly: it reverts if a batched call uses delegatecall. MultiSend allows them.
Decode every batch, and alert on each inner call.
Read storage slot 0 after every execution, and alert on any change.

On a SafeL2 deployment, the SafeMultiSigTransaction event carries the operation, data and nonce. On other Safes, decode the execTransaction input.

Pending Transactions and the Nonce

Most of the risk is visible before execution. Safe's Transaction Service collects signatures offchain and informs owners "about a pending transaction to be sent to the blockchain."

Safe's events service turns that into webhooks. Its event types include:

PENDING_MULTISIG_TRANSACTION: a new proposal.
NEW_CONFIRMATION: a new signature on a proposal.
EXECUTED_MULTISIG_TRANSACTION and DELETED_MULTISIG_TRANSACTION.
MODULE_TRANSACTION.
NEW_DELEGATE, UPDATED_DELEGATE and DELETED_DELEGATE.

For each proposal, send the decoded target, function, value, operation and nonce. Post each confirmation with the count against the threshold.

Watch the nonce

Each owner-signed execution raises the nonce by one, and every signature covers the nonce. Module transactions leave it alone. Three patterns need an alert:

A proposal far ahead of the current nonce: a pre-signed approval waiting its turn.
Two proposals at one nonce: one replaces or cancels the other. Confirm which the team intends.
The nonce rising with no matching proposal: signatures were gathered elsewhere. Treat it as Critical.

Also alert on ApproveHash. Safe's code notes: "The approved hash stays approved forever." Executing another transaction at that nonce retires it.

If the Safe queues into a timelock, SEAL says to monitor every queue, execute and cancel. Alerts should fire at once, with "decoded calldata and a countdown to the execution window."

Signers, Channels and Response

Watch each signer's own address. SEAL's multisig framework says monitoring should "detect unauthorized use of signer keys outside the multisig context."

TRM Labs advises an immediate alert on any EIP-7702 delegation on a treasury wallet. Apply the same rule to signer addresses.

Then protect the alerts. SEAL says channels must be immutable, or alert when their configuration changes.

They must also be redundant, so an admin cannot disable one channel without the other raising an alert.

When an alert fires

Alert	First moves
Unexpected proposal	Reach signers out of band. Nobody signs. Replace it at that nonce.
Owner or threshold change	Treat it as a signer compromise. Rotate with trusted keys.
Module enabled	Disable it. Pause the contracts the Safe controls.
Guard or handler changed	Confirm with signers. Revert through an approved transaction.
Delegatecall or slot 0 change	Page everyone. Pause downstream contracts. Call SEAL 911.

For the full runbook, see what to do when a multisig signer is compromised. To catch the bad transaction at the signing step, see how to verify a Safe transaction before signing.

Most monitoring platforms can watch these events. Our monitoring tools comparison covers the options.

How Guardian Helps

Guardian's Managed Security monitors your contracts on every block: privileged calls, role and ownership changes, upgrades, multisig transactions and large fund movements.

Monitors are customized to your protocol and run alongside out-of-the-box detectors. When something fires, a Guardian engineer responds.

Guardian maps the keys, signers and multisigs behind every path to your funds. Its security operations team reviews every multisig transaction before it is signed.

An OpSec audit reviews how transactions are proposed, checked and signed, and what a signer actually sees before approving.

Frequently Asked Questions

What events does a Safe emit when its owners change?

AddedOwner, RemovedOwner and ChangedThreshold. A swap emits RemovedOwner, then AddedOwner, with no threshold event. Adding or removing an owner emits ChangedThreshold only if the threshold changes.

Why are Safe modules a monitoring priority?

A module can execute transactions without owner signatures, including delegatecalls. The only check is that the module is enabled. Alert on every EnabledModule and on every module execution.

Is every delegatecall from a Safe malicious?

No. Batching through Safe's MultiSend libraries uses delegatecall. Allowlist the libraries you use, decode every batch and alert on any other target. The Bybit cold wallet transaction of February 2025 was a delegatecall.

Can I see a Safe transaction before it executes?

Usually. Safe's Transaction Service holds proposed transactions and offchain signatures, and its events service sends a webhook for each. Signatures gathered elsewhere will not appear there, so also alert when the onchain nonce moves unexpectedly.

Sources

Put an engineer behind your Safe alerts

Guardian reviews every multisig transaction before it is signed, and responds when a monitor on your Safes fires.

Talk to Guardian Explore Managed Security