Sui

Sui is staked through validator-bound objects that track every position change

Sui is staked by choosing one active validator and signing a transaction that turns the selected SUI into a self-custodial StakedSui object. The position stays pending until the next epoch, then its withdrawal value rises through the validator pool’s exchange rate as rewards accrue. Adding more SUI creates another position with its own activation epoch; unstaking consumes the chosen stake object and returns principal plus calculated rewards. Before signing, retain liquid SUI for gas, read the validator’s commission and confirm the wallet is connected to Sui Mainnet. The sections below follow this position from entry and status checks through routine additions, partial adjustments and final withdrawal.

Bottom line: A 1 SUI floor applies to each output of a split StakedSui position.

Fees and the liquid SUI reserve

Native staking fees are transaction gas charges, paid in SUI when a position enters, changes or leaves the staking pool. Entry needs one signed transaction, while a later full exit needs another.

SUI uses 9 decimal places, and 1 SUI equals 1,000,000,000 MIST, the unit used by protocol gas accounting. Detailed gas output exposes four relevant fields: computation cost, storage cost, storage rebate and the non-refundable storage fee. No durable SUI amount covers every stake because the reference gas price, gas budget and object-storage effects belong to the transaction being executed. A compatible wallet estimates that charge before signing. Keep a separate liquid balance for the unstake and any later transfer instead of committing the address’s entire spendable balance.

Validator selection before the first signature

Validator selection is the routing decision that binds one StakedSui position to one active validator’s staking pool. That choice affects commission, reward history and the position’s pool ID.

Commission uses a 10,000-basis-point scale: 1 basis point equals 0.01% and 500 basis points equals 5%. The displayed percentage remains validator-controlled and a requested change takes effect at an epoch boundary. Reward estimates also reflect the pool’s past performance. A validator that receives no reward for a completed epoch adds nothing to its pool exchange rate for that period, while the principal remains recorded in the stake object with the same pool ID and activation epoch for later withdrawal.

• Active status: select an active validator, not a candidate or inactive pool.
• Commission: read the stated rate and any pending next-epoch change.
• Pool history: compare several completed epochs rather than one annualized estimate.
• Identifiers: record the validator address and staking-pool ID shown before signing.
• Exit path: confirm the wallet exposes native unstaking for a StakedSui position.

This checklist separates durable on-chain conditions from a live yield number. It also makes the eventual withdrawal easier to reconcile.

The StakedSui object as the position record

A StakedSui object is the self-custodial on-chain record that represents one native stake position and its withdrawal right. It is owned by the staking address rather than credited as a liquid coin balance.

The Move struct in the Sui Framework carries four fields: an object ID, a staking-pool ID, an activation epoch and the principal balance. One object therefore points to exactly one pool and one activation epoch. Rewards do not rewrite the principal field after every epoch. The system derives the object’s redeemable value from the pool exchange-rate history when an application displays rewards or prepares a withdrawal.

Slush, the wallet built by Mysten Labs, presents that object through a staking interface. Another compatible interface reading the same address should find the same on-chain record. Creating a new address does not move the position; transferring the StakedSui object moves the redemption right with it. The object ID is the cleanest reference when wallet labels look similar.

Activation at the next epoch boundary

Stake activation is an epoch-boundary state change that moves a confirmed request from pending to reward-earning status. Confirmation and activation are therefore different lifecycle events.

A stake submitted in epoch E records activation epoch E + 1 and earns rewards only after it remains active for a full epoch. Mainnet epoch changes are intended to occur about every 24 hours, but the epoch number is the authoritative trigger. A request placed near a boundary has a shorter pending interval than one placed just after the previous boundary.

A pending object shows principal and its future activation epoch, yet it has completed zero reward-bearing epochs. If that pending stake is withdrawn before activation, the current staking-pool contract returns the principal and removes it from pending stake. The next decision is whether to wait for activation or close the request before its first reward-bearing epoch.

Reward accounting through pool exchange rates

Pool exchange rates are the accounting mechanism that turns a stake’s fixed principal into a rising withdrawal value. Each validator maintains its own rate history at epoch boundaries.

Every rate stores two integer amounts: SUI in the pool and the corresponding internal pool-token amount. For an active position, the protocol converts principal at the activation-epoch rate, then converts that pool-token amount back to SUI at the selected current epoch. Two snapshots drive the calculation. The difference between the current SUI value and principal is the estimated reward, limited by the pool’s available rewards balance.

Native stake compounds inside this accounting. Rewards deposited after an epoch raise the rate for the next one, so they participate in later growth without a separate claim transaction. There is no canonical protocol APY field. Wallets and explorers annualize completed exchange-rate changes using their own windows, which explains why Slush and Suiscan may display different percentages for the same validator.

Read the position’s SUI-denominated withdrawal estimate, activation epoch and pool identity together. A percentage alone cannot reconcile an individual object.

