SUI Token

(in maintenance)

What is Sui (SUI)?

Sui (SUI) is the native utility token of the Sui layer-1 blockchain. Sui is a permissionless smart-contract platform that uses the Move programming language and models on-chain assets as “objects” with built-in ownership rules, enabling safe creation and transfer of digital assets.

SUI is used to pay fees for transaction execution and on-chain data storage, to stake with validators in Sui’s delegated proof-of-stake system, and to participate in network governance.

SUI has nine decimal places; its smallest unit is called MIST (1 SUI = 1,000,000,000 MIST), similar to Ethereum’s “wei” for handling very small amounts.

What is SUI used for?

SUI underpins three protocol-level functions on Sui: paying for computation and persistent storage, securing the network via delegated proof-of-stake, and participating in governance. These uses are defined by the core protocol and exposed through standard tooling.

1) Gas (execution) and storage fees: All transactions on Sui pay in SUI. Fees cover both computation (“gas”) and the long-term cost of storing on-chain data. The protocol quotes a reference gas price per epoch and maintains separate pricing for computation and storage. For a deeper breakdown of fee components, see “How are gas and storage fees structured on Sui?”.

2) Staking to secure the network: Sui uses delegated proof-of-stake: holders can delegate SUI to validators to help secure the network and earn rewards. Staked funds are tracked by a stake object that records, among other fields, the activation epoch. For lifecycle and reward mechanics, see “How does staking work on Sui?”.

3) Governance: SUI grants the right to participate in on-chain governance, including voting on protocol matters such as upgrades. Implementation details and scopes of votes evolve through the project’s formal processes; readers interested in procedures and proposal types should consult governance materials and improvement proposals when available.

Beyond these protocol roles, SUI can be used as a general-purpose asset across Sui applications; however, platform-level economics (fees, staking, governance) are the token’s core utilities.

What type of blockchain is Sui?

Sui is a permissionless layer-1 smart-contract blockchain. It runs its own proof-of-stake validators for validation and ordering, and applications are written in Move. Instead of keeping balances in a single global account state, Sui represents on-chain data as typed objects with explicit ownership and rules for how those objects can change. This object-centred design sits at the core of the project.

What sets it apart is how that model shapes execution. When a transaction touches only data owned by a single address (for example, moving coins you control), validators can execute it immediately without waiting for global ordering; this enables wide parallel execution of independent transactions. When a transaction updates shared objects (state that many parties may change), it is ordered by the network first to avoid conflicts. These behaviours are part of the standard transaction lifecycle on Sui.

To provide ordering when it is required, Sui uses the Mysticeti consensus protocol, which outputs a consistent stream of transactions across validators and is engineered for low latency and high throughput. This division—fast paths for owned-object transactions and ordered consensus for shared state—explains Sui’s focus on parallelism without departing from strong consistency where it matters.

How does Sui’s object-based model work compared with account/UTXO designs?

Sui’s object-based model in a nutshell: On Sui, all user-level assets and application state are first-class objects defined in Move. Each object has a unique ID, a type, an owner and a version. Transactions take specific objects as inputs, read or mutate them, and emit new or updated objects as outputs; each output records the transaction that created it. This object graph forms the chain’s global state.

Ownership drives access and concurrency: Every object carries an ownership mode that determines who may read/write it and how it is processed: address-owned (single owner), shared (many participants), immutable, or wrapped/child relationships. By declaring exactly which objects a transaction touches, validators can lock those inputs to prevent double-spend and safely execute independent transactions in parallel.

How this differs from account-based designs (e.g., Ethereum): Account chains maintain a single global account state where smart contracts hold shared storage. Even if two users interact with the same contract on different variables, contention often forces serialisation through global ordering. Sui avoids this by scoping state to explicit objects: when transactions touch disjoint owned objects, they can run concurrently; when they modify shared state, they are ordered before execution. The programming surface remains expressive because objects are rich, typed Move structs rather than just balances or key–value slots.

How this differs from UTXO designs (e.g., Bitcoin, extended-UTXO): UTXO systems model funds as consumable outputs: each spend destroys prior outputs and creates new ones; mutable, long-lived application state is awkward. Sui’s objects are stateful and versioned—they can be updated across transactions while preserving a verifiable history—and they natively encode ownership and capabilities in Move. This “asset-oriented” approach is the core of Sui’s programming model described in the project’s whitepaper.

Practical implications:
* Predictable access control: ownership rules are part of the object type, so contracts can enforce who may mutate what.
* Parallel execution by construction: explicit object inputs enable validators to execute non-overlapping transactions concurrently; locks on inputs prevent conflicts.
* Asset-first development: common assets (including coins) are just objects following standard Move types, making transfers, splits and merges straightforward without bespoke account bookkeeping.

For a focused breakdown of ownership modes—owned, shared and immutable—see the dedicated section “What are ‘owned’ vs ‘shared’ objects and how do they impact latency and throughput?”

How does Sui reach consensus and when is global ordering required?

At a high level, consensus is the network agreeing on a single sequence of transactions so everyone sees the same history. On Sui, consensus is invoked only for transactions that need global ordering. The engine used on mainnet is Mysticeti, a DAG-based Byzantine-fault-tolerant protocol designed to provide a consistent ordered stream with low latency and high throughput.

Two execution paths — Sui separates transactions by what they touch:

• If a transaction uses only owned or immutable objects, validators can execute it immediately on a fast path without waiting for network ordering. This works because only the owner can change those objects, so no other transaction can legally conflict. Certificates are still forwarded to consensus for global consistency, but execution does not block on ordering.
• If a transaction touches at least one shared object—state that many parties may update—it must be sequenced by consensus first so every validator applies the same update order (typical examples include order books, AMM pools or shared game state).

Narwhal & Bullshark, in brief: Narwhal is a DAG-based mempool/data-availability layer that reliably disseminates and stores batches of transactions across validators. Bullshark is a DAG-based ordering protocol that interprets that DAG to produce a single, consistent transaction order. Sui’s original stack paired Narwhal for propagation/storage with Bullshark for ordering—an architectural split that informed Sui’s approach to sequencing shared-object transactions, even though Mysticeti now supplies the mainnet ordering stream.

Why this matters to users and builders: Simple actions like moving your own coins typically finalise quickly because they use the fast path. Workflows that update popular shared state wait for ordering, which adds some latency but ensures a single, conflict-free history. For ownership categories that drive these paths, see “What are ‘owned’ vs ‘shared’ objects and how do they impact latency and throughput?”

What are “owned” vs “shared” objects and how do they impact latency and throughput?

Owned objects are controlled by a single owner (usually an address; sometimes another object in a parent–child relationship). A transaction must list the exact owned objects it intends to read or change. Validators lock those inputs, execute the transaction and produce updated versions of those objects. Because no other user can validly mutate the same owned objects at the same time, these transactions can take a fast path: they execute immediately and in parallel with other transactions that touch different objects.

Shared objects are accessible to everyone on the network. Any update to a shared object (for example, a DEX pool or an order book) must be globally ordered so every validator applies the same sequence of changes. These transactions therefore go through the consensus path before execution, which adds coordination overhead relative to the fast path.

Latency and throughput in practice:

• Owned-only transactions (such as moving your coins or updating a user-specific position object) typically finalise faster because they don’t wait for consensus; validators can execute many such transactions in parallel across CPU cores, increasing throughput.
• Shared-object transactions (such as updating a popular liquidity pool) must be sequenced first, which increases latency and can create contention if many users try to modify the same object at once. Application design often mitigates this by sharding state across multiple shared objects or by keeping most user activity in owned objects and touching shared state only when necessary.

Other ownership modes (briefly for context): Sui also supports immutable objects, which can be read by anyone but not mutated after creation. They do not require consensus to read and are useful for code and metadata. Wrapped/child relationships are represented as objects owned by other objects, inheriting the owner’s semantics. (Detailed definitions are covered in Sui’s ownership documentation.)

In short, Sui’s ownership model lets the network avoid global ordering for the large class of owned-object operations, lowering latency and enabling parallel execution, while reserving consensus—and its costs—for updates to shared state where a single, conflict-free order is required.

What is a Programmable Transaction Block (PTB) and what does it enable?

A Programmable Transaction Block (PTB) is Sui’s standard transaction format: a single transaction composed of an ordered list of commands that execute on specified inputs (objects or pure values) to produce results. With a PTB you can call multiple Move functions, manage objects and manage coins in one atomic submission—without publishing new code. Effects are applied at the end of execution; if any command fails, the entire block reverts. You can also pipe the result of one command into later commands within the same PTB.

PTBs support a defined set of commands, including MoveCall, TransferObjects, SplitCoins, MergeCoins, MakeMoveVec, and package Publish/Upgrade. This lets a transaction, for example, split a coin, invoke multiple contract functions, and transfer resulting objects—all together and all-or-nothing.

From a performance and UX perspective, PTBs can batch up to 1,024 unique operations in one execution and are designed to reduce overhead versus sending many separate transactions. They are “lightweight and flexible” for builders and automation, while intentionally excluding complex control flow like loops—use a Move package for that.

Developers typically build PTBs using the Sui TypeScript SDK (e.g., the Transaction builder) or the CLI, adding commands programmatically before signing and submitting. This approach enables clean, multi-step workflows such as batched payments, minting/issuing flows, or composing calls across several packages, delivered as a single atomic user action.

How are gas and storage fees structured on Sui?

Two fee components per transaction: Every Sui transaction pays (a) computation gas for execution and (b) a storage fee for the on-chain data it creates or grows. Formally,
total_gas_fees = computation_units × reference_gas_price + storage_units × storage_price. If previously stored data is deleted in the same transaction, a storage rebate is applied:
net_gas_fees = computation_gas_fee + storage_gas_fee − storage_rebate.

Prices vs units: The network separates units from prices: computation/storage units measure the work (e.g., buckets of compute; bytes stored), while prices translate those units into SUI. The reference gas price is set by validators at each epoch boundary through a survey mechanism and is the usual price users pay; storage price is set via governance and changes infrequently. Wallets/SDKs default to the current reference gas price.

Gas budget and payment: Each transaction includes a gas budget (a cap on what you are willing to spend). The protocol requires the budget to cover at least the computation fee even if a transaction aborts; minimum and maximum budget bounds apply to protect the network. Gas is paid from a SUI gas coin; SDKs can automatically select coins, and “gas smashing” can combine multiple coins when needed.

How storage fees behave: Storage fees are paid upfront to reflect the long-term cost of keeping data on chain and are split into rebateable and non-rebateable parts; when data is later deleted, the rebateable portion is returned according to protocol rules. Detailed mechanics and the role of the storage fund are covered in the next section.

Developer implications (brief): Costs depend on both compute complexity (bucketed into coarse tiers) and bytes written. Designing contracts to minimise unnecessary writes and to reclaim state where appropriate can reduce net fees via rebates.

What is the storage fund and how do deposits and rebates operate?

The storage fund is a protocol-level pool of SUI that accumulates storage fees paid by transactions that add data to the chain. It lets Sui shift storage costs over time so that future validators are compensated for keeping historical data, even though the users who created that data paid in the past. The fund is designed not to deplete: it pays out only the returns on its capital (e.g., staking rewards) rather than the principal.

How deposits work when writing data: When a transaction creates or enlarges on-chain objects, it pays a storage fee that is split into:
* a rebateable deposit recorded per object (its storage_rebate), and
* a non-refundable storage fee retained by the system.

