Author: Sui Network

SUI Main Uses

• PoS: Used for participating in the proof of stake mechanism
• Gas Mechanism: Used for paying network transaction and storage fees
• Liquidity: Provides on-chain native liquidity in the Sui economy
• Community Governance: Could influence the future governance of Sui

Staking Process

Q1: What is a staker?

Anyone with a Sui address can stake SUI to one or more validator nodes of their choice, including validator nodes staking SUI or third-party SUI holders.

Q2: Where does the staked SUI go?

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

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 staked SUI can be tracked through the following consensus.

SUI at time E’ = (SUI staked at time E) * (Exchange rate at time E’ / Exchange rate at time E)

In concept, the operation of the staking pool is identical to that of a liquidity pool. When SUI is staked in the staking pool at epoch E, it is converted into liquidity tokens based on the exchange rate at epoch E. As the staking pool receives rewards, the exchange rate increases. At epoch E’, the value of these liquidity tokens is higher and can be converted into more SUI.

The staking pool differs from a typical liquidity pool in that there are no liquidity tokens in Sui. Instead, a global exchange rate table is used for tracking calculations. One advantage of this design is that all SUI in the staking pool, whether initially staked or deposited as staking rewards, are immediately considered staked, allowing for immediate compounding of rewards.

The staking pool is a system-level smart contract (staking_pool.move) and is part of the Sui framework.

Q4: What are the stages of SUI staking development?

Staking v1: [Original design, deprecated]

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

• Previously, the staking process was divided into two stages. First, after staking SUI, stakers immediately received a StakedSUI object containing the locked SUI. Second, at the end of the epoch, once the staking pool's exchange rate was updated, users received a Delegation object containing the user 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 predicted within the epoch, depending on the amount of gas fees collected throughout the entire epoch. This approach required a significant reconfiguration of transactions at epoch boundaries, so the Delegation object was removed in staking v2 (see below).
• Previously, when executing a staking withdrawal, the withdrawn staking entered a pending staking state and was processed after the epoch boundary closed. This was done because the staking rewards for the current epoch were determined over the entire epoch, so the exchange rate at the end of the epoch could not be fully predicted while the epoch was still active. This situation no longer exists, and withdrawals are processed immediately based on the exchange rate of the previous epoch.

Staking v2: [Current mainnet design]

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 uses Delegation objects to represent each user's relative ownership of the staking pool. Instead, the accounting is directly based on the change in exchange rates between the timestamps of StakedSUI objects (determining the time of deposit) and the epochs of deposit and withdrawal. The data structure of each staking pool contains a time series of exchange rates. These rates can be used to determine the withdrawal situation for any staker in that pool.
• Staking withdrawals are processed immediately based on the exchange rate of the previous epoch, without waiting for the current epoch to close. Withdrawals include the original staked amount and all staking rewards accumulated up to the end of the previous epoch. The drawback of this approach is that stakers do not receive their staking rewards for the current epoch until the epoch closes. Therefore, any user can immediately withdraw their staking and receive:

SUI withdrawn at time E’ = (SUI staked 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 the inability to handle an unbonding (or cooling-off) period, which is crucial for network security. This is achieved by modifying how Sui processes withdrawal requests, splitting 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 scheduled unbonding period has passed, the staker can submit the WithdrawalReceipt and receive their staked SUI principal and accumulated rewards.

Importantly, in addition to enabling the unbonding period, this design also allows users to receive all their due rewards after redeeming the WithdrawalReceipt, as it must be redeemed at the end of the epoch. This design does not encounter the challenge of significant reconfiguration transactions that occurred in staking v1, as the WithdrawalReceipt object can be redeemed at any time (once the unbonding period ends) and is not dependent on epoch boundaries.

Q5: When does my staking deposit request take effect?

Once a 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, pending staking deposit requests will only take effect at the end of the epoch in which the request is made.

Q6: When does my unstaking request take effect?

Once an unstaking or withdrawal request is received, it is processed immediately. Stakers will receive the originally staked SUI and all staking rewards accumulated up to the end of the previous epoch. In other words, they do not include staking rewards for the current epoch. Note that in the future, once staking v3 is implemented, unstaking 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 / Staked amount at time E)) * (Exchange rate at time E)

Importantly, the staking rewards received by stakers during epoch E are a subset of the total staking rewards received by the validator node pool during that epoch. In other words, the total staking rewards received by the validator node pool can be divided into three independent parts, depending on who receives 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 commission) and rewards allocated to the storage fund.

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

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

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

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

In a given validator node staking pool, all stakers receive the same proportion of rewards based on the appreciation of the pool through the exchange rate. Additionally, since validator nodes earn commissions and storage fund rewards on managing staking, validator nodes receive additional StakedSUI objects at the end of each epoch based on the amounts of these rewards.

Staking Rewards

Q1: Where do staking rewards come from?

Staking rewards come from transaction gas fees collected within the current epoch and staking subsidies released at the end of the epoch.

Staking rewards = Staking subsidies + gas fees

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

Q2: Do staking rewards automatically compound?

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

Q3: How much staking rewards 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 before the epoch begins according to a predetermined schedule.
• Gas fees: The amount for each epoch depends on the total gas fees collected throughout the entire epoch. Each Sui transaction pays gas fees based on two variables, the units of gas executed and the gas price:

Gas Fee = Gas Price * Gas Units

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

Staking Limits

Q1: Can I partially unstake from an active validator node staking?

This is not supported. Unstaking for each StakedSUI object is either all or nothing.

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

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

The minimum staking amount is 1 SUI.

Q3: What is the relationship between validator node staking and voting power in the consensus?

As a convention, regardless of the amount staked, the total voting power is always 10,000, so the statutory threshold is 6,667 (2/3 ratio). The consensus voting power of each validator node is proportional to its staking, with one exception: the maximum voting power for a single validator node is 1,000 (10% of the total voting power).

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

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

Similarly, the staking rewards share for a validator node will also be calculated with the same 10% cap on managing the staked amount (see Staking Rewards Calculation). In other words, once a validator node accumulates more than 10% of the total staking, the staking rewards for each staked SUI will start to decrease, as the staking pool no longer increases the amount of staking rewards they receive.

Staking Rewards Calculation

Friendly reminder: There are many formulas, it is recommended to carefully read if interested.

Validator Nodes

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

Sui's design 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 their proposed 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 in the validator node set and calculates the next epoch's reference gas price as a 2/3 weighted vote. Therefore, the reference gas price for each epoch remains constant throughout the entire epoch and is only updated at the epoch change.

The process of submitting quotes for the gas price survey is very simple. Each validator node has an object containing their proposed 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?

Sui's design 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 that everyone operates efficiently, considering the network's best interests. Non-compliant validator nodes will be fined, and their staking rewards will be reduced.

The protocol specifies that global statistical rule scores are only calculated at epoch boundaries, so it relies on active monitoring by validator nodes to change their scores when detecting changes in the behavior of other validator nodes. In general, the default setting for statistical rules should always be a score of 1 for all validator nodes, and it should only be changed to 0 when improper behavior 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 the power to participate in statistical rules to other accounts by transferring their operational capability object.

Q3: What are the criteria for assigning 0 points to a validator node 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 assign 0 points and reduce its rewards. In the future, as the Sui network matures, we expect the community to initiate a public dashboard to track the performance of validator nodes, which can be used as further signals to understand validator node operations.

Q4: Can multiple validator nodes be assigned 0 points?

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

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。