How a Bridge Can Drain Without Stolen Keys: Inside the 200,000 XRP Relayer Logic Flaw

The Coreum-XRPL bridge lost nearly 200,000 XRP after an attacker exploited the bridge’s transaction-verification logic without stealing validator keys or compromising the XRP Ledger itself.

On-chain analysis published by XRPL.to found that 199,916.3 XRP left the bridge on Aug. 9 through 94 payments over roughly 97 minutes. The bridge held about 200,410 XRP before the withdrawals began and was left with about 493.5 XRP.

What makes the incident unusual is that the withdrawals were properly authorized. Each payout contained the bridge’s own multisignature approval, which requires signatures from 17 of its 28 relayer keys. There is currently no evidence that those keys were stolen.

Relayers are programs that monitor activity on connected blockchains and tell the bridge when a qualifying deposit has occurred. Once enough relayers agree, the corresponding asset can be credited or released on the other network.

According to the XRPL.to analysis, the flaw was in determining what actually counted as a deposit.

The bridge issues a wrapped CORE token on the XRP Ledger. Because it is the token issuer, transactions involving that asset can affect records associated with the bridge account even when funds are moving between two unrelated wallets.

The attacker allegedly exploited that behavior by making transactions between wallets they controlled and attaching the memo format expected by the bridge. Relayers detected those transactions and treated them as deposits even though the attacker had not actually transferred the claimed funds into the bridge.

In one example, 21 separate relayers reportedly submitted the same attacker-controlled transaction to the Coreum bridge contract as a legitimate deposit. Similar transactions eventually allowed the attacker to create unbacked bridge balances representing roughly 200,001 XRP alongside millions of CORE tokens.

The attacker could then withdraw the artificially created balance through the bridge’s normal process.

That distinction explains how a bridge can lose funds even when its multisig security works exactly as designed. The 17-of-28 signature threshold protected the bridge from an attacker directly controlling its wallet. It did not protect against all of the relayers running the same flawed verification logic.

Once the system incorrectly accepted the phantom deposits, the resulting withdrawals appeared legitimate to the relayers. They therefore produced genuine signatures authorizing payouts from the bridge’s real XRP reserves.

The incident sheds some light on a different class of bridge risk: multisig security can protect custody while leaving the assumptions that determine what should be signed vulnerable.

For cross-chain systems, verifying that a transaction exists is not enough. Relayers also need to establish that funds reached the correct destination, involved the expected asset and amount, and genuinely created the economic deposit that the corresponding withdrawal is supposed to represent.