Closed Dinonard closed 2 weeks ago
reward_step = (30 - 10) / 2
@Dinonard I guess this needs to be reward_step = (30 - 10) / 10
?
reward_step = (30 - 10) / 2
@Dinonard I guess this needs to be
reward_step = (30 - 10) / 10
?
Good catch, I'll fix it.
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
oru32
).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 is10 ASTR
per eraTier 3
threshold is 15000 ASTR, and reward is30 ASTR
per erathreshold_step = (15000 - 1000) / 10
andreward_step = (30 - 10) / 10
[1000, 1000 + threshold_step>
staked, it will earn10 ASTR
[1000 + threshold_step, 1000 + threshold_step * 2>
staked, it will earn10 + reward_step
ASTR[1000 + threshold_step * 9, 1000 + threshold_step * 10>
staked, it will earn10 + reward_step * 9
ASTRIn 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