Fungible Tokens
This page provides a guide on how to use NMKR Studio to mint Fungible Tokens
Note - this guide is currently under construction

What is this?

Unlike Non-Fungible tokens, Fungible tokens are about as "un-unique" as you can possibly get. They are completely interchangeable, have identical value and are indistinguishable from one another.
A good way to think about "Fungible" is thinking about FIAT money. From the point of view of trading, the £10 Note in your hand is EXACTLY the same as the £10 Note in someone else's wallet or the TWO £5 Notes on your table.
Note - this analogy is slightly wrong, as you may know that physical bank notes have a serial number on them. For the purpose of this explanation, pretend that they don't.
Similarly $1 = $1, 1 BTC = 1 BTC, 1 ADA = 1 ADA and crucially there is simply no concept of 'I want THAT specific ADA' because there is no specific ADA, only an amount of ADA held in a wallet.
That, is what is means to be Fungible.

VS Duplicate NFT's?

You may have noticed that we have a guide for creating Serialised Duplicate NFTs. This is a different concept, so it is important that we outline the difference.
A duplicate NFT created with NMKR Studio is an NFT that has the exact same media and metadata, other than a slightly different Token Name and Display Name.
In this context Duplicate NFTs would be the addition of a Serial Number associated with what would technically otherwise be a fungible Token. Because they have a serial number, it is possible for a person to say that they hold 'item number 6127' or that they want to purchase 'item number 777'. This minor difference is what makes the tokens Non-Fungible (although in a sense, you could argue that these are almost 'semi-NFT's').

Use Cases

Fungible tokens should be used in all cases whereby there is a desire to track the AMOUNT of something a given user has. This could be anything from in-game currency, voting rights, points earned - anything designed to be the medium of exchange or in some way fungible.
Serialised Duplicates should be used instead when there is a need for users to be able to hold a specific, identifiable item that has identical properties to other duplicate items. A great example of this would be for a multiplayer racing game where people own the cars. You could create the game such that there are only ever 1000 Fast Cars, all of which have identical visuals, speed and handling but such that players know they own one or more specific Fast Cars. Another example would be with digital awards, whereby an unlimited number of people can earn the identical certificate, but they become the Xth person to be awarded as such.

Fungible Token Metadata Standard

Before we start with explaining the setup method, we need first to really deep dive into the Fungible Token Metadata Standard on Cardano, which is arguably more complex than NFTs!

ADA Lovelace

The first thing to note is that the Native 'Currency' (Token) that we call ADA is actually Lovelace.
1 ADA is equal to 1 Million Lovelace.
Technically speaking - 'ADA' is not really in existence, only Lovelace exists.
When you send someone ADA, you are actually sending them Lovelace!
Fun fact - It is named after Ada Lovelace: a 19th-century mathematician who is recognised as the first computer programmer.

Policy ID

As is the case with NFTs, the Policy on the Cardano blockchain represents a script that defines parameters like who can mint certain tokens and for how long they can be minted.
This policy and the ID associated with it is how the community will confirm that the FT you create, is indeed the real one. So be sure to make the Policy ID easy to find so that they can verify.
Note - it is expected that you will set the Policy ID to close at some point in the future as otherwise, it would technically mean the supply of the FT is infinite.
Once the Policy ID closes, no more of the FT can be minted as thus the supply is locked forever.

FT Metadata Example

Below is an example of well constructed On-Chain Fungible Token Metadata:
{
"721":{
"5ad3deb61bfec21ad2a16e1270b5873d0a00ac231b928b4c39ed1234":{
"EXAMPLE":{
"attributes":{
"publisher":"https://example.com/asset.json"
},
"name":"EXAMPLE",
"image":"ipfs://ipfs/1234567890123456789012345678901234567890123456",
"mediaType":"image/png"
}
}
},
"20":{
"5ad3deb61bfec21ad2a16e1270b5873d0a00ac231b928b4c39ed1234":{
"4558414D504C45":{
"ticker":"EXP",
"url":"https://example.com/asset.json",
"desc":"Example Publisher Token is great and we like it a lot",
"icon":"ipfs://ipfs/1234567890123456789012345678901234567890123456",
"icon-16":"ipfs://ipfs/1234567890123456789012345678901234567890123456",
"logo":"ipfs://ipfs/1234567890123456789012345678901234567890123456",
"decimals":6,
"version":"1.0"
}
}
}
}

Two Standards

The first thing you might notice is that there are two JSON objects at the top level, these are denoted by the 721 and 20 labels and these relate directly to the respective metadata standards. You might recognise the 721 metadata standard from that which is used for NFTs. The 20 metadata standard is used specifically for FTs.
3rd party applications/websites essentially look for these standards and use them to automatically search for, identify and display the information regarding the tokens.
Note that you will see some information repeated in here, that is to ensure we provide the data in such a way that as many 3rd party applications/websites support our metadata.
Note - his is particularly important at the moment as at the time of writing, the CIP for the 20 standard has not yet merged.

721 in-depth

Lets cover the more familiar part first:
  • Line 3 is the policy ID of the token
  • Line 4 is the name of the token
  • Lines 5, 6 and 7 are used to store the URL of the publisher's website
  • Lines 8, 9 and 10 are the usual information relating to the media

20 in-depth

This is where it gets more specific to fungible tokens, more interesting parts are shown in bold:
  • Line 15 is policy ID of the token (same as line 3)
  • Line 16 is the name of the token but given in HEX format
    • You can use an ASCII to Hex converter to do this
    • 4558414D504C45 = EXAMPLE in Hex
  • Lines 17 is the ticker for the token
    • This is used as a short-form of the token name
    • It is convention to keep this to 4 characters or less
  • Line 18 is used to store the URL of the publisher's website
  • Line 19 provides an opportunity to give a description of the token
  • Lines 20, 21 and 22 again are used to provide a link to where the token image is stored, these are repeated due to this being (at the time of writing) non-standardised
    • Including all 3 options means that most 3rd party applications/websites will be able to locate this attribute.
  • Line 23 is the Decimals, lets talk more about this:

Decimals

As mentioned above, Lovelace is the actual native currency on Cardano.
Because of this, when we mint a fungible token, we want to also specify the number of decimals that our token will have.
The reason for this is that it gives you the opportunity to define how granular you want your token to be. If you think about the Dollar, this would have 2 Decimals and can only be as granular as 1 Cent (0.01 Dollars).
Lets say we want to mint 25 Million EXAMPLE token:
  • 25,000,000 EXAMPLE token
  • With 6 Decimals
  • Means we need to mint 25 Trillion
  • 25 Trillion = 25,000,000,000,000 tokens
  • Note, we have 6 more zeros, for each of the decimals
All applications/websites will then know to display the amount of EXAMPLE token held as the amount divided by 1 Million (6 zeros).

Further Reading

We would like to say thank you to and reference Andrew Westberg, who provides a very good overview of this process. You can checkout their video below:
Andrew Westberg - How to create a FT on Cardano

Setup

Most of the setup action happens at the point of project creation for this!
For an NFT project, the max token count is always set to 1, however, we are making Fungible Tokens, so you can make this as large as you need to (within reason).
Note - the maximum allowed is ~ 1 Billion
Set up everything in the normal way, other than customising the Max Token Supply. In this example, I have set the supply to 1000.
Supply is no longer 1, its 1000!
Next, you will need to set some prices, (click the link to see the full guide) but crucially in this case, you will be able to set the quantity higher than 20.
It's now time to load in a single NFT. As we will only need the one, we can simple use the 'Upload and Pin NFT' function in the UI to save time.
Once loaded, you will notice something new in the state field that does not show for NFT's. This shows the count for each status.
States for a Fungible Token.

Sale Example

You are now all set to allow people to mint your Fungible Token.
In this example below, we are using the Payment Gateway for a Quantity/Price Combination of 500/100:
Payment Gateway Example

Token Registration

Once you have your token ready, the next thing to do is to register your Token on the Cardano Token Registry.
Following this link will give instructions which are really aimed at developers, in this section, we will simplify this somewhat and provide more details.
This is currently an Off-Chain process, that essentially works by submitting the data about the token as a 'mapping' file within a github repository. All of the other apps/websites know to look in this repo for the information and thus it becomes the single source of truth for Fungible Token information for the time being.
Note - If you are familiar with it, this is a very similar concept to the early days of NFT verification.
Again, we are going to be working with JSON metadata but this time the format is different to the standard mentioned above, this will get confusing, so we are going to refer to this as Off-Chain Metadata.

Off-Chain Example

{
"subject": "PolicyID+base16-encoded assetName",
"url": {
"sequenceNumber": 0,
"value": "https://example.com/asset.json",
"signatures": [
{
"signature": "urlValueSignedwithSKEY",
"publicKey": "theVKEY"
}
]
},
"name": {
"sequenceNumber": 0,
"value": "EXAMPLE",
"signatures": [
{
"signature": "nameValueSignedwithSKEY",
"publicKey": "theVKEY"
}
]
},
"ticker": {
"sequenceNumber": 0,
"value": "EXP",
"signatures": [
{
"signature": "tickerValueSignedwithSKEY",
"publicKey": "theVKEY"
}
]
},
"decimals": {
"sequenceNumber": 0,
"value": 6,
"signatures": [
{
"signature": "decimalsValueSignedwithSKEY",
"publicKey": "theVKEY"
}
]
},
"logo": {
"sequenceNumber": 0,
"value": "The PNG image converted to a Byte Array - This will be VERY LONG",
"signatures": [
{
"signature": "logoValueSignedwithSKEY",
"publicKey": "theVKEY"
}
]
},
"description": {
"sequenceNumber": 0,
"value": "Example Publisher Token is great and we like it a lot",
"signatures": [
{
"signature": "descriptionValueSignedwithSKEY",
"publicKey": "theVKEY"
}
]
}
}

Detailed Breakdown

The first thing you will probably notice is that this essentially made up of:

Subject

The Subject is the concatenation of:
  • base16-encoded policyId
  • base16-encoded assetName
  • With the PolicyID first
And then a repeated set of this for each attribute:
  • Attribute Name (url, name, ticker, decimals, logo, description)
  • sequenceNumber (this always seems to be 0)
  • value
  • signatures
    • signature
      • This is the value, singed with the sKey
    • publicKey
      • This is the vKey
      • DO NOT PUT THE sKey in here
      • NEVER SHARE THE sKey
Note - you should make sure the values in these attributes matches what has been added in the On-Chain Metadata.

url

The url is a HTTPS URL for the webpage relating to the token.

name

The name attribute is a human-readable name for the token, suitable for use in an interface.

ticker

The name attribute is a human-readable ticker for the token, suitable for use in an interface.

decimals

This is how many decimals to the token, in our example, we set this as 6.
This attribute is probably the least self explanatory, it has to be a PNG image file expressed as a byte string. This is very different to the on chain data, where we are always referencing an image or other media that is stored on IPFS.
This time, we are literally dropping the raw bytes into the JSON data, this is done because it is off-chain.
To do this, you need to use a file-to-bytes converter, which will produce a very long string as a result.

description

The description attribute is a human-readable description for the token, suitable for use in an interface.

Signing Keys

To do this, you are going to need to be familiar with Cardano Key Pairs, as we are going to essentially need to sign the data we are posting in the "value" attributes, thus proving it has been submitted by the creator. This will be familiar if you have knowledge of public key cryptography.
You will need to use this library to sign the data as we build the mapping.
You can access the Policy ID information such as the Vkey and Skey for your Fungible Token Project by the following method:

Export Policy Keys

Select 'Show Policy'
Next, we want to export the PolicyID information, so that we can copy it into our WhiteList Project.
Note - NEVER share your Skey ANYWHERE
Select 'Export Policy Keys'
You should then find a ZIP file in your downloads, extract and you will find it contains 4 files as shown below (with your Project Name as the prefix):
Check all 4 files are there, keep this folder open
You can access the information inside the files by opening them with a simple text editor like TextEdit (Apple) or Notepad (Windows).
Open each file with a text editor
Copy link
On this page
What is this?
VS Duplicate NFT's?
Use Cases
Fungible Token Metadata Standard
ADA Lovelace
Policy ID
FT Metadata Example
Decimals
Further Reading
Setup
Sale Example
Token Registration
Off-Chain Example
Detailed Breakdown
Signing Keys