Added stake as a new on-chain position

An added stake is a fresh on-chain position, even when it uses the same address and validator as an existing stake. The new object receives its own activation epoch.

Consider a routine top-up made after the original position has already activated. The first StakedSui object keeps its earlier activation snapshot and continues accruing, while the top-up stays pending until the following boundary and then begins from that later pool rate as a separate on-chain record. A wallet may group both under one validator name, although the chain still holds two object IDs and two reward histories.

Standard StakedSui objects join only when two metadata values match: the pool ID and activation epoch. Additions submitted in the same epoch to the same validator satisfy both conditions. A later top-up does not, because its activation epoch differs.

Applications built around SIP-6 can convert an active object into FungibleStakedSui, whose value represents internal pool tokens for one validator pool. That advanced route supports merging fungible positions from different activation epochs within the same pool. For ordinary native staking, keeping separate records preserves a clear entry history and lets the holder choose which position to redeem next.

Partial changes through stake-object splitting

A partial adjustment is a two-step object operation: split one StakedSui record, then redeem the portion selected for withdrawal. Both steps fit inside one Programmable Transaction Block.

The Move contract requires both outputs of a StakedSui split to hold at least 1 SUI, equal to 1,000,000,000 MIST. A position therefore needs at least 2 SUI before any compliant split exists. The withdrawn piece must contain 1 SUI or more, and the piece left staked must also retain at least 1 SUI. These thresholds govern splitting, not the initial add-stake call.

A developer using the Sui CLI or a software development kit can place the split and withdrawal calls in one atomic transaction with one signature. Wallet support for partial native unstaking varies by interface. When the interface offers only full redemption, the protocol-level alternative requires a client that constructs the correct object operations.

Unstaking as object redemption

Native unstaking is a redemption transaction that consumes one StakedSui object and returns a Coin to the same address. Principal and calculated rewards arrive together.

The system reads the pool rate at the object’s activation epoch and the rate for the current epoch. It converts the recorded principal into internal pool tokens using the first rate, values those tokens with the second and joins the reward difference to principal. That transaction also records the pool’s pending SUI and pool-token withdrawals for reconciliation at the next epoch change.

There is no protocol unbonding queue after an active native-stake redemption executes. The returned SUI is an owned coin once the transaction succeeds, while the selected StakedSui object no longer exists. An inactive pool follows the same holder-facing redemption outcome and processes its internal withdrawal bookkeeping immediately.

Check the object ID, principal amount and validator pool before approving a full exit. The next action uses the returned liquid SUI, not the consumed position record.

Position checks across wallets and explorers

A position check is a reconciliation of wallet labels with the stake object’s fields and the validator pool’s epoch data. Three observations establish the lifecycle state.

First, the transaction effects must show successful creation or consumption of the expected object. Second, the current epoch must be compared with the object’s activation epoch to distinguish pending from active. Third, the reward estimate must use that validator pool’s exchange rates rather than an unrelated headline APY. These checks explain the position without relying on a wallet’s portfolio total.

Slush provides the everyday view, while Suiscan and SuiVision expose address, object and validator details. The Sui CLI gives technical users direct object and transaction output, and Sui GraphQL RPC supports structured application queries. Use the same address and object ID across these tools. After an unstake, the decisive evidence is one consumed StakedSui object plus the returned SUI balance change.

Native stake and liquid staking tokens

Native stake and liquid staking tokens are separate position types with different custody, transfer and redemption workflows. This lifecycle page follows the native StakedSui path.

SIP-6 made native stake objects composable, which supports liquid staking protocols that issue transferable tokens and manage redemption through their own contracts rather than the native wallet’s ordinary StakedSui exit flow for each position. Established examples include Aftermath Finance’s afSUI, Haedal’s haSUI and Volo’s voloSUI. Those assets follow protocol-specific exchange, liquidity and redemption rules. Selling a liquid staking token transfers the associated economic position, while native unstaking consumes a validator-bound StakedSui object through the Sui system package.

The distinction matters when checking a balance. A symbol such as afSUI or haSUI is a fungible token issued by another protocol; FungibleStakedSui is a Sui Framework object tied to one native validator pool. Neither should be treated as the same record as an ordinary StakedSui object. Choose the exit workflow that matches the object or token actually held.

Epoch mechanics behind the lifecycle

Epoch mechanics are the protocol schedule that coordinates validator sets, reward deposits and every staking-pool exchange-rate update. Sui’s original subsidy reserve held 1,000,000,000 SUI, began distribution in epoch 2 and paid 1000000 SUI per epoch for the first 10 epochs. Each later 10-epoch tranche reduced that per-epoch subsidy by 10%. Computation fees provide the other reward source, while the storage fund changes how rewards are divided between delegators and validators. Those inputs meet at each boundary, where pending additions activate and pool rates advance.