QA Report #264
Labels
bug
Something isn't working
QA (Quality Assurance)
Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax
Table of Contents
[L-01] Unsafe casting may overflow
SafeMath and Solidity 0.8.* handles overflows for basic math operations but not for casting.
Consider using OpenZeppelin's SafeCast library to prevent unexpected overflows when casting from uint256 here:
[L-02] Check Effects Interactions pattern not respected
To avoid unexpected behavior in the future (be it for the solution or for a fork), it's recommended to always follow the CEI pattern.
Consider always moving the state-changes before the external calls.
Affected code:
[L-03] Deprecated safeApprove() function
Using this deprecated function can lead to unintended reverts and potentially the locking of funds. A deeper discussion on the deprecation of this function is in OZ issue #2219 (OpenZeppelin/openzeppelin-contracts#2219). The OpenZeppelin ERC20 safeApprove() function has been deprecated, as seen in the comments of the OpenZeppelin code.
As recommended by the OpenZeppelin comment, I suggest replacing safeApprove() with safeIncreaseAllowance() or safeDecreaseAllowance() instead:
[L-04] Missing address(0) checks
Affected code (from Slither):
[L-05] Unbounded loop on array can lead to DoS
As these arrays can grow quite large (only
push
operations, nopop
), the transaction's gas cost could exceed the block gas limit and make it impossible to call the impacted functions at all.Consider introducing a reasonable upper limit based on block gas limits and adding a method to remove elements in the array.
[L-06] Lack of event emission
According to Slither, these should emit events (indeed, state variables are being updated):
[L-07] Add a timelock to critical functions
It is a good practice to give time for users to react and adjust to critical changes. A timelock provides more guarantees and reduces the level of trust required, thus decreasing risk for users. It also indicates that the project is legitimate (less risk of a malicious owner making a sandwich attack on a user).
Consider adding a timelock to:
[N-01] Missing friendly revert strings
Here, a friendly message should exist for users to understand what went wrong:
[N-02] Unused named returns
While not consuming more gas with the Optimizer enabled: using both named returns and a return statement isn't necessary. Removing one of those can improve code clarity:
The text was updated successfully, but these errors were encountered: