Found during the #689 review. The USD wallet has no fee probe for LNURL destinations before an invoice exists, so MAX deliberately falls back to filling the full balance (documented in buildMaxAmountButton). Whenever the real fee is > 0, that amount then fails at confirm with the amount-exceeds-balance error — the same wall a user hits typing their full balance manually, but the MAX chip now actively invites it.
Options, roughly in order of preference:
- Request a throwaway invoice at the cap-clamped balance during the MAX computation and run the normal fee probe against it (cost: one extra invoice round-trip on tap).
- Reserve a conservative fee heuristic (e.g. the wallet's recent LNURL fee p95) and state it in the note.
- Accept the dead-end but catch the confirm-time error and offer a one-tap "retry with fee deducted".
Related: #690 (displayed vs spendable balance), #689 (MAX button), flash#480 (fractional balance serving).
🤖 Generated with Claude Code
https://claude.ai/code/session_015fAxSGEsL2LsMx1uCjAzHH
Found during the #689 review. The USD wallet has no fee probe for LNURL destinations before an invoice exists, so MAX deliberately falls back to filling the full balance (documented in
buildMaxAmountButton). Whenever the real fee is > 0, that amount then fails at confirm with the amount-exceeds-balance error — the same wall a user hits typing their full balance manually, but the MAX chip now actively invites it.Options, roughly in order of preference:
Related: #690 (displayed vs spendable balance), #689 (MAX button), flash#480 (fractional balance serving).
🤖 Generated with Claude Code
https://claude.ai/code/session_015fAxSGEsL2LsMx1uCjAzHH