Multisig or MPC: Best Practices for Splitting the Key in 2026

On September 24, 2026, roughly $387.5 million left Bitget’s hot wallets in under an hour, spread across eight blockchains, and not one private key was stolen. It is, so far, the largest crypto theft of the year, and Fortune reported that Bitget and outside analysts pointed quickly at North Korea’s Lazarus Group. The exchange initially put the loss at about $351.6 million before raising the tally to roughly $387.5 million.

For anyone who runs a shared wallet, the interesting part is what did not happen. No seed phrase was phished, no signer’s laptop was cloned, no smart contract was tricked into paying out. Bitget’s chief executive, Gracy Chen, said the attackers never stole a private key or forged a customer withdrawal; instead they compromised a backend system inside the exchange’s own wallet infrastructure, fed it spoofed transaction data, and let Bitget’s authorization process release funds that looked routine, per reporting by Yahoo Finance. The keys worked exactly as designed. The system that decides when to use them did not.

That is the same shape as almost every nine-figure loss of the past two years, and it is why the most common version of multisig best practice, an argument about how many signers you should have, is the wrong place to start. The better first question is which key-sharing model you use at all: a classic multisig, a multi-party computation (MPC) setup, or a threshold-signature scheme. They remove the single point of failure in different ways, and, more to the point, they fail in different ways. With Bitcoin near $83,350 and Ether around $2,676 the day this published, according to CoinGecko, the sums sitting under these wallets are large enough that the difference is not academic.

The $387 Million That Left Without a Stolen Key

The Bitget theft is worth walking slowly because it is the clearest recent example of a hack that never touched the cryptography. According to a forensic breakdown by Scorechain, the first unauthorized transfer left an internal wallet at 18:31 UTC, and the bulk of the money was gone within about 45 minutes. The proceeds landed on Ethereum, Arbitrum, Optimism, Base, BNB Chain, Avalanche, TRON, and the XRP Ledger, the now-standard pattern of scattering funds across cross-chain infrastructure to slow down investigators. A day later, most of it had not moved: about 68,300 ETH (roughly $183 million) and 102.6 million XRP (roughly $158 million) still sat in attacker-controlled addresses.

Bitget was explicit that cold wallets and private keys were untouched. What broke was the automated approval layer, the software that is supposed to look at an outbound transaction, decide it is legitimate, and sign it. Built for withdrawal speed, that layer had almost no friction and almost no delay, so once the attacker could hand it forged instructions it simply did its job. Customer balances were spared only because Bitget says it drew on a user protection fund it puts at more than $460 million, a voluntary reserve it had grown from about $300 million in 2023, and it set a deadline to reopen withdrawals within days. That backstop is a business decision, not a security control; the next exchange may not have one.

Strip away the exchange-specific detail and the lesson generalizes to any shared wallet. The attacker did not need a threshold of keys or a rogue insider with signing power. It needed to reach the machinery that authorizes signing and lie to it convincingly. That is an infrastructure-trust failure, and it is exactly the failure mode that the two dominant ways of splitting a key, multisig and MPC, distribute very differently.

Two Ways to Remove the Single Point of Failure

A single-key wallet has one obvious weakness: whoever holds the key controls the money, and whoever steals it does too. Both multisig and MPC exist to kill that single point of failure, but they do it with opposite philosophies.

A multisig wallet is a smart contract that will not move funds unless it receives a preset number of valid signatures out of a defined set, the familiar M-of-N. Each signer holds a complete, independent private key. The approval rule lives on-chain, in code anyone can read, and enforcement is done by the blockchain itself. Safe, formerly Gnosis Safe, is the dominant implementation on EVM chains; its foundation reported $27.24 billion in self-custodied assets across more than 63 million accounts at the end of the second quarter of 2026. Safe frames the design bluntly: it says a multisig "externalizes trust into verifiable code" because every rule is visible and every Safe contract can be checked on-chain.

MPC takes the opposite route. Instead of several whole keys, there is one logical key that is never assembled. It is mathematically split into shares held by different parties, and those parties run a cryptographic protocol to jointly produce a single signature without any of them ever seeing the full key. Fireblocks, one of the largest institutional providers, describes the property as a key that is "never created, never stored, and never assembled at any point," and notes that regulators recognized MPC as a valid model for self-custody wallets back in 2019. Because the coordination happens off-chain and only one signature reaches the network, MPC is cheaper in gas, works the same across chains, and lets you rotate shares without touching the wallet address. Safe’s own summary is that where multisig externalizes trust into code, MPC "internalizes trust into systems and infrastructure that cannot be fully verified on-chain."

There is a third path that Bitcoin people reach for, threshold signatures such as MuSig2 and FROST, which are close cousins of MPC applied at the signature-scheme level. They produce a single ordinary-looking signature from many participants, so the wallet looks like a normal address on-chain and reveals nothing about its internal policy. They are elegant and private, but they inherit MPC’s core tradeoff: the policy that decides who signs and when is not written on the chain for anyone to audit. The table below lines up the three on the properties that actually matter when something goes wrong.

What Actually Fails: The 2026 Casebook

Before choosing a model, look at how these wallets die in practice, because the pattern is remarkably consistent. TRM Labs counted a record 207 hacks in the first half of 2026, with total losses of about $972 million, down 57 percent from $2.3 billion a year earlier. The striking split is in its breakdown: smart-contract bugs were the majority of incidents but a small share of the money, while infrastructure and key-management compromises were only about 15 percent of incidents yet roughly 76 percent of the value stolen. The cryptography almost never breaks. The layer that authorizes signing does.

The biggest multisig losses bear this out. Bybit lost about $1.5 billion in February 2025 when attackers compromised a Safe developer machine and injected malicious JavaScript into the wallet interface, so the signers approved what looked like a routine transfer and actually authorized a contract upgrade that handed over the vault. WazirX lost roughly $230 million in July 2024 through the same trick at a different layer, a mismatch between what its custody interface displayed and what the transaction really did. Radiant Capital lost about $50 million in October 2024 when malware on multiple developers’ machines showed benign data on screen while malicious transactions were signed underneath; even Tenderly and Safe simulation looked clean because the compromised machines were the thing lying.

2026 added new variants without changing the theme. Drift Protocol, a Solana perpetuals venue, lost around $285 million on April 1 after attackers spent months social-engineering its security council into pre-signing durable-nonce transactions, a legitimate Solana feature that lets a signature be created once and executed later, per The Hacker News. Humanity Protocol lost about $36 million in June when its bridge keys, nominally split across two independent thresholds, turned out to have been backed up to a single employee laptop. The Liquid Network lost roughly $320 million on September 6 to a range-proof caching bug in the Elements node software, so its 11-of-15 functionaries signed a peg-out that the code wrongly told them was fully backed; Blockstream stressed that "no federation keys were compromised." Even the year’s hardware-wallet disaster, the $116 million Coldcard entropy bug, was not a stolen key; it was keys that were weak from birth. Bitget now closes the set from the exchange side.

Multisig’s Weak Spot Is the Screen, Not the Math

Multisig’s honest weakness is that its strength is on-chain and its danger is on the screen. The contract will faithfully enforce M-of-N, but a human being still has to look at a transaction and decide to approve it, and that decision is made against whatever the interface chooses to show. Bybit, WazirX, and Radiant were all the same attack in different clothes: the signers were shown a benign transaction and asked to sign a malicious one. This is blind signing, approving a payload your device renders as an opaque blob of hex or as a friendly summary you have no way to check.

The good news is that this is the one failure the industry is actively fixing, and the fix plays to multisig’s strengths because the truth of an EVM transaction is public calldata that can be decoded independently. In May 2026 the Ethereum Foundation took over stewardship of a Clear Signing standard from Ledger, built around ERC-7730, a JSON format that lets a wallet render a transaction in plain language on a trusted screen, plus a public registry and an attestation layer so third parties can vouch that a descriptor is accurate. The Foundation’s framing is that approving a transaction is the last line of defense, and, in its words, "when it is done blindly, that defense does not hold." The goal it states is What You See Is What You Sign. ERC-7730 remains a draft, but the direction is set, and it is the reason a well-run multisig is now defensible in a way it was not two years ago.

None of that helps if a signer approves without reading, which is the same discipline problem that smart-account delegation has made more urgent, since a single careless signature can now hand code the right to act for your address. Clear signing gives you the truth; it cannot make anyone look at it. That is a best practice, not a product, and it belongs to whoever runs the wallet.

MPC’s Weak Spot Is the Part You Can’t See

MPC trades the screen problem for a different one. Because there is no full key to steal and no on-chain approval to spoof at the contract level, the attack moves to the infrastructure that coordinates the signing, and that infrastructure is off-chain and, by Safe’s own admission about the model, not fully verifiable. When Fireblocks says the key is never assembled, that is true and genuinely valuable; it also means the thing you must trust is no longer a key you can hold but a policy engine, a set of servers, and a vendor’s operational security that you cannot inspect from the outside.

Bitget is the clean illustration. The attacker did not need any key share. It reached the backend that decides when to authorize a transfer and fed it forged data, and the automated policy signed because, as far as the system could tell, the request was valid. Whether Bitget’s hot-wallet setup was formally MPC or a bespoke automated-approval system almost does not matter; the failure has the MPC-family shape, which is that trust sits inside software you cannot audit on-chain. Concentration makes it worse. A large MPC provider can sit behind dozens or hundreds of institutions, so one compromised policy layer is a single point of failure wearing the costume of many. That is the mirror image of multisig’s transparency: MPC gives you convenience and cross-chain reach, and asks you to accept a backend you are not allowed to see.

The practical reading is not that one model is safe and the other is not. It is that they concentrate risk in different places. Multisig pushes risk onto the approval screen, which you can now harden with clear signing and verification discipline. MPC pushes risk onto an unverifiable backend, which you harden with vendor diligence, policy design, and monitoring. Choosing between them is really choosing which of those two jobs you are better equipped to do.

Best Practice 1: Match the Model to the Threat, Not the Trend

The first and most-skipped best practice is deciding which model you actually need, because the honest answer depends on who you are. Ledger’s chief technology officer, Charles Guillemet, made the point after the Coldcard fallout drove a wave of reflexive multisig adoption, warning that "multisig is not automatically the right answer" and that piling on more devices and backup seeds can add failure points rather than remove them. Complexity is not security; matched complexity is.

For an individual or a small treasury, a 2-of-3 multisig with clear signing is usually the sweet spot: it is cheap to reason about, fully on-chain, and it survives one lost or stolen key. The hard part is not the threshold but the guardians. Vitalik Buterin has written that the two questions that decide whether a multisig or social-recovery wallet is actually safe are "(i) whom do you choose as guardians, and (ii) what instructions do you give them?" A DAO or protocol treasury needs the opposite emphasis: transparency to token holders is itself a feature, so on-chain multisig with a mandatory timelock and at least one external signer is the right default, and the accountability that comes from rules you cannot quietly rewrite is worth the gas.

An active desk trading across many chains, or an exchange settling constant withdrawals, hits the limit of pure multisig fast: a separate contract per chain and a signature from every signer on every transfer does not scale to that throughput, which is exactly why institutions reach for MPC or a hybrid. Bitget is the warning label on that choice. Speed without friction is what let a spoofed backend drain it, so the model that buys you scale also buys you an unverifiable layer you then have to defend by other means. The table maps the common profiles to a sane starting point.

Best Practice 2: Diversify the Signers, Not Just the Count

Once the model is chosen, the quality of the signer set matters more than its size. The Security Alliance publishes a widely used set of secure multisig best practices that reads as a direct response to the casebook above: use at least three signers and a threshold above 50 percent, push to seven or more once a wallet holds more than $1 million, and never use an N-of-N scheme where losing one key freezes everything. The rules that follow are all about correlation. Signers should hold different hardware models from different manufacturers, so one firmware bug like Coldcard’s cannot take the whole set. They should be geographically separated. At least one should be an external party outside your own organization, and each multisig should get a dedicated signing address rather than reusing keys across wallets.

The reason count is not enough is that adding signers who share a laptop, a location, or a firmware version does not add independence; it adds coordination overhead while the real threshold stays at one. Humanity Protocol had two separate thresholds on two chains and still fell because the keys behind both were backed up to the same machine, collapsing a 3-of-6 and a 3-of-5 into a single point of failure. The same discipline applies to MPC: share-holders that all run in one cloud region, under one provider’s default configuration, are diverse on paper and correlated in reality. Diversity is a property of the failure modes, not the headcount.

Best Practice 3: Verify What the System Signs, Independently

Given that the approval layer is where the money leaves, verification is the single practice with the best return. For a multisig, that means every signer decodes the raw calldata and confirms the target contract, the function being called, and the parameters, rather than trusting a rendered summary. It means simulating the transaction before signing, with the caveat Radiant taught: simulation run on a machine the attacker already controls will happily show you a clean result, so the simulation is only as trustworthy as the device. The strongest version is to recompute the transaction hash on a separate, clean device and compare, which is exactly what open tools like Cyfrin’s clearsig and the community SafeLens project exist to do. Anything approving more than pocket money should also be confirmed out of band, a quick video call plus a signed message, because several of these thefts traced to a spoofed communication channel rather than the signing step itself.

MPC changes what you verify but not whether you verify. You cannot decode an on-chain approval that does not exist, so the object of scrutiny becomes the policy engine: what rules trigger an automatic signature, which addresses are whitelisted, what limits apply, and who can change those rules. Bitget failed precisely here, because the authorization logic accepted spoofed input and no human ever looked at the individual transfers. The lesson is symmetrical: multisig users must verify the transaction, MPC users must verify the policy, and both must confirm large or unusual movements through a channel the attacker does not control.

Best Practice 4: Buy Yourself Time

Almost every hack in the casebook shares one property: it was irreversible the instant the last approval landed, because nothing sat between authorization and execution. Time is the cheapest defense there is. A timelock that delays large or sensitive transactions by hours or days turns a silent drain into an alarm with a response window, and it is the control the Security Alliance flags as mandatory for high-value wallets. Drift is the cautionary tale in reverse: days before the theft, its security council migrated to a setup with no timelock at all, deleting exactly the detection window that would have exposed the pre-signed transactions before they executed. Convenience removed the brakes.

Bitget makes the same argument from the exchange side. Fifteen unauthorized transfers moved across seven chains in under an hour through an approval system built for speed. A per-destination rate limit, a hold on first-time counterparties, or a delay on transfers above a threshold would each have converted a 45-minute drain into a series of blocked or flagged events. Pair that with real monitoring, automated alerts on any transaction that touches the treasury, watched by someone who is actually on call, and you close the gap between a theft happening and anyone noticing. Timelocks, rate limits, whitelists, and durable-nonce hygiene are not glamorous, but they are the difference between an incident and a catastrophe.

Best Practice 5: Isolate the Keys and Rehearse the Recovery

A key is only as isolated as the machine that touches it. The Security Alliance recommends signing on dedicated, hardened, ideally air-gapped devices, and never mixing a signing key with a day-to-day laptop that browses the web and opens attachments. Radiant fell to a decoy PDF on a developer’s machine; Humanity fell because keys that were supposed to be independent shared one laptop. The rule that prevents both is boring and absolute: signing keys live on devices that do nothing else, and backups of different keys never rest in the same place.

Isolation is only half the job. The other half is planning for the day a signer quits, dies, loses a device, or is compromised mid-transaction, because a multisig with an unreachable signer can become a wallet no one can move. The Security Alliance now publishes an auditable multisig operations certification that formalizes this: a named operations owner, a full signer inventory kept current, quarterly access reviews, fast offboarding for departed signers, documented communication channels, and rehearsed emergency playbooks with reachability tests and annual drills. Most teams treat recovery as something to figure out during the emergency. The certification exists because that is exactly when it is too late.

Best Practice 6: The 2026 Answer Is Increasingly Both

The framing of multisig versus MPC is starting to feel dated, because the serious custody operations have stopped choosing. Safe notes that "most production-grade custody systems today combine both MPC and multisig wallets," using each where its strengths land. The custody firm ChainUp calls this the strategic convergence of the two and describes a defense-in-depth pattern in which an on-chain 3-of-5 multisig provides transparent, auditable governance logic while each individual signing key is itself protected by MPC, so no single key exists to steal at any layer. You get the multisig’s public, enforceable rule and the MPC share’s resistance to key theft at the same time.

The point of the hybrid is not to stack buzzwords; it is to make the two models cover each other’s blind spots. The on-chain multisig gives you the verifiable approval that pure MPC lacks. The MPC-protected keys remove the whole-key-on-a-device risk that pure multisig carries. What the hybrid does not do is dissolve the trust question, which is the same one that hangs over who actually controls your staked ETH: you still have to know who holds what, whose infrastructure the shares run on, and who can change the policy. Convergence upgrades the machinery. It does not retire the discipline.

Who Is Actually on the Hook: The SEC Custody Gap

For US readers there is a regulatory backdrop worth understanding, because it explains why none of this is someone else’s problem to solve. The Advisers Act custody rule, Rule 206(4)-2, requires registered investment advisers to keep client assets with a qualified custodian. 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 private-key-management and cybersecurity policies, SOC 1 and SOC 2 audits, asset segregation, and no rehypothecation without consent, as summarized in a legal analysis by Hunton. What the guidance pointedly did not do is resolve whether assets held in a multisig or MPC arrangement satisfy the custody rule at all. The signing architecture that this entire article is about sits in a regulatory gray zone.

The more important point is that not one hack in the casebook happened at an SEC-regulated custodian. Bybit, WazirX, Drift, Humanity, Liquid, and Bitget were all outside that perimeter. Bitget’s users were made whole by a voluntary protection fund, not a regulated guarantee, and a fund is only as good as the balance sheet behind it on the day it is needed. If you run your own multisig, or trust an offshore exchange’s automated approval layer, there is no regulator standing behind the keys. The operational controls in this article are not compliance theater you can delegate. They are the whole defense, and they belong to whoever holds the wallet.

A Practical Checklist Before You Fund the Wallet

Distilled from the casebook and the frameworks above, here is the short version worth pinning up before any shared wallet holds real money.

• Choose the model for your threat, not the trend: multisig for transparency and single-key survival, MPC or a hybrid for cross-chain scale and throughput.
• Use at least three signers and a threshold above 50 percent; move to seven or more above $1 million; never run an N-of-N that one lost key can freeze.
• Make signers genuinely independent: different hardware makers, different locations, at least one external party, a dedicated address per wallet, and no shared laptops or co-located backups.
• Turn on clear signing, decode the raw calldata, recompute the transaction hash on a clean device, and confirm anything large through a channel the attacker does not control.
• For MPC, verify the policy engine, the whitelists, and who can change the rules, not only the individual transaction.
• Put time between authorization and execution: timelocks on high-value moves, per-destination rate limits, and holds on first-time counterparties.
• Monitor the treasury with automated alerts that a real person on call actually watches.
• Sign only on dedicated, hardened, air-gapped devices that do nothing else.
• Write and rehearse a recovery plan for a lost or compromised signer before you need it.
• Remember no regulator backstops a self-run wallet or an offshore exchange; the controls are yours.

Frequently Asked Questions

Is multisig or MPC safer for crypto custody?

Neither is inherently safer; they concentrate risk in different places. A multisig keeps its rules on-chain and public, so its weak spot is the approval screen a human has to read. MPC never assembles a full key, so its weak spot is the off-chain infrastructure you cannot audit. The right choice depends on your threat model, and most serious custody operations in 2026 combine both.

Did the Bitget hack steal private keys?

No. Bitget said the attackers never stole a private key or forged a customer withdrawal. They compromised a backend system in the exchange’s wallet infrastructure and fed it spoofed transaction data, so its automated approval process released about $387.5 million across eight blockchains. Cold wallets were untouched, and a user protection fund covered customer balances.

What is blind signing and how do I avoid it?

Blind signing is approving a transaction you cannot actually read, usually shown as opaque hex or a friendly summary you have no way to verify. You avoid it with clear signing standards like ERC-7730, by decoding the raw calldata yourself, by simulating the transaction on a clean device, and by recomputing the transaction hash independently before you approve.

How many signers should a multisig have?

The Security Alliance recommends at least three signers with a threshold above 50 percent, rising to seven or more once a wallet holds more than $1 million, and never an N-of-N setup that one lost key can freeze. Independence matters more than the raw number: different hardware makers, different locations, and at least one external signer.

Could a timelock or hardware wallet have prevented these hacks?

Hardware wallets help but are not enough on their own, since Radiant and Coldcard both failed despite them. The more decisive control is time. Timelocks, rate limits, and active monitoring turn a silent drain into an alarm someone can answer, which is why Drift removing its timelock days before its hack was so costly.

Anneke de Vries covers wallet security and on-chain exploits for HOGE Wire.