[{"data":1,"prerenderedAt":20},["ShallowReactive",2],{"blog-detail:when-account-history-was-misclassified-as-deposit-proof-a-technical-analysis-of-the-xrpl-coreum-bridge-vulnerability-f867e8":3},{"category":4,"article":5},null,{"slug":6,"category":7,"categoryLabel":8,"subcategoryLabel":9,"authorName":10,"title":11,"excerpt":12,"contentHtml":13,"coverUrl":14,"publishedAt":15,"updatedAt":16,"readTime":17,"cover":14,"hasCover":18,"coverAlt":19},"when-account-history-was-misclassified-as-deposit-proof-a-technical-analysis-of-the-xrpl-coreum-bridge-vulnerability-f867e8","research","Research","Incident Analysis","Olivia","When Account History Was Misclassified as Deposit Proof: A Technical Analysis of the XRPL–Coreum Bridge Vulnerability","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.","\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">1. account_tx Can Discover Transactions, but It Cannot Prove a Deposit\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">The problem is that a transaction being associated with an account does not mean that the transaction transferred assets to that account.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">The processing logic can be simplified as follows:\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-bottom: 24pt\">\u003Cimg alt=\"1111111\" src=\"\u002Fmedia\u002Fmovebit\u002F2026\u002F08\u002Fa255d020e432cb797f063461a93e72a7.jpg\" style=\"width: 264.2pt\">\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-bottom: 24pt\">The problem is that the code effectively sends any transaction not initiated by the bridge into the incoming-transaction processing path.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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:\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">require(payment.Destination == bridgeAddress)\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">2. The Relayer Validated the Transaction State but Not the Full Deposit Conditions\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">The incoming-transaction path did perform several validations. The public implementation can be simplified to something like:\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cimg alt=\"222222\" src=\"\u002Fmedia\u002Fmovebit\u002F2026\u002F08\u002F74001cf6561c302ac19ff3aef0b1000f.jpg\" style=\"width: 298.3pt\">\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">However, these conditions are still not enough to prove that the bridge received the funds.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">The validation logic must also enforce:\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cimg alt=\"3333333\" src=\"\u002Fmedia\u002Fmovebit\u002F2026\u002F08\u002Fd9fa1cace233519377d2ddbc2a13b2c6.jpg\" style=\"width: 271.2pt\">\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">The underlying transaction may therefore be completely valid on XRPL while still failing to satisfy the bridge’s own deposit requirements.\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">3. Memo Data Should Be Used for Routing, Not as Proof of Deposit\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">A safer processing order is:\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cimg alt=\"444444\" src=\"\u002Fmedia\u002Fmovebit\u002F2026\u002F08\u002F0fe82016b32180024c3cc691a55673a0.jpg\" style=\"width: 166.2pt\">\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">If the destination has not yet been verified, attacker-controlled memo data should not be allowed to influence evidence generation.\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">4. Missing Destination Data in the Evidence Limited Coreum-Side Verification\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">Another important issue is the loss of transaction context when XRPL data is converted into evidence for Coreum.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">The public XRPLToCoreumTransferEvidence structure is roughly:\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cimg alt=\"5555555\" src=\"\u002Fmedia\u002Fmovebit\u002F2026\u002F08\u002Ff71eca57bad8594ccb831c9a5eecc809.jpg\" style=\"width: 252.9pt\">\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">The XRPL Payment Destination is not included.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">The original transaction contains information such as the sender, destination, asset, amount, transaction result, and memo. The evidence retains only part of that context.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">5. Multiple Relayers Do Not Protect Against Shared Validation Bugs\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">The Coreum bridge uses an evidence-threshold mechanism. Multiple trusted relayers must submit matching evidence before the bridge proceeds with the cross-chain workflow.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">The process can look like this:\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cimg alt=\"666666\" src=\"\u002Fmedia\u002Fmovebit\u002F2026\u002F08\u002F1c1501d8a74a280b3566691893b1627e.jpg\" style=\"width: 204.1pt\">\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">6. Multisig Protects Signing Authority, but It Cannot Correct Invalid Bridge State\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">However, the vulnerability occurred earlier in the workflow, during state validation.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">The problem is that the withdrawal was created from incorrect cross-chain state.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">7. Incoming Payment Verification Should Bind All Deposit-Critical Fields\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">A safer implementation should fully validate whether an Incoming Payment satisfies the definition of a bridge deposit before generating evidence.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">For example:\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cimg alt=\"777777\" src=\"\u002Fmedia\u002Fmovebit\u002F2026\u002F08\u002F0e207cd3c56c625332bff6f14cd96b27.jpg\" style=\"width: 295pt\">\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">8. Tests Should Cover Transactions That Are Valid on XRPL but Invalid for the Bridge\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">Examples include:\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cimg alt=\"8888888\" src=\"\u002Fmedia\u002Fmovebit\u002F2026\u002F08\u002F7364f4b31a61bba11702114a4fcbdec3.jpg\" style=\"width: 300.4pt\">\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">The relayer must apply bridge-specific semantic validation on top of the source chain’s transaction rules.\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">9. Runtime Monitoring Can Provide a Second Layer of Protection\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">In addition to fixing the transaction-validation logic, a bridge should monitor reserves and cross-chain accounting for abnormal behavior.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">For example:\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cimg alt=\"999999\" src=\"\u002Fmedia\u002Fmovebit\u002F2026\u002F08\u002Ff76fd144e8f3bac3eb47ce7b74c1df33.jpg\" style=\"width: 253.2pt\">\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">Implications for Move Developers\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">Security Takeaway\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">For cross-chain systems, one of the most important security questions is simple: \u003Cstrong>what exact conditions must be satisfied before a source-chain transaction is classified as a valid bridge deposit?\u003C\u002Fstrong> Those conditions should be explicit, complete, and enforced before the evidence is submitted to the destination chain.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>\u003Cp class=\"docx-align-justify\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">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.\u003C\u002Fp>","\u002Fmedia\u002Fmovebit\u002F2026\u002F08\u002F17300163bfb6286567e0bfa39953ad61.png","2026-08-13T05:40:59Z","2026-08-13T13:40:59Z","10 min read",true,"When Account History Was Misclassified as Deposit Proof: A Technical Analysis of the XRPL–Coreum Bridge Vulnerability cover image",1792635791891]