Equilibrium Quantum addendum

In the contract `LPPool`, 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 the token address, set the sign address, and set the LP token address.  The `LPPool` contract enables users to stake their `LP` tokens to earn rewards. Users can unstake their `LP` tokens using the `unDepositLP()` function, but only after obtaining signatures from the project team. If the signer's private key is compromised, users' `LP` tokens may be at risk, potentially leading to losses for the users. --- In the contract `EQNFT`, 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 or update the mint address status, as well as set the base URI.  In the contract `EQNFT`, the role `mintAddress` has authority over the functions shown in the diagram below. Any compromise to the `mintAddress` account may allow the hacker to take advantage of this authority and mint a new token to an address.  --- In the contract `NodePool`, 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 the token address, as well as set the sign address.  --- In the contract `Store`, 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 the admin address, set buy gas allocation ratios, set admin transfer address, set buy NFT USDT allocation admin ratio, set buy gas allocation addresses, set the USDT token address, set the NFT token address, set the token address, and set the buy NFT USDT amount.  --- In the contract `AllowContract`, 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 the allowed status for an address list.  --- In the contract `Ownable`, the role `_creator` has authority over the functions shown in the diagram below. Any compromise to the `_creator` account may allow the hacker to take advantage of this authority and transfer the creator role, remove an owner from the owners list, set the required signatures, and add a new owner.  --- In the contract `Sign`, 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 the allow contract address, set the verify address, and set the user nonce address.  --- In the contract `UserNonce`, 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 user's nonce, set allowed contract address, update user's last block number, and set the lock block.  --- In the contract `EQ`, 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 mint new tokens to specified addresses, set the node mint address, set the pool mint address, and set the tax address. 

Some or all tokens are sent to the contract deployer or one or several externally-owned account (EOA) addresses. This is a centralization risk because the deployer or the owner(s) of the EOAs can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

According to the design of the `_beforeTransfer()` function, when `to == pairAddress`, a fee will be charged for the transaction. ```solidity if (to == pairAddress) { require( block.number != lastTransactionBlock[from], "Cannot buy/sell in the same block" ); taxFee = (amount * dexTaxFee) / 10_000; require(amount > taxFee, "Amount less than tax fee"); super._transfer(from, taxAddress, taxFee); emit TransferTaxPaid(from, taxAddress, taxFee); } ``` The same condition applies to adding liquidity, and the contract does not have a whitelist mechanism. This means that anyone (including the team) adding liquidity will incur a fee, which may result in the ratio of the two tokens in the pair contract not meeting expectations after the team first adds liquidity.

Owners may fail to call centralized methods. For example, setting a variable to the zero address or when certain conditions are not met. If owners fail to call a method, the entire transaction will roll back, and the current owner's `action.signatures` will not be updated. However, the value for owners who previously voted will be set to true. This might cause an issue: if the failure was due to unmet conditions (e.g., EQToken's `mint()` method requires `mintNodeAddress` to be set), once the condition is met, only one owner needed to execute the failed method to complete the operation. This is because the early votes by owners remain intact since they were not cleared when the centralized method failed. Have you considered this case?

The project design may not be compatible with non-standard ERC20 tokens, such as deflationary tokens or rebase tokens. The functions use `transferFrom()`/`transfer()` to move funds from the sender to the recipient but fail to verify if the received token amount matches the transferred amount. This could pose an issue with fee-on-transfer tokens, where the post-transfer balance might be less than anticipated, leading to balance inconsistencies. There might be subsequent checks for a second transfer, but an attacker might exploit leftover funds (such as those accidentally sent by another user) to gain unjustified credit.

A sandwich attack can occur when an attacker notices a transaction involving token swaps or liquidity additions that lacks slippage restrictions or minimum output amount settings. The attacker can exploit this by frontrunning the transaction to purchase one of the assets, thereby manipulating the exchange rate, and then backrunning the transaction to sell the asset for a profit. The referenced functions are invoked without setting slippage restrictions or minimum output amounts, making transactions that trigger these functions particularly vulnerable to sandwich attacks, especially when large input amounts are involved.

The contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity IPancakeRouter02 public immutable pancakeRouter; address public tokenAddress; address public usdtTokenAddress; address public nftTokenAddress; ``` - The contract `Store` interacts with the above third party contracts. ```solidity address public immutable pairAddress; address public immutable routerAddress; address public usdtAddress; ``` - The contract `EQToken` interacts with the above third party contracts. ```solidity address public tokenAddress; address public lpTokenAddress; ``` - The contract `LPPool` interacts with the above third party contracts. ```solidity address public tokenAddress; ``` - The contract `NodePool` interacts with the above third party contracts.