What Are the Risks of Multi-Sig Wallets?

Is a Multisig Wallet Safe? The answer: a multisig wallet can meaningfully raise the bar for attackers, but it is not an “absolutely safe” vault.

A regular wallet is typically controlled by a single private key. If that key is leaked or lost, the assets can be stolen or become permanently unrecoverable. A multisig wallet instead uses an M-of-N scheme — for example “3-of-5” — where a transaction can only execute once at least 3 of the 5 signers have provided a valid signature.

This design reduces the risk of a single point of failure, but it also shifts the risk from “one person and one private key” to “multiple signers, multiple devices, a smart contract, and a governance process.” Some vendors in the industry approach this exact problem from a different angle — for instance, Safeheron compares MPC wallets with multisig wallets on its technical blog, pointing out that multisig has structural limitations around coordination efficiency, key recovery, and smart contract dependency.

What Is a Multisig Wallet? How It Actually Works

Before diving into the risk analysis, it’s worth pinning down how a multisig wallet actually works, because the risk profile differs depending on the implementation.

Technically, multisig wallets fall into two broad categories. The first is native to the blockchain protocol layer — for example, Bitcoin’s P2SH/P2WSH multisig addresses, where the signing rules are written directly into the transaction script without an additional smart contract. The second is implemented via a smart contract — the most common example in the Ethereum ecosystem being Gnosis Safe (now Safe{Wallet}), where the signature threshold, owner list, Guards, and modules are all managed and enforced by an on-chain contract. Institutions and DAOs tend to favor the latter for its flexibility, but that extra layer of contract code is exactly what introduces the smart contract vulnerability risk discussed later in this article.

In terms of use cases, multisig wallets typically show up in four scenarios: DAO or community treasuries, where several core members must jointly approve spending to prevent any single person from moving funds unilaterally; exchange or custodian cold wallets, where multisig distributes internal operating authority as part of risk control; family trusts, co-founded ventures, or shared marital assets, where “joint ownership, joint decision-making” is required; and protocol or cross-chain bridge admin permissions, where multisig gates high-risk actions like upgrades and pauses. Different scenarios call for different thresholds, signer selection, and contingency plans — a thread that runs through the rest of this article.

1. Human and Social Engineering Risk

The diagram below maps out the main risks across the human, technical, and operational layers — each is examined in detail below:

The weakest link in a multisig wallet is rarely the cryptography — it’s the signers themselves, for a few reasons:

The weakest link in a multisig wallet is rarely the cryptography — it’s the signers themselves, for a few reasons:

1. Phishing and Mis-Signed Transactions

Attackers can use phishing emails, spoofed websites, fake customer support, or impersonation of a colleague or partner to trick a signer into approving a malicious transaction.

A multisig contract can only verify that a signature is valid — it has no way to tell whether the signer was deceived. If enough members to meet the threshold fail to carefully verify a transaction, a malicious action can still be executed “legitimately.”

So multisig is not a license to sign carelessly. If anything, the more people involved, the more a team needs a unified transaction-verification process.

2. Insider Abuse and Privilege Escalation

An attacker doesn’t necessarily need to steal every private key. They can also bribe an insider, take over a team member’s account, or trick an administrator into adding a malicious address as a new owner or signer.

The following high-privilege actions deserve especially tight control:

• Adding or removing signers;
• Changing the signature threshold;
• Installing wallet modules;
• Swapping the Guard;
• Executing contract upgrades;
• Initiating high-risk calls such as delegatecall.

Any permission change should go through multi-person review — it should never be treated like a routine transfer.

3. The Bybit Incident: A Security Warning

The 2025 Bybit crypto asset theft is a textbook example of multisig supply-chain risk.

