An amount that differs by a power of ten may be a unit-display mismatch. Token contracts store integer units; wallets use the token’s decimals value to show a human-readable quantity.
ERC-20 defines the decimals metadata, and OpenZeppelin illustrates how it affects display. It does not change the underlying balance integer.
Work through a simple check
Hypothetical example: a token with six decimals has a raw balance of 1,500,000 units. Its human balance is 1.5 tokens. Showing the raw integer as 1,500,000 whole tokens would be a display error, not newly created wealth.
Compare the exact token contract and chain before applying that calculation. A different contract with the same ticker can have different metadata. Do not assume a familiar stablecoin uses identical decimals in every representation.
Do not sign through a disagreement
If the aggregator and wallet show different amounts, inspect the verified token information and the decoded request. An approval cap displayed with incorrect units could authorize much more than you intended.
Custom token import settings can affect a wallet’s display. Correcting them may fix the visible amount, but it does not alter already signed transaction data or restore tokens sent elsewhere.
Send support the token contract, chain, raw value if available and the two displayed amounts. This lets them distinguish formatting from a wrong token, wrong account or actual balance discrepancy. Keep private keys out of the report.
Sources & verification (2)
Source-check date is recorded in the article details. URLs are provided for manual verification. Use Copy to keep this page open.
- ERC-20: Token Standard
Allowance, spender, transferFrom, metadata and approval event semantics.
https://eips.ethereum.org/EIPS/eip-20 - ERC20 | OpenZeppelin Docs
ERC-20 implementation behavior, zero-first approval compatibility and pausable token extension.
https://docs.openzeppelin.com/contracts/5.x/api/token/erc20