Hashflow Hashverse

When a user deposits tokens into a quest, they do so using a struct, `TokenDeposit`, that includes the address of the token and the amount that will go into `safeTransferFrom()`. Moreover, the amount of tokens that a user is allowed to trade with in a quest depends on the `portfolioTokenBalances`, which is increased by the `TokenDeposit` amount when depositing tokens via `_depositTokens()`. As a result, if the `transferFrom` function does not act strictly via the input amount when changing balances (for example, in the case of deflationary tokens), then users may be able to trade with more tokens than actually reached the contract when depositing them, as other users may have deposited funds ahead of them. Consequently, the users who trade later may be unable to trade with the full amount of what they deposited. `potfolioTokenBalances` is also used when determining how much users are able to withdraw. Hence, if the amount of a token in the contract is lower than the cumulative amount recorded in `portfolioTokenBalances`, some users will be unable to withdraw in accordance with their rightful proportion of the total funds in the contract.

Users can bridge their items between chains by calling `wormholeBridgeOut()` in `RenovaItem` and `RenovaItemSatellite`. The user chooses the destination Wormhole chain ID with `dstWormholeChainId`. If the user passes the chain ID for a chain that does not have a `RenovaItemSatellite` contract deployed, the item is essentially lost as the item is burnt on the source chain during the bridging. There are no relevant checks to ensure that the destination chain is configured for bridging Renova items.

When bridging a Renova item to another chain, the user calls `wormholeBridgeOut()` on the source chain. After the item is burnt on the source chain, the line `delete _hashverseItemIds[tokenId];` deletes the Hashverse item ID associated with the token ID. However, after deleting the Hashverse item ID from the mapping, the event `XChainBridgeOut` calls `_hashverseItemIds[tokenId]` again to get the associated Hashverse ID. Therefore, the emitted Hashverse item ID will always be `0`.

In `mintItem()`, minted items are tracked using the `rootId` and `tokenOwner` address. If a `rootId` happens to reward a user multiple times, every call to `mintItem()` after the first one will fail.

When creating quests, the maximum number of items is assigned to `_maxItemsPerPlayer`. In `_loadItems()`, if `_maxItemsPerPlayer` is set to zero, then the maximum number of items is `type(uint256).max`. Therefore, the smallest maximum number of items a quest can have is one.

One attack vector that must be accounted for when implementing cross-chain functionality is that of replay attacks. It is possible for someone to design a system implementing Wormhole that allows a VAA coming from some chain to be transmitted more than once on the destination chain, as the Wormhole core layer contract does not prevent this. Therefore, it is the responsibility of the system designer to determine whether this is a desirable trait and, if not, to implement a countermeasure. In the case of Hashverse, there are two possible cross-chain messages to consider with respect to this issue. The first message is cross-chain minting of avatars. Any address is able to mint an avatar NFT; this NFT is soulbound (the transfer function is disabled) and the first minting must be on Ethereum Mainnet. It also cannot be burned. Subsequently, users can use the `RenovaAvatar.wormholeMintSend()` function to mint this avatar NFT on another chain and to the same address as it belonged to on Ethereum Mainnet. Attempting to replay the emitted VAA would accomplish nothing as the previously cross-chain minted NFT would still be at the same address, causing the attempt at replaying the VAA to revert. The second message is cross-chain transferring of items. Items are NFTs that can only be initially minted on Ethereum Mainnet. These mints are controlled -- they either require the minting user to be directly authorized by the NFT contract owner, or they must be minted through the command deck, either directly by the admin of the command deck, or a process involving Merkle trees controlled by the admin of the command deck. Once minted, an item can be sent to another chain by use of the `RenovaItem.wormholeBridgeOut()` function -- this burns the item on the source chain and emits a VAA that when received on the destination chain will mint the item with the same `tokenId`. To prevent replaying of the VAA, each VAA is sent with a nonce associated with the item and that increases every time the item is sent to another chain. Hence, attempting to replay the VAA would only result in execution being reverted. Therefore, there are overall no concerns about cross-chain replay attacks in the current project. However, the `WormholeBaseUpgradeable` contract is an abstract contract that developers may want to reuse in other projects. It is important to note that, in general, this contract does not prevent replaying VAAs in the `_wormholeReceive()` function.

Users can enter a quest as long as it is before the start time and the maximum number of players has not been reached. Once a user has entered a quest, `numRegisteredPlayers` is incremented. If `_maxPlayers` is small, a malicious actor could quickly register effectively inactive players until the maximum number of players is met. This would cause the malicious actor to be the only active player in the quest and deny other users the ability to play. Additionally, when entering a quest, `numRegisteredPlayersPerFaction` is incremented for the faction the user selected. If a quest is designed to have opposing factions compete against each other, a malicious actor could quickly register inactive players for the opposing faction to increase the malicious actor's chances of winning.

A greedy contract is a contract that can receive ether which can never be redeemed. `RenovaItemBase.wormholeBridgeOut()` is a payable function which means that users can send ETH to the contract using this function; however, at no point does this contract use any ETH in its functions, nor is there any means to withdraw ETH from the contract. Notably, ETH would ordinarily be used for interacting with Wormhole via `publishMessage()`.

The ordering of the parameters to the event `UpdateHashflowRouter` in `updateHashflowRouter()` is incorrect, as it currently suggests that we are updating the Hashflow router from the new router to the old one, based on the documentation of the event in the interface.

It is important to validate inputs, even if they only come from trusted addresses, to avoid human error. Specifically, in the following functions arguments of type `address` may be initialized with value `0x0`: * `RenovaCommandDeckBase.updateRenovaItem()`: `_renovaItem` * `RenovaCommandDeckBase.updateRenovaAvatar()`: `_renovaAvatar` * `RenovaCommandDeckBase.updateHashflowRouter()`: `_hashflowRouter` * `RenovaAvatarBase.__RenovaAvatarBase_init()`: `_renovaCommandDeck`