/
/ 

The tx bridge drain: what the XRP Ledger actually records

2026-08-12 · Web3 Security The XRP Ledger account behind the tx bridge sent 94 payments totaling 199,916.3 XRP on 9 August 2026, every one of them validly signed by 17 of its own 28 relayer keys. No key was stolen. The bridge authorized every transfer, because…

01 / 01 Sections Sections

2026-08-12 · Web3 Security

The XRP Ledger account behind the tx bridge sent 94 payments totaling 199,916.3 XRP on 9 August 2026, every one of them validly signed by 17 of its own 28 relayer keys. No key was stolen. The bridge authorized every transfer, because it had been told deposits arrived that never did.

Key findings

  • The bridge account rxXXXeMX8Gy5YvibvGLnQJ1XKKD7UswM1 sent 94 payments totaling exactly 199,916.300000 XRP between 19:26:30 and 20:53:50 UTC on 9 August 2026, an outflow window of 87 minutes. Verified against the XRP Ledger on 12 August 2026.
  • Every one of the 94 payments carried exactly 17 signatures, and the account’s master key is disabled with a signer quorum of 17 of 28. The multisig performed exactly as designed.
  • The funds went to two accounts, 47 payments each: 107,397.5 XRP to rfXSfH2q4zhGWdw45nYcWfjvFN5ZfwE1U6 and 92,518.8 XRP to rwt8PJhyXWgW8uwmTjmQ7Rw89tJHELFgb5. Both held exactly 3.00 XRP on 12 August 2026, the ledger’s base reserve, meaning both have been swept.
  • The bridge account held 493.543894 XRP on 12 August 2026, against roughly 200,410 XRP before the drain. That is 99.75 percent of the reserve.
  • The bridge’s own specification says relayers “observe all XRPL bridge account transactions.” On the XRP Ledger that set includes transactions the account neither sent nor received.
  • At 19:25:10 UTC, one minute before the first outbound payment, the bridge account’s transaction history contains payments a third-party account sent to itself, where sender and destination are the same address.
  • tx says the bridge “underwent several internal and third-party audits before deployment, but the vulnerability was not identified.”

Spec file

Field Value
Subject XRP Ledger cross-chain bridge relayer deposit verification
Incident Drain of the XRPL side of the tx (formerly Coreum) bridge
Bridge account rxXXXeMX8Gy5YvibvGLnQJ1XKKD7UswM1
Chain XRP Ledger mainnet
Amount 199,916.300000 XRP, roughly $200,000
Transactions 94 Payments, 17 signatures each
Window 2026-08-09 19:26:30 to 20:53:50 UTC
Account control Master key disabled; signer quorum 17 of 28
Reserve remaining 493.543894 XRP as of 2026-08-12
Recipients rfXSfH2q4zhGWdw45nYcWfjvFN5ZfwE1U6, rwt8PJhyXWgW8uwmTjmQ7Rw89tJHELFgb5
Reported by operator 2026-08-11
Legal posture Complaint filed with FBI IC3; no charges filed, no defendant named
Verified 2026-08-12 against s1.ripple.com:51234

What the record shows

What does the ledger say happened?

The account rxXXXeMX8Gy5YvibvGLnQJ1XKKD7UswM1, which XRPScan’s public registry labels as the Coreum bridge, sent 94 XRP payments on 9 August 2026. Queried on 12 August 2026, the total delivered across those payments is 199,916.300000 XRP. The first settled at 19:26:30 UTC, the last at 20:53:50 UTC, an outflow window of 87 minutes.

CoinDesk and Decrypt both describe the incident as a 97-minute event beginning at 19:16 UTC on 9 August 2026. That is consistent with the ledger if the clock starts at the attacker’s first spoofed deposit rather than at the first payment leaving the bridge. This article reports the outflow window it can see directly, which is 87 minutes, and does not dispute the 97-minute figure.

Was a key stolen?

No, and this is the part worth understanding. Every one of the 94 payments carried exactly 17 signatures. The bridge account on the XRP Ledger has its master key disabled and a signer quorum of 17 of 28, verified on 12 August 2026, which means multi-signing is the only way any transaction leaves it at all.

Seventeen independent relayer keys separately signed each of the 94 transfers that emptied the tx bridge. The multisig did not fail. It succeeded, 94 times, on instructions it had no way to question. A quorum protects against a minority of compromised signers. It does nothing when every honest signer is reading the same wrong input.

What did the relayers actually check?

The bridge’s published specification describes the relayer’s job this way: “An additional sub-process of each relayer observes all XRPL bridge account transactions and once it reaches that submitted transaction it provides evidence with transaction status and data.”

The load-bearing word is all. On the XRP Ledger, account_tx does not return only the payments an account sent and received. It returns every transaction that affected the account, which includes transactions submitted by strangers that touched its offers or its trustlines along a payment path. The bridge account is a busy piece of public infrastructure, so that feed is large: more than 770 transactions touched it in a five-minute stretch around the incident, almost all of them other people’s business.

The relayers scanned that feed for payments carrying a Coreum destination memo and treated what they found as deposits. What they did not do was confirm that the payment’s Destination field was the bridge.

What does a fake deposit look like on-chain?

Like a payment somebody sent to themselves. At 19:25:10 UTC on 9 August 2026, one minute before the first outbound transfer, the bridge account’s own transaction history contains a run of payments in which the sending account and the destination account are the same address. They moved that account’s own funds in a circle. They delivered nothing to the bridge. They appear in the bridge account’s history regardless, because a cross-currency payment routes through the order book and touches the accounts whose liquidity it consumes.

