FintruX Network security record

In the contract `FETHToken`, the role `admin` has authority over the following functions: - addMultipleValidators - removeValidator - updateValidatorBal - withdrawStakingRewards Any compromise to the `admin` account may allow a hacker to take advantage of this authority and modify the validator list or withdrawing staking reward to `f2eSwapAddress`. In the contract `FTXPriceFeed`, the role `owner` has authority over the following functions: - setPrice - setAddresses the role `admin` has authority over the following functions: - setTWAPInterval Any compromise to the aforementioned account may allow a hacker to take advantage of this authority and modify the price of FTX token,.

The function `redistribute()` is called when liquidated, while the function `offset()` is called when users withdrawing collaterals. However, the function `_decreaseTotalPAYDDeposits` is called in `redistribute()`, but not in `offset()`.

1. How are the Ethers transferred/deposited to the ActivePool (as well as other pools like MiningPool, RewardsPool and ValidatorPool)? Since there are no `receive()` or `fallback()` functions. The only legit token is FETH. Both ETH and PAYD only have the value stored. Indeed there are ways to store Ethers without `receive()` or `fallback()` functions, referring to Can a contract with no payable function have ether? - Ethereum Stack Exchange, we would like to confirm the use case of the assets flow of the pools 2. In the contract F2ESwap, how are ETH are FETH guaranteed to be 1:1, there seem to be no obvious checks/verifications in the implementation.

The two variables `truncateETH` and `truncatePAYD` are used in contracts Snapshot, RewardsPool and Fees. We understand that the truncation operations are to improve human readability. However, the truncations would lead to potential precision loss, although the potential loss amount is relatively small. For example, in the function `_getETHGainFromSnapshots()` of the contract Snapshot, the variable `ETHGain` is truncated from `1e18` to `1e6` or `1e8`. (Please also review [SCL-01|Inconsistency on `truncateETH` And `truncatePAYD`]() for the inconsistency of `1e6` and `1e8` here.) The public function `snapshot.getDepositorETHLoss()` directly returns the return value of `_getETHGainFromSnapshots()`. All functions that call the function `snapshot.getDepositorETHLoss()` will be forced to adopt the truncation from `truncateETH`.

The function `_processETH()` implements an FETH queue to distribute ETH. For the case that if there is a deposit with a huge amount of money, the queue will be stuck, and then the deactivation balance will not be able to be updated accordingly.

There are multiple addresses seems to be on testnets instead of the Ethereum mainnet: * BorrowerOperations: * `openWalletAddress` * `topupWalletAddress` * CacheManager: * paydSwapWalletAddress * F2ESwap: * `fethSwapWalletAddress` * FETHToken: * `stakingFeeWalletAddress` * `miningFeeWalletAddress` * `excessWalletAddress` * `fethSwapWalletAddress` * FTXStaking: * `ftxInventoryAddress` * KYCManager: * `charityWalletAddress`

The contract is serving as the underlying entity to interact with third party UniswapV3, Chainlink, Tellor and Ethereum staking deposit contracts. The scope of the audit treats 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc.

In function stake, variable `stakes[msg.sender].since` is updated when user's stake amount reaches tier 1. However, in case of the user deposit does not change discount tier, the variable is still updated. Possible scenario: 1. User deposits 30000 FTX token to reach tier 1. 2. User deposits another 30000 FTX token. After the deposit, the user is still in tier 1, but the timestamp is updated.