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, three kinds of speed
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, and that field explains why one transaction was instant and another took longer. Without an explorer that surfaces it, the difference is simply unpredictable latency with no available explanation.
Move packages and a different upgrade model
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 rather than needing separate verification after the fact.
The upgrade model follows from immutability. 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, since an old version does not stop existing.
Storage rebates and why fees look odd
Sui charges for computation and for storage separately, and refunds part of the storage cost when an object is deleted.
The practical result is that a transaction which cleans up after itself — closing a temporary object, consolidating coins — can cost far less than its gross gas figure, occasionally close to nothing. Suiscan shows the storage cost and the rebate as separate lines, which is the only way the final number makes sense.
The design intent is worth noting because it is unusual: state is a cost to the network, so the protocol pays you to reduce it. Most chains charge for writes and never refund, which means state grows without any economic pressure against it.
For anyone building on Sui, the rebate is a real design consideration rather than an accounting curiosity. For anyone reading an explorer, it is the answer to a fee that looks wrong.
Reading a Sui address without confusion
Three things surprise people opening a Sui address page for the first time, and all three are the model working correctly.
Multiple coin objects. Your SUI balance is the sum of your coin objects, and there may be many. Wallets merge them automatically when needed, so a page listing several rather than one total is normal. The same applies to any fungible token.
Objects you do not recognise. Interacting with an application often creates objects — receipts, positions, capability tokens — that live in your address afterwards. These are not spam in the BNB Chain sense, because objects cannot be pushed to you without your transaction creating them. They are the on-chain record of things you did.
Version numbers. Every object carries a version that increments when it changes. This is how Sui detects conflicts and enables parallel execution, and it also means an explorer can show you an object's full history without reconstructing it from events.
That last property is quietly excellent for provenance. On an account-model chain, tracing an NFT's ownership history means replaying transfer events. On Sui the object itself carries its history, so the explorer reads it directly. Anyone verifying the origin of a digital asset will find this considerably more convincing than an event log.
The limitation to keep in mind is ecosystem maturity. Labelling is thin, cross-checking options are few, and if Suiscan shows something odd there is not much to compare it against. On an older chain we would tell you to check a second source; here, that advice is harder to act on.