Twenty-one independent relayers, each running their own node, all signed off on a deposit that never left the sender’s wallet. The bridge between XRP Ledger and Coreum (now tx) accepted a fake deposit as real, minted unbacked assets, and let an attacker drain 198,715.88 XRP—worth roughly $200,000 at the time. The loss is small by industry standards, but the structural failure is not. This is not a failure of cryptography; it is a failure of logic. And it is a failure that will repeat unless the industry stops treating multisig as a silver bullet.
Context: The Bridge That Trusted the Wrong Signal
The bridge in question is a cross-chain protocol connecting XRPL to the Coreum ecosystem. It uses a relay-based model: 21 independent relayers monitor XRPL for deposit transactions, verify them, and then mint equivalent wrapped assets on the Coreum side. The architecture is standard—observer nodes, a multisig threshold, and a deposit-address scheme. But the implementation had a hidden flaw in how it parsed XRPL transactions. The bridge did not require the deposit to be a transfer of native XRP to the bridge’s vault. It accepted any transaction that included a deposit memo, even if the asset being moved was the bridge’s own wrapper token, circulating internally between two attacker-controlled wallets.
Core: The Bytecode Never Lies
I do not read the whitepaper; I read the bytecode. The vulnerability here is a classic case of event misidentification. The bridge’s software on Coreum scanned the XRPL for incoming payments to a specific account. But it did not verify the source of the funds. The attacker used the bridge’s own issued token—a wrapper token that the bridge itself had minted—and transferred it between two wallets. In the transaction memo, they appended a deposit instruction. The bridge’s software saw the deposit memo, saw a transfer to the bridge address, and concluded: “This is a real deposit.” It then minted the corresponding wrapped asset on Coreum. The attacker repeated this cycle, escalating the amounts, and each time the 21 relayers—all running the same flawed logic—unanimously approved the mint.
The attack was not a reentrancy exploit, not a consensus attack, not a signature forge. It was a logical spoon-feeding of the bridge’s own data. The bridge trusted its own token’s movement as if it were native XRP, because it never checked the asset type. The whitepaper might have promised a secure bridge, but the bytecode read: “If transfer to vault address and memo contains deposit, then mint wrapped asset.” No asset filter. No source validation. No confirmation that the vault actually received XRP. The 21 relayers were not 21 independent verifiers; they were 21 copies of the same broken logic.
I do not read the whitepaper; I read the bytecode. The relayers’ unanimity is not a strength—it is a symptom of a single point of failure in the verification rule set. In a secure bridge, each relayer might run a different client or apply independent checks. Here, they all trusted the same parse of the XRPL ledger. The attacker only needed to fool one piece of software, and the entire multisig network collapsed in lockstep.
Contrarian: What the Bulls Got Right—and What They Missed
The bulls will point to the positive signals: the team paused the bridge quickly, filed a report with the FBI, and no other assets were compromised. The loss is only $200k, a rounding error in the XRP market. The XRP Ledger itself was not attacked. These are all true. But they miss the structural rot. The low loss is a function of the bridge’s small size, not its security. The FBI report is a PR move, not a code fix. The fact that no other assets were compromised is a coincidence—the attacker only exploited the wrapper token path, but the same logic flaw could have been used to mint any asset if the bridge had issued other tokens. The real lesson is that a multisig of 21 relayers is meaningless if all relayers share the same single point of failure in their verification algorithm. This is not a bug; it is a design philosophy that equates redundancy with security, when in fact it is redundant vulnerability.
Takeaway: The Bridge Is Dead, But the Lesson Lives
I do not read the whitepaper; I read the bytecode. The bridge between XRPL and Coreum is now paused. To restore trust, the team must rewrite the verification logic from scratch—filtering only native XRP deposits, adding a source account check, and ideally introducing a fraud-proof or zero-knowledge proof to replace the relayers’ blind trust. But even that may not be enough. The attacker’s funds have already been laundered through THORChain and Tornado Cash. The bridge’s reputation is in the hands of the FBI now. For the industry, this is a warning: if your bridge’s security model relies on N nodes all running the same software, you have not built a distributed trust network. You have built a single point of failure with N faces. The 21 relayers approved a ghost deposit. The ghost was not the transaction—it was the illusion of security.