fix: mint UTXO auto-consolidation fails when margin exceeds balance

[JohnnyLawDGB]

Problem

PR #391 introduced UTXO auto-consolidation for mintdigidollar to handle wallets with >400 UTXOs (the MAX_TX_INPUTS limit in txbuilder.cpp). However, the consolidation itself fails in a common scenario, leaving the bug effectively unfixed in RC25.

Reported by: @AussieEpic in DigiSwarm — confirmed the bug is still present in RC25 with >400 mining UTXOs.

Root Cause

The consolidation logic calculates a target amount:

CAmount consolidationTarget = result.collateralRequired +
    (result.collateralRequired / 10) + 10000000; // collateral + 10% + 0.1 DGB

When the wallet's total balance barely exceeds the collateral requirement, the 10% margin pushes the target above the available balance:

Collateral needed:  250,309 DGB
+ 10% margin:        25,030 DGB
+ 0.1 DGB buffer:         0.1 DGB
= Target:           275,339 DGB
Available balance:  274,686 DGB  ← LESS than target!

Result: "Insufficient funds for collateral. Need 250309.79 DGB, have 274686.74 DGB across 499 small UTXOs." — the wallet clearly has enough DGB, but the margin math rejects it.

Reproduction

On testnet19 (RC25), oracle wallet with 499 UTXOs:

$ digibyte-cli -rpcwallet=utxo-frag-test mintdigidollar 10000 0

error code: -6
error message:
Insufficient funds for collateral. Need 250309.79 DGB, have 274686.74 DGB across 499 small UTXOs.

The wallet has 274K DGB across 499 UTXOs. The top 400 UTXOs (the MAX_TX_INPUTS limit) sum to only 225K DGB — below the 250K collateral requirement. So SelectCoins correctly identifies this as a fragmentation issue and triggers the consolidation path. But the consolidation rejects because 275K target > 274K available.

Fix

Replace the fixed-margin target calculation with a sweep-to-self approach using subtractfeefromamount:

1. Minimum check: Only verify that total balance > collateral + 0.2 DGB (the actual minimum needed)
2. Consolidation: Send entire balance to self with subtractfeefromamount=true — the wallet's standard coin selection handles fee calculation, and the sweep always succeeds regardless of margin
3. Retry: Re-gather UTXOs (now a single large output) and retry BuildMintTransaction

This approach:

• Never fails due to margin math
• Produces one clean UTXO for the retry (optimal for the mint builder)
• Uses the wallet's battle-tested CreateTransaction for fee calculation

Tested

Built from source and tested on testnet19:

$ digibyte-cli -rpcwallet=utxo-frag-test mintdigidollar 10000 0

{
  "txid": "dfa98af4...",
  "dd_minted": 10000,
  "dgb_collateral": 250682.55150161,
  "lock_tier": 0,
  "unlock_height": 139025,
  "collateral_ratio": 150,
  "fee_paid": 0.11830000,
  "position_id": "dfa98af4...",
  "consolidation_txid": "a5bf0373...",
  "utxos_consolidated": true
}

Same wallet, same UTXOs that failed on RC25 — now auto-consolidates and mints successfully.

Test Methodology

1. Sent 450 × 500 DGB to utxo-frag-test wallet (creating 499 UTXOs, 274K total)
2. Verified top 400 UTXOs sum to 225K (below 250K collateral requirement)
3. Confirmed RC25 binary fails with "Insufficient funds" error
4. Built patched binary from this branch
5. Confirmed patched binary auto-consolidates and mints successfully
6. Restored RC25 binary, verified oracle still running

Files Changed

• src/rpc/digidollar.cpp — consolidation block in mintdigidollar handler

Test plan

• Reproduce failure on RC25 with >400 fragmented UTXOs
• Verify patched binary auto-consolidates and mints successfully
• Verify consolidation_txid and utxos_consolidated appear in response
• Verify oracle continues running after swap back to RC25
• Test edge case: wallet with barely enough balance (collateral + 0.3 DGB)
• Test edge case: wallet with exactly 400 UTXOs (boundary condition)

🤖 Generated with Claude Code

[DigiSwarm]

Thanks @JohnnyLawDGB — solid fix, well-documented PR. 👏

Full code audit completed. Traced every code path this touches:

✅ fSubtractFeeFromAmount is fully wired in CreateTransaction (spend.cpp L1019, L1222) — fee subtraction works correctly
✅ Coin selection will sweep all UTXOs — with SFFO active, BnB is skipped (L720), Knapsack hits the nTotalLower == nTargetValue fast path and selects everything
✅ Weight is safe — 499 P2WPKH inputs = ~114K WU, well under 400K MAX_STANDARD_TX_WEIGHT
✅ 0.2 DGB buffer is conservative — worst-case fee at 100 sat/vB is only 0.034 DGB (6x margin)
✅ No race condition — CommitTransaction is synchronous within cs_wallet, UTXO re-gather sees the new output immediately
✅ DD outputs properly filtered — AvailableCoins skips collateral/DD/OP_RETURN outputs in both the RPC gather and wallet's internal gather

Built from source and ran full test suite on the PR branch:

• 2011/2011 C++ unit tests pass ✅
• 18/18 DigiDollar functional tests pass ✅

The sweep approach is cleaner and more robust than the margin math. Good catch on the real-world failure with @AussieEpic's 499-UTXO wallet.

Minor note: The error message lost the UTXO count that was in the old message — not a blocker, just slightly less diagnostic info.

LGTM — merging. 🚀