Comment on page
When you stake your SOL on Marinade, we delegate it to a number of high-performing validators using our delegation strategy. Here's how it works.
Our target is to provide the best staking yield for our users while making Solana more decentralized and censorship-resistant.
Delegation is split in 3 parts:
Every epoch, Marinade recalculates the performance score of each validator, collects MNDE votes and re-balances stake based on the results.
Every epoch, Marinade also looks at e.g. commission rugs and delinquent validators and moves the stake elsewhere as soon as possible.
The ethos is to be totally transparent and open to all validators.
We evaluate all active validators. The code computing score is available online and the results are published on-chain. You can view validator details, including their Marinade score, on Marinade's Validator Dashboard.
We collect a variety of data for each validator (vote credits, stake, commission, version changes, data center, block production, ...) and use this data to calculate the score. At least 10 epochs of data are required for a validator to be scored.
The score is a weighted average of 3 components averaged over past 10 epochs (~ 1 month). :
- APY performance ()
- Stake concentration ()
- Block production ()
Every component's values are min-max normalized to ensure the dimensions of the averaged values are the same.
Validators and their stakers receive inflation rewards based on validator's commission and vote credits earned. We are looking at the APY performance from staker's POV, therefore we adjust vote credits by commission:
. We call this metric "commission-adjusted credits" and use it as the main metric.
Some validators found a way to trick their stakers: By changing the commission to 100 % just before the rewards are calculated. We track this behaviour and protect mSOL holders by blacklisting such validators and by moving the stake elsewhere if applicable.
We want to incentivize validators to look for new data centers to help with Solana's decentralization and security - stake concentration at the level of a data center provider is, therefore, another component used in the scoring formula.
Validators are assigned "leader slots" in which they should produce blocks with processed transactions. If the validator does not produce the block in the slot assigned to it (e.g. validator is down, it has a poor network setup, it is a malicious actor who only votes but does not produce blocks on purpose), it harms the network as a whole, as the network is effectively down. (No transaction was processed at that moment).
This metric is very noisy for validators with only a few leader slots. Therefore if a validator has fewer than 200 leader slots assigned to it, we use the best value between their block production and cluster stake-weighted block production as this component's value for them.
Validators can receive votes from MNDE holders. Part of our TVL is distributed to eligible validators proportionally based on the votes.
Votes for a single validator are capped at 10 % of the total votes to manage a risk associated with delegating a lot of stake to a single validator. If there is an overflow of MNDE votes for an eligible validator, the overflow is split between other eligible validators proportionally based on their received votes.
If there are fewer than 10 eligible validators voted for (e.g. 8 validators, each reaching the cap), the overflow goes towards performance-based staking.
- Performance-based stake
- Validator is not blacklisted (running harmful mods, commission rugs)
- Validator runs up-to-date version of the node
- Validator's commission was ≤ 10 % in the past 10 epochs
- Minimum observed stake of the validator is at least 1000 SOL in the past 10 epochs
- Validator is in top 100 of eligible validators by score
- MNDE voted stake
- All rules for performance based stake apply with some changes (listed below)
- Minimum observed stake is at least 100 SOL (instead ot 1000 SOL)
- Validator's score is at least 90 % of the lowest scored validator picked by perfomance based rules (instead of being top 100)
Marinade will blacklist validators that are identified as harming the network. A validator can get blacklisted for:
- Slow voting (also called vote lagging)
- Commission rugs
- Failing to restart the node in the 36 hours following the cluster restart after a halt for at least 2 times
In order to be removed from the blacklist, the process is the following:
- 1.If a validator is blacklisted by Marinade's unjustly (e.g. validator's poor networking performance made us believe the validator was vote-lagging), the validator will be removed from the blacklist upon reviewing and approving the claim
- 2.If a validator, once rightfully blacklisted, chooses to reform their behavior and demonstrate compliance, they will be removed from the blacklist only after an observation period of at least 1 month.
- 3.Repeat offenders will be permanently blacklisted and prohibited from receiving Marinade stake. Rule 2 does not apply.
- 4.Validators blacklisted for commission rugs are blacklisted permanently. Rule 2 does not apply.
- The delegation strategy scoring runs once per epoch and is based on the past 10 finished epochs
- Every epoch, we also evaluate current epoch's metrics (e.g. if a validator bumped the commission over 10 %, has earned less than 50 % of cluster's stake-weighted average vote credits or is blacklisted, we instantly remove all the stake from such validator)
- At the end of each epoch our bot performs actions to move our stake distribution towards the desired state.
- Starting from Epoch 428, Marinade is now producing detailed validator reports that can be viewed in html or .csv. Validators can also generate these reports for any epoch and access the data themselves. Go to the Validator report homepage to access here.
- We use maxmind for geolocation services and data center identification
- We use Solana on-chain data to collect all metrics about validators apart from geolocation