✨Features
Collections
Admins can create a NextGen ERC721 collection by specifying the collection name, name of the artist, description of the collection, website, artist’s ETH address, license, base URI, library used, the script that generates the generative art, and total supply of the collection. Once a collection is created, an id is auto-assigned to the collection.
Each collection has its own custom token id based on the ID of the collection.
For example: the collection with ID #1 reserves the token ids starting at 10000000000 while collection with ID #2 reserves the token ids starting at 20000000000 and so on.
This allows for easier display and segregation of collections on websites.
The extremely large tokenID space allows for experimentation with very large non-traditional collections
Admins can update collection or token data until the collection is locked.
Admins can reduce the supply of the collection, after minting is completed, to the existing minted supply.
Admins can lock collections so they can never be updated by anyone on any dimension in the future (collection data and metadata, token data, token image URI and attributes).
On-chain/Decentralization
The default model of a NextGen collection is that it is 100% on-chain, in a similar manner to reference generative art collections like Autoglyphs and Art Blocks.
The basic features of the on-chain nature of the contract are similar: the script, library link and seed are stored on-chain so any image can be rendered in the future based directly from data in the contract.
The Randomizer contract generates a random hash for each minted token that is stored on-chain on the Core contract so as to be used by the generative script to generate the final output.
NextGen also has three features to bring some additional information on-chain:
The tokenURI on NextGen has been modified to support off-chain and on-chain metadata, Admins can change the way the metadata for a collection are returned when the tokenURI function is called.
NextGen can support on-chain metadata.
Once an admin enables on-chain metadata for a collection, NextGen starts producing an on-chain .json object for each token when the tokenURI function is called.
The on-chain metadata .json object returns the following parameters: token name, description, image, attributes and animation_url. Admins can store an image URI along with its attributes for each token on-chain until the collection is locked.
Artists can sign their collections on-chain with their Ethereum address or ENS for enhanced provenance. This means that the signature of an artist for a specific collection be on-chain along with the collection.
Most generative collections point to a rendered version of the image on their server for the convenience of marketplaces and other services.
NextGen does the same basic approach to support visualization of the collection during minting.
NextGen however has added a feature that allows the admin post-minting to update the off-chain metadata URI of a collection so as to include a rendered image on a decentralized storage platform like IPFS or Arweave to eliminate any dependence at all on the creators infrastructure post-mint.
Customization
A key approach in the NextGen is to be able to pass arbitrary data about minting wallets (in an allowlist). This allows multiple new directions to be explored in on-chain generative tokens such as:
Purely customized on-chain tokens like university certificates that may include personal data or may adjust based on personalized data (e.g. color palettes that change based on a student’s grade).
Generative Art collections that are not purely random mints, but instead incorporate information or metadata about the minter in the output parameters or in the weighting of the randomization of the output parameters.
Other highly exploratory areas.
The generative script - besides the tokenId and random hash - includes the tokenData variable which represents an array that stores additional arbitrary data for each tokenId on-chain.
The tokenData can be passed to the smart contract when the minting function is being executed during the allowlist phase and are optional.
The main purpose of the tokenData is to generate more personalised tokens based on the specific characteristics of the minting wallet.
Admins can update the tokenData that are stored on-chain (before a collection is frozen)
Minting Process
NextGen’s default minting process is allowlist and phase based (like The Memes)
The goals of allowlists are to:
Separate collection pricing from bot deterrence
Reduce wasted gas costs
Allow artists/creators to select their collectors (when relevant)
A collection can have an arbitrary number of phases (starting and ending times), each with their own allowlist.
After phases are completed, the collection can have an optional public sale period
Public mints without any allowlist phases are also possible on the contract
NextGen has native integration of NFTDelegation.com, the most advanced NFT delegation on-chain contract. This allows collectors to safely mint from hot wallets without exposing their NFT vaults.
NextGen allows for 6 different minting models. These models can be combined within a single collection drop by using phases.
Airdrops: NFTs are airdropped directly to a list of collectors
Fixed Price Sale: The minting cost is fixed during the minting phase.
Exponential Descending Sale: At each time period (which can vary), the minting cost decreases exponentially until it reaches its resting price (ending minting cost) and stays there until the end of the minting phase.
Linear Descending Sale: At each time period (which can vary), the minting cost decreases linearly until it reaches its resting price (ending minting cost) and stays there until the end of the minting phase.
Periodic Sale: Mints are limited to 1 token during each time period (e.g. minute, hour, day). The minting cost can either stable or have a bonding curve (increase) over time. This allows for long-lived or experimental mints. Any unminted tokens from previous periods are transferred for minting in upcoming periods.
Burn-to-Mint: Mints in this model can be one of two types:
If a user burns a NextGen token, then tokenData passes to the new token
If a user burns a non-NextGen token, that acts like a simple mintpass, tokenData can pass to the newly minted token during minting
Mint-to-Auction: Mints are limited to 1 token during each time period (e.g. minute, hour, day). Once a token is minted its directly send to an auction.
All parameters for the sales models are customizable per collection.
The sales models can be combined with phased allowlists to execute very complex drops. For example:
Phase 1: Airdrop the three pieces to collectors the artist chooses
Phase 2: The next ten pieces in a collection are sold, one per day, at a higher fixed price
Phase 3: The next 10 are sold at an exponentially descending price
Phase 4: The next 77 are sold at a fixed price
Phase 5: The next 50 are accessible only by burning another token
Phase 6: The last 50 are a fixed price public mint
Learn more about Sales Models here.
Accounting
Primary and secondary (royalty) splits can be set on a collection-by-collection basis.
These can be set directly by the admin
Alternatively, they can be proposed by the artist and accepted by the admin
Artists can propose separate addresses for primary sales proceeds and secondary royalty proceeds, which can be accepted by the admin.
Admins can send collected primary proceeds to the artist directly from the smart contract
Permissions
Admins can register additional global admins, collection admins and function admins on the Admin Contract.
Admins, depending on their access levels, can interact with specific functions on the Core, Minter and Admin contract.
While the Core contract is all on-chain and never changes, admins can update the smart contract addresses of the Minter, Admin and Randomizer contracts to provide new features.
Last updated