← Back to blog

Cross-Chain Bridge Vulnerabilities: A Decade of Translation Failures

Bridges were the most-robbed structure in crypto because a bridge is a translator between two systems that do not share a verifier. The same trust boundary now sits under every agent-tool call.

Published June 2026 · 9 min read

In 2022, the single most-robbed structure in all of crypto was not an exchange, a wallet, or a lending protocol. It was the bridges, the connective tissue built specifically to join one blockchain to another. According to Chainalysis, roughly $2 billion was stolen in thirteen cross-chain bridge hacks that year, and bridges accounted for about 69% of all crypto stolen in 2022. The cumulative toll has since passed $2.8 billion. The thing built to unite the chains became the easiest place in the entire ecosystem to steal from.

That is a strange and specific fact, and it deserves a strange and specific explanation. The worst of it is compressed into a few brutal years, call it 2021 to 2024, but the failure those years exposed is far older than crypto. Strip away the tokens and the smart contracts and every one of these hacks is the same thing: a translation that the reader could not independently check.

A bridge is a translator with no shared dictionary

Here is the cleanest one-sentence diagnosis I've found, from a post-mortem of the whole genre: bridge exploits are "structurally different from typical smart-contract hacks because they require trusting state from a chain the destination chain cannot natively verify."

Sit with that, because it's the whole essay. A blockchain is, by design, a machine for not having to trust anyone: every node re-runs every transaction and checks it against the rules. But a blockchain can only do that for its own history. Ethereum cannot re-run Solana's consensus. Solana cannot replay Ethereum's. So when you want to move value from one to the other, the destination chain faces a problem it cannot solve natively: it has to know that something happened "over there," a deposit got locked, an event fired, and it has no way to check. It cannot read the other chain's books. It can only accept a claim that the deposit happened, and then mint the corresponding tokens on its own side.

A bridge, in other words, is a translator between two systems that do not share a verifier. And every bridge has to answer the translator's oldest question: when you hand me a document in a language I can't read, and a certificate that says the translation is faithful, how do I know the certificate is real? Every bridge hack is a different way of answering that question wrong. The destination chain was made to believe a deposit happened that never did, and it minted real value against a fictional event.

Four ways a certified translation goes wrong

You don't need the full incident catalog, the technical taxonomy is well documented elsewhere, but four marquee failures map so cleanly onto four kinds of translation fraud that they're worth walking through as a set.

The forged certificate. The Wormhole bridge connected Ethereum and Solana through a set of "guardian" signers whose collective signature certified that a deposit was real. In February 2022, an attacker found that the contract was missing a single check, one key comparison that was never performed, and used the gap to forge a valid-looking guardian signature. With that one forged certificate, they minted 120,000 ETH on Solana (around $320 million at the time, though quotes vary with the price that week) against essentially nothing. A $300-million-plus loss from one un-done comparison. It is the digital equivalent of a notary's stamp that nobody ever checked the notary for: a certified translation whose certificate was a sticker anyone could print.

The compromised translators. Some bridges don't even pretend to verify the foreign state mathematically; they appoint a committee of validators, and the committee is the security. The Ronin bridge behind the game Axie Infinity used nine validator keys and required five to approve a withdrawal. Attackers obtained those five, four of them, devastatingly, through a spear-phishing campaign built around a fake job offer that compromised the validators' keys, plus one more from a delegated key. The U.S. Treasury later attributed the roughly 173,600 ETH and 25.5 million USDC theft (around $600 million) to North Korea's Lazarus Group. Note what broke: the people, not the cryptography. When your translation is only as honest as a handful of designated translators, you don't have to break the math. You bribe or phish the translator.

The broken rubber stamp. The Nomad bridge produced the most darkly funny failure of the era. A routine upgrade misconfigured a trusted root to a value of zero, which had the effect of making the verification step approve every message as already-proven. Spoofing a withdrawal became trivial, and then it became copy-pasteable: you could take someone else's successful drain transaction, swap in your own address, and resubmit it. Word spread, and hundreds of ordinary people piled in within hours, draining about $190 million in what observers called "the first crowdsourced bridge hack." This is the clerk who stamps "approved" on every document without reading it, and then a crowd notices, and lines up. A translation failure so total that no skill was required to exploit it; you just had to repeat the magic sentence.

The mistranslated role. Poly Network, hacked for around $611 million in 2021 (then the largest crypto theft ever, later returned in full), fell to a subtler trick: the attacker manipulated the cross-chain manager into reassigning who counted as authorized, effectively promoting themselves to keeper. The translation didn't forge a message, it mistranslated a role, rendering "ordinary caller" as "trusted administrator." One misrendered word, and the gates opened.

This is not a blockchain problem

Here's why a developer who will never touch a bridge should care: the vulnerability isn't crypto. It's any system that re-attests a fact across a trust boundary it can't natively verify. Once you see the shape, you see it everywhere.

