Quantelica

The contract has a critical logic flaw in the removeSubcollection function, where tokens from other subcollections can be mistakenly burned. The iteration over token IDs for removal does consider that token IDs are the startIndex and endIndex of a subCollection but that’s not the case for any subcollection. As a result, this could lead to the unintended burning of NFTs that do not belong to the subcollection being removed, causing a severe impact on token ownership and integrity of the protocol.

The fulfillRandomWords function lacks proper access control, allowing any external entity to call this internal function. As a result, there is a critical security vulnerability where an unauthorized entity could potentially spoof a VRF response with arbitrary random values. It is crucial to restrict the invocation of this function to only trusted entities, specifically the VRFConsumerBase.rawFulfillRandomness method, to ensure the integrity of the VRF process.

The contract exhibits a potential security risk due to a missing check for whether the destination address (to) is blacklisted or not in the batchTransfer and mintGoldenToken function. Without proper validation, blacklisted addresses can potentially receive tokens through batch transfers, leading to a bypass of the blacklist mechanism. This oversight poses a security vulnerability, as it allows tokens to be transferred to blacklisted addresses, contrary to the intended restrictions.

The contract has an issue where the burn function attempts to delete a tokenCID, but the corresponding set function _setTokenCID is marked as private and cannot be directly called by the burn function. As a result, there is no mechanism in place to set or update the tokenCID, making it impossible to delete the CID within the burn function. This limitation hinders the contract's functionality and could lead to undesired consequences.

The contract has a high-severity issue in the burn function where it fails to check whether the specified token exists or not before attempting to burn it. This absence of a pre-check on token existence creates a critical vulnerability, as attempting to burn a nonexistent token could lead to unexpected behavior, compromising the integrity of the contract and causing potential disruptions in token ownership.

LM Internal Functions(except isValidDepositAmount() function) in LoanManager.sol are never called from within contracts but yet declared public. Their visibility can be made external to save gas.

Several functions within the contract lack necessary checks and verifications, potentially leading to unintended behaviours or vulnerabilities. These missing checks can impact the contract's security, correctness, and adherence to intended rules. It's crucial to incorporate these checks to ensure proper functionality and prevent unauthorized or erroneous actions.

Custom errors reduce the contract size and can provide easier integration with a protocol. Consider using those instead of require statements with string error.

In the case of stable coins, the hierarchy of authority plays a crucial role and our team recommends that the roles with privileges must be given to the accounts with proven authority and functions like “Minting” and “Burning” must be used cautiously because once these functions are called on the mainnet then could be no minting or burning. Hence, it will be an irreversible change.

Several critical functions within the contract lack validation checks to ensure that zero addresses are not accepted as input parameters. This oversight can lead to unintended behavior, security vulnerabilities, and potential exploitation if malicious actors pass zero addresses as arguments to these functions.