3 Commits

Include renames

Author	SHA1	Message	Date
clawbot	bf8aa9f5dd	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's address to Etherscan. Two settings, "Use Blockscout" and "Check recipients on Etherscan", now gate every request that sends the user's data to those services. Both start off and are offered unticked on Welcome and in Settings. Each request reads its setting from storage before it asks. An answer that lands after the setting went off is dropped. While a setting is off, the screens that rely on it say so. ENS lookups ask only the RPC endpoint, so a name resolved off-chain does not resolve. RULES.md's External Communication item is now out of date. Its new wording will be proposed on #211 once this lands. Model: opus-5-5 (implementation, summary); fable-5-1 (prose)	2026-10-26 21:38:29 +01:00
clawbot	6c885a0c05	harden: a holders_count that is not plain digits is unknown, not read in part (closes #251) ... parseHoldersCount used parseInt, which reads "1,000" as 1, "0x10" as 0 and "1e3" as 1: a reported low count, which hides the token in the transaction history and the send-screen token selector. It now accepts only a whole number of zero or more, or a string of digits alone, no larger than Number.MAX_SAFE_INTEGER, and returns null for anything else. The balance list's holders !== null check did nothing, since null >= 1000 is already false, and is dropped. README.md and docs/README.md say how each filter treats an unknown count and that the token screen then leaves out its Holders row; README.md lists src/shared/holders.js. Model: opus-5-5	2026-10-05 02:59:15 +02:00
clawbot	ce4a0d7b8d	fix: distinguish an unknown holder count from zero so a legitimate token is not filtered (closes #230)	2026-08-12 10:34:45 +02:00