Estimate Wallet Changes Across Two Chains

Estimate wallet changes across two chains by rebuilding each wallet’s balance on each chain, then tracing the transfers that connect those ledgers. A wallet balance is chain-specific: an address can hold assets on both networks, but a change on one does not automatically explain a change on the other.

Start by choosing the two chains, the asset or assets, and a fixed time window. Record the opening and closing balances for each address on each chain. Then inspect the transactions within that window to distinguish deposits, withdrawals, swaps, fees and bridge activity. A cross-chain swap can involve several steps; Biswap’s cross-chain swap route is a fuller example of how those steps can fit together.

What counts as a wallet across two chains?

A wallet is better treated as a set of chain-specific addresses than as one universal account. Some compatible chains use the same address format, so one key may control the same address on both. That does not prove the addresses belong to the same person: an address can be unused on one chain, controlled by a contract, or shared through a service.

For a practical estimate, define an address-matching rule before counting. If your question is about addresses, compare exact addresses across the two chains and report them as a possible match. If your question is about people or organizations, address data alone cannot establish identity. Label the result as an address-level estimate and keep unmatched addresses separate.

How do you calculate the balance change?

Calculate the change separately on each chain: closing balance minus opening balance for each asset, then add the per-asset changes only if they share a meaningful unit. A token amount and a native coin amount cannot be added directly. For a value estimate, convert each asset at a consistent valuation time and state which price source or method you used.

Reconstruct balances from the chain’s transaction data. Native asset transfers are usually recorded in transactions or execution traces; token movements are commonly exposed as event logs. Include fees as outflows where relevant. Avoid counting a transaction’s headline value as the user’s net change: a swap can send one asset out and return another, while a contract call can trigger several transfers.

Think of the two chains like separate bank ledgers: reconcile each one first, then match entries that appear to connect them. A useful working table has one row per address and asset, with these fields:

• Opening and closing balance on each chain.
• Incoming and outgoing transfers during the window.
• Fees and swaps recorded separately from ordinary transfers.
• Possible bridge or cross-chain match, with the evidence used.

How should you treat bridge transfers?

Treat a bridge transfer as related events on two ledgers, not as one transaction moving an asset directly between chains. Depending on the bridge design, the source chain may lock or burn an asset, and the destination chain may release or mint a corresponding asset. The destination event can happen later, and fees or route changes can make the received amount differ from the amount sent.

Match events using available identifiers such as a bridge message ID, transaction references, token and amount, and timing. Treat amount and timing alone as weaker evidence because unrelated transfers can look similar. If you cannot establish a match, leave the entries as separate flows rather than assuming a bridge completed.

What makes the estimate reliable?

Use a consistent block or timestamp boundary on both chains, and record the data source and token identifiers. Token symbols can repeat across networks, so compare contract addresses or the chain’s native asset identifier, not just names. Decide whether the estimate covers only externally visible transfers or also contract-level movements and document that scope.

The result is a ledger-based estimate of address and asset changes, not a count of people or proof that a particular user moved funds. What changes is each chain’s recorded balance; next, check whether the matching transfers are complete, correctly attributed and inside the same time window.