It seems there are certain scenarios where the portal doesn't correctly construct the batch call for dApp staking.
One such example is of an account YJWhHaMqUerTV3wsjQdfC9ybEBvGCoDUFqP8sVX3me8ti3v.
This is the account state at block 6409946 (Astar):
What we can notice is:
account has ~702,510.26 ASTR
amount locked in dApp staking is 562,000.00 ASTR + 2x70,250.00 ASTR = 702,500.00 ASTR
this state is ok ✅
However, in the next block, a batch call is emitted to lock more funds: LINK
This should fail, but due to a bug in runtime it passes, and additional 70,250.00 ASTR are locked, resulting in user having
more locked funds than they have ASTR. This will be fixed in runtime within day(s).
However, frontend shouldn't even construct such batch.
Best case, the user should be allowed to re-lock their unlocking funds.
Describe the bug
It seems there are certain scenarios where the portal doesn't correctly construct the batch call for dApp staking.
One such example is of an account
YJWhHaMqUerTV3wsjQdfC9ybEBvGCoDUFqP8sVX3me8ti3v. This is the account state at block 6409946 (Astar):What we can notice is:
However, in the next block, a batch call is emitted to lock more funds: LINK
This should fail, but due to a bug in runtime it passes, and additional 70,250.00 ASTR are locked, resulting in user having more locked funds than they have ASTR. This will be fixed in runtime within day(s).
However, frontend shouldn't even construct such batch. Best case, the user should be allowed to re-lock their unlocking funds.