dApp Staking v3 - Tier Assignemt & Reward Distribution Algorithm Assignment Proposal

[Dinonard]

Overview

For better visibility of the proposed solution: https://forum.astar.network/t/dapp-staking-v3-tier-algorithm-adjustment-proosal/6411

Once dApp staking v3 performance is revised, this is one of the items that can be considered as an improvement approach.

NOTE: This issue ticket does not mean this approach will be adopted.

Solution Idea

It's important to keep the PoV size limited when describing the tier, so we shouldn't replace u8 with a larger footprint value (e.g. u16 or u32).

To implement the proposed ladder system between the tiers, we can do discretization of the space between the two tiers. E.g. we can split the space between tier 3 and tier 4 into 10 or 20 discrete steps. That way we can keep using u8, and will only need to do logic change and tier value adjustment in the existing reward storage.

E.g. if we have a situation where:

• Tier 4 threshold is 1000 ASTR, and reward is 10 ASTR per era
• Tier 3 threshold is 15000 ASTR, and reward is 30 ASTR per era
• There are 10 discrete steps between the two tiers, meaning threshold_step = (15000 - 1000) / 10 and reward_step = (30 - 10) / 10
  • If dApp has [1000, 1000 + threshold_step> staked, it will earn 10 ASTR
  • if dApp has [1000 + threshold_step, 1000 + threshold_step * 2> staked, it will earn 10 + reward_step ASTR
  • if dApp has [1000 + threshold_step * 9, 1000 + threshold_step * 10> staked, it will earn 10 + reward_step * 9 ASTR

In general, number of steps should be kept low. The idea is not to achieve full linearity between the tiers, but to reward significant increases in the TVL of a dApp. So something between 5 to 10 steps between tiers should be more than enough.

Implementation Details

• Number of steps should be configurable per runtime
• We can rely on the existing dApp staking migration pallet to execute the migration logic
• In case steps are configured to be zero, it should be backwards compatible

• make a model/analysis to showcase inflation change based on current TVL on Astar, depending on the number of steps between the tiers
• propose implementation solution
• modify & expand UTs where needed
• implement tier value migration logic to adjust already calculated tiers
• prepare Github issue for the UI team explaining how they need to change their calculation logic for the frontend
• update official documentation & forum discussions

[ermalkaleci]

• reward_step = (30 - 10) / 2

@Dinonard I guess this needs to be reward_step = (30 - 10) / 10?

[Dinonard]

• reward_step = (30 - 10) / 2

@Dinonard I guess this needs to be reward_step = (30 - 10) / 10?

Good catch, I'll fix it.