Repository navigation
feat: recheck on-chain required amount against actual UTXO count - #930
Closed
dangershony wants to merge 2 commits into
Closed
dangershony wants to merge 2 commits into
dangershony wants to merge 2 commits into
Conversation
Member
Author
|
I am not convinced this commit should go in |
…r funds arrive The signing transaction for on-chain invoice payments spends ALL UTXOs on the funding address and pays ~68 vB per input. If the user's payment arrives as multiple UTXOs (two separate sends, exchange withdrawal splits, RBF leftovers), the originally displayed amount no longer covers the miner fee, and BuildInvestmentDraft fails with 'Insufficient funds' after the payment was declared received. Add PaymentFlowConfig.OnChainRequiredForUtxoCount: after MonitorAddressForFunds succeeds, recompute the required amount for the actual detected UTXO count. If the received total is short, tell the user the exact shortfall and keep monitoring for the top-up instead of proceeding to a signing failure. Also add an EstimateOnChainRequired overload that accepts an input count.
dangershony
force-pushed
the
feat/onchain-dynamic-utxo-recheck
branch
from
October 15, 2026 10:39
80ebefe to
11fdb82
Compare
Member
Author
|
Closing in favor of a different approach: instead of recomputing the required amount per detected UTXO and asking the user to top up the invoice address (which has a moving-target problem — each top-up adds an input and raises the fee — and a mempool-only monitor race when the first payment confirms mid-wait), we'll detect >1 UTXO and redirect the user to the existing pay-from-wallet path. The funds already land in the wallet (MonitorAddressForFunds saves detected UTXOs to account info), and AddInputsAndSignTransaction does proper coin selection with per-input fees, so no estimator changes or top-up loop are needed. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes the multi-UTXO payment bug: signing spends all UTXOs on the funding address at ~68 vB each, but the displayed on-chain amount assumed one input. After funds arrive, PayToOnChainAddressAsync now recomputes the required amount for the actual detected UTXO count (PaymentFlowConfig.OnChainRequiredForUtxoCount) and keeps monitoring for the shortfall with a clear message, instead of failing at signing with "Insufficient funds". Wired for the invest flow only (InvestPageViewModel.CreatePaymentFlow); deploy flow intentionally not wired.
Supersedes #929 (closed).
Rebase notes
Tests
Angor.Shared.Tests, Angor.Sdk.Tests and LayoutRegression tests pass. App.Desktop builds clean (App.sln can't build locally without the iOS workload).
Caveats / follow-ups