Sui is a delegated proof-of-stake blockchain whose on-chain state is organized as uniquely identified objects. SUI is its native asset, gas and staking token. This page focuses on how SUI Gas and Storage Charges Work and the checks users need before sending funds, paying fees or using the network.
Review a Sui transaction by identifying the objects, Move calls, gas coin and ownership changes it contains.
Subject:
Sui
Market mode:
Snapshot Only
Fee asset:
SUI
Timezone:
UTC
This page does not verify an object ID, package, validator, token type or transaction and does not provide investment advice.
Content ownership: BitcoinToolkit Editorial TeamTechnical references: Official protocol and developer documentation.Review approach: Technical explanations are checked against primary sources and updated when the network or asset changes.Last content review: Data integration last tested:
How SUI Gas and Storage Charges Work
A transaction supplies one or more SUI coin objects for gas and declares a budget.
Sui workflow from the first user decision to a verified outcome.
Computation and storage
Gas accounts for computation and storage operations. The gas price interacts with the computation used, while storage charges reflect data written on chain. Storage rebates can return part of previously paid storage cost when eligible data is removed, so the final balance change can differ from a simple gas-used multiplication.
The gas coin is itself an object and can be mutated during payment. A user transferring another token still needs spendable SUI gas. The budget is a maximum willingness to pay, not a guarantee that every command is safe or that a congested application will complete.
Estimate before signing
Applications should use current reference gas prices and dry-run or simulation results, then preserve margin for state changes. Users should distinguish gas from transferred SUI, object deposits, application fees and swap price impact. An insufficient budget or stale object can fail even when the wallet shows enough total SUI.
The Next Sui Step
Sui stores assets and application state as objects with IDs, versions and explicit ownership.
Objects instead of a generic account store
Every Sui object has a unique ID, version, owner and metadata describing its latest use. Move objects contain typed application data, while package objects contain published Move bytecode. A package is not the same thing as a wallet or token balance, and a familiar package name is not proof that its ID is canonical.
Address-owned objects can be authorized by the controlling address. Objects can also be owned by other objects, shared for coordinated access, immutable, or wrapped inside another object. Those forms affect transferability and execution. A wallet summary that only lists coin amounts can hide the object changes an application call will make.
Versions prevent conflicting use
An object version changes when the object is mutated. Transactions reference specific inputs, allowing the system to detect attempts to use stale or already-consumed versions. Users retrying a failed application action should rebuild from current object state rather than repeatedly signing an old transaction payload.
A programmable transaction block can combine several commands and pass results between them as one atomic action.
Commands, inputs and effects
A Sui transaction identifies input objects, pure values, a gas object and commands such as transfers, coin splits, coin merges or Move calls. Commands can feed results into later commands. The complete transaction succeeds atomically or its intended state changes do not commit, although gas can still be charged for processing.
Move packages define the types and functions that can operate on objects. Ability rules and function signatures constrain whether an object can be copied, dropped, stored or used as a key. Wallets should display every package call and object transfer; users should be cautious when an interface reduces a multi-command transaction to one vague button label.
Owned and shared execution paths
Transactions using only independently owned objects can avoid global ordering when their dependencies are clear. Shared objects require consensus ordering so concurrent users agree on the sequence of changes. This difference supports parallel execution but does not guarantee that every transaction has the same latency.
Sui combines delegated proof of stake with consensus designed for low-latency ordering of shared-object activity.
What validators agree on
Validators process transactions and participate in the Mysticeti consensus protocol. Stake delegation contributes to validator voting power and rewards under current network rules. Consensus orders activity that needs a common sequence, particularly shared-object transactions, while object ownership allows simpler transactions to use optimized paths.
Final execution does not certify that a package is trustworthy or an object has economic value. It confirms that the network accepted the transaction under protocol rules. Applications should wait for the transaction effects required by their workflow and should verify them from a current full node or RPC service.
Staking boundaries
Delegating SUI exposes users to validator performance, reward timing and protocol rules. It does not grant control of application packages or protect against a malicious signature request. Validator and staking decisions should use current network data rather than historical rates.
Object-centric execution rewards a more detailed transaction review.
Transaction checklist
Verify mainnet, sender, gas object, gas budget, package IDs, input objects, shared-object calls, coin splits, transfers and resulting ownership. Confirm token type and package address instead of trusting a ticker. Rebuild stale transactions from current object versions.
Keep SUI available for gas.
Inspect every programmable command.
Verify package and token type IDs.
Treat simulation as an estimate, not an audit.
What Sui users should verify and why this design differs
Compare Aptos to see another Move implementation with a different state model. Developers should consult current Sui package and transaction documentation. Browse the tools directory for general validators and converters rather than treating a market page as an object inspector.
Sui Network use FAQ
What is a Sui object?
It is a uniquely identified unit of on-chain state with a version, owner and typed data.
What pays Sui transaction fees?
SUI coin objects pay computation and storage-related gas charges.
Why are shared objects different?
Concurrent access requires network ordering, while independently owned objects can use more direct execution paths.
What should I verify before a Sui transaction?
Check the official destination, current network, asset representation, amount, recipient and requested permissions. Transactions operate on owned, shared or immutable objects through Move packages. Object ownership determines whether a transaction can use a low-latency path or must be ordered through consensus. After confirmation, inspect the resulting balance or protocol state instead of relying only on a wallet success message.
Known Limitations
Gas schedules, package behavior and consensus software can change.
Simulation cannot prove that a Move package is safe.
The page does not verify an object, package, token type or validator.
Market Data Methodology
The page uses a CoinGecko aggregated SUI/USD snapshot. No exchange chart is rendered for this entity.
Market Snapshot Source
CoinGecko aggregated market data (SUI/USD)
Cache
Snapshot cache is approximately 60 seconds.
Failure Handling
Verified cached data is labeled Cached or Delayed. Missing values remain unavailable.
