CertiK reviewed NEXTYPE (NEXTYPE.FINANCE - Ⅳ) on 30 Aug 2022: 15 findings, 0 critical; 2 marked fixed, 13 acknowledged.
Report hosted on skynet.certik.com.
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 3 | 0 |
| Medium | 0 | 1 | 1 |
| Low | 0 | 9 | 1 |
In the contract `HeroBlindBox`, the role `admin` has authority over the following functions: - function setPlatformAddress(), to set a new `platformAddress` to receive the buying tokens or ETH. - function setBoxStatus(), to set the `boxStatus` to control the `boxPurchase()` is open or not. - function setBoxInfo(), to set the box information which contains a batch of NFTs. - function setBoxRoundCurrent(), to set the current round number. - function setBoxPurchaseLimitList(), to set the `boxPurchaseLimitList` in a round. In the contract `HeroNFT`, the role `admin` has authority over the following functions: - function mintItem(), to mint a new NFT to the recipient with a `propertyId`. - function mintMulti(), to mint several NFTs to the recipients with `propertyId`. In the contract `TokenClaim`, the role `admin` has authority over the following functions: - function claimTokens(), to transfer a number of tokens from the contract to the recipient. In the contract `Trusteeship`, the role `admin` has authority over the following functions: - function setFeeTo(), to set the address to receive fees. - function setFeeAmount(), to set the `FeeAmount` for a NFT. - function addNftBalance(), to add a NFT with `_propertyId` to the `nftList[_toAddress][_nftToken]` as the balance of the `_toAddress`. - function batchAddNftBalance(), to add several NFTs with `_propertyId` to the `nftList`. - function resetNftBalance(), to reset the `nftList` of an address. - function retrieveAuthorization(), to make a NFT retrievable. - function batchRetrieveAuthorization(), to make several NFTs retrievable. - function batchBurn(), to burn several NFTs. In the contract `UsdtClaim`, the role `admin` has authority over the following functions: - function setFeeAmount(), to set the `FeeAmount` for a NFT. - function setfeeTo(),to set the address to receive fees. - function setAllowedTokenList(), to set the `allowedTokens`. - function addTokenBalance(), to add a new token to the `allowedTokens`. - function setTokenBalance(), to set the `tokenBalanceList[_token][_user]`. - function addTokenBalanceMulti(), to set the balances of tokens to several addresses. Any compromise to the `admin` account may allow a hacker to take advantage of this authority.
In the contract `HeroBlindBox`, the role `owner` has authority over the following functions: - function setAdminList(), to set the addresses of the `admin` role. In the contract `HeroNFT`, the role `owner` has authority over the following functions: - function setBaseURI(), to set the URI. - function setAdminList(), to set the addresses of the `admin` role. In the contract `TokenClaim`, the role `owner` has authority over the following functions: - function addAllowedTokens(), to add a token to the `allowedTokens` list. - function withdrawTokens(), to transfer tokens from the contract to an address. - function setAdminList(), to set the addresses of the `admin` role. In the contract `Trusteeship`, the role `owner` has authority over the following functions: - function setAdminList(), to set the addresses of the `admin` role. In the contract `UsdtClaim`, the role `owner` has authority over the following functions: - function setAdminList(), to set the addresses of the `admin` role. - function addAllowedTokens(), to add a token to the `allowedTokens` list. Any compromise to the `owner` account may allow a hacker to take advantage of this authority.
People who buy NFTs later have already learned the type of NFTs that have been sold earlier in each round, so the probability of success is different when two users are trying to buy the same kind of NFT, which is unfair.
All of the ERT tokens are sent to the contract deployer when deploying the contract. This could be a centralization risk as the deployer can distribute ERT tokens without obtaining the consensus of the community. Any compromise to the deployer account may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.
In the `HeroBlindBox`, users buy NFTs with random `propertyId` in a range set by the privileged roles. In the `Trusteeship`, users could put their NFTs into the contract and then retrieve them only if they have been approved by the privileged roles, each step would take fees. In the `TokenClaim` and `UsdtClaim`, the privileged roles could change any addresses' balances and transfer tokens to them. We would like the client to provide with us more information to understand the financial model of these contracts.
The logic of functions `boxPurchase()` is too complex and contains many loops. Loops that do not have a fixed number of iterations, for example, loops that depend on storage values, have to be used carefully. Due to the block gas limit, transactions can only consume a certain amount of gas. Either explicitly or just due to normal operation, the number of iterations in a loop can grow beyond the block gas limit which can cause the complete contract to be stalled at a certain point. This may not apply to view functions that are only executed to read data from the blockchain. Still, such functions may be called by other contracts as part of on-chain operations and stall those. Please be explicit about such cases in the documentation of your contracts.
There is no check in `setBoxRoundCurrent()` to prevent from the duplicated `_round` number, besides, the `_round` number could be set arbitrarily, and users cannot know how many rounds have been paased.
It is now well understood that the difficulty or timestamp is not a source of randomness. They can be manipulated if the attacker is also a miner.
In the contract `UsdtClaim` and `Trusteeship`, the `admin` role could add balances to addresses, and eventually, these assets could be transferred out from the contract, however, the source of the fund is unknown.
In the contract `orderList`, the `orderList[orderId]` will be marked as `true` when an `orderId` is claimed, however, the `orderId` could be arbitrarily set by the `admin` role when calling the `claimTokens`. Besides, in the contract `Trusteeship` and `UsdtClaim`, the use of `orderList` is confusing to us as well. Hence we would like the client to provide with us more information about the use of the `orderList` in `TokenClaim`.
The `propertyId` is set manually when minting a new token by the admin role, yet multiple `tokenid` can correspond to the same `propertyid`, in fact, this is the feature that can be achieved by ERC1155. We would like the client to provide with us more information about the use of the `propertyId`.
Transfers should be approved in the function `boxPurchase` or the transactions may fail.
There are several unknown implementations in this protocol: - IERC721(_nftToken).transferFrom - IERC20(_token).transfer The scope of the audit treats 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, etc.
The report names a repository or files. Open the report to see its scope.
Repository and files the report names (6)
1,044 projects reviewed · 1,375 reports · latest May 2025
See CertiK’s auditsSomething wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us