Multisig Best Practices in 2026: Verify What You Sign

In almost every headline multisig theft of the last two years, the cryptography did exactly what it was designed to do. The math held, the signatures were valid, the threshold was met, and the money still left. That is the uncomfortable through-line of 2024, 2025 and 2026: a multi-signature wallet is only as safe as the thing its signers can actually see, and for years they have been approving things they could not read. TRM Labs found that infrastructure, key and operational compromises made up only about 15% of hacking incidents in the first half of 2026 but roughly 76% of the stolen value, according to its H1 2026 report. The expensive failures are not exotic contract bugs. They are ordinary people clicking approve on a payload that was not what their screen promised.

This is not the first time HOGE Wire has covered multisig best practices, and it is deliberately not another generic checklist. The threshold math, the signer diversity, the geographic separation all matter, and this guide covers them. But if you fix only one thing about how your treasury signs, fix verification. Make it hard, ideally impossible, to approve a transaction whose real effect you have not independently confirmed. In 2026 that stopped being a manual chore for the paranoid and started becoming a shared standard, because the Ethereum Foundation and most of the major wallet makers finally shipped the missing piece.

Multisig Does Not Break; the Approval Does

A multisig wallet requires M of N signatures before a transaction executes. On EVM chains the dominant implementation is Safe (formerly Gnosis Safe), which by the end of the second quarter of 2026 secured about $27.24 billion in self-custodied assets across more than 63 million accounts and processed nearly 130 million transactions in the quarter, per the Safe Q2 2026 report. The security model rests on one assumption: that each signer independently reviews and approves the exact transaction that will run.

In practice that assumption breaks constantly. Signers approve a hash, or a friendly summary rendered by an interface, while the actual calldata (the target contract, the function selector, the packed parameters, or a delegatecall to an arbitrary module) does something else entirely. The scheme that verifies M signatures over a message is flawless. The failure is that the message the humans believed they were signing was not the message that executed. The attack surface moved off the chain and onto the screen, and that is where nearly every large loss now happens. Adding more signers to a system with this blind spot does not fix it; it just multiplies the number of people approving the same lie.

Seven Multisig Failures, One Root Cause

The pattern is easiest to see side by side. The table below collects seven of the most instructive multisig compromises of the current cycle. Notice what is missing from the root-cause column: not one of them turned on breaking a signature algorithm.

Five of these were linked to North Korea by investigators, yet the common thread is not a single threat actor; it is the gap between what a signer saw and what the chain executed, or the collapse of key custody onto a single point of failure. The last row is worth sitting with, because it is not a protocol at all but a private individual: the attacker drained a whale’s Safe and then held a leveraged borrow open on a lending market to dodge liquidation while cashing out slowly through a mixer. An audit would not have stopped most of these, because the deployed code did exactly what it was written to do, a point we explored in our coverage of the audit paradox. These are operational failures, not cryptographic ones, and they respond to operational fixes. Bybit has since sued North Korea and the Lazarus Group in US federal court and won a preliminary asset freeze, per CoinDesk, but recovery of stolen crypto remains the exception, not the rule.

Blind Signing: The Vulnerability Hiding in Plain Sight

Blind signing is the act of approving a transaction your device cannot fully decode. A hardware wallet stores your keys in a secure element and produces a signature, but it does not always know what it is signing. Ethereum transactions are ABI-encoded: a four-byte function selector followed by tightly packed arguments. To a human, and often to the hardware wallet itself, that is an unreadable string of hex. So the device does one of two things. It shows you the raw bytes, which almost nobody reads, or it shows you a friendly summary such as sending 100 USDC to an address. The catch is that this summary usually comes from the same software interface an attacker may already control.

That gives an attacker two clean paths. The first is to lie at the display layer: show the signer a routine transfer while the bytes underneath approve something else, which is precisely what happened at Bybit, WazirX and Radiant. The second is to exploit the opacity of the mechanism itself. A Safe transaction can wrap a delegatecall, which runs another contract’s code in the wallet’s own context; UXLINK’s attacker used exactly this to rewrite the owner set and then mint trillions of tokens. In both cases the signature was genuine. The signer just never saw the real transaction. The Ethereum Foundation put it plainly when it argued that approving a transaction is meant to be the last line of defense, and that “when it is done blindly, that defense does not hold,” in its Clear Signing announcement.

Clear Signing: The Standard Built to End Blind Approvals

The single most important development in multisig safety this year is not a new wallet or a new threshold rule. It is a standard. On 12 May 2026 the Ethereum Foundation, through its Trillion Dollar Security initiative, took stewardship of Clear Signing from Ledger and launched it as a shared, vendor-neutral effort, per its own announcement. Ledger had originated the idea as an internal security project in 2021 and formalized it as ERC-7730 in 2024; handing governance to the Foundation was meant to make it credibly neutral, so that no one company owns the labels your wallet trusts.

