#154 makes the confirmation screen correctly refuse a send whose amount plus network fee exceeds the balance. Correct, but it leaves no way to empty an account: the user must guess an amount, get refused, and adjust — with the fee moving under them between estimates.
Deliberately left out of scope there; filing it rather than losing it. Not milestoned — move it into 1.0.0 if you consider "cannot send your whole balance" a 1.0 defect rather than a missing convenience.
Implementation requirements
Compute max from the exact wei balance minus the live fee estimate, not from the truncated display balance. src/shared/balances.js may need to expose the untruncated value.
Re-derive whenever the fee estimate updates; a max amount pinned to a stale estimate is the same bug #154 fixed.
validateTransfer() in src/shared/txValidation.js stays the gate — a max send must pass it, not bypass it.
For ERC-20, max is the full token balance and is unaffected by the fee, but the ETH-for-gas check still applies.
Follow the README Language & Labeling and No Layout Shift rules.
Definition of done
A max ETH send leaves exactly the estimated fee behind and the confirmation screen enables Send.
The max amount re-derives when the fee estimate changes.
A max ERC-20 send offers the full token balance and is still refused when ETH cannot cover gas.
Unit tests cover the max computation against the exact-wei balance, demonstrated failing first.
TODO.md updated in the same commit.
make check passes.
https://git.eeqj.de/sneak/AutistMask/issues/154 makes the confirmation screen correctly refuse a send whose amount plus network fee exceeds the balance. Correct, but it leaves no way to empty an account: the user must guess an amount, get refused, and adjust — with the fee moving under them between estimates.
Deliberately left out of scope there; filing it rather than losing it. Not milestoned — move it into 1.0.0 if you consider "cannot send your whole balance" a 1.0 defect rather than a missing convenience.
## Implementation requirements
- Compute max from the exact wei balance minus the live fee estimate, not from the truncated display balance. `src/shared/balances.js` may need to expose the untruncated value.
- Re-derive whenever the fee estimate updates; a max amount pinned to a stale estimate is the same bug https://git.eeqj.de/sneak/AutistMask/issues/154 fixed.
- `validateTransfer()` in `src/shared/txValidation.js` stays the gate — a max send must pass it, not bypass it.
- For ERC-20, max is the full token balance and is unaffected by the fee, but the ETH-for-gas check still applies.
- Follow the README Language & Labeling and No Layout Shift rules.
## Definition of done
- [ ] A max ETH send leaves exactly the estimated fee behind and the confirmation screen enables Send.
- [ ] The max amount re-derives when the fee estimate changes.
- [ ] A max ERC-20 send offers the full token balance and is still refused when ETH cannot cover gas.
- [ ] Unit tests cover the max computation against the exact-wei balance, demonstrated failing first.
- [ ] `TODO.md` updated in the same commit.
- [ ] `make check` passes.
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.
#154 makes the confirmation screen correctly refuse a send whose amount plus network fee exceeds the balance. Correct, but it leaves no way to empty an account: the user must guess an amount, get refused, and adjust — with the fee moving under them between estimates.
Deliberately left out of scope there; filing it rather than losing it. Not milestoned — move it into 1.0.0 if you consider "cannot send your whole balance" a 1.0 defect rather than a missing convenience.
Implementation requirements
src/shared/balances.jsmay need to expose the untruncated value.validateTransfer()insrc/shared/txValidation.jsstays the gate — a max send must pass it, not bypass it.Definition of done
TODO.mdupdated in the same commit.make checkpasses.