Token Metadata Interface

Background

In 2024, the Solana Foundation shipped Token Extensions, the next generation of Solana's SPL token (similar to Ethereum's ERC-20 token). Notably, it natively supports a vast array of new functionality due to its Extensions framework, such as confidential transfers, soulbound tokens, and new NFT programs. These programs can be anything, but they are expected to implement the Token Metadata Interface, A.K.A. sRFC 00017.

Token Metadata Interface (sRFC 00017)

Previously, Solana NFTs only operated through Metaplex's on-chain programs. This allowed Solana's NFT ecosystem to blossom rapidly. But in the long-run, the key primative of web3 cannot exist in a single program gate-kept by a single update authority. NFTs will underpin domain names, user profiles, social graphs, digital real estate, and more. NFT projects will have different needs, and developers need to be able to permissionlessly innovate on features.

In CS101, you learn that when different programs need to operate together but maintain separate features and implementations, you build an interface. Enter the Token Metadata Interface – Solana's new interface for NFTs shipping with Token-2022. The interface describes a set of instructions for your metadata program to implement:

pub fn initialize(
    program_id: &Pubkey,
    metadata: &Pubkey,
    update_authority: &Pubkey,
    mint: &Pubkey,
    mint_authority: &Pubkey,
    name: String,
    symbol: String,
    uri: String,
) -> Instruction { ... }

pub fn update_field(
    program_id: &Pubkey,
    metadata: &Pubkey,
    update_authority: &Pubkey,
    field: Field,
    value: String,
) -> Instruction { ... }

pub fn remove_key(
    program_id: &Pubkey,
    metadata: &Pubkey,
    update_authority: &Pubkey,
    key: String,
    idempotent: bool,
) -> Instruction { ... }

pub fn update_authority(
    program_id: &Pubkey,
    metadata: &Pubkey,
    current_authority: &Pubkey,
    new_authority: OptionalNonZeroPubkey,
) -> Instruction { ... }

pub fn emit(
    program_id: &Pubkey,
    metadata: &Pubkey,
    start: Option<u64>,
    end: Option<u64>,
) -> Instruction { ... }

source code

The inner details are now up to you. As long as you support these instructions, your NFT program will interoperate with marketplaces, dapps, etc. You are free to innovate as you wish!

Additional Interfaces

There is a slight wrinkle to this all.

Solana is built to be the most performant blockchain in the world. Every level of the stack is optimized to be as fast as possible. One major optimization that separates Solana from other blockchains is the requirement that all instructions first mark all data (ie. accounts) that they might read or write to. This allows validators to parallelize transactions that don't touch the same data. The performance boost is worth it, but it adds a slight rigidity to interfaces. Back to CS101, it's as if you're given an interface that not only specifies function names and parameters, but all internal variables as well. There is room to wiggle and do different things, but it's limited.

Luckily, there is a solution to this wrinkle, and it's the same solution as before... Now that we're no longer locked to Metaplex's program, we can add more interfaces.

We can write additional instructions that operate on the same metadata. Dapps can adopt whatever interfaces become popular that fit their needs. NFT marketplaces may not need to support the editing of metadata, but do need to support displaying it along with marketplace actions.

Next, we'll take you through the Field Authority Interface that we've developed to make Holder Metadata possible.