Clear Signing combines two ingredients. The first is a trusted screen: a hardware secure display the host computer cannot tamper with. The second is transaction understandability: structured metadata that describes the action being taken, the amounts in human units, the counterparties and contextual labels, so the screen can show intent rather than hex. The pieces that make this work as an open system are worth knowing by name:

• ERC-7730 is a JSON descriptor format that lets a contract describe its own functions in plain language, so a wallet can render “Approve 100 USDC for Uniswap” instead of raw calldata. It is a Draft standard, currently at version 2.0.0, authored by Ledger’s Laurent Castillo and Derek Rein among others, and it covers EVM calldata, EIP-712 messages, ERC-4337 user operations and EIP-5792 batches.
• A public registry stores and mirrors those descriptors, so the mapping from bytes to plain English is not controlled by a single provider and can be independently reproduced.
• ERC-8176 is an attestation framework that lets independent auditors cryptographically vouch that a descriptor accurately reflects what a contract does, which closes the obvious question of who wrote the label in the first place.
• ERC-8213 defines a calldata digest, a short reproducible fingerprint a signer can recompute on a separate device and compare, so two independent machines must agree before a signature is produced.

Version 2 of ERC-7730, released in 2026, widened coverage from Ledger-specific hardware to both hardware and software wallets, added cross-chain interactions, and made room for confidential-token use cases, according to Ledger’s write-up of the evolution. The working group now includes Ledger, MetaMask, Trezor, WalletConnect, Fireblocks, Cyfrin, Sourcify, Keycard, Zama and others. As Ledger framed it, clear signing is no longer a Ledger feature; it is becoming a shared standard. The Foundation set the bar bluntly: “What You See Is What You Sign” must be the goal, and Clear Signing must be the default.

One caution keeps this honest. Clear Signing is still Draft, adoption is partial, and a descriptor is only as trustworthy as the attestation behind it. A wrong or malicious label for a contract that has no attestation can still mislead a signer who has stopped checking. Clear Signing raises the floor dramatically, but it does not retire the discipline of verifying for yourself.

How to Verify a Transaction Before You Sign

Here is the routine that would have blunted the biggest thefts on the list above. It is not exotic, and it does not require a security team. It requires that you treat the moment of signing as a checkpoint rather than a formality, and that you do the same steps every time above a value you care about.

• Read the intent. If your wallet supports clear signing, confirm the described action, target contract, recipient and amount actually match what your team intended to do. If the wallet can only show a bare hash, treat that as a warning, not a green light.
• Simulate the transaction. Run it through a simulator such as Tenderly or Safe’s built-in simulation and read the resulting state changes, not just the word success. A transfer that also changes an owner or adds a module is telling you something. Remember the limit: a simulation runs against a node, and if your own machine is compromised, as Radiant’s signers learned, the simulation can be faked too. Necessary, not sufficient.
• Recompute the hash on a clean device. This is the step almost nobody does and the one that matters most. Independent tools such as Cyfrin’s clearsig and the community project SafeLens recompute the EIP-712 Safe transaction hash and domain separator offline, so a tampered front end cannot change what you are actually signing without changing the hash you compare against.
• Verify on the device’s own screen. The hardware wallet’s secure display is the one surface the host computer cannot rewrite. If the hash and details there do not match your independent recomputation, stop.
• Confirm out of band. Before the threshold is reached, signers confirm the exact hash and intent over a separate, authenticated channel: a live video call, or a signed message from a known key, never over the same interface or chat that proposed the transaction. Several incidents trace to a spoofed communication channel rather than the signing step itself, so the confirmation has to leave the compromised surface.

Write this down, make it mandatory above a set dollar value, and rehearse it. A verification routine that lives in one engineer’s head is not a control; it is a single point of failure wearing a lanyard.

Thresholds and Signer Diversity: Necessary, Not Sufficient

The structural rules still matter, and the Security Alliance (SEAL) publishes the clearest floor for them. Its secure multisig guidance recommends at least three signers and a threshold above 50%, seven or more signers for wallets holding over $1 million, and never an N-of-N arrangement where the loss of a single key freezes the funds forever. It also calls for different hardware wallet models and manufacturers, geographic separation of signers, keys held by different trusted people with at least one external signer, and a dedicated signing address for each multisig.

