QA Report #153
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
sponsor disputed
Sponsor cannot duplicate the issue, or otherwise disagrees this is an issue
QA Report
Table of Contents
summary
The main concerns are with the lack of input checks in setters, and the use of deprecated versions of Solidity.
Comment Missing function parameter
PROBLEM
Some of the function comments are missing function parameters or returns
SEVERITY
Non-Critical
PROOF OF CONCEPT
Instances include:
Aura.sol
AuraClaimZap.sol
BalLiquidityProvider.sol
ArbitartorVault.sol
Booster.sol
TOOLS USED
Manual Analysis
MITIGATION
Add a comment for these parameters
Events emitted early
PROBLEM
It is not recommended to emit events before the end of the computations, as the function might revert based on conditions ahead of the event emission
SEVERITY
Non-Critical
PROOF OF CONCEPT
Instances include:
AuraBalRewardPool.sol
AuraLocker.sol
TOOLS USED
Manual Analysis
MITIGATION
Place the event emission in the last position in the function.
Event should be emitted in setters
PROBLEM
Setters should emit an event so that Dapps can detect important changes to storage
SEVERITY
Low
PROOF OF CONCEPT
Instances include:
AuraStakingProxy.sol
AuraStakingProxy.sol
ArbitartorVault.sol
cCrv.sol
ConvexMasterChef.sol
CrvDepositor.sol
ExtraRewardStashV3.sol
PoolManagerProxy.sol
PoolManagerSecondaryProxy.sol
PoolManagerV3.sol
StashFactoryV2.sol
VoterProxy.sol
TOOLS USED
Manual Analysis
MITIGATION
Emit an event in all setters.
Function missing comments
PROBLEM
Some functions are missing comments.
SEVERITY
Non-Critical
PROOF OF CONCEPT
Instances include:
AuraBalRewardPool.sol
AuraClaimZap.sol
AuraLocker.sol
AuraMerkleDrop.sol
CrvDepositorWrapper.sol
ArbitartorVault.sol
BaseRewardPool.sol
BoosterOwner.sol
ConvexMasterChef.sol
CrvDepositor.sol
DepositToken.sol
ProxyFactory.sol
StashFactoryV2.sol
TokenFactory.sol
VirtualBalanceRewardPool.sol
VoterProxy.sol
TOOLS USED
Manual Analysis
MITIGATION
Add comments to these functions
Tautology
PROBLEM
Statements where a uint256 is checked to be >= 0 should be removed, as a uint256 is always >= 0.
SEVERITY
Non-Critical
PROOF OF CONCEPT
Instances include:
CrvDepositor.sol
TOOLS USED
Manual Analysis
MITIGATION
Remove the
_lockIncentive >= 0
conditionTypos
PROBLEM
There are a few typos in the contracts.
SEVERITY
Non-Critical
PROOF OF CONCEPT
Instances include:
ArbitartorVault.sol
TOOLS USED
Manual Analysis
MITIGATION
Correct the typos.
Uint256 alias
IMPACT
uint
is an alias foruint256
.It is better to use uint256: it brings readability and consistency in the code, and it future proofs it in case of any changes to the alias of uint
SEVERITY
Non-Critical
PROOF OF CONCEPT
Instances include:
BaseRewardPool.sol
Booster.sol
ExtraRewardStashV3.sol
PoolManagerSecondaryProxy.sol
TOOLS USED
Manual Analysis
MITIGATION
replace
uint
withuint256
Unlocked Solidity compiler pragma
IMPACT
Contracts should be deployed using the same compiler version/flags with which they have been tested.
Using an unlocked pragma of ^0.8.0 which allows different latest versions of Solidity, is risky because it allows contracts to be accidentally deployed using untested newer compiler versions with unfixed/undiscovered bugs
SEVERITY
Non-Critical
PROOF OF CONCEPT
Instances include:
All contracts in the
contracts
folder.TOOLS USED
Manual Analysis
MITIGATION
Lock the pragmas.
Use an up-to-date version of Solidity
IMPACT
By using a deprecated version of Solidity, you might use some less secure features, and you might get a bigger bytecode out of the compilation process, which will make you pay more gas for deployment.
SEVERITY
Low
PROOF OF CONCEPT
Instances include:
All contracts in the
convex-platform/contracts
folder.In this case, using a version < 0.8.0 forces you to use the external SafeMath library to check overflow and underflow of additions and subtractions, which could be avoided by upgradi
TOOLS USED
Manual Analysis
MITIGATION
Change the versions from
0.6.12
to any version >0.8.0
SafeApprove is deprecated
PROBLEM
The
safeApprove
method from openZeppelin's safeERC20 library is used although it's deprecated.(see https://github.com/OpenZeppelin/openzeppelin-contracts/blob/566a774222707e424896c0c390a84dc3c13bdcb2/contracts/token/ERC20/utils/SafeERC20.sol#L38)
SEVERITY
Non-critical
PROOF OF CONCEPT
It is used in the following contracts:
AuraBalRewardPool.sol
AuraClaimZap.sol
AuraLocker.sol
AuraMerkleDrop.sol
AuraPenaltyForwarder.sol
AuraStakingProxy.sol
AuraVestedEscrow.sol
BalLiquidityProvider.sol
CrvDepositorWrapper.sol
BaseRewardPool4626.sol
Booster.sol
CrvDepositor.sol
VoterProxy.sol
TOOLS USED
Manual Analysis
MITIGATION
As per OZ's suggestions, you should use
safeIncreaseAllowance
andsafeDecreaseAllowance
instead.Setters should check the input value
PROBLEM
Setters should check the input value - ie make revert if it is the zero address or zero
SEVERITY
Low
PROOF OF CONCEPT
The following setters set an admin but do not check the argument is not the zero address:
AuraMerkleDrop.sol
AuraStakingProxy.sol
AuraVestedEscrow.sol
ArbitartorVault.sol
Booster.sol
cCrv.sol
CrvDepositor.sol
ExtraRewardStashV3.sol
PoolManagerProxy.sol
PoolManagerSecondaryProxy.sol
PoolManagerV3.sol
StashFactoryV2.sol
VoterProxy.sol
TOOLS USED
Manual Analysis
MITIGATION
Add non-zero checks
The text was updated successfully, but these errors were encountered: