sRFC 23 – Field Authority Interface (for Token Metadata)

[jacksondoherty]

sRFC 23 – Field Authority Interface (for Token Metadata)

Summary

An interface that works alongside the Token Metadata Interface (sRFC 00017) which provides field-based authority to additional public keys.

Problem

The Token Metadata Interface outlines a basic standard which programs can implement for updating and retrieving fungible and non-fungible token metadata. The interface specifies a single update authority for all write operations. This works for basic tokens and NFTs.

But if you want to do something more advanced, such as allowing token holders to edit the token’s metadata, you have to either give them access to all fields or set the update authority to a PDA and carry out the logic in a custom program. The former doesn’t work because core fields could be edited like name and uri which would disrupt marketplaces and dapps. The latter “closes” the interface and takes us back to closed-program territory.

Solution

We propose the “Field Authority Interface," a way to specify additional public keys as authorities on specific metadata fields. The Field Authority Interface works alongside the Token Metadata Interface; it lives in the same program and writes to the same metadata account. The update authority from the Token Metadata Interface can add and remove Field Authorities. Field Authorities can be System Program keys or PDAs that “plug in” and implement custom logic – but this time they don’t close the interface.

Implementation / Live Example

At Garden Labs, we released a PFP collection called AI Aliens which implements the Field Authority Interface along with a Holder Metadata Plugin. We open sourced the code and provided a detailed write-up. The website and tweet thread focus on the holder metadata functionality, but it uses the Field Authority Interface under the hood. The implementation is fairly simple: adding a Field Authority creates a PDA with data, updating metadata via a Field Authority requires providing this PDA and a signature from the authority, and removing the Field Authority closes the PDA.

Limitations

This implementation only allows for one Field Authority per field. It also uses PDAs which perhaps limits discoverability. We want to keep the implementation simple for now while the Token Metadata Interface gets adopted / understood.

Further Thoughts

With the Field Authority Interface, most additional metadata functionality should be covered. Custom logic can be implemented via external programs that plug in. That said, as the ecosystem matures, it may make sense to turn some of these plugins like Holder Metadata into interfaces themselves.

[joncinque]

This is a really neat idea! Keeping the two interfaces in the same program simplifies a lot of the design.

My main idea for a multi-authority approach required the main authority to be set to a PDA on another program. This other program would handle the multiple authorities. The tradeoff is that you don’t need a bespoke program that implements two interfaces – instead, anyone can use the two deployed programs directly. On the flipside, the multiple levels of programs can be much more cumbersome to use unfortunately.

All in all, this is a great idea and a lovely use of program interfaces!

[jacksondoherty]

Thank you!

I originally considered the PDA approach but felt the cumbersome nature you’re talking about – for example, an NFT editing tool / website that uses the interface would present the wrong transactions. Maybe it could see that the authority is a PDA and know to use the PDAs program, but it would then have to know that program’s instructions and… we sort of end where we started, a closed Metaplex-like program.

A lighter approach to what I’ve proposed might be to just add a second optional authority to the Token Metadata Interface that could be for PDAs, etc.

At the same time, I think one of the benefits of the field-based approach is that you can have multiple of these secondary programs “plug in.” I think this architecture lends itself better to libraries of plugins that do different types of auth-ing – holder-based, multi-sig, additional token-gating, etc. etc. It looks like Metaplex might have independently converged on this idea with their plugins and authority types in Core.

[Gabynto]

The Field Authority Interface seems like a smart solution to expand metadata control without complicating the Token Metadata Interface. I would love to see how this can enable more flexibility and advanced use cases for NFTs and tokens.

[jacksondoherty]

I’ve implemented a V2 which removes the PDAs and uses a TLV-based approach. A list of field authorities are now placed inside the same account as the metadata via a second TLV struct. This allows for much easier composability, no longer having to pass extra accounts (code).

This also matches the UpdateField parameters types and accounts with Token Metadata Interface’s. @joncinque perhaps the Token Metadata Interface’s spec could loosen what is meant by update_authority in the UpdateField function? With TLVs it seems we can actually handle a much broader set of functionality / make this a bit more powerful without having to change any code.