Reconciling omnichain swap proceeds means matching the tokens a treasury sent and received with the fees, transaction records, and accounting entries for the full cross-chain activity. The key condition is that the swap may finish in a separate transaction, on a different blockchain, after the source-chain transfer has already succeeded.
What counts as proceeds from a cross-chain swap?
Proceeds are the assets the treasury actually receives, measured alongside what it gave up and what it paid to complete the route. A route can include a source token transfer, a bridge or messaging step, a swap, and destination-chain delivery; the treasury may see more than one transaction even though it intended to make one exchange.
Keep the economic activity distinct from the on-chain transactions. The economic activity is the intended exchange, such as spending token A for token B. Transactions are the individual records on each chain that show deposits, transfers, swaps, fees, and delivery. A router may also move intermediate tokens that the treasury never controls directly.
For the books, record the source asset and amount, the destination asset and amount, the transaction costs, the timestamps, and the dollar value required by your accounting policy. Whether the exchange creates a realized gain or loss, and how to treat a bridge transfer, depends on the entity’s accounting and tax rules. Don’t assume every intermediate movement is a separate swap—or that it can be ignored.
Which records should you match first?
Start with the source transaction hash, the unique identifier for the transaction on its blockchain. Confirm that it belongs to the treasury wallet and identify the actual token amount transferred, including any token decimal places; a displayed amount may be rounded.
Next, find the route’s cross-chain message identifier, if one is available, then use it to match the source activity to destination delivery. Chainlink CCIP documentation describes a useful general pattern: a message is sent on the source chain, then verified and executed on the destination chain. Its event reference lists separate source-send and destination-execution records. Other routes use different contracts and names, so match on the route’s own identifier when available rather than assuming every provider emits the same events.
On the destination chain, verify the receiving wallet, token contract, amount, and transaction status. A wallet’s token balance change is a useful cross-check, but it is not a substitute for transaction records: other deposits or withdrawals can happen between the before-and-after balance snapshots.
Save both transaction hashes, the message identifier, wallet addresses, token contract addresses, raw token quantities, timestamps, and explorer or API records. The IRS says U.S. taxpayers should keep records sufficient to support positions on tax returns, including digital-asset receipts, exchanges, transfers, and fair market value. Treasury books need a consistent evidence trail too, even when tax reporting is handled separately.
How do you value the swap and its costs?
Use the valuation time and pricing source required by your accounting policy, and apply them consistently. A practical record has one row for the source outflow, one for the destination inflow, and separate rows for fees when they are visible as distinct payments. Preserve each asset’s quantity and valuation; a dollar total alone cannot explain what changed.
For example, suppose the treasury sends 100 units of token A, receives 97 units of token B, and pays 0.002 units of the source chain’s native token as gas. These are illustrative figures. Record the 100 A outflow, the 97 B inflow, and the gas payment separately, then value each at the policy’s chosen time. If the route deducts a fee from the amount delivered, record the actual 97 B received and capture the fee evidence; don’t book an estimated 100 B as proceeds.
Separate network gas, paid to process a transaction, from swap or routing charges, which may be deducted from the traded amount or charged separately. Check token transfers and transaction receipts for what was actually paid. A quote or expected output helps explain a difference, but the settled amounts belong in the reconciliation.
What if the destination leg is delayed or different?
Keep the source transfer open as an in-flight item until delivery is confirmed or the route reaches a documented failure or refund outcome. Cross-chain activity is asynchronous: source-chain confirmation does not, by itself, prove that the destination transaction completed. Record the source hash and message identifier so the pending item can be checked again without treating it as completed proceeds.
If the delivered quantity differs from the quote, reconcile to the settled amount and document the cause using the route records: price movement, a fee deduction, or a failed attempt followed by a refund can produce different evidence. If the destination transaction failed, check whether assets remain recoverable or were returned before closing the item. Escalate a mismatch that the available records cannot explain; don’t force the books to balance with an unsupported fee estimate.
What should the close file contain?
Close with a compact evidence packet: the intended route, source and destination hashes, message identifier, token quantities and contract addresses, fee evidence, valuation method and time, and the resulting journal entries. Mark whether the route is complete, pending, failed, or refunded, and retain the reason for any adjustment. Have a second reviewer check that the evidence ties to the wallet and the entries reflect settled amounts.
Before posting, check that the source outflow, destination inflow, and fees reconcile; that every pending route has an owner; and that the valuation follows policy. If you need to make the cross-chain move and token swap through one interface, omnichain is one way to do it. Keep the same transaction-level evidence in the treasury file after the route completes.