Zoniqx security record

The safeTransferFrom method incorrectly handles the allowance verification due to a parameter mismatch and a logical error in the associated _spendAllowance method. This issue arises because the function uses a hardcoded zero (0) for the token ID instead of the actual token ID provided to the function, and there's a mix-up between the amount and id parameters in _spendAllowance.Impact: This flaw allows users (e.g., delegated operators) to potentially transfer tokens beyond their authorized allowance, leading to unauthorized asset movement and breach of trust assumptions in the token management system. It undermines the ERC-1155 standard's security guarantees regarding token transfers and allowance management.

The erc7518 specification states that only unlocked assets can be transferred or used by users who own them, however the safeBatchTransferFrom() allows the users to move their funds as this method is directly inherited from the ERC1155Upgradeable contract and is not overridden like safeTransferFrom() that implements additional checks like canTransfer to ensure correct restrictions and signatures are provided before transfers are made.

The lockTokens method in the contract lacks necessary authorization checks to verify if the caller has the right to lock tokens for the specified account. This allows any user to lock any amount of tokens belonging to any account, leading to potential misuse where tokens can be frozen maliciously without the owner's permission.

The naming of the forceTokenUnlock() and _forceUnlockTokens functions in ERC7518.sol are inconsistent, which could lead to confusion about their functionality.

The methods listed above do not check for the validity of the incoming function arguments which might result in setting invalid values such as for the payout address or an excessively large floor price, potentially leading to loss of funds or failed transactions.

The contracts and methods listed above perform critical functionality to manage users' assets and funds. However, there is no supporting documentation provided for NatSpec that explains the business needs and limitations of the applications which can cause misunderstandings and threaten users' operations.

The batchPayout() function lacks a non-reentrant modifier, potentially allowing reentrancy attacks which could lead to unexpected behaviors or exploits.

Redundant checks for the to address in the _payout() function can lead to unnecessary gas consumption and code complexity. This check is already placed inside ERC20Upgradeable contract that handles the payout's transfer call underneath.

Some functions in the listed contracts include arguments or return variables that are never used, leading to unnecessary code complexity and gas costs. For instance, the data variable in freeze() and unfreeze() is never utilized in the method for operation. Similarly, in the getDealsCount(), the return value deals is never used.

The order of arguments in verifySignature() _transferTokensToInvestor() is unconventional and might cause confusion, potentially leading to incorrect implementations or usage.