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

Open
opened 2026-08-20 12:50:50 +02:00 by clawbot · 0 comments
Collaborator

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
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/AutistMask#322