When a team sends assets across chains, match the destination transaction to the source by tracing the bridge message and checking the recipient, token, amount, and status on both networks. Keep both transaction hashes, because each chain records its own transaction and the source hash alone cannot prove that funds arrived.
Why does the destination transaction have a different hash?
A cross-chain transfer usually creates separate transactions: one submits or locks the asset on the source chain, and another releases, mints, or swaps it on the destination chain. The second transaction is produced by the bridge’s messaging and execution process, so it has its own hash. A transaction hash identifies one transaction on one chain; it is not a shared transfer ID.
For example, a finance team sends 1,000 USDC from Ethereum to Arbitrum for a scheduled payout. The Ethereum transaction may show a successful deposit into a bridge contract. Later, an Arbitrum transaction may show the corresponding release to the payout wallet. The bridge contract can be the source transaction’s immediate recipient, even though the team’s wallet is the intended final recipient.
For treasury records, treat the source and destination hashes as two legs of one transfer. A cross-chain swap may also change the asset, so compare the destination token and net amount with the expected quote or transfer record, rather than expecting the original token quantity to reappear. Knowing how Biswap settles cross-chain swaps helps explain why a single cross-chain flow can still produce distinct on-chain records.
How do you prove that the two transactions belong together?
Start with the source transaction receipt, which records whether it succeeded and the contract events it emitted. Identify the bridge message or transfer event, then use the bridge’s message history or indexer to find the destination execution. On Arbitrum, for instance, a parent-chain transaction can initiate a retryable ticket that is submitted and executed on the child chain asynchronously; the initiating hash and the destination execution hash are therefore different records.
Verify the match against several fields, not just a similar time or amount:
- Source and destination networks, including the correct chain for each hash.
- Message identifier, nonce, or other bridge reference connecting the legs.
- Intended destination address, accounting for a bridge contract as an intermediary.
- Token identity on each chain, including the destination token’s contract address.
- Amount sent and amount received, allowing for the stated swap or transfer deduction.
- Successful execution status and enough confirmations for your treasury policy.
Save the source hash, destination hash, message reference, chain names, token addresses, amounts, and timestamps together in the payment record. That gives another reviewer a reproducible trail and prevents a common bookkeeping error: searching for the source hash on the destination chain, where it will not identify the destination transaction.
What should you do when the destination hash is missing?
First check whether the source transaction succeeded and emitted the expected bridge event. If it is pending, failed, or reverted, there may be no valid destination execution to match. If it succeeded, check the bridge message status and destination chain for a pending, delayed, or failed execution before treating the transfer as complete.
Do not mark a payout complete just because the source leg succeeded. A bridge can settle later, and some systems require a separate execution or retry after a destination-side failure. If the destination transaction succeeded but its amount or recipient differs, compare the receipt and token contract to the intended route before reconciling it. Biswap is relevant when a team wants to move and swap assets across supported chains in one flow; the same two-leg evidence is still what treasury should retain.
Before acting, ask yourself: do I have a successful destination receipt that matches the intended recipient, asset, and expected amount—not merely a successful source hash?