Open code423n4 opened 2 years ago
We allow Unspecific Compiler version for our interfaces, so they can be imported by other projects
Not applicable.
We are not using block.timestamp
for deriving entropy. Slight time manipulation is possible by miners but not critical for our application
Not applicable. We need receive
to receive ether from WETH
contract. Duplicate of #7
Not applicable. axelarToken
is our own implementation in this context and it implements decimals
Yes. But that is applicable only to this one, because there is data following the dynamic type.
AxelarGateway.sol::544 => return keccak256(abi.encodePacked(PREFIX_TOKEN_DAILY_MINT_AMOUNT, symbol, day));
Yes. Dup #3
Nope. Dup #3
Yes. Dup #3
Dup #3
Those error messages are descriptive enough
Nope. You can't index dynamic data structures without loosing data
NC
Disagree for the cases shown above in lack of explanation
For the proxy L
L
Disputed for the example shown
Disputed for those usages
L
L
NC
Disputed
Don't think the sponsor would want to index those values as they will change each time, so what's the point
The turning test of QA
4L 2NC
[L-01] Unspecific Compiler Version Pragma
Avoid floating pragmas for non-library contracts.
While floating pragmas make sense for libraries to allow them to be included with multiple different versions of applications, it may be a security risk for application implementations.
A known vulnerable compiler version may accidentally be selected or security tools might fall-back to an older compiler version ending up checking a different EVM compilation that is ultimately deployed on the blockchain.
It is recommended to pin to a concrete compiler version.
[L-02] Use of Block.timestamp
Block timestamps have historically been used for a variety of applications, such as entropy for random numbers (see the Entropy Illusion for further details), locking funds for periods of time, and various state-changing conditional statements that are time-dependent. Miners have the ability to adjust timestamps slightly, which can prove to be dangerous if block timestamps are used incorrectly in smart contracts.
[L-03] Unused receive() function
If the intention is for the Ether to be used, the function should call another function, otherwise it should revert
[L-04] decimals() not part of ERC20 standard
decimals() is not part of the official ERC20 standard and might fail for tokens that do not implement it. While in practice it is very unlikely, as usually most of the tokens implement it, this should still be considered as a potential issue.
[L-05] abi.encodePacked() should not be used with dynamic types when passing the result to a hash function such as keccak256()
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), but abi.encode(0x123,0x456) => 0x0...1230...456). Unless there is a compelling reason, abi.encode should be preferred. If there is only one argument to abi.encodePacked() it can often be cast to bytes() or bytes32() instead.
[L-06] approve should be replaced with safeApprove or safeIncreaseAllowance() / safeDecreaseAllowance()
approve is subject to a known front-running attack. Consider using safeApprove() or safeIncreaseAllowance() or safeDecreaseAllowance() instead
[L-07] Unsafe use of transfer()/transferFrom() with IERC20
Some tokens do not implement the ERC20 standard properly but are still accepted by most code that accepts ERC20 tokens. For example Tether (USDT)'s transfer() and transferFrom() functions do not return booleans as the specification requires, and instead have no return value. When these sorts of tokens are cast to IERC20, their function signatures do not match and therefore the calls made, revert. Use OpenZeppelin’s SafeERC20's safeTransfer()/safeTransferFrom() instead
[L-08] Missing checks for zero address
Checking addresses against zero-address during initialization or during setting is a security best-practice. However, such checks are missing in address variable initializations/changes in many places.
Impact: Allowing zero-addresses will lead to contract reverts and force redeployments if there are no setters for such address variables.
[N-01] Use a more recent version of solidity
Use a solidity version of at least 0.8.4 to get bytes.concat() instead of abi.encodePacked(,)
Use a solidity version of at least 0.8.12 to get string.concat() instead of abi.encodePacked(,)
Use a solidity version of at least 0.8.13 to get the ability to use using for with a list of free functions
[N-02] require()/revert() statements should have descriptive reason strings
for troubleshotting purposes
[N-03] Event is missing indexed fields
Each event should use three indexed fields if there are three or more fields