* poc: monero receive pool with multiple redeem addresses for bob with given ratios
* fix: use new monero_receive_pool arg for buy_xmr
* update sweep/sweep_multi to return TxReceipt instead of String containing txid
* fix test (generate 1 block before checking balance after transfer)
* add move distribute function to rust, add property tests
* use rust distribute
* update sqlx cache/tempdb
* sqlx fix
* feat: update ui to display the monero address pool
* fix: remove unused functions, set dispatcher for tracing in wallet threads, use new subtract_fee wallet2 functionality
* Add patch system
* add wallet2_api_allow_subtract_from_fee patch
* apply git patches
* split monero-sys patches into chunks
* refactor
* .sqlx needs to be commited, revert unbound issue
* display pool on XmrRedeemInMempoolPage.tsx page, commit .sqlx folder
* fmt
* refactor
* assert MoneroAddressPool is on correct network, differntiate between stagenet and mainnet donaiton address
* looks ok
* re-add retry logic, database errors, ...
* add test
* add tests
* fmt comments, changelog
---------
Co-authored-by: Binarybaron <binarybaron@protonmail.com>
This diff introduces a new "approvals" mechanism that alters the swap flow by requiring explicit user intervention before the Bitcoin lock transaction is broadcast. Previously, the Bitcoin lock was executed automatically without any user prompt. Now, the backend defines `ApprovalRequestType` (e.g. a `PreBtcLock` variant with details like `btc_lock_amount`, `btc_network_fee`, and `xmr_receive_amount`) and `ApprovalEvent` (with statuses such as `Pending`, `Resolved`, and `Rejected`). The method `request_approval()` in the `TauriHandle` struct uses a oneshot channel and concurrent timeout handling via `tokio::select!` to wait for the user's decision. Based on the outcome—explicit approval or timeout/rejection—the approval event is emitted through the `emit_approval()` helper, thereby gating the subsequent broadcast of the Bitcoin lock transaction.
On the UI side, changes have been made to reflect the new flow; the modal (for example, in `SwapSetupInflightPage.tsx`) now displays the swap details along with explicit action buttons that call `resolveApproval()` via RPC when clicked. The Redux store, selectors, and hooks like `usePendingPreBtcLockApproval()` have been updated to track and display these approval events. As a result, the overall functionality now requires the user to explicitly approve the swap offer before proceeding, ensuring they are aware of the swap's key parameters and that the locking of funds occurs only after their confirmation.
