Multisig Best Practices in 2026: The Layer Above the Keys

On 6 September 2026, at 14:27 UTC, Bitcoin’s Liquid Network held 4,205 BTC in reserve. One minute later it held 202. In a single peg-out transaction, roughly 3,996 BTC, worth about $320 million, walked out of the sidechain’s vault, and not one of the fifteen keys that guard that vault had been stolen, phished, or coerced, according to a technical breakdown by crypto.news. The 11-of-15 multisig that secures Liquid’s peg did exactly what it was built to do: it read a withdrawal request, confirmed the request was valid, and signed it. The request was not valid. The software that told the signers it was valid had a bug.

For two years crypto’s most expensive lesson has been that multisig wallets rarely fail because the cryptography fails. They fail at the human approval step: blind signing at Bybit, a spoofed interface at WazirX, malware at Radiant. Liquid is a different and more uncomfortable lesson. Here the approval step was honest, the signers were not tricked, and their machines were not compromised. What failed sat one layer above the keys, in the code that decides what is true. That is the part almost no multisig checklist covers, and it is where a serious 2026 best-practices guide has to start. The same point runs through our survey of how stolen access, not broken code, now drives the biggest losses.

A $320 Million Withdrawal No Stolen Key Could Explain

Liquid is a Bitcoin sidechain, launched by Blockstream in 2018, that lets users move BTC onto a faster and more private settlement layer as Liquid Bitcoin (L-BTC), which is meant to be backed one-for-one by real Bitcoin held in the federation’s reserve. That reserve is guarded by an 11-of-15 multisig: fifteen functionaries, each an incorporated company running a hardened server with its signing key sealed inside a hardware security module, spread around the world. To move coins out, eleven of them must sign, and peg-outs are gated by a second set of Peg-out Authorisation Keys designed to add friction, per Blockstream’s own documentation. On paper it is one of the most conservative custody setups in the industry, engineered so that at least five functionaries would have to fail at once before the peg could be touched.

What happened on 6 September did not require five functionaries to fail, or even one. The attacker exploited a range-proof verification cache in Elements, the Bitcoin Core derived software that every Liquid node runs. Liquid uses Confidential Transactions to hide amounts and asset types, and every transaction carries a cryptographic range proof that the hidden value is legitimate. To save work, nodes cached the result of verifying a proof; the cache key, however, was derived only from the proof bytes and the hidden amount, and left out the asset type and the destination script. An attacker could therefore get a proof verified once in a harmless context, then replay it in a malicious one and have the node pull the earlier valid result straight out of the cache instead of checking again. Investigators say the attacker planted 68 identical range proofs over roughly fourteen hours, then constructed an output that collided with a cached key.

The effect was quiet and total. The node software concluded that unbacked L-BTC was fully backed, and the federation’s peg-out logic saw a withdrawal that passed every validity check it knew how to run. Eleven functionaries signed. Federation nodes, in the words of the crypto.news post-mortem, retrieved the cached result and skipped the verification that should have rejected the inflationary output, and the multisig obliged. Reserves fell from 4,205.29 BTC to 202.63 BTC in the span of a minute, about 95 percent of the peg, and the full path from minting the fake L-BTC to receiving real Bitcoin took roughly 35 minutes. Blockstream later said no federation keys were compromised, attributing the loss to a cache-key collision rather than any stolen signing key.

The ending was stranger than the theft. The attacker wrote the words “we are whitehats. contact us on chain” into an OP_RETURN field and opened a negotiation anyone with a block explorer could watch in real time. Blockstream halted the sidechain, patched the affected bridge nodes, and, in a PGP-signed message, told the attacker the fix was live and the funds were safe to return. Within about thirty hours 3,400 BTC came back; the attacker kept 598.5 BTC, roughly $47 million, or about 15 percent of the haul. Ledger’s chief technology officer, Charles Guillemet, was among those unconvinced by the white-hat label, arguing that genuine security researchers disclose a flaw before moving hundreds of millions in collateral, not after.

