fix: the approval screen says "Unknown token" for tokens whose symbol is already known #323

New Issue

clawbot · 2026-08-20T12:50:58+02:00

clawbot commented

2026-08-20 12:50:58 +02:00

Found while implementing #306. Not in that issue's definition of done, so left untouched.

The dApp approval screen labels anything outside the 512-entry bundled list as Unknown token, even when the symbol is already available from state.trackedTokens or from the address's own explorer-reported tokenBalances. resolveSymbol() in src/shared/tokenList.js exists for exactly this lookup and is not consulted here.

Consequence is UX, not safety: a user is shown "Unknown token" for a token they added themselves and hold a balance of, which trains them to disregard the label — and the label is one of the signals that ought to distinguish a familiar token from an attacker's.

Note the ordering constraint: #306 added the same three-source resolution chain for decimals (src/shared/approvalAmount.js). The symbol should reuse that chain rather than introduce a second one with its own precedence, so land this after #306.

Definition of done

The approval screen resolves the token symbol from the bundled list, then state.trackedTokens, then the address's explorer-reported entry — the same precedence and, where practical, the same code path as the decimals resolution.
Unknown token is shown only when no source knows the symbol, and continues to be shown in that case rather than guessing.
A symbol from an untrusted source is still subject to the existing spoof rule in src/shared/symbolSpoof.js — resolving a symbol must not create a new way to claim a bundled ticker.
Test covers: bundled token, tracked-only token, explorer-only token, and genuinely unknown token.
make check green.

Found while implementing https://git.eeqj.de/sneak/AutistMask/issues/306. Not in that issue's definition of done, so left untouched. The dApp approval screen labels anything outside the 512-entry bundled list as `Unknown token`, even when the symbol is already available from `state.trackedTokens` or from the address's own explorer-reported `tokenBalances`. `resolveSymbol()` in `src/shared/tokenList.js` exists for exactly this lookup and is not consulted here. Consequence is UX, not safety: a user is shown "Unknown token" for a token they added themselves and hold a balance of, which trains them to disregard the label — and the label is one of the signals that ought to distinguish a familiar token from an attacker's. Note the ordering constraint: https://git.eeqj.de/sneak/AutistMask/issues/306 added the same three-source resolution chain for **decimals** (`src/shared/approvalAmount.js`). The symbol should reuse that chain rather than introduce a second one with its own precedence, so land this after #306. ## Definition of done - [ ] The approval screen resolves the token symbol from the bundled list, then `state.trackedTokens`, then the address's explorer-reported entry — the same precedence and, where practical, the same code path as the decimals resolution. - [ ] `Unknown token` is shown only when no source knows the symbol, and continues to be shown in that case rather than guessing. - [ ] A symbol from an untrusted source is still subject to the existing spoof rule in `src/shared/symbolSpoof.js` — resolving a symbol must not create a new way to claim a bundled ticker. - [ ] Test covers: bundled token, tracked-only token, explorer-only token, and genuinely unknown token. - [ ] `make check` green.

clawbot commented

2026-08-20 12:57:54 +02:00

Fold this in — same cause, and it now reads worse than before.

pendingTxDetails.token stays "ETH" for a non-bundled ERC-20, so src/popup/views/txStatus.js:84 renders the wait summary as:

5000000000 base units (decimals unknown) ETH

Pre-existing and not introduced by #306 — the old code produced 5000.0000 ETH for the same case, which was wrong in a quieter way. Naming an ERC-20 transfer as ETH on a status screen is the same missing symbol resolution this issue is about, so the DoD here should cover pendingTxDetails.token and the status screens, not only the approval screen.

Fold this in — same cause, and it now reads worse than before. `pendingTxDetails.token` stays `"ETH"` for a non-bundled ERC-20, so `src/popup/views/txStatus.js:84` renders the wait summary as: ``` 5000000000 base units (decimals unknown) ETH ``` Pre-existing and not introduced by https://git.eeqj.de/sneak/AutistMask/pulls/306 — the old code produced `5000.0000 ETH` for the same case, which was wrong in a quieter way. Naming an ERC-20 transfer as ETH on a status screen is the same missing symbol resolution this issue is about, so the DoD here should cover `pendingTxDetails.token` and the status screens, not only the approval screen.

clawbot referenced this issue

2026-08-20 14:26:18 +02:00

pre-1.0 security review: key handling, DEBUG-mode policy, RPC input validation #303

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/AutistMask#323