Equilibrium Quantum security record

Maps are never `empty` in Solidity. So if someone accesses an item which has been deleted, the transaction will not revert but instead return the zero value for that datatype. If a mapping (or dynamic array) is inside a struct and the struct is deleted, the mapping or array will not be deleted. With the exception of deleting an array, the delete keyword can only delete one storage slot. If the storage slot contains references to other storage slots, those won’t be deleted. Due to historical data(`action.signatures`) not being cleared, the owner is unable to execute previously executed calls. ```solidity require(!action.signatures[msg.sender], "Ownable: action already signed by caller"); ``` Reference: - https://www.rareskills.io/post/smart-contract-security - https://docs.soliditylang.org/en/latest/types.html#delete

The `transferFrom` function within the smart contract contains a critical security issue related to how allowances are handled. When a spender initiates a `transferFrom` call, the intention is for the smart contract to transfer an amount of tokens from the owner's balance to a third-party address, deducting the same amount from the spender's allowance. However, due to the current flawed implementation, the amount actually deducted from the spender's allowance can be more/less than the amount transferred if fees are involved. - For instance, if the spender is authorized to spend 100 tokens and they execute a `transferFrom` for that amount, the system may only reduce the allowance by 90 tokens to account for fees taken from the transferred amount, not from the spender's allowance. - For instance, if the spender wants to spend 90 tokens and they execute a `transferFrom` for that amount, the system may reduce the allowance by 100 tokens to account for fees. This creates a loophole where the spender can end up spending more/less allowance than expected.

The tokenomics of `EQToken` prohibit users from buying and selling `EQToken` within the same block. Specifically, when users purchase tokens, the current block number is recorded as `lastTransactionBlock[user]`. This block number is then used to determine if a selling operation is attempted within the same block. ```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); } if (from == pairAddress) { lastTransactionBlock[to] = block.number; // Update the last transaction block for the user } ``` However, when users try to sell tokens, malicious users can exploit this by swapping or skimming tokens to their own address, leading to a denial of service (DoS) for the seller.

Generally, the base URI for NFTs is used to specify the base path for all NFT metadata. It simplifies metadata management by allowing access to each NFT's specific metadata by appending the token ID to the base URI. This helps maintain consistency in organizing and accessing metadata. However, in the contract, the `baseURI` variable is assigned a value but is not used elsewhere.

The purpose of the `unchecked` block is to explicitly skip overflow checks to improve performance. However, in the following code, the `unchecked` block itself doesn't perform any mathematical operations, so it is meaningless in this case. ```solidity uint256 nonce = userNonceList[_user]; uint256 newNonce = nonce + 1; unchecked { userNonceList[_user] = newNonce; } ```

The `getAndIncrementUserNonce()` function already has the following requirements, and when `lockBlock` is 0, the two requirements are the same. ```solidity require( block.number >= lastBlock, "Current block number is less than last block." ); require( block.number - lockBlock >= lastBlock, "Operation locked for this block." ); ```

The cited address input is missing a check that it is not `address(0)`.

The `LPPool` contract and the `Store` contract have both imported the `ReentrancyGuard.sol` contract to utilize its anti-reentrancy functionality. However, their import paths differ, indicating that one of them may be incorrect.

The `buyGas()` function is responsible for distributing tokens that users have purchased. However, there is a potential precision loss issue when calculating related values by multiplying each ratio. ```solidity for (uint256 i = 0; i < 4; i++) { allocTokenAmountList[i] = (tokenAmount * buyGasAllocRatioList[i + 1]) / 10000; } ``` This can lead to a small amount of tokens being locked in the contract.

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects.