NFT Minting
A guide for creating NFTs from start to finish.
1. Creating Non-Fungible Tokens (NFTs)
Creating NFTs in Peerplays is a two step process.
First, the metadata must be created for the NFT. This can be thought of like a template from which NFTs can be constructed. The account which owns the NFT metadata is the account with the rights to mint (create) the actual NFTs based on that metadata. The metadata is used to set certain basic permissions for the NFT, revenue sharing options, and the NFT identity information (name, symbol, and a URI).
Then using the metadata, NFTs can be minted into existence by the metadata owner. Once the NFTs are minted, they can be transferred, sold, auctioned, or otherwise used for their intended purpose as the permissions in the metadata allow.
2. NFT Metadata
2.1. nft_metadata_create
This function creates a new NFT metadata object. It can be created with or without a set of permissions. See the guide on permissions for details about creating resource permissions.
The basic structure of the nft_metadata_create
function looks like this:
Parameters
name | data type | description |
owner_account_id_or_name | string | The name or id of the account who is creating the metadata. |
name | string | The name of the NFTs created from this metadata. |
symbol | string | The symbol of the NFTs created from this metadata. |
base_uri | string | The URI of the NFT. This could be a website link, an API call, something on IPFS, some other unique identifier, etc. |
revenue_partner | string (optional) | The account name of the revenue partner. Whenever the minted NFT is sold in the marketplace a split of the selling price goes to the revenue partner. This can be the metadata owner. |
revenue_split | uint16_t (optional) | The amount of the selling price that goes to the revenue partner. 10000 = 100%, 100 = 1%, 1 = 0.01% |
is_transferable | bool | Specifies if the minted NFTs can be transferred by the owner of the NFT to other accounts. |
is_sellable | bool | Specifies if the minted NFTs can be sold in the marketplace. |
role_id | account_role_id_type (optional) | The resource permissions specifying the whitelisted accounts among which the NFTs can either be transferred or sold on the marketplace. |
broadcast | bool |
|
Example Call Without Permissions
In the example above:
account01 is the owner account of the metadata.
"AVALON NAME" is the name of the NFTs created from this NFT metadata.
"AVALON SYMBOL" is the symbol of the NFTs created from this NFT metadata. The symbol is reserved for future use.
"avalonmeta.com" is the URI of the NFTs.
account02 is the revenue partner.
150 is the revenue_split that will be shared with the revenue_partner. In this case, 1.5%.
false, is_transferable specifies the minted NFTs cannot be transferred by the owner of the NFT to other accounts.
true, is_sellable specifies minted NFTs can be sold in the marketplace.
null, role_id is not set.
true, This transaction will be in the upcoming block on the chain.
Example Call With Permissions
First we create the permission:
In the above function...
account01 is the owner of the permission being created which can be attached to NFT metadata.
"Avalon Permissions1" is the name of the resource permission being created.
"Permission Metadata" is the metadata, can be a JSON object as well.
[88,89,90,95] is the list of operations this permission whitelists for accounts.
88 - List Offer operation in marketplace
89 - Bid operation in marketplace
90 - Cancel Offer operation in marketplace
95 - Safe transfer from owner to another NFT
IDs are available here.
[1.2.40, 1.2.41] List of accounts whitelisted for the above operations. Offer, bid and transfer operations can only be among the whitelisted accounts.
"2020-11-04T13:43:39" Expiry date of the permission
true broadcast, keep it true to include the transaction in upcoming block.
Then we create the metadata with the above permission:
This example is just like the previous, except this time we include 1.32.0, the role_id, to attach permissions to all the NFTs created from this metadata.
2.2. nft_metadata_update
This function updates an existing NFT metadata object.
The basic structure of the nft_metadata_update
function looks like this:
Parameters
name | data type | description |
owner_account_id_or_name | string | The name or id of the account who owns the metadata this NFT is based on. |
nft_metadata_id | nft_metadata_id_type | The ID of the metadata you want to update. |
name | string (optional) | A new name for the NFT. |
symbol | string (optional) | A new symbol for the NFT. |
base_uri | string (optional) | A new URI of the NFT. |
revenue_partner | string (optional) | A new revenue partner account name or id. |
revenue_split | uint16_t (optional) | A new revenue split amount. |
is_transferable | bool (optional) | Whether or not the minted NFTs are transferable. |
is_sellable | bool (optional) | Whether or not the minted NFTs are sellable in the marketplace. |
role_id | account_role_id_type | A new set of resource permissions. |
broadcast | bool |
|
Example Call
3. Minting NFTs
3.1. nft_create
This function mints an NFT based on the metadata. NFTs are always minted by the owner of the metadata object the NFTs are based on. The fees associated with minting an NFT is just the transaction fee + storage fee which are both collected in core PPY token. After an NFT has been minted it can be sold on the marketplace for any token of the NFT owner’s choice.
The basic structure of the nft_create
function looks like this:
Parameters
name | data type | description |
metadata_owner_account_id_or_name | string | The name or id of the account who owns the metadata this NFT is based on. |
metadata_id | nft_metadata_id_type | The NFT metadata object ID to base this NFT on. (Currently this works on the "best guess" method by doing |
owner_account_id_or_name | string | The owner of the freshly minted NFT. As the owner of the metadata, you can mint NFTs directly into someone elses account! |
approved_account_id_or_name | string | The approved account of the NFT, can be the owner as well. |
token_uri | string | The URI of the NFT. This could be a website link, an API call, something on IPFS, some other unique identifier, etc. |
broadcast | bool |
|
Example Call
In the example above:
account01 is the owner account of the metadata.
1.30.0 is the ID of the metadata object.
account02 is the owner of the minted NFT.
account02 is the approved account of the minted NFT.
AVALON NFT URL is the URI that has additional information about this NFT.
true, This transaction will be in the upcoming block on the chain.
4. Sending NFTs
4.1. nft_transfer_from (nft_safe_transfer_from)
These functions are used to transfer NFTs from one account to another, if allowed. The difference between the two is that the safe transfer includes a string parameter which can be used to send along some metadata (or a memo) with the NFT. Otherwise, they are the same.
Or...
The basic structure of the nft_transfer_from
and nft_safe_transfer_from
function looks like this:
Parameters
name | data type | description |
operator_account_id_or_name | string | The operator or owner account. |
from_account_id_or_name | string | The account sending the NFT. |
to_account_id_or_name | string | The account receiving the NFT. |
token_id | nft_id_type | The ID of the NFT. |
data | string | Only for |
broadcast | bool |
|
Example Call
In the example above:
account02 is the owner or operator account.
account02 is sending the NFT.
account03 is receiving the NFT.
1.31.0 is the ID of the NFT.
"Enjoy my NFT" is the metadata of the transfer.
true, This transaction will be in the upcoming block on the chain.
5. Related Documents
The functions listed in this guide will cost transaction fees. To calculate how much PPY you'll need to make these transactions and meet your development goals, please see the Calculating Costs guide.
Last updated