Introduction

Staking is a widely used method for earning yield on cryptocurrencies and plays a vital role in securing Proof of Stake (PoS) blockchains. In the PoS model, validators are incentivised to help maintain the blockchain’s integrity and ensure its continuous operation through staking rewards. These validators are responsible for processing transactions, maintaining consensus, and upholding both the security and decentralisation of the network.

The PoS consensus mechanism relies on the assumption that validators are economically motivated to behave honestly and follow the network’s protocol. This motivation comes from two main factors: the opportunity to earn a staking yield and the requirement to stake a substantial amount of cryptocurrency as collateral. Validators who act maliciously face penalties or risk losing their staked assets. Conversely, those who act in good faith are rewarded with staking yields, which serve as an ongoing incentive for honest participation. 

In our previous paper, Mysticeti C, we discussed the consensus mechanism underlying the Sui network, outlining the foundational principles of how the network operates and the goals it seeks to achieve. Validators run the consensus protocol, processing transactions, and ensure that the network stays live and functioning. We also introduced the Delegated Proof-of-Stake (DPoS) model employed by the protocol, highlighting its role in the validation process and its importance within Sui’s network architecture. Under this model, users delegate their SUI tokens to validators and, in return, receive staking rewards. These rewards are funded through two primary sources: gas fees paid by users for conducting transactions, and staking subsidies provided by the Sui Foundation.

In this paper, we shift our focus to the fundamentals of staking on Sui. We explore validator economics including how gas fees are generated and the current system of staking subsidies provided by the Sui Foundation. By doing so, we aim to give readers a more informed perspective on staking within the Sui ecosystem.

How does Staking work? 

Staking on SUI is performed through a Delegated Proof of Stake (DPoS) framework which we introduced in our previous paper. The way the stake is delegated between validators differs in the DPoS, compared to the classic PoS. This is because the users are able to delegate their tokens to their chosen validator, deciding who is given the most power in the consensus mechanism and running of the blockchain. 

Although incremental staking exists in traditional PoS models through third party node runners, DPoS has this built in since there is no minimum stake requirement for delegation. This encourages solo stakers to participate in the consensus mechanism and earn a staking yield by assigning their SUI tokens to the validators (Delegates) available. In SUI’s model, DPoS allows for an unlimited amount of tokens to be staked with each validator without the need to add new validators to the set. Of course this is within the constraints of the ten billion total supply of SUI tokens. This means the total validator set can remain unchanged, optimising network load, even as total staked SUI increases on the network.

These active validators in the network who can be assigned a stake are called delegates, and there are currently 113 validators active in the SUI network. The elected validator's share of the total amount of SUI tokens staked in that epoch determines the validator's proportional power in processing transactions, producing blocks, confirming transactions, and maintaining consensus. Each validator is assigned a stake-weighted vote in the consensus mechanism. Although the maximum stake per a validator is theoretically unlimited, the power of a single validator within the consensus mechanism is capped at 10% regardless of the amount of stake they have been delegated. 

A higher stake also results in a correspondingly higher stake-weighted reward, as validators receive a share of the fees generated in each epoch equal to their proportion of the total staked SUI. At baseline, a validator’s reward is directly proportional to its stake relative to the network’s total delegated tokens. However, additional protocol rules and adjustments can influence the final reward distribution, which we will cover later in this report.

Currently, the top validators with the most stake assigned and therefore the most voting power are Mysten-1 with 2.92% voting power, Mysten-2 at 2.85% and Figment at 2.75%. All other individual validators hold under 2% of the voting power. Mysten Labs who run both validators Mysten-1 and Mysten-2, are also associated with the SUI Foundation. Maxed out, these validators would have a combined voting power of 20% which alone isn't enough to meet the ⅔ assumption used throughout the protocol but does however increase the centralisation risk given that this would account to a fifth of all votes. Since these two validators already hold the highest stake, it suggests a strong level of trust from existing stakers. This serves as a positive signal for future delegators, who may be more likely to stake with them, creating a reinforcing cycle of trust and delegation which would push each validator closer to the 10% voting cap.

At the end of the epoch, the validators will receive the staking rewards from which they will take their commission and then distribute it amongst the stakers who delegated their stake with them. Therefore, stakers earn a reward for staking with honest and functioning validators. Additionally, validators who stray from the protocol are penalised which further incentivises stakers to delegate to validators accordingly. The stake is held for the complete epoch, which in Sui is 24-hour and can only be withdrawn or redelegated at the epoch boundaries. 

