Harmony Horizon Bridge Hack: How $100M Was Lost and Why It Matters

In June 2022, the Horizon Bridge, which connected the Harmony blockchain with Ethereum, BNB Smart Chain and other networks, was drained of roughly $100 million in crypto assets. The attack did not come from a flaw in the Harmony blockchain's consensus. Attackers gained control of enough of the private keys that approve withdrawals from the bridge's vaults, then signed transfers that sent tokens to addresses they controlled.

The incident is one of the largest bridge losses on record and is often cited in discussions about cross-chain security. Its lessons reach well beyond one project. Anyone who moves assets between chains, or who holds wrapped tokens issued by a bridge, depends on the security of that bridge's operators and code, not only on the security of the chains at each end.

This guide covers how the attack worked in general terms, why the bridge's design made it possible, where the funds went, and which defensive habits reduce the chance of a similar loss. It is not a live status report. Details about the bridge's current operation, the team's response and any compensation can change, so the sections below explain where to check them.

A bridge that holds assets on one chain and issues matching tokens on another needs a way to decide when a withdrawal is valid. Many early bridges used a multisig, short for multi-signature, arrangement. A fixed set of signers, sometimes called validators or guardians, each control a private key. A withdrawal is approved only when a set number of them sign it.

The number that must sign is called the threshold. A setup described as two of five means five keys exist and any two can approve a withdrawal. The threshold sets the trade-off. A low threshold makes the bridge easier to operate but means fewer compromised keys are needed to move funds. A high threshold resists theft better but can slow operations or create other failure points.

Key distribution matters as much as the number. If several signers run on the same cloud account, use the same device or share a team that can be socially pressured, the effective threshold is lower than it looks on paper. Good designs spread keys across independent people, organizations, devices and locations, and they make it difficult for any single compromise to satisfy the threshold.

When you read a bridge's documentation, look for the exact threshold, who the signers are, how keys are stored and whether any delay or review step applies before a large withdrawal is executed.

Public post-incident reports said the attackers obtained enough signing keys to meet the bridge's approval threshold. Once that happened, they could produce valid-looking withdrawal approvals and drain the locked assets on the bridge's side of each route. Because the bridge accepted the signatures as legitimate, the on-chain contracts did not treat the transfers as anomalous in the way a user might expect.

The exact method for obtaining the keys is the most important detail to read in the team's own post-mortem. Reports of this kind of incident commonly describe a mix of problems, such as keys stored in systems connected to the internet, weak separation between signing infrastructure and everyday operations, or compromised devices and accounts used by the people who held the keys. Those factors are general patterns in key-management failures, and you should confirm what applied to this specific case in the primary source.

For a reader, the main takeaway is that a bridge's smart contract can be sound and the bridge can still be drained, because the contract trusts whoever controls the threshold. Security reviews of code alone do not cover operational security, and a serious assessment looks at signers, infrastructure and incident response as well.

Stolen bridge funds rarely stay in one place. Attackers typically split assets into many transactions, move them across several chains, swap them for other tokens and pass some through privacy tools or mixers. Each step makes tracing and freezing harder, although public blockchains keep a permanent record of every transfer.

Recovery depends on several factors that sit outside the hacked project's control. Centralized exchanges can freeze deposits they recognize as linked to a theft, but only if the funds reach them and the exchange chooses to act. Some stablecoin issuers can freeze tokens they issue. Law enforcement and blockchain analytics firms can follow transfers, though that does not guarantee the return of assets.

For users, the practical point is that losses from bridge exploits are often permanent unless the project or a third party steps in. If you were affected by a bridge incident, prioritize official statements from the project, reports from the security teams involved and the guidance of your own exchange or wallet provider. Be cautious about anyone who contacts you offering recovery help in exchange for a fee or private keys, since recovery scams often follow large hacks.

Bridges concentrate value. A bridge's vault may hold a large pool of tokens that represent assets on another chain, which makes it an attractive target compared with a single user's wallet. The attacker needs to compromise one set of keys or one contract path rather than many separate accounts.

