ABSTRACT
Dedaub was commissioned to perform a security audit of Simply VC’s ERC20LimitWrapper contract.
BACKGROUND
The ERC20LimitWrapper contract is a staking contract which allows users to deposit ERC20 tokens into the contract, and mint an equivalent amount of ERC20LimitWrapper contract tokens. The ERC20LimitWrapper tokens can then be burned by the contract to withdraw the original ERC20 tokens. The contract only supports one kind of ERC20 token (set at initialisation), and also supports functionality to limit the amount of deposits which can be made to a specified value. The owner is able to change this value, and to pause deposits (but not withdrawals).
SETTING & CAVEATS
This audit report mainly covers the contracts of the staking repository of the Simply VC protocol, at commit number 62b4dba.
Two auditors worked on the codebase for 1 day on the following contracts:
contracts
└── ERC20LimitWrapper.sol
The audit’s main target is security threats, i.e., what the community understanding would likely call “hacking”, rather than the regular use of the protocol. Functional correctness (i.e. issues in “regular use”) is a secondary consideration. Typically it can only be covered if we are provided with unambiguous (i.e. full-detail) specifications of what is the expected, correct behavior. In terms of functional correctness, we often trusted the code’s calculations and interactions, in the absence of any other specification. Functional correctness relative to low-level calculations (including units, scaling and quantities returned from external protocols) is generally most effectively done through thorough testing rather than human auditing.
VULNERABILITIES & FUNCTIONAL ISSUES
This section details issues affecting the functionality of the contract. Dedaub generally categorizes issues according to the following severities, but may also take other considerations into account such as impact or difficulty in exploitation:
Issue resolution includes “dismissed” or “acknowledged” but no action taken, by the client, or “resolved”, per the auditors.
CRITICAL SEVERITY
[No critical severity issues]
HIGH SEVERITY
[No high severity issues]
MEDIUM SEVERITY
[No medium severity issues]
LOW SEVERITY
Checks in deposit function can be bypassed if depositLimit <= 0
Low | Status: OPEN
In the deposit function, if the depositLimit <= 0, then the check which enforces that the totalSupply() + _amount > depositLimit is bypassed and the user can deposit any amount of funds into the contract, when the expected behaviour is that the user should not be able to deposit any funds.
Unsafe use of transfer and transferFrom
Low | Status: OPEN
The functions deposit and withdraw call transfer and transferFrom on the depositToken contract. Since the depositToken contract can be arbitrary, transfer and transferFrom will revert for tokens which do not return a boolean success value, such as USDT and others. Use OpenZeppelin’s SafeERC20::safeTransfer and SafeERC20::safeTransferFrom to protect against such reverts.
The depositLimit can be reduced below the totalSupply
Low | Status: OPEN
The setDepositLimit function is able to reduce the depositLimit value below the totalSupply. While this has no immediate consequences in the current contract, it breaks an important system invariant and could create further issues down the line. We recommend adding a validation to setDepositLimit to stop this scenario from taking place.
OTHER / ADVISORY ISSUES
This section details issues that are not thought to directly affect the functionality of the project, but we recommend considering them.
Make depositToken immutable
Advisory | Status: INFO
The variable depositToken is not modified after initialisation and could be declared immutable to save gas.
No validations in constructor
Advisory | Status: INFO
The constructor of the contract assigns values to DepositToken and DepositLimit but does not have any validations on these values. For instance it could check that DepositToken is not address(0), and that DepositLimit lies within some sensible range. In the latter case, the same validation could be applied to the setDepositLimit function.
Typo in comment of deposit function
Advisory | Status: INFO
The @notice comment of the deposit function reads as follows “deposit the contract deposite token into this contract and mint a wrapped version” which has several typos.
Compiler bugs
Advisory | Status: INFO
The code is compiled with Solidity 0.8.19. Version 0.8.19, in particular, has some known bugs, which we do not believe affect the correctness of the contracts.
DISCLAIMER
The audited contracts have been analyzed using automated techniques and extensive human inspection in accordance with state-of-the-art practices as of the date of this report. The audit makes no statements or warranties on the security of the code. On its own, it cannot be considered a sufficient assessment of the correctness of the contract. While we have conducted an analysis to the best of our ability, it is our recommendation for high-value contracts to commission several independent audits, a public bug bounty program, as well as continuous security auditing and monitoring through Dedaub Security Suite.
ABOUT DEDAUB
Dedaub offers significant security expertise combined with cutting-edge program analysis technology to secure some of the most prominent protocols in DeFi. The founders, as well as many of Dedaub’s auditors, have a strong academic research background together with a real-world hacker mentality to secure code. Protocol blockchain developers hire us for our foundational analysis tools and deep expertise in program analysis, reverse engineering, DeFi exploits, cryptography and financial mathematics.