Multisig and Safe: Securing Crypto with Multiple Signatures

Understand M-of-N multisig, the difference between Bitcoin and Safe on EVM, and how to verify what you sign to avoid a repeat of the $1.5 billion hack of 2025.

Security · Avancé · 11 min read · Publié le

The essentials

This guide is general information for educational purposes, and not investment, legal or tax advice.

The M-of-N principle

A multisig is described with two numbers: M, the minimum number of signatures required, and N, the total number of authorized keys. People say "2-of-3," "3-of-5," and so on.

In a regular wallet, a single private key (derived from your seed phrase) is enough to spend everything. If it's stolen, everything is lost; if it's lost, everything is locked. Multisig spreads that power:

  • Against theft: an attacker who obtains a single key can do nothing in a 2-of-3.
  • Against loss: in a 2-of-3, losing one key doesn't stop you from spending with the other two, then migrating to a new setup.
  • Against error or unilateral decisions: in a team, no single person can move the funds alone.

Choosing M and N is a trade-off. An M that's too low (1-of-3) provides almost no protection against theft. An M equal to N (3-of-3) turns every lost key into a permanent lockout. Setups like 2-of-3 or 3-of-5 are common precisely because they tolerate both a compromised key and a lost key.

Two technical families: Bitcoin and smart contracts

Bitcoin's native multisig

On Bitcoin, multisig is written into the transaction script. Bitcoin's developer documentation describes the standard case: a redeem script listing the public keys and the threshold, for example 2 keys out of 3, checked by the OP_CHECKMULTISIG instruction. Today, this script is wrapped (P2SH, then its SegWit variants): the address doesn't reveal the setup until the funds are spent.

Practical points on the Bitcoin side:

  • Signers pass around a partially signed transaction in PSBT (Partially Signed Bitcoin Transaction) format, which each hardware wallet signs in turn.
  • There is no contract to deploy: the multisig address is computed from the public keys.
  • Changing the setup (adding a key, changing the threshold) means creating a new multisig and moving the funds into it.
  • Critical point for recovery: to rebuild the wallet, you need to know all the co-signers' extended public keys (xpubs) and the exact configuration, not just M seeds. Two seeds out of three are not enough if you've lost the third xpub. Hence the importance of backing up the wallet "descriptor" (the file describing the configuration) with each seed.

Smart-contract wallets on EVM: the Safe example

On Ethereum and EVM-compatible networks, a regular account (EOA) can only have one key. Multisig is therefore implemented by a smart contract: a program deployed on the blockchain that holds the funds and applies its own rules. Safe (formerly Gnosis Safe) is the most widespread implementation, and serves as the illustration here.

According to Safe's documentation, a Safe account contains:

  • a list of owners, which are Ethereum addresses;
  • a threshold: the minimum number of owners who must confirm a transaction before it is executed, adjustable between 1 and the total number of owners;
  • optional modules, which add features and can execute transactions without going through signature verification;
  • optional guards, which perform checks before and after each transaction.

A major advantage over Bitcoin: owners and threshold can be changed by a transaction of the Safe itself, without moving the funds. In exchange, security also depends on the contract's code, its modules and the web interface used to prepare transactions.

CriterionBitcoin multisigSafe (EVM)
SetupComputed address, no deploymentContract to deploy (fees)
Changing signers or thresholdNew wallet + transferTransaction from the Safe
Risk surfaceSimple, well-tested scriptsContract, modules, web interface

Setups suited to each situation

An individual on their own

A 2-of-3 with three hardware wallets, ideally from different brands, kept in separate places (home, a second safe location, a vault). You sign day to day with two devices; the third serves as backup. Each seed is backed up separately from its device, and each backup comes with the full configuration (xpubs or addresses of all signers).

A family

A 2-of-3 where one key is held by you, one by a trusted relative, and one kept in a safe place. This structure makes inheritance easier (see the guide on inheritance): the relative can't do anything alone, but with the backup key will be able to access the funds when the time comes. Write a procedure that someone who isn't technical can understand.

A team or an association

A 3-of-5 (or more) where each signer uses their own dedicated hardware wallet, never shared. Define in writing who proposes, who verifies and who executes, and plan for a member leaving: the first action after a departure must be to remove their address and, if necessary, adjust the threshold.

A rule common to all these setups: no single person and no single location should hold M keys at once. Two seeds in the same drawer turn a 2-of-3 into a plain wallet.

Verify before you sign: lessons from the February 2025 hack

What happened

On February 21, 2025, a major centralized exchange had about $1.5 billion of assets stolen, a theft the FBI attributed to North Korea (activity designated "TraderTraitor"). The funds were in an Ethereum "cold wallet" protected by a Safe multisig.

According to NCC Group's technical analysis, the signers believed they were approving a routine transfer to a hot wallet. In reality, the web interface used to prepare the transaction had been compromised and showed them a misleading version. The signed transaction used a delegatecall operation (which runs another contract's code in the context of the Safe) to a malicious contract. That contract replaced the address of the code used by the Safe with that of a contract controlled by the attacker, who then drained the wallet: more than 400,000 ETH, in addition to other assets. The analysis stresses that the signers signed blind, trusting what the web app displayed rather than what their device showed.