The Layer Above the Keys

Here is the sentence that should reframe how every treasury thinks about its multisig: a multisig authorizes, it does not audit. The eleven signatures on Liquid’s peg-out were mathematically perfect and the keys were exactly where they belonged. What no signature can attest to is whether the thing being signed is true, and at Liquid the thing being signed rested on a false premise, that the L-BTC being redeemed actually existed. As one markets desk put it, secure private keys cannot protect reserves if the software feeding transactions into the signing process wrongly decides that a withdrawal is valid.

It helps to picture a multisig as one layer in a stack. At the bottom sit the keys and the signers. Above them is the software that builds and validates transactions. Above that is the accounting logic that defines what the system even counts as solvent. Above that is the human and organizational process that decides who signs, when, and on what evidence. A threshold signature scheme is a strong lock on exactly one of those layers and does nothing for the others. Most multisig guidance published in the last two years concentrates on the signing layer, yet the expensive failures of 2026 came from almost every layer except the keys.

A pegged sidechain is a bridge in all but name, and the economics of cross-chain trust were already flashing warnings long before September. Bridges concentrate value behind a small validator or federation set, which makes the code that governs that set the single richest target in the system. Liquid simply proved that the target does not have to be the keys.

What a Multisig Protects, and What It Cannot

An M-of-N multisig requires M of N designated keys to authorize a transaction. Its guarantee is narrow and genuinely valuable: no single key, and no group smaller than M, can move funds on its own. That defeats the classic single point of failure of one stolen seed phrase, and it forces an attacker to compromise several independent parties at once. For an individual protecting savings or a company protecting a treasury, that is a large and worthwhile step up from a single signature.

The trouble is the list of things a threshold does not touch, and 2026 worked through most of it:

• A signer who approves the wrong thing because the interface lied to them, the blind-signing pattern behind Bybit and WazirX.
• A transaction that was signed legitimately earlier and executed later, as with the pre-signed durable nonces used against Drift.
• Keys that are nominally independent but physically together, such as backups sitting on a single laptop.
• Validity logic that is simply wrong, as at Liquid, so that an invalid request looks valid to every honest signer.
• The device or software around a key being compromised even when the key itself is not, the lesson of the Radiant heist.

Every one of those is a real incident, not a hypothetical, and none of them is solved by adding another signer.

The 2026 Casualty List

Put the year’s marquee multisig failures side by side and a pattern jumps out: the cryptography held every time. What varied was which layer above the keys gave way.

The dollar figures come from post-incident reporting: Bybit’s $1.5 billion, the largest crypto theft on record, traced to malicious code on a Safe developer’s machine; WazirX’s roughly $230 million; Radiant’s roughly $50 million; Drift’s $285 million; and Humanity Protocol’s $36 million. The wider trend is not that hacks are getting bigger everywhere. TRM Labs counted a record 207 incidents in the first half of 2026 yet total losses fell to about $972 million, and while smart-contract bugs made up most of the incident count, infrastructure and key-related compromises were a minority of events that drove roughly three quarters of the value stolen. The money follows the layer above the code.

Best Practice Now Starts Before the Signers

If the validity layer can lie to the signers, then the first control is not on the keys at all; it is an independent check that the request even makes sense. For a peg or a treasury that means a machine-checkable solvency invariant, a rule such as total issued must never exceed total backing, enforced by watchers that run separately from the nodes doing the signing. The Liquid bug corrupted one code path; a second, independent path computing the same invariant would have raised the alarm that supply had jumped by 4,000 coins with no matching deposit.

The second control is a brake. A system that can lose 95 percent of its reserve in a single one-minute transaction has no rate limit worth the name. Withdrawal caps, per-transaction ceilings, and circuit breakers that pause outflows when they exceed a rolling threshold turn a total loss into a partial one and, crucially, into a detectable one. None of this is exotic; centralized exchanges and well-run bridges already do it. The lesson is to treat the peg-out path as adversarial even when every signer is honest.

