ZNS Token Upgrade
Summary
This report outlines the audit of the new MeowToken implementation by Quantstamp. The MeowToken is an ERC20 token designed for Meow DAO ownership. The audit assessed the contract's upgradeability, its transition from modified OpenZeppelin v4.0.0 to v4.8.2, the removal of centralized functionalities like balance snapshot and pausing, and the addition of a token burning mechanism on transfers to the token address. The Transparent Proxy of MeowToken is deployed at `0x0eC78ED49C2D27b315D462d43B5BAB94d2C79bf8` and the current token implementation is deployed at `0xb8a9c7b782056edfc9e4585b14f078b5dd63994b`. During the audit process, the team expressed the intention to remove centralized functionalities, ownership, and upgradeability from MeowToken. While the removal of centralized functions in the new implementation contract was validated, we did not have access to the scripts that would be used to eliminate ownership and admin privileges from the Transparent Proxy at the time of the audit. The audit resulted in a total of 6 findings along with 4 best practices outlined below. We determined the test coverage to be low, and strongly recommend the client to test all functions to ensure high coverage. Furthermore, we recommend updating the test suite to validate the new implementation contract using OpenZeppelin's Hardhat Upgrade API [validateUpgrade](https://docs.openzeppelin.com/upgrades-plugins/1.x/api-hardhat-upgrades#validate-upgrade). We also recommend that the client update all documentation related to MeowToken to reflect the new changes and address or consider all findings highlighted in this report. **Fix Review**: During the fix review, the client addressed all issues from ZNS-1 to ZNS-6 by either implementing fixes or acknowledging them. The client also added more tests to thoroughly test all functions and to validate upgradeability compatibility. Additionally, the client switched from OpenZeppelin's implementation v4.8.2 to v4.8.3 as v4.8.2 contained a vulnerability; hence, the client switched as best practice. Furthermore, the client updated documentation to reflect the latest Meow implementation and provided documentation that outlines the procedure for removing ownership and admin privileges from `MeowToken` by renouncing ownership of the `ProxyAdmin`, which we have reviewed. <br> They inquired if it is preferable to `renounceOwnership()` or transfer ownership to a dead address. If the client's intention is to renounce ownership, we recommend invoking `renounceOwnership()` for transparency on the chain. Once ownership is revoked, it will be impossible to upgrade the MeowToken implementation since there will be no owner, the sole entity that can upgrade the contract. After the ownership of its ProxyAdmin is renounced, `MeowToken` will no longer be upgradeable.
Issues (6)
Low | Medium | High | Critical | Total | |
|---|---|---|---|---|---|
Not fixed | 2 | - | - | - | 2 |
Fixed | 4 | - | - | - | 4 |
| Total | 6 | 0 | 0 | 0 | 6 |