The fee for a Bitcoin withdrawal depends on inputs you haven't chosen yet.
That sentence sounds like a paradox, and in coin selection it is a genuine loop. The fee is a function of transaction size. Size is a function of how many inputs you spend. And how many inputs you need to spend depends on the fee, because the fee comes out of the same funds.
The usual implementation pretends the loop isn't there. Select inputs to cover the amount, then bolt the fee on afterwards. Now the selected set no longer covers amount plus fee, so you pull in one more input, which makes the transaction larger, which raises the fee again. Or the code quietly resolves it by shrinking the change output until it drops below dust — and that change is not returned to the user, it's handed to miners.
When I built custodial BTC wallets, the fix was structural, not arithmetic: every candidate input set is evaluated with its own fee at the current rate, including the marginal cost of the change output, and selection only terminates when a set covers amount plus its own fee.
Fee estimation belongs inside the selection loop, never after it.
If you run on-chain payouts: does your selector price the change output, or discover it later?
https://polycratia.com/c/43729555