dApp Staking - Too High Threshold Incident

Hello everyone,

this is just a quick info sharing regarding the ongoing incident related to dApp staking’s tier thresholds.


The issue doesn’t impact stakers, only dApps & developers.

As tier thresholds have increased beyond what was expected, some dApps have been pushed to lower tiers, even though for the current ASTR price they should have remained in the higher tier.


The issue is with the formula used to calculate the threshold adjustment. The formula from the report & implemented in the code is essentially correct, but it must account for the fact that thresholds saturate at some point (e.g. for Tier 1 it’s 200M ASTR). Docs here cover this, and will be updated after next docs release with corrections.

The slightly adjusted formula will always consider price changes compared to the base price using which the model in the report(s) was made. That way, we have a guarantee that regardless of the current thresholds and number of slots, the calculated thresholds will be as expected. But to avoid tech details, for those interested feel free to check the PR: Base native currency price for dApp Staking by Dinonard · Pull Request #1252 · AstarNetwork/Astar · GitHub

The problem wasn’t introduced in any recent updates, but was made visible after the oracle integration since this caused tier configuration to be recalculated on a daily basis.

Technical Fix

The fix has been made in the PR linked above, and will be deployed any time now. From the next era, thresholds will be back to values similar as before.

NOTE: If ASTR price goes further down, thresholds will continue to increase.

Missed Reward Compensation

We realize that projects have missed on some rewards due to this bug.
To remedy that, we’ll compensate them accordingly.

We’ll calculate what the tier assignments would have been if runtime was working correctly, and payout the reward difference to the projects.

The calculation will be done via script, which will simulate reward distribution if correct runtime logic was used. The script will be shared publicly.

We cannot specify exact dates yet, but it should be done in the next weeks, by the end of June.


Glad to see that quick action kicked in after the bug has been discovered and eventually the fix is already prepared!

1 Like

Hello Dino! Thanks for the quick action.

1 Like

Thank you for providing the information promptly.
I am trying to extract and graph on-chain data related to dAppStaking, so it is very important when analyzing that it is corrected to the expected correct logic and correct values.


It’s amazing to see the very good support Astar generates to the problems he faces, Great news, Dino!

1 Like

@Dino Thanks for the report!
I am relieved at the quick response.

One thing that concerns me is that the threshold was above the MAX Threshold yesterday. Was this also resolved with this update?


1 Like

The first number is not MAX but a starting value associated with base price of 0.05$.


Sorry, I am not sure what you mean.

Does that mean that a Tier 1 could exceed the 300M threshold?

I understand that a dynamic threshold range is specified regardless of the ASTR price.

1 Like

Yes, that’s correct.


Okay, thank you very much.

1 Like

Thanks to @ermal, script has already been implemented & results generated.
The code can be found here: GitHub - AstarNetwork/dapp-staking-reimbursement-script

We assume that people will be most interested in:

High level approach is described here: dApp Staking - Threshold Issue Reimbursement · Issue #1253 · AstarNetwork/Astar · GitHub

Feel free to check & verify the results.

We will execute the reimbursement call next week.


It’s great, thank you very much for coming to remind us. =)