Multisig Wallet Best Practices: The Complete 2026 Playbook

On February 21, 2025, Bybit signers approved a transaction they had checked, on a device they trusted, following a process the exchange had used for months. Roughly $1.5 billion in ether left cold storage minutes later, still the largest theft in crypto history. The multisig contract guarding those funds was never broken; its math held up perfectly. What failed was everything around the math: the interface the signers looked at, the machine that interface ran on, and the assumption that several people approving a transaction automatically means several people understood what they were approving. That gap between cryptographic security and operational security is where nearly every serious multisig loss since has happened, and it is why multisig best practices have become a board-level conversation rather than an engineering afterthought.

Why Multisig Best Practices Are Suddenly a Board-Level Issue

The numbers explain the urgency. TRM Labs tracked 207 separate hacks and exploits in the first half of 2026, the highest six-month count on record, even as total losses fell to roughly $972 million, according to the firm’s H1 2026 crypto crime report. Buried inside that report is the statistic that matters most here: infrastructure and operational compromises, the category that includes mismanaged multisigs, compromised signer devices and manipulated interfaces, accounted for only about 15 percent of incidents but roughly 76 percent of everything stolen. Smart contract bugs, the failure mode most security budgets are built around, made up the bulk of incident count and a small fraction of the dollar losses.

At the same time, the value sitting behind multisig wallets keeps growing. Safe, the dominant smart account standard on Ethereum and other EVM chains, processed nearly 130 million transactions in the second quarter of 2026 alone, a quarterly record, with $39.35 billion in transfer volume across every chain it supports, according to the Safe Ecosystem Foundation’s Q2 2026 report. More than 63 million Safe accounts now exist. Every one of them depends on the same handful of human decisions: how many signers, who they are, what devices they use, and how carefully they check what they are about to sign. Get those decisions right and a multisig is one of the most resilient custody structures available. Get them wrong and the smart contract’s guarantees are irrelevant, because an attacker never needs to break code that humans will approve for them.

How a Multisig Wallet Actually Works

A multisig (multi-signature) wallet replaces a single private key with a rule: M-of-N. A treasury might require any 3 of 5 designated signers to approve a transaction before it executes, or 4 of 7, or any other combination the owners choose. No single compromised key, lost device or rogue insider can move funds alone, at least in theory.

On Ethereum and other EVM chains, this is almost always implemented as a smart contract account rather than a property of one private key. Safe, formerly known as Gnosis Safe, is the dominant standard: signers submit and approve transactions through an interface, the contract checks that enough valid signatures have accumulated, and only then executes the underlying call. Bitcoin multisig works differently, using script-level M-of-N conditions enforced directly by consensus rules rather than a smart contract, but the operational logic is the same.

The detail that every incident in this article turns on is that signers do not sign the words send funds to address X. They sign a hash, a compact cryptographic fingerprint of the full transaction data. A hardware wallet’s small screen, or a software interface’s summary view, is supposed to translate that hash back into something a human can verify: destination, amount, function being called. When that translation layer lies, through malware, a compromised developer machine, or a manipulated front end, the signer approves something they never actually saw. Every major multisig loss covered below is a variation on that single failure.

The Uncomfortable Lesson From Bybit and Humanity Protocol

Two cases make the pattern unmistakable.

At Bybit, attackers compromised a developer’s machine at Safe, the multisig infrastructure provider, then used that access to inject malicious JavaScript into the Safe wallet interface itself, according to incident reporting from BleepingComputer, which traces the attack to North Korea’s Lazarus Group. When Bybit’s signers went to approve a routine cold-to-hot wallet transfer, the tampered interface displayed the transaction they expected while a different transaction, one handing control of the cold wallet’s underlying contract to the attackers, was what actually got signed. Every signer followed procedure. Every signature was valid. The keys were never stolen or cracked; the display layer between the signers and the blockchain lied to them.

Sixteen months later, Humanity Protocol lost roughly $36 million in a case that shows how a seemingly conservative threshold can be an illusion. The project’s bridge admin keys were nominally split 3-of-6 on Ethereum and 3-of-5 on BNB Chain, two separate thresholds that looked like defense in depth. In practice, several keys from both chains had been backed up to a single employee’s laptop. One compromised device crossed both thresholds at once, letting attackers drain roughly 141 million H tokens on Ethereum and mint another 200 million through an unlimited-mint function on BNB Chain. Founder Terence Kwok was unusually direct about the cause, telling CoinDesk that “some of the keys were accidentally backed up to a compromised device during setup.” On paper, Humanity Protocol had two independent multisigs. In practice, it had one laptop.

Neither case stands alone. India’s WazirX lost roughly $230 million, about half its reserves, in 2024 when a Gnosis Safe multisig’s signers approved a transaction that looked benign in their custody provider’s interface but carried a hidden payload, as Halborn’s incident analysis lays out. Months later, DeFi lender Radiant Capital lost roughly $50 million after developers were compromised through malware delivered via a decoy PDF on Telegram, letting attackers sign a malicious transferOwnership call while the Safe interface on the infected machines showed nothing unusual, per Halborn’s writeup of that case. And in April 2026, Solana perpetuals exchange Drift Protocol lost roughly $285 million after its security council was socially engineered into pre-signing transactions that only needed to be broadcast later, with no timelock in place to catch it, one of the North Korea-linked cases TRM Labs says drove most of H1 2026’s losses. The common thread across all of them: the multisig’s math was never the weak point.

Choosing a Threshold That Actually Means Something

The first practical decision in setting up a multisig is the threshold itself, and it is where SEAL, the security nonprofit built around Paradigm security lead Samczsun and a broad coalition of whitehat responders, has the clearest guidance. SEAL’s Secure Multisig Best Practices framework sets a firm floor: at least three distinct signers with a signing threshold of 50 percent or greater, and never an N-of-N configuration, where every single signer must approve every transaction. N-of-N looks maximally secure on paper, but it means one lost device, one signer who goes unreachable during an emergency, or one succession problem can freeze funds permanently. A threshold below half of N, meanwhile, means a minority of compromised or colluding signers could move funds without the rest finding out until after the fact.

Treasury size should scale the signer count, not just the ratio. SEAL recommends seven or more signers for any multisig holding upward of $1 million in assets, on the logic that a wider signer set makes both compromise and collusion harder to pull off quietly. The table below maps that guidance to rough treasury tiers; treat it as a starting point to adjust for individual risk tolerance and operational capacity, not a rule to follow blindly.

SEAL’s guidance does allow narrow exceptions to the 50 percent floor, but only for tightly scoped operations that are further restricted by smart contract safeguards, such as a role that can only pause a contract and can do nothing else. A general-purpose treasury multisig should not be treated as one of those exceptions.

Signer Selection: Diversity Is a Security Control, Not a Nicety

Picking a number is the easy part. Picking the right people, and making sure they are meaningfully independent of each other, is where most of the real security work happens. Vitalik Buterin has framed this as the central question of multisig design. “Two key questions in using multi-sig wallets and social recovery wallets securely are: (i) whom do you choose as guardians, and (ii) what instructions do you give them?” he wrote, in comments compiled by CryptoSlate. Signers who all work in the same office, use the same laptop model, back up seed phrases the same way, or take instructions from the same manager are not really independent, no matter what the on-chain threshold says. Humanity Protocol’s two independent thresholds collapsing into one laptop is what this looks like when it goes wrong.

SEAL’s framework translates that principle into concrete rules: assign keys to different trusted individuals rather than one person holding multiple signer slots; require geographic separation between the physical locations where keys and backup seed phrases are stored; and use diverse client software and hardware wallet models and manufacturers across the signer set, so a single vulnerability, vendor breach or supply chain compromise cannot take out a majority of signers at once. Each signer should also use a dedicated address per multisig, generated from a different hardware wallet index, rather than reusing one signing key across multiple treasuries or roles. It sounds like unnecessary friction until the alternative, one person’s compromised device controlling several protocols’ treasuries at once, actually happens.

Hardware Wallets Are Necessary, Not Sufficient

Hardware wallets are the standard recommendation for multisig signers, and for good reason: keeping a private key on an air-gapped or semi-air-gapped device makes remote malware dramatically less useful to an attacker. But a hardware wallet is only as trustworthy as its firmware, and a case that broke days before this article was written shows how that can fail at the manufacturer level, not the user level.

