I also desire to have more static APIs for pallet-assets, that other pallets can call into. Have been thinking about it a lot too this week. That said I think having such a high-level Ethereum-specific interface in FRAME may not be appropriate.

Rather, we could add new low-level Inspect, and Mutate traits for working with asset metadata and approvals. Users can then build higher-level constructs on top of them.

Rough example: (not too much thought put into it):

// fungibles::metadata::Inspect
trait Inspect<AssetId> {
   fn name(asset: AssetId) -> Vec<u8>;
   fn symbol(asset: AssetId) -> Vec<u8>;
   fn decimals(asset: AssetId) -> u8;
}

// fungibles::metadata::Mutate
trait Mutate<AssetId> {
   fn set(asset: AssetId, name: Vec<u8>, symbol: Vec<u8>, decimals: u8) -> DispatchResult;
}

Yeah I dont mind dividing this into more low level traits.

I applied the suggested change. We could also name the traits differently like InspectMetadata and InspectApproval so that we can import them directly.

Why would name, symbol, or metadata need to be read by another pallet?

This data should only be used off-chain which is why it is not exposed via any traits.

In the case of Moonbeam we are trying to build an ERC-20-like precompile for assets, which has getters for those attributes. In any case we are more interested in the allowance getter, which is the one we trully need, we could live without the metadata getter

For Snowbridge, we are interested more in allowing another pallet to set/mutate metadata for wrapped assets bridged over from Ethereum. We don't need to read any metadata at this stage. That said, I guess a metadata mutator is not relevant to this PR, so I can cut another one.

Yeah same thing, I could leave the mutators out of this PR too and leave the inspectors only.

@shawntabrizi is there an option we can make parts of the pallet-assets storage public, either through traits or through a getter? We were thinking about assigning specific contract addresses to existing assets based on their Asset Id but we need to know if such An AssetId exists in the first place

@thiolliere can you also review?

I dont see much reason for the audit, as it is just a code refactor. i don't see any real underlying changes.

Made them dependent on Fungibles, that leaves the traits only with AccountId as generics

bot merge

Trying merge.