Hector Network security record

In the contract `RedemptionNFT` the role `PAUSER_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `PAUSER_ROLE` account may allow the hacker to take advantage of this authority and pause/unpause the transfer of FNFTs.  In the contract `RedemptionNFT` the role `_moderator` has authority over the functions shown in the diagram below. Any compromise to the `_moderator` account may allow the hacker to take advantage of this authority and mint tokens to hacker address.  ----- In the contract `HectorRedemption` the role `_moderator` has authority over the functions shown in the diagram below. Any compromise to the `_moderator` account may allow the hacker to take advantage of this authority and withdraw all tokens.  ----- In the contract `HectorRedemptionTreasury` the role `_moderator` has authority over the functions shown in the diagram below. Any compromise to the `_moderator` account may allow the hacker to take advantage of this authority and withdraw all tokens.  ----- In the contract `LockAccessControl` 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 change `addressProvider`.  ----- In the contract `LockAddressRegistry` the role `MODERATOR_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `MODERATOR_ROLE` account may allow the hacker to take advantage of this authority and set moderators.  In the contract `LockAddressRegistry` 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 change important contract addresses.  ----- In the contract `TokenVault` the role `_moderator` has authority over the functions shown in the diagram below. Any compromise to the `_moderator` account may allow the hacker to take advantage of this authority and mint FNFTs and withdraw tokens.  In the contract `TokenVault` 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 pause/unpause the contract.  ----- In the contract `HectorRegistration` the role `DEFAULT_ADMIN_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `DEFAULT_ADMIN_ROLE` account may allow the hacker to take advantage of this authority and set moderators.  In the contract `HectorRegistration` the role `MODERATOR_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `MODERATOR_ROLE` account may allow the hacker to take advantage of this authority and add registered wallets or blacklist addresses. 

In the contract Emissionor.sol the role `_owner` has authority over the following functions: - `setModerator()` - `setTreasury()` - `setSplitterContract()` - `setRewardToken()` Any compromise to the `_owner` account may allow a hacker to take advantage of this authority and approve or unapproved moderators, or change the addresses of necessary variables. In the contract Emissionor.sol the modifier `onlyMod` has authority over the following functions: - `initialize()` - `emitReward()` Any compromise to the an approved `moderators` account may allow a hacker to take advantage of this authority and affect the reward emitting. In the contract LockAddressRegistry.sol the role `_owner` has authority over the following functions: - `initialize()` - `setAdmin()` - `setTokenVault()` - `setFNFT()` - `setEmissionor()` - `addFarm()` Any compromise to the `_owner` account may allow a hacker to take advantage of this authority and set incorrect privileged contract addresses, potentially as EOA, or approve unintended addresses as farms. In the contract RewardWeight.sol the role `_owner` has authority over the following functions: - `register()` - `setRewardWeight()` - `updateReceiverStatus()` Any compromise to the `_owner` account may allow a hacker to take advantage of this authority and set or change receive rate and/or status. In the contract SplitterDistributor.sol the role `_owner` has authority over the following functions: - `register()` - `setRewardContract()` - `updateReceiverStatus()` Any compromise to the `_owner` account may allow a hacker to take advantage of this authority and change receiver status. In the contract TokenVault.sol 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 pause or unpause the functionality of the vault.  In the contract `RewardReceiver` the role `_owner` has authority over the following functions: - `setRewardToken()` Any compromise to the `_owner` account may allow a hacker to take advantage of this authority and improperly set the token received as rewards.

The contracts in scope are part of a broader system that includes substantial off-chain components. These off-chain components play an essential role, such as calculating the amount of tokens users can redeem, and they are not in scope for this audit. The scope of the audit treats off-chain components and third-party entities as black boxes and assumes their functional correctness. However, in the real world, they can be compromised and this may lead to lost or stolen assets.

The `getBalancesFromWallet()` function calls `_getWalletBalance(_walletAddress)`, which adds `FNFTbalance` with various ERC20 token balances. The meaning of adding tokens of different types and values is unclear and could be confusing to users.

The linked contracts import and use OpenZeppelin's `Counters` contract. OpenZeppelin has deprecated the usage of the `Counters` contract: https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4233

The `initialize()` function can be called multiple times. Prior initialization could be overwritten if called more than once.

The linked functions are equivalent to the compiler-generated getter functions for the respective variables.

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user stakes 100 deflationary tokens (with a 10% transaction fee) in a MasterChef, only 90 tokens actually arrive in the contract. However, the user can still withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction. Details on this kind of exploit: https://thoreum-finance.medium.com/what-exploit-happened-today-for-gocerberus-and-garuda-also-for-lokum-ybear-piggy-caramelswap-3943ee23a39f We notice that the current plan allows HEC, HEC/DAI, and HEC/USDC as the staking token, which is good for now. We want to ensure that the team does not plan to add any deflationary token(with transition fees) into the LockFarm pool.