5 Commits

Include renames

Author	SHA1	Message	Date
sneak	4910ad02fc	fix: Blockscout and Etherscan lookups are off until the user turns them on (closes #668) ... Out of the box the wallet sent the user's addresses to Blockscout and each recipient to Etherscan. Two settings, "Use Blockscout" and "Check recipients on Etherscan", now gate those requests. Both are off in a new install and offered unticked on Welcome and in Settings. While one is off, the screens that relied on it say so in a plain line. Each gated request reads its setting from storage before it asks and when the answer lands, and drops a late answer. An open popup takes another page's change and draws its screens again. While "Use Blockscout" is off, no address keeps an untracked token, and no screen names a token from Blockscout's report. ENS lookups ask only the RPC endpoint. Model: opus-5-5	2026-10-26 10:06:20 +00:00
clawbot	cf7ca99215	test: a token scale of zero decimals is used, not skipped (closes #325) ... resolveTokenDecimals() treats a scale of 0 from the bundled list or a tracked token as an answer, but nothing tested it: changing either `d !== null` check to a plain truthiness check left every test green while a zero-decimal token fell through to the next source or to "decimals unknown". The approval tests now assert a scale of 0 from each source, both from the resolver and on the approval screen's Amount line. toDecimals() was already shared from transferAmount.js since #349. Model: opus-5-5	2026-10-05 05:43:05 +02:00
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	50078b3566	fix: resolve approval-screen token decimals, and refuse to format an unknown scale (closes #306) ... decodeCalldata consulted only the 512-entry bundled list and defaulted to 18 decimals, so a transfer of 5,000 units of a 6-decimal token rendered "Amount 0.0000" and the user confirmed a drain reading zero. The same understatement applied to approve, where an unbounded allowance also rendered 0.0000. Decimals now resolve from the bundled list, then trackedTokens, then the address's explorer-reported entry, with uint8 validation and a refusal when sources for one contract disagree. When no source knows the scale, no formatUnits call is reached at all: the line renders raw base units with an explicit "decimals unknown" warning, and the same string reaches pendingTxDetails.amount so the status screens carry no formatted figure either. Verified failing first two independent ways: restoring the old `token ? token.decimals : 18` fails 6 of 15 new tests with the unknown case reporting "0.0000"; making the resolver return 18 rather than null on the unknown path fails a different 6, spanning resolver and render levels.	2026-08-20 12:57:38 +02:00