Everything is an object
Sui does not store a table of balances. It stores objects, each with a unique identifier, a type, a version and an owner. Your SUI is held in coin objects. Your NFT is an object. A staking position is an object. The code that defines all of them lives in package objects.
A transaction takes objects as inputs and produces objects as outputs, which is closer to Bitcoin's UTXO model than to Ethereum's accounts — except that objects are typed and carry arbitrary structured data rather than just value.
This has a direct performance consequence and it explains Sui's design. Transactions touching disjoint sets of objects cannot conflict, so they can be executed in parallel without consensus ordering. A simple transfer of an object you solely own does not need agreement from the whole network about ordering, which is why it finalises in well under a second.
Suiscan shows this structure directly — object IDs, types, versions and ownership — rather than computing a balance and presenting it as the truth. The balance is a derived figure; the objects are the state.
Three kinds of ownership
Sui distinguishes ownership in a way most chains do not, and the distinction determines how a transaction is processed.
Owned objects belong to a single address. Only that address can use them, so transactions touching only owned objects skip full consensus and finalise almost immediately.
Shared objects can be used by anyone — a liquidity pool, an order book, a shared registry. Because multiple parties may try to modify them simultaneously, these transactions require consensus ordering and are correspondingly slower.
Immutable objects cannot be changed at all. Published packages are immutable, which is why Sui contract upgrades work differently from EVM proxy patterns.
Suiscan labels the ownership type on every object. That field explains why one transaction was instant and another took longer, which is otherwise mysterious.
Move packages, and why upgrades differ
Sui uses Move, a language designed around resources that cannot be copied or accidentally discarded. That property is enforced by the type system rather than by developer discipline, which removes a category of bug that has been expensive on other chains.
Suiscan lets you browse published packages: modules, public functions, struct definitions and type signatures. For anyone assessing what a package can do, that is the equivalent of reading verified source on Etherscan, and it is available by default because packages are published as readable bytecode with type information.
The upgrade model is worth understanding. Because packages are immutable objects, upgrading means publishing a new version with a link to the previous one, rather than swapping an implementation behind a proxy. The upgrade path is explicit and on chain, which is more transparent than the EVM approach — though it does mean you must check which version an application is actually calling.
Using it in practice
Two things worth knowing when you open an address page.
Your SUI balance is the sum of your coin objects, and there may be many of them. Wallets merge these automatically, but a page showing several coin objects rather than one balance is normal rather than a sign of anything wrong.
And storage rebates are real. Sui charges for storage and refunds part of it when an object is deleted, which means a transaction that cleans up after itself can cost less than you expect, occasionally close to nothing. Suiscan shows the storage cost and rebate separately, which is the only way to understand an unexpectedly small fee.
For cross-checking, 3xpl indexes Sui and renders faster if you only need to confirm a transaction exists. For anything involving objects, packages or ownership, Suiscan is the tool that models the chain correctly.
What our reference tests showed
Our Sui reference items were chosen to exercise the object model: a simple owned-object transfer, a transaction touching a shared object, an NFT transfer, a package publication, and a transaction that deleted an object to trigger a storage rebate.
The owned-object transfer finalised almost instantly and Suiscan showed it as such, with the ownership type labelled. The shared-object transaction took visibly longer and the explorer's presentation made the reason apparent — consensus ordering was required because the object could be contended.
That contrast is the most useful thing we learned from the testing. Two transactions that look identical to a user took markedly different times, and the explanation was a single field on the page. Without an explorer that surfaces ownership type, the difference is simply unpredictable latency.
The NFT transfer rendered with full provenance, because on Sui an NFT is an object with a version history rather than an entry in a contract's mapping. Following previous owners took no additional queries.
The package publication view showed modules, public functions and their type signatures without us having to submit source for verification — the type information is published with the bytecode, which is a structural advantage over the EVM's verify-after-the-fact model.
The storage rebate test produced a transaction with a net cost lower than its gross gas, and Suiscan showed the storage cost and rebate as separate lines. Without that breakdown the final figure looks like an error.