The Coreum Bridge Released 200,000 XRP. It Wasn't Rippling.
On 9 August 2026 the XRP Ledger account that runs the Coreum bridge sent about 200,000 XRP to two wallets in 97 minutes, almost emptying itself. A widely shared warning blamed “rippling” and an on-by-default account flag. The ledger says otherwise: every payment was signed by the bridge’s own multisig, and native XRP cannot be rippled at all. The cause was a relayer that took the attacker’s own self-payments for deposits.
What happened
The bridge account rxXXXeMX…, the official Coreum account for XRP Ledger operations, held 200,409.9 XRP on the afternoon of 9 August 2026. Starting at 19:16 UTC it sent that XRP away in a steady stream of payments to two brand-new wallets, alternating between them about every 51 seconds. Ninety-seven minutes later it held 493.5 XRP.
The two destinations were created that same afternoon, less than two hours before the first payment. They received 107,397.5 XRP and 92,518.8 XRP, and passed almost all of it on within hours.
The accounts involved
Every XRP Ledger account in the theft, what it did, and what it held on 16 October 2026:
| Role | Account | Created | What it did | Holds now |
|---|---|---|---|---|
| The bridge | rxXXXeMX8Gy5YvibvGLnQJ1XKKD7UswM1 | 12 March 2024 | Coreum’s XRP Ledger account, run by its relayers’ multisig. Paid 199,916.3 XRP to the two front wallets on 9 August; has signed one transaction since. | 763.5 XRP |
| Front wallet A1 | rfXSfH2q4zhGWdw45nYcWfjvFN5ZfwE1U6 | 9 August 2026, that afternoon | Received 107,397.5 XRP from the bridge; forwarded it within hours. | 3.0 XRP |
| Front wallet A2 | rwt8PJhyXWgW8uwmTjmQ7Rw89tJHELFgb5 | 9 August 2026, that afternoon | Received 92,518.8 XRP from the bridge; forwarded it within hours. | 3.0 XRP |
| Staging wallet | rnaBRmXU6ZS7orU6Qj38wsBYQmqHPbrhA9 | 28 June 2026 | Took 96,315.0 XRP from the front wallets. | 1.2 XRP |
| Staging wallet | r3jV8g599WMR9zeFi5m1rbvXyEwNWwYFXt | 28 June 2026 | Took 73,498.2 XRP from the front wallets. | 1.0 XRP |
Every payment was signed by the bridge itself
This is the fact the rest of the story turns on. Each payment has the bridge account in the Account field, so it is the sender, not a bystander, with an empty SigningPubKey and a Signers array of 17 signatures.
That is what a multi-signature transaction looks like. The bridge is controlled not by one key but by a list of 28 relayer keys (a relayer is one of the bridge’s operator programs, which watch both chains and co-sign its payouts), and a quorum of 17 must approve anything it does. Its master key is disabled, so the multisig is the only way it can act.
Rippling only moves issued tokens along trust lines. Native XRP has no trust line, so this path does not exist for XRP. No account flag can create it.
Every release is a Payment the bridge itself sent, with 17 of its 28 relayer keys signing each one. The cause sits upstream of the signatures, on the Coreum side.
The XRP did not leak out of the bridge. The bridge paid it out, and its relayer quorum signed every payment, from the first probe (50E065FC…) to the last release (CD308F78…). Whatever made the quorum authorise these transfers sits upstream of the signatures, not in any XRP Ledger flag.
Why it wasn't rippling
The warning, posted at 20:23 UTC while the drain was still running, named a specific mechanism: that the account’s DefaultRipple flag was on and two wallets were “draining native XRP through it via partial-payment loops.” Three parts of that can be checked, and all three fail.
1. Native XRP cannot ripple
“Rippling” is the movement of an issued token (an IOU) along a chain of trust lines through the issuer. It only ever touches trust-line balances. Native XRP has no issuer and no trust line, so it is never part of a rippling path. No setting on any account, on by default or not, can make native XRP “leak through” an issuer.
2. All of the loss was bridge-signed payments
Every XRP that left the bridge, split by cause:
3. DefaultRipple is on, and irrelevant; there were no partial payments
The flag really is set: the account has DefaultRipple on today. It governs issued tokens, which is exactly what a token bridge needs, and has no bearing on the XRP that moved. The releases also did not carry the tfPartialPayment flag, and neither did any other transaction in the incident, on the bridge’s side or the wallets’, so “partial-payment loops” does not describe them either.
The suggested one-transaction fix, an AccountSet to clear DefaultRipple, would have changed nothing, because the flag was never the lever.
The token side first, then the XRP
The order of the payments points at a bridge being driven, not a wallet being emptied. The first nine payments did not send XRP at all. They sent the bridge’s own wrapped-Coreum token, an IOU the bridge account issues under the generated currency code coreum7c8eb29e07, the naming scheme the bridge’s public specification uses for Coreum-side assets. They start with a 92-unit probe (50E065FC…), then a ladder that roughly doubles each step (27A1A932…) up to a final payment of 1,824,252 units: 4,356,778 units in all.
Only then does the account switch to native XRP: 3,249 XRP first (B1CB50EF…), a single 25,908.6 XRP transfer at the peak (A36A38BC…), then a steady rhythm of about 1,694.7 XRP to each wallet in turn (3B4F6764…, then 73676CFE… fifty seconds later) until the account was nearly empty.
To see why that order matters, picture what the bridge is: an escrow with a bookkeeper on another chain. The XRP Ledger account holds what users lock. A smart contract on Coreum keeps the books of who is owed what. The relayers are couriers between the two: each one watches both chains, holds one of the 28 keys, and co-signs whatever the contract’s books say should be paid. Honest books, honest payouts:
Coming back is the mirror image: return tokens on Coreum, the contract records what you are owed, and the relayers co-sign a real XRP Ledger payment from the bridge to you. The relayers decide nothing: they pay out whatever the contract’s books say is owed.
The attacker never funded the bridge. They moved the bridge’s own token between their own two wallets, tagged with a bridge memo. Because the bridge issues that token, the transfer showed up in its history, and the relayers, which never check that a payment was actually sent to the bridge, counted it as a deposit and minted the attacker the balance. First in small doubling amounts to prove the trick, then in bulk.
The first red arrow, how the contract’s books were poisoned, sits on Coreum, not on the XRP Ledger. Coreum is a public chain too, and its records show exactly what was fed to the contract.
How the books were poisoned
The bridge’s contract is open source, so we can be precise about where the payout decision is made. The contract that keeps the books runs on Coreum, and it never reads the XRP Ledger itself. It waits for its relayers to report what happened. Each relayer submits an attestation (the code calls it Evidence) saying “this XRP Ledger transaction deposited this much, for this recipient.” When enough relayers submit the same attestation, the contract treats the deposit as real and mints the wrapped tokens (contract/src/evidence.rs, the handle_evidence gate).
The whole design rests on relayers attesting only to deposits that really happened, and the relayer code, open source in the same repository, has a gap on exactly that point. A relayer builds a deposit attestation from any successful payment it sees in the bridge account’s history that carries a Coreum-recipient memo, reading the amount the ledger says was delivered (relayer/processes/xrpl_to_coreum.go). What it never checks is who the payment was sent to. It does not require the destination to be the bridge at all.
That gap is reachable because the bridge issues its own token on the XRP Ledger. Any movement of an issuer’s token touches the issuer’s account: when the attacker sent that token between their own two wallets, the bridge’s trust-line records changed, so the transfer landed in the bridge’s transaction history and the relayers picked it up. Attach the bridge memo, and a payment that never went near the bridge’s funds is read as a deposit into them.
That is what both chains show. The attacker’s opening move was a payment of 100 units of the wrapped-CORE token from one of their wallets to the other (3DB7E443…), never sent to the bridge, carrying the memo {"type":"coreumbridge-xrpl-v1","coreum_recipient":"core1e7y6…"}. On Coreum, 21 separate relayers each submitted that transaction to the contract as a deposit, and the contract minted the balance to the attacker’s account.
The XRP side used the same flaw a different way: the attacker paid XRP to themselves with the wrapped token set as the most to spend (3A04E779…), so the payment converted the token through the exchange’s order book, touching the bridge as issuer with the memo attached, and was read as a deposit of 1,714 XRP.
Repeated with growing amounts (the doubling ladder above), this minted the attacker about 4,356,812 CORE and 200,001 XRP of bridge tokens out of nothing, spread across a handful of Coreum accounts. Each was then bridged back the normal way, and that is the release the relayer quorum co-signed on the XRP Ledger. The 200,000 XRP that left the bridge is the withdrawal of a balance no deposit ever backed.
This points to a flaw in the logic, not stolen keys. 21 independent relayers each attested the very first phantom deposit. A stolen key or server does not make honest operators agree; shared code that looks right and is wrong does. Every relayer ran the same code, the code counted a self-transfer as a deposit, and every relayer attested it.
All of it is on two public chains. The bridge contract on Coreum is core1zhs909jp9yktml6qqx9f0ptcq2xnhhj99cja03j3lfcsp2pgm86studdrz, and the attacker’s main Coreum account is core1e7y6qwktg7l6ajr8e2eal5j4dnc2jyceftnjce. The two phantom payments above are on the XRP Ledger, and their matching attestations are on Coreum. Who the attacker is has not been made public.
The sell-off that found no buyers
What did the two wallets do with 4,356,778 freshly minted units? They tried to sell them on the XRP Ledger’s own exchange, and found almost nobody to sell to. Between them sit 94 conversion payments: a wallet paying itself XRP while spending the wrapped token, filled by whatever sell offers were on the order book. But the offers they crossed were mostly each other’s: about 191,000 XRP simply went back and forth between the pair, and less than 5,000 XRP of the proceeds came from anyone else.
Watched live, two new wallets posting offers and firing rapid conversion payments may well be what looked like “partial-payment loops” from the outside. None of it used partial payments, and none of it moved the bridge’s XRP. The wallets signed every one of those conversions themselves; the bridge’s balance only ever fell on payments the bridge signed.
Where the XRP went
Neither front wallet kept the XRP. Within hours both forwarded it in even chunks of about 9,600 to 9,720 XRP: A1 sent 92,488.3 XRP in 11 payments (9C0CF29C… is one) and A2 sent 77,324.9 XRP in 8 (C01D38D2…), mostly into two staging accounts created six weeks earlier, on 28 June 2026. Another 34,405.2 XRP went to three further wallets in the same even chunks.
The stolen XRP did not travel alone. Between 9 and 31 August the two staging wallets took in 169,813.2 XRP from the front wallets and another 941,104.2 XRP from 274 other accounts, and paid out 1,129,325.2 XRP in 335 payments to 201 accounts. Both have been empty since 31 August 2026.
Since then
Coreum renamed itself tx in March 2026, when it merged with Sologenic (tx.org). On 11 August tx posted: “The bridge has been halted, the vulnerability has been identified, and all potential remedies are being evaluated” (tx on X). The next day CoinDesk reported that tx had fixed the code, hired blockchain forensics specialists and filed a complaint with the FBI’s Internet Crime Complaint Center, and had not said how holders would be made whole (CoinDesk). The fix is not in the bridge’s public code: its repository has no commit after 5 September 2025.
On the XRP Ledger, the bridge has signed nothing since 02:56 UTC on 10 August (D60D83D0…). It holds 763.5 XRP: the 493.5 left after the drain, plus 270 XRP that another account paid in on 14 August with no memo (D402EBBC…), so no bridge deposit.
The wrapped CORE the attack minted is still on the XRP Ledger. Of the 6,021,494 units of 
What the warning got wrong
After the last release at 20:53 UTC (CD308F78…) no more XRP left the account. By the following afternoon the bridge contract was reported halted, which fits both facts: still able to sign at 02:56, stopped by the time of the report. The account’s flags are unchanged: master key disabled, DefaultRipple still on, no global freeze. Clearing DefaultRipple was never done and never needed to be, because it played no part in what happened.
Raising the alarm on a fast, abnormal outflow was the right instinct, and by the next day the thread had corrected itself: “it’s the coreum side”, in the author’s own words. On the XRP Ledger, an on-by-default flag and partial payments get blamed for many drains they have nothing to do with, and the way to tell is always the same: read who signed the transaction.
Reference transactions
Every hash below is a validated XRP Ledger transaction.
- First payment: 91.97 units of the bridge’s own wrapped-Coreum token to A2 · ledger 106,183,34650E065FCEAC40BB3B3DB22FBA70430AB08AC4F915F5D73F19C717C67282B76BB
- Wrapped-token ladder: 79,762 units to A1 (each step about doubles the last) · ledger 106,183,36927A1A9325F3910990EBAB1780EF12BDD040CDBF572277F3125E35E9F3370BE99
- First native-XRP release: 3,249 XRP to A2 · ledger 106,183,498B1CB50EF8651CD4C036B547972838A0826453B10B3A951CB1FB4F6D75F9EE433
- Largest single XRP release: 25,908.6 XRP to A1 · ledger 106,183,574A36A38BCD40971F0183B22E39DBA382556F7A9CA97ADABEFBB82CDAF9B28588B
- Steady-state cycle: 1,694.7 XRP to A1 · ledger 106,184,2163B4F67647C798D823B5BCE98F423F44D06DAF221054AA2F3851DC65574095E78
- Steady-state cycle: 1,694.7 XRP to A2, 50 seconds later · ledger 106,184,22973676CFE83996BA68D7DA216E3F1A1C1E18F3BD248FE55603F41D312D1C90EDA
- Last XRP release: 520.3 XRP to A1 · ledger 106,184,842CD308F78B8E3154F809C0DA46EE54BB9B00DAC14E81805A4F7317105B128020D
- The only transaction the bridge has signed since: 96.3 wrapped-token units, 02:56 the next morning · ledger 106,190,470D60D83D07AC20BB5F4A4CD9D746081063C9B27A1E74652362C927BDECE4439C5
- Onward hop: A1 forwards 9,616 XRP to a staging wallet · ledger 106,184,8779C0CF29CD70856C284073D9BE414700056D643EC2022663FA7C33E344C33D659
- Onward hop: A2 forwards 9,719 XRP to a staging wallet · ledger 106,187,318C01D38D2E60ED346DDB206B6212288C9D0369E1C37B7704F5977DF507937CCDA
- 14 August: 270 XRP paid into the bridge with no memoD402EBBC5304602F2F25E5D710603EC7180B46CA70A8BBFE077962CC6FC8A8D9
Bridge design and code: specification, contract source (the attestation gate is evidence.rs; the relayer’s missing destination check is in xrpl_to_coreum.go). The warning thread: original post, correction, halt report. tx’s statement.
Coreum side (public chain): bridge contract core1zhs909jp9yktml6qqx9f0ptcq2xnhhj99cja03j3lfcsp2pgm86studdrz; attacker’s main account core1e7y6qwktg7l6ajr8e2eal5j4dnc2jyceftnjce. The two phantom “deposits” on the XRP Ledger, a wallet-to-wallet token transfer (3DB7E443…) and a self-directed XRP payment (3A04E779…), each appear on Coreum as an xrpl_to_coreum_transfer attested by 21 relayers against the bridge contract.