Hardcore knowledge about SUI staking that you may not know

Author: Sui Network

Main Uses of SUI

• PoS: Used to participate in the delegated proof-of-stake mechanism
• Gas Mechanism: Used to pay for network transaction and storage fees
• Liquidity: Provides on-chain native liquidity in the Sui economy
• Community Governance: Has the potential to influence the future governance of Sui

Staking Process

Q1: What is a staker?

Anyone with a Sui address can stake by delegating SUI to one or more validator nodes of their choice. Stakers include validator nodes that stake SUI or third-party SUI holders.

Q2: Where does the staked SUI go?

Rest assured, they are securely locked in your address! Unlike existing liquid staking solutions in other networks, where stakers must transfer control of their staked tokens to a third-party liquid staking smart contract, Sui allows SUI holders to directly stake their SUI to the chosen validator nodes while retaining full control over their staked tokens. The staked 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 node maintains its own staking pool to track the amount staked and accumulate staking rewards. The validator node pool operates in conjunction with the exchange rate time series calculated at each epoch boundary. These exchange rates determine the amount of SUI that each past staker can withdraw in the future. Importantly, as more rewards are deposited into the staking pool, the exchange rate increases, and the longer SUI is deposited in the staking pool, the more rewards are accumulated.

Each validator node has an exchange rate time series corresponding to its specific staking pool, stored on-chain within the staking pool object. From the perspective of SUI stakers, the value of their stake can be tracked through the following consensus:

SUI at time E' = (SUI deposited at time E) * (exchange rate at time E' / exchange rate at time E)

Conceptually, the operation of the staking pool is identical to that of a liquidity pool. When SUI is deposited into the staking pool at 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 increases. At epoch E', the value of these liquidity tokens is higher and can be converted into more SUI.

The only difference between the Sui staking pool and a typical liquidity pool is that in Sui, liquidity tokens do not exist. Instead, a global exchange rate table is used for tracking calculations. One advantage of this design is that since all SUI in the staking pool are identical, regardless of whether they were initially deposited as new stakes or as staking rewards, all SUI are immediately considered staked, and 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 SUI staking gone through?

Staking v1: [Original design, deprecated]

This design was used in the second phase of the testnet but has now been deprecated, removing two major implementations:

• Previously, the staking process was divided into two phases. First, after the staker deposited SUI, they 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 tokens. The Delegation object had to wait until the epoch closed because the exchange rate at the end of the epoch could not be known in advance; it depended on the total amount of gas fees collected throughout the epoch. This approach required a large number of transactions to be reconfigured at the epoch boundary, so the Delegation object has been removed in Staking v2 (see below).
• Previously, when executing a staking withdrawal, the withdrawn stake entered a pending staking state and was processed after the epoch boundary closed. This was necessary because the staking rewards for the current epoch were determined throughout the epoch, making it impossible to fully predict the exchange rate at the end of the epoch while it was still active. Therefore, this design required waiting for the epoch to close before processing withdrawals with updated exchange rates. This situation no longer exists, and withdrawals will be processed immediately using the exchange rate from the previous epoch.

Staking v2: [Current mainnet design]

The two main changes are:

• The accounting of the staking pool has been simplified. As before, when users stake SUI, these objects are wrapped into StakedSUI objects. However, the staking pool no longer implements each user's relative ownership of the staking pool through Delegation objects. Instead, accounting is done directly through the timestamp of the StakedSUI object (which determines when the deposit occurred) and the changes in exchange rates between the deposit epoch and the withdrawal epoch. Each staking pool's data structure contains a time series of exchange rates for that pool. These exchange rates can be used to determine the withdrawal situation for any staker in that pool.
• Staking withdrawals will be processed immediately based on the exchange rate from the previous epoch, without waiting for the current epoch to close. Withdrawals include the original stake deposited by the user and all staking rewards accumulated up to the previous epoch boundary. The downside of this approach is that during the epoch from which the withdrawal is made, the staker will not receive their staking rewards. Until the epoch closes, it is impossible to know in advance how much staking reward will accumulate during the current epoch, so it cannot be included in the withdrawal. Therefore, any user can immediately withdraw their stake and receive:

SUI withdrawn at time E' = (SUI deposited at time E) * (exchange rate at time E'-1 / exchange rate at time E)

