Portfolio tracking in crypto requires assembling transaction history, pricing data, and balances from multiple onchain and offchain sources into a unified view. The core challenge is not calculation but source reconciliation: ensuring complete transaction coverage, handling address changes, and dealing with missing or delayed API data. This article walks through the technical decisions that determine whether your tracking system stays accurate as your holdings scale.
Source Architecture: Onchain vs Exchange vs Manual
Effective tracking starts with identifying where your assets move and how you extract that data.
Onchain wallets expose transaction logs via block explorers or node RPC endpoints. You can query by address, parse incoming and outgoing transfers, and derive balances deterministically. This works well for EVM chains with mature indexing services. Non-EVM chains (Solana, Cosmos ecosystem, UTXO chains) require different parsers and may not surface all token metadata cleanly.
Centralized exchanges offer API endpoints that return trade history, deposits, withdrawals, and current balances. Coverage varies: some exchanges paginate poorly or impose strict rate limits. CSV exports are common but often omit fee details or use inconsistent timestamp formats. If you hold assets on multiple exchanges, you need separate ingestion logic for each.
Manual entries fill gaps where APIs do not exist or are unreliable. Examples include OTC trades, airdrops claimed before indexing services captured them, or assets held on custodians without public APIs. Manual records introduce human error but are sometimes the only option.
Transaction Completeness and Double Counting
Missing transactions corrupt cost basis and PnL. Common gaps include:
Internal transfers between your own addresses. If you track each address separately without linking them, a transfer looks like a disposal and an acquisition instead of a neutral move. Solution: maintain a list of owned addresses and tag internal transfers explicitly.
Failed transactions that consumed gas but did not execute the intended swap or transfer. Onchain parsers must check transaction status and handle gas-only costs separately.
Wrapped and bridged assets. Depositing ETH into WETH or bridging USDC to Polygon creates new token entries. Your system must recognize when a wrap or bridge is a transformation rather than a taxable event, depending on your jurisdiction.
Staking rewards and LP positions. Staking often auto-compounds, so your balance increases without discrete deposit transactions. You need to poll balances periodically or parse staking contract events. LP positions require tracking both the LP token itself and the underlying reserve balances to calculate impermanent loss.
Pricing Data and Historical Reconstruction
Accurate PnL requires historical prices at the exact timestamp of each transaction. Real-world complications:
Price source consistency. Using CoinGecko for one asset and Binance spot for another introduces basis risk. Price feeds disagree, especially for low liquidity tokens. Pick one primary source and document exceptions.
Timestamp precision. Onchain transactions have block timestamps, but centralized exchange trades may report execution time, settlement time, or API polling time. Misaligned timestamps create small but cumulative errors.
Delisted or extinct tokens. Projects that rugged or lost all liquidity may have no reliable price history. Some tracking tools substitute zero, others use last known price. Either choice distorts aggregate metrics. Flag these manually and decide whether to exclude them from performance calculations.
Oracle vs spot price. If you are tracking DeFi positions that liquidate based on oracle prices (Chainlink, Pyth), your realized loss may not match the spot price at liquidation time. Record both for forensic analysis.
Worked Example: Tracking a Multichain Wallet
You hold assets on Ethereum mainnet, Arbitrum, and Binance. On Ethereum, you have 2 ETH in address A and 500 USDC in address B. On Arbitrum, you have 1 ETH in address C. On Binance, you hold 1000 USDT.
- Query Ethereum: parse logs for addresses A and B. You find a transfer of 0.5 ETH from A to C three months ago, before you started tracking Arbitrum.
- Query Arbitrum: address C shows 1.5 ETH total. The extra 0.5 matches the Ethereum outbound transfer. Tag it as internal to avoid double counting the initial 0.5 ETH acquisition cost.
- Query Binance API: retrieve deposit history. You find a 1000 USDT deposit six months ago from an external wallet (address D, which you have since abandoned). Because address D is not in your tracked set, the system does not auto-link it.
- Manually add address D to your ownership list and reparse. The deposit now shows as an internal transfer rather than new funds.
Your portfolio now reflects 3.5 ETH across two chains, 500 USDC, and 1000 USDT, with correct cost basis for each lot.
Common Mistakes and Misconfigurations
Tracking only current balances without transaction history. Balance snapshots show what you own now but cannot reconstruct cost basis or PnL. Always ingest full transaction logs.
Using a single aggregator without verifying its source coverage. Some portfolio tools index only top 50 tokens or skip certain chains. Cross-check that your long tail holdings appear.
Ignoring gas costs. Gas is a real expense that affects net returns. Many tracking systems omit it or aggregate it separately, making performance comparisons misleading.
Not linking exchange deposit addresses to known wallets. When you deposit from wallet X to exchange Y, the exchange assigns you a unique deposit address. If you do not tag that address, the system treats the deposit as a sale.
Treating LP tokens as static holdings. The value of an LP token changes as the underlying pool ratio shifts. Fetch reserve data or use protocol-specific subgraphs to calculate current backing.
Failing to handle token migrations. Protocols occasionally reissue tokens (e.g., old token to new contract). If you do not map the migration, your holdings appear to vanish.
What to Verify Before You Rely on This
- Confirm that your tracking tool or script covers all chains where you hold assets. Check the list of supported networks explicitly.
- Verify that your exchange API keys have read permissions for trade history, deposits, and withdrawals, not just balances.
- Test historical price availability for low-cap tokens. Query your price feed for a token acquired more than a year ago.
- Check whether your tool treats staking rewards as income at receipt or at withdrawal. This affects tax reporting.
- Review how your system handles bridged assets. Does it recognize canonical bridges (Arbitrum, Polygon PoS) automatically, or do you need manual rules?
- Confirm gas cost inclusion. Run a test report and verify that gas fees appear as line items or adjustments to cost basis.
- Document your internal address list. Any address you control must be tagged to prevent false disposal events.
- Test your tool’s handling of failed transactions. Execute a failed swap on testnet and verify that only gas is recorded.
- Verify that your price feed returns the correct quote currency. Some APIs default to USD, others to USDT or BTC.
- Check update frequency for live balance tracking. If you refresh once per day, intraday trades will not appear until the next cycle.
Next Steps
- Set up a spreadsheet or database schema linking your addresses, exchange accounts, and manual entry records. This is your source of truth.
- Schedule a monthly reconciliation: compare your tracking system’s reported balances against live wallet and exchange balances. Investigate discrepancies immediately.
- Build alerts for missing transaction data. If your script pulls zero transactions from an address that you know had activity, flag it for manual review.
Category: Crypto Portfolio Tracking
