Solana Staking What Is It Rewards

On the Solana network, many different people and entities run a program on specialized computers known as a validator. Validators play a key role in maintaining and securing the Solana blockchain. Validators are responsible for processing new incoming transactions on the network, as well as for voting on and appending new blocks to the blockchain.

As different validators around the globe may receive different pieces of information at different times, it is essential that the network is able to come to agreement about which transactions and data are continually added to the blockchain. The strategy by which the validators and the entire network come to this understanding is known as the consensus mechanism, and is a core challenge to edifice a successful decentralized blockchain network. Many different projects have attempted various solutions on how to accomplish consensus in a fast and cost-efficient manner.

The Solana network uses a Proof-of-Pale consensus mechanism (often abbreviated to PoS). Every validator on the network has an opportunity to participate in consensus past casting votes for which blocks they believe should be added to the blockchain, thereby confirming any valid transactions contained in those particular blocks. However, not all validator’s votes are weighted equally.

Validator’s consensus votes are stake-weighted, meaning the more stake an private validator has, the more influence that ane validator has in determining the effect of the consensus voting. Similarly, validators with less pale have less weight in determining the vote result, and validators with no stake cannot influence the event of a consensus vote.

Staking is the process by which a SOL token holder (such every bit someone who purchased SOL tokens on an exchange) assigns some or all of their tokens to a particular validator or validators, which helps increase those validators’ voting weight. Assigning your tokens to add to a validator’due south stake-weight is known equally “delegating” your tokens. Delegating your tokens to a validator does Not give the validator ownership or command over your tokens. At all times, you still control all your staked tokens that y’all may have chosen to delegate.

By staking tokens with a validator or validators, the token holder indicates a degree of trust in the validator they chose to delegate to. As validators amass larger amounts of stake delegations from different token holders, this acts as “proof” to the network that the validator’s consensus votes are trustworthy, and their votes are therefore weighted proportionally to the amount of pale the validator has attracted. By weighing the collective votes from all validators against the proportion of pale that has been delegated to them, the network reaches consensus by this Proof of Stake.

In an open and decentralized network similar Solana, anyone tin can run a validator if they choose. A malicious validator or other bad actor could attempt to attack the network or to submit incorrect or fraudulent transactions for their own proceeds. Because of the Proof-of-Stake consensus mechanism described to a higher place, a single entity interim alone in this fraudulent manner would need to attract some amount of stake before any of their proposed activities would be weighed in the consensus vote.

As more token holders cull to pale their SOL tokens to dissimilar validators beyond the network, and the total amount of stake on the network increases, it becomes increasingly difficult for even a coordinated and well-funded aggressor to amass enough pale to single-handedly alter the outcome of a consensus vote for their own benefit.

In brusk, the more pale that is delegated to many different validators across the network, the more safe and secure the network becomes for all of its users.

Additionally, token holders who choose to stake their tokens and assist secure the network in doing so, are eligible to receive staking rewards once they have delegated their tokens to 1 or more than validators. More than details on staking rewards are found below.

On many Proof-of-Stake networks, there exists a mechanism known as “slashing”. Slashing is any process by which some portion of stake delegated to a validator is destroyed as a punitive measure for malicious actions undertaken by the validator.

This machinery incentivizes validators not to undertake such actions, as less stake delegated to a validator ways that validator then accrues fewer rewards. Being slashed can also be seen equally a reputational risk for retaining current or attracting potential future stake.

Slashing also poses a run a risk to token holders who could potentially lose some of their tokens if they have delegated to a validator which gets slashed. The presence of slashing could incentivize token holders to only delegate their tokens to validators they feel are reputable, and not to delegate all their tokens to a single or small number of validators.

On Solana, slashing is not automated. If an assailant causes the network to halt, they can be slashed upon network restart. For more information, please check out our docs.

Anyone who holds SOL can stake their tokens at any time.

To stake SOL tokens, y’all must employ a wallet that supports staking. Not all wallets support staking at this time. SolFlare.com is one user-friendly wallet that supports staking. Check out the official docs for a list of wallets which support staking.