On July 30, 2026, Coinkite disclosed that a firmware bug in its widely used Coldcard hardware wallets had, since March 2021, routed private key generation through a weak software random number generator instead of the device’s secure hardware RNG. On affected Mk2 and Mk3 devices, seed generation was close to fully deterministic, derivable from the device’s own identifier and internal timer state. Newer Mk4, Mk5 and Q models fared better but still landed around 72 bits of real entropy instead of the 128 bits the design called for. Attackers who appear to have reverse-engineered the flaw drained about 1,367 BTC, worth roughly $88.6 million, from thousands of addresses across several waves, starting with 1,196 addresses emptied in the first 41 minutes, according to The Hacker News‘ reporting on the incident. Coinkite shipped patched firmware within about a day of disclosure, but as the company was careful to note, updating the firmware does not repair a seed that was already generated on vulnerable software; anyone whose wallet was born on the wrong firmware version has to move funds to a freshly generated seed, whether or not they have noticed suspicious activity yet.

Coinkite co-founder NVK (Rodolfo Novak) drew a broader lesson from the episode, warning that “AI-assisted code review can now find latent bugs at a speed that is outpacing even the industry’s most seasoned experts,” and that any firmware which has ever been open-source or public should be treated as though it is already being read by attackers, in comments reported by Bitcoin Magazine. For multisig operators specifically, the Coldcard episode is exactly why SEAL’s guidance to mix hardware wallet models and manufacturers across signers exists: a multisig where every signer happens to use the same device model and firmware version does not have five or seven independent points of failure, it has one, multiplied.

Clear Signing: Verifying What You Are Actually Approving

Every case above, Bybit’s tampered interface, WazirX’s mismatched display, Radiant’s malware-fed screen, shares a root cause with a name: blind signing. For years, most hardware wallets could only show a signer a transaction hash, a string of characters with no human-readable meaning, rather than the actual contents of what was being approved. A signer checking that hash against their screen is really only checking that the hash matches, not that the underlying transaction does what they think it does. If the software generating that hash has been compromised, the hash will correspond perfectly to a malicious transaction instead.

The industry’s answer, still rolling out through 2026, is a standard called Clear Signing. The Ethereum Foundation’s Trillion Dollar Security Initiative took over stewardship of the effort from Ledger in May 2026, coordinating contributions from Ledger, MetaMask, Trezor, Fireblocks, WalletConnect, Keycard, Cyfrin, Sourcify, ZKnox, Zama and Argot, according to the Ethereum Foundation’s announcement. Its technical core is ERC-7730, a shared, publicly auditable format for transaction descriptors that lets a wallet render a plain-language summary instead of a raw hash or calldata. Two companion standards round it out: ERC-8176, an attestation framework built on the Ethereum Attestation Service that lets independent auditors formally vouch that a given descriptor accurately represents what a contract call does, and ERC-8213, a calldata digest that produces a short, reproducible fingerprint a signer can independently recompute on a separate device and compare against what their primary signing device shows.

That last piece matters most for multisig operators specifically. SEAL’s guidance to conduct out-of-band verification, a video call plus a separately signed message for anything unusual, and to independently verify raw calldata before signing, both become dramatically easier once there is a standard, cross-wallet way to generate a short fingerprint rather than manually parsing hex data. Community tools built for exactly this purpose already exist for Safe transactions, letting a signer recompute a transaction’s true hash on a clean, separate machine before approving it on their primary signing device. The rule of thumb SEAL and Clear Signing both converge on is the same: never sign what a device cannot show in plain language, and never trust a single machine’s word for what is about to be approved.

Timelocks and the Discipline of Deliberate Slowness

Every technical control above assumes a signer has time to notice something is wrong. SEAL’s framework builds that assumption directly into policy: transactions affecting user funds or protocol privileges should be made deliberately slow through mandatory timelocks and review windows, on the theory that speed is itself a risk, and forced urgency is one of the most consistent tools attackers use to short-circuit scrutiny.

