Step 1: Read What the Transaction Actually Does
Before any key touches a multisig transaction, read its content in plain language: which contract it calls, which method it runs, and what the arguments do. A screen showing raw hexadecimal is not a reading, it is a guess, and the whole routine that follows exists because that guess is where losses start.
Every transaction to a contract carries a payload: the target address, the function it will call, and the parameters. In raw form it is hexadecimal, and the small screen of a signing device often shows exactly that. Reading it means getting the payload translated into words, so that what you approve is a sentence and not a blob.
Safe{Wallet} Monitor does this translation as its first job: it takes the transaction content and translates it into clear, human-readable explanations of what the call will do. The point of the step is not the tool; it is the standard. A transaction whose effect you cannot state in one sentence is not ready for your signature.
The reason this step comes first is written into the largest loss of 2025. In the February 2025 Bybit incident, close to 1.5 billion dollars left the exchange after the interface presented a transfer while the transaction actually performed a contract upgrade. The attacker had deployed and tested the malicious contract two days early. The keys did their job. The reading never happened. The Cybersecurity and Infrastructure Security Agency documents this class of supply chain and interface deception in its advisories.
Step 2: Test the Transaction Before You Sign
Reading tells you what the transaction says it will do; a test run shows what it will actually do. Run the transaction in a sandbox that executes it against a copy of chain state and report the results: which balances move, which permissions change, which contracts end up different. Then compare that report with what you intended.
A payload can be honest looking and still wrong, because the real effect of a contract call only shows up when it runs. The test does not publish anything; it executes the transaction against a sandbox copy of the chain and returns the aftermath. If you thought you were approving a routine withdrawal and the report shows a delegatecall into a fresh contract, you have your answer before signing rather than after.
Safe{Wallet} Monitor includes this as its risk check and transaction test step: it checks transactions against risk rules and runs the action to expose what would happen. For the routine, what matters is the order: read first, test second, and treat any mismatch between the two as a stop signal, not a curiosity.
Step 3: Bring In Someone Who Is Not Signing
The third check belongs to a person who is not one of the signers. Push the translation and the test result to a non signer, and get their read before the final signature lands. The failure this prevents is social, not technical: the second signer trusts the first, the third trusts the second, and nobody in the chain actually looked.
Multisig concentrates a subtle risk: the signature sequence itself invites deference. If the routine is sign, sign, done, then the M in M of N is decoration, and the wallet is effectively single sig with extra steps. A non signer who receives the decoded transaction and the test outcome, and who answers back with agreement, breaks that chain of trust at exactly one removed.
This is why Safe{Wallet} Monitor pushes its alerts through several channels at once, aimed at signers and non signers both. A message to a phone, a message to a workstation, delivered by routes an attacker would have to control all at once to silence. The design assumption is blunt and correct: in a targeted attack, one compromised device should not be enough to complete a blind approval.
Step 4: Set Guardrails for Routine Operations
The last layer is standing rules that act without waiting for anyone. A whitelist limits which contracts your wallet may interact with, and any change raises an alert. Automatic response rules can transfer funds to backup accounts or pause contracts when the risk check flags harm. Together they turn the routine from read everything, every time, into check the exceptions.
A whitelist is the boring version of safety: the small set of contracts you actually use, recorded, with every attempt to add or swap one flagged for review. Most weeks, nothing knocks. The week something does, the alert is the whole story. The National Institute of Standards and Technology frameworks treat this layered approach, defense in depth with automatic responses, as the baseline shape of a serious control setup.
The warning layer stays on throughout, in the window that matters. An alert can arrive after a risk is found but before signing finishes and before the transaction reaches the chain. That is the only window in which a stop is still possible. Guardrails do not replace the reading and the test; they catch what slips past tired humans at 2 a.m.
A Worked Example: Signing an Upgrade
Walk the four checks through a contract upgrade. Read the translation and see the target. Test the run and watch the permissions change. Send both to a non signer and wait for their reply. Check the whitelist for the new contract, then sign. Total extra minutes: a few. What it would have caught: the largest crypto theft to date.
| Check | What it catches | In the upgrade example |
|---|---|---|
| Read the translation | A target or method that is not what was described | The call shows an upgrade, not a transfer |
| Test the run | Effects that only appear when it executes | Permissions change on the contract |
| Non signer review | Deference along the signature chain | A second reader questions the change |
| Guardrails | Contracts outside the whitelist | The new contract is not on the list |
Upgrades are the scenario worth rehearsing because they are legitimate, they are rare, and they concentrate power: the transaction that upgrades a contract can change everything that contract does next. It is also the exact shape of the Bybit case, where a disguised upgrade passed as a transfer. The scale is not hypothetical, either: by March 2025, Safe accounted for more than 39.14 million created wallets holding around 54.9 billion dollars (per BlockSec), so the routine protects a lot of real value.
The honest close is the same one the family keeps repeating. These four checks lower the risk on the operation side: what you sign, read, tested, and confirmed. The security of your devices, your signing setup, and your backups remains its own work. What Is Blind Signing in Crypto? and Multisig Wallets cover that ground. The tool behind the routine is on the Safe{Wallet} Monitor page, and the wallet risk hub maps the whole family.