|0.0.1||Oct 13, 2021|
#40 in #metaplex
1,358 downloads per month
Used in 9 crates (6 directly)
title: Token Metadata Program
Solana's programming model and the definitions of the Solana terms used in this document are available at:
The Token Metadata Program's source is available on github
There is also an example Rust client located at
that can be perused for learning and run if desired with
cargo run --bin metaplex-token-metadata-test-client. It allows testing out a variety of scenarios.
The crate provides four instructions,
mint_new_edition_from_master_edition_via_token(), to easily create instructions for the program.
This is a very simple program designed to allow metadata tagging to a given mint, with an update authority that can change that metadata going forward. Optionally, owners of the metadata can choose to tag this metadata as a master edition and then use this master edition to label child mints as "limited editions" of this master edition going forward. The owners of the metadata do not need to be involved in every step of the process, as any holder of a master edition mint token can have their mint labeled as a limited edition without the involvement or signature of the owner, this allows for the sale and distribution of master edition prints.
Operational flow for Master Editions
It would be useful before a dive into architecture to illustrate the flow for a master edition as a story because it makes it easier to understand.
- User creates a new Metadata for their mint with
create_metadata_accounts()which makes new
- User wishes their mint to be a master edition and ensures that there is only required supply of one in the mint.
- User requests the program to designate
create_master_edition()on their metadata, which creates new
MasterEditionwhich for this example we will say has an unlimited supply. As part of the arguments to the function the user is required to make a new mint called the Printing mint over which they have minting authority that they tell the contract about and that the contract stores on the
- User mints a token from the Printing mint and gives it to their friend.
- Their friend creates a new mint with supply 1 and calls
mint_new_edition_from_master_edition_via_token(), which creates for them new
Editionrecords signifying this mint as an Edition child of the master edition original.
There is a slight variation on this theme if
create_master_edition() is given a max_supply: minting authority
is locked within the program for the Printing mint and all minting takes place immediately in
create_master_edition() to a designated account the user provides and owns -
the user then uses this fixed pool as the source of their authorization tokens going forward to prevent new
supply from being generated in an unauthorized manner.
Permissioning and Architecture
There are three different major structs in the app: Metadata, MasterEditions, and Editions. A Metadata can have zero or one MasterEdition, OR can have zero or one Edition, but CANNOT have both a MasterEdition AND an Edition associated with it. This is to say a Metadata is EITHER a master edition or a edition(child record) of another master edition.
Only the minting authority on a mint can create metadata accounts. A Metadata account holds the name, symbol, and uri of the mint, as well as the mint id. To ensure the uniqueness of a mint's metadata, the address of a Metadata account is a program derived address composed of seeds:
["metadata".as_bytes(), program_id.as_ref(), mint_key.as_ref()]
A master edition is an extension account of this PDA, being simply:
["metadata".as_bytes(), program_id.as_ref(), mint_key.as_ref(), "edition".as_bytes()]
Any limited edition minted from this has the same address, but is of a different struct type. The reason these two different structs(Edition and MasterEdition) share the same address is to ensure that there can be no Metadata that has both, which would make no sense in the current architecture.
(Mint authority must be signer)
This action creates the
(Update authority must be signer)
This call can be called at any time by the update authority to update the URI on any metadata or update authority on metadata, and later other fields.
(Update authority must be signer)
This can only be called once, and only if the supply on the mint is one. It will create a
Now other Mints can become Editions of this Metadata if they have the proper authorization token.
(Mint authority of new mint must be signer)
If one possesses a token from the Printing mint of the master edition and a brand new mint with no
that mint has only a supply of one, this mint can be turned into an
Edition of this parent
Master Edition by
calling this endpoint. This endpoint both creates the
Metadata records and burns the token.
This program is designed to be extended with further account buckets.
If say, we wanted to add metadata for youtube metadata, we could create a new struct called Youtube and seed it with the seed
["metadata".as_bytes(), program_id.as_ref(), mint_key.as_ref(), "youtube".as_bytes()]
And then only those interested in that metadata need search for it, and its uniqueness is ensured. It can also have it's own update action that follows a similar pattern to the original update action.