Coreum XRPL Bridge Lost 199,916 XRP in Suspected Relayer Logic Exploit

How the XRP left the bridge

According to the transaction review, every outgoing XRP payment was authorized through the bridge’s own multisignature process. Each payout carried 17 signatures from a set of 28 relayer keys, suggesting the withdrawals were approved by the system’s normal signing flow rather than by stolen keys.

XRPL.to reported that the attacker was able to trigger real XRP withdrawals after the bridge credited balances that were not backed by actual deposits. In total, the bridge account sent 94 signed XRP payments during the attack window. No further XRP was seen leaving the account after 20:53 UTC on Aug. 9.

Suspected flaw in relayer verification

The published analysis points to the bridge’s transaction interpretation logic. The attacker allegedly moved the bridge’s own wrapped Coreum token between wallets under their control while attaching memos formatted for the bridge. Because the bridge account issues that wrapped token, those transfers appeared in the account history.

Public relayer code reportedly checks whether a payment succeeded, reads the delivered amount and extracts a Coreum recipient from the memo before submitting deposit evidence. But the described processing flow does not verify that the payment destination was the bridge address first. That omission appears to have allowed self-payments with the correct memo format to be treated as valid deposits.

XRPL.to said 21 relayers attested the attacker’s first phantom transaction. Once enough matching evidence reached the Coreum contract, the system is said to have credited balances that did not correspond to genuine XRP deposits, after which the attacker used the ordinary withdrawal mechanism to obtain real XRP.

Why analysts rejected the initial rippling explanation

An early warning reportedly blamed rippling and the bridge account’s DefaultRipple setting. The later review disputed that explanation directly. XRP Ledger documentation states that rippling applies to issued assets that move through trust lines, while native XRP does not use trust lines.

The transaction record also did not match a rippling-based loss, according to the analysis. XRPL.to attributed the full 199,916.3 XRP removed from the bridge to payments signed by the bridge itself and said no XRP left through a rippling route. It also found that the transactions were not partial payments.

Based on that evidence, the incident does not currently indicate an XRP Ledger consensus failure. Instead, it fits a broader bridge security pattern in which the underlying blockchain remains intact but a cross-chain verification system accepts incorrect event data.

Funds moved on as the bridge stayed offline

The two first receiving wallets forwarded nearly all of the stolen XRP within hours. XRPL.to traced about 169,000 XRP into two staging accounts created on June 28, while roughly another 34,000 XRP moved toward three other wallets. The analysis did not identify the attacker.

After the Aug. 9 outflows stopped, the bridge account made one more wrapped-token transaction early the following morning and then went quiet. The bridge contract was later reported halted. Under the bridge specification, any relayer or the contract owner can halt operations in response to unexpected behavior, but only the owner can restart them.

What comes next

As of the Aug. 11 analysis, Coreum had not published a formal post-incident explanation. The main confirmed issues to watch are whether the project releases an incident report, whether the suspected destination-verification flaw in relayer handling is remediated, and whether any recovery effort is pursued for the transferred XRP.

A separate reopening decision also remains outstanding, since the bridge specification gives the owner control over resuming operations after a halt.