**Update**: The client addressed all the issues discussed in the report. <br><br> **Initial audit**: Quantstamp performed an audit for Hashflow's Hashverse contracts based on the code present in the linked repository. <br><br> The contracts within this repository form the basis for the on-chain behaviour of an NFT gaming system. Although it is to be integrated with a DAO, this aspect was not part of the audit. Instead, the audit focused on the NFT contracts, an administrative module termed `RenovaCommandDeck`, and a quest contract where users may use their NFTs and may sometimes engage in trading with the Hashflow trading system. <br><br> Of particular note is the use of Wormhole, a cross-chain generalized message passing protocol that is being used in the current instance to enable two types of functionality: 1. cross-chain minting of player avatar NFTs; and 1. cross-chain transfers of item NFTs. While avatar NFTs can be freely minted, item NFTs can only be minted by authorized accounts and in situations determined by a Merkle tree system; for example, when successful in a quest, the admin may update a Merkle tree indicating that a user is eligible to mint an item, and then provide them a Merkle proof that allows them to mint that item. <br><br> It is also important that quests are facilitated through the `RenovaQuest` contract, which is deployed for every quest that players may take part in, and which may custody users' funds when they interact with it for the purposes of trading. <br><br> Therefore, the audit was mainly focused around the following key areas of concern: * Proper interaction with the Wormhole contracts; * Correct accounting of custodied funds in `RenovaQuest`; * Appropriate implementation of minting and transfer functionalities for the NFTs. The most severe issue found is in relation to accounting of custodied funds: when dealing with deflationary tokens, some users may be unable to retrieve all the tokens to which they are entitled. <br><br> With regards to Wormhole, we identified an issue concerning the lack of an appropriate recipient contract on the destination chain: if there is none, then the transferred item is effectively burned. We also discuss issues about fees and relayers that are not problems now, but may become problems in the future. <br><br> Although the code is commented very well, the project overall is severely lacking in technical documentation that details the intended functioning of the smart contracts. We did our best to remedy this issue by engaging in extensive communication with the client during the course of the audit. The test suite, though supplemented with Wormhole integration tests, is also lacking, and should be improved before deploying the project to production. <br><br> We recommend that the client address and/or consider all the findings included in this report.
Low | Medium | High | Critical | Total | |
---|---|---|---|---|---|
Not fixed | 4 | - | - | - | 4 |
Fixed | 14 | 1 | 1 | - | 16 |
Total | 18 | 1 | 1 | 0 | 20 |
# | File Name |
---|---|
1 | contracts/wormhole/WormholeBaseUpgradeable.sol |
2 | contracts/test/TestERC20.sol |
3 | contracts/test/TestERC1271.sol |
4 | contracts/interfaces/nft/IRenovaAvatar.sol |
5 | contracts/staking/StakingVault.sol |
6 | contracts/nft/RenovaAvatar.sol |
7 | contracts/nft/RenovaItem.sol |
8 | contracts/test/MockHashflowRouter.sol |
9 | contracts/core/RenovaQuest.sol |
10 | contracts/interfaces/Interfaces.sol |