The Metal team asked us to review and audit their new Metal Token contract code. We looked at their contracts and now publish our results.
The audited contracts can be found in their metal-token repo. The version used for this report is commit
Good work writing very minimal code and reusing existing contracts.
Here’s our assessment and recommendations, in order of importance.
No severe issues were found.
All contracts except
MetalToken are from version 1.0.5 of OpenZeppelin. Consider installing the contracts from NPM instead of vendoring (copy-pasting) them into the repository.
Notes and Additional Information
- Good job using OpenZeppelin!
- The modifier
BasicToken(lines 86 and 101) and
StandardToken(line 136) was added as a mitigation for the Short Address Attack. After some discussion we agreed that this problem should be fixed elsewhere, and removed it from OpenZeppelin. It doesn’t seem to cause any issues in the Metal Token code, but consider removing it to reduce attack surface.
- The state variables
INITIAL_SUPPLYshould all be constants.
INITIAL_SUPPLYshould be defined using the
decimalsstate variable as
66588888 * 10 ** decimals. This is clearer and more future proof.
INITIAL_SUPPLYamount is correct for the defined Metal token decimals (8).
No severe security issues were found. Some small changes were proposed to follow best practices and reduce potential attack surface.
Good work writing very minimal code and reusing existing contract modules.
Note that as of the date of publishing, the above review reflects the current understanding of known security patterns as they relate to the Metal Token contract. We have not reviewed the related Metal project. The above should not be construed as investment advice or an offering of tokens. For general information about smart contract security, check out our thoughts here.