Tutorial to create the best Solana metadata standard

In this third article of the series on how to revolutionize NFT on Solana, we’ll go over the Proof-of-Concept (PoC) implementation of the metadata standard to solve the problems outlined in the first article, by utilizing tools presented in the last article.

The goal of this article is to first provide more details about a missing feature that has conveniently been left out so far. Then, we’ll present the high-level design of our ideal metadata standard, and how it solves the issues we have identified. Finally, we’ll be going over the PoC’s open-source implementation, outlining the

The missing feature

Although it has been quickly mentioned as the last point (inflexible collections) of the first article about the weaknesses of the current metadata standard, we so far have not provided an alternative for what would solve this.

First, let’s point out an important fact about NFT collections: Collections are about connections, and current standards don’t facilitate connecting much. Having connections easily accessible on-chain enables composition for off-chain and on-chain apps, creating rich and expressive experiences using those connections. The reason for this expressiveness is that connected objects form a graph and that graphs are extremely powerful.

Everything can be a graph

Graphs are a set of interconnected edges and vertices. They are well-known mathematical objects with many interesting properties and have been gaining popularity in many domains of information technologies, from databases (e.g. Neo4J), distributed networks (e.g. Distributed Hash Tables), or even artificial intelligence (e.g. Graph Neural Networks).

The reason for their gain in popularity is that graphs are very abstract objects. This is a strength because it can be used to model arbitrarily complex interactions, which would provide an important primitive for digital ownership on blockchains.

Graphs are a pain in the A in practice

However, their strength can also be a weakness: because they can model complex phenomenons, they also make interactions and analysis less clear, especially for end-users who don’t have a deep understanding of the system.

Graphs are great for making cool-looking visualizations where you have many points interconnected, but they often hide the actually important data that would have otherwise been exposed using more classical tools.

Finally, by adding more degrees of freedom to the modeling, developers using those tools can find themselves adding too much complexity to their app when it’s not needed. This confuses users, but also other devs willing to integrate the protocol.

Sets to the rescue

Sets are mathematical objects that represent collections of things. They are at a nice halfway point between full-featured graphs and limited existing collections. At a high level, they immediately correspond to collections, making it clear to users what is happening. However, they can also be (ab)used to mimic graphs if needed, enabling the more complex interactions.

Example of a set

High-Level Design

We start from the first principles before presenting how those principles can be manifested in the metadata standard’s architecture.

First principles

• Succinct: Proving a relation takes few resources, regardless of how nested one element is in the other. Resources here are the main bottlenecks of Solana’s transactions: transaction size (number of accounts passed) as well as compute budget consumed to verify the proof. Minimizing the cost makes composition with other programs easier, which is one of the main advantages of integrated blockchains like Solana.
• Permissionless: The appropriate authority can always declare a relation with any other metadata, regardless of its authority over the included token. This is again needed to boost composability.
• State-minimized: The state footprint of accounts is limited so that rent is as minimized as possible

Proposed solution

• Trimmed down metadata. By getting rid of most fields on the on-chain metadata object, we reduce the state it occupies and the associated cost in rent. We only keep an on-chain display name, a hash of the content to facilitate clients verification, and a pointer to the actual metadata. This data is stored in a Metadata account.
• Overlapping metadata pointers. Thanks to Rust’s enumerations, it is possible to store many different types of pointers in the same memory zone of an account. Metaplex’s standard uses 200 bytes to store a URI and that’s all, we enable using this space for diverse usages such as on-chain metadata or referencing other metadata.
• Every metadata is a set. Sets are created empty but new elements can be added later by the appropriate set inclusion authority. Following the permisionless principle, the same element can belong to many different sets. Every inclusion is represented by an Inclusion account.
• Succinct inclusion proof. Because metadata can be deeply nested, proving that some metadata is a subset of another can be expensive in terms of compute and transaction size. To remedy this, a proof called a superset inclusion can be generated separately from the transaction that needs to know if metadata A is a subset of B. This way, you only need to add one account in your transaction to verify an inclusion (not even the metadata program).
• Reusing authorities. Since we have many parts in the protocol and might want different access rules for each of them, we need to declare many authorities. Storing each of them in every metadata would be wasteful so we introduce authority groups that can be reused for several metadata. Authorities are stored in a AuthoritiesGroup account.

Example of nested sets

Implementing the protocol

Since the implementation is open source, everybody is invited to directly read through the codebase to understand how everything actually works. For the purpose of this article, we will only go through the protocol using the figure below instead of pasting around big blocks of code.

Metadata Standard’s interactions and relations

We can first notice how creating token metadata is separate from the creation of the actual token. This is done to make it clear how metadata can be applied to many different tokens: fungibles, semi-fungible and non-fungible. Mint characteristics are only handled by the SPL token program, not by the metadata. This also enables using any combination of Token2022 extensions, especially the ones mentioned in the previous article.

We can then observe that the metadata creation ability is restricted to the mint authority of the token. This prevents squatters and bots that could listen for new token creations and snipe the associated metadata. The creator must specify an AuthoritiesGroup that contains all the associated authorities. They can all have the same value if they are the same account.

The inclusion authority is the account authorized to create Inclusion accounts between 2 Metadata accounts. It is a somewhat new role compared to Metaplex standard because it used to be the same as the update authority. By using a separate authority, it enables delegating this role to a program to run custom logic or even to users in the more liberal cases, e.g. when liking on-chain content, the content can be anything that the user chooses.

SupersetInclusion accounts, that are a special account that proves that the child metadata is a subset of another metadata. This account is created in its independent instruction using a path of Metadata accounts and Inclusion accounts.

Finally, all types of inclusions have a creation_slot field used to prevent attacks where a burnt metadata can be recreated by a random account and still benefit from the previously established inclusions.

Conclusion

We have seen how to improve upon the existing token Metadata standards on Solana. This new standard introduces a new feature, sets, that we believe will strike just the right balance between simplicity and expressiveness. We have developed a PoC implementation and seen an overview of why and how it is built.

We have so far been laying the basis for better NFTs on Solana. In the next article, we will finally get into the core of how to disrupt the current digital ownership metagame and present a simple yet effective solution to it.