By default, the rebateable share starts at 99% and the non-refundable share at 1% (governance parameters may change). The system maintains an invariant that the fund’s accounting equals cumulative fees in minus rebates out, tracking the sum of all live objects’ storage_rebate and the fund’s non-refundable balance.

How rebates work when deleting data: If a later transaction deletes previously stored objects (or shrinks their size), the sender receives the object’s storage rebate back; only the non-refundable portion is kept by the system. Rebates are credited after execution and cannot be used to pay gas in the same transaction. In practice, wallets/SDKs credit the rebate to the gas coin once the transaction completes.

Where the fund is visible and how it’s used: Protocol APIs expose the fund’s size, non-refundable balance and the total of live storage_rebates; epoch records also track fund inflows/outflows and storage-related charges. Validators are compensated from returns on the fund’s capital so that storage costs remain covered across epochs without drawing down principal.

Design implications for builders: Because storage is paid upfront and only partially rebated, contracts that reclaim or compress state (for example, by retiring obsolete objects) can reduce long-term costs for users. For the fee formula and pricing knobs (reference gas price vs storage price), see “How are gas and storage fees structured on Sui?”

Does the protocol include any SUI removal/burn mechanics?

No automatic “base-fee burn”: Sui does not implement an Ethereum-style, protocol-level burn of gas fees. Gas paid in SUI funds validator rewards and network operations (computation fees) and the storage economics described below, rather than being destroyed.

Storage fees are locked, not burned: When a transaction writes data, it pays a storage fee that is split into a rebateable deposit (recorded per object) and a non-refundable portion. These amounts accrue to the storage fund, which the protocol accounts for explicitly; the fund pays out rebates when objects are later deleted and keeps a non-refundable balance. This balance is tracked on chain and is not a burn—it remains in the storage fund’s accounting rather than being destroyed.

Developer “burn” APIs don’t apply to SUI itself: In Sui’s framework, mint/burn of fungible assets requires control of a token’s TreasuryCap (the authority object). That pattern is available for user-issued coins, but there is no public TreasuryCap for the native SUI coin, whose supply was fixed at genesis—so applications cannot reduce SUI supply via the generic coin::burn flow. (This follows from the framework’s API requirements and the project’s description of SUI as fixed-supply.)

Mechanisms that influence what users pay (and what is deposited to storage) are detailed in “How are gas and storage fees structured on Sui?” and “What is the storage fund and how do deposits and rebates operate?”

What is SUI’s supply and distribution model?

SUI has a capped total supply with a long-run target of 10 billion tokens. Circulating supply increases over time according to a published release plan maintained by the Sui Foundation. (Live figures are shown on this page’s stats panel.)

How tokens are allocated and distributed: At a high level, supply is split across several buckets governed by the project’s tokenomics and foundation policies:

• Community Reserve (Foundation-managed): used for ecosystem growth, including a Delegation Programme to help bootstrap validators and promote balanced stake, grants (developer and education), and research & development. This reserve is the principal source for ongoing community distributions.
• Mysten Labs treasury: reflects Mysten Labs’ role as the project’s original contributor.
• Early participants and supporters: allocations administered by the Foundation, including the Community Access Programme for eligible early contributors; these allocations follow lockups defined in the release plan.
• Stake Subsidy pool: a dedicated balance of SUI set aside to bootstrap staking rewards; the amount distributed decays over time and is paid out with epoch rewards. This pool is tracked on chain (e.g., distribution counter, current amount, period length).

Release schedule and transparency: The Foundation publishes a multi-year release schedule (subject to adjustments for network health) and exposes official APIs that report monthly circulating-supply figures. These resources underpin dashboards and the live stats visible on this page.

Notes on economics (context): Rewards to validators and delegators are driven by protocol economics, including gas fees and the storage-fund design; neither mechanism implies perpetual inflation beyond the capped supply, and stake-subsidy distributions are drawn from their reserved pool rather than new issuance. For details on fees and the storage fund, see the dedicated sections.