Hashflow security record

In the contract `HashflowFactory` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set contract addresses used to create a new pool.  In the contract `HashflowGovernance` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and modify critical parameters of the Hashflow protocol.  In the contract `HashflowRouter` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and withdraw funds from the router.  Furthermore, the role `factory` has authority over the functions shown in the diagram below. Any compromise to the `factory` account may allow the hacker to take advantage of this authority and add/remove authorized pools.  In the contract `HashflowPool` the role `_operations` has authority over the functions shown in the diagram below. Any compromise to the `_operations` account may allow the hacker to take advantage of this authority and update pool properties and drain the funds.  In the contract `HashflowPrivatePool` the role `_authorizedRouter` has authority over the functions shown in the diagram below. Any compromise to the `_authorizedRouter` account may allow the hacker to take advantage of this authority.  Furthermore, the role `_operations` has authority over the functions shown in the diagram below. Any compromise to the `_operations` account may allow the hacker to take advantage of this authority and remove pool liquidity.  Additionally, the role `_xChainUa` has authority over the functions shown in the diagram below. Any compromise to the `_xChainUa` account may allow the hacker to take advantage of this authority and withdraw funds from the pool.  In the contract `HashflowPublicPool` the role `_authorizedRouter` has authority over the functions shown in the diagram below. Any compromise to the `_authorizedRouter` account may allow the hacker to take advantage of this authority and remove pool liquidity.  Furthermore, the role `_operations` has authority over the functions shown in the diagram below. Any compromise to the `_operations` account may allow the hacker to take advantage of this authority and withdraw funds from the pool.  Additionally, the role `_xChainUa` has authority over the functions shown in the diagram below. Any compromise to the `_xChainUa` account may allow the hacker to take advantage of this authority and withdraw funds from the pool.  Finally, regarding the contract `HashflowPublicPool`, the role `_withrawalAccountAuth` has authority over the function `transferAssets()`. Any compromise to the `_withrawalAccountAuth` account may allow the hacker to take advantage of this authority and withdraw funds from the pool. In the contract `HashflowXChainUA` the role `_lzEndpoint` has authority over the functions shown in the diagram below. Any compromise to the `_lzEndpoint` account may allow the hacker to take advantage of this authority and withdr

Projects may rely on block timestamps for various purposes. Given the cross-chain nature of this application, it is important to note that different networks may impose different requirements for their validators when it comes to setting the timestamp of a block, and attackers may be able to manipulate timestamps for their own purposes. If a smart contract relies on a timestamp, it must take this into account.

In discussion with the client, it was determined that the vast majority of user interactions with the dApp will occur in off-chain components, meaning the proper functioning of the system as a whole largely depends on off-chain code that is not within the scope of this audit. This makes it difficult for us to evaluate the risks associated with interacting with the application, especially when there is a lack of documentation for these off-chain computations (e.g. quest reward mechanism, Merkle tree computations). Furthermore, the cross-chain component of the application will be facilitated by a relaying system that is not within the scope of this audit.

In discussion with the Hashflow team, we learned that they plan to operate specialized Wormhole relayers and have the client relay the VAA as a fallback measure. It should be noted that the current implementation does not work with the [generic relayer](https://book.wormhole.com/technical/relayer/genericRelayer.html), which is currently only available on testnet. The generic relayer system requires that there is a function in the target contract on the destination chain called `receiveWormholeMessages()` as an entry point for execution. However, this function is not implemented in contracts that receive VAAs from Wormhole, e.g. `RenovaAvatarSatellite` and `RenovaItemBase`. For a reference implementation, see the last section of the Wormhole documentation on Best Practices [here](https://book.wormhole.com/technical/evm/bestPractices.html). This would additionally require proper use of nonces, as they are used to batch VAAs before they are relayed. However, they are currently hardcoded to zero.

The report gives no description here.

No description was provided.