The trap is to read that as a headcount race. More signers is not linearly safer, because every signer is another laptop, another phone, another person who can be phished, and coordination gets harder as the number grows. Humanity Protocol had thresholds of 3-of-6 and 3-of-5 on paper, which sounds robust, yet those keys were backed up onto a single laptop, so one compromised device crossed both thresholds at once. The point of a multisig is diversity, not quantity: diverse people, diverse device brands, diverse locations, and diverse communication channels, so that no single failure can reach a threshold. Ethereum co-founder Vitalik Buterin has framed the same idea around the human layer, writing that the two key questions in using multisig and social-recovery wallets securely are, in his words, “(i) whom do you choose as guardians, and (ii) what instructions do you give them,” in comments reported by CryptoSlate. A 2-of-3 fits a small team; 3-of-5 or 4-of-7 suits a high-value treasury; a 12-of-15 with all keys in one office is theater.

The Device Is Not the Trust Anchor You Think It Is

Hardware wallets reduce risk, but they are not a finish line, and two lessons from this year make the point. The first is that a hardware wallet which can only blind-sign a hash gives you tamper-resistant key storage and zero transaction transparency. The Bybit signers used hardware wallets. Their keys were never extracted. They still approved the transaction that drained the exchange, because the device showed them something they could not meaningfully check.

The second lesson is that the device itself can be the flaw. A build-configuration error in Coldcard firmware from March 2021 silently weakened the randomness used to generate seeds, and in 2026 attackers drained roughly $116 million from more than 5,200 addresses by brute-forcing those weakened keys, without ever touching a single device, as documented by TRM Labs. The defensive reading is straightforward: use dedicated devices per multisig, keep a hardened or air-gapped signing machine, spread keys across different manufacturers so one firmware bug cannot compromise a whole threshold, and demand a device that clear-signs rather than blind-signs. Trusting the brand is not the same as trusting the specific firmware build in your hand.

Timelocks, Simulation, and Monitoring: Buy Yourself a Window

Even good signers make mistakes, and a good multisig assumes they will. The most underrated control is the timelock: a mandatory delay between when a transaction is approved and when it can execute. That gap is your chance to notice a malicious transaction and cancel it. Drift Protocol’s council migrated to a structure with zero timelock days before its theft, deleting exactly this window and turning a set of pre-signed transactions into an on-demand drain. A timelock on high-value actions, especially owner changes and module additions, is cheap insurance against your own worst day.

Simulation and monitoring close the loop. Simulate every meaningful transaction and read the state changes, keeping in mind the Radiant caveat that a compromised machine can return a clean-looking simulation. Then wire up on-chain monitoring that alerts, over an out-of-band channel, on the events that precede a theft: owner changes, threshold changes, new modules, delegatecalls, and large or unwhitelisted transfers. SEAL’s guidance treats active monitoring and alerting as a baseline, not a luxury. Whitelisting known destinations turns an unfamiliar recipient into a blocked action rather than a judgment call at two in the morning.

Rotation, Offboarding, and a Recovery Plan You Have Rehearsed

A multisig is not a set-and-forget object; it is an operational program. The Security Alliance formalized this in its SFC Multisig Operations certification, an open, auditable checklist across six areas: governance and inventory (a named owner and a maintained registry), risk-tiered controls, signer access control (a dedicated address per multisig, geographically distributed backups, quarterly access reviews and fast offboarding), operational procedures (independent verification across two separate interfaces and multi-year audit-trail retention), communication (encrypted, MFA-protected channels), and emergency operations (playbooks, reachability tests and drills).

Two habits carry most of the weight. Rotate keys after any suspected compromise and whenever a signer leaves; a former employee who still holds a valid key is a threshold you no longer fully control. And keep a written, rehearsed disaster-recovery plan for the day a quorum of keys becomes unavailable, or a compromise is suspected mid-transaction. Rehearse it on a schedule, because a recovery plan you have never actually run is not a plan, it is a hope with a document attached. The teams that recover fastest from an incident are the ones that practiced the bad day before it arrived.

Multisig or MPC: Matching the Tool to the Threat

Multisig is not the only way to split control of a wallet. Multi-party computation (MPC) takes a single private key, splits it into shares held by different parties, and lets them jointly produce one signature without ever reconstructing the whole key. To the chain it looks like an ordinary single-signer wallet. Each model has a distinct trust story, and the right choice depends on who you are and what you fear.

Safe frames the difference as multisig externalizing trust into verifiable code, while MPC internalizes trust into systems and infrastructure that cannot be fully verified on-chain, in its own comparison. Institutional custody providers tend to favor MPC for its speed and flexible key management, while multisig keeps the longer and more established on-chain audit trail. Neither is universally safer. A transparent protocol treasury benefits from multisig’s public auditability; a high-frequency trading desk may value MPC’s speed and quiet signer changes. The mistake is treating the choice as a status symbol rather than a threat-model decision.

