3 Commits

Include renames

Author	SHA1	Message	Date
sneak	75a24b59e7	fix: Send refuses every amount the confirmation screen would refuse (closes #532) ... Send accepted any amount parseFloat() read as above zero, so "1e-3", "1abc" and an amount with a nonzero digit past the token's decimal places reached ConfirmTx, which then refused them. isValidAmount() in src/shared/txValidation.js is now the one check: Review and Max on Send call it with the token's decimal places, and validateTransfer() calls it for ConfirmTx, which now also refuses a zero amount and a token amount with a nonzero digit past the token's places. Zeros past those places are accepted, since the amount encoded for the transfer is the same. Model: opus-5-5	2026-10-18 19:34:11 +00:00
clawbot	a207ac70bd	feat: a "Max" button on the Send screen (closes #198) ... Max fills in a token's balance, cut down to the 18 decimal places the confirmation screen accepts, or for ETH the exact balance minus the fee reserve the confirmation screen's balance check gates on. An ETH fee estimate that finishes after the Send screen was left, or its address, holding, recipient or amount changed, fills nothing in. The confirmation screen works a max ETH amount out again from its own fee estimate and signs it with that estimate's fee fields, so a fee that rose before signing cannot push amount plus fee above the balance. validateTransfer() still gates every send, the check that ETH covers a token send's fee included. Where there is nothing to fill in, a flash message says why. Model: opus-5-5	2026-10-05 07:43:06 +02:00
clawbot	158278d251	fix: count the network fee in the confirm-screen balance check (closes #154)	2026-08-11 15:41:37 +02:00