Ensure the security of your smart contracts

Lido Liquid Staking for Kusama Upgrades to the Uncapped Second Stage

Author: MixBytes team
The First Stage was launched on February 18th, 2022 and is performing nice and steady. We are excited to announce 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
Kusama delegation

14.6%* APR;
Kusama Network;
stakingrewards.com/earn/kusama/
Lido KSM staking

>24%* APR;
Moonriver Network;
kusama.lido.fi
Karura

19.9%* APY
Karura Network;
apps.karura.network/lksm
* — As of April 19th, 2022
Development — bug fixes and optimizations
TL;DR (for more details see Github):

    1. We have our own RelayEncoder implemented and ready for cases when Moonbeam or Moonriver can't upgrade it as fast as we need for uninterrupted XCM work.

    2. Withdrawal smart contract Fast track fixed. That means deposited funds go immediately to withdrawal smart contract in case ledgers must return some funds from Relay Chain to parachain.

    3. Function for XCM call for transferring funds from Relay Chain to parachain was updated.

    4. Withdrawal smart contract incorrect roundings bug fixed.

    5. Ledger renomination changed to batchable execution.

    6. The bytecode size of core smart contracts was reduced.
    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 30% 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, Moonriver, 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 Moonriver 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.
    How our dynamic nomination model works
    Abstract
    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: support.polkadot.network/support/solutions/articles/65000168050-what-is-an-era-. 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 this era (link). And not producing blocks means you will not earn any rewards for that era (link).

    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:
    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 last 16 eras, then its activity ratio is 50%).

    5. Calculate average era points for validator for 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 Kusama relay chain might be slashed due to different reasons starting from unavailability to double signing. Lido should minimize that risk despite slashing occurring rarely.

    Our hedging strategy is based on stake diversification, which 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. We use optimal total stake on one ledger equal to 5,000 KSM. Kusama market cap = 12,000,000 KSM, current staked amount = 43% of market cap → 12,000,000 * 0.43 = 5,160,000 KSM, active validators set consist of 1,000 validators → optimal ledger stake 5,160,000 / 1000 ~ 5,000 KSM. This means if the ledger has more than 5,000 KSM in stake, then it starts to underperform. Therefore, if Lido's total stake is greater than 20,000 but less than 25,000 we will use 5 ledgers.

    That approach allows us to minimize slashing risk, e.g. let's assume that we have 5 ledgers with the same stake and there are no intersections between nominated validators across them so if one of the ledgers gets slashed rewards from other ledgers will cover/minimize slashed losses.

    For example, in one era we have 5 active ledgers with an active stake of 4,500 KSM and one of the ledgers nominates to the validator, which was slashed in the current era. According to our current APR = 25% we will receive as rewards 4,500 * 4 * 0.25 / 365 = 12.3 KSM. And as for one ledger let's assume that the nominated validator goes offline, thus causing a 1% unresponsiveness slash to their nominators then 4,500 * 0.01 = 45 KSM will be slashed. In this case, era losses will be 45 - 12.3 = 32.7 KSM. If we use only one ledger, then losses will be 4,500 * 5 * 0.01 = 225 KSM.
    Case studies
    a. 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.

    b. Validator showed average performance last week, but for the last 3 months it had very good APR, then our algorithm will choose this validator.

    c. 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.

    d. 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.

    Validators that passed the selection process during the first stage of deployment for review: link.
    Disclaimer
    The 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