locker.sol
Type | Severity | Location | Status |
Best Practice | Medium | lock, unLock, updateLockInfo | Resolved |
Description
The functions call external contracts, exposing themselves to potential reentrancy attacks.
IBEP20(currentLock.token).safeTransfer(currentLock.owner, releaseAmount);
Recommendation
Add a reentrancy guard or follow check-effect interactions pattern. check-effect interaction pattern is more recommended because reentrancy guard has limitations such us calling other function which has reentrancy guard protection will cause an error.
Type | Severity | Location | Status |
Best Practice | Medium | unLock | Resolved |
Description
Add a message to the
require
statement.Type | Severity | Location | Status |
Logical Issue | Medium | unLock | Resolved |
Description
Anyone can call unlock on behalf of the lock owner if they have the lock id.
Recommendation
Add a require statement that makes sure only the owner of the lock may call this function.
Type | Severity | Location | Status |
Logical Issue | High | unLock | Resolved |
Description
currentLock.claimed
should be subtracted from releaseAmount
. Otherwise, users can call the function twice in a row.Recommendation
Add a require statement that makes sure only the owner of the lock may call this function.
Type | Severity | Location | Status |
Volatile Code | Low | renounchOwnershipOfLock | Resolved |
Description
The
userLock
array's size is limitless. Iterating over an unbounded array may cause the transaction to hit the block gas limit.Recommendation
Add length restrictions on the number of iterations.
⚠️ The maximum iterations is limited by 100, however the team need to check that the code doesn't reach block gas limit if the userLock array size is 100.
Last modified 5mo ago