StarkNet Portfolio Tracking: A Non-EVM, Cairo Chain

Where zkSync Era keeps an EVM balance model and only changes finality timing, StarkNet changes the execution environment itself. Its contracts are written in Cairo rather than Solidity, so porting Ethereum code is a rewrite and not a recompile, and an EVM ingester cannot read StarkNet by analogy. On top of that, StarkNet has native account abstraction: every account is a smart contract, not a keypair, which changes how transactions and transfers decode. The distinct tracking problem here is therefore decoding and account model, layered over the same validity-proof finality timing as any ZK rollup. This article covers what an EVM tracker gets wrong on StarkNet and how to reconcile a Cairo portfolio. It is one of the non-EVM cases in the multi-chain aggregation hub.

Why StarkNet needs native decoding

• StarkNet is a STARK-based validity rollup written in Cairo, not the EVM, so porting from Ethereum is a rewrite, not a recompile.
• It has native account abstraction: accounts are smart contracts, not simple EOAs, and must be interpreted accordingly.
• Finality follows a STARK proof verified on Ethereum, so usable in-rollup is not the same as L1-final.
• An EVM-only tracker misreads or misses StarkNet activity, so it needs StarkNet-native decoding.
• Cost basis and tax are unchanged (jurisdiction method); L1 to L2 movements of your own funds are internal transfers.
• The 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, because 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.

Key StarkNet token standards

• ERC-20 equivalent — The OpenZeppelin Cairo ERC-20 implementation is the de-facto standard. The balanceOf(account: ContractAddress) function returns a u256. ABI decoding is Cairo-specific; it is not the same as Ethereum ABI encoding.
• ERC-721 / NFTs — Cairo-based NFT contracts emit Transfer events with felt252 type arguments, not Ethereum's address type. An EVM event decoder will mis-parse these.
• Native STRK and ETH — On StarkNet, ETH is an ERC-20-like contract at a well-known address (0x049d36...), and STRK is similarly a contract. Neither is a "native" chain asset in the Ethereum sense — both must be queried as contract balances.

Account abstraction by default

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

Step-by-step: how to track a StarkNet portfolio

1. Identify the account contract address. Unlike Ethereum EOAs, a StarkNet address is a deployed contract. Confirm the address is deployed before querying; an undeployed address has no on-chain state yet even if funds were pre-funded.
2. Query token balances using starknet_call. Call balanceOf on each token contract. ETH is at 0x049d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7 and STRK at 0x04718f5a0fc34cc1af16a1cdee98ffb20c31f5cd61d6ab07201858f4287c938d.
3. Fetch transaction history via starknet_getTransactionByHash or an indexer. StarkNet's native RPC does not provide a "transactions by address" endpoint — you need a StarkNet indexer (e.g. Voyager, Starkscan, or Apibara) to query per-address history.
4. Decode events using the Cairo ABI. Each contract emits events defined in its Cairo ABI. For ERC-20 transfers, look for the Transfer event with from_, to, and value fields encoded as felt252 or u256 (two felts for u256). Apply the contract-specific ABI, not a generic Ethereum decoder.
5. Handle multicall transactions. Account abstraction wallets frequently batch multiple calls in a single transaction (e.g. approve + swap). The tracker must unpack each Execute call in the transaction and attribute each token flow individually.
6. Track L1↔L2 bridge movements. Deposits via the StarkGate bridge are initiated on Ethereum and finalised on StarkNet. Withdrawals are submitted on StarkNet and finalised on Ethereum after proof settlement. Both legs must be paired as internal transfers.
7. Classify fees. StarkNet fees are paid in ETH or STRK (depending on the fee token setting on the account). Read the actual_fee field from the transaction receipt and attribute it to the corresponding token's cost basis.

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 and 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 rather than a missing address.

Common errors and how to fix them

Error 1 — Querying ETH as a native balance. On Ethereum, ETH balance is read via eth_getBalance. On StarkNet, ETH is an ERC-20-like contract. Using a native-balance query returns zero. Fix: call balanceOf on the ETH contract address, not a native balance endpoint.

Error 2 — Mis-parsing u256 values. Cairo's u256 is represented as two felt252 values (low 128 bits and high 128 bits). An EVM decoder expecting a single 32-byte integer will read only the low half and silently truncate large token amounts. Fix: decode u256 as (low: felt252, high: felt252) and reconstruct value = low + high * 2^128.

Error 3 — Missing multicall sub-transactions. Argent X and Braavos wallets send multicall transactions where the outer transaction wraps several Call entries. A tracker that reads only the outer transaction misses the individual token transfers within. Fix: unpack the calldata of __execute__ calls and attribute each inner call's token flows separately.

Error 4 — Counting fee payment in STRK as a separate disposal. When the account pays a transaction fee in STRK, that fee deduction should reduce the STRK cost-basis pool, not be booked as a sale of STRK for ETH. Fix: classify actual_fee payments as fee deductions, not as disposals, regardless of which token is used.

Tax unchanged; native decoding is the work

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

• StarkNet-native decoding for Cairo and abstracted accounts;
• completeness across the account's StarkNet activity;
• validity-finality timing handled, distinguishing L2-usable from L1-final;
• L1 to L2 movements of your own funds classified 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 is not L1-final, so 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.

Choosing a tool for a Cairo chain

Koinly and Zerion support non-EVM chains to varying degrees, but the StarkNet-specific checks are:

• it decodes Cairo events and types natively, including reading u256 as two felt252 halves so large token amounts are not silently truncated;
• it queries ETH and STRK as contract balances at their well-known addresses, not as a native-balance call that returns zero;
• it unpacks multicall transactions (common with Argent X and Braavos) so each inner token flow is attributed individually;
• it classifies an actual_fee payment as a fee deduction, not a disposal of the fee token;
• it treats L1 to L2 movements of your own funds as internal transfers.

An EVM-only ingester will under-report or misread a StarkNet portfolio.

How Wag3s handles StarkNet

Wag3s Folio decodes StarkNet natively (Cairo execution, account-abstraction accounts, multicall unpacking, u256 reconstruction), applies the validity-proof finality timing, and classifies L1 to 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 — Accounts: native account abstraction, where every account is a smart contract rather than an externally-owned key, with programmable validation and fee logic.
• Starknet — SNOS and the validity rollup: the STARK-based validity rollup written in Cairo, proving state and settling to Ethereum.
• IRS — Digital assets for the US cost-basis and disposal framework applied to the decoded data, not the chain.