When Multisig Is the Wrong Best Practice

The most counterintuitive best practice is knowing when not to use a multisig at all. After the Coldcard fallout sent a wave of individuals rushing to set up multisigs, Ledger’s chief technology officer Charles Guillemet pushed back, warning that “multisig is not automatically the right answer,” in remarks reported by U.Today. His argument is that added complexity, more devices, more backup seeds, more coordination steps, creates new failure points and can make recovery harder or even impossible. For many individuals a single, well-backed-up hardware wallet that supports clear signing is more robust than a fragile, poorly-run multisig, and Bitcoin users can look at Miniscript combined with MuSig2 as a middle path.

Cost is a real factor too. Some native multisig implementations layer their own fees on top of gas, and the added operational overhead of running a proper signing ceremony every time you move funds is not free either. A multisig that nobody wants to use gets bypassed, and a bypassed control is worse than none because it creates a false sense of safety. Match the structure to the threat model and the operational maturity of the people running it, not to whatever the last victim wishes they had done.

Who Pays When a Multisig Fails: The Regulatory Gap

None of Bybit, WazirX, Radiant, Drift or Humanity happened at an SEC-registered custodian, and that is not an accident. For US investment advisers, the Advisers Act Custody Rule (Rule 206(4)-2) requires a qualified custodian, and in late September 2025 the SEC’s Division of Investment Management issued guidance letting state-chartered trust companies qualify as bank custodians for crypto, conditioned on written key-management and cybersecurity policies, SOC-1 and SOC-2 audits, asset segregation, and no rehypothecation without consent, as summarized by law firm Hunton. Crucially, that guidance does not resolve whether assets held in a multisig or an MPC arrangement satisfy the Custody Rule at all. The regulatory perimeter and the technical reality do not yet line up.

For a self-custodied DeFi treasury or a private whale, there is no custodian and no regulator to make you whole. Your own signing routine is the entire safety net. And once funds move, recovery gets hard fast: as the December 2025 whale case showed, a mixer like Tornado Cash can break the trail within hours, which is why we keep returning to the uncomfortable math of getting stolen crypto back. Exchanges and licensed custodians that do hold client funds carry compliance obligations of their own, including the cross-border reporting we unpacked in our look at the crypto Travel Rule, but those regimes govern intermediaries, not the self-custody setups where most of these losses occur. If you run your own multisig, the buck stops at your verification process.

The 2026 Multisig Checklist

Pulling the practices together, the table below tiers the controls by how much value the wallet holds. It leans on the SEAL floors for structure and on the verification discipline for the parts that actually stop modern attacks. Treat the personal column as a minimum and the high-value column as the standard for anything meaningful.

The through-line of every row is the same: a multisig’s job is to make it hard to move money without genuine, independent human agreement, and that only works when the humans can see what they are agreeing to. Get the verification right and the rest of the checklist reinforces it. Skip verification and the rest is decoration.

Frequently Asked Questions

What is the single most important multisig best practice in 2026?

The single most important practice is to verify what you sign. Before you approve, independently confirm the real effect of the transaction: read the human-readable intent, simulate it, and where the stakes are high, recompute the transaction hash on a separate clean device and confirm it over a second channel. Most large multisig thefts came from signers approving a payload they could not see, not from broken cryptography.

Is a multisig safer than a single hardware wallet?

Not automatically. A well-run multisig removes single points of failure, but a poorly run one adds devices, backups and coordination steps that create new ways to fail. Ledger’s chief technology officer has cautioned that multisig is not automatically the right answer, and for many individuals a single, well-backed-up hardware wallet that supports clear signing is more practical than a fragile multisig.

What is blind signing and why is it dangerous?

Blind signing means approving a transaction your wallet cannot fully decode, so it shows you a raw hash or a summary supplied by a front end you have to trust. If that display is manipulated, as it was in the Bybit, WazirX and Radiant thefts, you sign one thing while a different transaction executes. Clear signing, which renders calldata in plain language on a trusted screen, is the direct answer.

How many signers should a multisig have?

Security researchers at the Security Alliance recommend at least three signers and a threshold above 50%, rising to seven or more for wallets holding over $1 million, and they warn against N-of-N setups where every signer is required. Diversity of people, devices, vendors and locations matters more than the raw number of signers.

Does Clear Signing (ERC-7730) fully solve the problem?

It helps a great deal by turning opaque calldata into human-readable descriptions and letting independent auditors attest to their accuracy, but it is still a Draft standard with partial adoption, and a description is only as trustworthy as the attestation behind it. Clear Signing raises the floor; independent verification remains best practice.

Anneke de Vries is HOGE Wire’s security desk editor.