Compare commits

...
1 Commits
Author SHA1 Message Date
sneak ee24afafd1 docs: name every approval-screen amount string, fix stale zero claim (closes #369)
e2e / e2e-chrome (push) Failing after 1s
e2e / e2e-firefox (push) Failing after 1s
check / check (push) Successful in 57s
The README's amount-display section carried a claim that contradicted the
tree: it said a genuine zero renders `0.0000`, but a swap's `Min. received`
worked example now shows `None (no minimum guaranteed)` for a zero minimum.
The claim is corrected — it holds for the ERC-20 amount, while the swap's
`Amount` and `Min. received` state their two misleading zeros (a V4 open
delta and a zero minimum) in words before the floor is reached.

A new list names every string an amount slot can show and what each means:
a formatted quantity, `Unlimited`, `All available (V4 open delta)`,
`None (no minimum guaranteed)`, base units with decimals unknown, and
`Unknown (not named in the calldata)`. It also records that a zero
`minBalance` on a `BALANCE_CHECK_ERC20` step now reads the no-minimum
wording where it once read `0.0000`. Each claim was checked against the
tree. Docs only; no code or tests change.

Model: opus-4-8
2026-09-21 22:49:20 +00:00
2 changed files with 52 additions and 3 deletions
+40 -3
View File
@@ -882,9 +882,14 @@ On those screens, when the truncated string would contain no digit from 1 to 9
and the value does, the amount is extended to its first significant digit
instead: `0.000000000000000001 DAI`, not `0.0000 DAI`. The test is on the whole
truncated string, integer part included, so `1.00005` still shows as `1.0000`
the exception only fires where the entire displayed figure would read as zero. A
genuine zero still renders `0.0000`, and truncation stays truncation: `0.99999`
shows as `0.9999`, never rounded up.
the exception only fires where the entire displayed figure would read as zero.
Truncation stays truncation: `0.99999` shows as `0.9999`, never rounded up. A
genuine zero reaching this rule renders `0.0000`, and the ERC-20
`approve`/`transfer` amount does exactly that. The swap's `Amount` and
`Min. received` lines never hand it one: the two zeros that would mislead there
— a V4 open-delta amount and a zero minimum — are stated in words before the
floor is reached, so on those lines a zero is never shown as `0.0000` (see the
list of amount-slot strings below).
The rule and its exception live in `src/shared/amountDisplay.js` as
`truncateAmount()` and `truncateAmountNeverZero()`. Everything the approval and
@@ -936,6 +941,38 @@ and compare against. Reading the stored field directly instead answers `null`
for a bundled or tracked token the explorer merely omitted, which is not a
refusal the wallet has any reason to make.
**Every string an amount slot can show:** taken together, the exceptions above
mean an amount line on the dApp approval screen (and the wait/success/error
screens that carry a figure forward) shows one of a fixed set of strings, not
always a number:
- A formatted quantity, e.g. `17.1900 USDT`: the token's scale is known and the
figure is at or above the floor, or below it and extended to its first
significant digit. This is `truncateAmountNeverZero()`
(`src/shared/amountDisplay.js`).
- `Unlimited`: an unbounded allowance or permit, which needs no scale to
describe — a `uint256`-max ERC-20 `approve` (`src/popup/views/approval.js`) or
a Permit2 amount at the `uint160` max on a swap's `Amount`
(`src/shared/uniswap.js`).
- `All available (V4 open delta)`: a V4 exact-in swap whose `amountIn` is zero.
V4 reads that zero as "use the whole open delta", not as a literal zero, so
the calldata states no quantity at all. Swap `Amount` line only
(`src/shared/uniswap.js`).
- `None (no minimum guaranteed)`: a zero minimum — the swap guarantees nothing
back. It is a literal zero slippage floor on a V2/V3/V4 swap, and it also
reaches a `BALANCE_CHECK_ERC20` step: a zero `minBalance`, which once rendered
`0.0000` beside the token symbol, now reads this. Swap `Min. received` line
(`src/shared/uniswap.js`).
- `<amount> base units (decimals unknown)`: the token's scale could not be
resolved, so the base-unit integer is shown with that caveat rather than
formatted (see Unknown token scale above). Reaches both the ERC-20 amount line
and the swap's `Amount` and `Min. received` (`unknownDecimalsAmount()` in
`src/shared/approvalAmount.js`).
- `Unknown (not named in the calldata)`: not an amount but the currency itself —
the `Token In` or `Token Out` line when nothing in the calldata established
which token, shown beside the amount and, like the strings above, a sentence
rather than a value (`src/shared/uniswap.js`).
#### Partial USD totals
Prices are fetched for the top 25 tokens only, so an address can hold assets the
+12
View File
@@ -132,6 +132,18 @@ but the review is broader than any of them.
constant rather than `isDebug()`, so it survives only in a debug build; a
testnet or the runtime debug toggle still raises the banner but without the
view id.
- 2026-09-21: `README.md` now documents the approval screen's amount-slot
vocabulary and no longer contradicts itself
([#369](https://git.eeqj.de/sneak/AutistMask/issues/369)). The stale claim
that a genuine zero still renders `0.0000` is corrected: it holds for the
ERC-20 amount, but the swap's `Amount` and `Min. received` state their two
misleading zeros in words upstream. The amount-display section now names every
string a slot can show — a formatted quantity, `Unlimited`,
`All available (V4 open delta)`, `None (no minimum guaranteed)`, base units
with decimals unknown, and `Unknown (not named in the calldata)` — and records
that a zero `minBalance` on a `BALANCE_CHECK_ERC20` step now reads
`None (no minimum guaranteed)` where it once read `0.0000`. Docs only; each
claim checked against the tree.
- 2026-08-30: An address no longer wraps, or is shortened to fit, in any of the
common views ([#380](https://git.eeqj.de/sneak/AutistMask/issues/380)). The
wallet list was the reported case: the address shared one row with the