Add metadata extensions on CreateMint

[grod220]

• Changes CreateMint to add MetadataPointer and TokenMetadata extensions to wrapped Token-2022 mints
• The MintCustomizer interface has been updated to support extensions that must be initialized after the mint account itself. New: pre_initialize_extensions() & post_initialize_extensions()

Up next

• SPL token -> Token-2022 case
  • An instruction to copy metaplex metadata into the token2022 metadata.
• Token-2022 -> Token-2022 case
  • An instruction to copy token-2022 metadata from the unwrapped mint to the wrapped token-2022 metadata

[joncinque]

Looks good overall! Just a couple of small things

[buffalojoec]

Lgtm after Jon's feedback.

[joncinque]

Looks good to me!

[buffalojoec]

Are you also going to allow this to be updated? For metaplex metadata accounts, this is actually a PDA, and for Token-2022 metadata-enabled mints, this authority can be separate from the mint authority.

Is it possible to first check if the metadata extensions exists already and if so, inherit those first?

[grod220]

I think we have four cases that need to be handled after this:

• SPL token -> Token-2022: an instruction to copy metaplex metadata into the token2022 metadata.
• Token-2022 -> Token-2022: an instruction to copy token-2022 metadata from the unwrapped mint to the wrapped token-2022 metadata
• Token-2022 -> SPL token: an instruction to create & update metaplex metadata (copied from token-2022 ext metadata)
• SPL token -> SPL token: an instruction to create & update metaplex metadata (copied from existing metaplex data)

These should exist to essentially sync metadata state from the unwrapped to wrapped.

Is it possible to first check if the metadata extensions exists already and if so, inherit those first?

I worry about moving some of the above's case branching into the initialization logic. It seems simpler to separate this complexity into the individual instructions handling those. I don't think it should be too difficult for the consumer to make an additional call to update. What do you think?

[buffalojoec]

Will I be able to call "SyncMetadata" again if my unwrapped token's metadata changes? Also, if my unwrapped token has no metadata, am I paying extra rent on the wrapped mint for no reason?

This is kind of a tradeoff, since if we only added metadata for tokens who have it during the time of wrapping, then we lose the ability to sync newly created metadata on the unwrapped token with the wrapped token.

Nonetheless I think it's ok to leave this as the program's mint authority PDA as long as it never goes beyond sync.

[grod220]

Will I be able to call "SyncMetadata" again if my unwrapped token's metadata changes?

Yes, I was intending for that subsequent instruction to be something that can be repeatedly called

if my unwrapped token has no metadata, am I paying extra rent on the wrapped mint for no reason?

Ah, this is an important point I think. As of this PR, for token-2022 wrapped mints, the answer is yes. If we were to move initialize_token_metadata() to a dedicated instruction, this would move this from opt-out to opt-in. Think that is probably best. Will follow up with a PR for that.

[buffalojoec]

I think the only gotcha there is that you can create Metaplex token metadata for your mint anytime after it's been initialized, as long as you hold the mint authority. However, for Token-2022, the MetadataPointer extension can only be added before the mint is initialized.

So, if you have no metadata on an SPL Token, and you wrap it under Token-2022, then later you create metadata for your unwrapped mint via Metaplex, you wouldn't be able to add metadata to the already-wrapped mint. You'd have to burn it all and re-wrap.

[grod220]

True, don't think we could ever get around removing the MetadataPointer extension. We'd have to continue adding that to each mint.