To a relayer filtering on a memo rather than a destination, a self-payment carrying a Coreum memo is indistinguishable from a genuine deposit. Seventeen relayers agreed, independently and correctly by their own logic, that a deposit had occurred. The contract on the tx side minted bridged XRP against it, and the attacker redeemed that unbacked balance for real XRP from the reserve.

Where did the XRP go?

To two accounts, in an almost perfectly even split: 47 payments and 107,397.5 XRP to rfXSfH2q4zhGWdw45nYcWfjvFN5ZfwE1U6, and 47 payments and 92,518.8 XRP to rwt8PJhyXWgW8uwmTjmQ7Rw89tJHELFgb5. Both accounts were funded immediately before the drain, and on 12 August 2026 both held exactly 3.00 XRP, which is the XRP Ledger’s base account reserve and the smallest balance an account can hold without being deleted. Everything above the reserve floor has already moved.

Reporting describes the onward path as XRP converted to ether, routed through THORChain, then through Tornado Cash. This article did not trace those hops across chains and does not independently confirm them.

How much was left?

The bridge account held 493.543894 XRP when queried on 12 August 2026, against a balance of roughly 200,410 XRP before the drain. That is 99.75 percent of the reserve gone. The remainder is close to the account’s own reserve requirement, which is to say the account was emptied to the floor rather than partially drained.

What does this mean for bridged XRP on the tx chain?

Bridged XRP on the tx chain is a claim on that reserve, and the reserve is empty. tx states that bridged XRP “is not currently fully backed,” that all other bridged assets remain fully backed, and that no action is currently required from holders. The company says it has halted the bridge, remedied the code, traced the funds, filed a complaint with the FBI’s Internet Crime Complaint Center, and engaged forensics specialists.

No charges have been filed and no individual has been named by any authority. An IC3 complaint is a report to law enforcement, not a proceeding.

What I think is going on

The audits are the part I would look at hardest, and not because the auditors were careless.

tx says the bridge passed several internal and third-party reviews before deployment. I believe that, and I think this class of bug survives review as a matter of course. A reviewer reading the relayer code sees a function that fetches transactions for the bridge account and filters for a memo. Every line of it is correct. The defect is in an assumption that never appears in the code at all: that a transaction returned by account_tx for an account is a transaction involving that account as a counterparty. That assumption is wrong, it is wrong for a reason documented in the XRP Ledger’s own API reference, and there is no line in the diff where a reviewer would notice it missing. Audits are good at finding bad code. This was correct code resting on a wrong belief about someone else’s system.

The economics reinforce it. About $200,000 is a small loss by bridge standards, and the reason is not restraint. The tx bridge held roughly 200,410 XRP on 9 August 2026 and lost 199,916.3 of it, so the ceiling was the size of the pot rather than the sophistication of the attack. The same flaw against a bridge holding fifty times as much would have produced a fifty-times headline with an identical mechanism.

The 47-and-47 split across two fresh XRP Ledger accounts reads as operational habit rather than necessity. Two destinations rather than one, near-equal amounts, and both accounts funded immediately before the 9 August 2026 drain. That is somebody following a routine.

What I would want before drawing firmer conclusions is the relayer source at the commit that was running on 9 August, and the memo format the spoofed payments carried. Both would settle whether the destination check was absent or merely wrong, which is the difference between an oversight and a misunderstanding.

What reduces your exposure

Nothing here is a wallet-hygiene problem. Nobody holding XRP on the XRP Ledger was at risk from this, and no user action would have prevented it. The exposure was to a specific asset on a specific chain, and the useful lessons are structural.

A bridged asset is a credit claim, not the asset. Bridged XRP on the tx chain is a claim on a reserve wallet you can inspect. That claim is only as good as the reserve behind it, which in this case is now 493 XRP. Holding the native asset on its own chain carries none of this risk. Holding a wrapped version of it means accepting the operator’s software as a counterparty.

The reserve is public, so you can check it. The backing for a bridge like this sits at an address anyone can query, and it takes one call and no account:

curl -s -X POST https://s1.ripple.com:51234/ \
  -H 'Content-Type: application/json' \
  -d '{"method":"account_info","params":[{"account":
       "rxXXXeMX8Gy5YvibvGLnQJ1XKKD7UswM1","ledger_index":"validated"}]}'

Compare the balance against the supply of the bridged token on the destination chain. If the reserve does not cover the claims, the peg is arithmetic rather than opinion. This is checkable before an incident, not only after.

Treat “audited” as a statement about effort, not a guarantee. This bridge was audited internally and externally and the flaw shipped anyway, because it lived in an assumption about a third-party API rather than in the code under review. An audit narrows the space of likely bugs. It does not convert a bridge into a safe place to leave value indefinitely.

Watch for recovery scams now. tx has warned that official updates come only through its own channels. A public list of affected addresses, a widely reported loss and no announced reimbursement mechanism is precisely the setup approach-phishing operators wait for. Nobody legitimate will ask for a seed phrase or a signature to process a recovery.

Sources

Cite as. Max Avery, “The tx bridge drain: what the XRP Ledger actually records,” maxavery.org, 12 August 2026.

Disclosure. Max Avery is affiliated with Digital Ascension Group (DAG). Investment advisory services are offered through DAG Wealth, an SEC-registered investment adviser (CRD No. 328627). Registration does not imply a certain level of skill or training. DAG is not a law firm and does not provide legal or tax advice. Custody arrangements with third-party independent qualified custodians reduce certain risks but do not eliminate them. Nothing here is investment, legal, or tax advice, or a recommendation to buy or sell any asset. This article describes matters of public record; charges are allegations and defendants are presumed innocent unless and until proven guilty.

More from the journal

Continue reading.