Batch Minting Non-Fungible Tokens

Enabling infinite ERC-721 token creation with the EIP-2309 Consecutive Transfer Extension.

One of the most powerful features of the Cargo platform is the ability for creators to create an infinite amount of digital collectibles (ERC-721 non-fungible tokens, aka NFTs) in one transaction. This is huge for the NFT community and takes NFT creation to the next level. This powerful feature is enabled by EIP-2309.

The Consecutive Transfer Extension may at first glance seem simple, but with this one event we now have a standardized method in which decentralized applications can use to track ownership of a massive amount of NFTs.

The Consecutive Transfer Extension solves one part of the NFT scalability problem and efficient data structures can solve the rest. The original ERC-721 specification can't scale. With Cargo you can create 2^255 NFTs in one transaction, but it's absolutely impossible to emit that many Transfer events (part of the original standard). One would have to iterate 2^255 times emitting a Transfer event for each iteration of the loop. This transaction is bound to fail. However, with the Consecutive Transfer extension you could emit one event to track the creation of all 2^255 NFTs. It could look something like this:

function mint(uint amount, address from, address to) public {
// Create NFTs and assign ownership
// ...
// Emit Consecutive Transfer Event
emit ConsecutiveTransfer(lastMintedId + 1, lastMintedId + amount, from, to);
}

The lastMintedId would be the last consecutive token that was created. For example lastMintedId would initially be 0 . After creating the first NFT it would become 1 . Then if you created five more NFTs the range of NFTs created would be 2 to 6 .

Backwards Compatibility

This extension was written to allow for the smallest change possible to the original ERC-721 spec while still providing a mechanism to track the creation, transfer, and deletion of a massive amount of tokens. While it is a minimal change the effects on platforms that only use the original Transfer event to index token ownership would be severe. They would not be properly recording token ownership information that could be known by listening for the ConsecutiveTransfer event. For platforms that wish to support the ConsecutiveTransfer event it would be best to support both the original Transfer event and the ConsecutiveTransfer event to track token ownership.

For additional details read the full ERC-721 Consecutive Transfer Extension EIP.

Do you need to mass create collectibles? We can help.

Email us at: contact@cargo.build