MAX_DECIMALS in src/shared/transferAmount.js was 255, any uint8, but ethers' formatUnits() and parseUnits() refuse more than 80 decimal places (the real bound is 80, not the ~87 the issue estimated). A token reporting 81 to 255 made the formatter throw inside the swap decoder and the ERC-20 decoder, and their catches turned that into an approval screen with no decoded call.
MAX_DECIMALS is now 80, so toDecimals() refuses such a scale where it is read, and both approval paths show the amount as 5000000000 base units (decimals unknown), the existing wording for an unknown scale. The README's unknown token scale section states the bound.
Not visible in the diff: toDecimals() is the wallet's one scale check, so the balance list, the history list and the Send screen also treat such a token as having no known scale. Before, it stopped an address's token balances from refreshing and its history from loading.
The new tests fail against current next: both decoders return no decoded call for a token tracked at 81 decimals.
Judgement call: the catch { return null } in decode() is unchanged. With the bound, no scale reaches it any more; narrowing it further would let a swap deadline past the year 275760 throw out of the approval screen, filed as #437.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/AutistMask/issues/350.
`MAX_DECIMALS` in `src/shared/transferAmount.js` was 255, any `uint8`, but ethers' `formatUnits()` and `parseUnits()` refuse more than 80 decimal places (the real bound is 80, not the ~87 the issue estimated). A token reporting 81 to 255 made the formatter throw inside the swap decoder and the ERC-20 decoder, and their catches turned that into an approval screen with no decoded call.
`MAX_DECIMALS` is now 80, so `toDecimals()` refuses such a scale where it is read, and both approval paths show the amount as `5000000000 base units (decimals unknown)`, the existing wording for an unknown scale. The README's unknown token scale section states the bound.
Not visible in the diff: `toDecimals()` is the wallet's one scale check, so the balance list, the history list and the Send screen also treat such a token as having no known scale. Before, it stopped an address's token balances from refreshing and its history from loading.
The new tests fail against current `next`: both decoders return no decoded call for a token tracked at 81 decimals.
Judgement call: the `catch { return null }` in `decode()` is unchanged. With the bound, no scale reaches it any more; narrowing it further would let a swap deadline past the year 275760 throw out of the approval screen, filed as https://git.eeqj.de/sneak/AutistMask/issues/437.
Model: opus-5-5
toDecimals() accepted any uint8 scale, but formatUnits() and parseUnits()
refuse more than 80 decimal places. A token reporting 81 to 255 made the
formatter throw, and the catch in the swap decoder and in the ERC-20 decoder
turned that into an undecoded approval screen with nothing saying why.
MAX_DECIMALS is now 80, the formatter's own limit, so such a scale is
treated exactly like an unknown one: both approval paths show the base-unit
amount with the scale stated as unknown. The balance list, the history list
and the Send screen use the same check.
Model: opus-5-5
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.
Closes #350.
MAX_DECIMALSinsrc/shared/transferAmount.jswas 255, anyuint8, but ethers'formatUnits()andparseUnits()refuse more than 80 decimal places (the real bound is 80, not the ~87 the issue estimated). A token reporting 81 to 255 made the formatter throw inside the swap decoder and the ERC-20 decoder, and their catches turned that into an approval screen with no decoded call.MAX_DECIMALSis now 80, sotoDecimals()refuses such a scale where it is read, and both approval paths show the amount as5000000000 base units (decimals unknown), the existing wording for an unknown scale. The README's unknown token scale section states the bound.Not visible in the diff:
toDecimals()is the wallet's one scale check, so the balance list, the history list and the Send screen also treat such a token as having no known scale. Before, it stopped an address's token balances from refreshing and its history from loading.The new tests fail against current
next: both decoders return no decoded call for a token tracked at 81 decimals.Judgement call: the
catch { return null }indecode()is unchanged. With the bound, no scale reaches it any more; narrowing it further would let a swap deadline past the year 275760 throw out of the approval screen, filed as #437.Model: opus-5-5
PASS
Model: opus-5-5