OAuth and SSO are bridges. Service B accepts an identity claim minted by provider A, a token that says "this user is authenticated." B usually can't and doesn't re-derive that fact from scratch; it trusts the certificate. Forge or replay the token and you have a forged attestation across a trust boundary, Wormhole in a different costume. API gateways and adapters are bridges every time they trust an upstream's claimed result without re-checking it. ETL and data import pipelines are bridges, and the "import everything, validate nothing" default is Nomad's broken rubber stamp waiting to happen. Customs, notarization, treaty verification, certified legal translation: the human originals of this problem are literally about trusting a certified rendering of a document from a system you can't re-run.

And the one that should make every team building with AI sit up: an agent calling a tool is a bridge. When an AI agent invokes an external tool, or a Model Context Protocol server, or another agent, and trusts the output it gets back without any way to independently verify it, that is exactly the bridge problem. A poisoned MCP server, a malicious agent-card, a tool that lies about what it did: these are forged attestations across the agent's trust boundary, and the agent mints real action against a fictional event, just as Solana minted real ETH against a fake deposit. Cross-chain bridges are the matured, expensively-documented, $2.8-billion precedent for the exact trust boundary that agentic systems are now erecting everywhere, often without noticing. The bill for "trust an unverifiable foreign claim" has already been run up once. We should read the receipt before we run it up again.

And the four failure types map across with unsettling precision. The forged certificate is a tool that fabricates a result the agent has no way to re-derive: a search tool inventing a citation, an API wrapper returning a success it never achieved. The compromised translator is a once-trusted MCP server that gets suborned by a supply-chain compromise and starts quietly returning poisoned data, the way Ronin's validators were turned by a job offer. The broken rubber stamp is the agent that stops validating tool outputs against their declared schema, accepting whatever comes back because it usually works, which is Nomad's zero root in a system prompt. And the role mistranslation is prompt injection: hostile text smuggled through a tool's output that re-renders "untrusted data" as "trusted instruction," promoting a foreign string to the authority of the operator, Poly Network's reassigned keeper performed in natural language. The exploits have new names, but the trust boundary, and the four ways it breaks, are identical.

Verify, don't trust, and pay for it

So what do the good bridges do? The design that materially reduces the danger is called trust-minimized bridging: light-client and zero-knowledge-proof designs that re-derive the proof of the foreign event rather than trusting a committee's stamp. Instead of accepting a certificate that says "the translation is faithful," the destination chain re-checks the source's own grammar: it verifies a cryptographic proof that the event really happened under the source chain's rules. Translation by re-checking the original, not by trusting the seal.

I want to be honest about the limit, because overclaiming here would be its own kind of forgery. Verification is not free, and it is not automatic. Even light-client and zk designs have shipped implementation bugs, because verifying a foreign system correctly is the hard, irreducible core of the whole problem: moving the trust from a validator committee to a prover doesn't make the verification disappear; it concentrates it into code that now absolutely has to be right. And there's a humbling footnote to the whole saga: several of these "final" on-chain thefts were partly un-done. Poly Network's $611 million was returned by the hacker; Wormhole's 120,000 ETH was recovered a year later through a counter-exploit; Nomad got white-hat returns. On-chain "finality" proved to have a social layer above it that occasionally reversed the boundary failure, which is reassuring for victims and slightly terrifying for anyone who believed the math was the whole story.

The boundary is where the danger lives

Strip it all the way down and you reach a sentence that has nothing to do with blockchains: verifying a foreign system without sharing its verifier is hard, and the boundary where you attempt it is the most dangerous code you will ever write. It's dangerous for a structural reason the bridges make vivid: it is the one place where value concentrates and verification is weakest at the same time. The connective tissue is the most-robbed organ precisely because it sits between two systems, each confident in its own invariants, neither responsible for the translation between them.

So the practical discipline is a single repeated question, asked at every seam in your architecture. Find every place your system accepts a claim about another system's state that it cannot natively check: the OAuth token, the upstream API result, the imported dataset, the tool or MCP response your agent is about to act on. At each one, ask: what, exactly, am I trusting here, and what happens if it lies to me? Then push as hard as the stakes justify toward re-verifying the claim yourself: re-derive it, re-check it against the source's own rules, demand a proof you can validate, rather than trusting a stamp. Where you can't, at least know that you've made the issuer of that stamp your single point of failure, and protect it like one, because someone will eventually phish it, forge it, or zero it out.

The bridges spent the better part of four years and the better part of three billion dollars teaching this lesson in the most expensive classroom imaginable. The lesson isn't "blockchains are insecure." It's older and more useful than that: a translation is only ever as trustworthy as your ability to re-check it against the original, and the moment you stop being able to do that, you are no longer verifying anything. You are just believing a certificate, and hoping the translator was honest.


Sources

An agent calling a tool is a bridge.

Every place your agent acts on a tool result, an MCP response, or another agent's claim without re-checking it is the exact trust boundary that cost crypto $2.8 billion. The Agent Trust Stack is the verify-don't-trust discipline made into infrastructure: provenance you can re-derive, reputation earned from real track record, and attestations an agent can check instead of believe, so a foreign claim has to prove itself rather than just carry a stamp.

pip install agent-trust-stack · npm install agent-trust-stack
vibeagentmaking.com → · See it in action