fix: a nonzero approval amount still renders as 0.0000 when it is smaller than the 4-decimal display floor #322

New Issue

2026-08-20T12:50:50+02:00

clawbot commented

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

Found while implementing #306. Same visible failure as that issue — an amount the user is authorizing displayed as zero — but a different cause, so #306's fix does not close it.

formatTxValue truncates to 4 decimal places, per the documented display rule in README.md. With the correct scale now resolved, a small amount of a 6- or 8-decimal token still renders 0.0000: 500 base units of a 6-decimal token is 0.0005, which truncates to 0.0000.

Consequence

Bounded, unlike #306 — the understatement is always less than 0.0001 of a token unit, so this is not a drain rendered as zero. It is still a nonzero transfer or allowance displayed as nothing on the one screen whose entire job is to state what is being authorized, and on an 8-decimal high-value token the hidden quantity is not negligible.

The invariant worth holding is narrow and cheap: a nonzero amount must never render as zero. The 4-decimal rule is a scannability decision for summary views and should stay; it just cannot be allowed to produce a figure that reads as "nothing is being moved".

Definition of done

On the approval and confirmation screens, a nonzero amount never renders as 0.0000. Below the display floor, show enough precision to be nonzero, or show the raw base units — either is acceptable, silently rounding to zero is not.
The 4-decimal rule is otherwise unchanged; balance lists and history are not in scope.
README.md's Display Consistency section records the exception, since it currently states the 4-decimal rule without one.
Test: 500 base units of a 6-decimal token, and 1 base unit of an 18-decimal token, each render a nonzero string on the approval screen. Must fail against current head — state the mutation and observed result.
make check green.

Found while implementing https://git.eeqj.de/sneak/AutistMask/issues/306. Same visible failure as that issue — an amount the user is authorizing displayed as zero — but a different cause, so #306's fix does not close it. `formatTxValue` truncates to 4 decimal places, per the documented display rule in `README.md`. With the **correct** scale now resolved, a small amount of a 6- or 8-decimal token still renders `0.0000`: 500 base units of a 6-decimal token is 0.0005, which truncates to `0.0000`. ## Consequence Bounded, unlike #306 — the understatement is always less than 0.0001 of a token unit, so this is not a drain rendered as zero. It is still a nonzero transfer or allowance displayed as nothing on the one screen whose entire job is to state what is being authorized, and on an 8-decimal high-value token the hidden quantity is not negligible. The invariant worth holding is narrow and cheap: **a nonzero amount must never render as zero.** The 4-decimal rule is a scannability decision for summary views and should stay; it just cannot be allowed to produce a figure that reads as "nothing is being moved". ## Definition of done - [ ] On the approval and confirmation screens, a nonzero amount never renders as `0.0000`. Below the display floor, show enough precision to be nonzero, or show the raw base units — either is acceptable, silently rounding to zero is not. - [ ] The 4-decimal rule is otherwise unchanged; balance lists and history are not in scope. - [ ] `README.md`'s Display Consistency section records the exception, since it currently states the 4-decimal rule without one. - [ ] Test: 500 base units of a 6-decimal token, and 1 base unit of an 18-decimal token, each render a nonzero string on the approval screen. Must fail against current head — state the mutation and observed result. - [ ] `make check` green.

clawbot added this to the 1.0.0 milestone 2026-08-20 12:50:50 +02:00

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

clawbot referenced this issue from a commit

2026-08-23 15:18:29 +02:00

fix: never render a nonzero approval amount as zero (closes #322)

clawbot referenced a pull request that will close this issue

2026-08-23 15:18:51 +02:00

fix: never render a nonzero approval amount as zero (closes #322) #339

clawbot referenced this issue

2026-08-23 15:24:33 +02:00