StarkNet Portfolio Tracking: A Non-EVM, Cairo Chain

Most "multi-chain" trackers are really "multi-EVM-chain" trackers. StarkNet breaks that assumption: it runs Cairo, not Solidity, and its accounts are smart contracts by default. An EVM tracker cannot read it by analogy. This guide is what StarkNet changes for portfolio tracking.

TL;DR

• StarkNet is a STARK-based validity rollup in Cairo, not the EVM — porting from Ethereum is a rewrite, not a recompile.
• Native account abstraction: accounts are smart contracts, not simple EOAs — interpret accordingly.
• Validity finality: usable in-rollup before the STARK proof is settled on L1 — L2-usable ≠ L1-final.
• An EVM-only tracker mis-reads or misses StarkNet — it needs StarkNet-native decoding.
• Cost basis/tax unchanged — jurisdiction method; L1↔L2 own moves are internal transfers.
• Completeness principle is the same as any chain, applied to a non-EVM environment.

Cairo, not Solidity

StarkNet contracts are written in Cairo. Porting an Ethereum codebase generally means a rewrite, not a recompile — StarkNet is not EVM-equivalent (unlike a Type-2 zkEVM, and further from mainnet than a Type-4 like zkSync Era). For tracking, the consequence is direct: an EVM-only ingester cannot read StarkNet by analogy. Token standards, transaction structure, and event decoding differ from Ethereum, so the tracker needs StarkNet-native decoding.

Account abstraction by default

StarkNet uses native account abstraction: an account is a smart contract, not a simple externally-owned key. Account behaviour — validation, fee payment, multicall — is programmable. A tracker must therefore treat StarkNet accounts as contract accounts and decode their transactions accordingly, not assume an EOA model. This changes how transfers and interactions are interpreted for reconciliation — the account itself is logic, not just a keypair.

Validity finality, same timing discipline

StarkNet is a validity rollup: finality follows a STARK proof verified on Ethereum, not an optimistic challenge window. As with zkSync Era, an in-rollup transaction is usable before the proof settles on L1, and bridged withdrawals follow the proof/settlement timeline. So L2-usable and L1-final are different states, and bridged funds have an in-transit period — the same cross-chain pairing discipline, on a non-EVM chain.

Why an Ethereum tracker fails here

Each mismatch causes missed or misread activity — the StarkNet equivalent of an unmapped wallet, but caused by the execution model, not a missing address.

Tax unchanged; native decoding is the work

StarkNet does not change the cost-basis method — the jurisdiction-mandated one applies. The work:

• StarkNet-native decoding (Cairo, abstracted accounts);
• completeness across the account's StarkNet activity;
• validity-finality timing handled (L2-usable vs L1-final);
• L1↔L2 own-fund moves as internal transfers, not disposals (see internal transfer vs disposal).

Practical guidance

1. Do not use an EVM-only tracker for StarkNet — require StarkNet-native decoding.
2. Treat accounts as smart contracts (account abstraction), not EOAs.
3. Apply the validity-finality timing — L2-usable ≠ L1-final; model in-transit withdrawals.
4. Ensure StarkNet-native completeness across the account's activity.
5. Apply the jurisdiction cost-basis method; L1↔L2 own moves are internal transfers.
6. Reconcile to StarkNet with correct decoding and an audit trail.

How vendor tools handle StarkNet

Koinly and Zerion support non-EVM chains to varying degrees. Confirm the tool has StarkNet-native decoding (Cairo, account abstraction), applies validity-finality timing, and treats L1↔L2 own-fund moves as internal transfers — an EVM-only ingester will under-report or misread a StarkNet portfolio.

How Wag3s helps

Wag3s Folio decodes StarkNet natively (Cairo execution, account-abstraction accounts), applies the validity-proof finality timing, and classifies L1↔L2 own-fund movements as internal transfers under your jurisdiction's cost-basis method — so a non-EVM chain reconciles to the same standard as an EVM one. See the Folio product page.

Further reading

• zkSync Era Portfolio Tracking
• Solana Portfolio Tracking
• Multi-Chain Portfolio Aggregation Beyond EVM
• L2 Accounting: Arbitrum, Optimism, Base
• Cross-Chain Transfer Reconciliation (CCTP & Bridges)
• Crypto Cost Basis Methods 2026

Sources

• StarkNet — STARK-based validity rollup; contracts in Cairo (not EVM-equivalent; porting is a rewrite)
• StarkNet native account abstraction (accounts are smart contracts, not externally-owned keys)
• Validity-rollup finality (STARK proof verified on Ethereum; L2-usable vs L1-final distinction)