Question 1

What is SUI, and what are its main uses?

Accepted Answer

SUI is the native token of the Sui mainnet: users use it to pay Gas for on-chain operations, holders can delegate it to validators to participate in proof of stake, and it can also serve as on-chain voting power and a liquid asset in applications. It is not reward points for any single application; executing a Sui transaction requires fees to be denominated and paid in SUI. Therefore, holding SUI does not automatically mean receiving revenue or rights from a particular application. Its specific roles in governance, staking, and applications depend on the rules already deployed by the network protocol and by the relevant applications themselves.

Question 2

Why does Sui's object model affect the transaction experience?

Accepted Answer

Sui's on-chain state uses objects as its basic unit, rather than placing all state in one unified balance table for an address. Assets, data, and resources created by Move smart contracts can all be objects with a unique ID, owner, and version; transactions read objects as inputs and create, modify, transfer, or delete objects as outputs. This design affects transaction paths. Address-owned objects controlled by only one address usually do not contend with other users and can use a lower-latency fast path; shared mutable objects that multiple parties can operate must go through consensus ordering. Shared objects make multi-party interactions such as liquidity pools and markets possible, but heavy concurrent writes to the same object create contention, so their latency and throughput should not be conflated with uncontended address-owned-object transactions.

Question 3

How can SUI participate in the network through delegated staking?

Accepted Answer

Sui uses delegated proof of stake (DPoS). SUI holders do not need to run a validator themselves: they can delegate their SUI to a selected validator, where it counts toward that validator's stake; the validator locks its collateral during an epoch and processes and validates network operations. Delegation does not give the validator unrestricted control over the tokens: the protocol creates a self-custodied stake object for that stake, recording the validator stake pool and activation epoch. Validator stake changes take effect only in a new epoch; holders can withdraw or redelegate before the next epoch begins. Validator choice still makes a practical difference because delegation rewards are related to the delegated amount, while a validator's service and fee arrangements affect the delegator's outcome.

Question 4

Where do SUI staking rewards come from, and when are they received?

Accepted Answer

SUI staking returns are not a pre-committed fixed rate. At the end of each epoch, the protocol first aggregates that epoch's staking rewards: these include computation fees accumulated during the period and an early-network staking-reward subsidy that will disappear as circulating supply approaches the supply cap; it then distributes them under protocol rules to participants and to the portion used to compensate storage costs. For delegators, only stake that remains active for the entire epoch accrues rewards for that epoch. When unstaking, the system calculates withdrawable rewards from the validator reward pool based on the stake's activation epoch and unstaking epoch, then unwraps the principal and accumulated rewards together into SUI. Therefore, displayed historical yield, validator performance, and the timing of staking and unstaking must not be treated as a fixed-return promise.

Question 5

What makes up Sui Gas fees?

Accepted Answer

The net Gas fee for a Sui transaction can be summarized as: net fee = computation fee + storage fee − storage rebate. The computation fee depends on the computation units required to execute the transaction and the computation Gas price used by that transaction; the storage fee depends on the storage units consumed by newly added on-chain data and the storage price. The computation Gas price can be understood as the current reference price plus an optional tip. At the start of each epoch, validators submit the minimum price at which they are willing to process transactions, and the protocol selects the two-thirds percentile by stake weight as the reference price; the amount above the reference price can act as a priority-enhancing tip. The storage price is adjusted through governance proposals and usually changes less often. Users must also set a gas budget for a transaction: it is the maximum payable fee, and the transaction will fail if it is insufficient to cover what is required, while part of the budget may still be charged, so the budget ceiling is not the final net fee.

Question 6

How do Sui's storage fund and storage rebates work?

Accepted Answer

Storage fees are not merely one-time charges for on-chain data; they are also connected to Sui's storage fund. When a transaction adds data, the related storage fees enter the storage fund; the fund earns rewards through staking, and the protocol then distributes most of those rewards to current validators to compensate them for the cost of retaining historical data. The logic is to make users who create historical data responsible for storage that future validators must continue to bear, rather than leaving old-data costs entirely to validators who join later. When data is deleted or reduced, the payer can receive a partial storage rebate; current documentation specifies that the rebate equals 99% of the original storage fee. However, the storage fund's principal is not distributed directly, and the unreimbursed portion remains in the fund, so “deleting data provides a rebate” does not mean all previously paid fees are returned.

Question 7

What is the difference between SUI's supply cap and circulating supply?

Accepted Answer

