Open code423n4 opened 2 years ago
Not a fan of the blanket statement, in lack of any risk am downgrading to NC
Valid Low, esp on uint96
Valid Low
I think this is highly unlikely, am very conflicted. Marking Low for now
Valid Low
I don't see any risk of clash of hashes, so in lack of further detail am marking invalid, consider finding an instance of clash and submit as higher severity in the future
Valid Ref
Disagree as long as usage is consistent (+ slither gives false positives is you emit after a transfer or w/e)
NC
Valid R
Valid NC
Valid NC
Valid Ref
NC
Valid Ref
Valid NC
Neat report
4L 4R 6NC
Table of Contents
@openzeppelin/contracts
versionreceive()
function)abi.encodePacked()
should not be used with dynamic types when passing the result to a hash function such askeccak256()
require()
should be used for checking error conditions on inputs and return values whileassert()
should be used for invariant checking>= 0.8
: SafeMath10000000e18
should be changed to1e25
for readability reasons400000e18
should be changed to4e23
for readability reasons100000e18
should be changed to1e23
for readability reasonsstring.concat()
bytes.concat()
instead ofabi.encodePacked(<bytes>,<bytes>)
1e3
, or even just1000
) rather than exponentiation (e.g.10**3
)return
statement when the function defines a named return variable, is redundantLow Risk Issues
1. Known vulnerabilities exist in currently used
@openzeppelin/contracts
versionAs some known vulnerabilities exist in the current
@openzeppelin/contracts
version, consider updatingpackage.json
with at least@openzeppelin/contracts@3.4.2
here:While vulnerabilities are known, the current scope isn't affected (this might not hold true for the whole solution)
2. 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 (or custom safe-casting functions) to prevent unexpected overflows when casting here:
3. Funds could be locked (unused/empty
receive()
function)If the intention is for the Ether to be used, the function should call another function, otherwise it should revert. Furthermore, in those contracts, no withdraw mechanism exist to retrieve locked ether (Ether sent by mistake).
4. 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.
5. Prevent accidentally burning tokens
Transferring tokens to the zero address is usually prohibited to accidentally avoid "burning" tokens by sending them to an unrecoverable zero address.
Consider adding a check to prevent accidentally burning tokens here:
6.
abi.encodePacked()
should not be used with dynamic types when passing the result to a hash function such askeccak256()
Similar issue in the past: here
Use
abi.encode()
instead which will pad items to 32 bytes, which will prevent hash collisions (e.g.abi.encodePacked(0x123,0x456)
=>0x123456
=>abi.encodePacked(0x1,0x23456)
, butabi.encode(0x123,0x456)
=>0x0...1230...456
). If there is only one argument toabi.encodePacked()
it can often be cast tobytes()
orbytes32()
instead.Non-Critical Issues
1.
require()
should be used for checking error conditions on inputs and return values whileassert()
should be used for invariant checkingProperly functioning code should never reach a failing assert statement, unless there is a bug in your contract you should fix. Here, I believe the assert should be a require or a revert:
As the Solidity version is > 0.8.* the remaining gas would still be refunded in case of failure.
2. It's better to emit after all processing is done
3. Typos in revert strings
4. Typos in comments
5. Deprecated library used for Solidity
>= 0.8
: SafeMath6. Missing friendly revert strings
7. Open TODOS
Consider resolving the TODOs before deploying.
8.
10000000e18
should be changed to1e25
for readability reasons1e25
is already well understandable. Writing10000000e18
is actually confusing9.
400000e18
should be changed to4e23
for readability reasons1e23
is already well understandable. Writing400000e18
is actually confusing10.
100000e18
should be changed to1e23
for readability reasons1e23
is already well understandable. Writing100000e18
is actually confusing11. Use solidity version of at least 0.8.12 to get
string.concat()
Use a solidity version of at least 0.8.12 to get
string.concat()
instead ofabi.encodePacked(<str>,<str>)
12. Use
bytes.concat()
instead ofabi.encodePacked(<bytes>,<bytes>)
Solidity version 0.8.4 introduces
bytes.concat()
(vsabi.encodePacked(<bytes>,<bytes>)
)13. Use scientific notation (e.g.
1e3
, or even just1000
) rather than exponentiation (e.g.10**3
)14. Adding a
return
statement when the function defines a named return variable, is redundantWhile 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.
Affected code:
15. The pragmas used are not the same everywhere
16. Non-library/interface files should use fixed compiler versions, not floating ones