Skip to content

Make MAX and multi-recipient send exclusive - #6178

Open
j0ntz wants to merge 1 commit into
developfrom
jon/remove-max-multi-recipient
Open

Make MAX and multi-recipient send exclusive#6178
j0ntz wants to merge 1 commit into
developfrom
jon/remove-max-multi-recipient

Conversation

@j0ntz

@j0ntz j0ntz commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

CHANGELOG

Does this branch warrant an entry to the CHANGELOG?

  • Yes
  • No

Dependencies

none

Requirements

If you have made any visual changes to the GUI. Make sure you have:

  • Tested on iOS device
  • Tested on Android device
  • Tested on small-screen device (iPod Touch)
  • Tested on large-screen device (tablet)

Description

Asana: https://app.asana.com/0/1215088146871429/1209203315991847

MAX spends the entire spendable balance, which only has a coherent meaning for a
single recipient. Since the send scene gained 1-to-many support, MAX and
multi-send conflict in both orderings:

  • Tap MAX on recipient 2 and nothing happens. The recalculation effect only ever
    honors maxSpendSetter === 0, so a max requested by any later target sets
    state that nothing consumes.
  • Tap MAX on recipient 1, then add a second recipient with any amount, and the
    send fails with Insufficient Funds, because recipient 1 already claims the
    whole balance.

The operator's decision on the task (after twice rejecting a per-target
remainder calculation) is to make the two mutually exclusive. This does that in
both directions:

  1. handleFlipInputModal passes hideMaxButton to FlipInputModal2 once the
    send has more than one spend target. The prop already existed and is gated in
    ExchangedFlipInput2 alongside noMaxSpend, so no new plumbing.
  2. renderAddAddress withholds the "Add Another Address" row while a max spend
    is set. Clearing the max instead would silently discard an amount the user
    deliberately chose, so the entry point is withheld rather than the amount
    rewritten.

Single-recipient sends are unchanged, and currencies with maxSpendTargets < 2
never reach either branch.

Testing

Driven on the iOS simulator against a funded Bitcoin Testnet wallet
(maxSpendTargets 32, same multi-send path as mainnet BTC):

  • One recipient: MAX is present, and tapping it fills the amount as before.
  • With MAX applied: "Add Another Address" is gone.
  • Retyping the amount by hand on that same screen (which clears the max) brings
    the row back, so the two frames differ only in maxSpendSetter.
  • Two recipients: the amount modal has no MAX button.
  • A 2-recipient send still broadcasts to Transaction Success.

tsc --noEmit, jest (SendScene2 snapshots unchanged), and verify-repo.sh all pass.

@j0ntz

j0ntz commented Aug 28, 2026

Copy link
Copy Markdown
Contributor Author

📸 Test evidence

max present single recipient

max present single recipient

max set add address hidden

max set add address hidden

manual amount add address visible

manual amount add address visible

max hidden second recipient

max hidden second recipient

multisend broadcast success

multisend broadcast success

Captured by the agent's in-app test run (build-and-test).

MAX spends the entire spendable balance, which only has a coherent
meaning for a single recipient. The send scene now hides the MAX button
whenever the send has more than one spend target, and withholds the
"Add another address" row while a MAX amount is set, so the two can no
longer be combined into a transaction that always fails with
insufficient funds.
@j0ntz
j0ntz force-pushed the jon/remove-max-multi-recipient branch from 5526b61 to 62ef387 Compare August 28, 2026 02:35
@j0ntz
j0ntz marked this pull request as ready for review August 28, 2026 02:35
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant