You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
The text was updated successfully, but these errors were encountered: