LiveArtX security record

Functions which are never called internally within the contract should have external visibility. --- ```solidity=103 function totalSupply() public view returns (uint) { ``` ```solidity=107 function tokenURI(uint256 tokenId) public view virtual override returns (string memory) { ``` --- ```solidity=117 function params() public view returns (Params memory) { ``` --- ```solidity=191 function burn(uint256 tokenId) public { ``` --- ```solidity=200 function setAdmin(address _admin) public onlyOwner { ``` --- ```solidity=206 function setBaseURI(string memory _baseURI) public onlyAdmin { ``` --- ```solidity=210 function setBeneficiary(address _beneficiary) public onlyAdmin { ``` --- ```solidity=214 function reveal(string memory _baseURI) public onlyAdmin { ``` --- ```solidity=222 function setParams1(bytes32 _merkleRoot, uint256 _price, uint256 _maxAmount, uint256 _startTime, uint256 _endTime) public onlyAdmin { ``` --- ```solidity=233 function setParams2(bytes32 _merkleRoot, uint256 _price, uint256 _maxAmount, uint256 _startTime, uint256 _endTime) public onlyAdmin { ```

Anyone can call functions `mint1()` and `mint2()` on behalf of another account, as long as they provide a valid `merkleProof` corresponding to inputs `index`, `account`, and `maxAmount`. If the functions are called once, and the `amount` value does not exceed `maxAmount`, then the inputs can be used to call the function again by another entity. Additionally, it appears that if `maxAmount1` (or respectively, `maxAmount2`) are met before a user's `maxAmount` is met, then the specified `account` cannot mint the `maxAmount` of tokens for which they have been whitelisted. Please clarify whether each user's `maxAmount` is calculated so that the total sum of `maxAmount` values for all whitelisted users does not exceed the `maxAmount1` or `maxAmount2` amount respectively.

One or more state changes do not emit events to pass the changes out of chain. ```solidity=201 admin = _admin; ``` ```solidity=224 price1 = _price; ``` ```solidity=225 maxAmount1 = _maxAmount; ``` ```solidity=226 startTime1 = _startTime; ``` *Note: Only a sample of 3 state variable assignments (out of 4) are shown above.* --- ```solidity=235 price2 = _price; ``` ```solidity=236 maxAmount2 = _maxAmount; ``` ```solidity=237 startTime2 = _startTime; ``` *Note: Only a sample of 3 state variable assignments (out of 4) are shown above.*

The given input is missing a check for a non-zero value.

Addresses should be checked before assignment or external call to make sure they are not zero addresses. ```solidity=99 admin = _admin; ``` - `_admin` is not zero-checked before being used. --- ```solidity=100 beneficiary = _beneficiary; ``` - `_beneficiary` is not zero-checked before being used. --- ```solidity=201 admin = _admin; ``` - `_admin` is not zero-checked before being used. --- ```solidity=211 beneficiary = _beneficiary; ``` - `_beneficiary` is not zero-checked before being used.

The contract has an unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to an ambiguity when debugging as compiler-specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

The `SafeMathUpgradeable` library is used unnecessarily. With Solidity compiler versions 0.8.0 or newer, arithmetic operations will automatically revert in the case of integer overflow or underflow.

The function `params()` appears unnecessary since all state variables are public and have getter functions.