Deploy Your First ERC721-C Contract in Less Than 5 Minutes!

The FreeNFT Minting Press makes deploying and managing your own NFT collection as simple as a few clicks, with a user-friendly GUI that guides you through the entire process.

The first step is to navigate to https://developers.freenft.com/ where you’re presented with 2 cards. Click Deploy New Contract

This brings you to the contract deployment flow. Each step has tooltips and information to help you make decisions on what configurations to choose.

Contract Primitive

The first is what we call the “Contract Primitive” — the base of the contract you’re going to deploy. The choices are:

• ERC721-C — This is a basic ERC721-C contract, which extends the ERC721 standard with additional capabilities to allow for more control over your tokens. Note that the basic ERC721-C contract does not support token burning.
• Adventure ERC721-C — Extends the ERC721-C standard even further, enabling on-chain quest mechanics for gaming projects with more complex needs, or for projects where token burning features are required.

For this example, we will choose Adventure ERC721-C.

Distribution

Next is the Distribution mechanism. There are 2 choices here: Airdrop directly to users (developer subsidizes the transaction fees) or Merkle claim (users are added to a list curated by the developer and they pay gas to claim their tokens). Note that when using the airdrop distribution type a complete distribution of your collection is guaranteed, whereas with merkle distribution there is no guarantee that every whitelisted user will claim their NFTs.

To successfully distribute a merkle claim collection, you will need to generate a merkle tree and distribute merkle proofs to users. There are many open sourced libraries that can facilitate this, and hosting can be as simple as pinning to IPFS or as complicated as serving individual merkle proofs to users via an API you host.

The merkle claim adds more complexity to the process for end users and yourself, but socializes the cost of distribution, whereas the airdrop is more expensive for the developer but simplifies the process for everyone involved.

Royalty Type

As of the writing of this article, there are 4 programmable royalty types you can choose from:

• Basic — 100% of royalties go to the creator defined address at a royalty rate specified by the creator
• Immutable Minter — 100% of royalties go to the address that minted the token. The creator sets the royalty rate, and the rate is unchangeable after deployment
• Mutable Minter — 100% of royalties go to the address that minted the token. The creator sets the default royalty rate, but the minter can change the royalty for their own tokens after minting.
• Shared — Royalties are sent to a payment splitter where an unchangeable split is able to be claimed. The creator determines the split percentage between themselves and the minter, as well as the overall royalty rate. Royalty funds accumulate in the payment splitters, and may be claimed at any time.

Security Settings

You can then decide on your Security Level. This is the heart of the ERC721-C protocol, allowing you to define allowlists and create restrictions which guarantee compliance with the rules you set. A Security Level of 0 acts as a standard ERC721 and grants no explicit royalty protections, so if you would like to have basic royalty protections or other restrictions you must select at least Level 1. Tokens deployed with Level 1 are automatically set to use the Limit Break managed Operator Allowlist, which we will use for our contracts. If you would like to modify this, you can do so post deployment.

To fully guarantee royalty payment and compliance with other applicable rules, ERC721-C implements more restrictive policies, enabling and disabling OTC trading and receiver restrictions.

• OTC trading in this case is the ability for the owner to transfer the token directly, allowing for direct trades peer to peer. Restricting this is advisable if there is a large portion of your trading volume happening off exchange, where royalties cannot be enforced.

Restricting receivers comes in two levels:

• Enforcing the receiver does not have code at its address. This restriction attempts to enforce the receiver is not a smart contract. However, this can be defeated by clever tactics such as deterministic contract deployment or triggering transfers in a constructor. If this concerns you, consider the next restriction level that follows below.
• Enforcing the receiver signs a message and submits to an on chain EOA Registry. This is the ultimate proof that a user has control over a private key and the receiving address is an EOA. This is as close to impossible as one can get to circumventing an EOA receiver requirement.

For more detailed information on the security settings, you can review the original Medium post, or reference the github.

Metadata & Collection Settings

From here, you enter the standard data you need when creating an NFT such as the intended contract owner, collection name and symbol, the URI where your metadata is stored and an optional suffix. For security reasons, it is strongly encouraged to make the contract owner a multi-sig wallet with at least 2/3 signing keys required. If starting with an EOA contract owner, it is strongly encouraged to ultimately transfer ownership to a multi-sig.

The URI can be an IPFS or HTTP URL, but all token IDs must have a corresponding metadata file labelled by their token ID. An example of this is below the Metadata Suffix for you to review before moving on to the next step.

Note: You are responsible for your own metadata and image hosting.

Supply & Mint Parameters

Next you set the supply parameters. Depending on your distribution mechanism, you can set the amount for users to be able to claim, the maximum amount you can distribute via airdrop. All contracts come with a privileged owner mint, allowing for the option of the owner to mint some set amount directly.

The ultimate limiter is the “Max Supply, so if you were to launch a token with 10,000 max supply, 10,000 owner mints and 10,000 airdrops, if the owner mints 1,000 tokens there will only be 9,000 left for airdrop.

You can also define the max simultaneous quests at this step if you have Adventure ERC721-C as the primitive, allowing for “soft staking” of up to 100 quests at a time for a token per adventure smart contract.

Royalties

The final configuration step is royalties. Here you will enter a number in BPS (100 = 1%) and the calculated percentage is displayed below. Once this is filled, you will see a preview modal pop-up that displays your contract configuration. Verify all the settings are what you expect, and submit the transaction.

Note: You can connect your wallet at any step during the process.

To submit the transaction, click the “CREATE CLONE” button.

And that’s it!

Once our transaction is confirmed, we’ll receive a confirmation window where we can see the contract address, view it on the network’s block explorer, or review and modify the collection. Our fully configured NFT has been deployed on Sepolia at https://sepolia.etherscan.io/address/0x3bbeeae916146afb9fd46c905bf4d5b2a21485ed#code.

Now that you have a deployed contract, you can head over to our next entry in the tutorial series which shows you how to modify your collection and security settings.

Limit Break’s ERC721-C, Adventure ERC721-C, Payment Processor, Minting Press, and related services and protocols (collectively “Tools”) are made available on an as-is basis and Limit Break disclaims all representations and warranties, express or implied, in connection with use of these Tools. Users bear all responsibility for ensuring the proper and legal use of these Tools and should exercise best judgment and caution where appropriate when deploying them. Limit Break does not warrant, endorse, guarantee, or assume responsibility for any product or service advertised or offered by a third party using the Tools, and will not be a party to or in any way be responsible for monitoring any transaction between users and any third-party providers of products or services deploying the Tools.