The issue in the XRPL–Coreum bridge incident appears straightforward: when identifying inbound XRPL transfers, the relayer failed to verify whether the Payment Destination was the bridge address.
However, treating the incident as nothing more than a missing if statement would miss the more important issue. The relayer used an incomplete set of conditions to determine whether an XRPL transaction represented a valid bridge deposit. As a result, a transaction associated with the bridge account could be incorrectly classified as an inbound deposit and then converted into evidence accepted on the Coreum side.
The vulnerability therefore involved more than a single field check. It affected transaction discovery, inbound transfer classification, memo parsing, evidence generation, and the multi-relayer verification process.
From MoveBit’s security research perspective, this is also a useful case for examining a broader class of cross-chain risks. A contract on the destination chain may be secure, while the off-chain component responsible for interpreting source-chain transactions introduces incorrect state. For Move-based bridges, this boundary deserves the same level of review as the on-chain contract itself.
1. account_tx Can Discover Transactions, but It Cannot Prove a Deposit
The Coreum relayer monitors the bridge account using XRPL’s account_tx RPC method. This is a reasonable approach because account_tx returns validated transactions associated with a specified account and can therefore be used to identify candidate transactions for further processing.
The problem is that a transaction being associated with an account does not mean that the transaction transferred assets to that account.
The results returned by account_tx should therefore be treated only as candidate transactions. Before classifying any of them as an XRPL-to-Coreum deposit, the relayer still needs to verify the Payment direction, destination, asset, amount, memo, and other relevant fields.
The processing logic can be simplified as follows:
The problem is that the code effectively sends any transaction not initiated by the bridge into the incoming-transaction processing path.
A transaction not being sent by the bridge does not mean that it was sent to the bridge. A correct inbound Payment check must at least confirm:
require(payment.Destination == bridgeAddress)
Without this check, a transaction that involves the bridge account but does not actually transfer funds to it may still be processed as a deposit.
2. The Relayer Validated the Transaction State but Not the Full Deposit Conditions
The incoming-transaction path did perform several validations. The public implementation can be simplified to something like:
These checks confirm that the XRPL transaction was validated, that the Payment succeeded, that the transaction type was correct, that a Coreum recipient could be extracted from the memo, and that the delivered amount could be obtained from the transaction metadata.
However, these conditions are still not enough to prove that the bridge received the funds.
DeliveredAmount is particularly important here. It represents the amount actually delivered by a Payment to its recipient, but it does not independently prove that the recipient was the bridge. Even if tx.success == true and DeliveredAmount is present, the transaction cannot automatically be treated as a bridge deposit.
The validation logic must also enforce:
The underlying transaction may therefore be completely valid on XRPL while still failing to satisfy the bridge’s own deposit requirements.
3. Memo Data Should Be Used for Routing, Not as Proof of Deposit
The XRPL–Coreum bridge uses memos to carry cross-chain routing information, such as the destination Coreum address. The relayer parses this memo to determine where the bridged assets should eventually be credited on Coreum.
This design is common, but memo data is controlled by the transaction sender. It can provide routing information, but it should not be used as evidence that a valid bridge deposit occurred.
An attacker can construct a valid XRPL Payment containing a correctly formatted bridge memo. A valid memo only proves that the transaction contains data matching the bridge’s expected format. It does not prove that the Payment Destination is the bridge.
A safer processing order is:
The system should first confirm that the transaction actually transferred assets to the bridge, then verify the asset and amount, and only after that use the memo to determine the cross-chain recipient.
If the destination has not yet been verified, attacker-controlled memo data should not be allowed to influence evidence generation.
4. Missing Destination Data in the Evidence Limited Coreum-Side Verification
Another important issue is the loss of transaction context when XRPL data is converted into evidence for Coreum.
The public XRPLToCoreumTransferEvidence structure is roughly:
The XRPL Payment Destination is not included.
This means that the relayer has access to the full XRPL transaction during processing, but after the evidence object is created, the Coreum side receives only a subset of those fields.
The original transaction contains information such as the sender, destination, asset, amount, transaction result, and memo. The evidence retains only part of that context.
As a result, if the relayer fails to validate the destination before creating the evidence, the Coreum contract may not have enough information to independently confirm that the Payment was actually sent to the bridge.
This design pattern requires careful handling. Any field that directly determines whether cross-chain assets can be credited or released should be fully validated before evidence is created. Where appropriate, fields such as Destination can also be included in the evidence so that the on-chain logic can perform an additional check.
5. Multiple Relayers Do Not Protect Against Shared Validation Bugs
The Coreum bridge uses an evidence-threshold mechanism. Multiple trusted relayers must submit matching evidence before the bridge proceeds with the cross-chain workflow.
This mechanism can reduce the risk of a single relayer acting maliciously, being compromised, or malfunctioning. However, it does not automatically protect against a validation bug shared by every relayer.
If multiple relayers run the same software version and that implementation is missing the Destination == bridgeAddress check, each relayer may classify the same invalid transaction in the same way and submit matching evidence.
The process can look like this:
An N-of-M relayer model shows that multiple relayers reached the same conclusion about a transaction. It does not prove that the classification rule used by those relayers is correct.
Relayer count and relayer validation logic are therefore separate security concerns. Increasing the number of relayers reduces certain single-point-of-failure risks, but it does not prevent a shared software defect from reaching the evidence threshold.
6. Multisig Protects Signing Authority, but It Cannot Correct Invalid Bridge State
Assets on the XRPL side of the bridge are protected by a multisignature account. Multisig reduces the risk that a single private key or signer can directly control bridge funds.
However, the vulnerability occurred earlier in the workflow, during state validation.
If invalid deposit evidence has already been accepted on Coreum and the system generates a withdrawal request based on that state, the withdrawal may appear completely valid to the signers.
In that situation, the final XRP transaction can be generated through the normal workflow and signed by the required number of authorized signers. The multisig mechanism has not been bypassed, and the signature process itself is functioning correctly.
The problem is that the withdrawal was created from incorrect cross-chain state.
Multisig can prevent unauthorized transfers, but it cannot determine whether the deposit evidence that produced a withdrawal request was valid. Custody security and cross-chain state verification therefore need separate controls. Multisig cannot replace upstream transaction validation.
7. Incoming Payment Verification Should Bind All Deposit-Critical Fields
A safer implementation should fully validate whether an Incoming Payment satisfies the definition of a bridge deposit before generating evidence.
For example:
The destination check is only one part of the solution. Sender, destination, asset, amount, recipient, and transaction hash should all be included in the validation logic.
Only after all of these conditions are satisfied should the transaction be classified as a valid XRPL-to-Coreum deposit and used to generate cross-chain evidence.
8. Tests Should Cover Transactions That Are Valid on XRPL but Invalid for the Bridge
Bridge relayer tests should not focus only on normal deposits and obviously malformed transactions. They should also cover transactions that are fully valid under XRPL rules but do not satisfy the bridge’s business logic.
Examples include:
All of these transactions may pass XRPL consensus and execute successfully. Their validity at the protocol level therefore cannot be used as proof that they represent valid bridge deposits.
The relayer must apply bridge-specific semantic validation on top of the source chain’s transaction rules.
9. Runtime Monitoring Can Provide a Second Layer of Protection
In addition to fixing the transaction-validation logic, a bridge should monitor reserves and cross-chain accounting for abnormal behavior.
The Coreum bridge already includes a kill switch. This mechanism can be combined with asset-flow and accounting checks so that unusual conditions trigger an alert or halt.
For example:
These controls do not replace relayer validation, but they can provide additional protection if a bug in the verification logic allows invalid state to enter the system.
This is especially important for bridges because they combine several independent components, including source-chain parsing, off-chain relayers, threshold verification, smart contracts, key management, and asset accounting. A failure in one component should not automatically result in unrestricted asset outflow.
Implications for Move Developers
The same issue is particularly relevant to cross-chain systems built in the Move ecosystem. In MoveBit’s security work across Move-based networks, bridge security cannot be evaluated only from the Move contract layer. The relayer and source-chain verification logic are also part of the system that determines whether assets can be minted, credited, or released.
Move’s type system, resource model, ownership rules, and bytecode verification can prevent many classes of on-chain asset-handling errors. However, these mechanisms can only ensure that Move code executes safely according to the state and inputs it receives. They cannot determine whether information supplied by an off-chain system or another blockchain is correct.
If an off-chain relayer submits invalid deposit evidence to a Move contract and the contract has no independent way to verify the corresponding source-chain transaction, the contract may still mint assets, update balances, or allow withdrawals based on incorrect evidence, even if the Move code itself has no type-safety or resource-management flaws.
For Move bridges and other cross-chain infrastructure, this is why MoveBit’s security reviews look beyond the Move contracts themselves. Relayer behavior, source-chain transaction parsing, evidence construction, replay protection, and the handling of security-critical fields all need to be reviewed when they can directly affect on-chain asset state.
Security Takeaway
The immediate issue in the XRPL–Coreum bridge incident was the absence of a Destination == bridgeAddress check in the Incoming Payment flow. At the system level, however, the more important problem was that the relayer used incomplete conditions to determine whether an XRPL transaction represented a valid bridge deposit.
A source-chain transaction executing successfully only proves that it satisfies the source chain’s protocol rules. It does not prove that it satisfies the bridge’s deposit requirements. The relayer must independently validate the destination, asset, amount, transaction result, memo, transaction hash, and any other fields that directly affect bridge accounting before generating evidence for the destination chain.
Multi-relayer thresholds, multisig custody, and Move’s on-chain safety mechanisms address different categories of risk. None of them can replace complete source-chain event validation.
For cross-chain systems, one of the most important security questions is simple: what exact conditions must be satisfied before a source-chain transaction is classified as a valid bridge deposit? Those conditions should be explicit, complete, and enforced before the evidence is submitted to the destination chain.
For MoveBit, this is also an important part of how we approach cross-chain security. Reviewing a Move contract alone is not enough when off-chain relayers, source-chain parsers, and evidence-generation logic can directly change the state that the contract receives. A complete bridge security review needs to cover both the on-chain execution logic and the components responsible for producing cross-chain evidence.
MoveBit continues to research security issues across Move-based ecosystems, with a focus on smart contract security, cross-chain infrastructure, and the assumptions that affect asset safety beyond the contract itself.