decodeCalldata resolved an ERC-20 amount's scale from the 512-entry bundled token list alone and fell back to 18 decimals for everything else. Most tokens are outside that list, including anything the user added by contract address, so a transfer of 5000000000 units of a 6-decimal token - 5,000 tokens - was drawn as "Amount 0.0000". A user who reads zero confirms, and loses the balance or grants the allowance. The new src/shared/approvalAmount.js resolves decimals from the bundled list, then state.trackedTokens, then the decimals the block explorer already reported in addr.tokenBalances, accepting only a real uint8 from any of them and refusing a scale the explorer's own entries disagree about. Where no source knows the scale the amount is not formatted at all: the line reads "5000000000 base units (decimals unknown)". A formatted number computed from a guessed scale is the defect itself, and for a token with fewer decimals than the guess it is wrong in the direction that reads as zero. approve is covered alongside transfer; an unbounded allowance still reads "Unlimited", which needs no scale. The same string is carried to the status screens, so no formatted figure reappears downstream. Verified failing first: restoring only the old lookup fails 6 of the 15 new tests, with the unknown-decimals transfer case receiving exactly "0.0000".
7.5 KiB
7.5 KiB