Multi-Chain Portfolio Aggregation Beyond EVM

The phrase "multi-chain portfolio" hides the hard part: the chains do not agree on what a balance even is. EVM mappings, Solana token accounts, Move objects, validity-rollup timing — four models, one required view. This guide is why aggregation is a reconciliation problem, not an integration count.

TL;DR

• A real portfolio spans four incompatible state models: EVM mappings, Solana token accounts, Move resources/Objects & Sui objects, validity-rollup timing.
• Aggregation is not "more RPCs" — it is reconciling four models into one non-double-counted view.
• Three recurring failures: missed positions, double-counting (bridged in-transit), broken cost basis (cross-model self-transfer as disposal).
• Cross-chain self-transfers are internal transfers — basis carries, not a sale.
• One jurisdiction cost-basis method applied to the unified, de-duplicated history — not re-chosen per chain.
• Correctness = completeness + 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 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, a Sui Coin object never enters the view. 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 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.

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 must carry across the move; 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.

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.

Practical guidance

1. Ingest each model natively — EVM mappings, Solana token-accounts+rent, Move resources/Objects, Sui objects.
2. Handle validity-finality timing — model in-transit/bridged states; don't double-count.
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.

How vendor tools handle non-EVM aggregation

Koinly and CoinTracker aggregate across EVM and non-EVM chains to varying depth. Confirm the tool ingests each state model natively (not EVM-by-analogy), guarantees cross-model completeness, pairs cross-chain self-transfers as internal, and applies one jurisdiction method to the unified history — endpoint count is not correctness.

How Wag3s helps

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

• Distinct state models: EVM balance mappings; Solana SPL token accounts + rent; Aptos Move resources/Objects; Sui Coin-object split/merge; validity-rollup L2-usable-vs-L1-final timing
• Reconciliation failures from model heterogeneity: missed positions, double-counting (bridged in-transit), cross-model self-transfer mis-booked as disposal
• One jurisdiction cost-basis method applied to the unified, de-duplicated, classified history (not re-chosen per chain)