4 Commits

Include renames

Author	SHA1	Message	Date
clawbot	5e4b8ff3b0	fix: the confirmation screen reads its balance on the network it is drawn for (closes #558) ... ConfirmTx showed and checked the balance Send handed it, so a screen the popup reopened onto stated the balance as Send knew it, not as it is on the network the screen is drawn for. Each time it is shown, ConfirmTx now reads the From address's ETH balance, and for a token send its token balance, from the node reviewedNetworkProvider() picks for the network the transaction was reviewed for, the node the fee estimate and recipient checks ask. The fee estimate starts once the read returns. Until then the balance line says "Loading..." and Sign & Send stays disabled; a failed read is stated as unknown. Each message the read can bring has a box reserved from the first paint, so nothing moves when it returns. Model: opus-5-5	2026-10-19 09:54:09 +02:00
clawbot	3b713809c8	harden: a token scale above 80 decimal places is refused as unknown (closes #350) ... 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	2026-10-04 21:43:11 +02:00
clawbot	1b52aa1723	fix: store an absent explorer decimals as unknown instead of fabricating 18 (closes #349) ... parseInt(decimals || "18") ran before writing stored tokenBalances[].decimals, so an explorer reporting no decimals produced a fabricated 18 indistinguishable from a real one at read time. That defeated the resolve-or-refuse guarantees of #306 and #340: their refusal paths were intact but never fired, because the guess was laundered upstream of them. An absent scale is now stored as unknown, and a holding whose scale nothing knows carries a null balance -- unknown, never zero -- with six reader sites saying so rather than printing 0.0000. The Send screen resolves the display scale rather than reading the stored one, so a bundled token whose explorer row omits decimals still sends; when the scale cannot be resolved the stored quantity is withdrawn too, so the user is told the balance is unknown rather than only that the fee failed. Existing fabricated 18s cannot be told apart retroactively and are replaced wholesale on the next balance refresh. An explorer-sourced scale stays trusted -- only fabrication is removed; the reasoning is recorded on the issue.	2026-08-23 21:19:04 +02:00
clawbot	2f80a9bdb4	fix: sign the ERC-20 amount the confirmation screen displayed (closes #305) ... The send screen was built from the indexer's decimals while the transfer was encoded from the contract's decimals() read at signing time, with nothing comparing them. A token whose scales disagree moved 10^12 times the approved amount. The displayed scale is now carried on pendingTx from the same tokenBalances entry the amount, balance and symbol were rendered from, and both encode sites use it. transferAmount.js refuses rather than falling back when the two scales disagree or either is unusable. Adds the first end-to-end coverage of the popup's own Send -> ConfirmTx -> Sign & Send path; #btn-confirm-send had never been clicked by any test.	2026-08-20 12:31:28 +02:00