docs: describe the bundled token list by its criterion, not a drifting count (closes #239)

README.md

@@ -443,9 +443,9 @@ The core hierarchy is **Wallets → Addresses**:
 Which tokens an address shows is decided by `fetchTokenBalances()` in
 `src/shared/balances.js`, from the Blockscout `token-balances` response, so
 tokens do appear without the user adding them. An ERC-20 is shown when its
-balance is nonzero and it is in the bundled top-250 token list, is tracked by
-the user, or has 1,000 or more holders; a token claiming a symbol from the
-bundled list from any other contract address is always dropped. That filter is
+balance is nonzero and it is in the bundled known-token list, is tracked by the
+user, or has 1,000 or more holders; a token claiming a symbol from the bundled
+list from any other contract address is always dropped. That filter is
 unconditional — the "Hide tokens with fewer than 1,000 holders" setting governs
 the transaction history and the send-screen token selector, not this list.
 Tracked tokens with a zero balance are listed as well while "Show tracked tokens
@@ -1008,7 +1008,7 @@ communicates with three external services to function as a wallet:
 What the extension does NOT do:
 
 - No analytics or telemetry services
-- No token list APIs (the top-250 token list is bundled at build time)
+- No token list APIs (the known-token list is bundled at build time)
 - No Infura/Alchemy dependency (any JSON-RPC endpoint works)
 - No backend servers operated by the developer
 
@@ -1136,8 +1136,8 @@ hardcoded test phrase.
 - Add multiple addresses within an HD wallet
 - Manage multiple wallets simultaneously
 - View ETH balance per address
-- View ERC-20 token balances (bundled top-250 tokens, tokens with 1,000 or more
-  holders, and tokens the user adds by contract address)
+- View ERC-20 token balances (tokens on the bundled known-token list, tokens
+  with 1,000 or more holders, and tokens the user adds by contract address)
 - Send ETH to an address
 - Send ERC-20 tokens to an address
 - Receive ETH/tokens (display address, copy to clipboard, QR code)
@@ -1195,26 +1195,30 @@ indexes it as a real token transfer.
   address. Users should always verify the full address on the confirmation
   screen before signing or sending.
 
-- **Known token symbol verification**: AutistMask ships a hardcoded list of the
-  top 250 ERC-20 tokens with their legitimate contract addresses and symbols.
-  Any token transfer claiming a symbol from this list (e.g. "ETH", "USDT",
-  "USDC") but originating from an unrecognized contract address is identified as
-  a spoof and filtered from display. The fake "Ethereum" token in the attack
-  above used symbol "ETH" from contract
-  `0xD05339f9Ea5ab9d9F03B9d57F671d2abD1F55c82`, which does not match the known
-  WETH contract — so it would be caught by this check. Detecting a spoof is also
-  what adds a contract to the fraud contract blocklist below; that is the only
-  thing that populates it. In the transaction history the check is the "Hide
-  fake tokens impersonating a known symbol" setting, on by default; with it off,
-  spoofed transfers are shown and no new blocklist entries are learned from
-  them. The send-screen token selector applies the same check unconditionally,
-  because it decides which tokens the user can act on rather than what the
-  history displays. The balance list applies it unconditionally too, but not
-  identically: it exempts symbols that `KNOWN_SYMBOLS` maps to `null`, and
-  `"ETH"` is the only one. So the fake "Ethereum" token above is filtered from
-  the transaction history and from the send selector, but a fake-`ETH` ERC-20
-  that clears the balance list's own 1,000-holder floor — or that the user
-  tracked manually — is still shown in the balance list.
+- **Known token symbol verification**: AutistMask ships a hardcoded list of
+  high-market-cap ERC-20 tokens with their legitimate contract addresses and
+  symbols. The list is a point-in-time snapshot of the highest-market-cap
+  Ethereum mainnet ERC-20s taken from the CoinGecko API, with decimals verified
+  on-chain and addresses EIP-55 checksummed; `TOKENS` in
+  `src/shared/tokenList.js` is the authoritative set. It is bundled at build
+  time and only changes when that file is regenerated. Any token transfer
+  claiming a symbol from this list (e.g. "ETH", "USDT", "USDC") but originating
+  from an unrecognized contract address is identified as a spoof and filtered
+  from display. The fake "Ethereum" token in the attack above used symbol "ETH"
+  from contract `0xD05339f9Ea5ab9d9F03B9d57F671d2abD1F55c82`, which does not
+  match the known WETH contract — so it would be caught by this check. Detecting
+  a spoof is also what adds a contract to the fraud contract blocklist below;
+  that is the only thing that populates it. In the transaction history the check
+  is the "Hide fake tokens impersonating a known symbol" setting, on by default;
+  with it off, spoofed transfers are shown and no new blocklist entries are
+  learned from them. The send-screen token selector applies the same check
+  unconditionally, because it decides which tokens the user can act on rather
+  than what the history displays. The balance list applies it unconditionally
+  too, but not identically: it exempts symbols that `KNOWN_SYMBOLS` maps to
+  `null`, and `"ETH"` is the only one. So the fake "Ethereum" token above is
+  filtered from the transaction history and from the send selector, but a
+  fake-`ETH` ERC-20 that clears the balance list's own 1,000-holder floor — or
+  that the user tracked manually — is still shown in the balance list.
 
 - **Low-holder token filtering**: Token transfers from ERC-20 contracts with
   fewer than 1,000 holders are hidden from transaction history by default.