A cross-chain bridge linking XRP Ledger (XRPL) and tx was exploited on Aug. 9, with nearly 200,000 XRP stolen, worth about $200,000. The issue came from the bridge software’s validation logic: the system treated transactions that never actually delivered XRP into the reserve wallet as valid deposits, letting the attacker withdraw real XRP from reserves.
The affected bridge connected XRPL with the Coreum blockchain, which the report said was renamed tx in March this year and focuses on real-world asset tokenization. Its operating model was straightforward: a user sends XRP on XRPL to a reserve wallet, the bridge creates an equivalent amount of cross-chain XRP on tx, and when those wrapped tokens are returned, the user can redeem real XRP from the reserve wallet.
In this case, the attacker found a way to make the system issue what amounted to a deposit receipt without any XRP actually being placed into reserve. According to a statement posted by tx on X, the bridge software recorded transactions as deposits even when those transfers had never sent XRP into the bridge reserve wallet. That allowed the attacker to obtain unbacked cross-chain XRP and then redeem it through the bridge for genuine XRP.
The drain was completed in 97 minutes
Disclosed details show the theft began at 19:16 UTC on Aug. 9 and was completed in 97 minutes.
- Start time: Aug. 9, 19:16 UTC
- Amount stolen: nearly 200,000 XRP, worth about $200,000
- Duration: 97 minutes
- Bridge structure: 28 relay nodes
- Approval threshold: 17 node approvals required for payment
- Current status: the bridge has been halted and the vulnerability has been fixed
tx said the relay node software monitored both chains at the same time and approved transfers whenever the bridge record showed there was an obligation to pay out. The problem was not the majority-vote mechanism itself, but how the relay software determined that a deposit had happened in the first place.
The flaw was in deposit verification
According to the disclosure, the relay code handled payment transactions that included bridge memos, but did not verify the destination address before processing them. In effect, relayers saw a memo-bearing transaction and treated it as a valid deposit without checking whether the XRP had actually entered the bridge’s reserve wallet.
As a result, each fabricated payment flow received approval from 17 of the 28 nodes, and the system behaved exactly as designed. The failure was in the data source and validation logic used by relayers, not in the multi-party approval model itself.
Funds moved within hours
On-chain analysis from xrpl.to showed that the stolen XRP did not remain at the original address for long. Most of the funds were moved through multiple addresses within hours, and their final destination remains unclear.
tx said it has hired blockchain forensic specialists to trace the assets and has filed a report with the FBI’s Internet Crime Complaint Center, or IC3.
The incident points to a basic cross-chain bridge weakness
The scale of the loss, about $200,000, was relatively small. Still, the case exposed a basic issue in bridge design: if the logic used to confirm deposits is flawed, adding more nodes to approve withdrawals does not solve the problem.
The report also referred to an incident from December 2024 in which Ripple was said to have suffered the theft of 210 million XRP. It said the underlying cause there was also a bridge contract vulnerability, and that the event led to a short-term drop in XRP’s price. Compared with that case, the tx bridge exploit was smaller, but the mechanism was similar in one important way: a software logic flaw let an attacker create value out of nothing. The difference this time was that the relay majority-vote mechanism itself did not fail; the fault lay in the deposit recognition logic used by the relay nodes.
For projects that rely on cross-chain bridges, the episode highlights a simple point: confirming deposits matters more than authorizing withdrawals. A bridge may have as many as 28 nodes approving every redemption, but if the deposit check is wrong, that extra approval layer cannot stop assets from being released improperly.