The Safe foundation said the origin was the compromise of one of its developers' machines, and that external audits had found no flaw in its smart contracts.

What to take from it

The multisig wasn't "broken": all the required signers did sign. The weak point was verification. If every signer trusts the same screen, compromising that screen is enough.

Verifying the hash, step by step

Each Safe transaction is summarized by a hash (a unique cryptographic fingerprint, computed according to the EIP-712 standard from a "domain hash" that identifies the Safe and the network, and a "message hash" that describes the transaction). This hash, or its components, is what most hardware wallets display when you sign.

  1. Get the details of the proposed transaction: recipient, amount, data ("calldata"), operation type, nonce.
  2. Recompute the hash independently, on another machine or with a different tool than the interface that proposed the transaction. Open-source tools exist for this, such as the safe-tx-hashes-util script, which computes the three hashes from the parameters.
  3. Compare the recomputed hash with the one shown on the hardware wallet's screen, character by character on at least the beginning and the end.
  4. Check the operation type: a delegatecall to a contract you don't know should stop you from signing.
  5. Check the nonce: it must match the next expected transaction, with no gap or duplicate.
  6. Decode the data: a "transfer" whose data calls another function, or an unexpected change of owners, is a warning sign.

Ideally, at least two signers do this check independently, with different computers.

The costs of a multisig

  • Bitcoin: a multisig transaction contains several signatures and the script, so it is larger and costs more in fees than a simple spend. There are, however, no creation fees.
  • Safe: according to Safe's help center, creating a Safe is free but activating it (deploying the contract) requires paying fees in the native asset on each network. Each transaction execution then costs gas, more than a simple transfer from a regular account. On Ethereum mainnet, these fees can weigh on small amounts; on a layer 2, they are generally much lower.
  • Human cost: each operation requires coordinating several people and devices. That's by design, but it makes multisig poorly suited to frequent small spends.

Recovery and migration

  • A lost key in a 2-of-3: on Safe, the other two signers immediately replace the lost address. On Bitcoin, the other two sign a transfer to a new multisig. Don't wait: until the key is replaced, you have no margin for error left.
  • A potentially compromised key: same procedure, urgently, before the attacker obtains a second key.
  • Multi-network on Safe: a Safe can have the same address on several networks, but it must be deployed on each. Safe's help center warns that some networks, such as zkSync Era, don't allow the same address: funds sent on that network to the address of a Safe existing elsewhere would be lost. Always check that your Safe exists on the destination network before sending.
  • Test recovery: do a trial with a small amount, rebuilding the wallet from your backups on a blank device.

A concrete example

Claire wants to protect savings in bitcoin and ETH. She chooses a 2-of-3 with three hardware wallets from two different brands.

  • Device A at her home, device B at her sister's, device C in a bank vault. Each seed is written on a medium separate from its device, in a different location.
  • On the Bitcoin side, she exports the wallet descriptor (the three xpubs and the 2-of-3 configuration) and stores a copy with each seed. She checks on each device's screen that the first receiving address is identical.
  • On the Ethereum side, she creates a Safe on a layer 2 with the three addresses and a threshold of 2, then first sends a small test amount.
  • For every outgoing transfer, she prepares the transaction, recomputes the hash on a second computer, compares it with the screen of device A and then device B, and signs only if everything matches.

Six months later, device B is lost during a move. Claire uses A and C to replace B with a new device on the Safe, and transfers her bitcoin to a new 2-of-3 multisig.

Mistakes to avoid

  • Storing M seeds in the same place: this cancels the whole point of multisig.
  • Forgetting to back up the xpubs (Bitcoin): without the full configuration, even the right seeds may not be enough.
  • Signing blind: trusting the web interface instead of reading the hardware wallet screen and recomputing the hash.
  • Accepting an unknown delegatecall or a change of owners that nobody announced.
  • Using the same computer for all signers: a single compromised machine is then enough to fool everyone.
  • Adding modules without understanding them: on Safe, a module can execute transactions without the owners' signatures.
  • Sending funds on a network where the Safe isn't deployed, or on a network that doesn't allow the same address.
  • Never testing recovery before you need it.

Key takeaways

  • An M-of-N multisig requires M signatures out of N keys; the 2-of-3 tolerates both a stolen key and a lost key.
  • On Bitcoin, multisig is native and simple, but any change requires a new wallet; back up all the xpubs.
  • On EVM, Safe is a smart contract: signers and threshold are changeable, but the contract, modules and interface add risks.
  • The February 2025 theft ($1.5 billion) exploited a compromised interface and blind signing, not a flaw in the multisig principle.
  • Independently recompute each transaction's hash and compare it with your hardware wallet's screen before signing.
  • Spread keys and backups across separate locations, and test recovery with a small amount.

Sources

Compare services related to this topic