The third control is plurality in the validation itself. Ethereum’s multi-client model, where several independent implementations must agree, exists precisely so that one buggy verifier is outvoted rather than obeyed. A federation or bridge that runs a single codebase inherits every latent flaw in that codebase, and the Elements range-proof bug reportedly sat unnoticed for more than two years. Diversity of signers is standard advice; diversity of the software those signers trust is the part that Liquid showed still missing.

Audit the Code That Feeds the Signers

Most multisig security budgets are aimed at the wallet: the Safe contract, the signer devices, the signing ceremony. That leaves the larger attack surface, the node and validation software, comparatively under-examined. A cache that keys on the wrong fields is a textbook bug class, the sort of thing fuzzing and targeted review are built to catch, and it lived in a mature, widely deployed codebase. The takeaway is not that audits do not work; it is that the audit scope was drawn too narrowly.

Practical measures follow directly. Commission independent review of the transaction-validation and consensus code, not only the smart contract that holds funds. Use formal verification for the invariants that matter most, supply conservation and proof verification chief among them, so that a property is proven rather than merely tested. Fund continuous fuzzing of the validation paths. Scale bug bounties to the value at risk, since a range-proof flaw guarding hundreds of millions justifies a seven-figure reward far more than most projects pay. On Bitcoin specifically, expressing spending conditions in an auditable policy language is part of the same discipline; our look at Miniscript and the Taproot script path covers how custody rules can be made legible enough to reason about instead of trusted blindly.

Thresholds and Signer Diversity: Necessary, Never Sufficient

None of this retires the classic guidance, which remains the floor. The Security Alliance’s secure-multisig framework sets sensible minimums: at least three signers, a threshold above half, seven or more signers once a multisig holds more than $1 million, and never an N-of-N scheme where losing a single key freezes the funds forever. It also calls for hardware from different models and manufacturers, geographic separation of signers, at least one external signer outside the core team, a dedicated signing address per multisig, and signing on hardened or air-gapped devices.

Follow all of it and you still would not have stopped Liquid, which had fifteen signers at incorporated companies on separate continents, each key in its own hardware module. That is the point worth sitting with: signer diversity defends against a compromised or coerced signer, and beyond a sensible threshold the marginal key stops adding protection once the failure moves off the key layer. Guillemet has made a related argument about reflexive multisig adoption, cautioning that multisig is not automatically the right answer, because every added device, backup, and coordination step is also a new way to fail. Diversity is necessary. It is not a substitute for the controls above it in the stack.

Clear Signing Verifies the Message, Not the Premise

The most important safety standard to land in 2026 is Clear Signing. Launched by the Ethereum Foundation in May, it bundles ERC-7730, a JSON format that lets a contract describe its functions in plain language, with a public registry of those descriptors and an attestation framework, ERC-8176, that lets independent auditors vouch for their accuracy. The goal is what its designers call What You See Is What You Sign: the signer approves a human-readable statement of what a transaction does, not an opaque blob of calldata. Against the Bybit and WazirX pattern, where a manipulated interface showed a benign transfer while the wallet signed something else, this is exactly the right medicine, and every serious signer setup should adopt it.

Liquid marks the edge of what clear signing can do. The malicious peg-out was not a lie about the calldata; the calldata was honest. A functionary reading a perfectly clear-signed description would have seen a valid withdrawal of L-BTC that the system believed was backed, and approved it in good conscience. Clear signing answers the question, is this transaction what it claims to be. It cannot answer the deeper question, is what it claims true. That second question belongs to the solvency and validity checks described earlier, which is why the two have to be run together rather than treated as alternatives.

Timelocks, Rate Limits, and the Transaction You Already Signed

