The Otoy team asked us to review and audit their Render Token (RNDR) and crowdsale contracts. We looked at the code and now publish our results.
The audited contract is in the RenderToken/rendertoken repository. The version used for this report is the commit
Good job using OpenZeppelin to write minimal extra code!
Here’s our assessment and recommendations, in order of importance.
Misuse of FinalizableCrowdsale
As it is documented in the comments, to use
FinalizableCrowdsale you must inherit from it and define a custom
finalization function. Instead,
finalize was redefined. Although this isn’t causing any problems in the current state of the code, the misuse of the library hinders maintainability and may cause severe problems in future revisions. Remove this function and move the extra minting to a
- Keep in mind that it is the transaction sender who will be checked against the whitelist, and not the beneficiary of a purchase. This means that a whitelisted address may buy tokens for a non-whitelisted address. Make sure this is the desired feature.
- Consider adding events to log when an address is added or removed from the whitelist.
- (This was written for a previous version that was audited.) What is named “minimum cap” (
minCap) is not really a cap, because the word means an upper bound. In OpenZeppelin we use the term “goal” to refer to this concept.
RenderTokenis an instance of
MintableToken, which has a public variable
mintingFinishedinitially set to
false. Since this is a public variable that will be shown in interfaces (such as Etherscan’s) it might cause some confusion if it remains
falseafter the crowdsale ends. Consider calling
token.finishMinting()at finalization, to set the variable to
trueand avoid this potential confusion.
- The final token allocation will be: 25% of supply will have been on sale in the crowdsale, 65% is assigned to the foundation, and 10% will be held by the founders. Tokens not sold in the crowdsale will be sent to the foundation.
One low severity issue was found and explained, along with recommendations on how to fix it.
Note that as of the date of publishing, the above review reflects the current understanding of known security patterns as they relate to the Render Token contract. We have not reviewed the related Render project. The above should not be construed as investment advice. For general information about smart contract security, check out our thoughts here.