Based on publicly disclosed information, the attackers did not break the multisig contract directly. Instead, they compromised the development environment behind the wallet service and tampered with the front end. What the signers saw did not match what was actually being executed, and they ended up approving a hijacked transaction. This shows that even when neither the private keys nor the smart contract itself are compromised, the front-end page, developer devices, domains, and software dependencies can still be the attack surface. For high-value transactions, checking the transaction summary on a webpage simply isn’t enough.

It’s worth noting that this exact pattern — “what’s displayed doesn’t match what’s actually signed” — is a defense priority for institutional-grade wallet providers. For example, Safeheron’s published security architecture emphasizes a “what-you-see-is-what-you-sign” integrity check combined with address monitoring, specifically to ensure that what’s confirmed on-chain matches exactly what the user saw and authorized on their device. That approach is a useful reference when a team is building its own verification process: whichever wallet solution you use, there should be a verification step independent of the front-end page.

2. Smart Contract and Technical Risk

Many multisig wallets rely on a smart contract to manage assets. If the contract, its upgrade mechanism, or an external component has a vulnerability, extra private keys cannot prevent the loss.

1. Smart Contract Vulnerabilities

The 2017 Parity multisig wallet incident is one of the most famous cases. A vulnerability in Parity’s related contracts first led to roughly 150,000 ETH being stolen. A few months later, a separate flaw caused the core library contract to be accidentally destroyed, permanently freezing more than 510,000 ETH.

This incident shows that a multisig wallet’s security depends not only on its signers, but also on whether the underlying code is sound.

When choosing a multisig solution, it’s worth checking closely:

• Whether the contract has been independently audited;
• Whether it has run for a long time and withstood real-world scrutiny;
• Whether there’s ongoing maintenance and a bug-bounty program;
• Whether the contract is upgradeable, and who controls the upgrade permission;
• Whether it depends on unaudited modules or external contracts.

To judge whether a given security audit is actually credible, it helps to look at industry best practice: is the auditor a firm with a public track record, does the audit cover multiple version iterations, and is it backed by recognized compliance certifications? As one example, Safeheron’s published audit and certification record includes multiple rounds of audits by SlowMist covering its client and web console, an audit by Kudelski Security of its MPC algorithm library, audits by Least Authority of its MPC-ECDSA algorithm, and a dedicated audit by Cure53, alongside ISO/IEC 27001:2022 and SOC 2 Type II certification. This pattern — several independent firms, multiple versions, ongoing rolling audits — is a reasonable benchmark for evaluating whether any custody or signing solution, multisig contract or otherwise, is trustworthy.

2. Over-Concentrated Permissions

If a single multisig address simultaneously controls a large pool of assets, a cross-chain bridge, protocol upgrade rights, and emergency admin permissions, it becomes a new single point of failure in its own right.

If that wallet is compromised, the fallout can extend well beyond one account — potentially affecting multiple protocols or an entire ecosystem.

Institutions should, where possible, separate day-to-day funds, cold reserves, contract upgrade rights, emergency pause rights, and cross-chain bridge management into distinct wallets. That way, even if one wallet has a problem, the blast radius stays contained.

3. Front-End and Supply-Chain Attacks

Users typically create and sign multisig transactions through a webpage, but the front end, browser extensions, domains, APIs, and third-party dependencies can all be tampered with.

For high-value transactions, signers should independently verify:

• The recipient address and amount;
• The target contract address;
• The actual method being called;
• The calldata;
• Whether it includes a delegatecall;
• Whether it changes the owner list, threshold, Guard, or modules.

If a hardware wallet can’t fully display the critical details, pause the signing process and verify through another tool.

3. Operational and Governance Risk

Even without a hacker involved, misconfiguration, lost keys, or an unreachable team can freeze assets just as effectively.

1. Lost Keys Causing a “Deadlock”

Take a 3-of-5 multisig as an example: if 3 or more signers permanently lose their keys, the remaining keys can no longer reach the signature threshold, and the assets may be locked forever.

Common causes include:

