How to Record Omnichain Swaps for Portfolio Attribution

A cross-chain swap can create a source-chain debit, a bridge message and a destination-chain trade, so portfolio attribution must join those records before calculating the result. Each step can have its own transaction hash, fee and timestamp. Treating them as unrelated trades can make one wallet action look like several independent investment decisions.

For a practical walkthrough of the wallet flow, see how to swap tokens through omnichain. For bookkeeping, retain the source and destination records even when an interface presents the action as one swap.

Why can one swap produce several records?

A cross-chain swap usually has distinct on-chain events because the source and destination networks maintain separate transaction histories. A wallet may first approve a token, then submit a transfer or swap, followed by a message delivery and a destination-side exchange. Some routes bundle steps, but the records still belong to different chains or contracts.

LayerZero’s OFT technical reference describes a transfer flow in which tokens are debited on the source chain, a message is routed, and tokens are credited on the destination chain. The source transaction alone therefore does not establish that the destination credit or swap completed. Link records by message or transfer identifier when available; otherwise match the wallet, assets, amounts and route, and mark the association as inferred.

What should a portfolio record contain?

Store each event separately, then group related events under one portfolio action. Keep enough detail to replay the path from the token leaving the source wallet to the asset received on the destination chain.

• Identity: wallet, chain, transaction hash, block time and event type.
• Movement: token contract, quantity debited or credited, and the counterparty or protocol where known.
• Route: source and destination chains, message or bridge reference, and linked transaction hashes.
• Valuation: fees and the valuation method and timestamp used for each asset movement.

Keep approvals distinct from token movements: an approval grants permission and does not by itself mean the approved amount was spent. Record fees in the asset actually paid, and preserve the original token quantities alongside any converted portfolio values.

How should the records affect attribution?

Attribute the portfolio decision once, while preserving every transaction that executed it. The source debit and destination credit describe movement through the route; they are not automatically separate buys and sells. The destination swap is the point where the asset exposure changes, while network and routing fees remain costs of execution.

For most readers, a linked event group with chain-level evidence is the clearest record: it avoids double-counting transfers and keeps fees visible. If a destination leg is pending, failed or unmatched, leave the group unresolved rather than assigning a completed outcome. The next step is to reconcile destination delivery and any swap against the source record; whether every route exposes a common identifier remains dependent on the protocols and tools involved.