Drift Protocol’s April 2026 loss is the clearest recent case study in what happens when that discipline slips. Days before the exploit, the protocol’s security council had migrated to a smaller 2-of-5 signer configuration with no timelock at all. That change removed the review window that might otherwise have caught months of social engineering aimed at getting signers to pre-sign Solana durable nonce transactions, a legitimate feature that lets a transaction be signed once and executed later without expiring. With no delay between signature and execution, there was no point at which the fraud could be caught before funds actually moved.

A working timelock setup pairs a mandatory delay, commonly 24 to 72 hours for routine treasury operations and longer for anything touching upgradeable contract logic, with a separate veto quorum: a smaller set of signers, or even a different multisig entirely, empowered to cancel a pending transaction if something looks wrong during the review window. The delay only helps if someone is actually watching during it, which is why SEAL also calls for active, automated monitoring, tools like Safe Watcher that immediately flag proposed transactions, new signatures and owner changes rather than relying on a signer to check manually.

Verification Culture: Communication Protocols and Social Engineering

Not every failure happens at the signing device. Radiant Capital’s developers were compromised through a decoy PDF sent over Telegram; WazirX signers approved a transaction because the interface they trusted told them it was safe. Both are, at root, social engineering problems wearing a technical disguise.

SEAL’s certification framework treats communication security as its own category, distinct from signer key management, requiring encrypted and multi-factor-authenticated channels for coordination between signers, documented identity verification procedures, and emergency contact lists reviewed at least twice a year so they are not stale when actually needed. The practical habits that follow are simple to state and easy to skip under pressure: never copy a destination address from a block explorer, chat message or email, use a verified internal address book instead; treat any request to change a previously verified address as a full re-verification event, not a minor update; and for high-value transfers to a new counterparty, verify the destination character by character on a live video call rather than trusting a typed confirmation, since a compromised chat account or a convincing deepfake can impersonate a colleague asking for an urgent approval. None of this is exotic. It is the same instinct that tells someone not to wire money because an urgent email from the chief executive asked for it, applied to a context where the transfer is irreversible the instant enough signatures accumulate.

SEAL’s New Multisig Operations Certification: What It Actually Requires

Most of the guidance above has existed in some form for years as recommendations. What is new in 2026 is that it is becoming something closer to an auditable standard. SEAL’s Framework Checklist for Multisig Operations, an open-source operational security certification, packages best practices into six categories that a protocol or treasury can be assessed against rather than just encouraged to follow.

Governance and inventory comes first: a named operations owner and a complete registry of every multisig, its configuration, its signers and the contracts it controls, updated within 24 hours of any security-relevant change. Risk assessment follows, requiring risk-based classification of each multisig with controls proportional to what it guards, the same three-signer, 50 percent floor and N-of-N prohibition covered above, plus contract-level protections like timelocks and transaction guards. Signer security and access control is the most detailed category: mandatory hardware wallets with dedicated addresses per multisig, geographically distributed seed phrase backups, quarterly access reviews, documented signer training, and a hard 48-to-72-hour window to offboard any signer who held emergency-class privileges.

The remaining three categories cover what happens around the signing moment rather than the signing itself. Operational procedures require signers to independently verify transaction details across two separate interfaces before approving, plus a three-year retention window for audit trails. Communication and coordination mandates the encrypted, MFA-protected channels described above. Emergency operations closes the loop: documented playbooks, quarterly reachability testing of every signer, response-time requirements by severity, with anything classified as an emergency requiring a response inside two hours, continuous monitoring, and a full disaster-recovery drill at least once a year. Together, the checklist reads less like advice and more like the operational-resilience audits banks already have to pass, which is precisely the gap TRM Labs’ 76-percent-of-losses statistic suggests the industry has been missing.

Multisig vs MPC vs Smart Contract Wallets: Picking the Right Model

Multisig is not the only model for distributing custody risk across multiple parties, and it is worth understanding the alternatives before assuming a bigger multisig is always the answer. Multi-party computation (MPC) wallets split a single private key into cryptographic shares held by different parties, who jointly produce one valid signature without any single party, or any combination short of the threshold, ever reconstructing the full key. Unlike multisig, this coordination happens off-chain: the blockchain sees one ordinary signature, not a visible M-of-N structure.