• A damaged hardware wallet;
• A lost seed phrase or backup;
• A signer leaving the organization or becoming unreachable;
• A signer being incapacitated;
• No succession or handover plan in place.

Multisig doesn’t remove the need for backups — every signer should build an independent, secure, and tested recovery plan. This is also a structural weakness of the multisig contract model itself: the threshold mechanism improves security, but it inherently introduces the risk that losing “just enough” keys can lock the whole wallet — something worth weighing carefully when evaluating the technology.

2. Decision Gridlock

If a key signer becomes unreachable, refuses to sign, or disagrees with a transaction, the wallet can become unusable in practice.

A threshold set too low weakens security; one set too high increases coordination overhead and the risk of frozen funds.

Teams should define in advance:

• Each signer’s responsibilities;
• The normal approval process and its timeline;
• How urgent transactions are handled;
• How a departing signer is replaced;
• The contingency plan if someone becomes unreachable or a key is compromised.

3. Misconfiguration

Adding the wrong address, setting an unreasonable threshold, installing an unaudited module, or mistakenly sending assets to an incompatible network can all cause serious losses.

Because on-chain transactions are generally irreversible, management actions like the signer list, threshold, and security modules should go through at least two independent rounds of review.

4. How to Use a Multisig Wallet More Safely

To help you use a multisig wallet more safely, here are seven practical recommendations addressing the human, technical, and operational risk layers:

1. Diversify Devices and Vendors

Avoid having every signer use the same hardware wallet brand, model, or batch. Using devices from multiple vendors reduces the risk that a single firmware or supply-chain flaw compromises every key at once.

Also avoid storing multiple keys on the same computer, in the same browser wallet, or in the same physical location.

2. Set a Sensible Threshold

A higher M-of-N isn’t automatically safer — it’s a trade-off between security and usability.

For example, 2-of-3 suits a small team, while 3-of-5 fits better for a mid-sized institution or a DAO treasury. For very large cold reserves, a higher threshold can make sense, but only alongside a solid recovery and handover plan.

3. Use Mature Contracts and Security Components

Choose an officially supported, audited, and actively maintained multisig contract version.

For high-value wallets, consider configuring a Guard, address whitelist, transaction limits, delayed execution, and anomaly monitoring as needed. But a Guard is itself a piece of code — misconfiguring it or using an unaudited version can just as easily lock the wallet.

4. Independently Verify Every Transaction

Signers shouldn’t rely solely on what a webpage shows. For large transfers, approvals, or permission changes, independently verify through a hardware wallet, a block explorer, or a transaction simulation tool.

Watch especially for these operations:

• approve and permit;
• enableModule;
• setGuard;
• changeThreshold;
• delegatecall;
• Contract upgrades;
• Unlimited allowance approvals.

5. Review Wallet Permissions Regularly

Teams should periodically review the signer list, threshold, Guard, enabled modules, token approvals, and admin permissions.

Revoke approvals that are no longer needed promptly — a long-forgotten “zombie permission” is exactly the kind of thing an attacker looks for.

6. Build an Emergency Plan

Before depositing significant assets, test the full workflow with a small amount first: creating a transaction, collecting signatures, executing it, and recovering keys.

Teams should also regularly drill for scenarios like an unreachable signer, a damaged device, an inaccessible front end, a suspected key leak, or an urgent asset migration.

7. Consider MPC as an Alternative or Complementary Technology

Some of multisig’s limitations — dependency on an on-chain contract, the fees and coordination delays from multiple transactions, and the cascading risk from a single lost key — are inherent to the architecture itself, and management discipline alone can’t fully eliminate them.

