MPC Wallets vs Multisig After the Bybit Hack: Fireblocks Controls Trillions in Institutional Volume, Safe Had a Developer Machine Compromised, and the Debate Over Which Architecture Is Actually Safer Just Got Real

crypto_chris · February 7, 2026, 9:57pm

The $1.4B Wake-Up Call

The Bybit hack didn’t just drain $1.4 billion from one of the world’s largest exchanges. It ripped open a debate that institutional crypto has been quietly avoiding for years: are we using the right wallet architecture to secure digital assets at scale?

The attack vector was devastating in its simplicity. The attackers didn’t break cryptography. They didn’t find a zero-day in Ethereum. They compromised a developer machine connected to Safe{Wallet}'s infrastructure and manipulated the signing interface that Bybit’s team trusted to verify transactions. The multisig did exactly what it was designed to do – it collected the required signatures. The problem was that the humans providing those signatures were looking at a compromised UI that showed them one transaction while executing another.

This is now the single largest crypto theft in history, and it happened to a team that was following what most of the industry considers best practices.

The Market Just Repriced Custody Risk

From a trading and risk perspective, this hack fundamentally changes how institutions should price custody risk. Before Bybit, the market’s default assumption was that multisig wallets – particularly those using audited smart contracts like Safe – represented the gold standard for institutional custody. That assumption is now broken.

Let me lay out the competitive landscape as it stands today:

MPC (Multi-Party Computation) providers:

Fireblocks dominates institutional custody, processing trillions of dollars in cumulative transaction volume across 1,800+ institutional clients. SOC 2 Type II certified, ISO 27001 compliant. Their MPC-CMP protocol distributes key shards across multiple parties with no single point of failure.
Copper offers ClearLoop for off-exchange settlement, targeting hedge funds and trading firms.
BitGo serves as qualified custodian with MPC capabilities, processing substantial institutional volume.
Coinbase Prime provides MPC-based custody for institutional clients, leveraging their regulatory standing.
Ceffu (formerly Binance Custody) offers MPC custody with deep exchange integration.

Multisig providers:

Safe{Wallet} (formerly Gnosis Safe) secures over $100 billion in assets across 30,000+ accounts. Open-source, transparent, on-chain verifiable. But now has a confirmed supply chain compromise on its record.
Squads on Solana is pushing on-chain multisig as a superior alternative to MPC, emphasizing transparency and verifiability.

Why This Debate Matters for Your Portfolio

Here’s the uncomfortable truth that most custody discussions avoid: the choice between MPC and multisig is not purely a technical decision. It’s a risk-pricing decision.

MPC wallets offer several advantages that matter to institutional investors:

Cost efficiency: No on-chain transactions for key management operations, which means lower gas costs at scale
Privacy: Key shard distribution happens off-chain, so attackers can’t see your signing topology
Flexible key rotation: You can rotate key shards without changing the on-chain address, which is operationally critical for institutions that have addresses hardcoded into compliance systems
Flexible signer management: Adding or removing signers doesn’t require on-chain transactions

Multisig offers different advantages:

On-chain verifiability: Anyone can audit the signing requirements by reading the smart contract
Transparency: The governance structure is publicly visible, which matters for DAOs and public treasuries
No single vendor dependency: You’re not locked into one provider’s MPC implementation
Smart contract enforcement: The rules are enforced by code, not by a vendor’s infrastructure

The Supply Chain Attack Surface Problem

What the Bybit hack exposed is that multisig’s greatest strength – its reliance on a signing interface for human verification – is also its greatest weakness. The security of a multisig is only as good as the UI that signers trust to display accurate transaction data.

MPC wallets aren’t immune to this either. If a Fireblocks customer’s policy engine were compromised, the result could be similar. But MPC architectures generally have a tighter integration between the signing process and the verification layer, because both happen within the same vendor’s infrastructure. There’s no browser-based UI sitting between the key holders and the transaction.

The counterargument is that this tight integration creates its own risk: vendor lock-in and single points of failure at the infrastructure level. If Fireblocks itself were compromised, the blast radius would be enormous given the volume they process.

What I’m Watching

The trend I’m tracking most closely is the move toward self-hosted, open-source MPC implementations. Several institutional players are now evaluating open-source MPC libraries that they can run on their own infrastructure, giving them the cryptographic advantages of MPC without the vendor dependency risk.

