One asset, several ledger entries
Hold the same token on three venues and you have three balances and one economic position. Treating them as three positions is the most common structural error.
It shows up as a cost basis problem, because each venue has its own idea of what you paid. But the underlying issue is simpler: an asset is the same asset regardless of where it sits, and a consolidated view has to treat it that way from the start.
The categories that are not simple holdings
| Balance type | What it actually is | Why it breaks totals |
|---|---|---|
| Available balance | Funds you can trade or move now | Correct, but usually only part of the picture |
| Locked or in order | Committed to open orders | Often shown separately or omitted entirely |
| Pending withdrawal | Left the venue, not yet arrived | Double counted, or missing on both sides for a period |
| Staked or locked | Still yours, earning or not | Treated as spendable, or counted twice |
| Lending position | Supplied to a protocol, earning interest | Not a spot holding; valued differently by different views |
| Liquid staking receipt | A claim on a pool, not the token itself | Shares a name with the underlying and gets double counted |
| Wrapped or bridged form | A different representation of the same claim | Appears as a separate asset with its own price |
Internal transfers
Moving assets between accounts you control changes nothing economically, and every good consolidation treats it as a no-op.
Detecting them takes three signals together: the quantities match within rounding, the timestamps are close, and no third party appears in the path. Any one of them alone is not enough — two unrelated transfers of the same amount in the same minute are rare but not impossible.
A transfer in flight creates the most visible discrepancy in practice. For a period, one venue has debited you and the other has not credited you. A total computed across both during that window is wrong by exactly that amount, and it corrects itself when the transfer lands.
Wallets are the harder half
Exchange balances arrive through an interface designed to list them. Self-custody balances do not: a wallet address produces transactions, not a total, and a tracker has to reconstruct the position from a chain.
That reconstruction is more fragile than a balance query, and it carries assumptions the exchange side never has to make — which contracts count as holdings, which are spam, whether a token is the one you think it is. A wallet figure with no methodology stated is a set of assumptions, not a measurement.
What a consolidated view should expose
- Coverage. Which accounts are included and which are not. A total that silently omits an account is more dangerous than no total at all.
- Last successful sync per account. A venue you stopped connecting to looks identical to a venue that has not changed.
- What is excluded. Lending positions, receipt tokens and anything the view decided not to count, listed explicitly.
- Unmatched transfers. Movements that did not pair up, so they can be investigated rather than absorbed.
A reconciliation routine
- List the accounts, not just the totalEvery account you hold anything in, including the ones you are not sure still work. The second list is usually where the gap is.
- Check each balance against its own venueIndividually. A total that matches nothing individually is not a total worth trusting.
- Match transfers in both directionsPair each withdrawal with a deposit. Anything left unmatched is either a real movement or a problem.
- Look for duplicate representationsReceipt tokens, wrapped forms and bridged versions of something you already hold.