Accounts
Metadata
Description
The Metadata Account is responsible for storing additional data attached to tokens. As every account in the Token Metadata program, it derives from the Mint Account of the token using a PDA.
It stores a variety of information for different use-cases and, thus, the reader might benefit from reading the "fields" table below to learn more about them. Additionally, dedicated feature pages have been written to provide more documentation on what can be done with these fields. Their description will contain a link to the appropriate page when available.
One particular field to notice is the Uri field that points to an off-chain JSON file which, itself, contains more data. That data is standardized so applications and marketplaces can reliably find information on a given token. If you're wondering why the Metadata account provides two data stores — one off-chain and one on-chain — you might want to take a look at the FAQ here.
Seeds
| Seed | Type | Description |
|---|---|---|
| Metadata | Literal: metadata | The program's prefix for PDA seeds. |
| Token Metadata Program | Program ID | The public key of the program. |
| Mint | Variable | The public key of the Mint Account to derive from. |
Fields
| Field | Offset | Size | Description |
|---|---|---|---|
Key | 0 | 1 | The discriminator of the account as an enum. Equals to MetadataV1(4). |
Update Authority | 1 | 32 | The public key that is allowed to update this account. |
Mint | 33 | 32 | The public key of the Mint Account it derives from. |
Name | 65 | 36 | The on-chain name of the token, limited to 32 bytes. For instance "Degen Ape #1 ". |
Symbol | 101 | 14 | The on-chain symbol of the token, limited to 10 bytes. For instance "DAPE". |
Uri | 115 | 204 | The URI of the token, limited to 200 bytes. This URI points to an off-chain JSON file that contains additional data following a certain standard. You can learn more about this JSON standard here.The JSON file can either be stored in a traditional server (e.g. using AWS) or using a permanent storage solution such as using Arweave. |
Seller Fee Basis Points | 319 | 2 | (Indicative) The royalties shared by the creators in basis points — i.e. 550 means 5.5%. Whilst this field is used by virtually all NFT marketplaces, it is not enforced by the Token Metadata program itself. |
Creators | 321 | ~ | (Optional) An array of creators and their share of the royalties. This array is limited to 5 creators. Note that, because the Creators field is an array of variable length, we cannot guarantee the byte position of any field that follows (Notice the tilde ~ in the fields below). Each creator contains the following fields. |
Address | ~ | 32 | The public key of the creator |
Verified | ~ | 1 | A boolean indicating if the creator signed the NFT. It is important to check this field to ensure the authenticity of the creator. |
Share | ~ | 1 | (Indicative) The creator's shares of the royalties in percentage (1 byte) — i.e. 55 means 55%. Similarly to the Seller Fee Basis Points field, this is used by marketplaces but not enforced by the Token Metadata program. |
Primary Sale Happened | ~ | 1 | (Indicative) A boolean indicating if the token has already been sold at least once. Once flipped to True, it cannot ever be False again. This field can affect the way royalties are distributed. |
Is Mutable | ~ | 1 | A boolean indicating if the Metadata Account can be updated. Once flipped to False, it cannot ever be True again. |
Edition Nonce | ~ | 2 | (Optional) A nonce used to verify the edition number of printed NFTs. It will only be set on Edition NFTs and not Master Edition NFTs. |
Token Standard | ~ | 2 | (Optional) This enum captures the fungibility of the token. You can learn more about the token standard here. |
Collection | ~ | 34 | (Optional) This field optionally links to the Mint address of another NFT that acts as a Collection NFT. It contains the following sub-fields. |
Verified | ~ | 1 | A boolean indicating if the owner of the Collection NFT signed this NFT. It is important to check this field to ensure the authenticity of the collection. |
Key | ~ | 32 | The public key of the Collection NFT's Mint Account |
Uses | ~ | 18 | (Optional) This field can make NFTs usable. Meaning you can load it with a certain amount of "uses" and use it until it has run out. You can learn more about using NFTs here. |
Use Method | ~ | 1 | An enum defining the use behaviour for the NFT. It can be one of the following: Burn, Multiple or Single. |
Remaining | ~ | 8 | The remaining amount of uses. |
Total | ~ | 8 | The total amount of uses allowed in the first place. |
Collection Details | ~ | 10 | (Optional) This optional enum allows us to differentiate Collection NFTs from Regular NFTs whilst adding additional context such as the amount of NFTs that are linked to the Collection NFT. You can learn more about the sized collections here |
Programmable Config | ~ | 35 | (Optional) This optional enum stores any data relevant to Programmable NFTs. The different variants of the enum are used as versions so we can add more features later on without introducing breaking changes. The latest version `V1` optionally contains the address of the RuleSet defining authorization rules for the Programmable NFT. If no RuleSet is provided, then all operations are allowed. |
Master Edition
Description
The Master Edition account, derived from a Mint Account, is an important component of NFTs because its existence is proof of the Non-Fungibility of the token.
When creating a Master Edition account, the Token Metadata program will check for the following conditions:
- The Mint Account has zero decimals, i.e.
Decimals = 0. - The Mint Account minted exactly one token to a wallet, i.e.
Supply = 1.
Additionally, it will transfer the Mint Authority and the Freeze Authority to the Master Edition account to prevent anyone from being able to mint additional tokens. You can read more about why these authorities are transferred instead of being voided in the FAQ.
Therefore, what we end up with is a Mint Account whose supply will never go above one and whose token cannot be shared or divided. As such, we end up with a Non-Fungible Token (NFT).
On top of being a Non-Fungible proof, the Master Edition allows NFTs to be printed a limited or unlimited amount of times. The Master Edition NFT acts as the "original record" of the digital asset that can be duplicated or "printed" into Edition NFTs. This allows creators to offer more than one copy of their digital assets to their audience.
The optional Max Supply field of the Master Edition account tells us how many copies of the NFT can be created. When set to None, an unlimited amount of copies can be created. When set to zero, the NFT cannot be copied.
Seeds
| Seed | Type | Description |
|---|---|---|
| Metadata | Literal: metadata | The program's prefix for PDA seeds. |
| Token Metadata Program | Program ID | The public key of the program. |
| Mint | Variable | The public key of the Mint Account to derive from. |
| Edition | Literal: edition | A literal to differentiate the Edition accounts. |
Fields
| Field | Offset | Size | Description |
|---|---|---|---|
Key | 0 | 1 | The discriminator of the account as an enum. Equals to: MasterEditionV2(6) (or, for previous versions: MasterEditionV1(2)). |
Supply | 1 | 8 | The amount of NFTs printed from this Master Edition. This field is automatically computed by the program and cannot be manually updated. Once the Supply reaches the Max Supply, no more prints can be made from this Master Edition. |
Max Supply | 9 | 9 | (Optional) The maximum number of times NFTs can be printed from this Master Edition. When set to None, the program will enable unlimited prints. You can disable NFT printing by setting the Max Supply to 0. |
Edition
Description
The Edition account, derived from a Mint Account, represents an NFT that was copied from a Master Edition NFT.
It is important to note that the seeds used to generate this PDA account are the same as the Master Edition account. This means an NFT can either be a Master Edition NFT or an Edition NFT but not both.
Similarly to the Master Edition account, the Edition account will perform Non-Fungibility checks and gets assigned as the Mint Authority and the Freeze Authority of the Mint Account.
Additionally, the Edition account keeps track of the Master Edition account it was printed from in the Parent field as well as the edition number in the Edition field.
Seeds
| Seed | Type | Description |
|---|---|---|
| Metadata | Literal: metadata | The program's prefix for PDA seeds. |
| Token Metadata Program | Program ID | The public key of the program. |
| Mint | Variable | The public key of the Mint Account to derive from. |
| Edition | Literal: edition | A literal to differentiate the Edition accounts. |
Fields
| Field | Offset | Size | Description |
|---|---|---|---|
Key | 0 | 1 | The discriminator of the account as an enum. Equals to: EditionV1(1). |
Parent | 1 | 32 | The public key of the Master Edition account that printed this edition. |
Edition | 33 | 8 | The edition number of this printed edition. For instance, the 10th printed NFT will have Edition = 10. |
Edition Marker
Description
Edition Marker accounts are used internally by the program to keep track of which editions were printed for a given Master Edition.
Each Edition Marker account is responsible for storing a subset of the printed editions. More precisely, they each store 248 editions using a bitmask where 0 means, the edition has not been printed and 1 means it has. That means Master Edition accounts typically end up using more than one Edition Marker account.
To understand how this works, let's imagine that we want to print the 500th edition of a Master Edition.
To know if this edition has already been printed, we need to check the third Edition Marker account because the first two are keeping track of the first 496 editions (248 + 248 = 496) and should, at this point, be full of 1s. Then, we can check the fourth bit of the third Edition Marker to see if the 500th edition has already been printed.
Therefore, we can find out if the nth edition was printed by checking the n % 248th bit of the ⌊n / 248⌋th Edition Marker.
This is why ⌊n / 248⌋ is used as a seed of the Edition Marker PDA.
Seeds
| Seed | Type | Description |
|---|---|---|
| Metadata | Literal: metadata | The program's prefix for PDA seeds. |
| Token Metadata Program | Program ID | The public key of the program. |
| Mint | Variable | The public key of the Mint Account to derive from. |
| Edition | Literal: edition | A literal to differentiate the Edition accounts. |
| Edition Marker | Variable | The edition number divided by 248 rounded down. |
Fields
| Field | Offset | Size | Description |
|---|---|---|---|
Key | 0 | 1 | The discriminator of the account as an enum. Equals to: EditionMarker(7). |
Ledger | 1 | 31 | An array of 31 bytes keeping track of the editions that have been printed within the marker's range. With 31 bytes, each marker keep track of 248 editions using a bitmask. |
Token Record
Description
Token Record accounts are used by Programmable NFTs only. Since Programmable NFTs add another layer on top of tokens, Token Record accounts enable us to attach custom data to token accounts rather than mint accounts.
More specifically, they keep track of the current delegate authority on the token account, if any, and its type. When a delegate is set, it provides a locking mechanism via a state attribute analogous to the "Frozen" state of the Token program. This can be Unlocked, Locked or Listed based on the current delegate type.
You can read more about Token Record accounts and the delegates it supports here.
Seeds
| Seed | Type | Description |
|---|---|---|
| Metadata | Literal: metadata | The program's prefix for PDA seeds. |
| Token Metadata Program | Program ID | The public key of the program. |
| Mint | Variable | The public key of the Mint Account to derive from. |
| Token Record Prefix | Literal: token_record | A literal to differentiate Token Record accounts. |
| Token | Variable | The public key of the Token Account to derive from. |
Fields
| Field | Offset | Size | Description |
|---|---|---|---|
Key | 0 | 1 | The discriminator of the account as an enum. Equals to: TokenRecord(11). |
Bump | 1 | 1 | The bump that was used to create the PDA of this account. |
State | 2 | 1 | The state of the token account as defined by the TokenState enum. You can read more about the different states and what their behaviour in the Programmable NFT guide. |
Rule Set Revision | ~ | 9 | (Optional) The current rule set revision attached to the token, if any. This ensures that, if the rule set changes on the Metadata account, the token continues to use the current rule set until it has been unlocked. |
Delegate | ~ | 33 | (Optional) The address of the delegate authority, if any. |
Delegate Role | ~ | 2 | (Optional) The role of the delegate authority as defined by the TokenDelegateRole enum. |
Locked Transfer | ~ | 33 | (Optional) The only address of the LockedTransfer delegate is allowed to transfer to. |
Metadata Delegate Record
Description
Metadata Delegate Record accounts are used to store multiple delegate authorities for a given Metadata account.
It is a PDA derived from the Mint Account, the public key of the delegate authority and the role of the delegate authority. The PDA also derives from the current Update Authority of the Metadata account to ensure that all delegate authorities are automatically voided when the Update Authority is changed.
Depending on the role of the delegate authority, it can be used to verify/unverify collection items, use the asset, update part of the Metadata account, etc.
You can read more about Metadata Delegate Record accounts and the delegates it supports here.
Seeds
| Seed | Type | Description |
|---|---|---|
| Metadata | Literal: metadata | The program's prefix for PDA seeds. |
| Token Metadata Program | Program ID | The public key of the program. |
| Mint | Variable | The public key of the Mint Account to derive from. |
| Metadata Delegate Role | Variable | The role of the delegate authority as defined by the MetadataDelegateRole enum. |
| Update Authority | Variable | The address of the current update authority of the Metadata account. |
| Delegate | Variable | The address of the delegate authority. |
Fields
| Field | Offset | Size | Description |
|---|---|---|---|
Key | 0 | 1 | The discriminator of the account as an enum. Equals to: MetadataDelegate(12). |
Bump | 1 | 1 | The bump that was used to create the PDA of this account. |
Mint | 2 | 32 | The address of the Mint Account. |
Delegate | 34 | 32 | The address of the delegate authority. |
Update Authority | 66 | 32 | The address of the Update Authority for which this delegate record is valid. |
Collection Authority Record
Description
Collection Authority Record accounts are used internally by the program to keep track of which authorities are allowed to set and/or verify the collection of the token's Metadata account.
It uses a PDA derived from both the Mint Account and the public key of the authority. That way, one can check if a public key is allowed to alter the collection of an NFT by checking the existence of a Collection Authority Record account. The Collection Authority Record account stores the Bump that was used to generate the PDA to provide more thorough verification.
You can read more about NFT Collections here.
Seeds
| Seed | Type | Description |
|---|---|---|
| Metadata | Literal: metadata | The program's prefix for PDA seeds. |
| Token Metadata Program | Program ID | The public key of the program. |
| Mint | Variable | The public key of the Mint Account to derive from. |
| Collection Authority Prefix | Literal: collection_authority | A literal to differentiate the Collection Authority Record accounts. |
| Collection Authority | Variable | The public key of the authority that is now allowed to verify collections on that NFT. |
Fields
| Field | Offset | Size | Description |
|---|---|---|---|
Key | 0 | 1 | The discriminator of the account as an enum. Equals to: CollectionAuthorityRecord(9). |
Bump | 1 | 1 | The bump that was used to create the PDA of this account. |
Update Authority | 2 | ~ | (Optional) |
Use Authority Record
Description
Use Authority Record accounts are used internally by the program to keep track of which authorities are allowed to reduce the uses of the token's Metadata account.
It uses a PDA derived from both the Mint Account and the public key of the authority. That way, one can check if a public key is allowed to reduce the uses of an NFT by checking the existence of a Use Authority Record account. The Use Authority Record account stores the Bump that was used to generate the PDA to provide more thorough verification.
It also stores the Allowed Uses for the given authority to ensure it cannot use more than what it was allowed to use.
You can read more about using NFTs here.
Seeds
| Seed | Type | Description |
|---|---|---|
| Metadata | Literal: metadata | The program's prefix for PDA seeds. |
| Token Metadata Program | Program ID | The public key of the program. |
| Mint | Variable | The public key of the Mint Account to derive from. |
| User Prefix | Literal: user | A literal to differentiate the Use Authority Record accounts. |
| User | Variable | The public key of the authority that is now allowed to use that NFT. |
Fields
| Field | Offset | Size | Description |
|---|---|---|---|
Key | 0 | 1 | The discriminator of the account as an enum. Equals to: UseAuthorityRecord(8). |
Allowed Uses | 1 | 8 | The amount of uses this authority is allowed to use. |
Bump | 9 | 1 | The bump that was used to create the PDA of this account. |