How a Deposit-Detection Bug Drained Nearly 200,000 XRP From the Tx Bridge

An attacker drained nearly 200,000 XRP, worth about $200,000 at the time, from the bridge connecting the XRP Ledger to Tx Chain on August 9. The XRP Ledger itself was not compromised, and there is no indication that private keys or XRPL consensus were breached. The failure occurred in the bridge software that watched for deposits.

According to Tx, the bridge recorded certain transactions as XRP deposits even though no XRP had reached its reserve account. The system then created unbacked bridged XRP on Tx Chain. The attacker returned those unbacked assets through the normal withdrawal process and received real XRP from the bridge reserve.

Tx has halted the bridge, patched the affected code, hired blockchain forensics specialists, and filed a complaint with the FBI's Internet Crime Complaint Center. The bridge remains offline while the project reviews its security and considers options for affected users.

A bridge is supposed to keep the assets on both sides in balance. When a user moves XRP to Tx Chain, real XRP is held in a reserve account on the XRP Ledger and a corresponding bridged balance is created on Tx Chain. When that bridged balance is returned, the matching XRP is released from the reserve.

That model depends on one critical check: the bridge must confirm that a real deposit reached the correct account before it creates anything on the other chain.

In this case, the deposit-detection logic accepted transactions that did not deliver XRP to the bridge reserve. Once those false deposits were treated as valid, the rest of the system operated as designed. It created bridged balances and approved withdrawals against them, even though the backing XRP had never arrived.

An independent on-chain reconstruction reported that the bridge released about 199,916 XRP across 94 payments in roughly 97 minutes. Each payment was approved by 17 of the bridge's 28 relayers. Reports use slightly different totals for the amount ultimately stolen, so "nearly 200,000 XRP" is the most accurate description without implying false precision.

The relayer count matters. This was not simply one rogue signer bypassing a multisignature setup. The relayers appear to have relied on the same incorrect deposit signal, so reaching the signature threshold did not protect the reserve. A distributed approval process cannot correct bad data when every participant evaluates that data through the same flawed logic.

Early explanations linked the drain to rippling or the Default Ripple setting on the XRP Ledger. The on-chain evidence does not support that explanation.

XRPL's official documentation defines rippling as the indirect movement of trust line tokens. It does not apply to native XRP in the way those claims suggested. The outgoing XRP payments were authorized by the bridge's own multisignature account, and the bridge software had already treated the attacker's transactions as valid deposits.

The distinction is important. Calling this an "XRP Ledger hack" suggests that the network's consensus or native payment system failed. What failed was a third-party bridge integration that read XRPL transactions incorrectly. The transactions recorded on the XRP Ledger were processed according to the instructions that the bridge's authorized signers submitted.

That is good news for XRPL users: the core ledger kept doing exactly what it was designed to do. On the current XRPL mainnet, native XRP moves through protocol-defined Payment transactions, not user-deployed smart contracts, so there was no XRPL smart contract for the attacker to exploit here. This smaller execution surface is one of the strengths of XRPL's protocol-native design. It does not make every product connected to XRPL secure, however. In this incident, the risk sat outside the ledger, in Tx's bridge and relayer software.

Reza Bashash, a co-founder of Sologenic and Coreum, reported that the stolen XRP was converted to ETH, routed through THORChain, and then sent to Tornado Cash. That movement makes recovery more difficult, but it does not make the funds impossible to investigate. Tx says it has traced the flow, engaged forensic specialists, and shared evidence with authorities.

No recovery or compensation plan has been confirmed. Tx says it is evaluating ways to address the shortfall for affected users. Until the project publishes a final accounting, an independent post-mortem, and clear reopening conditions, the status of the bridge should be treated as unresolved.

XRP traded around the $1 level as the incident entered the news cycle. CoinGecko briefly framed the move as a drop below $1 following the exploit, but timing alone does not establish that the exploit caused the price move.

The stolen amount was roughly $200,000 against an XRP market capitalization of about $63 billion. It was too small to create meaningful direct supply pressure across the wider market. The bridge incident could still affect short-term sentiment, especially when headlines incorrectly imply that the XRP Ledger itself was hacked, but XRP was already trading within a broader multi-day decline.

The cleaner conclusion is that the exploit and the move below $1 occurred close together, not that one has been proven to have caused the other.

This incident exposes three practical weaknesses that extend beyond one bridge.

First, transaction presence is not proof of payment. An XRPL integration needs to verify the destination, the validated result, and the amount actually delivered. XRPL documentation specifically points integrations to transaction metadata for the delivered amount rather than assuming the requested amount arrived.

Second, signer decentralization does not eliminate shared software risk. Seventeen relayers can reach the same wrong conclusion if all seventeen run code with the same verification flaw.

Third, an audit is not a guarantee. Tx says the bridge went through internal and third-party audits before launch, yet the flaw was not found. Adversarial testing, real-time reserve monitoring, withdrawal limits, and automatic circuit breakers still matter after an audit is complete.

Users holding XRP directly on the XRP Ledger do not need to change wallets or rotate keys because of this incident. The affected component is the Tx bridge and the XRP backing bridged balances on Tx Chain.

Tx has warned users not to trust accounts or websites claiming they can recover the stolen funds. The bridge is offline, and users should rely only on official Tx updates for information about reopening or compensation.

The attacker did not break the XRP Ledger. They exploited a bridge verifier that confused activity involving XRP with a real deposit of XRP into its reserve. The ledger itself continued processing valid, authorized transactions as intended.

That difference narrows the scope of the incident, but it does not make the failure trivial. Nearly 200,000 XRP left a reserve account because a bridge created value against deposits that never happened. The remaining questions are whether affected users will be made whole, what an independent review finds, and what safeguards Tx requires before the bridge returns.