Author: Sui Network
SUI Main Application
PoS: Used to participate in the delegated proof of stake mechanism
Gas mechanism: used to pay for network transactions and storage fees
Liquidity: Providing on-chain native liquidity in the Sui economy
Community governance: may affect the future governance of Sui
Staking Process
Q1: What is a staker?
Anyone with a Sui address can stake SUI by staking it to one or more validation nodes of their choice, including validation nodes or third-party SUI holders who stake SUI.
Q2: Where did the pledged SUI go?
Rest assured, they are safely locked in your address! Unlike existing liquidity staking solutions in other networks, where stakers need to hand over control of their staked tokens to a third-party liquidity staking smart contract. Sui allows SUI holders to stake their SUI directly to the validation nodes of their choice while retaining full control of their staked tokens. Staking tokens are protected by the Sui protocol layer and are not affected by vulnerabilities in third-party smart contracts.
Q3: What is a staking pool?
Each Sui validator maintains its own staking pool to track the amount staked and accumulate staking rewards. The validator pool operates with a time series of exchange rates calculated at each epoch boundary. These exchange rates determine the amount of SUI that each SUI staker in the past can withdraw in the future. Importantly, the exchange rate rises as more rewards are deposited into the staking pool, and the longer SUI is deposited in the staking pool, the more rewards are accumulated.
Each validator has a time series of exchange rates corresponding to its specific staking pool, stored on-chain within the staking pool object. From the perspective of a SUI staker, the value of their stake can be tracked through the following consensus.
SUI at E’ = (SUI deposited at E) * (Exchange rate at E’ / Exchange rate at E)
Conceptually, staking pools operate exactly the same way as liquidity pools. When SUI is deposited into a staking pool in epoch E, it is converted into liquidity tokens based on the exchange rate at epoch E. As the staking pool earns rewards, the exchange rate rises. In epoch E’, these liquidity tokens are worth more and can be converted into more SUI.
The only difference between a Sui staking pool and a typical liquidity pool is that in Sui, the liquidity token does not exist. Instead, a global exchange rate table is used to track calculations. One advantage of this design is that since all SUIs in a staking pool are identical, regardless of whether they were initially deposited as new stakes or as staking rewards, all SUIs are immediately considered staked, so rewards are compounded immediately.
The staking pool is a system-level smart contract (staking_pool.move) and is part of the Sui framework.
Q4: What stages has the development of SUI staking gone through?
Pledge v1: [Original design, deprecated]
This design was used in the second phase of the testnet, but has now been deprecated, with two major implementations removed:
Previously, the staking process was divided into two stages. First, after the staker deposited SUI, he immediately received a StakedSUI object containing the locked SUI. Second, at the end of the epoch, once the exchange rate of the staking pool was updated, the user received a Delegation object containing the user's pool token. The Delegation object must wait until the epoch is closed, because the exchange rate at the end of the epoch cannot be known in advance within the epoch, it depends on the amount of gas fees collected throughout the epoch. This approach requires a lot of transactions to be reconfigured at epoch boundaries, so the Delegation object has been removed in Staking v2 (see below).
Previously, when performing a stake withdrawal, the withdrawn stake entered the pending stake state and was processed after the epoch boundary was closed. The reason for this is that since the staking rewards for the current epoch are determined within the entire epoch, the exchange rate at the end of the epoch cannot be fully predicted while the epoch is still active. Therefore, this design requires waiting for the epoch to close before processing a withdrawal with an updated exchange rate. This is no longer the case, and withdrawals will be processed immediately with the exchange rate of the previous epoch.
Staking v2: [Current Mainnet Design]
The two main changes are:
Accounting for staking pools has been simplified. As before, when users stake SUI, these objects are wrapped into StakedSUI objects. However, staking pools no longer implement each user's relative ownership of the staking pool through Delegation objects. Instead, accounting is done directly through the timestamp of the StakedSUI object (determining the point in time when the deposit occurred) and the change in exchange rate between the deposit epoch and the withdrawal epoch. The data structure for each staking pool contains a time series of exchange rates for that pool. These exchange rates can be used to determine withdrawals for any staker in the pool.
Stake withdrawals are processed immediately based on the exchange rate of the previous epoch, without waiting for the current epoch to close. The withdrawal includes the original stake that the user deposited and all staking rewards accumulated until the previous epoch. The disadvantage of this method is that the staker will not receive their staking rewards during the epoch of the withdrawal. Until the epoch closes, since it is not known in advance how much staking rewards will have accumulated during the current epoch, it cannot be included in the withdrawal. Therefore, any user can withdraw their stake instantly and receive:
SUI withdrawn at E’ = (SUI deposited at E) * (Exchange rate at E’-1 / Exchange rate at E)
Staking v3: [Future Update]
This is a long-term solution that will eventually be pushed to mainnet.
The main challenge with the Staking v2 design is the inability to handle the unbonding (or cool-down) period, which is critical to network security. This is achieved by modifying how Sui handles withdrawal requests, breaking it into two steps:
In the first transaction, the pledger will submit a withdrawal request and get a WithdrawalReceipt. At this time, the pledger will not receive any SUI.
In the second transaction, once the scheduled unbonding period has passed, the staker can submit a WithdrawalReceipt and receive their SUI principal and accumulated rewards.
Importantly, in addition to enabling the unbonding period, this design also allows users to receive the full rewards they are due after withdrawing a WithdrawalReceipt, since the withdrawal must be made at the end of the epoch in which the withdrawal request was submitted. This design does not suffer from the challenges of staking v1 that caused very large reconfiguration transactions, because the WithdrawalReceipt object can be redeemed at any time (once the unbonding period ends) and does not rely on epoch boundaries.
Q5: When will my pledge deposit request take effect?
Once a pledge deposit request is submitted, it immediately enters the pending state in the pledge pool. Sui Wallet will reflect any pending pledge deposit requests for user accounts. However, pending pledge deposit requests will not take effect until the end of the epoch in which the request is made.
Q6: When will my request to release the pledge take effect?
Unstaking or withdrawal requests are processed immediately once received. Stakers will receive the SUI initially deposited plus all staking rewards accumulated up to the previous epoch boundary. In other words, they do not include staking rewards from the current epoch. See Staking v2 for more details on this implementation. Note that in the future, once Staking v3 is implemented, unstaking requests will not be processed immediately.
Q7: How to calculate the exchange rate of each validator pool?
The exchange rate for each validator pool is calculated at each epoch boundary as follows:
Exchange rate at E+1 = (1 + (Staking reward at E / Staking amount at E)) * (Exchange rate at E)
Importantly, the staking rewards earned by stakers during epoch E are a subset of the total staking rewards earned by the validator pool during that epoch. In other words, the total staking rewards earned by the validator pool can be broken down into three separate parts, depending on who earned them:
Staking Rewards = Stakeholder Rewards + Validator Commissions + Storage Fund Rewards
Regular SUI stakers only receive staker rewards. Meanwhile, validators receive commissions charged on these rewards (validator commissions) as well as rewards attributed to the storage fund.
The validator pool's exchange rate is updated only by the amount of staker rewards, in order to fully track the rewards earned by SUI stakers. However, this calculation method also enables Sui to track the rewards earned by validators by providing validator commissions and storage fund rewards to validators in the form of additional StakedSUI objects via the updated exchange rate.
Q8: How is the staking process for validators different than for third-party SUI holders?
The process is the same. A validator that stakes SUI together will follow the same process as any third-party SUI holders that stake together with that validator.
Q9: How is the staking reward calculation different for validators compared to SUI stakers?
In a given validator staking pool, all stakers receive the same proportion of rewards through the appreciation of the pool's exchange rate. In addition, since validators earn commissions and storage fund rewards on managing stakes, validators receive additional StakedSUI objects at the end of each epoch in proportion to these amounts.
Staking Rewards
Q1: Where do the staking rewards come from?
Staking rewards come from transaction gas fees earned within the current epoch and the staking allowance released at the end of the epoch.
Staking Reward = Staking Allowance + Gas Fee
The staking stipend is intended to subsidize the early stages of the network and is funded by 10% of the SUI. Once this allocation is exhausted, the entirety of the staking reward will be composed of gas fees collected through regular network operations.
Q2: Will staking rewards automatically compound?
Yes! Please refer to the answer to “Q3: What is a staking pool” above.
Q3: How many staking rewards will there be on the mainnet?
The staking reward consists of gas fees and staking allowance. The total amount distributed per epoch is determined as follows:
Staking allowance: The amount distributed each epoch is determined before the epoch starts according to a predetermined schedule.
Gas Fee: The amount per epoch depends on the total gas fee earned during the entire epoch. Each Sui transaction pays a gas fee based on two variables, the gas unit executed and the gas price:
Gas fee = gas price * gas unit
The total amount of gas fees collected corresponds to the sum of gas fees for all transactions processed within the epoch. Under normal market conditions, we expect the gas price for the vast majority of transactions to be equal to the reference gas price. In the future, Sui will introduce a congestion pricing mechanism so that when the network is congested, the gas price will be higher than the reference gas price, because users will actually pay tips to the validator nodes in exchange for priority.
Staking restrictions
Q1: Can I unstake part of my active validator node stake?
This is not supported. Each StakedSUI object's unstake is either all or none.
However, users can stake any number of SUI objects to any validator. Therefore, if they unstake a portion of their SUI objects from a validator, they can effectively unstake a portion of their SUI objects from the validator. Since StakedSUI objects can be split into multiple objects, a staker can always effectively unstake a portion of their SUI objects if they first split a StakedSUI object into several objects and then unstake some of the objects.
Q2: What is the minimum staking amount for a single verification node?
The minimum stake amount is 1 SUI.
Q3: What is the relationship between the validation node’s stake and the voting rights in the consensus?
By convention, total voting power is always 10,000 regardless of the amount staked, so the quorum threshold is 6,667 (a 2/3 ratio). Each validator’s consensus voting power is proportional to its stake, with one exception: a single validator’s voting power is capped at 1,000 (10% of total voting power).
Q4: What is the maximum staking amount for a single validation node?
There is no limit. However, the voting power of a single validator is capped at 10% in consensus. If a validator accumulates more than 10% of the total stake, the voting power of that validator will remain at 10% and the rest will be dispersed among the rest of the validator set.
Similarly, a validator's share of staking rewards will also use the same 10% cap to calculate the amount of governance stake (see Staking Rewards Calculation). In other words, once a validator has accumulated more than 10% of the total stake, the SUI rewards per stake will begin to decline as the staking pool can no longer increase the amount of staking rewards it receives.
Staking Rewards Calculation
Warm reminder: There are too many formulas, so those who are interested are advised to read them carefully.
Validation Node
Q1: What is the reference gas price and when do validators need to participate?
Sui is designed so that gas prices remain stable and predictable for end users during regular network operations. This is achieved by setting the network’s reference gas price by validating nodes at the beginning of each epoch.
Operationally, this is accomplished through a “gas price survey”, which proceeds as follows:
During each epoch E, each validator submits what they believe to be the best reference gas price for the next epoch E+1.
At the epoch boundary, when Sui transitions from epoch E to epoch E+1, the network observes the gas price in the set of validators and uses the 2/3 vote weighted as the reference gas price for the next epoch. Therefore, the reference gas price for each epoch is constant throughout the epoch and is only updated when the epoch changes.
The process of submitting a quote for a gas price survey is very simple. Each validator has an object containing their reference gas price. If a validator wishes to change their quote, then they simply update the value in this object. Validators can delegate the ability to set gas price quotes to other accounts by transferring their operational capability object.
Q2: What are the statistical rules and when do verification nodes need to participate?
Sui is designed to encourage and enforce community monitoring of the validator set. This is achieved through statistical rules, where each validator monitors and scores every other validator to ensure that everyone is operating efficiently and in the best interest of the network. Those validators that do not comply will be fined and their staking rewards will be cut.
The protocol specifies that global statistical rule scores are only calculated at epoch boundaries, and therefore relies on active monitoring by validators to change their scores when they detect changes in the behavior of other validators. In general, the default option for statistical rules should always be a score of 1 for all validators, and only change to 0 when it is determined that the operation is improper. In practice, statistical rules consist of a set of objects owned by each validator, which default to a score of 1, so validators will usually passively update objects corresponding to the scores of other validators only when needed. Similar to submitting gas price quotes, validators can also delegate their power to participate in statistical rules to other accounts by transferring their operation capability objects.
Q3: What are the criteria for assigning 0 points to the verification node in the statistical rules?
Statistical rules should be enforced through social equilibrium. The set of validators should actively monitor themselves, and if a validator is clearly underperforming, the other validators should give it a score of 0 and cut its rewards. In the future, as the Sui network matures, we expect the community to launch a public dashboard to track the performance of validators and can be used as a signal to further understand the operations of validators.
Q4: Is it possible to give multiple verification nodes a score of 0?
Yes. Each validator will score every other validator using statistical rules, and there is no limit on how many 0 or 1 scores each validator can submit.
