[Claudius-Maginificent]

TL;DR: "Max" on a send from Core to the shielded pool moves the whole Core balance minus fees. An interrupted transfer can be finished from the Shielded tab. Stacked atop #1028 (fix/orphaned-tx). Blocked on dashpay/platform#5528, which #1028 pins.

User story

As a wallet user, I want Max on a Core-to-shielded send to shield everything I have, so that no dust is left behind and the send never fails for being a few duffs short of its own fees.

Scenario

Actual behavior

Max shields an estimated amount. The estimate can come up short of the real fees, or leave a small remainder in Core.

Expected behavior

Max shields the whole balance minus fees. The amount is fixed only when the funding transaction is built. If the app closes mid-transfer, the Shielded tab says the transfer is unfinished and offers "Finish now". That resumes the same transfer without paying twice.

Detailed discussion

Stacked atop #1028, which pins all Platform dependencies to 344e110a6, the head of dashpay/platform#5528 (stack #5150 → #5207 → #5210 → #5528). #5528 is the first point where SqlitePersister attests the wallet-drain persistence contract. This PR changes no dependency. It merges after #1028, once #5528 is on v5.1-dev.

• Max drain: runs the upstream pooled wallet drain.
  • The drain is registered with the wallet first, and only then is its operation id stored in the DET k/v sidecar, scoped to the wallet and network. The registration is held until the drain returns, so a status read in between sees a running transfer, never "not sent". It is dropped before the outcome is read, so a drain that ended before building its lock reads as not sent and releases its id. The id is removed only once the transfer has an outcome.
  • A second Max transfer waits for the first to settle.
  • A read-only preview refuses a wallet that cannot cover the fees, or that holds too many coins for one transfer, before anything is stored. It also refuses, with a dedicated message, a spendable balance that differs from the one the user confirmed, so the drain moves what the confirmation showed. The lock floor is upstream's: it drops a drain too small to pay the pool fee before broadcast. "Finish now" resumes without a preview.
• Shielded tab: looks up a stored transfer on arrival. While the transfer is unfinished, the tab offers "Finish now", which resumes the same drain and never builds a second funding lock. The status read moves no funds.
• Send form: the caption says that Max moves the whole balance. Sending a Max transfer first fetches the drain's own read-only quote. The confirmation then shows the spendable Core balance the transfer spends, the fees and the expected shielded amount. That balance excludes CoinJoin and unconfirmed funds. The quote covers every account the drain pools (BIP44, BIP32 and DashPay receiving funds), and the confirmed balance travels with the transfer. In the Shield flow the destination is the wallet's own shielded balance, and both the Max and the exact-amount confirmations say so instead of naming an empty address. Editing the amount, switching wallet or network, or resetting the form returns to an exact-amount send.
• User story SND-007 is updated in docs/user-stories.md.

What moved to #1028: two of this PR's former commits.

• 85077af5b, the adaptation to the drain-capable stack: the conflicted asset-lock status and the AssetLockFundingConflicted error. fix(wallet): surface unresolved Platform funding transfers #1028 carries it as a cherry-pick, because it does not compile at the pin without it. The boxed WalletStorageError is already on the base (c1f1a5ae71).
• fef5d6e0b, which ran the newer wallet migrations over bridged profiles. It is dropped: fix(wallet): surface unresolved Platform funding transfers #1028's own bridge stages the V019 reference schema and runs V020/V021 over the translated rows.

This PR now carries only the feature.

TODO(max-drain-1107): #1107 (feat/wallet-max-send-limits) makes the Core→Shielded Max a backend-quoted asset-lock ceiling, while this PR makes an untouched Max a whole-balance drain. Whichever lands second must merge them, so that one component owns the button: #1107's quote and limits, with the drain where Max is untouched.

• Known gap left for that merge: the amount field still fills in the BIP44-only estimate. Only the confirmation shows the drain's own quote.
• Also left for that merge: Max is hidden when BIP44 alone cannot pay the fee, even if BIP32 or DashPay funds could.

Testing

• Clippy --all-features --lib --tests -- -D warnings is clean.
• The library tests for the drain, the Shielded tab, the send screen, the shielded backend and the fee estimation pass.
• Orchestration tests on an offline context with the in-memory store cover:
  • a status read between storing the id and starting the drain keeps the transfer pending;
  • an unrun transfer settles as not sent and releases its id;
  • a second transfer is refused;
  • Finish and status without a stored transfer;
  • an unreadable record counting as pending.
• Orchestration tests also cover:
  • a drain that fails before building its lock settles as not sent and releases its id;
  • a refused second transfer leaves no registration behind.
• Unit tests cover the drain-run state derivation, the quote, and the refusal of a changed balance.
• Send form tests cover:
  • the quote-then-confirm flow, with the transfer bound to the confirmed balance;
  • the literal confirmation sentences for the own-pool marker and for a typed address;
  • the exact-amount own-pool sentence;
  • a late quote after an edit, a wallet change or a network switch.
• Not live-tested on testnet, and no backend-e2e covers the drain or its resume.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

🤖 Generated with Claude Code

https://claude.ai/code/session_012ujJpB9DBhvtbjhYB3aG9Q

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

🕓 Review not started yet because this PR is a draft.

• Request normal review — click when the PR is ready for review.
• Request priority review — click to move this review to the front of the queue.

Commit e473f30. Normal review starts when eligible; priority review starts as soon as a slot is available.

[Claudius-Maginificent]

Blocked on dashpay/platform#5528 (open draft), the head of the stack dashpay/platform#5150, dashpay/platform#5207, dashpay/platform#5210, then #5528 (all open). The temporary pin cc5d498837 is not on v5.1-dev, so the pin-ancestry guard fails. When #5528 merges, repin to the v5.1-dev merge commit and take the PR out of draft.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

[Claudius-Maginificent]

Rebuilt on top of #1028 (fix/orphaned-tx, which now pins dashpay/platform#5528). The base is changed to fix/orphaned-tx. The PR is now 4 commits: the feature plus the review fixes; the Platform pin comes from #1028.

Still blocked: it depends on #1028, which waits for the platform stack #5150 → #5207 → #5210 → #5528 to merge into v5.1-dev.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}