Drift is the cautionary tale about time. The attackers, after months of social engineering, persuaded members of the protocol’s Security Council to sign transactions built on durable nonces, a Solana feature that lets a transaction be signed once and executed later without expiring. When the moment came, the instructions handing administrative control to the attacker were already signed; there was no live approval step left to catch them, and roughly $285 million drained in about twelve minutes.

Two habits follow. First, treat a signature you gave in the past as a live liability: track pending and pre-signed authorizations, expire them aggressively, rotate session keys, and understand any mechanism, durable nonces included, that lets an approval sit dormant and fire later. Second, never remove your detection window. A mandatory timelock between authorization and execution is the difference between a theft and a caught attempt, because it gives humans and monitors time to react. Liquid is the same lesson from the opposite direction: with no delay and no rate limit, the drain was over in a minute, faster than any person could intervene. Timelocks and withdrawal caps buy the one thing incident response actually needs, which is time.

One Laptop, Two Thresholds

Humanity Protocol shows how a multisig can be defeated on paper and in practice at the same time. The project split its bridge admin keys into a 3-of-6 on Ethereum and a 3-of-5 on BNB Chain, two nominally independent thresholds. In reality, multiple keys from both had been backed up to a single employee’s laptop during setup, so one compromised device crossed both thresholds at once, and the attacker drained and minted on both chains. 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.

The lesson is that key isolation, not key count, is the property that matters. Six keys that share a backup are one key wearing a costume. Best practice is uncompromising here: no shared backups, no two keys derivable from the same seed or stored in the same vault, dedicated signing hardware per key, and an explicit verification at setup that keys described as independent really are independent, on separate devices, in separate hands, with separate recovery paths.

Monitoring and the Whitehat You Cannot Count On

Liquid ended well because the attacker chose to return 85 percent of the loot. That is not a control; it is luck, and luck is not a security model. The reason to build everything else in this article is precisely so that survival does not depend on an anonymous counterparty’s conscience. Guillemet’s skepticism is worth heeding: an actor who drains a system and only then asks to talk, keeping tens of millions while an on-chain negotiation plays out, looks less like responsible disclosure and more like leverage.

The controls that reduce dependence on goodwill are unglamorous. Real-time monitoring of balances and invariants, with alerting that pages a human within seconds rather than reconciliation that runs overnight. An incident-response playbook that names owners, defines who can halt the system, and has actually been rehearsed. A disaster-recovery plan for the case where a threshold of keys becomes unavailable or a compromise is suspected mid-transaction. The Security Alliance now publishes an operational certification for multisig teams covering exactly this ground, from a named operations owner and a full signer registry to quarterly access reviews and regular emergency drills. The people who run these signer sets carry real operating costs and incentives of their own, much like the validators whose economics we track across chains, and treating operations as a funded, audited function rather than an afterthought is what separates a resilient setup from a lucky one.

MPC Is a Different Trust Model, Not a Fix

Institutions frequently ask whether multi-party computation solves the problems above. It does not; it relocates them. In an on-chain multisig, M separate keys each sign and a smart contract verifies the threshold, which is transparent and independently auditable on-chain but chain-specific and slower to reconfigure. In an MPC wallet, the full private key is never assembled; shares held by different parties jointly produce a single signature off-chain, which is faster, chain-agnostic, and easy to re-share, at the cost of trusting infrastructure that cannot be fully verified on-chain.

As Safe frames the tradeoff, multisig externalizes trust into verifiable code while MPC internalizes it into systems that cannot be fully verified on-chain. Both are legitimate, and the right choice depends on your threat model. But note what neither model changes: both authorize transactions, and neither audits whether the request is legitimate. An MPC wallet fed the same false solvency data would have signed Liquid’s peg-out just as obligingly. Choosing between them is a real decision; it is not the decision that would have prevented 2026’s biggest multisig loss.

Where the SEC Fits, and Where It Doesn’t

