fix(asb): serialize Monero locks and refund unfundable swaps

[louislaugier]

Problem

Two swaps running at the same time can both select the same Monero output while building their lock transactions. wallet2 only marks an output spent after its lock transaction is relayed, and monero-sys has no reserve/freeze API, so the second lock becomes a permanent double-spend that monerod rejects, and that swap hangs until the cancel timelock (the recurring "xmr is refundable" reports).

A related case: when concurrent swaps together need more XMR than the maker holds, even a serialized second swap can be forced to reselect the first swap's freshly spent outputs, build a lock that double-spends, and then retry the rejected publish forever (the publish retry has no deadline), wedging until the cancel timelock.

Fix

1. Serialize the construct-to-first-publish window with a process-wide async mutex, so at most one unpublished lock exists at a time. Overlapping swaps that are each fundable then pick different outputs and both succeed. A max-hold deadline releases the mutex if a swap wedges on a rejected publish, so one stuck swap cannot starve the others.
2. Under that guard, before constructing, check the wallet's unlocked balance against what the lock needs. If a concurrent swap already consumed the shared balance, fail with a permanent error that routes to an early Bitcoin refund (no Monero is locked, so this is safe) instead of building a doomed double-spend that wedges the swap.

Testing

concurrent_bobs_before_xmr_lock_proof_sent and concurrent_bobs_after_xmr_lock_proof_sent (both swaps funded, both redeem), a new concurrent_bobs_insufficient_xmr (maker funded for only one of two concurrent swaps; the winner redeems, the loser refunds early rather than wedging), and happy_path all pass locally.

Mainnet: two wedges followed end to end, two distinct failure signatures

Running this change on a live maker (deployed 2026-08-21), I followed two wedges to their endings. They split the problem cleanly:

Swap 5eabdea8 (2026-08-26) — insufficient balance, missed by the pre-check. Wallet held 13.156 XMR against a 13.963 XMR lock; the pre-check still passed (it never logged its refusal — a stale unlocked_balance() read), the publish was rejected with an empty-reason TransactionRejected, and the swap retried that same transaction until the cancel timelock, ~4.2h. The balance recovering mid-wedge (20.29 XMR unreserved for 33 minutes) changed nothing.

Swap 0abd1dcd (2026-08-27) — ample balance, unreachable by any balance check. Wallet held 41.3 XMR unlocked against a 6.85 XMR lock; the pre-check was right to pass. But the constructed tx had selected outputs freshly spent by an earlier swap that wallet2 had not yet reflected, and monerod rejected that one fixed transaction 799 times over 3.9h until the cancel timelock. Meanwhile the max-hold deadline released the mutex and sibling swap 4f885739 constructed with fresh outputs and completed end-to-end (locked, redeemed) during the wedge — the serialization half doing exactly its job. Neither wedge ever locked Monero; both takers were refunded on time.

What this pins down:

• The construct-time gate must operate on outputs, not balance: the daemon-side is_key_image_spent query, as the primary check. Happy to wire it in, and to extract the lock phase into a testable struct per the review comment.
• The two end-states want different exits. Insufficient funds routes to the early Bitcoin refund this PR adds. Sufficient-funds-but-stale-selection would have been saved by rebuilding the lock tx on rejection — the direction feat(asb): rebuild xmr lock tx on confirmed double spend  #1142 explores. The two are complementary, not competing.

Relationship to #1142

#1142 explores rebuilding the lock transaction after a confirmed double-spend; the discussion there leaned toward aborting into a clean end state rather than rebuilding. This PR takes that route for the unfundable case — no Monero is ever locked, so there is nothing to rebuild. The 0abd1dcd wedge above shows the other case is real too: with ample funds and a stale selection, a rebuild succeeds where any abort forfeits a fillable swap. Its is_key_image_spent signal slots directly into this PR's early-refund trigger either way.

Related

• Manage Monero inputs efficiently #120: managing Monero inputs across concurrent swaps.
• Retry locking Monero #138: earlier report of concurrent swaps colliding on the Monero lock.
• feat(asb): rebuild xmr lock tx on confirmed double spend  #1142: rebuild-on-confirmed-double-spend; complementary per the mainnet evidence above.
• [RPC] "double_spend" error when using transfer followed by sendrawtransaction monero-project/monero#2585: the wallet2 behaviour (no spent-state update before relay) behind the double-spend.

AI disclosure: I used Claude (Fable 5 and Opus 5) to help investigate and write this change. I understand the code, tested it, and am responsible for it.

[louislaugier]

Update: reproduced this exact wedge on a live mainnet ASB today and deployed the full change (mutex + balance pre-check -> early refund). Details + an honest best-effort caveat (wallet2 lag; is_key_image_spent as the reliable follow-up) added to the PR description above.

[binarybaron]

Lets extract MONERO_LOCK_PHASE into a testable struct such that we don't have to put as much logic directly into the state machine.