-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In reward calculation, dust amount is left and stuck in the contract for every epoch #46
Comments
Lead: The remainders left inside the contract are not handled properly, But it doesn't lead to a large loss. |
heyy @0xmahdirostami
The max loss in every epoch could be in one month, loss could go up to |
The main token is FNX, which has a precision of 18, for the test I took the following values, certain extreme cases: user balance = 1e18 1e18 * 1e6/1_000_000e18 = 1 wei As you can see from this point, when the numbers are smaller, losses begin, and when the user has a share of less than 0.000001%, this is a dust, this is also true for all users with a minimum balance Also, the recommendation seems to be incorrect Rounding and loss of reward by the user occurs when their share is less than the accuracy of the token, so this is still dust |
In your given example , user balance is just 1 token and just 1 reward token is distributed in epoch. Do you really think this represents the actual case ? |
@Tri-pathi This was attached as a case study of how this works. We can also change the numbers, but the point will not change This case is far from reality and is as close as possible to a situation where this reward is lost. We can also state that the user's balance can be an order of magnitude smaller, but the rewards can be greater. 18 decimals balance * 6 decimals reward token / 18 decimals supply = 6 decimals reward amount So, the losses start when the token does not have sufficient decimals, but in practice it will still be dust Also, for example, an actual case will most likely look like this: User A balance: 100 FNX 100e18 * 1200e18/10_000_000e18 = 0.012e18 (all ok) Ok, let's reduce the amount of the user and rewards And now for a case similar to the one mentioned above: @Tri-pathi Please provide the numbers you used to determine the maximum loss case, Thanks |
Github username: --
Twitter username: --
Submission hash (on-chain): 0xe5a9b42a2793537a95cd2b51884dd64816b2eb94a7ec90beea86d0a93611761d
Severity: medium
Description:
Description
When rewards calculation happens, rewards accures with reward per epoch and the token's proportion of the total supply to determine the reward amount. Thus, every time, the remainder which is less than
supply
are left in the contractProof of Concept (PoC) File
Revised Code File (Optional)
The left amount of rewards should be added to next epoch or current epoch for distribution. This will motivate to current stakers to harvest rewards timely
Labeling this medium since higher the supply, higher rewards will be lost from each epoch
The text was updated successfully, but these errors were encountered: