The emergencyRevoke() function transfers unclaimed tokens back to the contract but does not update the categoryUsed mapping. This results in an inconsistency where the revoked tokens are still considered "used" within their category, effectively reducing the available allocation for future vesting schedules. Over time, this could lead to fewer tokens being allocated than intended.
The function emergencyRevoke(address beneficiary) is designed to revoke a vesting schedule and recover unclaimed tokens.
It deletes the vesting schedule and transfers the remaining tokens back to the contract.
However, it does not update the categoryUsed mapping, which tracks the total allocated tokens for each category.
As a result, even though the tokens are revoked and returned to the contract, they are still counted as "used" under their respective category, reducing the available allocation.
This could lead to a situation where the contract artificially prevents new vesting schedules from being created due to a perceived lack of available tokens, even though revoked tokens remain in the contract.
Incorrect Allocation Tracking: Revoked tokens are not deducted from categoryUsed, making it appear that more tokens are allocated than actually in use.
Potential Allocation Lockout: Future vesting schedules may be rejected due to apparent lack of available tokens in a category, even when tokens have been returned to the contract.
Manual Code Review
Modify emergencyRevoke() to subtract the unreleasedAmount from categoryUsed[category] when a vesting schedule is revoked.
This ensures that the revoked tokens are correctly deducted from the total used allocation.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.