3 Commits

Include renames

Author	SHA1	Message	Date
clawbot	3b713809c8	harden: a token scale above 80 decimal places is refused as unknown (closes #350) ... toDecimals() accepted any uint8 scale, but formatUnits() and parseUnits() refuse more than 80 decimal places. A token reporting 81 to 255 made the formatter throw, and the catch in the swap decoder and in the ERC-20 decoder turned that into an undecoded approval screen with nothing saying why. MAX_DECIMALS is now 80, the formatter's own limit, so such a scale is treated exactly like an unknown one: both approval paths show the base-unit amount with the scale stated as unknown. The balance list, the history list and the Send screen use the same check. Model: opus-5-5	2026-10-04 21:43:11 +02:00
clawbot	2fe6447625	fix: name a tracked or explorer-known token instead of "Unknown token" (closes #323) ... The approval and transaction-status screens read a token's scale from the bundled list, the tokens the user tracks, then the block explorer, but read its symbol from the bundled list alone. A token the user added by hand was scaled correctly yet labelled "Unknown token", and a non-bundled ERC-20 was carried onto the wait screen as ETH. resolveTokenSymbol() now draws the symbol through the same sources and precedence as the scale, and the ERC-20 and Uniswap swap lines both use it. A tracked or explorer-reported name stays subject to the spoof rule, so it cannot claim a bundled or native ticker. Folds in #354. Model: opus-4-8 Co-authored-by: clawbot <clawbot@noreply.example.org>	2026-09-21 21:28:06 +02:00
clawbot	43784cab3f	harden: resolve or refuse the swap token scale instead of guessing 18 (closes #340) ... tokenInfo() returned decimals 18 for any token absent from the bundled list, so the swap approval line rendered a real 1000.00 of a 6-decimal token as 0.000000000001. The scale is now resolved from what the wallet already holds (bundled list, tracked tokens, explorer-reported decimals) or refused outright, matching the rule set for the ERC-20 path in #306. A refusal reuses unknownDecimalsAmount(), so it reads as "base units (decimals unknown)" with no decimal point and no symbol, and the same string propagates to rawValue so no downstream screen can render a figure the approval screen refused. No new network call on the approval path. Verified green on all three CI contexts: check, e2e-chrome, e2e-firefox.	2026-08-23 16:20:22 +02:00