The minting policy based validation process does not accord for assets being minted by smart contracts.

Hi @jsyme222

To provide an opinion-neutral consideration of the topic let me refer to CIP-26:

With regards to the monetary policy:

Metadata objects that contain an extra top-level property policy MUST therefore abide by the following rules:

Their subject MUST be an assetId, encoded in base16; where the assetId is the concatenation of a policyId (28 bytes) and an assetName (up to 32 bytes). The policy MUST therefore re-hash (through blake2b-224) into the first 28 bytes of the metadata's subject (the policy id). Every metadata entry MUST have a set of signatures such that, the monetary script given in policy can be validated using the provided signatures, irrespective of the time constraints. Said differently, the public keys from the annotated signature must re-hash into key hashes present in the policy AND each key must verify its associated signature AND the provided signatures must be sufficient to validate the monetary script according to the semantic given by the cardano ledger without considering the time constraints.

So if there is a policy field included in your metadata, you must abide to the rules above.

Also CIP-26 states with regards to the phase-1 monetary policy based validation:

This approach is now considered superseded by the more general approach. While it has some nice properties, new applications should consider sticking to the general case even for phase-1 monetary policies. Servers who seek backward-compatibility should implement both.

In more general CIP-26 suggests that the metadata is signed with just any key and the consumer applications can decide if they trust that key. This is accords more to the Uniswap token list approach, where certain entities/parties maintain lists of token metadata and sign that data with their keys. The user's are then up to decide which of those lists they want to trust.

And here is the thing: Cardano Foundation could be an entity that signs-off metadata entries with their key. The keys can be registered in any public key registry for example or we can register a key on chain and foresee any governance mechanism how to rotate/revoke etc. those keys. If you then pull only those metadata entries from the registry that were signed with this key you get the "Cardano Foundation approved" off-chain metadata list. So far so good and perfectly doable. Challenge is as follows:

As Cardano Foundation I want to be neutral (not just because the Foundation is registered in Switzerland) not introducing any kind of censorship by a single central authority. So a simple approach would be to just check if the data is valid according to the standard (data format and such, and also for the special case of the monetary policy script, if the signatures are ok). But then we would probably allow that users could register offensive content (in the logo data or the description or whatsoever) which is a legal liability. This could even lead to possible copyright infringements. This is why the process at the moment has this manual step involved, which is to be frank nothing else but censorship. Not meant in a bad way but this is how most bad things start. In the end this is currently solved that we have a "terms of use" which on top of the formal spec add some rules about what is considered ok and what not when it comes to the content.
To mitigate this central authority issue, we can replace the Foundation with a group of entities/people (e.g. from the community) and they whether decide together if an update to the registry data is "ok" to accept and if so, they sign it with the keys they own OR everyone out there is free to sign the data with its own keys and the consumer is up to include a check which key or set of keys must have signed a metadata entry so that it is accepted on consumer side. This mechanism is actually already supported by this implementation of CIP-26 but it is not used as far as I am aware of.
There is no reward mechanism for people maintaining a token list (by signing metadata entries). If I am not wrong, for DEXes it is a problem out of liability issues or "fair" treatment of tokens traded on their platform.

There are other standards out there to overcome this challenge (e.g. CIP-67 together with CIP-68) or any other on-chain metadata related standard. But imho those do solve the problem that the asset minter is able to register and modify metadata but no external party is able to do so (maybe I don't want to use the description provided by the person that minted the asset or whatever).

TL;DR; If no policy field is included, you can register any metadata as long as it conforms to the terms of use and spec provided by CIP-26. That token metadata is accepted where no policy field is included and the signatures arrays are empty is indeed a bug in the validation (meaning the validation does not accord to the CIP-26 standard). This bug is accepted atm because a lack of governance.

cardano-foundation / cardano-token-registry

The minting policy based validation process does not accord for assets being minted by smart contracts. #2576