Question 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
- 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?