fix: an address holding only unpriced tokens reports its total as $0.00 #261

New Issue

2026-08-12T10:57:29+02:00

clawbot commented

2026-08-12 10:57:29 +02:00

getAddressValueUsd() returns 0, not null, when the ETH price is known but a held token's is not. Only the top 25 tokens are priced (src/shared/prices.js:21), so an address holding only unpriced ERC-20s renders Total: $0.00.

It is wrong in the direction that matters: the user is told their address is worth nothing when it may hold a great deal. On the address-removal confirmation added by #240 it lands directly beneath "This address holds a balance.", which reads as a contradiction — though the per-token line does still show the real quantity.

Pre-existing and shared: the same helper behaves identically on Home and AddressDetail. Found by the independent review of #240, which reused the helper exactly as its own round-1 review had asked, so it was not blocked there.

Implementation requirements

Distinguish "worth zero" from "worth an unknown amount" — the same absent-versus-zero distinction #230 drew for holder counts.
Decide deliberately what to show when the total is partially known and say why in the PR body. A total covering only the priced portion is misleading unless it is labelled as partial; suppressing the line entirely loses the ETH figure the user could have had.
Apply it everywhere the helper is consumed — Home, AddressDetail, and the address-removal confirmation.

Definition of done

An address holding only unpriced tokens does not report $0.00.
An address genuinely worth zero is still distinguishable from one whose value is unknown.
A fully-priced address is unchanged.
Tests cover all three cases, demonstrated failing first.
TODO.md updated in the same commit.
make check passes.

`getAddressValueUsd()` returns `0`, not `null`, when the ETH price is known but a held token's is not. Only the top 25 tokens are priced (`src/shared/prices.js:21`), so an address holding **only** unpriced ERC-20s renders `Total: $0.00`. It is wrong in the direction that matters: the user is told their address is worth nothing when it may hold a great deal. On the address-removal confirmation added by https://git.eeqj.de/sneak/AutistMask/pulls/240 it lands directly beneath "This address holds a balance.", which reads as a contradiction — though the per-token line does still show the real quantity. Pre-existing and shared: the same helper behaves identically on Home and AddressDetail. Found by the independent review of https://git.eeqj.de/sneak/AutistMask/pulls/240, which reused the helper exactly as its own round-1 review had asked, so it was not blocked there. ## Implementation requirements - Distinguish "worth zero" from "worth an unknown amount" — the same absent-versus-zero distinction https://git.eeqj.de/sneak/AutistMask/issues/230 drew for holder counts. - Decide deliberately what to show when the total is partially known and say why in the PR body. A total covering only the priced portion is misleading unless it is labelled as partial; suppressing the line entirely loses the ETH figure the user could have had. - Apply it everywhere the helper is consumed — Home, AddressDetail, and the address-removal confirmation. ## Definition of done - [ ] An address holding only unpriced tokens does not report `$0.00`. - [ ] An address genuinely worth zero is still distinguishable from one whose value is unknown. - [ ] A fully-priced address is unchanged. - [ ] Tests cover all three cases, demonstrated failing first. - [ ] `TODO.md` updated in the same commit. - [ ] `make check` passes.

clawbot referenced this issue from a commit

2026-08-17 08:10:16 +02:00

fix: an address holding only unpriced tokens is no longer totalled at $0.00 (closes #261)

clawbot referenced a pull request that will close this issue

2026-08-17 08:10:40 +02:00

fix: an address holding only unpriced tokens is no longer totalled at $0.00 (closes #261) #298

clawbot referenced this issue from a commit

2026-08-17 08:11:21 +02:00

fix: an address holding only unpriced tokens is no longer totalled at $0.00 (closes #261)

clawbot closed this issue

2026-08-17 08:38:11 +02:00

clawbot referenced this issue from a commit