Contact Us
Hire Team Stars
Hire Team Reality
Hire Dream Team
Audit Application Form
Lido Liquid Staking for Polkadot Upgrades to the Uncapped Second Stage
Author: MixBytes team
The Lido on Polkadot First Stage was launched on May 31st, 2022 and is performing great. We are thrilled to share that we are ready to move to the Second Stage.
Second Stage parameters
- Uncapped stake and number of validator nodes
- Dynamic nomination model to increase annualized reward rate, or Annual Percentage Rate (APR) even more
- Launch of decentralized reward oracles
- Multisigs to control contract updates
What we've accomplished
Staking Rewards Performance
* — As of July 12th, 2022
Lido on Polkadot scheme
Decentralization efforts
We have increased the security against malicious actions from one party by setting up decentralized oracles and multisigs.
What do our oracles do?
Decentralized reward oracles were released with 3/4 consensus on rewards and slashing amounts. If an oracle reports a more than 5% reward or slashing amount change compared to the previous result it will be ignored and the team will receive a report. Oracles are run independently by Lido, Moonbeam, and MixBytes.
Multisigs to control contract updates (MixBytes + Lido)
We have decentralized decision-making on smart contract updates approvals to several parties. There is a Gnosis Safe Multisig fork in the Moonbeam key provided for each relevant role in Lido and MixBytes.
Single superuser role was removed while implementing multisig, hence leaving no chance to manipulate the contract without all the respective parties participation.
Single superuser role was removed while implementing multisig, hence leaving no chance to manipulate the contract without all the respective parties participation.
Dynamic nomination model
One of Lido's goals is to reach the maximum possible APR. The main problem here is the validators choice. We have a strategy based on validator performance uncensored public data.
General principles
Transparency
Validator choice algorithm should be not just only transparent itself, but also based on public and provable data for each era. Era is a period of time during which there is a specific set of active validators.
Here is the data we gather and calculate for each validator and era:
Gathered data is aggregated and used to build several metrics for different time periods:
Then the scoring model considers dynamical changes of validators' performance, e.g.:
Here is the data we gather and calculate for each validator and era:
- Era points
- APR
- Stake amount
- Nominators list
- Slashing
- Payout rate
Gathered data is aggregated and used to build several metrics for different time periods:
- Operational: last block
- Short-term: ~1 week
- Mid-term: ~1 month
- Long-term: ~6 months
Then the scoring model considers dynamical changes of validators' performance, e.g.:
- Operational data lets us detect oversubscribing, fees increase and slashing.
- Short-term data will show us if some relatively good validator in the long-term goes down or starts to lack in performance.
- Mid- and long-term data will hedge us from choosing validators who show good performance in the short-term but might be unstable in the long run.
APR maximization
APR maximization mechanics are based on validator scores described above. Lido will renominate validators as short-term parameters changed, so that we are up to date with new scores each week.
According to our short-term and long-term simulations and also according to the rules of the Phragmén algorithm we nominate 3 validators from each ledger.
Nominating less than 3 validators leads to the risk of nominating a validator not elected to the active set. Being in an active set means that a validator has been elected to produce blocks at this era: https://wiki.polkadot.network/docs/learn-nominator
And not producing blocks means you will not earn any rewards for that era: https://wiki.polkadot.network/docs/learn-staking-faq#nominated-validators-not-in-the-active-set
Having more than three validators leads to lower average APR in the available validator list left.
The next thing that we consider in choosing nominations amount on each validator is era points randomness. According to our simulation result, if we renominate validators every 7 days, then fewer nominated validators on each ledger leads to higher APR.
According to our short-term and long-term simulations and also according to the rules of the Phragmén algorithm we nominate 3 validators from each ledger.
Nominating less than 3 validators leads to the risk of nominating a validator not elected to the active set. Being in an active set means that a validator has been elected to produce blocks at this era: https://wiki.polkadot.network/docs/learn-nominator
And not producing blocks means you will not earn any rewards for that era: https://wiki.polkadot.network/docs/learn-staking-faq#nominated-validators-not-in-the-active-set
Having more than three validators leads to lower average APR in the available validator list left.
The next thing that we consider in choosing nominations amount on each validator is era points randomness. According to our simulation result, if we renominate validators every 7 days, then fewer nominated validators on each ledger leads to higher APR.
Algorithm for selecting validators
1. Filter out only validators open to the nomination.
2. Change nomination for ledgers immediately if the validator received a slash, increased commission, is not in the active set, validator calls kick for our nominator, or validator is kicked. We also have team notifications on each renomination case for manual review if needed.
3. For every era for each validator calculate APR for a week, month, year using the following equation:
2. Change nomination for ledgers immediately if the validator received a slash, increased commission, is not in the active set, validator calls kick for our nominator, or validator is kicked. We also have team notifications on each renomination case for manual review if needed.
3. For every era for each validator calculate APR for a week, month, year using the following equation:
where eraRange - specific era range (e.g. for week eraRange = 28);
era[i].commission - validator commission for i-th era;
era[i].rewards - validator rewards for i-th era;
era[i].otherStake - validator nominated stake for i-th era;
erasPerYear - eras amount in year.
4. Calculate validator activity ratio (e.g. if a validator was in active set in 8 eras for the last 16 eras, then its activity ratio is 50%).
5. Calculate average era points for each validator for each eraRange.
6. Calculate aggregated metric for each validator:
metric = (aprWeek + 3 ∗ aprMonth + aprYear) ∗
(2 ∗ activityWeek + activityMonth + activityYear) / 100 - 10¹⁸ ∗ sumSlashing,
where apr = metric mentioned in (1) per week, month, year
activity = metric mentioned in (2) per week, month, year
sumSlashing = cumulative slashing that validator received for all time
7. Determine best validators according to the aggregated metric;
8. Select top N * 3 validators for nomination, where N - ledgers amount;
9. For ledger[i] nominate validator[i], validator[i + N], validator[i + 2 * N];
10. Create a proposal for renomination in multisig.
era[i].commission - validator commission for i-th era;
era[i].rewards - validator rewards for i-th era;
era[i].otherStake - validator nominated stake for i-th era;
erasPerYear - eras amount in year.
4. Calculate validator activity ratio (e.g. if a validator was in active set in 8 eras for the last 16 eras, then its activity ratio is 50%).
5. Calculate average era points for each validator for each eraRange.
6. Calculate aggregated metric for each validator:
metric = (aprWeek + 3 ∗ aprMonth + aprYear) ∗
(2 ∗ activityWeek + activityMonth + activityYear) / 100 - 10¹⁸ ∗ sumSlashing,
where apr = metric mentioned in (1) per week, month, year
activity = metric mentioned in (2) per week, month, year
sumSlashing = cumulative slashing that validator received for all time
7. Determine best validators according to the aggregated metric;
8. Select top N * 3 validators for nomination, where N - ledgers amount;
9. For ledger[i] nominate validator[i], validator[i + N], validator[i + 2 * N];
10. Create a proposal for renomination in multisig.
Slashing hedging
Validators in the Polkadot relay chain might be slashed due to different reasons, like unavailability or double signing. Lido should minimize that risk despite slashing occurring rarely.
Our hedging strategy is based on stake diversification. That means we distribute pooled stake to several nominators, or staking ledgers. We won't choose a validator that once was slashed.
The amount of staking ledgers changes proportionally to pooled stake. Current total staked amount in the Polkadot network is ~ 625 MDOT and active validators set consist of 297 validators → maximal ledger stake ~ 2 MDOT. This means if the ledger has more than 2 MDOT in stake, then it starts to underperform. Considering slashing should be hedged at least at 50%, that amount may be too high if overall stake is less than 2 MDOT. We now use a dynamic optimal total stake on one ledger.
That approach allows us to minimize slashing risk, e.g. let's assume that we have few ledgers with the same stake and there are no intersections between nominated validators across them so if one of the ledgers gets slashed then rewards from other ledgers will minimize slashed losses.
For example, in one era we have 5 active ledgers with an active stake of 500,000 DOT and one of the ledgers nominates to the validator, which was slashed in the current era. According to our current APR = 16% we will receive as rewards 500,000 * 4 * 0.16 / 365 ~ 877 DOT. And as for one ledger let's assume that the nominated validator goes offline, thus causing a 1% unresponsiveness slash to their nominators then 500,000 * 0.01 = 5,000 DOT will be slashed. In this case, era losses will be 5,000 - 877 ~ 4,123 DOT. If we use only one ledger, then losses will be 500,000 * 5 * 0.01 = 25,000 DOT.
Our hedging strategy is based on stake diversification. That means we distribute pooled stake to several nominators, or staking ledgers. We won't choose a validator that once was slashed.
The amount of staking ledgers changes proportionally to pooled stake. Current total staked amount in the Polkadot network is ~ 625 MDOT and active validators set consist of 297 validators → maximal ledger stake ~ 2 MDOT. This means if the ledger has more than 2 MDOT in stake, then it starts to underperform. Considering slashing should be hedged at least at 50%, that amount may be too high if overall stake is less than 2 MDOT. We now use a dynamic optimal total stake on one ledger.
That approach allows us to minimize slashing risk, e.g. let's assume that we have few ledgers with the same stake and there are no intersections between nominated validators across them so if one of the ledgers gets slashed then rewards from other ledgers will minimize slashed losses.
For example, in one era we have 5 active ledgers with an active stake of 500,000 DOT and one of the ledgers nominates to the validator, which was slashed in the current era. According to our current APR = 16% we will receive as rewards 500,000 * 4 * 0.16 / 365 ~ 877 DOT. And as for one ledger let's assume that the nominated validator goes offline, thus causing a 1% unresponsiveness slash to their nominators then 500,000 * 0.01 = 5,000 DOT will be slashed. In this case, era losses will be 5,000 - 877 ~ 4,123 DOT. If we use only one ledger, then losses will be 500,000 * 5 * 0.01 = 25,000 DOT.
Case studies
- Validator shows very good performance for the last week, but it works only for 2 weeks already, so our algorithm will not choose this validator, because it doesn't have month and year history yet.
- Validator showed average performance last week, but for the last 3 months it had very good APR, then our algorithm will choose this validator.
- Validator generated a very high APR as a result of the last month, but it was already slashed once any time before. In this case the algorithm will not choose this validator because of slashing risks.
- Validator shows great performance but is being elected to the active set only once a week. The algorithm will not choose this validator, because its activity is very low, which means low APR in the long term.
- Who is MixBytes?
- DisclaimerThe information contained in this Website is for educational and informational purposes only and shall not be understood or construed as financial or investment advice.
Other posts