3

When making Token Extensions using token extensions metadata, many fields:

  • name
  • symbol
  • attribute key/value pairs

Already appear in the JS/TS parameters for the mint. The token extensions with metadata example uses this TokenMetadata type, from @solana/spl-token-metadata/src/state.ts


export interface TokenMetadata {
  // The authority that can sign to update the metadata
  updateAuthority?: PublicKey;
  // The associated mint, used to counter spoofing to be sure that metadata belongs to a particular mint
  mint: PublicKey;
  // The longer name of the token
  name: string;
  // The shortened symbol for the token
  symbol: string;
  // The URI pointing to richer metadata
  uri: string;
  // Any additional metadata about the token as key-value pairs
  additionalMetadata: [string, string][];
}


In older tokens, name and symbol and attributes used to be in the JSON file in the URI:

{
    "name": "OPOS",
    "symbol": "OPOS",
    "description": "Only Possible On Solana",
    "image": "https://raw.githubusercontent.com/solana-developers/opos-asset/main/assets/CompressedCoil/image.png",
    "attributes": [
      {
        "trait_type": "Item",
        "value": "Compressed Coil"
      }
    ]
  }

Does this mean my 'richer metadata' should now just be:

{
    "image": "https://raw.githubusercontent.com/solana-developers/opos-asset/main/assets/CompressedCoil/image.png"
}

... i.e. just using onchain metadata for name, symbol, etc.?

Also, is there a validation tool for JSON metadata files so I can confirm if a JSON file has the necessary fields and is formatted correctly?

3
  • It depends, IMO, this is viable for fungible tokens that don't require the attributes and description fields found in the off-chain URI metadata, but are a necessity for non-fungible tokens determining things like a rarity.
    – Jimii
    Commented Aug 15 at 19:08
  • Thanks @Jimii. When you write "this" - could you be more specific about what "this" refers to? Also couldn't we use attributes in TokenMetadata for rarity?
    – mikemaccana
    Commented Aug 15 at 19:19
  • this strategy you've described, using token-22 is most viable for fungible tokens. i.e having the off chain uri metadata only contain the image. For non-fungibles, it is possible to have the additional metadata contain the attributes, but the costs will quickly rack up, plus explorers and wallets need to know that the additional metadata in your token represents the attributes
    – Jimii
    Commented Aug 16 at 9:55

1 Answer 1

0

I would recommend checking out Metaplex docs as they are the most used Token Standard and well documented. https://developers.metaplex.com/token-metadata/token-standard#the-fungible-standard

1
  • Thanks for the link! I think it helps the discussion, but I'm not sure it's an answer - Metaplex's fungible standard was created before Token Extensions, so it seems that Token Extensions would remove the need for many of the fields in the standard, hence the question.
    – mikemaccana
    Commented Aug 15 at 19:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.