Multi-Chain Portfolio Aggregation Beyond EVM

This is the hub for the non-EVM chains, because the phrase "multi-chain portfolio" hides the hard part: the chains do not agree on what a balance even is. An EVM address has a per-contract balance mapping; Solana scatters holdings across token accounts with rent; Aptos stores account-owned Move resources grouped by Objects; Sui holds Coin objects that split and merge; and validity rollups like zkSync Era and Starknet add an L2-usable-versus-L1-final timing layer. The distinct problem this article addresses is reconciling those incompatible models into one correct, non-double-counted view: not "add more RPCs," but normalising state shapes so a single cost-basis method computes the right gain. For the single-owner, same-EVM case underneath all of this, see the multi-wallet aggregation pillar.

What this hub covers

• A real portfolio spans incompatible state models: EVM mappings, Solana token accounts, Move resources and Objects and Sui objects, and validity-rollup timing.
• Aggregation is not "more RPCs"; it is reconciling those models into one non-double-counted view.
• Three recurring failures: missed positions, double-counting of bridged-in-transit assets, and broken cost basis when a cross-model self-transfer is booked as a disposal.
• Cross-chain self-transfers are internal transfers, so basis carries rather than a sale being recorded.
• One jurisdiction cost-basis method is applied to the unified, de-duplicated history, not re-chosen per chain.
• Correctness is completeness plus classification, not endpoint count.

Four models, no shared definition

There is no shared definition of a balance across these. So an aggregator that assumes an address simply has balances (the EVM model) is structurally wrong for four of the five. Aggregation must ingest each model natively, then normalise: the reconciliation discipline generalised across state models.

The three failures of naive aggregation

1. Missed positions: an unmapped Solana token account, an Aptos Object, or a Sui Coin object never enters the view. This is the completeness problem, multiplied by model variety.
2. Double-counting: a bridged asset shown on both L2 and L1 during a withdrawal delay, or counted on both the source and destination of a cross-chain transfer.
3. Broken cost basis: a cross-model or cross-chain self-transfer booked as a disposal, manufacturing a phantom gain and resetting basis (see internal transfer vs disposal).

Each is a completeness or classification error that model heterogeneity amplifies, not a new category of error.

Step-by-step: building a multi-model aggregated view

1. Build the complete inventory first. List every address/account/object across EVM chains, Solana, Aptos, Sui, and L2s. Include exchange accounts. A missing address is a missing model — the most expensive error.
2. Ingest each model natively. For EVM, query balanceOf contracts. For Solana, enumerate SPL token accounts and rent states. For Aptos, read account resources and enumerate owned Objects. For Sui, enumerate Coin objects and aggregate by type. For validity rollups, layer in the finality-stage status.
3. Normalise to a common schema. Map each native representation to a common record: {chain, address, asset_type, quantity, acquisition_date, cost_basis_unit, finality_state}. The normalisation layer is where model differences are resolved.
4. Pair cross-chain and cross-model self-transfers. For each outflow from one chain, search for a matching inflow on another chain within a time window that matches asset type, quantity, and ownership. Mark matched pairs as internal transfers; unmatched outflows/inflows are flagged for manual review.
5. Handle in-transit bridge states. A withdrawal initiated on a validity rollup but not yet executed on L1 is neither fully on L2 nor on L1. Tag it as withdrawal-in-progress and exclude it from both chain's reported balances until execution is confirmed.
6. De-duplicate. Bridged assets tracked on both source and destination before pairing are the most common source of double-counting. Confirm each asset appears exactly once across all models.
7. Apply one jurisdiction cost-basis method to the unified, de-duplicated history — not per chain.

Cross-chain self-transfers carry basis

Moving your own value between your own addresses or across chains is not a sale, whatever the state models involved. Cost basis and acquisition date carry across the move, and both legs must be paired into one internal movement (see cross-chain reconciliation). Treating the outflow on one model and the inflow on another as unrelated is the single most expensive aggregation bug.

Protocol-specific edge cases across models

Different chains introduce unique edge cases that a multi-model aggregator must handle:

• Solana rent reclaim: closing an SPL token account returns the rent lamport deposit. The tracker must record this as an SOL inflow (cost basis: zero, since the rent was previously expensed) and close the token account position.
• Aptos fungible asset standard migration: tokens created under the old Coin standard and the new FungibleAsset standard can coexist. The aggregator must unify them to avoid counting the same economic asset twice.
• Sui coin merges triggered by the protocol: some DeFi protocols automatically merge a user's Coin objects as part of a transaction. The tracker must recognise protocol-triggered merges as non-disposal administrative operations.
• Validity rollup L1 data blobs: some rollups now use EIP-4844 blobs for data availability. The tracker does not need to track blob contents, but must not misclassify the blob-submission transaction as a user transfer.

One method, applied to the unified history

Aggregation does not re-choose the cost-basis method per chain. The jurisdiction-mandated method is applied once, to the complete, de-duplicated, correctly classified transaction set across all models. The aggregation layer's job is to produce that clean unified history; the tax method then computes the right gain from it. The chains differ; the method does not.

Common errors and how to fix them

Error 1 — One EVM-style decoder applied to all chains. An aggregator that queries eth_getBalance + balanceOf for Solana addresses returns zero for every SPL token. Fix: detect the chain model from the address format and network ID, then route to the correct ingestion path.

Error 2 — Missing Solana zero-balance token accounts. Solana token accounts with a zero balance are still open accounts that once held tokens. Ignoring them breaks historical cost basis because acquisitions recorded in those accounts are no longer visible. Fix: pull the full token account history, including closed accounts, via the Solana transaction history API.

Error 3 — Treating every USDC bridging as a new acquisition. USDC moves across chains via Circle's CCTP (burn on source, mint on destination). A naive aggregator sees a USDC outflow on Ethereum and a USDC inflow on Base as unrelated events, manufacturing a disposal and a new acquisition. Fix: detect CCTP burn/mint patterns and pair them as internal transfers.

Error 4 — Applying the wrong cost-basis method per chain. An aggregator that uses FIFO for EVM and average cost for Solana produces an inconsistent blended result that matches no jurisdiction's mandated method. Fix: enforce one method across the unified history; the method is a jurisdiction setting, not a per-chain setting.

Practical guidance

1. Ingest each model natively: EVM mappings, Solana token-accounts plus rent, Move resources and Objects, Sui objects.
2. Handle validity-finality timing by modelling in-transit and bridged states without double-counting.
3. Build a complete inventory across wallets, token accounts, Objects, and chains.
4. Pair cross-model/cross-chain self-transfers as internal movements that carry basis.
5. Apply one jurisdiction cost-basis method to the unified history, not per chain.
6. Keep an audit trail back to each chain for every aggregated position.

Choosing a tool for multi-model aggregation

Koinly and CoinTracker aggregate across EVM and non-EVM chains to varying depth, but the checks that matter for a heterogeneous portfolio are:

• it routes each address to the correct ingestion path by chain model, rather than applying one EVM-style decoder that returns zero for Solana, Aptos or Sui;
• it guarantees cross-model completeness, including Solana zero-balance token accounts whose history holds acquisitions;
• it detects bridge patterns (for example Circle CCTP burn-and-mint, or a validity-rollup withdrawal in transit) and pairs them as internal transfers rather than as a disposal plus a new acquisition;
• it enforces one jurisdiction method across the unified history, not a different method per chain.

Endpoint count is not correctness; completeness and classification are.

How Wag3s handles multi-model aggregation

Wag3s Folio ingests EVM, Solana, Aptos, Sui and validity-rollup state natively, builds one complete inventory across all models, pairs cross-chain self-transfers as internal movements that carry basis, and applies your single jurisdiction cost-basis method to the unified, de-duplicated history with an audit trail to each chain. See the Folio product page.

Further reading

• Solana Portfolio Tracking
• Aptos Portfolio Tracking
• Sui Portfolio Tracking
• zkSync Era Portfolio Tracking
• StarkNet Portfolio Tracking
• Multi-Chain Reconciliation

Sources

• Solana — SPL Token Basics: the per-mint token-account model and rent-exempt SOL deposit.
• Aptos — Move resources and Objects: account-owned resources grouped by addressable Objects.
• Sui — Object Model: assets as unique objects, the basis of the split-and-merge Coin behaviour.
• ZKsync — Finality: the L2-usable-versus-L1-final timing that bridged-asset double-counting hinges on.
• IRS — Digital assets for the single US cost-basis method applied to the unified, de-duplicated history.