SUI's mainnet total supply cap is 10 billion tokens, meaning the protocol can mint at most 10 billion SUI; this defines a supply cap, not the amount freely tradable at any point in time. The official description gives the mainnet's long-term circulating supply as 10 billion tokens. Tradable circulating supply can be affected by lockups, vesting, and release arrangements. When the Sui mainnet launched publicly on May 3, 2023, approximately 5% of tokens were circulating, while the rest were set to enter the market gradually under the proposed release schedule. Therefore, supply comparisons must distinguish the cap, minted/total supply, and current circulating supply; 10 billion tokens cannot be treated directly as the amount currently tradable in the market.

Question 8

What do SUI's release schedule and the end of the 2024 cliff mean?

Accepted Answer

SUI releases can change the number of tokens that may become available in the market, but they do not change the total supply cap of 10 billion. The official supply page explains that remaining tokens after mainnet launch become available according to a release schedule; the actual arrangement may also vary according to how the foundation deploys its allocation to support builders and the ecosystem, so chart dates should be viewed as estimates rather than guaranteed quantities at every point in time. One key event that has occurred is that initial investor stake had a one-year cliff after mainnet launch, during which it could not enter the market; this cliff ended in May 2024. This event changed when this portion of initial tokens could be transferred. It should not be mischaracterized as new minting, nor should it be used to infer an inevitable price direction.

Question 9

What is the relationship between holding SUI and governance?

Accepted Answer

SUI holders have the right to participate in Sui's on-chain governance voting, and official materials list matters such as protocol upgrades as examples covered by governance. This role differs from paying Gas: Gas pays for transaction execution and resource use, while governance rights are rights to participate in protocol-level decisions. Holding tokens itself does not show that a proposal has passed, that a feature has been enabled on mainnet, or that an on-chain application will necessarily accept a particular voting result. When reading governance-related information, confirm separately the proposal's content, voting or approval status, protocol implementation status, and whether applications have actually adopted it.

Question 10

What is the difference between native SUI staking and liquid staking?

Accepted Answer

Liquid staking is not synonymous with Sui protocol staking; it is an additional application-layer arrangement built on top of stake objects. After Sui introduced SIP-6, stake objects could be used by liquid staking protocols; such protocols may use them to issue another receipt or asset usable in applications. Users therefore need to distinguish two layers: the underlying stake object represents SUI delegated to a validator and its epoch reward settlement; a liquid staking receipt additionally depends on the specific protocol's redemption, fees, smart contracts, and secondary-market liquidity rules. Holding a receipt does not mean directly holding unstaked SUI that can always be redeemed at face value; exit mechanisms and price deviations should follow the rules already deployed by that protocol.

Question 11

What did the Mysticeti upgrade change?

Accepted Answer

Mysticeti is Sui's consensus protocol and began phased deployment on mainnet in July 2024. Before the upgrade, Sui's design combined Narwhal-Bullshark consensus with a fast path for address-owned objects; Mysticeti uses a DAG-based approach to improve the processing path that requires consensus ordering, with the goal of reducing latency and validator computational burden. This change primarily concerns transactions that rely on consensus ordering, such as transactions operating on shared objects; it did not remove the fact that shared objects require ordering, nor does it mean every transaction, every application, or every network condition will achieve the same speed. To assess the upgrade's practical experience, distinguish test results, phased deployment, protocol enablement, and an application's own bottlenecks.

Question 12

Why should you carefully verify signatures and contract permissions when using Sui applications?

Accepted Answer

When interacting with shared objects, users must not treat an object as an asset without permission restrictions simply because it is “publicly accessible.” Any address can submit a transaction referencing a shared object, but the Sui runtime does not automatically provide business authorization controls for privileged operations on shared objects; whether withdrawals, parameter changes, or value transfers are allowed depends on whether the Move contract explicitly checks conditions such as capability credentials, the transaction sender, or object ownership. Before actually signing, verify the connected network, the identity of the contract or application, the objects the transaction will use or modify, the amount, and the scope of authorization. Address-owned objects can be used only by transactions signed by their owner, while the security boundary for shared objects is implemented more through contract code; therefore, the risk of signing for an unknown contract or granting capabilities beyond what is expected does not disappear merely because the transaction passes through the Sui network.

Sui (SUI) Price

Sui (SUI) Price Performance

About Sui (SUI)

How to Buy Sui (SUI)

How to Buy

Frequently Asked Questions About Sui (SUI)