Skip to main content
added 323 characters in body
Source Link
Burger Bob
  • 1.5k
  • 4
  • 19

Question 1

  1. I was wondering how do I create a metadata PDA account that matches 1:1 with the T22 Metadata Interface. Here is my attempt so far:
#[account]
#[derive(Default, Debug)]
pub struct Mint22 {
    /// The authority that can sign to update the metadata
    pub update_authority: Option<Pubkey>,
    /// The associated mint, used to counter spoofing to be sure that metadata
    /// belongs to a particular mint
    pub mint: Pubkey,
    /// The longer name of the token
    pub name: String,
    /// The shortened symbol for the token
    pub symbol: String,
    /// The URI pointing to richer metadata
    pub uri: String,
    // TODO, does this match Vec<(String, String)>?
    /// Any additional metadata about the token as key-value pairs. The program
    /// must avoid storing the same key twice.
    pub additional_metadata: Vec<[String;2]>,
}

For reference here is the T22 Metadata interface https://github.com/solana-labs/solana-program-library/blob/56aaa6732670824273414bb14bbea12c83a46829/token-metadata/interface/src/state.rs#L25

So the questionssub-questions are:

Part 1 a) How do I ensure OptionalNonZeroPubkey type which is 4 bytes instead of the 1 byte Option type?

Part 1 b) Also the Anchor IDL is not happy about Vec<[String;2]> as a replacement for Vec<(String, String)>. How to accommodate this also?

Part 1 c) I most likely also need to store the bump, right? In that case, wouldn't this create a mismatch on the interface?

Part 1 d) If I adhere to this T22 Metadata interface, I assume I would be able to do something like getMetadataPointerState from the client-side using the @solana/spl-token library to fetch the account data?

Question 2

  1. How do I ensure that my account adheres to dynamic sizing depending on the contents of additional_metadata? Would there be a clean way of doing so?

Maybe something like this:

space = ExtraAccountMetaList::size_of(metas.len()).unwrap(),

Part 2 a) Although, I am curious to know if there are more examples like so?

  1. I was wondering how do I create a metadata PDA account that matches 1:1 with the T22 Metadata Interface. Here is my attempt so far:
#[account]
#[derive(Default, Debug)]
pub struct Mint22 {
    /// The authority that can sign to update the metadata
    pub update_authority: Option<Pubkey>,
    /// The associated mint, used to counter spoofing to be sure that metadata
    /// belongs to a particular mint
    pub mint: Pubkey,
    /// The longer name of the token
    pub name: String,
    /// The shortened symbol for the token
    pub symbol: String,
    /// The URI pointing to richer metadata
    pub uri: String,
    // TODO, does this match Vec<(String, String)>?
    /// Any additional metadata about the token as key-value pairs. The program
    /// must avoid storing the same key twice.
    pub additional_metadata: Vec<[String;2]>,
}

For reference here is the T22 Metadata interface https://github.com/solana-labs/solana-program-library/blob/56aaa6732670824273414bb14bbea12c83a46829/token-metadata/interface/src/state.rs#L25

So the questions are:

Part 1 a) How do I ensure OptionalNonZeroPubkey type which is 4 bytes instead of the 1 byte Option type?

Part 1 b) Also the Anchor IDL is not happy about Vec<[String;2]> as a replacement for Vec<(String, String)>. How to accommodate this also?

Part 1 c) I most likely also need to store the bump, right?

  1. How do I ensure that my account adheres to dynamic sizing depending on the contents of additional_metadata? Would there be a clean way of doing so?

Maybe something like this:

space = ExtraAccountMetaList::size_of(metas.len()).unwrap(),

Part 2 a) Although, I am curious to know if there are more examples like so?

Question 1

  1. I was wondering how do I create a metadata PDA account that matches 1:1 with the T22 Metadata Interface. Here is my attempt so far:
#[account]
#[derive(Default, Debug)]
pub struct Mint22 {
    /// The authority that can sign to update the metadata
    pub update_authority: Option<Pubkey>,
    /// The associated mint, used to counter spoofing to be sure that metadata
    /// belongs to a particular mint
    pub mint: Pubkey,
    /// The longer name of the token
    pub name: String,
    /// The shortened symbol for the token
    pub symbol: String,
    /// The URI pointing to richer metadata
    pub uri: String,
    // TODO, does this match Vec<(String, String)>?
    /// Any additional metadata about the token as key-value pairs. The program
    /// must avoid storing the same key twice.
    pub additional_metadata: Vec<[String;2]>,
}

For reference here is the T22 Metadata interface https://github.com/solana-labs/solana-program-library/blob/56aaa6732670824273414bb14bbea12c83a46829/token-metadata/interface/src/state.rs#L25

So the sub-questions are:

Part 1 a) How do I ensure OptionalNonZeroPubkey type which is 4 bytes instead of the 1 byte Option type?

Part 1 b) Also the Anchor IDL is not happy about Vec<[String;2]> as a replacement for Vec<(String, String)>. How to accommodate this also?

Part 1 c) I most likely also need to store the bump, right? In that case, wouldn't this create a mismatch on the interface?

Part 1 d) If I adhere to this T22 Metadata interface, I assume I would be able to do something like getMetadataPointerState from the client-side using the @solana/spl-token library to fetch the account data?

Question 2

  1. How do I ensure that my account adheres to dynamic sizing depending on the contents of additional_metadata? Would there be a clean way of doing so?

Maybe something like this:

space = ExtraAccountMetaList::size_of(metas.len()).unwrap(),

Part 2 a) Although, I am curious to know if there are more examples like so?

Source Link
Burger Bob
  • 1.5k
  • 4
  • 19

Questions on Token2022 Metadata

  1. I was wondering how do I create a metadata PDA account that matches 1:1 with the T22 Metadata Interface. Here is my attempt so far:
#[account]
#[derive(Default, Debug)]
pub struct Mint22 {
    /// The authority that can sign to update the metadata
    pub update_authority: Option<Pubkey>,
    /// The associated mint, used to counter spoofing to be sure that metadata
    /// belongs to a particular mint
    pub mint: Pubkey,
    /// The longer name of the token
    pub name: String,
    /// The shortened symbol for the token
    pub symbol: String,
    /// The URI pointing to richer metadata
    pub uri: String,
    // TODO, does this match Vec<(String, String)>?
    /// Any additional metadata about the token as key-value pairs. The program
    /// must avoid storing the same key twice.
    pub additional_metadata: Vec<[String;2]>,
}

For reference here is the T22 Metadata interface https://github.com/solana-labs/solana-program-library/blob/56aaa6732670824273414bb14bbea12c83a46829/token-metadata/interface/src/state.rs#L25

So the questions are:

Part 1 a) How do I ensure OptionalNonZeroPubkey type which is 4 bytes instead of the 1 byte Option type?

Part 1 b) Also the Anchor IDL is not happy about Vec<[String;2]> as a replacement for Vec<(String, String)>. How to accommodate this also?

Part 1 c) I most likely also need to store the bump, right?

  1. How do I ensure that my account adheres to dynamic sizing depending on the contents of additional_metadata? Would there be a clean way of doing so?

Maybe something like this:

space = ExtraAccountMetaList::size_of(metas.len()).unwrap(),

Part 2 a) Although, I am curious to know if there are more examples like so?