As Safe’s own comparison of the two models puts it, “multisig externalizes trust into verifiable code,” while “MPC internalizes trust into systems and infrastructure that cannot be fully verified onchain.” That is a fair summary of the tradeoff. Multisig transactions are fully transparent and auditable on-chain by anyone, with no dependency on an off-chain coordination service; the cost is higher gas fees for multiple signatures and real friction whenever thresholds or signers change, since that typically requires an on-chain transaction of its own. MPC transactions are cheaper and faster, since only one signature ever hits the chain, and threshold or key-share changes can often happen off-chain without moving to a new address at all; the cost is that verifying what actually happened requires trusting the MPC provider’s infrastructure and implementation, not just reading a public ledger.

Neither model is unconditionally safer, and the practical 2026 answer for many serious treasuries is not choosing one but layering both: MPC for high-frequency, cross-chain or automation-heavy operations where speed and multi-chain flexibility matter most, multisig for the treasury-of-record and governance functions where public verifiability matters more than convenience. Institutional custody has moved in a similar direction on the exchange side, where deposit, withdrawal and internal-transfer processes at major venues increasingly combine several of these techniques rather than relying on one, a comparison HOGE Wire examined in detail when testing how Coinbase, Binance, Kraken and OKX handle institutional-size trades.

Disaster Recovery: Planning for the Day a Key Is Compromised

A best-practices checklist is only half the job; the other half is having a plan for the day it fails anyway. SEAL’s certification requires exactly this: a documented emergency playbook, quarterly tests to confirm every signer is actually reachable, response-time targets by severity, and a full disaster-recovery drill at least annually, not a document that sits unread until an actual incident forces someone to open it for the first time under pressure.

A workable plan answers a short list of questions before they become urgent. If one signer’s device or seed phrase is suspected compromised, is there a pre-agreed process to rotate that signer out and add a replacement without needing the compromised key’s cooperation? Who has the authority to freeze or pause protocol functions on suspicion alone, before a loss is confirmed, and what is the cost of that authority being exercised too readily? If a threshold number of signers becomes unreachable at once, whether through a coordinated attack, a regional outage, or something as mundane as a canceled flight during a scheduled key ceremony, is there a fallback path that does not require quietly weakening the threshold?

Centralized exchanges at least offer a support line to call when something looks wrong, however imperfect that process can be in practice, as HOGE Wire found when comparing how Coinbase, Binance, Kraken and OKX handle support requests. A self-custodied multisig has no equivalent unless the team builds one deliberately, in advance, before it is needed. None of Bybit, WazirX, Radiant, Drift or Humanity Protocol had a functioning answer to the compromised-signer question fast enough to stop the theft in progress; in each case, by the time anyone realized the interface or the signer had been compromised, the transaction had already executed. Disaster recovery planning will not prevent every incident, but it is the difference between an incident and a total loss.

Treasury Governance for DAOs and Protocols

Protocol and DAO treasuries face a version of this problem that individual signers do not: the temptation to put too much authority behind a single multisig because it is operationally simpler than maintaining several. SEAL’s guidance pushes the opposite direction, recommending that protocols avoid consolidating all admin privileges into one contract, and instead split functionally distinct powers, pausing a contract, upgrading its logic, moving treasury funds, adjusting fee parameters, across separate multisigs with their own signer sets and thresholds. The goal is limiting blast radius: a single compromised or socially engineered multisig should be able to do damage in one narrow area, not everywhere at once.

Cross-chain bridges are the sharpest version of this problem, since a bridge’s admin keys typically control minting and burning authority across two or more chains simultaneously, and 2026 has produced no shortage of examples of what happens when that authority is concentrated, as HOGE Wire’s look at this year’s cross-chain exploit wave documents in more detail. Humanity Protocol’s failure was exactly this pattern: two multisigs that were supposed to be independent across two chains, undone because both drew from the same underlying key material.

There is no universal number of multisigs a given protocol should run, but the audit question is consistent: list every privileged action a protocol’s contracts allow, then check whether more than one of them can be triggered by the same signer set. If most of them can, that is a governance decision worth revisiting, not just a signing procedure.

The Regulatory Gap: Who Is Actually on the Hook When a Multisig Fails

