Why is this not part of TokenMetadata directly?

It feels very closely related, so I would consider including it. Making it a separate component means users always need to remember to include it in their account next to TokenMetadata and need to decode both TokenMetadata and Info to get all the related data, so this pushes some complexity up the stack.

It would also be nice if we could set mutability flags directly via the mentioned TokenMetadataBuilder, e.g. TokenMetadataBuilder::new(...).description("abc").mutable_description().build().

Related, I think Info does not be an AccountComponent, since it does not have any code. This suggests it is a set of standard storage slots but not a full account component (a combination of functionality / code and storage). So in the same way as TokenMetadata is not an account component (but more like a standardized storage slot), we could make Info a reusable set of storage slots. I would then include it in TokenMetadata, which in turn is included in BasicFungibleFaucet (a proper account component). Notably, this does not prevent reusing Info for other purposes in the future (such as for NFTs).

Naming: I think this is more aptly described as TokenMetadata. This is more generic metadata than what is currently called TokenMetadata which is specific to fungible assets. So maybe it is better to rename the current TokenMetadata to FungibleTokenMetadata to free up that name for this.

It would be great if we could implement validation (e.g. of max supply, token supply, ...) once and then reuse it, and also avoid instantiating the struct directly (Self { ... }) in multiple places.

Ideally, we end up with a single constructor that validates the basics and instantiates the struct, all other constructors are wrappers around this. This results in the least amount of duplication and the least chance to introduce differences in how validation works.

We now have new_validated, could we now call it here instead of reimplementing the checks?

Self::new_validated(
    symbol,
    decimals,
    max_supply,
    token_supply,
    metadata.name.ok_or_else(todo!()),
    metadata.description,
    metadata.logo_uri,
    metadata.external_link,
);

It would be good to avoid using magic numbers here, especially because if we update the layout in TokenMetadata, these changes are less likely to propagate here since this is a different module. TokenMetadata should be the only place that defines the exact layout of this mutability config word and should provide helpers for constructing and reading from those instead.

So basically, I think we should change TokenMetadata::read_metadata_from_storage to return TokenMetadata (unless this doesn't work for some reason), and maybe rename it to try_from_storage.

We should be able to remove this, make the slot in crates/miden-standards/asm/standards/metadata/fungible_faucet.masm public and then import it here.

We now have new_validated, could we now call it here instead of reimplementing the checks?

Self::new_validated(
    symbol,
    decimals,
    max_supply,
    token_supply,
    metadata.name.ok_or_else(todo!()),
    metadata.description,
    metadata.logo_uri,
    metadata.external_link,
);

I think we can avoid this code if we change new_validated to:

pub(crate) fn new_validated(
    symbol: TokenSymbol,
    decimals: u8,
    max_supply: u64,
    token_supply: u64,
    metadata: TokenMetadata,
) -> Result<Self, FungibleFaucetError> {

Then we can convert the u64 in that constructor to a Felt if it's valid and we only implement the max supply check exactly once.

I'd also change FungibleTokenMetadataBuilder::token_supply to take u64 for consistency with max_supply.

I'd still suggest returning an error instead of silently falling back to an empty string which could hide issues in tests.

Nit: I'd use a longer name, one that is encoded into two words (where both words are non-empty) as a more interesting test case.

Do we need the push.0 for anything here or can we remove them?

• Can we use rstest to encode these cases?
• Can we use the more concise build_faucet_metadata() for the second and following cases?

Nit: We don't need this line, same in test_field_setter_owner_succeeds.

Nit: For the non-owner test, we don't need to pass any data in, so we can simplify the test setup.

Nit: We probably don't need this here either.

let metadata = FungibleTokenMetadata::try_from(updated_faucet.storage())?;
assert_eq!(
    metadata.max_supply().as_canonical_u64(),
    new_max_supply,
    "max_supply should be updated"
);
assert_eq!(
    metadata.token_supply().as_canonical_u64(),
    0,
    "token_supply should remain unchanged"
);

Nit: Avoid using Felt::new. This is a nice opportunity to also test the try from storage impl.