https://github.com/code-423n4/2024-11-nibiru/blob/8ed91a036f664b421182e183f19f6cef1a4e28ea/x/evm/keeper/erc20.go#L147-L164:
These are helper functions that are used to load the name, symbol, and decimals of an ERC20 token contract and they help within NIbirus scope in ensuring functionalities execute as expected, for eg we can see it being used in funtokens implementation:
https://github.com/code-423n4/2024-11-nibiru/blob/8ed91a036f664b421182e183f19f6cef1a4e28ea/x/evm/keeper/funtoken_from_erc20.go#L26-L52
However, the issue is that there is a wrong assumption that all tokens return their metadata using string, which is wrong. This then means that when tokens that have their metadata as bytes are used, the functionality would be broken due to a revert that occurs when trying to load the string from here, because of the type mismatch, i.e., bytess != string.
https://github.com/code-423n4/2024-11-nibiru/blob/8ed91a036f664b421182e183f19f6cef1a4e28ea/x/evm/keeper/erc20.go#L166-L194
Evidently, we expect a string value from ERC20String for erc20Val; however, for tokens such as MKR that have metadata fields (name/symbol) encoded as bytes32 instead of a string, this flow wouldnt work.
Since we have broken integration for some supported tokens cause when creating the fun token mapping for these tokens we meet an error here in the function createFunTokenFromERC20.
This window also breaks one of the core invariants stated by Nibiru, (see 4 below):
https://github.com/code-423n4/2024-11-nibiru/blob/8ed91a036f664b421182e183f19f6cef1a4e28ea/README.md#L179
Consider outrightly stating that not all tokens are supported, or support two types of metadata, i.e., string and bytes.