SOL tokens in your wallet must first be moved into a stake account. You can create as many stake accounts as you lot like, and deposit as much or equally lilliputian SOL into each stake account equally y’all want. Each new pale account has a unique address, and a single wallet can manage or “qualify” many dissimilar stake accounts. Bank check out our docs on stake account structure for more details.

In order to earn staking rewards (if aggrandizement is enabled on Mainnet Beta), the tokens in a stake account must be delegated to a validator. A unmarried pale account tin can only be delegated to a single validator at any fourth dimension, so if you want to delegate to different validators you volition need to split your tokens between multiple stake accounts.

Aye. Some people may have received a stake account with locked up tokens from the Solana Foundation that was distributed in commutation for services. Tokens in stake accounts with a lockup may not be withdrawn to another wallet accost before the lockup expires, only they may still be delegated to a validator to potentially earn staking rewards during this time. Rewards earned on locked tokens are deposited back into the locked stake account.

When y’all beginning create a pale account, you specify how many SOL tokens y’all want to fund it with, and these tokens are withdrawn from your main wallet account and deposited into the new stake account.

Tokens tin can also be transferred into a pre-existing stake business relationship at any time, by using your wallet’due south Transfer or Transport feature and providing the address of your stake account. If yous transfer tokens into a stake account that is already delegated, these new tokens volition non automatically exist delegated.

If you accept a delegated pale account and yous wish to increase your delegation to a detail validator, the all-time do is to create a new stake account with the additional amount of stake and delegate that account to the aforementioned validator.

Example: Increasing the stake delegated to a single validator

• User has a wallet with m SOL residual.
• User uses the wallet interface to create a stake account with 100 SOL, then delegates the tokens in the stake business relationship to Validator A.
• Wallet remainder is at present 900 SOL and the wallet also controls a stake account with a balance of 100 SOL.
• The pale account shows in the wallet interface and on the Explorer that it is “Activating”. In one case it is “Active”, the staked tokens are eligible for rewards. See Timing Considerations for more details.
• Later, the user wants to increment their delegation to Validator A, and so uses the wallet interface to create a 2nd stake account with l SOL, so delegates the tokens in the new pale business relationship to Validator A.
• Wallet balance is now 850 SOL and the wallet also controls 2 pale accounts with 100 and 50 SOL, respectively, each delegated to Validator A.

If yous transfer tokens into a stake account that is already delegated, these new tokens will not automatically be delegated. In order to go these new tokens also delegated and earning rewards, you would need to un-delegate the entire business relationship, and so re-delegate the same account. As un-delegating and re-delegating tin take several days to accept effect, your original stake would not exist earning rewards during this transition period.

Therefore, we recommend only transferring SOL into a pale account when it is kickoff created or otherwise not delegated.

Tokens can only be withdrawn from a stake account when they are not currently delegated. When a stake business relationship is first un-delegated, it is considered “deactivating” or “cooling downwardly”. Tokens may not be withdrawn from the business relationship until some or all of them accept finished deactivating and are considered “inactive” and therefore no longer earning any potential staking rewards. For details on how long this transition period may accept, please see Timing Considerations.

Once the tokens in a stake account are inactive, they can be withdrawn back to your master wallet accost or to some other address immediately.

Instance: Withdrawing all tokens from a stake account

• User has a wallet with a remainder of 900 SOL, and a single pale account with 100 SOL delegated to a validator.
• User uses the wallet interface to Deactivate their stake delegation. The pale business relationship shows in the wallet interface and on the Explorer that it is “Deactivating”. Once it is “Inactive” or “Not Delegated”, the staked tokens stop earning rewards and tin be withdrawn. Encounter Timing Considerations for more details.
• User can utilise the wallet interface to withdraw their all tokens back into their main wallet business relationship. The wallet residue at present shows 1,000 SOL and the stake account is closed.

If y’all want to reduce the amount of delegated stake assigned to a given validator without deactivating your entire balance (and therefore missing any potential rewards during the delegation downtime), you can Divide an existing stake account into two accounts, and undelegate one, while leaving the other account delegated and continuously eligible for rewards.

Case: Reducing the delegation staked to a given validator

• User has a wallet with a residual of 800 SOL, and a single pale business relationship with 200 SOL delegated to a validator.
• User wants to reduce the amount of stake delegated to the validator by 100 SOL.
• Utilize the wallet interface to “Split” the stake business relationship, and specifies 100 SOL as the amount to split up.
• At that place are at present two stake accounts, each with 100 SOL which are each delegated to the same validator.
• User can and then employ the wallet interface to Deactivate one of their stake delegations. The stake account shows in the wallet interface and on the Explorer that it is “Deactivating”. Once it is “Inactive” or “Not Delegated”, the staked tokens stop earning rewards and can be withdrawn. See Timing Considerations for more details.
• Once the account is Inactive, the user tin can then choose to delegate the business relationship to a different validator, or to withdraw the tokens back into the primary wallet, or to further split the inactive pale business relationship and consul to multiple dissimilar validators.

Tokens in a stake account with a lockup may non be withdrawn until the lockup expires, regardless of the delegation state of that account. One time the lockup expires, undelegated tokens may be withdrawn immediately. There is no action required by the account holder to specifically unlock the account.

When you consul or un-delegate a pale business relationship, the tokens exercise non change state immediately. Newly delegated tokens are considered “activating” or “warming up”, and are not eligible to earn rewards until they are fully activated. Newly united nations-delegated tokens are considered “deactivating” or “cooling down” and are not able to exist withdrawn until deactivated.

The Solana protocol only allows pale tokens to finish changing state at the first of a new epoch. An epoch is approximately 2 days long. Apply
solana epoch-info
to come across details of the current epoch.

If you consul tokens in a pale account in the centre of an epoch, the tokens volition appear in your wallet as “activating” until the current epoch ends, at which bespeak they will exist active and eligible to earn rewards. Whether y’all delegate your stake tokens nearly the starting time of the current epoch, or nigh the stop of the current epoch does non touch on when the tokens volition become active, which is merely at the next epoch boundary. The same logic applies to un-delegating or deactivating a delegated stake business relationship. Deactivating tokens cannot be withdrawn until they have finished deactivating at the epoch purlieus.

There is a limit to how much full pale can change state in a single epoch across the unabridged Solana network. No more than 25% of the total active stake on the network can be activated or deactivated in a single epoch. In a scenario where more than 25% of the full active accept on the network is being activated in a unmarried epoch, a portion of all activating/deactivating stake upwards to the global 25% limit, will finish changing state at the offset epoch boundary. The remaining stake would stay equally “activating” or “deactivating” for at least 1 more epoch, until the next epoch boundary.

If a stake activation takes multiple epochs, the portion of stake that becomes fully active at the commencement epoch purlieus is eligible for rewards, while the remaining portion that is notwithstanding activating for an boosted epoch is not withal eligible for rewards.

Similarly, if a stake deactivation takes multiple epochs, the portion of stake that becomes fully inactive at the first epoch purlieus becomes able to exist withdrawn, while the remaining portion is nonetheless deactivating for an boosted epoch, at which point it can then be withdrawn.

All pale accounts on Solana (and all accounts of any variety) can exist viewed on Solana’s network explorer, found hither:

Solana Explorer

Re-create and paste the pale account address of involvement in the main search bar of the explorer to run across details of the account, including its activation/deactivation/delegation status, current balance, and the address of the stake account’s regime, which would usually be the same as your wallet’south main accost.

Depending on which wallet solution you use to manage your stake accounts, this same information may be visible by logging in to your wallet and viewing your stake accounts.

Staking rewards are computed and issued once per epoch. An epoch is approximately 2 days long. Rewards accrued in a given epoch are issued to all validators and delegators in the start block of the post-obit epoch. Staking yield is presented every bit an annualized figure, though this number varies each epoch as the inflation rate and total active stake continually change. Staking yield and the full aggrandizement design is detailed in our official docs here.

Estimates of Staking Yield, given various models of the fraction of total SOL staked, tin can be explored here:

Staking Yield Models

To judge the amount of SOL a delegator can expect to see in a single epoch in a single stake business relationship:

Validator Uptime is defined past a validator’due south consensus voting behavior. For each time a validator votes on a block that is ultimately appended to the blockchain, that validator earns ane Vote Credit.

When rewards are tallied at the stop of the epoch, all the stake-weighted vote credits earned by all the validators are used to determine the total amount of SOL that is issued to each particular validator and their delegators.

Validators accuse a fee on inflationary rewards earned by the stake accounts that are delegated to them, in substitution for their services in securing the blockchain and processing transactions. This fee is known as the commission rate. Each time rewards are issued, the committee is deposited in the validator’due south business relationship and the remaining rewards are deposited in all of the stake accounts that are delegated to that validator, proportionally to the corporeality of actively delegated stake in each business relationship. Validator commission and staking rewards are always issued simultaneously.

Rewards are issued once per epoch and are deposited into the pale account that earned them. Pale rewards are automatically re-delegated as active stake.

If the rewards due to a validator or one of their stakes is less than ane lamport for a given epoch, reward issuance is deferred until the next epoch in which both would receive at least ane lamport.

The details of the originally proposed aggrandizement schedule are discussed here. The specific parameters that determine the inflation schedule are:

1. Initial Inflation Charge per unit: viii %
2. Dis-inflation Rate: −fifteen%
3. Long-term Inflation Rate: 1.5%

The above parameters are defined as:

• Initial Inflation Rate: The starting Aggrandizement Rate for when inflation is first enabled. The token issuance charge per unit can only decrease from this amount
• Dis-aggrandizement Rate: The annualized charge per unit at which the Inflation Rate is reduced
• Long-term Aggrandizement Rate: The stable, long-term Inflation Rate to exist expected

Note that the inflation charge per unit will not be the same equally the staking yield (i.eastward. the interest earned past staking tokens). See below for a discussion of staking yield.

100% of the inflationary issuances are proposed to be delivered to delegated stake accounts and validators.

A proposal for a community driven governance process to enable inflation has been proposed here. The timeline of expected events can be seen at the bottom of that post.

Staking yield comes from inflationary issuances being distributed beyond delegated staking accounts and validator vote accounts per the validator committee rate. Due to this design, the staking yield is to be primarily a office of the fraction of SOL that is staked on the network. A detailed discussion of the design and its bear on on staking yield can be found hither:

Aggrandizement Design Overview

The amount of full SOL that will be staked is unknown, so we can but estimate the exact staking yields. Below, we prove staking yields over time segmented past unlike values of the per centum of staked SOL that might exist observed on the network (betwixt 60-ninety%). The inflation schedule parameters are set as described above.

A simple interactive dashboard is provided here, in which different % of staked SOL can be selected to meet the impact on prospective staking yields.

Please note that this is an idealized Staked Yield as it neglects validator uptime impact on rewards, validator commissions, potential yield throttling and potential slashing incidents. It additionally ignores that % of Staked SOL is dynamic by blueprint, i.east. it is expected that the % of staked SOL changes over fourth dimension thus impacting the staking yield over time. Information technology is only presented to be used equally a rough gauge for expected staking yields.

As the number of nodes on Mainnet Beta continues to abound, the Solana Foundation is committed to continuing to delegate 100M SOL to be split evenly among qualified validators. In order to increment growth to upward to 500 individual nodes, which volition help increment the security of the network, qualified validators volition receive Foundation delegations of upwards to 200,000 SOL.

• Requirements for Baseline stake delegation: 25,000 SOL

  • Commission of 10% or lower
  • Not-delinquency
  • “Qualified participant” as defined in the terms of the Participation Agreement

• Requirements for Bonus stake delegation: 175,000 SOL

  • Meeting all requirements for Baseline stake delegation
  • Node has produced a valid block in 75% or more than of its scheduled leader slots in the previous epoch