Bridges also combine several hard problems. Each one connects two systems with different rules, finality times and token standards, and it has to agree on what happened on the other side. Its code, its off-chain relayers or validators and its operational processes all have to be correct. A weakness in any of those layers can be enough.

The ecosystem also contains many bridges with different designs, which means users and teams often face unfamiliar risks. Some bridges rely on a small committee, some on optimistic or fraud-proof models, some on cryptographic proofs and some on messaging networks run by separate operators. Each design has its own failure modes, so a bridge that is secure in one respect may still be exposed in another.

The pattern is not a reason to avoid all cross-chain movement. It is a reason to understand the trust model of each route before you commit a meaningful amount of money to it.

Several warning signs can suggest that a bridge deserves extra caution. None of them proves that a bridge is unsafe on its own, but together they are useful reasons to delay or reduce exposure.

• The threshold is low relative to the number of signers, or the signers are not clearly identified.
• The team does not publish how keys are stored or who controls them.
• There is no withdrawal delay, rate limit or pause mechanism for unusually large transfers.
• Audits are missing, old or limited to a narrow part of the system.
• The project has no clear incident response process or contact channel.
• Large amounts are pooled in a single contract with little visibility into reserves.
• The bridge is new, has little public track record and promises unusually high incentives.

Watch for social engineering as well. Fake support accounts, phishing sites that mimic bridge interfaces and urgent messages asking you to approve a new contract are common around large incidents. Always type or bookmark the official address yourself rather than following a link from a message.

If you see several of these signs at once, consider using a smaller amount, waiting for more information or choosing a route with a different trust model.

Before you move funds, a short checklist can reduce avoidable risk. Work through it in order and skip any step you cannot complete.

1. Confirm the bridge address from the project's official documentation, not from a search result or chat message.
2. Read the trust model. Note the signer count, the threshold, any delay mechanism and whether a team controls upgrades.
3. Check the security history. Look for audits, bug bounty programs and any past incidents, and read how the team responded.
4. Check the reserves or liquidity it holds and the value you plan to move relative to what you can afford to lose.
5. Send a small test transfer first and confirm that the token arrives and that the contract address on the destination chain matches the official one.
6. Review the transaction details in your wallet before you sign, including the spender address and the amount of any token approval.
7. Revoke any token approval you no longer need, using the approval management tools in your wallet.

For very large balances, consider whether you need to bridge at all, and whether a centralized exchange withdrawal or a different route is more appropriate for your situation. Keep records of each transfer in case you need to verify it later.

If you held or used assets that were affected by a bridge incident, act calmly and work from primary sources. The steps below apply to most bridge exploits and do not depend on any particular project.

• Stop using the affected bridge and avoid approving any new transactions on it.
• Read the official statements from the project about which assets, chains and time windows were affected.
• Check your wallet's token approvals and revoke any that point to the affected contracts.
• If you hold wrapped versions of tokens issued by the bridge, check the project's guidance on redemption, since some may no longer be redeemable.
• Contact your exchange or wallet provider if your funds passed through a service they operate, and keep your transaction records.
• Report phishing or impersonation attempts to the project and to the platforms where they appear.

Be cautious with anyone who offers to recover funds for a fee, asks for your seed phrase or private keys, or pressures you to act within a short deadline. Legitimate project updates are usually published in several official places at once, so cross-checking helps.

Developers and teams can learn several durable lessons from this kind of incident. Treat signer keys as the most sensitive part of the system and protect them as if they were the reserves themselves. Separate signing environments from internet-connected systems, use hardware-backed storage where practical, and make sure no single person, device or account can satisfy the threshold alone.

Add time-based controls for large withdrawals, so that an unusual transfer can be paused or reviewed before it completes. Monitor balances, approvals and signing activity continuously, and rehearse incident response with a clear communication plan for users. Publish key management practices and signer identities where it is safe to do so, since transparency helps users judge risk.

Users can apply a parallel discipline. Assume that any bridge you use is a point of concentrated trust, size your exposure accordingly and keep your own wallet hygiene strict. A well-run bridge reduces risk, but it does not remove the need for careful decisions on your side.