Staking v3: [Future update]

This is the long-term solution that will eventually be pushed to the mainnet.

The main challenge of the Staking v2 design is its inability to handle unbinding (or cooling) periods, which are crucial for network security. This is achieved by modifying how Sui handles withdrawal requests, dividing it into two steps:

• In the first transaction, the staker submits a withdrawal request and receives a WithdrawalReceipt. At this point, the staker does not receive any SUI.
• In the second transaction, once the designated unbinding period has passed, the staker can submit the WithdrawalReceipt and receive their principal SUI and accumulated rewards.

Importantly, in addition to enabling the unbinding period, this design allows users to receive all their due rewards after retrieving the WithdrawalReceipt, as the withdrawal must occur at the end of the epoch in which the withdrawal request was submitted. This design does not encounter the challenges of Staking v1, which caused a large number of reconfiguration transactions, because the WithdrawalReceipt object can be redeemed at any time (once the unbinding period ends) and does not rely on epoch boundaries.

Q5: When does my staking deposit request take effect?

Once the staking deposit request is submitted, it immediately enters a pending state in the staking pool. The Sui wallet will reflect any pending staking deposit requests in the user's account. However, the pending staking deposit request will only take effect at the end of the epoch in which the request was made.

Q6: When does my unbonding request take effect?

Unbonding or withdrawal requests will be processed immediately upon receipt. Stakers will receive the originally deposited SUI as well as all staking rewards accumulated up to the previous epoch boundary. In other words, they do not include the staking rewards of the current epoch. For more details on this implementation, please refer to Staking v2. Note that in the future, once Staking v3 is implemented, unbonding requests will not be processed immediately.

Q7: How is the exchange rate for each validator pool calculated?

The exchange rate for each validator node pool is calculated at each epoch boundary as follows:

Exchange rate at time E+1 = (1 + (staking rewards at time E / staking amount at time E)) * (exchange rate at time E)

Importantly, the staking rewards that stakers receive during epoch E are a subset of the total staking rewards earned by the validator node pool during that epoch. In other words, the total staking rewards earned by the validator node pool can be divided into three independent parts, depending on who earned them:

Staking rewards = Staker rewards + Validator node commission + Storage fund rewards

Regular SUI stakers only receive staker rewards. Meanwhile, validator nodes receive commissions on these rewards (validator node commissions) as well as rewards belonging to the storage fund.

The exchange rate of the validator node pool is updated solely based on the amount of staker rewards to fully track the rewards earned by SUI stakers. However, this calculation method also allows Sui to provide validator node commissions and storage fund rewards to validator nodes in the form of additional StakedSUI objects through updated exchange rates, thereby tracking the rewards earned by validator nodes.

Q8: How does the staking process differ for validator nodes compared to third-party SUI holders?

The process is the same. Validator nodes staking SUI will follow the same process as any third-party SUI holders staking with that validator node.

Q9: How does the calculation of staking rewards for validator nodes differ from that of SUI stakers?

In a given validator node staking pool, all stakers receive rewards in proportion to the appreciation of the pool's exchange rate. Additionally, since validator nodes earn commissions and storage fund rewards for managing stakes, they receive additional StakedSUI objects at the end of each epoch in proportion to these amounts.

Staking Rewards

Q1: Where do staking rewards come from?

Staking rewards come from the gas fees earned during the current epoch and the staking subsidies released at the end of the epoch.

Staking rewards = Staking subsidies + gas fees

Staking subsidies are intended to subsidize the early stages of the network, funded by 10% of SUI. Once this allocation is exhausted, the overall staking rewards will consist of gas fees collected through regular network operations.

Q2: Do staking rewards compound automatically?

Yes! Please refer to the answer to "Q3: What is a staking pool" above.

Q3: How much staking reward will there be on the mainnet?

Staking rewards consist of gas fees and staking subsidies. The total amount distributed for each epoch is determined as follows:

• Staking subsidies: The amount distributed for each epoch is determined according to a predetermined schedule before the epoch begins.
• Gas fees: The amount for each epoch depends on the total gas fees earned throughout the epoch. Each Sui transaction pays gas fees based on two variables: the number of gas units executed and the gas price:

Gas fees = gas price * gas units

The total amount of gas fees collected corresponds to the sum of gas fees for all transactions processed during the epoch. Under normal market conditions, we expect the gas price for the vast majority of transactions to equal the reference gas price. In the future, Sui will introduce a congestion pricing mechanism so that during network congestion, gas prices will be higher than the reference gas price, as users will effectively tip validator nodes for priority.

Staking Limitations

Q1: Can I unbond a portion of my stake from an active validator node?

This is not supported. Unbonding of each StakedSUI object must be either all or none.

However, users can stake any number of SUI objects to any validator node. Therefore, if they unbond a portion of SUI objects from one validator node, they can effectively unbond a portion of their stake from that validator node. Since StakedSUI objects can be split into multiple objects, if a staker first splits a StakedSUI object into several objects and then unbonds some of those objects, the staker can effectively unbond a portion of their stake.

Q2: What is the minimum staking amount for a single validator node?

The minimum staking amount is 1 SUI.

Q3: How does the staking of validator nodes relate to voting power in consensus?

By convention, regardless of the amount staked, the total voting power is always 10,000, so the quorum threshold is 6,667 (2/3 ratio). The consensus voting power of each validator node is proportional to its stake, but there is one exception: the voting power cap for a single validator node is set at 1,000 (10% of total voting power).

Q4: What is the maximum staking amount for a single validator node?

There is no limit. However, in consensus, the voting power of a single validator node is capped at 10%. If a validator node accumulates more than 10% of the total stake, its voting power will remain at 10%, and the remaining voting power will be distributed among the rest of the validator node set.

Similarly, the share of staking rewards for validator nodes will also be calculated using the same 10% cap to determine the amount of stake managed (see Staking Rewards Calculation). In other words, once a validator node accumulates more than 10% of the total stake, the SUI rewards for each stake will begin to decrease, as the staking pool will no longer increase the amount of staking rewards it receives.

Staking Rewards Calculation

Friendly reminder: There are many formulas; those interested are advised to read carefully.

Validator Nodes

Q1: What is the reference gas price, and when do validator nodes need to participate?

The design of Sui allows end users to maintain stable and predictable gas prices during regular network operations. This is achieved by having validator nodes set the reference gas price for the network at the beginning of each epoch.

Operationally, this is done through a "gas price survey," with the following steps:

• During each epoch E, each validator node 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 prices from the set of validator nodes and will set the reference gas price for the next epoch based on a 2/3 weighted vote. Therefore, the reference gas price for each epoch remains constant throughout the epoch and is only updated when the epoch changes.

The process of submitting gas price survey quotes is very simple. Each validator node has an object containing their reference gas price. If a validator node wishes to change their quote, they simply update the value in that object. Validator nodes 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 validator nodes need to participate?

The design of Sui aims to encourage and enforce community monitoring of the validator node set. This is achieved through statistical rules, where each validator node monitors and scores every other validator node to ensure everyone operates efficiently, considering the best interests of the network. Non-compliant validator nodes will be penalized, and their staking rewards will be reduced.

The protocol specifies that global statistical rule scores are only calculated at epoch boundaries, relying on the active monitoring of validator nodes to change their scores when detecting changes in the behavior of other validator nodes. Generally, the default option for statistical rules should always be a score of 1 for all validator nodes, and only changed to 0 when misconduct is determined. In practice, the statistical rules consist of a set of objects owned by each validator node, with default scores of 1, so validator nodes typically passively update the objects corresponding to their scores with other validator nodes only when necessary. Similar to submitting gas price quotes, validator nodes can also delegate their participation in statistical rules to other accounts by transferring their operational capability object.

Q3: On what basis is a validator node assigned a score of 0 in the statistical rules?

Statistical rules should be implemented through social equilibrium. The validator node set should actively monitor itself, and if a validator node is clearly underperforming, other validator nodes should score that validator node with 0 and reduce its rewards. In the future, as the Sui network matures, we expect the community to launch public dashboards to track the performance of validator nodes, which can serve as signals for further understanding validator node operations.

Q4: Can multiple validator nodes be assigned a score of 0?

Yes. Through statistical rules, each validator node scores every other validator node, with no limit on how many 0 or 1 scores each validator node can submit.