MetaMask shows raw ERC-20 balances (doesn’t apply decimals) on Shardeum Unstablenet

[quiet sleet]

@stark wind my message deleting how am i supposed to send

[stark wind]

Let me check the issue.

[quiet sleet]

now good i send txt file pic

[stark wind]

Thanks for sharing. I'll check and fix the message issue.

---

^ Feedback from @quiet sleet:

MetaMask/Rabby incorrectly displays token amounts on Shardeum Unstablenet (Smart Contract Testnet, chainId 8080). Instead of serving a divided state by 10^decimals in the raw balanceOf() value for ERC-20 tokens, it shows the raw numbers.

The token's decimals() return correct 18, but shows 1,000,000,000,000,000,000,000,000 for a mint amount of 1,000,000 tokens (1,000,000 displayed).

Steps to Reproduce

Add Shardeum Unstablenet to MetaMask (see “Network Details” below).
Deploy a standard ERC-20 (OpenZeppelin) with decimals() = 18. Mint 1,000,000 × 10^18 units to an address (i.e., 1,000,000 tokens) or use my dapp i created .
Import token to MetaMask (Custom Token). Look at the balance displayed to your account in MetaMask.
Expected Behavior MetaMask should divide the raw balanceOf() by 10^decimals() and display 1,000,000 tokens. Actual Behavior MetaMask is showing the raw integer: 1,000,000,000,000,000,000,000,000 (no decimals applied).

Contract Details
decimals() → 18
totalSupply() → 1,000,000 × 10^18
Environment
Network: Shardeum Unstablenet (Smart Contract Testnet)
Chain ID: 8080
RPC URL: https://api-unstable.shardeum.org/
Block Explorer: https://explorer-unstable.shardeum.org/
MetaMask version: latest

Notes
Manually setting decimals while "Import Token" still does not resolve incorrect display.
Same token code displays correctly on all other EVM networks with MetaMask applying decimals.

[quiet sleet]

@stark wind nevermind after hours i find out there was multiplication going on in backend causing token inflation its fixed now and token deployer is also updated for correct token minting

[pulsar creek]

It seems you were able to resolve this on your side. I did not encounter this issue and was unable to reproduce it on my end.