For a registered investment adviser in the United States, custody of client crypto assets is not a purely technical decision, it is a compliance obligation under the SEC’s Advisers Act Custody Rule, formally Rule 206(4)-2, which requires client funds to sit with a qualified custodian. In late September 2025, the SEC’s Division of Investment Management issued a no-action letter allowing state-chartered trust companies to qualify as bank custodians for crypto assets, conditioned on written private-key-management and cybersecurity policies, SOC 1 or SOC 2 audits, proper segregation of client assets, and a ban on rehypothecation without client consent, according to legal analysis from Hunton Andrews Kurth.

What that guidance does not resolve is whether a multisig or MPC arrangement, on its own, actually satisfies the Custody Rule at all. That ambiguity matters because none of the largest multisig losses covered in this article happened at an SEC-registered entity: Bybit is a Dubai-headquartered offshore exchange, WazirX operates in India, and Radiant Capital, Drift Protocol and Humanity Protocol are all decentralized projects governed by their own multisigs rather than any regulated custodian. For a fully decentralized DeFi treasury, there is effectively no regulator to call after a loss like this happens, only insurance funds, community goodwill, and whatever recovery negotiation the team can manage with the attacker, part of a broader pattern of uneven accountability HOGE Wire examined in its review of the SEC’s own crypto enforcement record.

The practical takeaway is not that regulation is coming to rescue decentralized treasuries from bad multisig hygiene. It is closer to the opposite: for anything outside a regulated custodian relationship, the operational practices covered in this article are the entire defense, not a supplement to a regulatory backstop that does not currently exist for this specific failure mode.

Frequently Asked Questions

What is the safest threshold for a multisig wallet?

There is no universally correct ratio, but security researchers converge on a few floors. SEAL’s multisig framework recommends at least three distinct signers with a threshold of 50 percent or higher, and warns against N-of-N setups, where every signer must approve every transaction, since one lost key or unreachable signer can freeze funds permanently. For treasuries holding more than roughly $1 million, the recommendation rises to seven or more signers. A common working setup is 3-of-5 for smaller teams and 4-of-7 or 5-of-9 for larger treasuries, adjusted for how many signers can realistically stay reachable and secure over time.

Is a multisig wallet safer than a single hardware wallet?

Generally yes, because no single lost device, stolen seed phrase or coerced individual can move funds alone. But a multisig is only as strong as its weakest operational link: if every signer uses the same hardware wallet model and firmware, stores backups in the same location, or takes instructions through the same channel, the multisig can behave like a single point of failure even though it looks decentralized on paper. Diversity across signers, devices and locations is what actually delivers the security a multisig promises.

What is blind signing, and why does it matter for multisig security?

Blind signing happens when a signer approves a transaction hash, a cryptographic fingerprint, without their device or software showing the actual contents of what they are approving: the destination address, the amount, or the function being called. If the interface generating that hash has been compromised, a malicious transaction can produce a hash that looks completely normal to the signer. Nearly every major multisig theft of the past two years, including the Bybit hack, involved signers approving something other than what they believed they were signing. Clear Signing standards like ERC-7730 exist specifically to replace blind hashes with human-readable transaction summaries.

Should a company or DAO use multisig or MPC for treasury custody?

It depends on what the treasury needs to do. Multisig offers full on-chain transparency and suits treasury-of-record functions and DAO governance, where public verifiability matters and transaction volume is relatively low. MPC wallets are typically faster and cheaper per transaction, and handle cross-chain and high-frequency operations more gracefully, at the cost of relying on off-chain infrastructure that cannot be independently verified on a public ledger. Many institutional custody setups now combine both rather than choosing exclusively.

Can a multisig wallet be drained without any private key being stolen?

Yes, and this is now the dominant failure mode. In the Bybit, WazirX, Radiant Capital and Humanity Protocol incidents, every signature was cryptographically valid and no private key was cracked or directly stolen at the moment of theft. Attackers instead compromised the layer between signers and the blockchain, a tampered interface, malware on a signing device, or key backups that undermined an assumption of independence, so that signers approved something other than what they intended. Data from TRM Labs shows this category of operational compromise now accounts for the large majority of value stolen from crypto platforms, even though it represents a minority of total incidents.

Anneke de Vries covers security, custody and infrastructure for HOGE Wire.