Submitted by gesha17
https://github.com/code-423n4/2024-12-secondswap/blob/main/contracts/SecondSwap_StepVesting.sol#L298
Some token owners may create StepVesting contracts with very large numbers of steps, to simulate a continous vesting. This can lead to two edge cases for the releaseRate of a beneficiary:
This is only a real concern with tokens that have very low decimals, which are in scope as per the competition page.
Protocol function is impacted as beneficiaries will not get their liquidity released correctly, so their funds will essentially be temporarily locked.
Suppose a scenario where an issuer wants to continuosly release 90000 tokens over the period of 1 day and decides to set 50000 steps.
start time = 0
end time = 86400
numSteps = 50000
amount = 90000 tokens
Lets analyse how releaseRate will be calculated for the beneficiary:
https://github.com/code-423n4/2024-12-secondswap/blob/main/contracts/SecondSwap_StepVesting.sol#L298
stepDuration = 86400/50000 = 1
releaseRate = 90000/50000 = 1
So at step 49999, total vested is 49999 and at step 50000, the rest 40001 tokens get vested at step 50000 which creates a very uneven distribution.
Also, as we can see if the amount of tokens is less than the number of steps, the releaseRate will round down to 0.
Mitigation is non-trivial as it would require partially changing protocol design - instead of calculating release rate, calculate release amount based on how many steps are passed in the claimable() function.
calvinx (SecondSwap) commented:
Koolex (judge) commented:
gesha17 (warden) commented:
Koolex (judge) commented:
