Across v2 Legacy Deposit Changes and Reversibility Limits

Existing fills before fee-based recovery

A normal legacy transfer reached its recipient through destination fills. When delivery remained incomplete, a depositor could authorize a higher relayer fee through the applicable speed-up mechanism. That recovery path changed the incentive to fill the outstanding portion. It did not retrieve tokens that had already reached a recipient.

Historical reconciliation therefore starts with existing delivery records. An update transaction and a destination fill describe different actions, even when both succeeded. The first authorized terms; the second recorded execution. Treating the update receipt as delivery evidence could conceal an outstanding balance. The legacy design supported partial fills, unlike the v3 fill model.

The commitment boundary at the original deposit

A confirmed legacy deposit had already committed the deposited funds to the bridge mechanism. Its speed-up interface offered no general depositor cancellation operation. Consequently, a requirement to retain unilateral control until destination delivery did not fit that design. The meaningful opportunity to stop came before submitting the deposit; afterward, changing supported execution terms and completing delivery were different from reversing the deposit.

Open full-size image

Fee authorization and actual execution

A fee update required the depositor's authorization for the identified deposit. Increasing compensation could make a remaining fill more attractive, but the signature itself transferred no destination tokens.

The signed request

The early fee-update function checked a signature tied to the depositor, origin chain, deposit identifier, and new fee. It then emitted RequestedSpeedUpDeposit. A successful request established authorization for the supplied terms. It did not establish how much remained outstanding.

Revocation depended on the implementation and the depositor's wallet. Later v2 support for EIP-1271 allowed contract wallets with suitable signature-validation rules to invalidate an update before execution. This did not cancel the deposit or reverse completed fills. Once another party possessed a usable signature, closing the interface did not erase that authorization. Publishing another request was not evidence that an earlier authorization had become unusable.

The fill that used the update

The early fillRelayWithUpdatedFee path retained the original relay identity while applying the authorized fee. Previous fills therefore continued to count toward the same transfer. An accounting system that created a fresh obligation for every fee update would misrepresent the deposit.

Recipient and message corrections depended on the implementation

Recipient corrections were not a uniform capability across every v2 deployment. Early fee-only interfaces lacked recipient and message update parameters. Later v2 code introduced those changes, and a subsequent correction addressed a defect in their execution. A historical request must therefore be interpreted against the implementation that handled it.

Open full-size image

A corrected recipient could affect a subsequent eligible fill; it could not relocate tokens from an earlier completed payment. Likewise, changing a message did not rewrite an application action that had already executed. The distinction matters when one deposit produced several destination transactions. OpenZeppelin's UMA Across V2 Diff Audit 2023 records the recipient/message defect as resolved; whether a historical transfer could use the correction depended on its deployed implementation.

Partial fills after a change

A partial fill reduced the outstanding obligation without completing the entire transfer. Fee changes made the distinction between gross fill accounting and actual recipient payments especially important.

Outstanding amount on a consistent basis

The legacy relayFills mapping tracked filled amounts before fee deductions. The corresponding outstanding amount was the original deposit amount minus its cumulative pre-fee fills. A recipient's net token receipts were a different quantity.

The totalFilledAmount event field represented a running total. Adding successive running totals would count earlier delivery repeatedly. Reconciliation should use the final cumulative amount for the matching relay or sum distinct incremental fillAmount values, without counting the same event twice.

Payments under different fees

Each fill's applied fee explained its own payment. A later fee increase did not retroactively change the tokens that an earlier fill delivered. Reconstructing every payment using only the latest fee could therefore create an apparent shortfall that never existed.

Open full-size image

Completion required the cumulative gross fill amount to reach the deposit amount, alongside the corresponding destination execution records. The recipient could receive less than the gross deposit because the mechanism deducted fees. A full gross fill and a smaller net receipt were therefore compatible.

Slow fills completed delivery rather than returning the deposit

The legacy slow-relay mechanism used protocol funds to complete an unfilled or partially filled transfer. Its intended destination remained the recipient on the destination chain. It was a settlement path, not a withdrawal of the original deposit back to the depositor.

Slow completion depended on the root-bundle process and destination execution. Elapsed time alone did not prove that either had completed. A record concerning reimbursement of a relayer also had a different purpose from a payment to the recipient. Confusing those records could make a transfer appear settled before its remaining delivery occurred.

Event names without their historical context

The names FundsDeposited and FilledRelay do not identify v2 behavior by themselves. Later protocol migrations reused those names with changed parameter types and meanings. Historical decoding needs the emitting contract, transaction block, and matching application binary interface, or ABI.

This affects more than display labels. Reading a later fill format as a partial-fill record could produce incorrect totals. Reading a legacy fee-based update as an output-amount update could misstate what the depositor authorized. Preserve the original transaction hashes and decoded fields together, so a refreshed interface does not become the only account of the transfer.

Exit after delivery reconciliation

A completed legacy payment left no unfilled portion for a speed-up to recover. Moving received tokens afterward required a separate transaction, with its own authorization and execution record. An unresolved remainder required continued investigation of the existing transfer, rather than silently treating a second deposit as a repair.

The closing record should preserve both the original obligation and what actually executed. In the early fee-update interface, that distinction was the difference between RequestedSpeedUpDeposit and FilledRelay.