~/notes / reading on-chain data
Contract Storage and Why It Is Expensive
Writing to persistent storage is the most costly common operation. The pricing explains a great deal about how contracts are written.
Reading a variable in ordinary software is free. In a smart contract, persistent storage operations dominate the cost of almost everything.
The pricing
Writing a new storage slot is among the most expensive operations available. Updating an existing slot costs less. Clearing a slot refunds part of the cost, subject to caps.
Reading is cheaper than writing and still not free, particularly for a slot not previously accessed in the same transaction.
The asymmetry reflects the real cost: a written slot must be stored by every node, forever.
What follows from it
Contracts minimise storage writes. Patterns that look inefficient in ordinary programming are frequently optimal here because they avoid a write.
Packing. Multiple small values are packed into a single slot, because the cost is per slot rather than per byte.
Events instead of storage. Where data needs to be available to external observers but not to the contract’s own logic, emitting an event is far cheaper than storing it. Events are recorded in logs, which are not part of state.
This is why so much contract data is only accessible by reading logs rather than by querying the contract.
Clearing storage for refunds. Patterns that delete data to reclaim gas, which is where the concept of gas tokens originated before the mechanism was constrained.
The state growth connection
Every written slot is permanent. The fee is paid once by whoever wrote it; the storage cost is borne by every node indefinitely.
That mismatch is the root of the state growth problem, and it is why proposals to address it involve either charging more for writes, expiring untouched state, or moving to designs where nodes do not store state at all.
What a reader can observe
Storage layout is visible on explorers for verified contracts. Reading a specific slot is possible through node queries.
More practically, the distinction between state and logs explains why some information about a contract is easy to query and some is not. If it is in state, a contract can read it and so can you. If it is only in an event, it was cheaper to emit and it is not available to contract logic.
The user-facing consequence
Operations that write more storage cost more gas. A first interaction with a protocol frequently costs more than subsequent ones, because the first writes new slots and later ones update existing ones.
That is why the same operation can cost noticeably different amounts on consecutive attempts, and it is not a malfunction. The confirmation screen shows the estimate before you sign, and checking it is the habit that matters. For withdrawals from a venue, the network fee is handled by the platform, and those that show it separately, such as a platform with real on-chain withdrawals, make the underlying cost visible without you needing to model it.
# Corrections and technical nitpicks are welcome. Send them over. They get published with the fix.