What the Bybit Exploit Reveals About Enterprise Custody

On February 21, 2025, Bybit lost approximately $1.5 billion in ETH from its Ethereum cold wallet. It was the largest single theft in digital asset history.

What makes this case instructive for enterprise custody teams: Bybit was using what most consider best-practice security. A Safe (formerly Gnosis Safe) multisignature wallet requiring three approvals, with each signer using a Ledger hardware wallet. The entire drain executed in under 15 minutes.

The attack did not break cryptography or steal private keys; it manipulated what the signers believed they were authorizing. The cryptographic layer was intact, but the human trust layer was compromised.

How the Attack Worked

The attack had four phases, each documented by independent forensic investigators:

• Infrastructure compromise: On February 4, 2025, attackers compromised a Safe{Wallet} developer’s macOS machine through a social engineering attack. Using the developer’s hijacked AWS session tokens, they gained access to Safe’s hosted frontend infrastructure.
• Transaction substitution: On February 19, the attackers injected malicious JavaScript into a single file serving Safe’s web interface. The code activated only for Bybit’s specific wallet addresses. When Bybit’s operators initiated a routine ETH transfer, the malicious JS silently replaced the transaction payload. The UI displayed a legitimate-looking transfer, but the actual payload contained instructions to transfer wallet ownership to attacker-controlled addresses.
• Blind signing: All three Ledger signers approved the transaction. Each hardware wallet displayed structured data fields but could not decode what the transaction’s data parameter actually did. The critical change from a standard call to a delegatecall was visible as a numeric parameter (operation: 1) but meaningless without decoded context. No signer could verify what they were actually authorizing.
• Drain: With ownership transferred via the delegatecall mechanism, the attacker signed and executed transactions draining all assets in under 15 minutes. Two minutes after the theft succeeded, the attackers removed the malicious code from Safe’s frontend.

The attack was later attributed to Lazarus Group, a North Korean state-sponsored threat actor, by the FBI and multiple on-chain investigators.

The Core Architectural Failure

The fundamental failure was a single one: all three signers trusted the same compromised web interface. Every other security measure Bybit had in place depended on the integrity of that interface. Once it was compromised, no downstream control could compensate.

Multisig protects against one compromised signer. It provides no protection when all signers are deceived by the same source. Three-of-three security collapsed to one-of-one.

Three properties of the underlying architecture made this collapse possible:

The UI was the single trust point. There was no independent system between the user interface and the signing event that could verify whether the displayed transaction matched the actual transaction. Every signer relied on the same compromised frontend. There was no policy engine, no address whitelist check, no server-side validation operating independently of the UI.

Blind signing is the default for complex Ethereum transactions. When a hardware wallet is asked to sign a complex smart contract interaction, it cannot fully decode and display what the transaction does. The signer hits Confirm because they trust the interface that presented the transaction. No display warned that the transaction would transfer control of a $1.5 billion wallet to an unknown address.

Ethereum’s delegatecall enabled full ownership takeover. This is the mechanism that turned a UI compromise into a total loss, rather than a single fraudulent transfer. The malicious transaction used delegatecall to replace the list of authorized signers with attacker-controlled addresses and reduce the required signatures to one. From that point, the attacker could drain everything unilaterally.

What Is delegatecall, and How Was It Exploited?

delegatecall is an Ethereum Virtual Machine opcode. When Contract A executes a delegatecallto Contract B, Contract B’s code runs using Contract A’s storage. This means Contract B can read and write Contract A’s state variables.

The standard legitimate use is proxy contract upgrades. A proxy contract stores data but holds no business logic. It uses delegatecall to forward all calls to a separate implementation contract. When an upgrade is needed, a designated admin changes the implementation pointer to a new contract version. Users keep interacting with the same proxy address while the logic behind it changes. In properly designed systems like OpenZeppelin’s Transparent Proxy pattern, only a designated admin contract can trigger this change.

In the Bybit exploit, the attackers abused this same mechanism. The malicious transaction called Safe’s execTransaction function with the operation parameter changed from 0 (standard call) to 1 (delegatecall), targeting an attacker-deployed contract. Because of delegatecall, this contract’s code executed in the context of Bybit’s wallet and overwrote the storage slot containing the wallet’s implementation pointer. This redirected all future calls to a draining contract controlled by the attacker.

Bitcoin’s UTXO Model Eliminates the Attack Class

Bitcoin’s transaction model removes the delegatecall attack class entirely.

In Ethereum’s account model, a smart contract maintains a persistent state that a single transaction can modify, including who controls the contract. delegatecall compounds this by allowing external code to execute within a contract’s own storage context.

Bitcoin uses a UTXO (unspent transaction output) model. Each UTXO is locked to a script that defines its spending conditions. Bitcoin’s Script language is stateless: there is no persistent storage, no global state to modify, and no concept of “changing ownership” through code execution. A transaction either satisfies the script’s spending conditions and consumes the UTXO, or it fails. Scripts validate; they never mutate.

Bitcoin Script is deliberately not Turing-complete. It has no loops, no state mutation, and no mechanism for delegated code execution. There is no opcode equivalent to delegatecall. An attacker cannot construct a transaction that rewrites who controls existing funds, regardless of what interface they compromise. The UTXO either spends according to its script, or it does not.

