Becoming a CNFT creator
I’ve talked with quite a few creatives, wanting to start their own NFT collection series or mint native assets on the Cardano Blockchain.
And out of all those conversations there were always a few things which I made sure to point out.
So I thought — why not compose a little post about what I think is important and what you need to consider if you want to start a NFT project in Cardano?
Here are some of the topics I want to cover in this article:
- The Lifecycle of NFTs in Cardano
- Designing a “drop”
- Tools and services in different levels of difficulty
And of course I try to highlight pitfalls and rules you need to know when working with native assets / tokens in Cardano whenever necessary.
1. The lifecycle of NFTs in Cardano
Unlike other Blockchains like Ethereum, NFTs or officially called “native assets” don’t need smart contracts in Cardano.
They can be created, sent and received just like ada. Wallets like Daedalus or Yoroi are able to handle transactions of native assets out of the box.
Hence the term “native”.
To create one (or many) native assets you just need to add an additional
mint parameter to a transaction.
The downside?
As of now modifying transactions and adding an additional mint parameter can only be done with a full node.
A full node is the open source software from IOHK running on a linux machine. It’s directly connected to other network participants like stake pools, relays or Daedalus wallets, synchronized to the blockchain and it offers a CLI — a text based way of issuing transactions and other actions via the linux terminal.
Self-minting capabilities from services like the nft-maker or the Nami wallet also use a full node under the hood.
They just add additional, more user friendly layers and maybe a graphical interface between you and the node.
Think of cooking food yourself (working on a node) vs. takeout (using a self service portal).
The ingredients are still the same but the way it’s processed is different.
What you need to know about transactions
Since those services as well as wallets like Daedalus or Yoroi do all of the node stuff and transactions under the hood you probably wouldn’t ever notice what actually happenes.
You do however need to know a few basics about transactions.
First of all, transactions on the full node are mainly issued with the CLI, through specific commands.
Each transaction gets saved as a file after its being built.
Depending on how much information you want to transact, the file varies in size.
Therefore a transaction sending only ada has a smaller file size than a transaction with additional parameters and information needed for NFTs.
That’s important to know because transaction fees are based on the size of the transaction file. The bigger the file size, the higher the fee.
There’s also a limit as to how big a transaction can be. If you exceed this limit, the transactions needs to be split up into two transactions — each having their own transaction fee.
Additionally each transaction needs to be verified.
Since anyone can build a transaction with the ID of your funds, a transaction has another layer of security to ensure that only the owner of the funds can spend them.
For that, a transaction needs to be signed with a specific key, only you have access to.
The concept of using keys to sign off a transaction is important to understand as it also gets applied to creating or destroying NFTs.
What you need to know about minting and policies
As I’ve written above, tokens can be created without any smart contracts just by supplying an additional mint parameter to a transaction.
Let’s take a look what other prerequisites we need to take into consideration before making such a minting transaction.
A mintin transaction which creates a native asset / token / NFT requires two things:
- Policy keys.
Just like keys for a regular transaction provide proof that you are indeed eligible to spend the specified funds, policy keys are the equivalent proof that you’re able to create or destroy the native assets.
Each minted asset is tied to one ore more keys. Which key is needed and which key can do what and when is defined in a monetary policy called the minting policy. - A minting policy.
This piece defines who can create or destroy the tokens at which time.
A publicly available hash of this file is used as the so called policy ID.
The policy ID in turn serves as the unique identifier for all tokens minted with the specified conditions set in the minting policy.
Projects should publish the minting policy so potential buyers can verify if a NFTs is indeed the original. They are also used at the cnft.io marketplace to verify the authenticity of the token being sold.
Let’s take a closer look at the underling policy script of a policy ID and what we can tweak in regards to the lifecycle of our assets. Here are a few examples which can be defined in a policy script:
- Which key or keys are needed to sign the minting transaction to add or subtract (burn) token. You can require for example one key (maybe yours) or multiple (maybe being held by one of your friends).
- Before / After. You can specify a certain time before or after a key is invalid. If a script is invalid no more minting or burning actions can be performed.
- A combination of both. You could specify that up until December 1st 2021 only Key 1 can mint or burn token and after that only key 2 and key 3 are able to do so (and so forth…)
You see, there are quite a few possibilities. There’s a very detailed GitHub page about those scripts and what values can be supplied.
What you need to know about how to make a token unique and metadata
All of what we’ve covered so far is the framework to create native assets /token.
But since we want our tokens to be truly non-fungible, it’s time to flesh them out.
For a true NFT, we need to take care of two properties:
- Uniqueness
An NFT should not be reproducable.
With the policy script you’re able to define a point in time after which the policy “locks”. No other token can be made with that exact policy after the specified time has passed.
This way you can make sure your NFT can never ever be re-made and lives on the blockchain forever.
Please make sure not one of your tokens has the same name. Only the policy ID is unique, token names are not checked for uniqueness. That is something you have to take care of yourself. - Metadata
Metadata is the meat of every NFT.
All of the neccesary information like a link / IPFS image hash, attributes, authors, rarity level, version and so forth can be attached to a token through metadata.
Written in a structured and machine readable form (JSON), the metadata will be attached to the minting transaction of a token.
The beauty of this approach — after knowing the asset fingerprint or policyID and asset name, third party tools can look up the last minting transaction, check the attached metadata, find the entry in the metadata corresponding to the asset name and display all of the information.
To make things more tangible, let’s take a quick look into an example, of how a minting transaction might look in pseudo code:
Transaction from A to B
+ mint one token with the name “Test_1” with policy ID X
+ mint one token with the name “Test_2” with policy ID X
+ mint one token with the name “Test_3” with policy ID X
AND attach metadata to this transaction
This would create and send three tokens to B in one transaction.
The attached metadata would contain queryable information to each token name (Test_1, Test_2 and Test_3).
So it is possible to mint multiple NFTs in a single transaction under the same policy ID.
As we’ve learned earlier, transactions have a maximum file size.
The more metadata you attach to the transaction the more likely you are to hit the file size limit and the minting needs to be split up into multiple transactions.
Depending on the individual metadata of one token, currently around 50 unique NFTs can be minted with one single transaction (which is an inofficial estimation).
2. Designing a “drop”
Since we now have our basics down, let’s talk about selling the NFTs.
Here’s a quick recap and a few important facts you need to know if you plan to make large amounts of token:
- Tokens are minted through a transaction, therefore transaction fees apply.
- NFTs are made by attaching metadata in form of a JSON file to the minting transaction.
- As of now the limit of minting unique NFTs is probably somewhere around 50 NFTs per transaction.
There is a maximum transaction size in bytes, so the amount of mintable tokens per transaction depends solely on how much information you pass into the metadata.
More information = more bytes = maximum transaction size reached faster. - What we didn’t cover as of now:
In order to send NFTs you must at least send about 1 ada with that transaction.
This is to avoid sending tokens only to an — maybe empty — address.
It’s also known as the minAdaValue and is currently set to 1 ada. Experience has shown that most of the time it’s actually not 1 ada but slightly more – depending on various conditions and size of the transaction.
There’s more information available here.
With those points in a few architectural / design problems come to mind.
Pre-minting NFTs is too expensive
Depending on how much you want to make, pre minting NFTs is quite costly.
Let’s say you want to pre-mint 10000 NFTs and due to the maximum transaction size (as we’ve talked about earlier) you can mint about 50 per transaction.
This means you would need make (and pay fees for) about 200 minting transactions.
So it’s safe to say that this approach does not work well with large amounts of NFTs.
A vending machine
This concept was first introduced by the SpaceBudz drop.
Just like with a vending machine, the team took the approach to only mint on demand, after the NFT was actually sold (read: after a transaction with a specific amount was recieved).
This however requires some infrastructure running in the background.
We not only need a cardano node to issue transactions for that.
We also need:
- A way to keep track of the state of all NFTs.
Namely the state “NFT is available for sale”, “NFT is currently reserved and we’re awaiting payment” or “NFT has been sold”. - A way to handle the purchases.
We need to know which incoming transaction belongs to which NFT. - A way to mint the NFT.
Once a payment for a (reserved) NFT is recieved we need to verify the correct amount. If everything is correct we need a way to automatically build a transaction with the sender now being the receiver.
In this new transaction the NFT get’s actually minted and we also need to send the current minimum ada value with it.
We also need to query the address the payment came from to know where to send it. - In regards of that, we also need a way to know which NFT needs to be minted in the post-sale transaction and what metadata is the correct one to be attached to this transaction.
- We also need to think of all of the exceptions we didn’t anticipate.
If a buyer sends multiple tokens with the purchase transaction, those tokens need to be sent back as well.
If someone sends too much ada, the leftovers need to be calculated and refundend. And so on…
As of now the biggest problem I see is, that there is no best practice to match a on-chain transaction to a off-chain purchase (over a website for example).
As the seller you just receive some ada and need to find a way to find out who sent it and what was initially bought with it.
Of course this will change over time (especially with smart contracts), but as of now, this is the way.
I want to introduce you to a few concepts I am aware of on how to handle the payment — NFT relationship
A wallet drop
You only publish one single address and state a pre-defined amount of ada. Everyone who sends an transaction with at least the pre-defined amount will get a random NFT back until a certain threshold of NFTs is reached.
One drawback is the need to refund every transaction once the sale is over and buyers can’t chose and pick what NFT they will get (which also can be seen as rather fair).
We also seen quite a bit of load on the chain with those kind of drops, slowing things down. As drops usually last only a couple of minutes, transactions will peak during that time, maybe offering not the best user experience to the end consumer.
Here’s a brilliant (more technical) description on what happened during the ClayMates drop a few days ago.
This thread is especially great because you get a little glimpse into what really happens behind the scenes of a big NFT project.
Multiple address
You basically define an individual address for one or multiple NFTs and batch them together, therefore making it easier to process. But there’s still the issue of matching incoming payments and keeping track of everything around the sale.
Identify NFT by unique price
Each NFT will be assigned an individual and unique price.
Once a potential buyer clicks on purchase, the NFT will be reserved and the unique amount of ada will be displayed alongside an address.
Only if the exact amount was received on this address, the NFT will be minted. This way you can list your NFTs for example like this:
- Token X: 1,00001 ada
- Token Y: 1,00002 ada
- Token Z: 1,00003 ada
Once you recieve a payment of 1,00002 ada you know which token (Token Y) it belongs to and the minting process can be started automatically. Check out the spacebudz post on medium for more info on their (very early) infrastructure.
As you see, there’s quite a bit to handle and that’s just the very low-level architecture of how the NFTs — payment — transaction relationship needs to be thought of.
We did not talk about having a robust website, securing against bots or DDOS attacks etc. — which is also out of scope of this article.
3. Tools and services in different levels of difficulty
Now that you hopefully now more about what to think about before starting out, I want to give you some starting points you can build upon — depending on your skill level.
Zero to medium technical skill required
NFT-maker.io pro
The NFT Maker PRO version offers pretty much everything you need.
For a certain margin you get to use the API which you can embed in your homepage. Making sales of random NFTs or more sophisticated one’s a breeze.
They even offer an API endpoint to upload your NFTs so you don’t have to manually upload 10000 NFTs through the GUI. Batch uploading is still missing but once you know how to call the API to upload you can wrap that call into a loop for all of your tokens.
You still need some development skills and know what an API is, how it works and how you can make use of it in the context of your sale / drop.
Be careful though!
Direct API calls to the NFT Maker expose your API and project key in the URL. This could lead malicious exploitation of your keys and project.
Therefore you should have some sort of intermediate system in between to disguise your API key and prevent any exploitation of your key.
Most of the times having a website, handling the API calls would be considered best practice. I really hope we see something like authorization with a bearer token in the future.
So you should be able to spin up a production grade website which can handle a bit of load.
NFT Maker PRO also offers a wallet drop feature.
Buffy Bot
Buffy Bot is a service being used for multiple drops in the past. I don’t know much about it but I hear Adam Dean is responsible for operating it. So if you want someone knowledgeable and who’s been around the (Cardano) block to guide you through your drop, he’s probably the right person to talk to.
Easy CNFT
Easy CNFT offers so called flash series in which you can upload multiple NFTs and publish your own NFT series in the style of a wallet drop.
Development skill required
There are some repositories which you can use to build a infrastructure to handle your drop by yourself.
The three repositores listed here are in no way final and you can find plenty more.
Those just happened to be in my bookmarks ;)
They all offer some way of interacting with the full node but in a more convenient way.
Repositories:
DIY
Last but not least — you can obviously write everything by yourself.
If you want to gain a deeper understanding of how transactions are built and how to communicate with the node, I highly reccomend dipping your toes into a testnet node.
From there you can check wether or not you want to build everything yourself, use or extend existing open source projects or rely on full service portals or service providers.
I hope you now have some insight as to what goes into starting out as a CNFT creator.
If you have any questions, please feel free to reach out, I’ll do my best to answer them.
Also I’m happy to hear about feedback if I’ve missed something or was off completely.
If you want to support me, my work and everything I do you can send a little donation of ada my way with the following address:
addr1qxeez9lx2s7pdd0p33gju53d5k7jdrecjq8x7sxqhxa88w93ec4e835klg78fhheyvzlnuxrjdrrw3j8p46r58j84j7q9tdyd3
