CLI spl-token update-metadata doesn't follow expected JSON format

[SolBugz]

If this isn't the right place to report CLI bugs, then please copy the right person. The problem is that this command and subcommand are supposed to insert new fields and values within additionalMetadata of a Token-2022 structure on chain. For example:

"additionalMetadata": []

can be expanded to:

"additionalMetadata": [
[
"animal": "horse"
]
]

using the above command. However, what actually happens is this:

"additionalMetadata": [
[
"animal",
"horse"
]
]

Thus both the format (comma rather than colon) and the display (skipped line rather than not) of the JSON are inconsistent with the usual "field: value" format. It's acting as though "animal" and "horse" are equivalent items in a list, instead of a field and its value. As a result, downstream consumers can't parse it correctly.

[SolBugz]

On second thought, it could be just a display problem with "spl-token display", in which case the downstream issues are due to other causes. It's hard to tell because while that command shows commas, and solscan.io shows the same, solana.fm shows colons.

[buffalojoec]

@SolBugz The Token Metadata additional metadata is one field with a Vec<(String, String)>. To put this in JavaScript terms (closer to JSON) it looks like: [string, string][].

So the JSON you've pasted here appears correct. It's a list of tuples [string, string]. ie:

{
  "additionalMetadata": [
    ["animal", "horse"],
    ["plant", "daisy"],
    ["rock", "granite"]
  ]
}

It's hard to tell because while that command shows commas, and solscan.io shows the same, solana.fm shows colons.

SolanaFM may be trying to map this to key-value display, since that's what the intention is with this field, but it must be tuples in order to be dynamic for key names!

[SolBugz]

@buffalojoec Thanks but I'm not sure what "dynamic for" means in this context. You can have the exact same dynamically-sized, updateable structure in your example with colons instead of commas. They wouldn't be Vecs in the Rust sense but the format would be consistent with all the metadata already out there.

This might explain why it seems that no explorer or wallet currently picks up "image" when it resides in "additionalMetadata". This is problematic because it forces the existence of off-chain metadata, at least for tokens with images, when in fact Token-2022 would allow one to implement an SPL token entirely on-chain.

I suppose it's too late to change this (unless comma-vs-colon is left undefined in the Token-2022 spec). If that's the case then it's an awareness problem on the part of all the explorers and wallets, both in terms of the punctuation and also that "additionalMetadata" should be imported just like off-chain metadata.