As validators operate, they can expect to organically grow their total stake, as positive performance metrics tend to attract additional delegation and staking rewards compound.  To further incentivise the operation of validators, the Sui Foundation has implemented a dedicated initiative in which it delegates the foundation owned SUI tokens to validators. Since a higher stake generally correlates with a larger stake-weighted reward, it boosts overall staking rewards and makes operating a validator more profitable. The initiative is particularly aimed at encouraging new validators to join the network. It is expected that validators will pass on a portion of these benefits to stakers, for example, by offering a lower commission rate. To be eligible for this, there is a stricter set of “best practices” a validator must adhere to, beyond the hardware, software and staking requirements outlined below. 

Sui’s staking functionality is inherently non-custodial, this means that the token holders remain the true owner of the SUI token despite delegating their stake to another validator. The non-custodial delegation of tokens is native to the network, it doesn't rely on third party work arounds for stakers to retain ownership of tokens when staked with another party’s validator. This is possible through the wrapping of tokens to create stake objects. Once a user has decided which validator to delegate their tokens to, that validator will wrap the SUI and assign the crucial information to the wrapped objects. This includes ownership rights, validator staking pool ID and which epoch the stake was activated in, which will be used to determine the staking rewards. The user submits a staking request transaction to the network via their chosen validator, to call the staking function which when processed, wraps the tokens to create a non-custodial stake object.

Validator Staking Pool

When a user stakes SUI, their tokens are converted into tokenised stake objects, using the exchange rate of the validator they've delegated to, at that specific epoch. Similarly, when a user decides to unstake their tokens, the SUI token stake object will be converted back to regular SUI at the updated exchange rate (minus validator commission). If the validator has accrued rewards, this would translate to a higher exchange rate and the user will receive more SUI back than they put in. There is a single global exchange rate table which tracks each validator's exchange rate and provides an accurate track record of how much each validator earns.

Becoming a Validator

The incentive to become a validator for SUI, alongside contributing to the running and decentralisation of the network, is to generate a commission free yield on your own staked SUI tokens and to generate a commission via other users delegating tokens to your validator. 

SUI is a permissionless network and therefore anyone who meets SUIs requirements, can request to join the network as a delegate validator. Hurdles to becoming a validator include having the appropriate hardware setup and moreover meeting the minimum stake requirements, both outlined in more detail below. If these requirements are met, users can run the validation SUI software on their machine to begin validating and contributing to the liveness of the network. 

From a hardware perspective, the SUI foundation suggests these as the minimum requirements to run a validator

• CPU: 24 physical cores (or 48 virtual cores)
• Memory: 128 GB
• Storage: 4 TB NVME
• Network: 1 Gbps

The full specification of technical details on how to run a validator node and essential hardware and software requirements for joining the SUI validator set can be read here.

The minimum staking requirement to apply to join the validator set stands at 30 million SUI, which is approximately $100 million USD as of April 2025. For active validators already running the protocol, the minimum stake to stay running drops down to 20 million SUI. If an active validators stake drops to between 15-20 million, they are given a grace period of 7 epochs (approximately 7 days) to rebuild their stake to 20million+ to remain running. However, if they drop below 15 million SUI, the validator will be removed at the next epoch boundary. This mechanism works in tandem with the DPoS model to boost the network security since active stakers are incentivised to move their stake away from malicious and faulty nodes, who do not accrue rewards, to honest nodes. This will reduce a malicious validator’s total stake and be more likely to drop under the minimum staking requirements and hence removed from the system. 

On SUI, penalties for malicious validators only affect staking rewards, not the initially staked SUI, in line with the Tallying rule explained in a later section. This means that although malicious validators will earn no staking rewards, they can still remain above the 20 million threshold and therefore part of the network, unless stakers actively withdraw their delegated stake. 

SUI Subsidies

Staking rewards come from gas fees generated, which are paid by the network users, along with SUI staking subsidies and are distributed amongst validators at the end of every epoch (approx 24 hours)

To accelerate network growth, the Sui Foundation supports validator participation through a dedicated subsidy initiative that delegates Foundation-owned SUI tokens to validators, making their operations more profitable. Receiving additional SUI is beneficial for validators, as a higher stake is directly correlated with greater staking rewards. These subsidies are designed to encourage the network's growth, especially in the early stages of the network, with the long-term goal of making the blockchain self-sustaining through gas fees alone. There are 1 billion SUI tokens dedicated to this staking initiative, which are set to be released periodically up till April 2030. The exact amount of SUI delegated to each validator isn't publicly specified, however, the Sui Foundation has set best practice guidelines linking maximum validator commission rates to subsidy amounts. For example, maximum 8% commission for 20 million SUI or more and 4% for 100 million SUI or more. This provides an insight into the potential scale of the current subsidy allocation. At present, applications for the SUI subsidy program are non-selective, although this policy may change in the future. 

Validators who are granted a subsidy are expected to adhere to a higher standard of  “best practices”. This includes running an additional node on SUI testnet, regularly relaying network monitoring metrics to the SUI foundation and upgrading their node software in  a “timely fashion”.

Validator performance and compliance with these best practices are reviewed monthly, based on data collected across epochs. Additionally, the SUI Delegation Program supports new validators who are waiting to join the active validator set, providing a staking subsidy to help them meet the minimum stake requirement.

Gas Fee Generation

Gas fees in the Sui ecosystem are generated by user activity. A key feature of Sui’s gas pricing mechanism is its distinction between computation fees and storage fees. Computational costs are dynamically adjusted on an epoch-by-epoch basis while storage costs remain fixed for longer periods. This is because storage prices fluctuate less, and storage fees are designed only to cover the baseline costs of long-term data storage per transaction, not to generate profit.

On the other hand, computational fees serve purposes beyond merely covering the computational resource costs. It also regulates network demand, with the idea that a higher cost results in less network traffic and vice versa and provides a profit, ensuring that running a validator node remains economically attractive. The calculation of the computational fee is explained in more detail later in the report. 

Validators on the Sui must store a comprehensive set of data that includes the live set of on-chain objects, finalised transaction records, and the most recent checkpoints. The object store contains all owned, shared, and immutable objects that are currently part of the Sui network’s state, while the transaction records maintain metadata about each confirmed transaction, including its input and output. Validators also store checkpoint data, which captures the digest of all transactions in a given time window, helping nodes synchronise with the global state efficiently. For operational efficiency and high performance, validators typically require around 200GB of high-speed NVMe disk space to keep this data readily accessible.

Storage fees on Sui are designed to compensate validators for the long-term cost of maintaining on-chain data. When users create or mutate objects, they pay a one-time storage fee that reflects the size of the object. These fees cover the perpetual storage of data. If an object is deleted, users will receive a partial rebate from the original storage fee which is currently set at 90%. 

When you modify an object, you effectively receive a 90% rebate on the original storage costs and then pay a new storage fee for the updated version. This means that if storage costs in the current epoch are lower than they were when your object was last modified, you can receive a storage rebate simply for modifying the object, even if the on-chain size remains unchanged. These storage fees can be updated through governance decisions to reflect real-world costs such as hardware and electricity expenses. 

The total gas fee pricing is broken down using this formula:

GasFees= (ComputationUnits×ComputationPrice) + (StorageUnits×StoragePrice)

The calculation of computational and storage fees can be broken down even further, which we explore later in the paper. As seen below, storage fees account for approximately ten times the amount of computation fees when calculating the total gas fees.

‍

Overall, the computation fees are determined by the complexity and processing required by the transaction, while storage fees reflect the cost of storing newly created or modified on-chain objects.

The Storage Fund 

Sui measures the storage requirements of a transaction in storage units, mapping each byte of on-chain data to 100 storage units. This linear mapping ensures that larger transactions consuming more storage resources pay proportionally higher fees. 

Storage fees are paid by users when executing a transaction. They are not paid directly to validators; instead, they are deposited into the storage fund. The storage fund effectively holds a stake in the network, allowing it to earn a stake-weighted proportion of the epoch’s total staking rewards, without actively being delegated to a validator. 

It is the storage fund’s “staking rewards" which are distributed to the validators to compensate for their storage costs for that epoch. The fund only ever distributes the staking rewards and never the principal, with exception of storage rebates, preserving the base capital indefinitely. Since storage costs are not intended to generate a profit for validators, any excess staking rewards left after distribution are reinvested back into the fund, creating a compounding effect which ensures that the storage fund is self-sustaining.

Computation fees

The computation fee is calculated using the formula:

ComputationFees = (ComputationUnits×ComputationPrice)

The total computation Fee can be broken down into the two elements, ComputationUnits determined by the amount of computation a transaction needs (transaction complexity) and ComputationPrice which factors in the the chains state and varies on an epoch-by-epoch basis, both explained in more detail below. 

Computation Units

Sui assigns computation units to transactions based on their processing and execution complexity. Transactions are categorised using a bucketing approach, grouping them into predefined computational ranges as seen below rather than a continuous scale. 

‍

A computational unit represents an abstract measure of the computational resources and complexity involved in executing a transaction; for instance, a simple transaction storing 10 bytes of data consumes 1,000 computational units, whereas a more complex transaction involving 120 bytes consumes 5,000 computational units, reflecting greater processing effort and resource utilisation. 

‍

All transactions are rounded up as determined by their bucket when calculating the fees. For example, a transaction determined to need 200 computation units will fall into the smallest bucket, covering transactions from 0 to 1,000 and therefore charged at 1,000 computation units. There are variable buckets covering computational units up to 5,000,000 units. Above this, transactions are rejected to ensure fair distribution of the network's computational power and overall maintain the network's stability by preventing excessive resource consumption.

‍

SUI uses this bucketing approach for two main reasons, to make user pricing more predictable and also to encourage developers to focus on large optimisations in their applications as opposed to "gas golfing" (fine-tuning every transaction for cost efficiency). 

Computation Price  

The ComputationPrice varies from one epoch to the next and is calculated by:

ComputationPrice[τ] = ReferencePrice + Tip[τ]

Reference Gas Price:

The ReferencePrice is determined through a gas price survey conducted at the start of the epoch. Once it is set, it remains constant for the entire epoch. In this survey, validators specify and submit their reservation price, the minimum gas fee at which a validator is willing to process a computational unit. They submit this reservation price using the request_set_gas_price function. Validators do not know each other’s reservation prices, as all submissions are made independently and simultaneously. 

Once all validators have submitted their reservation prices, the protocol aggregates these submissions to create the Reference Price. This is the network-wide gas price benchmark for that epoch and is calculated as the 2/3 stake-weighted percentile of all the reservation prices i.e. validators representing 2/3 of the total stake (which translates to ⅔ of the voting power) have a reservation price at or below the reference price. ⅔ is chosen to ensure enough validators are incentivised to participate in the epoch. Once determined, this reference gas price is then locked in for the entire epoch providing users with an indication of the minimum gas fee they can be expected to pay during that epoch.

The remaining validators who make up 1/3 of the total stake, who submitted reservation prices above the final reference price are still included in the validator set. Regardless of their reservation price, they are expected to participate during the epoch and process transactions at the reference price. However, they can receive reduced rewards in two ways. 

Firstly, referring back to our previous paper, SUI separates transactions into two main types, Single Owned Object Transactions and Shared Object Transactions. Single Owned Object Transactions are fast-path transactions and only require one single validator to process the transaction. In this case, the user, usually the wallet application, can choose which validator to send their transaction to. They will be more likely to choose validators with lower fees. Therefore, a lower reservation gas price, set at the individual validator level, is expected to translate to a higher transaction volume translating to higher fee generation rewards. Validators with high reservation prices will likely receive less flow.

Secondly, all validators are expected to participate in the validating of Shared Object Transactions which require multiple validators to reach consensus. However, the final reward distribution for each validator is calculated via the tallying and distribution rule detailed below. In this, consistently setting the reservation price much higher than the reference price is not looked at favourably and can limit the share of reward that a validator is assigned at the end of the epoch.

This process is designed to reflect consensus among the majority of validators, establishing a broadly agreed-upon price. However, in a decentralised network, this approach may unintentionally exclude smaller validating operations, who often face higher operational and break-even costs, resulting in lower profit margins from validation activities.

The Final Staking Reward

There are two rules to determine the final distribution of the computational staking rewards amongst the validators. The tallying rule, which penalises underperformance and dishonest behavior and the distribution rule, which rewards outperformance. These are explained further below. Validators who adhere to the protocol and honour the reference price, meeting expectations, receive their full stake rewards; validators who outperform receive boosted rewards whereas validators who underperform will receive a reduced or entirely slashed reward.  At the end of the epoch, the two rules are aggregated and a “global multiplier,” is assigned to each individual validator. This is calculated as the stake-weighted median of all the individual scores assigned to them by other validators. The staking rewards are distributed and the tallying and distribution rules are refreshed for the next epoch.  

Tallying rule- Peer-Evaluated Penalties 

The tallying rule uses peer evaluation to determine each validator's adherence to the protocol. This includes processing all transactions honestly as per the consensus mechanism, processing all shared object transactions above the reference price alongside single owned objects above their own reservation price. Additionally this rule penalises validators with “reputational damage” from consistently submitting reservation prices much higher than the epoch’s reference price and acting dishonestly in the tallying rule in previous epochs .

Validators are incentivised to be truthful, as their influence in the tallying rule scoring process is weighted by their reputation. Dishonest scoring, such as colluding to upvote or downvote specific validators can be detected through statistical anomalies. Those with a consistent record of honest and accurate evaluations gain more say in future assessments and those who vote dishonestly have a reduced say in future rounds of the tallying rule. Dishonest validators who submit inaccurate peer reviews suffer reputational damage, leading to lower scores in future epochs under the tallying rule. Since staking rewards are tied to these ratings, misreporting directly reduces their own earnings, as the system penalises inconsistent or manipulative behavior regardless of stake size. This mechanism relies on a game-theory approach ensuring that honesty is the most beneficial strategy, especially when most participants act truthfully. Furthermore, the transparency of on-chain score submissions allows for public auditing, reinforcing accountability through community oversight.

At the end of the epoch, the tallying rule evaluations are submitted and the protocol aggregates them to assign a performance metric to each validator. By default, all validators receive a tallying rule score of one, which may be lowered to a value between zero and one through peer evaluation. If a validator receives the minimum zero score from ⅔ or more of their peer validators as per the tallying rule, their computational rewards will be slashed entirely. Zero score can be submitted for extremely poor operational performance, malicious behavior and majorly straying away from the protocol.

Distribution rule- Outperformance bonus 

Conversely, the distribution rule in Sui allows validators to earn boosted rewards if they demonstrate outperformance. A validator is considered to have outperformed when it processes more transactions than the median of the validator set. This means they must process all transactions priced at or above the network-wide reference gas price and additionally process transactions that are priced below the reference price, but still above their own declared reservation price. Therefore only validators, whose initial reservation price is lower than the reference price are eligible for these boosted rewards. The performance multiplier is calculated from the median number of transactions processed by all validators, compared to the individual validator’s outperformance. 

Computation Price Tipping   

As part of the computation price calculation, users have the option to include a Tip to incentivise validators to prioritise their transactions. A similar priority fee tipping structure is used in other blockchains including ETH and XRP where transactions with higher extra gas fees are given processing priority. 

Conclusion

Sui's staking framework is reinforced by two key mechanisms, the tallying rule and the distribution rule, which play a critical role in promoting honest behavior and optimal validator performance. The tallying rule relies on honest peer evaluation to assess whether validators are acting in accordance with protocol expectations, penalising those who underperform and stray away from the protocol by reducing their rewards. Complementing this, the distribution rule rewards validators who outperform by processing more transactions than the median. Together, these mechanisms create a system of positive and negative incentives that encourage validators to behave honestly and maximise processing power.

‍

Sui's approach to staking, particularly through token wrapping into non-custodial stake objects, effectively addresses the custodial dilemma common in other blockchains by ensuring users retain full ownership of their tokens while delegating. Currently, Sui’s validator set remains relatively centralised with just 113 active validators, meaning the Sui Foundation's subsidy program has a moderate impact on overall network decentralisation, especially when compared to larger PoS networks like Solana with approximately 1,500 validators and Ethereum boasting around 900,000 validators. Nevertheless, the scheduled emission of subsidy tokens through 2030 aims specifically to incentivise new validators, thus promoting broader adoption and increased decentralisation over time. Ultimately, the long-term vision for Sui is to transition into a fully self-sustaining blockchain, entirely supported by user-generated gas fees without the need for ongoing subsidies.