Hook
21 independent validators. 21 signatures. One phantom transaction. On March 8, 2025, the bridge connecting XRP Ledger to Coreum (now tx) was drained of 198,715.88 XRP. The attack took 97 minutes. No alarms triggered. No single relayer flagged the anomaly. The multi-sig firewalls performed exactly as designed—but the design itself was the vulnerability.
Pattern recognition precedes prediction. When every validator runs the same flawed logic, redundancy becomes a single point of failure. This is not a crypto attack. It is a software engineering autopsy.
Context
The bridge in question is a relay-based cross-chain messenger: it monitors XRP Ledger transactions, interprets deposit events, and instructs Coreum to mint wrapped assets. The model is simple—a set of 21 Coreum relayers observe the source chain, agree on a set of events, and authorize minting. No light client verification. No zero-knowledge proofs. Just trust in the relayers' software to correctly parse XRPL transactions.
According to the post-mortem analysis by researcher Reza Bashash, the attack exploited a gap between the bridge's internal token transfer logic and its deposit event recognition. The bridge issued its own wrapper tokens on XRPL. Attackers transferred these wrapper tokens between their own wallets while attaching a deposit memo. The Coreum-side software misinterpreted this internal transfer as a legitimate cross-chain deposit of real XRP. All 21 relayers approved. The bridge minted unbacked assets on Coreum. Attackers then redeemed those assets for real XRP before the bridge paused.
Core: The On-Chain Evidence Chain
Let me reconstruct the data trail. I have traced similar patterns before—in 2021, during my NFT wash trading analysis, I identified five wallets generating 30% of Bored Ape Yacht Club volume by self-trading. The same principle applies here: the attack is not a cryptographic break but a misinterpretation of what constitutes a “real” deposit.
Step 1: The Bridge’s Wrapper Token on XRPL
The bridge operates by issuing a representation of its own minted assets on the source chain. These tokens are used for internal accounting. Attackers acquired these wrapper tokens—likely through legitimate swaps or flash loans—and then initiated a transfer between two addresses they controlled. The transaction included a memo field that the bridge’s observer software parsed as a deposit request.
Step 2: The Misinterpretation
The bridge’s software, running on Coreum, scanned the XRPL ledger for deposit events. It looked for transactions that matched a specific pattern: a transfer to the bridge’s deposit address with a memo containing a destination address on Coreum. However, the code did not verify the origin of the transferred asset. It checked the destination address and the memo, but not the token type. Because the bridge’s own wrapper token was sent to the bridge’s deposit address, the software treated it as a valid deposit of XRP.
Step 3: The Relayer Consensus Failure
All 21 relayers independently validated the same transaction. They ran the same software, parsed the same ledger data, and reached the same conclusion: a deposit of XRP. No relayer queried the actual balance of the bridge’s XRP reserve on XRPL. No relayer checked whether the transaction involved the bridge’s own token versus real XRP. The multi-signature mechanism provided no security because the verification logic was homogeneous. This is a structural flaw I have highlighted in my own audits: a multi-sig of identical nodes is not decentralization; it is a single point of failure dressed as a committee.
Step 4: The Escalation
The attack repeated with escalating amounts. The first transaction was small—a test. Once the minting succeeded, the attackers repeated the same pattern, each time increasing the amount. The bridge had no per-transaction cap, no cumulative withdrawal limit, no anomaly detection. The funds flowed: phantom minting on Coreum, then withdrawal of real XRP from the bridge’s reserve. Within 97 minutes, 198,715.88 XRP was gone.
Step 5: The Money Trail
The stolen XRP was swapped to ETH via THORChain, then funneled into Tornado Cash. The choice of THORChain is telling: it offers strong liquidity and no KYC, making it a preferred routing point for attackers. The final destination, Tornado Cash, is under OFAC sanctions. This introduces a regulatory angle that the project cannot ignore.
Contrarian: The Real Risk Is Not the $200K Loss
At first glance, the loss is minor—~$200,000 at the time of the attack. Compare that to the Ronin bridge hack ($600 million) or the Wormhole exploit ($320 million). This is a rounding error in crypto market terms. But the true cost is not the lost XRP; it is the revealed fragility of the relay-based bridge model.
Counter-intuitive angle #1: Multi-sig is not security when the logic is shared.
The market often equates “21 validators” with “21 security layers.” In reality, if all 21 run the same binary, they will all make the same mistake. The attack exploited a single logic flaw, and the multi-sig merely amplified the error by approving it many times. The probability of detection was zero because there was no diversity in verification logic. This is a governance failure, not a technology failure.
Counter-intuitive angle #2: The bridge’s own token was the vector.
Most bridge audits focus on the security of the wrapped asset on the destination chain. Here, the attack used the bridge’s own representation token on the source chain. The assumption that “only real XRP can be deposited” was not enforced in code. The bridge treated its own wrapper token as a valid deposit asset because the deposit logic did not filter by token type. This is a classic case of insufficient input validation.
Counter-intuitive angle #3: The attacker’s profit is small, but the precedent is dangerous.
The attack is reproducible. The same logic flaw can be exploited on any relay-based bridge that does not strictly verify the source asset type. The market should not dismiss this as a one-off event. The underlying pattern—misidentifying internal token transfers as deposits—is a design anti-pattern that likely exists in other bridges. The next exploit could be larger.
Takeaway: The Signal for Next Week
History is written in blocks, not promises. The bridge is now paused. The team has reported the incident to the FBI. A compensation plan is under discussion. But the fundamental issue remains: the relayers’ verification logic is homogeneous. Without introducing diversity—either by running multiple independent client implementations or by adding zero-knowledge proofs—the bridge will remain vulnerable to the same class of attack.
Liquidity evaporates when logic fails. The immediate market impact on XRP is negligible. The real impact is on the trust model for relay-based bridges. Investors should demand proof of verification diversity, not just a count of validators. The next time a bridge claims 21 signatures, ask: 21 copies of the same bug, or 21 distinct perspectives?
For my own part, I will be watching the on-chain activity of the attacker’s wallet. The funds are now in Tornado Cash, but the pattern of the attack itself—the gradual escalation, the use of wrapper tokens, the reliance on a single logical gap—will resurface. Pattern recognition precedes prediction. The ghost in the machine has been identified. Now the question is: how many other bridges are running the same ghost?