AddressFundsTransferTransition::calculate_min_required_fee is too low

[lklimek]

AddressFundsTransferTransition::calculate_min_required_fee is lower than the one that is actually expected by Drive.

Similar issue also exists for other state transitions, like IdentityTopUpFromAddressesTransition.

Expected Behavior

1. Create an AddressFundsTransferTransition with 3 inputs and 1 output.
2. Calculate fee using AddressFundsTransferTransition::calculate_min_required_fee() ensure that fee is available for payment.
3. Send state transition to DAPI.
4. State transition is executed.

Current Behavior

calculate_min_required_fee returns 0.00007500 DASH; the state transition is rejected with error:

Failed to transfer Platform credits: Protocol error: Insufficient combined address balances: total available is less than required 27122100

Drive logs

2026-02-02T16:15:42.006310Z TRACE tokio-runtime-worker ThreadId(120) drive_abci::execution::validation::state_transition::processor::traits::address_balances_and_nonces: Validating input address balances and nonces for state transition inputs={P2pkh([121, 18, 146, 107, 95, 198, 174, 237, 166, 39, 140, 185, 89, 132, 65, 21, 101, 200, 26, 206]): (5, 39985738700), P2pkh([176, 192, 12, 8, 140, 32, 167, 200, 129, 107, 155, 112, 53, 134, 190, 167, 128, 135, 186, 138]): (5, 29993262200), P2pkh([205, 108, 183, 206, 205, 136, 189, 238, 114, 94, 230, 34, 164, 28, 16, 118, 183, 219, 201, 18]): (5, 20293831300)}
2026-02-02T16:15:42.007230Z TRACE tokio-runtime-worker ThreadId(120) drive_abci::abci::handler::check_tx: AddressFundsTransfer state transition (e073919332609e01aea0474a8eaa04b2e7f46494c110cf67ceb065fe65a8c17d) rejected with code 40602 due to error: Insufficient combined address balances: total available is less than required 27122100 check_tx_result=CheckTxResult { level: FirstTimeCheck, fee_result: Some(FeeResult { storage_fee: 23814000, processing_fee: 3308100, fee_refunds: FeeRefunds({}), removed_bytes_from_system: 0 }), unique_identifiers: ["sHkSkmtfxq7tpieMuVmEQRVlyBrOAAAABQ==", "sLDADAiMIKfIgWubcDWGvqeAh7qKAAAABQ==", "sM1st87NiL3ucl7mIqQcEHa328kSAAAABQ=="], priority: 0, state_transition_name: Some("AddressFundsTransfer"), state_transition_hash: Some([224, 115, 145, 147, 50, 96, 158, 1, 174, 160, 71, 74, 142, 170, 4, 178, 231, 244, 100, 148, 193, 16, 207, 103, 206, 176, 101, 254, 101, 168, 193, 125]) } error=Some(StateError(AddressesNotEnoughFundsError(AddressesNotEnoughFundsError { addresses_with_info: {P2pkh([121, 18, 146, 107, 95, 198, 174, 237, 166, 39, 140, 185, 89, 132, 65, 21, 101, 200, 26, 206]): (5, 7500000), P2pkh([176, 192, 12, 8, 140, 32, 167, 200, 129, 107, 155, 112, 53, 134, 190, 167, 128, 135, 186, 138]): (5, 0), P2pkh([205, 108, 183, 206, 205, 136, 189, 238, 114, 94, 230, 34, 164, 28, 16, 118, 183, 219, 201, 18]): (5, 140)}, required_balance: 27122100 }))) st_hash="e073919332609e01aea0474a8eaa04b2e7f46494c110cf67ceb065fe65a8c17d" 

So, Drive logs demand 23814000 + 3308100 = 27 122 100 , while AddressFundsTransferTransitionV0::calculate_min_required_fee returns 7 500 000 .

Possible Solution

Wee need to fix the algorithm.

Context

Tried to fix fee calculations in Dash Evo Tool.

Your Environment

• Version used: platform commit 07f7eb6, dash evo tool branch fix/not-enough-balance-for-fee
• Operating System and version (desktop, server, or mobile): Ubuntu 24
• Link to your project: fix: not enough balance to pay a fee in platform to core transfers dash-evo-tool#513

[Claudius-Maginificent]

Hit again in the wild. Surfaced empirically in PR #3549's e2e harness while validating PR #3554's [ReduceOutput(0)] auto-select path.

Reproducer (1in/1out, [ReduceOutput(0)])

• AddressFundsTransferTransition::estimate_min_fee ≈ 6_500_000
• Drive chain-time total_base_fee() = storage_fee + processing_fee ≈ 14_939_900
• Auto-select greenlights selection with output[0] = 10_000_000 (passes Phase 4: 10M ≥ 6.5M).
• Broadcast then fails:

  AddressesNotEnoughFundsError {
    addresses_with_info: { addr_1: (nonce=1, balance=30_600_900) },
    required_balance: 14_939_900
  }
  

• Path: validate_fees_of_event::v0::PaidFromAddressInputs arm → deduct_fee_from_outputs_or_remaining_balance_of_inputs → output[0] absorbs 10M of the 14.94M, the remaining 4.94M can't be drawn from anywhere because the strategy is [ReduceOutput(0)] only.

Same shape as the original report (3in/1out, 7.5M static vs 27.1M chain-time, +19.6M gap), just smaller.

Workarounds applied today

• PR fix(platform-wallet): auto_select_inputs honors Σ inputs == Σ outputs #3554: comment in select_inputs_reduce_output Phase 4 noting the limitation — small-output[0] callers should prefer [DeductFromInput(0)] or [ReduceOutput(0), DeductFromInput(0)] until this is fixed.
• PR test(platform-wallet): e2e framework + full test suite — triage pins, Found-*/PA-* guards, fail-closed persist, Stage-2 merge #3549: bumped e2e TRANSFER_CREDITS and FUNDING_CREDITS so output[0] clears the empirical chain-time ceiling with comfortable headroom — sidesteps the bug rather than fixing it.

Why we didn't add a wallet-side band-aid
DET tried (dashpay/dash-evo-tool#514) and closed as "blocked on #3040". A more conservative wallet estimate would just create two parallel bad estimates; the real fix is in dpp's calculate_min_required_fee algorithm. Suggest pairing this with #3041's API redesign so the new estimator can be queried by the wallet without constructing a signed transition.

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