SMART CONTRACT SECURITY AUDIT FOR WEPC
At Blaize, we provide security services at all levels for projects of different scales. That includes verifying the implementation of ERC20 tokens, as we performed for the WEPC token by the WAR.DAY team.
ABOUT THE PROJECT
The WAR.DAY team develops a modern Play2Earn protocol that aims to connect the experience of traditional multiplayer games with the advantages of the web3 landscape. The WAR.DAY team entrusted Blaize Security with the task of verifying the security of their platform token WEPC. Thus, the objective of the security team was: to verify the correctness of the ERC20 standard implementation, identify the substandard logic, and describe any potential security vulnerabilities in it. This report serves as a detailed account of our findings during the security audit.
WEPC token is a standard ERC20 token with additional extensions for token minting and burning – an additional interface controlled by the designated role and responsible for the containment of the token’s supply.
MAIN REQUIREMENTS
During our audit, we scrutinized the smart contract for various vulnerabilities in several stages:
1) Standard vulnerabilities checklists, including but not limited to:
- Reentrancy
- Gas limit and loops
- Transaction-ordering dependence
- Unchecked external calls
- Denial-of-Service (DoS) attacks
- Malicious libraries and injections
- Storage issues (uninitialized, unused, etc) and incorrect local variable usage
- Public interface and access control structure
and other potential Solidity vulnerabilities and attack vectors;
2) Business logic decompositions to find loopholes, deadlocks, hidden backdoors, incorrect math and calculations, malicious code injections, and other flow-related issues;
3) Review of dependencies, integrations and 3rd parties, verified with appropriate integration tests;
4) Our own internal security checklists, additionally verified during the testing stage.
The team first focused on verifying the correctness of the ERC20 standard implementation, the version of standard contracts used from the OpenZeppelin library, the access control approach (for mint and burn functions), and the chosen approach for token supply management (via mint and burn functions).
SMART CONTRACT SECURITY AUDIT PROCEDURE
Our audit process encompassed manual and testing stages:
1.MANUAL AUDIT STAGE
- Manual line-by-line code review by 2 security auditors with crosschecks and validation from the security lead;
- Vulnerabilities analysis against several checklists, including internal Blaize.Security checklist;
- Business logic inspection;
- Protocol decomposition and components analysis with building interaction schemes and sequence diagrams;
- Storage usage review and gas optimization review;
- Math operations and calculations analysis;
- Access control and roles structure review;
- Review of dependencies, 3rd parties, and integrations;
- Review with automated tools and static analysis;
- Code quality, documentation, and consistency review.
2.TESTING STAGE
- Development of edge cases based on manual stage results;
- False positives validation;
- Integration tests for checking connections with 3rd parties;
- Manual exploratory tests over the locally deployed protocol;
- Checking the existing set of tests and performing additional unit testing;
Upon completing the audit, we delivered a comprehensive smart contract security analysis report to the WAR.DAY team. This report included:
- Identified risks
- Potential mitigations
- Detailed vulnerability assessments
- Recommendations for improvements
AUDIT RESULT
The audit aimed to confirm the correctness of the ERC20 interface implementation, check the integrity of the token logic, and check the access control system. Besides that, our auditors performed a review against the standard vulnerabilities checklist and against the list of potentially vulnerable areas.
The team noted several areas which produce increased risks for the system:
- potential risks connected to the ERC-2612 Permit interface – potential race condition for signatures issued simultaneously, absence of the ability to withdraw the signature before the deadline, and absence of the deadline validation;
- potential risks connected to the public burning interface – secondary threats from the compromised protocols holding the token and from dangling approvals;
- potential risks connected to the unrestricted minting interface – centralization and human factor risks, which can both lead to the incorrect minting process.
Though, the WAR.DAY team acknowledged all risks and verified the necessity of the current business logic implementation. Thus the security team advises providing additional sanitizing measures for the minting process (who will hold the Minter role, what amounts are minted, and to what accounts), sanitizing measures for integrated protocols (so they cannot burn tokens using dangling approvals), and notifying users about the Permit interface correct usage.
The security team verified that the WEPC token implements the ERC20 interface correctly and according to the standard. The team also verified that standard contracts from the OZ library are integrated correctly and according to the last OZ v5.0.2 release. The auditors noted that the project contains no initial Hardhat/Foundry repository; thus, the security of the development environment was not verified.
In conclusion, and including the acknowledgment of the listed risks by the WAR.DAY team, the security team evaluated the project as Secure. Thus, the WEPC project successfully passed the audit with a final security rating of 9.7 out of 10.