NextGen audit details
- Total Prize Pool: $60,500 USDC
- HM awards: $41,500 USDC
- Analysis awards: $2,250 USDC
- QA awards: $1,250 USDC
- Bot Race awards: $3,750 USDC
- Gas awards: $1,250 USDC
- Judge awards: $6,000 USDC
- Lookout awards: $4,000 USDC
- Scout awards: $500 USDC
- Join C4 Discord to register
- Submit findings using the C4 form
- Read our guidelines for more details
- Starts October 30, 2023 20:00 UTC
- Ends November 13, 2023 20:00 UTC
Automated Findings / Publicly Known Issues
The 4naly3er report can be found here.
Automated findings output for the audit can be found here within 24 hours of audit opening.
Note for C4 wardens: Anything included in the 4naly3er or the automated findings output is considered a publicly known issue and is ineligible for awards.
Overview
NextGen
NextGen is a series of contracts whose purpose is to explore:
- More experimental directions in generative art and
- Other non-art use cases of 100% on-chain NFTs
At a high-level, you can think of NextGen as:
- A classic on-chain generative contract with extended functionality
- With the phase-based, allowlist-based, delegation-based minting philosophy of The Memes
- With the ability to pass arbitrary data to the contract for specific addresses to customize the outputs
- With a wide range of minting models, each of which can be assigned to a phase
Click here to read more about NextGen's features
NextGen Smart Contracts architecture
The NextGen smart contract architecture is as follows:
- Core: Core is the contract where the ERC721 tokens are minted and includes all the core functions of the ERC721 standard as well as additional setter & getter functions. The Core contract holds the data of a collection such as name, artist's name, library, script as well as the total supply of a collection. In addition, the Core contract integrates with the other NextGen contracts to provide a flexible, adjustable, and scalable functionality.
- Minter: The Minter contract is used to mint an ERC721 token for a collection on the Core contract based on certain requirements that are set prior to the minting process. The Minter contract holds all the information regarding an upcoming drop such as starting/ending times of various phases, Merkle roots, sales model, funds, and the primary and secondary addresses of artists.
- Admin: The Admin contract is responsible for adding or removing global or function-based admins who are allowed to call certain functions in both the Core and Minter contracts.
- Randomizer: The Randomizer contract is responsible for generating a random hash for each token during the minting process. Once the hash is generated is sent to the Core contract that stores it to be used to generate the generative art token. NextGen currently considers 3 different Randomizer contracts that can be used for generating the tokenHash.
a) A Randomizer contract that uses the Chainlink VRF.
b) A Randomizer contract that uses the ARRNG.io service.
c) A custom-made implementation Randomizer contract.
Links
Scope
Files and contracts in scope for this audit in the table below:
Out of scope
Anything but the files listed above is out of scope.
That includes OpenZeppelin, Chainlink, and ARRNG contracts as well as the contracts below:
smart-contracts/IMinterContract.sol
smart-contracts/INextGenAdmins.sol
smart-contracts/INextGenCore.sol
smart-contracts/IRandomizer.sol
smart-contracts/IXRandoms.sol
smart-contracts/NFTdelegation.sol
smart-contracts/IDelegationManagementContract.sol
Additional Context
- This code will be deployed to Ethereum mainnet at launch, and it is the only blockchain considered to be in scope for this audit.
- Deployment process
- Set up a collection ready for minting
- Call the createCollection(...) function on the Core contract.
- Call the setCollectionData(...) function on the Core contract.
- Call the addRandomizer(...) function on the Core contract.
- Call the setCollectionCosts(...) function on the Minter contract.
- Call the setCollectionPhases(...) function on the Minter contract.
Note: Once the process is finalized, you can airdrop tokens or mint tokens once the minting phases start.
- Trusted Roles that can interact with specific functions of the smart contracts and are set on the Admins Contract
- Global Admin
- Collection Admin
- Function Admin
- Artist
- How to use the VRF or the RNG smart contracts
- It's recommended to use the Goerli Network when you want to interact with the Chainlink VRF or the RNG smart contracts.
- For the chainlink VRF you need to create a subscription from the chainlink platform, fund the subscription and add the smart-contracts/RandomizerVRF.sol smart contract address as a consumer.
- For the ARRng.io smart contract you need to deploy the smart-contracts/RandomizerRNG.sol and send some eth to the smart contract address as the deposit funds on the smart contract will be used to pay for the generation of the random hash.
- The _saltfun_o is for future purposes and its currently not being used.
- We are aware of the price rounding errors when the Exponential Descending Sales Model is used and the minting cost is low, thus any finding on this is not valid.
- We are aware that we do not accept decimals when we set the sales percentages, thus any finding is not valid.
- We do not consider a DOS of the Ethereum network to be sufficient to warrant a finding valid.
Attack ideas (Where to look for bugs)
A non-exclusive set of attack ideas
- Access Controls and Permissions
- Consider ways in which addresses can be added to the Admin contract either without the specific approval of its owner or from a global admin or as a result of contract deployment.
- Consider ways in which the artist's proposed address can be maliciously altered after they were first proposed by the artist.
- Consider ways in which functions on all contracts can be called without having a specific role.
- Consider ways a user can escalate their authority beyond their role.
- Payments
- Consider ways in which payments can be altered so the funds will be sent to different addresses than the ones that were proposed by the artist.
- Consider ways in which the emergencyWithdraw() function does not send the funds to the Admins Contract owner.
- Consider ways in which payments will not be accepted by a SAFE(formerly Gnosis) wallet.
- Sales Models
- Consider ways in which the minting cost price will differ from the actual value based on the parameters set on the setCollectionCosts() function.
- Random Hash generators
- Consider ways in which the generator will not produce a hash value, besides the lack of funds on the VRF and RNG.
- Consider ways in which the hash value of a tokenid can be altered after it has already set.
- Consider ways in which the random hash is not returned by the Randomizer contracts, but it can be set directly from the Core contract.
- On-chain metadata
- Consider ways in which the on-chain metadata can be altered after a collection was frozen (locked).
- Updating details
- Consider ways in which the collection data can be altered after a collection was frozen (locked).
- Admin contract
- Consider ways in which the Admin contract address on all other contracts can be maliciously altered.
- Burn or Swap to mint functionalities
- Consider ways in which you can burn or swap a token from a collection that is different than the collection that was already set.
- Allowlist minting
- Consider ways in which an allowlist address can mint more tokens than what it is allowed to mint.
- Consider ways in which an address can bypass the merkle proofs and mint without having an allowlist spot.
- Consider ways in which an address can mint on behalf of an allowlist address without having a delegation.
- Consider issues with allowlist attacks across phases of allowlists.
- Consider issues with attacks relating to starting, stopping, restarting (adding) new phases of allowlists.
- Airdrop/Minting
- Consider ways in which the airdrop or minting functionalities incl. burnToMint(), burnOrSwapExternalToMint() etc. are not executed from the Minter Contract.
- Consider ways in which more than 1 token can be minted at the same time period for the Periodic Sale Model.
- Consider ways in which an address during the public phase can mint more tokens compared to what its allowed to mint (maxCollectionPurchases)
- MintToAuction
- Consider ways in which the token is not transferred to the final winning bidder of an Auction after the auction finishes (token approval to the AuctionDemo contract is needed) and the funds are not refunded to other bidders.
- Consider ways in which a cancelled auction bid does not return the funds back to the bidder.
- Consider ways in which the owner of the token will not receive the funds of the highest bid after an Auction is claimed.
- Smart Contract Wallets
- Consider if any functionality does not work with a SAFE (formerly Gnosis) wallet.
- Consider if any functionality will not work post ERC-4337.
Main invariants
Properties that should NEVER be broken under any circumstance:
- Admin roles can only be registered on the Admin Contract.
- Global Admins can only be registered by the Admin Contract owner.
- Function and Collection admins can only be registered by global admins.
- Specific admin roles can call the functions of the smart contracts.
- Only artists can sign their collections.
- NFTDelegation is the only delegation management contract that will be used.
- Payments can only be made when royalties are set, the artist proposes addresses and percentages, and an admin approves them.
- Once a hash is set for a specific token it cannot be altered.
- The emergencyWithdraw() function sends the funds to the admin contract owner.
- Once a collection is frozen (locked) its data cannot be altered.
- Airdrop/mint can only be done from the Minter contract.
- The random hash is calculated from a Randomizer contract.
- The highest bidder will receive the token after an auction finishes, the owner of the token will receive the funds and all other participants will get refunded.
Scoping Details
- If you have a public code repo, please share it here: https://github.com/6529-Collections/nextgen
- How many contracts are in scope?: 8
- Total SLoC for these contracts?: 1265
- How many external imports are there?: 28
- How many separate interfaces and struct definitions are there for the contracts within scope?: 5
- Does most of your code generally use composition or inheritance?: Inheritance
- How many external calls?: 28
- What is the overall line coverage percentage provided by your tests?: 100
- Is this an upgrade of an existing system?: No
- Check all that apply (e.g. timelock, NFT, AMM, ERC20, rollups, etc.): NFT, Timelock function
- Is there a need to understand a separate part of the codebase / get context in order to audit this part of the protocol?: No
- Please describe required context:
- Does it use an oracle?: Yes - in come cases
- Describe any novel or unique curve logic or mathematical models your code uses: You can find info about the Sales Models that use mathematical models here: https://seize-io.gitbook.io/nextgen/for-creators/sales-models
- Is this either a fork of or an alternate implementation of another project?: No
- Does it use a side-chain?: No
- Describe any specific areas you would like addressed: See above
Tests
Sample hardhat tests are provided.
- Download the github repo
- Open command prompt and navigate to the hardhat folder
- Install hardhat using
npm i
- Compile smart contracts using
npx hardhat compile
- If you get
Error HH502 then please upgrade to the laetst hardhat - npm up hardhat
- Run the tests that exist within the test folder using
npx hardhat test
Slither
To run slither use the command slither smart-contracts