/Reach - Diff 2

All privileged permissions should be clearly documented for users. The privileged permissions of the audited contracts are documented below: - `ReachMainDistribution`: - Owner can: - Withdraw all the balance of the contract (ETH and REACH) - Change credit price - Create new distributions - Transfer the ownership to another address - Swap ETH balance for REACH tokens - `ReachAffiliateDistribution`: - Owner can: - Create new distributions - Transfer the ownership to another address - Swap ETH balance for REACH tokens - `ReachFactory`: - Owner can: - Deploy new affiliate distribution contracts - Change `mainDistribution` address - Change `commission` value - Transfer the ownership to another address Furthermore, the rewards withdrawal logic depends solely on Merkle roots provided by the off-chain component controlled by the team. This design allows the owner to provide rewards to targeted receivers but, at the same time, introduces centralization risks.

The function `createDistribution()` accepts three input arguments: the `_merkleRoot` containing all the users and the amount (both ETH and REACH) each user should get, and the `_ethAmount` and `_reachAmount` inputs representing the total amount to be distributed in both tokens, and should be equal to the total amount to be distributed to all the leaves in the Merkle tree, and also less or equal to the current ETH or token balance of the contract. Otherwise, some users would be expecting rewards that are not even available.

Distributions are held in different rounds, where a user must submit their Merkle proof to claim their rewards for the current round. If the round has elapsed through calling `createDistribution()`, the Merkle roots are overwritten. Though the funds remain in the contract for future distribution, there is no guarantee that the new Merkle roots will account for unclaimed prizes. There are multiple scenarios that can arise and it is unclear how the team handles this situation. 1. The rewards are re-introduced in the tree for the next version, guaranteeing users their unclaimed rewards. 2. The rewards are diluted between the beneficiaries of the next distribution, which might exclude the user.

In swapEth(), for both the `ReachMainDistribution` and `ReachAffiliateDistribution`, it emits the event with the variable `_outputAmount`. However, the function `swapExactETHForTokensSupportingFeeOnTransferTokens()` tries to swap as many output tokens given the exact amount of `ETH`, which means the actual amount of output tokens you get (in this case `REACH`) will likely not be the same as `_outputAmount`. Note that `_outputAmount` is the minimum you need to receive for the swap function not to revert, rather than the exact amount you will receive. While there is no security issue from the smart contract standpoint, this may mess up the backend accounting.

In the current version, any user can call the `createMission` function, potentially with the same `missionId`, which can be problematic. Note that the `MissionCreated` event does not keep track of the user who created the mission. It is unclear how the backend keeps track of and handles this situation. Furthermore, this function is `payable` and receives native tokens (i.e. ETH), but the received amount is not bounded. It is not clear what the expected behavior is if a user sends less than the expected minimum amount to create a mission (if any).