Why bridges keep getting hacked, and what a bridged token actually is
For a stretch of 2021 and 2022, cross-chain bridges were the single most reliably robbed thing in crypto. Not exchanges, not wallets, not smart contracts generally — bridges.
Ronin lost roughly $625 million. Poly Network lost over $600 million. Wormhole lost around $320 million. Nomad lost close to $200 million. That's more than one and a half billion dollars from four incidents, and the list is longer than four.
None of those were failures of Bitcoin, Ethereum, or any underlying chain. Understanding why is the most useful thing you can learn about bridges, because it tells you exactly what you're trusting when you use one.
Chains can't talk to each other
The root problem is simple and often glossed over. Bitcoin has no idea Ethereum exists. Each chain validates only its own transactions and has no mechanism for observing another chain's state. There is no built-in way for one to learn what happened on the other.
So "sending BTC to Ethereum" is impossible in the literal sense. Your bitcoin cannot leave Bitcoin.
What actually happens is a substitution. You send real BTC to an address controlled by the bridge. The bridge notices, and something on Ethereum issues you a token that represents that BTC. When you want out, you burn the token and the bridge releases the original.
The crucial consequence: a bridged token is not the asset. It's a claim on a pot of the asset, held by whoever runs the bridge. Its value rests entirely on that pot still being there and the operator still honouring redemptions. If the pot is drained, your wrapped token is a receipt for nothing — which is precisely what holders discovered in each of the incidents above.
Someone has to decide the deposit happened
Since neither chain can observe the other, some third party must watch chain A and attest to chain B that a deposit occurred. That attestation mechanism is the bridge, and it's where all the money goes missing.
The designs vary in how much you have to trust:
A multisig or validator set — a fixed group of signers whose quorum authorises releases. Simple, fast, and only as strong as the smallest number of keys that can move funds.
An optimistic model — messages are assumed valid unless challenged during a window. Cheap, but it depends on someone actually watching and on the challenge logic being correct.
Light clients and proofs — the destination chain verifies cryptographic proofs of the source chain's state. The strongest approach and the most expensive, which is why it's less common than it should be.
Everything else is a variation. What matters is that in almost every case, a small set of parties or a single verification function stands between the pot and an attacker.
The four failures, and what each one teaches
Ronin — compromised keys, not compromised code. The bridge used a nine-signer validator set requiring five to authorise a withdrawal. An attacker obtained four keys through spear phishing, then reached the fifth through a third party that had earlier been granted signing access and never had it revoked. Five of nine, quorum met, funds released. Nothing was cryptographically broken. The signature check worked perfectly — it just verified signatures from an attacker.
The lesson isn't "multisig is bad." It's that a quorum is only as meaningful as the independence of its signers. Four keys at one company plus one stale permission is not a five-of-nine, it's closer to a one-of-two wearing a costume.
Poly Network — the contract was persuaded to change its own guard. The attacker found a cross-chain call path that let them alter the keeper role — the thing that decides which messages are legitimate — to an address they controlled. After that, every fraudulent withdrawal was, as far as the contract was concerned, properly authorised.
The lesson: the most dangerous function in a bridge is rarely the one that moves money. It's the one that decides who's allowed to.
Wormhole — the signature check itself was flawed. A verification routine could be tricked into accepting a forged set of guardian signatures, which let the attacker mint 120,000 wETH on Solana that was never backed by anything on Ethereum.
The lesson: "verified by signatures" means nothing without a correct verifier. The cryptography was fine; the code around it wasn't.
Nomad — a configuration change opened the door for everyone. A routine upgrade left a trusted root set to a zero value, which had the effect of making essentially any message appear proven. The exploit needed no special skill: people copied the first attacker's transaction, swapped in their own address, and repeated it. It became a crowdsourced drain.
The lesson, and it's the uncomfortable one: this wasn't an exotic attack. It was a deployment mistake. Most bridge losses look more like botched operations than like cryptography being defeated.
What this means for you
Bridged assets carry the bridge's risk, not the chain's. Holding wrapped BTC on another chain is not holding BTC. It's holding a claim, secured by whatever that bridge's weakest component happens to be. That may be perfectly acceptable — but it should be a decision, not an assumption.
Prefer not bridging when there's an alternative. If you can buy the asset natively on the destination chain, or use a centralised exchange as the crossing point, you've swapped bridge risk for a different and often better-understood risk. Neither option is risk-free; they just fail in different ways, and exchange failure modes are at least well catalogued.
Don't leave value parked in bridged form. Bridge risk accumulates with time. Crossing over, doing what you came to do, and crossing back exposes you briefly. Holding a wrapped asset for a year exposes you for a year.
Judge a bridge by its trust model, not its interface. How many signers can move the funds? Are they independent organisations or one team? Has the code been audited, and — more tellingly — has it survived time and volume? A slick front end tells you nothing.
Size the position to the trust. The straightforward rule is to bridge no more than you'd be willing to lose if the operator vanished, because in the worst case that's the same thing.
Where SSP stands
SSP supports moving assets between EVM chains, and it's worth being exact about what that does and doesn't protect.
Our 2-of-2 protects your keys and your approvals. Nobody can initiate a bridge transaction without both of your devices signing it, and you'll see what you're approving on each. That property holds completely.
What it cannot do is make the bridge itself safe. Once your assets are in a bridge contract, they're governed by that contract's rules and that operator's key management — not by your multisig. Two-device approval is excellent protection against someone moving your funds without permission. It is no protection at all against your funds being taken from a place you deliberately sent them to.
That's not a limitation we can engineer around, and pretending otherwise would be dishonest. Bridges are one of the places in crypto where the honest answer is that the security depends almost entirely on somebody else, and the right response is to look hard at who that somebody is before you cross.
