API Reference
Peerplays API Libraries
Development Guides
The Cookbook
Tools and Integrations
Supporting & Reference Docs
Development Workflow Docs
Other Documentation
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.
return type, namespace, & method
1
signed_transaction graphene::wallet::wallet_api::nft_metadata_create(
2
string owner_account_id_or_name,
3
string name,
4
string symbol,
5
string base_uri,
6
optional<string> revenue_partner,
7
optional<uint16_t> revenue_split,
8
bool is_transferable,
9
bool is_sellable,
10
optional<account_role_id_type> role_id,
11
bool broadcast)
Copied!
Function Call
The basic structure of the
nft_metadata_create function looks like this:When using the cli_wallet...
1
nft_metadata_create <owner_account_id_or_name> <name> <symbol> <base_uri> <revenue_partner> <revenue_split> <is_transferable> <is_sellable> <role_id> true
Copied!
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
true or false, whether or not you want to broadcast the transaction to the network.Example Call Without Permissions
1
nft_metadata_create account01 "AVALON NAME" "AVALON SYMBOL" "avalonmeta.com" account02 150 false true null true
Copied!
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:
1
create_account_role account01 "Avalon Permissions1" "Permission Metadata" [88,89,90,95] [1.2.40, 1.2.41] "2020-11-04T13:43:39" true
Copied!
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
- [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:
1
nft_metadata_create account01 "AVALON NAME" "AVALON SYMBOL" "avalonmeta.com" account02 150 false true 1.32.0 true
Copied!
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.
return type, namespace, & method
1
signed_transaction graphene::wallet::wallet_api::nft_metadata_update(
2
string owner_account_id_or_name,
3
nft_metadata_id_type nft_metadata_id,
4
optional<string> name,
5
optional<string> symbol,
6
optional<string> base_uri,
7
optional<string> revenue_partner,
8
optional<uint16_t> revenue_split,
9
optional<bool> is_transferable,
10
optional<bool> is_sellable,
11
optional<account_role_id_type> role_id,
12
bool broadcast)
Copied!
Function Call
The basic structure of the
nft_metadata_update function looks like this:When using the cli_wallet...
1
nft_metadata_update <owner_account_id_or_name> <nft_metadata_id> <name> <symbol> <base_uri> <revenue_partner> <revenue_split> <is_transferable> <is_sellable> <role_id> true
Copied!
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
true or false, whether or not you want to broadcast the transaction to the network.Example Call
1
nft_metadata_update account01 1.30.1 sknft01 sknft01 sknft01 null null true true true
Copied!
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.
return type, namespace, & method
1
signed_transaction graphene::wallet::wallet_api::nft_create(
2
string metadata_owner_account_id_or_name,
3
nft_metadata_id_type metadata_id,
4
string owner_account_id_or_name,
5
string approved_account_id_or_name,
6
string token_uri,
7
bool broadcast)
Copied!
Function Call
The basic structure of the
nft_create function looks like this:When using the cli_wallet...
1
nft_create <metadata_owner_account_id_or_name> <metadata_id> <owner_account_id_or_name> <approved_account_id_or_name> <token_uri> true
Copied!
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
get_object 1.30.0, 1.30.1, 1.30.2... and so on. In the future a new cli command will be introduced that can list all the metadata objects by owner account.)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
true or false, whether or not you want to broadcast the transaction to the network.Example Call
1
nft_create account01 1.30.0 account02 account02 "AVALON NFT URI" true
Copied!
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.
return type, namespace, & method
1
signed_transaction graphene::wallet::wallet_api::nft_transfer_from(
2
string operator_account_id_or_name,
3
string from_account_id_or_name,
4
string to_account_id_or_name,
5
nft_id_type token_id,
6
bool broadcast)
Copied!
Or...
return type, namespace, & method
1
signed_transaction graphene::wallet::wallet_api::nft_safe_transfer_from(
2
string operator_account_id_or_name,
3
string from_account_id_or_name,
4
string to_account_id_or_name,
5
nft_id_type token_id,
6
string data,
7
bool broadcast)
Copied!
Function Call
The basic structure of the
nft_transfer_from and nft_safe_transfer_from function looks like this:When using the cli_wallet...
1
nft_transfer_from <operator_account_id_or_name> <from_account_id_or_name> <to_account_id_or_name> <token_id> true
2
​
3
nft_safe_transfer_from <operator_account_id_or_name> <from_account_id_or_name> <to_account_id_or_name> <token_id> <data> true
Copied!
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
nft_safe_transfer_from, you can include more metadata in the transfer with this field.broadcast
bool
true or false, whether or not you want to broadcast the transaction to the network.Example Call
1
nft_safe_transfer_from account02 account02 account03 1.31.0 "Enjoy my NFT" true
Copied!
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.