Across v2
Across v2 Legacy Inputs and Delivery Records
· updated
Across v2 transfer tracing starts with the original deposit receipt and ends with the recipient's matching destination payments. For an old transfer, identify the historical contract, decode its deposit inputs, and reconcile the fills against the expected amount after fees. Start with a read-only inspection before authorizing another transaction. A missing receipt, an incomplete event search, or the wrong token view can leave delivery unresolved without establishing that the bridge needs another deposit.
Locate the deposit before another transaction
The usual tracing path begins with a successful origin transaction whose receipt contains the bridge deposit event. When that receipt is missing, locate the original transaction in account history. Submitting another deposit would create a separate transfer request.
Keep wallet prompts closed while collecting the transaction hash and origin network. Reading public transaction records does not require a spending approval or a signature.
An old browser session or saved quotation can help locate a transfer, but neither establishes execution. Treat the receipt as the starting record, and preserve any difference between the intended inputs and the recorded deposit.
Receipt status and historical interface
The transaction receipt and the contract implementation at its block determine how to interpret an old deposit. A familiar function name alone does not establish the version.
Transaction outcome
A reverted transaction did not leave a successful bridge deposit from that execution. A successful transaction still needs inspection: its logs must contain the relevant deposit from the expected contract. Account activity may include approvals, transfers, and unrelated contract calls alongside the attempted bridge operation.
Event layout
Legacy v2 used
FundsDeposited
and
FilledRelay, but later protocol changes reused those names with different fields. Decode the event log using the application binary interface, or ABI, appropriate to the historical implementation. Do not apply a modern event layout simply because its name matches.
If decoding produces missing or implausible fields, retain the raw log. An interpretation failure does not prove that the underlying transaction failed.
Which record identifies the old transfer?
The deposit receipt identifies the transfer through its origin context, emitting contract, deposit identifier, and recorded transfer inputs. Preserve that context when searching destination activity.
Record the depositor and recipient separately. They serve different functions, and the account that submitted the deposit need not be the account receiving destination funds. Keep the origin token, amount, destination chain, fee fields, and quote timestamp beside those addresses. Where the historical implementation supported deposit updates, also check which authorized recipient, message, and fee changes the fill actually applied.
A bare deposit identifier is insufficient for an archival search across multiple networks or deployments. It belongs to a particular origin context. When several records appear similar, compare the full transfer details before grouping their fills or treating a payment as delivery.
Destination asset and recipient details
The expected destination asset followed the historical token mapping associated with the deposit, rather than a ticker-only match. A current asset list cannot establish that old relationship. Preserve the destination contract identity alongside the recipient address.
Token identity
A token symbol is a display label, not a unique contract identifier. Matching symbols across networks do not establish equivalent assets. Inspect the token contract that the destination execution actually used, then compare it with the mapping applicable to the original transfer.
Native asset delivery
In the early v2 implementation, the destination SpokePool unwrapped its designated wrapped native token for an externally owned recipient. It sent the wrapped token to a contract recipient instead. That distinction changes which balance or execution trace reveals delivery. Apply it only when the historical implementation contains that behavior.
Legacy fields that belong together
The original deposit amount and fee inputs formed part of the legacy request that relayers attempted to fill. Preserve their original values when reconciling later execution.
V2 represented fees differently from its successor. Its deposit interface supplied a relayer fee percentage, while the realized liquidity provider fee participated in fill accounting. Newer output-amount fields therefore cannot simply replace missing legacy inputs.
Distinguish an absent field from a recorded zero. The former may indicate the wrong decoder or incomplete data; the latter is an actual value. Keep raw integers as well as formatted displays so that conversion does not erase a difference.
Expected receipt after fees
The amount recorded as filled and the amount delivered to the recipient answered different accounting questions in v2. The early v2 contract tracked cumulative fills on a basis before fees. Recipient payments reflected the fees that the execution applied.
Keep a comparison between gross fill progress and the deposit amount separate from a comparison between net payments and expected receipts. Subtracting a net payment directly from a gross deposit mixes those bases and can exaggerate the apparent outstanding amount.
For an exact reconciliation, retain the applied fee values and the implementation's integer arithmetic. Display rounding can hide small differences. If different executions applied different fees, reconcile their payments individually before combining them; one fee assumption cannot explain every payment automatically.
Partial delivery and search coverage
A destination payment could represent only part of a legacy transfer, so one matching transaction did not establish full delivery. V2 supported partial fills. Include slow-relay payments funded by the protocol when searching for the remainder. The early v2 implementation recorded these through ExecutedSlowRelayRoot, so searching only FilledRelay can miss delivery. Use the slow-fill event layout applicable to the historical implementation.
Search beyond the first matching result and retain each distinct event's transaction and log position. Overlapping exports can repeat the same event. Counting those duplicates as separate payments inflates delivery without adding any actual funds.
An empty search result also needs context. The query may target the wrong deployment, omit an older block range, or use an incompatible event signature. Describe such a result as unresolved until the search coverage supports a stronger conclusion. A missing index entry does not itself establish an unpaid deposit.
A missing recipient field in a saved export
Consider a hypothetical archival case: a saved export contains the origin transaction hash and network but omits the recipient. The export also lists a destination transaction whose relationship to the deposit remains uncertain.
To check delivery without signing another transaction, the account holder retrieves and decodes the original receipt. Suppose that inspection reveals a successful legacy deposit and its recipient, giving the reader the missing address needed for the destination comparison.
The destination receipt then shows a fill matching the deposit's historical inputs. In this hypothetical case, that single fill covers the full gross deposit amount, and the payment to the recorded recipient matches the expected net receipt under that execution's fees.
The account holder has matched the deposit to its destination payment without another authorization. If the recipient remained unavailable, or the payment did not match, the reader would stop with that discrepancy unresolved. Repeating the deposit would not repair the missing historical evidence.
Delivered funds and relayer reimbursement
A relayer's payment to the recipient preceded its reimbursement through the protocol's settlement process. Relayers supplied destination funds, and subsequent bundles handled repayment. This separation matters when a history screen mixes user delivery with settlement activity.
Do not count a relayer refund as another payment to the recipient. Likewise, an unresolved reimbursement record does not negate a recipient payment that the destination execution already establishes.
Why does the wallet balance differ from the recorded payment?
A wallet's present balance includes activity beyond the bridge payment, so it may differ from the amount originally delivered. Later spending, additional receipts, or a different selected network can explain that mismatch.
Use the destination transaction's execution and asset movements to establish the historical payment. A balance snapshot answers how much the account held at a particular point, not which transaction supplied it. Even a before-and-after comparison needs care when other movements occurred within the interval.
A contract recipient can also move funds during its own execution. Delivery to that contract and a later balance in a user wallet are separate observations. Trace the relevant movements before treating a missing wallet display as a failed bridge transfer.
Stop at reconciliation or a specific unresolved mismatch
The tracing task ends when the identified deposit, its destination fills, and the recipient payments reconcile on consistent terms. Preserve the transaction hashes, decoded records, and any calculation needed to explain that conclusion.
If they do not reconcile, name the remaining problem precisely: an unavailable receipt, an uncertain historical mapping, incomplete fill coverage, or a payment discrepancy. That narrower description makes further investigation possible without treating every unresolved case as a request for another transaction.
Historical reconciliation does not establish that the same legacy route accepts new deposits today. A new transfer requires its own applicable interface, asset support, and execution terms. An old successful receipt proves that earlier execution, not present availability.
Questions and answers
Does inspecting an old across v2 deposit require the original wallet keys?
Public transaction inspection does not require the original wallet keys. A transaction hash and the correct network allow the receipt and logs to be retrieved without signing. Account addresses help locate activity when the hash is missing. Keep that read-only investigation separate from any proposed authorization: a signature request changes the task and is unnecessary merely to examine an existing deposit or destination payment.
How should I handle conflicting exports of the same legacy fill?
Compare the exports with the underlying transaction receipt before choosing either interpretation. Preserve the raw event data, emitting address, transaction hash, and log position. Different decoders can assign different meanings to identical bytes, especially when they use incompatible interfaces. Two exports of one log still describe one event. If the raw records themselves disagree, leave the amount unresolved until the discrepancy is explained.
Can the deposit transaction hash also identify the destination payment?
The origin deposit hash identifies a transaction on the origin network, while destination delivery has its own transaction record. Searching only for the origin hash on the destination network will not establish payment. Use the decoded deposit details to find the related destination execution, then preserve both hashes. Their relationship comes from the matching transfer data, not from identical transaction identifiers.
When is an explorer's rounded amount insufficient for reconciliation?
A rounded display is insufficient when its precision hides the difference that you are investigating. Compare the raw amount with the token's decimal precision before deciding that funds are missing. Preserve fee calculations in their original integer units until the final display conversion. An unexplained difference should remain a discrepancy; calling it rounding requires arithmetic that actually accounts for it.
Which details help someone investigate an unresolved legacy transfer?
Provide the origin network, deposit transaction hash, emitting contract, recipient, and any candidate destination transaction hashes. Include the specific mismatch and the block range already searched. Raw logs help when decoding is uncertain, while payment details help when the amount is disputed. Private keys and seed phrases have no role in that investigation. Public addresses can reveal associated activity, so share only the transaction context needed.