None of the incidents in this article happened at an SEC-regulated custodian, which is the first thing to understand about the regulatory backstop: for most of these failures, there was not one. In the United States, the Advisers Act custody rule, Rule 206(4)-2, requires registered investment advisers to hold client assets with a qualified custodian. A no-action letter from the SEC’s Division of Investment Management in late September 2025 let state-chartered trust companies act as bank custodians for crypto, subject to written key-management and cybersecurity policies and independent audits, as Hunton’s analysis lays out.

What that guidance pointedly did not resolve is whether assets held in a multisig or MPC arrangement satisfy the custody rule at all, leaving the exact configurations this article is about in a gray zone. Liquid’s functionaries are incorporated companies, but the federation is not a US qualified custodian, and a decentralized-finance user whose treasury sits behind a Safe has no regulator to call if a signer goes rogue or a validity bug drains the pool. For the large majority of multisig holders, in other words, the operational routines described here are not a supplement to regulatory protection. They are the protection.

The 2026 Multisig Checklist

Pulling the layers together, a defensible 2026 multisig setup does all of the following, from the accounting layer down to the keys:

• Enforce a solvency or supply invariant with watchers that are independent of the signing path.
• Impose withdrawal rate limits and circuit breakers so no single transaction can drain most of the reserve.
• Run more than one independent implementation of the validation code, and audit that code, not just the wallet contract.
• Adopt clear signing (ERC-7730) so every signer approves a human-readable transaction, and pair it with validity checks.
• Set a sane threshold: at least three signers, above half, seven or more above $1 million, and never N-of-N.
• Diversify hardware, manufacturers, and geography, and include at least one external signer.
• Keep keys genuinely isolated: no shared backups, no shared seeds, dedicated signing devices.
• Apply mandatory timelocks and expire pre-signed or delegated authorizations aggressively.
• Monitor balances and invariants in real time, and rehearse an incident-response and disaster-recovery plan.

No single item on that list would have stopped every incident of the past two years, and that is the point. Security here is the product of layers, not of any one heroic control, and the treasuries that come through 2027 intact will be the ones that stopped treating the signing ceremony as the whole of the problem.

Frequently Asked Questions

Did the Liquid Network hack steal anyone’s private keys?

No. Blockstream said none of the fifteen federation keys were compromised. The attacker exploited a range-proof verification cache bug in the Elements node software to create unbacked Liquid Bitcoin, so the 11-of-15 multisig approved a peg-out that looked valid. Roughly 4,000 BTC, about $320 million, left the sidechain, and about 3,400 BTC were later returned.

What is the safest multisig threshold to use?

The Security Alliance recommends at least three signers, a threshold above half, and seven or more signers for treasuries above $1 million, while avoiding N-of-N schemes where losing one key locks the funds. A threshold only protects the key layer, so it must be paired with software audits, spending limits, and monitoring.

Does clear signing or ERC-7730 prevent multisig hacks?

Clear signing prevents blind-signing attacks, where a manipulated interface shows one thing while the wallet signs another, as happened at Bybit. It does not catch a transaction that is internally valid but built on a false premise, which is what defeated Liquid, so clear signing should be combined with independent solvency and validity checks.

Is MPC safer than a multisig wallet?

MPC is a different trust model, not automatically safer. A multisig is verifiable on-chain but chain-specific and slower to reconfigure, while MPC never assembles the full key and is faster and chain-agnostic but relies on infrastructure that cannot be fully verified on-chain. Neither would have stopped Liquid, because both authorize transactions and neither audits whether the request is legitimate.

How do you protect a multisig against a software bug like the one at Liquid?

Enforce a machine-checkable solvency invariant, so total issued can never exceed total backing, using watchers that are independent of the signing path. Add withdrawal rate limits and circuit breakers so no single transaction can drain most of the reserve, run more than one independent implementation of the validation code, audit that code rather than the wallet contract alone, and monitor balances in real time.

Marcus Feld covers security and exploits for HOGE Wire.