MPC (multi-party computation) wallets offer a different technical approach to these pain points: the private key stays split into shards distributed across multiple parties and is never reconstructed on a single device; signing happens through off-chain cryptographic collaboration rather than an on-chain multisig contract, so the vulnerability and accidental-destruction risks tied to multisig contracts simply don’t apply. MPC also supports asynchronous signing and a single on-chain submission, which is typically more efficient and cheaper in gas than traditional multisig. As one example, Safeheron’s MPC self-custody solution uses a dual-layer architecture combining MPC with a TEE (Trusted Execution Environment), paired with a policy engine, whitelisting, and AML/KYT risk controls, while still giving users the ability to self-recover offline from their key shares — reducing dependency on any single provider.

It’s worth stressing that MPC and multisig aren’t mutually exclusive, and neither is categorically “better.” They’re two different technical approaches to the same underlying problem — single-point key risk — each suited to different scenarios. For DAO governance or any case that needs publicly verifiable on-chain signing logic, a multisig contract still has irreplaceable advantages. For institutional use cases prioritizing higher throughput, lower on-chain costs, or less reliance on trust in the smart contract itself, MPC is worth including in the comparison. Teams can weigh their own asset scale, team distribution, and compliance requirements — and can even combine the two, for example using multisig for cold reserves and MPC for day-to-day operating funds.

Frequently Asked Questions

Can a multisig wallet be hacked?

Yes. Multisig raises the bar for an attack, but it can’t fully prevent phishing, mis-signed transactions, compromised devices, front-end tampering, insider abuse, or smart contract vulnerabilities.

Is a multisig wallet safer than a cold wallet?

They solve different problems. A cold wallet is about keeping the private key offline; a multisig wallet is about distributing control. For large holdings, it’s common to combine multisig with several independent hardware wallets.

Which is safer, multisig or MPC?

Neither is categorically safer — they have different risk models. Multisig’s security rests on a smart contract and an on-chain threshold mechanism; its advantage is that the signing logic is transparent and verifiable on-chain, while its risk points are contract bugs, coordination overhead, and deadlock from lost keys. MPC’s security rests on cryptographic secret-sharing and hardware isolation (such as a TEE); the private key is never fully reconstructed and there’s no dependence on an on-chain contract, but it places higher demands on the provider’s technical implementation, audit rigor, and compliance certification. In practice, it’s worth examining both the underlying risk model of the architecture itself and whether the solution has passed independent third-party audits and holds recognized certifications such as ISO 27001 or SOC 2 — a vendor like Safeheron, which publicly discloses multiple rounds of independent audits and certifications, is a useful reference point for that kind of evaluation.

If a multisig wallet’s private keys are lost, can they be recovered?

It depends on whether the remaining valid keys can still reach the signature threshold. If the number of valid keys falls below the threshold and no recovery mechanism was set up in advance, the assets may become permanently unrecoverable.

Do everyday individual users need a multisig wallet?

It depends on the asset size and the use case. For a small, personal, day-to-day wallet, a single-signature hardware wallet with good backup habits is usually enough — adding multisig would mostly just add operational complexity. But for shared family assets, a founding team’s shared funds, or any holding large enough that a single point of failure would be hard to absorb, the extra security margin from multisig or MPC-based solutions is worth the added learning curve and management overhead.

Conclusion

By distributing the private key and control, a multisig wallet can meaningfully reduce the risk that comes with a single leaked key — but it also introduces new security considerations around people, smart contracts, supply chains, and organizational governance.

A genuinely reliable setup requires getting several things right at once — distributing keys, verifying independently, isolating permissions, reviewing regularly, and having a recovery plan — rather than simply relying on the “multisig” label. On the technology-selection side, whether a team sticks with a well-audited, long-running multisig contract or brings in an alternative architecture like MPC as a complement, the underlying principle is the same: carefully evaluate the risk model of the underlying technology, favor solutions backed by independent audits and compliance certifications, and build a complete operational and governance process around it. Book a consultation now to learn more about Safeheron’s MPC + TEE solution.

Multisig raises the bar for an attacker — it does not provide absolute safety. Only by combining the right technology, sound operating practices, and solid governance can you meaningfully reduce the risk of crypto assets being stolen or permanently frozen.