The Coreum Bridge Released 200,000 XRP. It Wasn't Rippling.
On 9 August 2026 the XRP Ledger account that operates 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 one of those payments was signed by the bridge’s own multisig, and native XRP cannot be rippled at all. Reading both public chains together, the real cause is a relayer that mistook the attacker’s own self-payments for deposits — here is the whole chain of evidence.
What happened
The bridge account rxXXXeMX8Gy5YvibvGLnQJ1XKKD7UswM1— the official Coreum account for XRP Ledger operations — held about 200,410 XRP on the afternoon of 9 August 2026. Starting at 19:16 UTC it began sending that XRP away in a steady stream of payments to two brand-new wallets, alternating between them roughly every 51 seconds. Ninety-seven minutes later it held 493.5 XRP. No XRP has left it since — the account has signed exactly one transaction more, a small wrapped-token payment early the next morning.
The two destinations were created the same afternoon, less than two hours before the first payment: rfXSfH2q4zhGWdw45nYcWfjvFN5ZfwE1U6 at 17:34 UTC and rwt8PJhyXWgW8uwmTjmQ7Rw89tJHELFgb5 at 17:57 UTC. They received about 107,397.5 XRP and 92,518.8 XRP respectively, then forwarded almost all of it onward within hours. Both hold roughly 3 XRP today.
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 Accountfield — it is the sender, not a bystander — with an empty SigningPubKey and a Signers array of 17 signatures. That is the on-chain signature of a multi-signature transaction: the bridge is controlled not by one key but by a list of 28relayer keys — a relayer being one of the bridge’s operator programs, which watch both chains and co-sign its payouts — of which a quorum of 17 must jointly approve anything it does. Its master key is disabled, so the multisig is the only way it can act.
In other words, 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 (50E065FCEAC40BB3B3DB22FBA70430AB08AC4F915F5D73F19C717C67282B76BB) to the last release (CD308F78B8E3154F809C0DA46EE54BB9B00DAC14E81805A4F7317105B128020D). Whatever caused the quorum to authorise these transfers, the cause 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 DefaultRippleflag was on and two wallets were “draining native XRP through it via partial-payment loops.” Three separate parts of that are checkable, 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 — it is never part of a rippling path. So no setting on any account, on-by-default or not, can make native XRP “leak through” an issuer. The premise is not just unlikely here; it is not a thing the ledger can do.
2. The numbers attribute 100% of the loss to bridge-signed payments
We can settle it by counting. Splitting every XRP that left the bridge by cause:
3. DefaultRipple is on — and irrelevant; the payments were not partial payments
The flag really is set: the account has DefaultRippletrue today. That is a true detail that points nowhere — 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 tfPartialPaymentflag — in fact not one transaction anywhere in the incident did, on the bridge’s side or the wallets’ — so “partial-payment loops” does not describe them either. And 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 sequence itself 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 (50E065FCEAC40BB3B3DB22FBA70430AB08AC4F915F5D73F19C717C67282B76BB), then a ladder that roughly doubles each step (27A1A9325F3910990EBAB1780EF12BDD040CDBF572277F3125E35E9F3370BE99) up to a final payment of 1,824,252 units — 4,356,778 units in all.
Only after that does the account switch to releasing native XRP, beginning with 3,249 XRP (B1CB50EF8651CD4C036B547972838A0826453B10B3A951CB1FB4F6D75F9EE433), spiking to a single 25,908.6 XRP transfer (A36A38BCD40971F0183B22E39DBA382556F7A9CA97ADABEFBB82CDAF9B28588B), then settling into a metronomic rhythm of about 1,694.7 XRP to each wallet in turn (3B4F67647C798D823B5BCE98F423F44D06DAF221054AA2F3851DC65574095E78 then 73676CFE83996BA68D7DA216E3F1A1C1E18F3BD248FE55603F41D312D1C90EDA fifty seconds later) until the account was nearly empty.
To see why that sequence is damning, picture what the bridge actually is: an escrow with a bookkeeper on another chain. The XRPL 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 28keys, and co-signs whatever the contract’s books say should be paid. Honest books, honest payouts:
The first red arrow — howthe contract’s books were poisoned — is the part that sits on Coreum, not the XRP Ledger. Coreum has not published a post-mortem, but Coreum is a public chain too, and its records show exactly what was fed to the contract. Reading both chains together, the mechanism is no longer a mystery. It is below.
How the books were poisoned
The bridge’s contract is open source, so we can be precise about where the payout decision is made — and honest about what the code cannot tell us. The contract that keeps the books runs on Coreum, and it never reads the XRP Ledger itself. Instead it waits for its relayers to report what happened. Each relayer submits an attestation— the code calls it Evidence— saying “this XRPL transaction deposited this much, for this recipient.” When enough relayers submit the same attestation to cross a set threshold, the contract treats the deposit as real and mints the wrapped tokens (contract/src/evidence.rs, the handle_evidence gate).
The safety of that whole design rests on the relayers only attesting 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 issuesits own token on the XRP Ledger — the wrapped-CORE IOU from a moment ago. 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’ scanner picked it up. Attach the bridge memo, and a payment that never went near the bridge’s funds gets read as a deposit into them.
That is precisely 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 (3DB7E443981B9757DB878DE7A2079AFE2D69EA08BF532D46CE5B74A4D5BC73C5) — a wallet-to-wallet transfer, never sent to the bridge — carrying the memo {"type":"coreumbridge-xrpl-v1","coreum_recipient":"core1e7y6…"}. On Coreum, 21 separate relayerseach 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 maximum to spend (3A04E779DBFC0BD8CF9D5BB1FE46CED182BFC4690C33BC4288107DDD8D2F2365), so the payment converted the IOU through the DEX order book — touching the bridge as issuer, memo attached — and was read as a deposit of 1,714 XRP.
Repeated with escalating amounts — that is the doubling ladder from earlier — this minted the attacker roughly 4,356,812 CORE and 200,001 XRPof bridge tokens out of nothing, spread across a handful of Coreum accounts. Each was then bridged back the honest 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 that no deposit ever backed.
And this points to a logic flaw, not stolen keys. 21 independent relayers each attested the very first phantom deposit. A key or server compromise does not make honest operators agree; only shared logic 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 dutifully attested it. The DefaultRipple flag the original warning blamed stays a red herring: the payments were visible to the bridge because it issues the token, which is true no matter how that flag is set.
All of this is on two public chains. The bridge contract on Coreum is core1zhs909jp9yktml6qqx9f0ptcq2xnhhj99cja03j3lfcsp2pgm86studdrz; 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. What is still notpublic is who the attacker is, and whether any relayer operator was more than negligent — that is for Coreum’s own post-mortem, which had not appeared as of 11 August 2026.
The sell-off that found no buyers
What did the two wallets do with 4,356,778freshly 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 are on the order book. But the offers they crossed were overwhelmingly each other’s— about 191,000 XRP simply circulated between the pair, and less than 5,000 XRP of the proceeds came from anyone else. They still hold about 4,069,631 units between them, pointing at a bridge that has since been halted.
That churn matters for the story. Watched live, two fresh wallets posting offers and firing rapid conversion payments may well be what read as “partial-payment loops” from the outside — but none of it used partial payments, and none of it moved the bridge’s XRP. Every one of those conversions was signed by the wallets themselves, and the bridge’s balance only ever fell on payments the bridge signed.
Where the XRP went
Neither receiving wallet kept the XRP. Within hours both forwarded it onward in even chunks of roughly 9,600–9,720 XRP — A1 sending about 92,000 XRP (9C0CF29CD70856C284073D9BE414700056D643EC2022663FA7C33E344C33D659and ten more like it) and A2 about 77,000 XRP (C01D38D2E60ED346DDB206B6212288C9D0369E1C37B7704F5977DF507937CCDAand seven more) — mostly into two accounts created six weeks earlier, on 28 June 2026, within twenty seconds of each other. Another ~34,000 XRP went to three further wallets in the same even chunks.
The two receiving wallets being minutes old while the wallets behind them were weeks old is the ordinary shape of a laundering path: fresh, disposable front wallets take the funds directly, then hand off to older staging accounts before the money reaches anywhere that has to answer for it.
Where it stands
After the last release at 20:53 UTC (CD308F78B8E3154F809C0DA46EE54BB9B00DAC14E81805A4F7317105B128020D) no more XRP left the account, and its balance has sat at 493.5 XRP since. The bridge signed exactly one more transaction — 96.3 units of the wrapped token at 02:56 the next morning (D60D83D07AC20BB5F4A4CD9D746081063C9B27A1E74652362C927BDECE4439C5) — and then went silent. 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. That last point matters for anyone reading the original advice: clearing DefaultRipple was never done and never needed to be, because it played no part in what happened.
None of this is a knock on the person who raised the alarm. Spotting a fast, abnormal outflow and shouting is the right instinct, and by the next day the thread had corrected itself— “it’s the coreum side”, in the author’s own words. The point of writing it up is narrower: on the XRP Ledger, an on-by-default flag and partial paymentsget blamed for a lot of 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; click to open it. Nothing here depends on trusting us — the sender, amount, signatures and result are on the public ledger.
Accounts: bridge rxXXXeMX8Gy5YvibvGLnQJ1XKKD7UswM1; receiving wallets rfXSfH2q4zhGWdw45nYcWfjvFN5ZfwE1U6, rwt8PJhyXWgW8uwmTjmQ7Rw89tJHELFgb5; staging wallets rnaBRmXU6ZS7orU6Qj38wsBYQmqHPbrhA9, r3jV8g599WMR9zeFi5m1rbvXyEwNWwYFXt. To reproduce the totals, run account_tx on the bridge account over ledgers 106,183,346–106,184,842 and sum delivered_amount by destination.
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.
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 3DB7E443981B9757DB878DE7A2079AFE2D69EA08BF532D46CE5B74A4D5BC73C5 and a self-directed XRP payment 3A04E779DBFC0BD8CF9D5BB1FE46CED182BFC4690C33BC4288107DDD8D2F2365— each appear on Coreum as an xrpl_to_coreum_transfer attested by 21 relayers against the bridge contract.