A bridge connecting the XRP Ledger to another blockchain just lost 200,000 in under 100 minutes — not because a hacker broke through a wall, but because the software could not tell the difference between a real deposit and a fake one. Here is why this flaw matters for every bridge in crypto.
By Keisha Williams | August 12, 2026
The Hook
Nearly 200,000 XRP — worth approximately 200,000 — was drained from a bridge linking the XRP Ledger to the tx blockchain after an attacker exploited a software flaw that made the system accept deposits that never actually happened. The entire drain took just 97 minutes on August 9 before the bridge was halted. According to on-chain data tracked by CoinDesk, most of the stolen tokens moved through several other addresses within hours.
The bridge was operated by tx, formerly known as Coreum, a U.S.-based blockchain company focused on tokenizing real-world assets. The company has since confirmed the vulnerability, engaged blockchain forensics specialists, and filed a complaint with the FBI — but has not yet said how affected users will be compensated.
How the Exploit Worked — The Receipt System That Failed
To understand why this matters, you need to understand how a bridge works. Think of a bridge like an international money transfer service. You deposit XRP into a reserve wallet on one blockchain, and the bridge issues an equivalent amount of “bridged” XRP on the other chain. When you want your original tokens back, you send the bridged tokens back through, and the bridge releases the real XRP from its reserve.
The system relies on a simple principle: no deposit, no receipt. But in this case, the bridge’s software failed at exactly that check. According to tx’s own explanation, the software registered transactions as deposits even though those transactions never actually delivered XRP to the reserve wallet.
- The attacker sent transactions that looked like deposits — but the XRP never arrived at the bridge’s reserve address.
- The bridge issued bridged tokens anyway — creating tokens backed by nothing.
- The attacker sent those unbacked tokens back through the bridge — triggering a withdrawal of real XRP from the reserve.
- 17 of 28 relayers approved each payout — because the bridge’s own records showed the deposits as legitimate, the automated validators signed off exactly as designed.
The specific failure sat in the relayer code, which processed payments carrying the bridge’s memo field without first verifying the actual destination address. In plain terms: the system read the label on the envelope without checking whether the envelope actually contained money. Relayers are automated programs that watch both blockchains and approve transfers when the bridge’s records indicate a withdrawal is owed — and 17 out of 28 of them signed off on each fake withdrawal because the records looked correct.
Why This Matters Beyond Just One Bridge
This exploit is not an isolated incident — it is a pattern. Crypto bridges have been one of the weakest links in the entire blockchain ecosystem for years, accounting for some of the largest hacks in the industry’s history. The fundamental problem is that bridges require trust in software that connects two separate systems, and any flaw in that connecting code becomes an open door.
What makes the tx bridge exploit particularly instructive is how mundane the failure was. This was not a sophisticated zero-day attack or a compromised private key. It was a missing verification step — the kind of basic error that any well-audited codebase should catch. The fact that it slipped through suggests that bridge security audits may not be keeping pace with the complexity of the systems they are meant to protect.
For regular crypto investors, bridges are unavoidable. If you want to use DeFi applications on one blockchain but hold your assets on another — a common scenario as Bitcoin trades near 63,364, Ethereum around 1,885, and Solana near 76 — you will likely cross a bridge at some point. The tx incident is a reminder that every time you move assets across chains, you are trusting code that may not have been checked thoroughly enough.
The Aftermath — and What Happens Next
tx has taken standard post-exploit steps: the bridge is halted, the vulnerability has been patched, forensics experts are on the case, and law enforcement has been notified. But one critical question remains unanswered: will affected users get their money back?
In many bridge hacks, the answer has been no — or only a partial recovery after months of negotiation. The 200,000 stolen here is relatively small compared to exploits like the Ronin bridge hack that cost 625 million in 2022 or the Wormhole hack that lost 320 million. But the dollar amount matters less than the principle: users who trusted the bridge with their XRP are now waiting to find out whether that trust was warranted.
- Bridge security remains the industry’s Achilles’ heel. This exploit was caused by a missing address verification — a basic check that should have been in place from day one.
- Relayer systems can approve fraudulent transactions — 17 of 28 validators signed off on each withdrawal because they relied on corrupted records, not actual on-chain verification.
- User compensation is uncertain. tx has not yet outlined a recovery plan for affected holders.
- The stolen XRP is already moving. On-chain tracking shows the funds dispersed through multiple addresses within hours, making recovery increasingly difficult with each passing day.
The broader lesson is one that crypto investors hear too often and internalize too rarely: not every bridge is built the same, and even bridges operated by legitimate companies can have catastrophic software flaws. Before crossing any bridge with your assets, it is worth asking a simple question — does the team behind it have a track record of third-party security audits, and do they have a plan for what happens when things go wrong?
The cryptocurrency market remains highly volatile. This article is for informational purposes only and does not constitute financial advice.
Disclaimer: This article is for informational purposes only and does not constitute financial advice. Cryptocurrency investments carry risk; always do your own research.
17 of 28 relayers signed off on fake withdrawals and nobody thought maybe 17 wasnt enough. bridge security is a joke
a missing address verification. thats literally line one of any bridge security checklist. how does something this basic survive an audit
^ exactly. they read the memo field but never checked if XRP actually landed at the reserve address. thats not a hack, thats a design failure that should have been caught in week one of testing
the relayer just read the XRP memo field and trusted it as truth. no on-chain verification that the reserve address actually received funds. bridge 101 failure
memo_field_bug_ suggestion box is the right word lol. one reserve address query per deposit would have killed this exploit in 10 lines
10 lines and a unit test, thats it. instead the bridge trusted its own event log over actual chain state. never trust your own emission, always verify on-chain
the check exists in the docs of every bridge framework and still never got called. genuinely impressive engineering culture
the fake deposit trick is literally older than DeFi. how do bridge devs keep falling for this in 2026
^ right? its the same replay attack pattern from 2022 Aurora. nothing changed except the chain name
17 of 28 relayers approved fake withdrawals because their records showed deposits that never happened. the entire validation model is broken if relayers just trust internal state instead of checking the chain
97 minutes to drain 200K XRP and the bridge just kept signing off on fake deposits. relayers reading memo fields instead of checking the actual reserve address is genuinely embarrassing
relay_min_ the relayer model is fundamentally broken when 17 out of 28 nodes just rubber stamp whatever internal state says. no independent chain verification at all. same bug class as the Aurora bridge from 2022
Cormac F. 17 of 28 relayers rubber stamping fake deposits is insane. that means 61% of the network never independently verified anything
Thiago M. and the 11 that verified had no way to veto. 61pct rubber stamps and the quorum keeps signing. whats the threshold even for
they keep signing because slashing punishes downtime way harder than bad blocks. the incentive design told them clicking yes was the safe play
slash_me_not exactly, an honest abort looks like downtime and gets slashed while a rubber stamp only hurts if the bridge drains. the 61pct quorum math made lazy signing the rational strategy
a quorum system where verification is decorative. the 17 signers were rationally lazy rather than malicious, which is somehow scarier
rational laziness is scarier than malice, agreed. the system rewarded clicking yes and punished anyone who paused to ask questions
Thiago M. and the scary part is this is probably not unique to this bridge. how many other XRP bridges are out there trusting memo fields without checking receipts
tx used to be coreum, rebranded, and still shipped relayers that trust a memo field. new name, same skipped address check on every deposit
rebrand bought them exactly zero security review lol. same relayer code, new logo. the FBI complaint is free, compensating users is the expensive part they keep dodging
Dan Kowal courts will read a bridge trusting its own event log very differently than a broken key. expect the lawsuit to argue negligence, which turns an insurance payout into a fight
97 minutes of fake deposits and nobody checked the reserve address once. every bridge postmortem is the same boring bug wearing a new logo
the reserve check should have been the first integration test written. you verify the deposit landed before you mint anything. day one stuff, somehow still optional
97 minutes for 200k because a memo field outranked the reserve address. cheapest heist per line of code this year
a memo field outranking the reserve address is a bug you catch in code review, not a postmortem. 200k gone in 97 minutes to a missing if statement
The quorum signed off on deposits nobody verified. Verify before mint is day one bridge logic, the docs had it and the code did not.