Storage & Data

Sui is an L1 that stores all of its state — it is not a rollup, so there is no separate "data availability layer" in the rollup sense. But the question of who stores what, for how long, and who pays is still central to building correctly on Sui. This module covers the object store, checkpoints, archival data, and the storage fund.

The object store

Validators and full nodes maintain the canonical object store — every live object, keyed by ID with version history. "State" and "data" are the same thing here: reading an object is reading state, and serving object data is how the network proves its own history. There is no off-chain blobs-to-derive-from; the chain is the database.

Checkpoints: the settlement log

All transaction effects are committed into checkpoints — signed, sequenced blocks that form the chain's immutable log. Checkpoints are the unit of finality and the unit of history:

• Each checkpoint references its predecessor, so the log is cryptographically append-only.
• Full nodes sync checkpoints from validators to stay current; archive nodes store the full checkpoint history.
• Analytics, indexers, and audit tooling read history from checkpoints, not from the live object store.

Data retention

• Validators / full nodes — keep live objects plus recent history (configurable), typically pruning old object versions once they're checkpointed and no longer needed for fast-path reads.
• Archive nodes — the full record: every checkpoint, every transaction, every object version. If you need historical queries, you need an archive node or an indexer that runs one.

Who pays for storage

Storing bytes on Sui isn't free, and the fee design is worth knowing:

• Transactions pay a storage fee proportional to the bytes they create (object content), separate from execution gas.
• That fee goes into the storage fund, which pays validators for maintaining storage and provides a rebate when storage is deleted — a market-based incentive for the network to keep data available.
• This is why deleting an object (or its content) can return SUI to its owner: you're selling back storage capacity.

Querying data

Developers read data through the JSON-RPC sui_* methods (see the API Reference module): objects by ID or owner, dynamic fields, coins, checkpoints, and transaction history. The object store's indexing (by owner, by type) is what makes these queries cheap and structured — a real contrast with chains where "read my balance" requires parsing a whole account's storage.

Edge cases

• Reading a wrapped object's content via getObject returns nothing useful — the bytes live inside the parent object; use the parent's content.
• Object versions are not globally contiguous — always pass the version you expect, and handle "object version mismatch" as a normal retry, not an error.
• Storage refunds apply only to actual byte deletion; merely overwriting content still costs storage for the new bytes.