Every account is a contract
On Ethereum there are two kinds of account: externally owned accounts controlled by a private key, and contract accounts controlled by code. Starknet has only the second kind.
Your Starknet wallet is a smart contract. It defines its own signature validation, which means it can use signature schemes Ethereum cannot, support multiple signers, implement session keys, or allow someone else to pay your fees.
This is native account abstraction, and it is a genuine improvement on the EVM model, where the same capabilities require bolted-on standards. It also means every transaction is a contract call, with no simple-transfer special case.
Starkscan presents this correctly: account pages show the account contract and its class, not a pretend externally-owned account. Once you know the model, the explorer makes sense; before that, it is confusing in a way that is the model's doing rather than the explorer's.
Classes and instances
Starknet separates contract code from contract deployment. Code is declared as a class, identified by a class hash. Instances are then deployed from that class, each with its own address and storage.
Many wallets share one account class. Many tokens can share one token class. The code exists once on chain; the instances are cheap.
This is more efficient than the EVM approach of deploying identical bytecode repeatedly, and it changes what verification means. Verifying a class verifies every instance of it — which is a considerably stronger property than the EVM's per-address verification.
Starkscan shows both dimensions: the class with its declared code, and the instances deployed from it. When assessing an unfamiliar contract, checking whether its class is a widely-used verified one is a fast and genuinely informative check with no EVM equivalent.
Cairo and calldata
Cairo is Starknet's language, designed so that execution can be proven with STARK proofs. It is not Solidity and it does not compile to EVM bytecode; the semantics genuinely differ.
The practical consequence for reading transactions is calldata. Starknet calldata is an array of field elements — raw numbers — and without knowing the target function's signature it is meaningless. Starkscan decodes it against the contract's ABI, turning a list of integers into named typed arguments.
Where it cannot decode, it shows the raw array. That is the right behaviour, and it is worth checking the raw form when something looks odd, since a decoder working from an incorrect ABI produces confidently wrong output.
Voyager is the second opinion here, and on an ecosystem this young having two independent decoders is more valuable than it would be on Ethereum.
Validity proofs, not challenge windows
Starknet is a validity rollup. Rather than assuming transactions are correct and allowing a challenge period, it generates a cryptographic proof that a batch was executed correctly and verifies that proof on Ethereum.
The difference from Arbitrum and Base is significant. There is no seven-day challenge window, because there is nothing to challenge — the proof either verifies or it does not. Withdrawals are bounded by proof generation and verification time rather than by a fixed dispute period.
Proof generation is computationally heavy, so batches are not instant, and Starkscan shows which batch a transaction is in and whether its proof has been verified on Ethereum. That is the field that tells you whether a transaction is settled in the strongest sense.
The same distinction applies to Linea and Scroll. When comparing rollups, "how long to withdraw" is answered by the proof system, not by the marketing.
What our reference tests showed
Starknet needed a modified reference set, because half our usual EVM items do not exist here — there are no externally owned accounts and no plain transfers that are not contract calls.
What we tested instead: an account deployment, a token transfer through an account contract, a call to a widely-used verified class, a call to an unverified contract, and a multicall bundling several operations.
The account deployment rendered correctly, with the class hash identified and linked to other instances of the same class — which is the view that has no EVM equivalent and is genuinely informative. Seeing that an unfamiliar account uses the same widely-deployed wallet class as thousands of others is a meaningful signal in a way that a per-address verification badge is not.
Calldata decoding worked on every verified class we tried, producing named typed arguments rather than field-element arrays. On the unverified contract it fell back to the raw array, clearly labelled as undecoded rather than presented as a best guess. That is the correct behaviour and we checked for it specifically, because a decoder that quietly guesses is worse than one that admits it cannot.
The multicall was rendered as its component calls, which is what account abstraction makes possible and what makes Starknet transactions readable at all.
We cross-checked three of the five against Voyager. All three matched. On an ecosystem this young, running the comparison occasionally is worth the thirty seconds, because a decoding divergence between two independent implementations is the fastest way to discover that one of them has an ABI wrong.