Motivation

today, program developers need to keep multiple types of program metadata on-chain: their IDL, security_txt, and solana-verify arguments. In the future, program developers may also want to maintain dapp links, social information, Blink IDLs, or other program-related information.

Goal

We would like an on-chain SBF program that meets these metadata needs today while also anticipating future developer needs.

Summary

Program should manage buffer & buffer histories at specified PDA derivation paths under 1 authority, initialized from the program authority.

Accounts

PDA [<custom path>, <program id>, <uploader>] → metadata

PDA [<custom path>, <program id>, <uploader>, <index>] → buffer containing arbitrary data, corresponding to <custom path>

Example for path “idl”:

PDA [“idl”, <program id>, 0] → buffer initialized with program authority

Notes on Buffer Authority

Today, with anchor IDL PDAs, program authority is initially given control over buffer, and henceforth the idl authority is separate from the program authority. The general consensus seems to be okay with this. This seems fine.

Usage

We imagine that having versioned history would solve data indexing problems going forward for IDLs. IDL versions would be stored on-chain & unable to be closed.

We imagine the verifier args for solana-verify would go in the verify path.

We imagine that this also gives program developers the freedom to come up with new types of program metadata & encourage adoption w/o intervention from the Foundation.

Obviously program developers are free to override their buffers with meaningless information, but not sure what we can do to stop this.