Problem: Given a Token Color or Contract Address, we want its metadata, and ask the Source.
| What is Stored →Source ↓ | Ledger Metadata | Emit Actual Metadata | Off-chain Metadata | Off-chain Compact Source | Circuit / Compact Source |
|---|---|---|---|---|---|
| EventsLedger v9 | MIP-XXXXPublishing verifiable off-chain interfaces | WorksMIP-0018 | WorksMIP-0018 + a metadata standard | MIP-XXXXPublishing verifiable off-chain interfaces | NoNot feasible due to large size |
| Ledger | NoCannot prove the ledger structure* | NoCannot prove the ledger structure* | NoCannot prove the ledger structure* | NoCannot prove the ledger structure* | NoNot feasible due to large size |
| Circuit / Compact Source | NoLedger variable position cannot be verified | NoCannot access | WorksWorks, but source is non-public | N/A | WorksWorks, but source is non-public |
| Off-chaincentralized | Prove on-chainMust be proven on-chain (via event data, ledger data* or calling a circuit) | PossiblePossible to read authoritative standards such as MIP-0018 | Prove on-chainMust be proven on-chain (via event data, ledger data* or calling a circuit) | VerifiableCircuit can be verified | VerifiableCircuit can be verified |
* Not possible today. It becomes possible in the future if the ledger structure can be proven on-chain, which is an improvement we would like to see.
maintainer_authority can change over time or be empty. An off-chain file that carries a valid signature can only be verified against the value at the current chain tip. On-chain, this path does not solve the source problem, so it is only useful for off-chain validation.
The contract must emit metadata in a standard format of key:value pairs.
The contract emits the URL where its contract files are located. This is verifiable in both directions.
Supports long events, given the 256-byte restriction on a single event.