The approval screen and the wait/success/error status screens now resolve a token's symbol from the bundled list, then the tokens the user tracks, then the block explorer's report — the same sources and precedence the amount line already used for the token's scale. resolveTokenSymbol() sits beside resolveTokenDecimals() in src/shared/approvalAmount.js, and both the ERC-20 line and the Uniswap swap lines call it, so there is one chain, not two.
Why
A token the user added by hand was scaled correctly yet labelled Unknown token; a non-bundled ERC-20 was even carried onto the wait screen as ETH. The name and the scale disagreed about which sources they trusted. Folds in #354.
What a reader might trip over
A tracked or explorer-reported symbol is user-supplied text, so it stays subject to the spoof rule in src/shared/symbolSpoof.js: a candidate wearing a bundled or native ticker from a contract not entitled to it is refused and the next source tried. Unknown token is still shown when nothing names it.
The amount line now appends the resolved symbol for a tracked/explorer token (e.g. 5000.0000 NOVEL), as bundled tokens already render; three decimals-focused tests that asserted the old symbol-less string are updated to match.
Disclosures
Judgement call: symbol resolution now also feeds the amount suffix and the description, not just the bold token label, so the name is trusted wherever the scale is.
Deviation: ran jest directly once to enumerate failing assertions; all gating went through make check.
make check green under the shared-host gate flock.
Model: opus-4-8
## What changed
The approval screen and the wait/success/error status screens now resolve a token's symbol from the bundled list, then the tokens the user tracks, then the block explorer's report — the same sources and precedence the amount line already used for the token's scale. `resolveTokenSymbol()` sits beside `resolveTokenDecimals()` in `src/shared/approvalAmount.js`, and both the ERC-20 line and the Uniswap swap lines call it, so there is one chain, not two.
## Why
A token the user added by hand was scaled correctly yet labelled `Unknown token`; a non-bundled ERC-20 was even carried onto the wait screen as `ETH`. The name and the scale disagreed about which sources they trusted. Folds in https://git.eeqj.de/sneak/AutistMask/issues/354.
## What a reader might trip over
- A tracked or explorer-reported symbol is user-supplied text, so it stays subject to the spoof rule in `src/shared/symbolSpoof.js`: a candidate wearing a bundled or native ticker from a contract not entitled to it is refused and the next source tried. `Unknown token` is still shown when nothing names it.
- The amount line now appends the resolved symbol for a tracked/explorer token (e.g. `5000.0000 NOVEL`), as bundled tokens already render; three decimals-focused tests that asserted the old symbol-less string are updated to match.
## Disclosures
- Judgement call: symbol resolution now also feeds the amount suffix and the description, not just the bold token label, so the name is trusted wherever the scale is.
- Deviation: ran jest directly once to enumerate failing assertions; all gating went through `make check`.
`make check` green under the shared-host gate flock.
Model: opus-4-8
PASS. The token's symbol is now drawn through one chain — the bundled list, then the tokens the user tracks, then the block explorer's report, the same precedence and the same spoof guard the amount line already used for the scale — so a hand-added or held token is named instead of shown as Unknown token, a non-bundled ERC-20 is no longer carried onto the wait screen as ETH, a tracked or explorer-reported name that wears a bundled or native ticker it is not entitled to is still refused on every path (approval line, amount suffix, description and the wait, success and error screens), and the definition of done for #323 and the folded-in #354 is met with meaningful tests and a green local make check.
Model: opus-4-8
PASS. The token's symbol is now drawn through one chain — the bundled list, then the tokens the user tracks, then the block explorer's report, the same precedence and the same spoof guard the amount line already used for the scale — so a hand-added or held token is named instead of shown as `Unknown token`, a non-bundled ERC-20 is no longer carried onto the wait screen as `ETH`, a tracked or explorer-reported name that wears a bundled or native ticker it is not entitled to is still refused on every path (approval line, amount suffix, description and the wait, success and error screens), and the definition of done for https://git.eeqj.de/sneak/AutistMask/issues/323 and the folded-in https://git.eeqj.de/sneak/AutistMask/issues/354 is met with meaningful tests and a green local `make check`.
Model: opus-4-8
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
Rebased onto current next (2da790f); new head 3b94a17d356d863e05dfb509122feee8770be1e2.
The only conflict was in TODO.md: this unit's Completed Steps entry (#323) now sits directly after the 2026-09-21 entries already on next. Nothing else changed. Local make check is green on the rebased head.
Model: opus-4-8
Rebased onto current `next` (`2da790f`); new head `3b94a17d356d863e05dfb509122feee8770be1e2`.
The only conflict was in `TODO.md`: this unit's Completed Steps entry ([#323](https://git.eeqj.de/sneak/AutistMask/issues/323)) now sits directly after the 2026-09-21 entries already on `next`. Nothing else changed. Local `make check` is green on the rebased head.
Model: opus-4-8
clawbot
merged commit 2fe6447625 into next2026-09-21 21:28:06 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What changed
The approval screen and the wait/success/error status screens now resolve a token's symbol from the bundled list, then the tokens the user tracks, then the block explorer's report — the same sources and precedence the amount line already used for the token's scale.
resolveTokenSymbol()sits besideresolveTokenDecimals()insrc/shared/approvalAmount.js, and both the ERC-20 line and the Uniswap swap lines call it, so there is one chain, not two.Why
A token the user added by hand was scaled correctly yet labelled
Unknown token; a non-bundled ERC-20 was even carried onto the wait screen asETH. The name and the scale disagreed about which sources they trusted. Folds in #354.What a reader might trip over
src/shared/symbolSpoof.js: a candidate wearing a bundled or native ticker from a contract not entitled to it is refused and the next source tried.Unknown tokenis still shown when nothing names it.5000.0000 NOVEL), as bundled tokens already render; three decimals-focused tests that asserted the old symbol-less string are updated to match.Disclosures
make check.make checkgreen under the shared-host gate flock.Model: opus-4-8
PASS. The token's symbol is now drawn through one chain — the bundled list, then the tokens the user tracks, then the block explorer's report, the same precedence and the same spoof guard the amount line already used for the scale — so a hand-added or held token is named instead of shown as
Unknown token, a non-bundled ERC-20 is no longer carried onto the wait screen asETH, a tracked or explorer-reported name that wears a bundled or native ticker it is not entitled to is still refused on every path (approval line, amount suffix, description and the wait, success and error screens), and the definition of done for #323 and the folded-in #354 is met with meaningful tests and a green localmake check.Model: opus-4-8
2a918bf6bfto3b94a17d35Rebased onto current
next(2da790f); new head3b94a17d356d863e05dfb509122feee8770be1e2.The only conflict was in
TODO.md: this unit's Completed Steps entry (#323) now sits directly after the 2026-09-21 entries already onnext. Nothing else changed. Localmake checkis green on the rebased head.Model: opus-4-8