There’s also a growing interest in hybrid approaches that combine MPC key management with multisig on-chain verification. The idea is to use MPC for the key generation and shard distribution, but then require multisig-style on-chain confirmations for high-value transactions. This gives you the privacy and flexibility of MPC with the transparency and verifiability of multisig.

The Bybit hack didn’t prove that multisig is broken. It proved that any system that relies on humans verifying transactions through a potentially compromised interface is broken. The question now is which architecture gives us the best tools to minimize that attack surface.

I’m genuinely curious what the security researchers and protocol architects in this community think. Is the institutional market overreacting by moving toward MPC? Or is the supply chain risk to multisig signing interfaces a fundamental architectural flaw that can’t be patched?

security_sophia · February 7, 2026, 9:58pm

Threat Model Analysis: MPC vs Multisig Security Properties

Chris, excellent framing of the market dynamics. Let me put on my security researcher hat and break down the actual threat models here, because the discourse around this topic has been frustratingly imprecise. The Bybit hack doesn’t prove that multisig is inherently less secure than MPC. What it proves is that the attack surface has shifted from cryptographic primitives to the operational layer, and neither architecture is immune.

Decomposing the Attack Vectors

Let me structure this as a proper threat model comparison.

Multisig (Smart Contract-Based) Threat Surface:

Smart contract vulnerabilities: The contract itself can have bugs. Safe has been audited extensively and battle-tested with $100B+ in assets, but no code is provably bug-free outside of formally verified components.
UI/signing interface compromise (the Bybit vector): Signers rely on a frontend to decode and display transaction data. If that frontend is compromised – whether through a supply chain attack on the developer’s machine, a malicious browser extension, or DNS hijacking – signers will approve transactions they don’t understand.
Social engineering: With on-chain transparency, attackers can identify the exact signers and their threshold. This makes targeted phishing and social engineering campaigns more efficient.
On-chain governance manipulation: If the multisig upgrade logic is exposed, attackers can potentially manipulate the contract’s own governance to lower thresholds or add malicious signers.

MPC (Off-Chain Computation) Threat Surface:

Implementation vulnerabilities: MPC protocols are cryptographically complex. The GG18, GG20, and CMP protocols each have different security assumptions. A bug in the threshold signing implementation could be catastrophic, and unlike smart contracts, the code running the MPC ceremony is not publicly auditable in most commercial implementations.
Key shard storage: Each party stores their key shard. If the shard storage is compromised across enough parties to meet the threshold, the key is reconstructed. This is functionally equivalent to compromising enough multisig signers, but the attack is invisible – there’s no on-chain trace.
Vendor infrastructure compromise: For hosted MPC solutions like Fireblocks, a compromise of the vendor’s infrastructure could affect all customers simultaneously. This is the systemic risk Chris mentioned, and it’s real.
Collusion attacks: MPC assumes honest-majority or dishonest-minority models depending on the protocol. If enough key shard holders collude, the system fails silently.

The Critical Distinction Nobody Is Making

Here is what I think the industry is getting wrong in this debate: the Bybit hack was not a failure of multisig cryptography or smart contract logic. It was a failure of the operational security layer around the signing process.

The Safe smart contracts performed exactly as designed. The 3-of-5 threshold was met. The signatures were valid. The contract executed the transaction faithfully. The failure was that the transaction data presented to the human signers was falsified at the interface level.

Now, would an MPC architecture have prevented this specific attack? Possibly, but not necessarily. Here is why:

In a Fireblocks-style MPC setup, the transaction construction happens within the vendor’s policy engine, which provides an additional verification layer. The signers interact with the Fireblocks API or application rather than a browser-based frontend, which reduces (but does not eliminate) the UI compromise surface.
However, if an attacker compromised the Fireblocks policy engine itself – or the API integration between the customer and Fireblocks – the result would be identical: transactions would be signed that the human operators did not intend to authorize.
The difference is that Fireblocks has SOC 2 Type II certification and ISO 27001 compliance, which means their infrastructure undergoes regular third-party security audits. Safe’s smart contracts are audited, but the surrounding infrastructure (frontend, build pipeline, developer machines) was not held to the same standard.

The Auditability Trade-off

This is where I part ways with the MPC maximalists. One of the most important security properties of multisig is on-chain verifiability. Anyone can inspect the Safe contract, verify the signer set, check the threshold, and audit every historical transaction. This transparency enables:

Independent security monitoring by third parties
Public accountability for custodians
Post-incident forensic analysis (which is exactly how the Bybit hack was quickly identified and traced)

MPC provides none of this. The key generation ceremony, shard distribution, and signing process all happen off-chain. You have to trust the vendor’s claims about their implementation, their infrastructure security, and their internal access controls. For an industry built on the principle of “don’t trust, verify,” this should be deeply uncomfortable.

What Would Actually Fix This

Rather than abandoning multisig for MPC, I would argue the industry needs to invest in:

Hardware-level transaction verification: Signers should verify transaction details on a trusted hardware device (like a Ledger or Trezor) that cannot be compromised by a browser-based attack. The fact that Bybit’s signers were approving transactions through a web UI rather than verifying the raw calldata on a hardware wallet is the real failure.
Independent transaction simulation: Before signing, each signer should independently simulate the transaction using their own infrastructure to verify the expected state changes. Tools like Tenderly and Blockaid already offer this capability.
Time-locked execution with cancellation windows: High-value transactions should have mandatory time delays during which independent monitoring systems can flag suspicious activity and initiate cancellation.
Multi-channel verification: Transaction details should be verified through multiple independent channels – not just the signing UI. This could include SMS verification, email confirmation, or even phone calls between signers.

The Bybit hack is a wake-up call, but the lesson is not “switch to MPC.” The lesson is that operational security around the signing process needs the same level of rigor as the cryptographic primitives themselves, regardless of which architecture you choose.

blockchain_brian · February 7, 2026, 9:59pm

The Architecture Debate Goes Deeper Than Most People Realize

Sophia’s threat model breakdown is outstanding, and I want to build on it by examining the protocol-level architecture of both approaches, because I think there are fundamental cryptographic trade-offs being obscured by the marketing narratives on both sides.

MPC: The Cryptographic Elegance and Its Hidden Costs

Multi-Party Computation for threshold signing is genuinely elegant cryptography. The core idea – multiple parties jointly compute a signature without any single party ever reconstructing the full private key – is a beautiful application of secure computation theory. But the devil is in the implementation details.

The protocol landscape is fragmented and evolving:

The dominant MPC-TSS (Threshold Signature Scheme) protocols in production today are:

GG18/GG20 (Gennaro-Goldfeder): The original practical threshold ECDSA protocols. GG18 requires an honest majority, GG20 relaxed this to dishonest majority but introduced additional rounds of communication.
CMP (Canetti-Makriyannis-Peled): What Fireblocks uses. Reduces the number of communication rounds and supports pre-signing, which is critical for latency-sensitive applications. But it adds complexity to the key refresh protocol.
FROST (Flexible Round-Optimized Schnorr Threshold signatures): Works with Schnorr signatures rather than ECDSA, which makes it natively compatible with Bitcoin’s Taproot and Ed25519-based chains. Two-round signing protocol, significantly simpler than ECDSA-based alternatives.

Each of these protocols has different security assumptions, different communication patterns, and different failure modes. This is not a mature, standardized technology. There is no equivalent of the ERC-4337 standard for MPC wallet implementations. Every vendor rolls their own, and the security proofs are only as good as the implementation fidelity.

Here is a concrete example of why this matters: in 2023, researchers from Fireblocks themselves discovered critical vulnerabilities in multiple MPC-TSS implementations (including GG18 and GG20) that could allow a single malicious signer to extract the full private key. They called it “BitForge.” The vulnerability existed in production implementations used by major custodians. It was patched, but it illustrates that the cryptographic complexity of MPC creates an attack surface that is qualitatively different from smart contract bugs – it is harder to find, harder to audit, and harder to verify has been correctly fixed.

Multisig: The Power and Limitations of On-Chain Enforcement

Smart contract-based multisig has a fundamentally different architecture philosophy. Instead of distributing the computation off-chain, it distributes the authorization on-chain. Each signer has their own complete private key. The smart contract enforces the threshold requirement by collecting and verifying individual signatures before executing a transaction.

The architectural advantages are real:

Composability: A multisig is a smart contract, which means it can interact with other smart contracts natively. It can hold ERC-20 tokens, interact with DeFi protocols, participate in governance votes, and serve as an owner of other contracts. MPC wallets produce a standard EOA (Externally Owned Account), which has more limited on-chain capabilities without additional infrastructure.
Upgradeability and programmability: Safe supports modules that extend its functionality – spending limits, recovery mechanisms, automated transactions, role-based access control. This programmability is not possible with a pure MPC approach, because the MPC wallet appears as a regular EOA on-chain.
Chain-agnostic verification: The multisig logic is enforced by the blockchain’s execution environment, which means it works the same way on every EVM chain. MPC implementations need to support each chain’s specific signature scheme and transaction format, which is why MPC providers often lag behind in supporting new chains.
Decentralization alignment: As Sophia noted, the on-chain nature of multisig means no single vendor controls the infrastructure. If Safe{Wallet}'s frontend disappears tomorrow, anyone can interact with a Safe contract directly through Etherscan, a custom frontend, or a command-line interface. The contract and the assets are on-chain and permissionless. If Fireblocks goes down, what happens to the key shards?

The Decentralization Trade-off Nobody Wants to Discuss

This is the part of the debate that I think gets closest to the philosophical core of what we are building in crypto.

MPC-based custody, as currently implemented by the major providers, is fundamentally a centralized service. Yes, the key shards are distributed. But the protocol implementation, the infrastructure, the policy engine, the key refresh mechanism – all of this is controlled by a single vendor. When people say “Fireblocks processes trillions in volume,” what they are really saying is that a single company’s infrastructure sits in the critical path of trillions of dollars in transactions.

Compare this to Squads on Solana, which is explicitly positioning itself as the decentralized alternative. Squads Protocol v4 is open-source, on-chain, and permissionless. Every multisig operation – creation, signer management, transaction approval, execution – happens on-chain with full transparency. There is no vendor infrastructure to compromise because there is no vendor infrastructure at all. The protocol is the product.

Now, I am not naive about the trade-offs. Squads and Safe are not operationally equivalent to Fireblocks. Fireblocks provides a complete operational platform with policy engines, compliance integrations, exchange connectivity, and 24/7 support. A bare multisig contract does not give you any of that. But the question we should be asking is: can we build those operational layers on top of an on-chain foundation rather than around an off-chain one?

The Hybrid Architecture That Actually Makes Sense

I think the future is neither pure MPC nor pure multisig. Here is the architecture I would design for a billion-dollar treasury:

Layer 1 - On-chain multisig (Safe or Squads): This is the source of truth for authorization. The signer set, threshold, and execution logic are all on-chain and publicly verifiable.

Layer 2 - MPC-distributed individual keys: Each signer’s individual key is itself an MPC wallet, distributing that signer’s key across multiple devices or parties. This means compromising a single signer’s key requires compromising multiple MPC shards, not just stealing one private key.

Layer 3 - Hardware security modules: The MPC shards for each signer are stored in hardware security modules (HSMs) or secure enclaves, providing hardware-level protection against software-based key extraction.

Layer 4 - Independent verification infrastructure: Each signer runs their own transaction simulation and verification pipeline, completely independent of the signing UI. Before approving any transaction, the signer’s infrastructure independently fetches the transaction calldata from the mempool, simulates it, and compares the results to the expected behavior.

This layered approach gives you the on-chain verifiability and transparency of multisig, the key distribution benefits of MPC, hardware-level shard protection, and independent verification to prevent UI-based attacks.

Is this complex? Absolutely. Is it overkill for a 10-person startup? Definitely. But for organizations securing billions of dollars, this kind of defense-in-depth is not optional – it is the minimum viable security architecture.

The Bybit hack should not push us toward MPC or away from multisig. It should push us toward layered architectures that do not have single points of failure at any level of the stack.

blockchain_brian · February 7, 2026, 10:00pm

The Architecture Debate Goes Deeper Than Most People Realize

Sophia’s threat model breakdown is outstanding, and I want to build on it by examining the protocol-level architecture of both approaches, because I think there are fundamental cryptographic trade-offs being obscured by the marketing narratives on both sides.

MPC: The Cryptographic Elegance and Its Hidden Costs

Multi-Party Computation for threshold signing is genuinely elegant cryptography. The core idea – multiple parties jointly compute a signature without any single party ever reconstructing the full private key – is a beautiful application of secure computation theory. But the devil is in the implementation details.

The protocol landscape is fragmented and evolving:

The dominant MPC-TSS (Threshold Signature Scheme) protocols in production today are:

GG18/GG20 (Gennaro-Goldfeder): The original practical threshold ECDSA protocols. GG18 requires an honest majority, GG20 relaxed this to dishonest majority but introduced additional rounds of communication.
CMP (Canetti-Makriyannis-Peled): What Fireblocks uses. Reduces the number of communication rounds and supports pre-signing, which is critical for latency-sensitive applications. But it adds complexity to the key refresh protocol.
FROST (Flexible Round-Optimized Schnorr Threshold signatures): Works with Schnorr signatures rather than ECDSA, which makes it natively compatible with Bitcoin’s Taproot and Ed25519-based chains. Two-round signing protocol, significantly simpler than ECDSA-based alternatives.

Each of these protocols has different security assumptions, different communication patterns, and different failure modes. This is not a mature, standardized technology. There is no equivalent of the ERC-4337 standard for MPC wallet implementations. Every vendor rolls their own, and the security proofs are only as good as the implementation fidelity.

Here is a concrete example of why this matters: in 2023, researchers from Fireblocks themselves discovered critical vulnerabilities in multiple MPC-TSS implementations (including GG18 and GG20) that could allow a single malicious signer to extract the full private key. They called it “BitForge.” The vulnerability existed in production implementations used by major custodians. It was patched, but it illustrates that the cryptographic complexity of MPC creates an attack surface that is qualitatively different from smart contract bugs – it is harder to find, harder to audit, and harder to verify has been correctly fixed.

Multisig: The Power and Limitations of On-Chain Enforcement

Smart contract-based multisig has a fundamentally different architecture philosophy. Instead of distributing the computation off-chain, it distributes the authorization on-chain. Each signer has their own complete private key. The smart contract enforces the threshold requirement by collecting and verifying individual signatures before executing a transaction.

The architectural advantages are real:

Composability: A multisig is a smart contract, which means it can interact with other smart contracts natively. It can hold ERC-20 tokens, interact with DeFi protocols, participate in governance votes, and serve as an owner of other contracts. MPC wallets produce a standard EOA (Externally Owned Account), which has more limited on-chain capabilities without additional infrastructure.
Upgradeability and programmability: Safe supports modules that extend its functionality – spending limits, recovery mechanisms, automated transactions, role-based access control. This programmability is not possible with a pure MPC approach, because the MPC wallet appears as a regular EOA on-chain.
Chain-agnostic verification: The multisig logic is enforced by the blockchain’s execution environment, which means it works the same way on every EVM chain. MPC implementations need to support each chain’s specific signature scheme and transaction format, which is why MPC providers often lag behind in supporting new chains.
Decentralization alignment: As Sophia noted, the on-chain nature of multisig means no single vendor controls the infrastructure. If Safe Wallet’s frontend disappears tomorrow, anyone can interact with a Safe contract directly through Etherscan, a custom frontend, or a command-line interface. The contract and the assets are on-chain and permissionless. If Fireblocks goes down, what happens to the key shards?

The Decentralization Trade-off Nobody Wants to Discuss

This is the part of the debate that I think gets closest to the philosophical core of what we are building in crypto.

MPC-based custody, as currently implemented by the major providers, is fundamentally a centralized service. Yes, the key shards are distributed. But the protocol implementation, the infrastructure, the policy engine, the key refresh mechanism – all of this is controlled by a single vendor. When people say “Fireblocks processes trillions in volume,” what they are really saying is that a single company’s infrastructure sits in the critical path of trillions of dollars in transactions.

Compare this to Squads on Solana, which is explicitly positioning itself as the decentralized alternative. Squads Protocol v4 is open-source, on-chain, and permissionless. Every multisig operation – creation, signer management, transaction approval, execution – happens on-chain with full transparency. There is no vendor infrastructure to compromise because there is no vendor infrastructure at all. The protocol is the product.

Now, I am not naive about the trade-offs. Squads and Safe are not operationally equivalent to Fireblocks. Fireblocks provides a complete operational platform with policy engines, compliance integrations, exchange connectivity, and 24/7 support. A bare multisig contract does not give you any of that. But the question we should be asking is: can we build those operational layers on top of an on-chain foundation rather than around an off-chain one?