This is a structural property of Bitcoin’s design, present since its launch in 2009. It cannot be replicated by adding controls on top of Ethereum’s more flexible execution model.

Independent Validation: The Missing Layer

The fundamental failure at Bybit was the absence of an independent validation layer between the user interface and the signing event. What the signers saw was not what they signed. No system checked whether the actual transaction matched the intended transaction.

By contrast, if Blockstream’s enterprise custody architecture had been used, our architecture introduces three independent layers between a transaction request and the signing event:

Layer 1: Policy Engine. Every transaction passes through a policy engine that runs server-side within the client’s own infrastructure. The engine evaluates the actual transaction against configurable policies: destination address whitelists (most importantly), value limits, and role-based access controls. A compromised UI cannot override the policy engine because it operates independently of the frontend. In the Bybit scenario, the substituted payload would have failed policy validation before any signer saw it.

Layer 2: Multi-party approvers with clear view on what is signed and where funds are going. After policy validation, M-of-N human approvers confirm the transaction within the platform.

Layer 3: HSM signing. Private keys never leave hardware security modules controlled by the client. The HSM signs only after both policy layers have cleared. The entire signing stack runs inside the client’s perimeter. There is no third-party hosted frontend to compromise.

Each layer must be independently compromised for an attack to succeed. At Bybit, there was only one layer: a third-party hosted website.

Liquid: Separating Settlement from Cold Storage

The Bybit attack succeeded because the compromised interface had direct access to the custody wallet. Moving funds meant executing an on-chain transaction that directly exposed $1.5 billion in cold storage to the execution environment.

The Liquid Network provides architectural separation between institutional settlement operations and base-layer cold storage, directly addressing this exposure.

When bitcoin is pegged into Liquid, the underlying BTC is locked under a federation multisig scheme controlled jointly by institutional members (exchanges, custodians, financial institutions). An equivalent amount of LBTC (Liquid bitcoin) is issued on the Liquid sidechain. Settlement, trading, and smart contract execution happen on Liquid, while cold-storage bitcoin is never touched during normal operations.

To redeem bitcoin via peg-out, the federation must reach consensus. No single compromised party can drain the underlying reserves unilaterally. This is a structural security gate that no single-chain multisig can replicate.

In the Bybit scenario, an attacker who compromised a Liquid-based settlement interface would only affect LBTC movements within the sidechain environment. The cold-storage bitcoin would remain unexposed to the attack surface. The $1.5 billion loss was possible because the compromised UI had direct signing authority over the cold wallet itself. Liquid’s architecture eliminates that direct exposure by design.

Key Takeaways for Enterprise Clients

The Bybit exploit was a failure of UI trust and smart contract complexity, not cryptography. From it, five principles emerge for institutional custody teams:

• Hardware wallets alone are not sufficient for institutional cold storage. Signing must be preceded by an independent policy validation layer that evaluates the actual transaction, not the UI representation.
• Multisig is only as strong as the source of its signing interfaces. All signers using a weak external UI collapse M-of-N security to 1-of-1.
• Cloud-hosted frontend infrastructure is a critical vulnerability. On-premises deployment eliminates this entire attack class.
• Execution model flexibility is a liability in high-value custody. Bitcoin and Liquid (plus Simplicity contracts) have constrained execution models that remove delegatecall-class attacks by design, vastly improving on Ethereum’s complex smart contract interfaces.
• Custody infrastructure must assume a well-resourced attacker. Lazarus Group operates at nation-state level sophistication. The Bybit attack demonstrates surgical precision: injected code activated only for Bybit’s specific Safe address, indicating extensive prior reconnaissance.

Blockstream’s enterprise custody stack, built on Bitcoin-native infrastructure with independent policy validation, HSM-controlled signing, and the Liquid Network’s federated settlement model, directly addresses each of these architectural weaknesses.

How to Evaluate Enterprise Custody Solutions

The Bybit exploit shows that custody architecture can determine whether a sophisticated UI compromise can drain a cold wallet. The questions below help evaluate any enterprise custody provider, including Blockstream.

Does the provider offer:

• a server-side policy engine that can be deployed on-premises, inside the customer’s own infrastructure?
• an on-premises deployment option for the full signing stack, with no critical component running on third-party hosted infrastructure?
• customer-controlled HSMs that generate and hold private keys, with no key shares ever leaving the HSM boundary?
• a signing path with no dependence on an externally hosted web frontend?
• an independent pre-signing validation layer that checks the actual transaction against policy before a signer is asked to confirm?
• an underlying chain with no delegatecall-equivalent attack surface, so a single transaction cannot rewrite control of a wallet?
• a federated settlement layer, such as the Liquid Network, that separates institutional settlement from base-layer cold storage?
• support for high-assurance smart contracts on the underlying chain?
• air-gap-compatible hardware signing devices?

Each “no” answer marks an architectural gap. Blockstream’s enterprise custody solution was designed to answer “yes” to each of these. 

To learn more:

• Visit Blockstream Enterprise
• Contact us for enterprise custody inquiries