wallet: Add separate balance info for non-mempool wallet txs #33671

ajtowns commented at 4:59 PM on October 21, 2025: contributor

Changes getbalances to report the sum of txos spent by transactions that aren't confirmed nor in the mempool (eg due to being part of too long a mempool chain, or spending non-standard outputs, or having a datacarrier output that exceeds -datacarriersize, etc). Those values are added to the trusted/untrusted_pending/immature/used fields as appropriate (where previously they were skipped), and subtracted from the new nonmempool field, so that the sum of all fields remains the same.

For example:

$ bitcoin-cli -regtest getbalances
{
  "mine": {
    "trusted": 6049.99999220,
    "untrusted_pending": 0.00000000,
    "immature": 3200.00000780,
    "nonmempool": -100.00000000
  },
  "lastprocessedblock": {
    "hash": "3ab4582226d5e8ad76438db48d76e822c31bce2cdbc7ba82a5d974a277515d0d",
    "height": 221
  }
}

Closes #11887

DrahtBot commented at 4:59 PM on October 21, 2025: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33671.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	w0xlt, musaHaruna, achow101
Concept ACK	vasild, RandyMcMillan

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#bitcoin-core/gui/911 (Adds non-mempool wallet balance to overview by ajtowns)
#34917 (wallet: mark bip125-replaceable deprecated, remove walletrbf argument by rkrux)
#34544 (wallet: Disallow wallet names that are paths including .. and . elements by achow101)
#33392 (wallet, rpc: add UTXO set check and incremental rescan to importdescriptors by musaHaruna)
#27865 (wallet: Track no-longer-spendable TXOs separately by achow101)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

ajtowns commented at 5:03 PM on October 21, 2025: contributor

Relevant for #29415 -- private relay of our wallet transactions would create spends that weren't in the mempool and would thus disappear mysteriously from the wallet balance which seems unacceptable. I think I've seen similar behaviour when doing lots of consolidations of my signet wallet, which has also been disturbing.

Perhaps see #11020 for a similar previous attempt.

~~This PR currently doesn't include tests that this works sensibly for nonzero nonmempool balances, hence wip/draft.~~

glozow added the label Wallet on Oct 22, 2025

ajtowns force-pushed on Oct 22, 2025

vasild commented at 10:31 AM on November 4, 2025: contributor

Concept ACK

This extends the getbalances RPC. Would be good to also update the GUI (not necessary in this PR).

The new type of transactions would have somehow to be fed to the wallet so that they would be returned by wallet.GetTXOs(), called by GetBalance(). How would that be done?

RandyMcMillan commented at 1:18 PM on November 10, 2025: contributor

Concept ACK

ajtowns force-pushed on Nov 19, 2025

ajtowns commented at 1:21 AM on November 19, 2025: contributor

This extends the getbalances RPC. Would be good to also update the GUI (not necessary in this PR).

Okay, I have a patch for that opened as draft at bitcoin-core/gui#911

The new type of transactions would have somehow to be fed to the wallet so that they would be returned by wallet.GetTXOs(), called by GetBalance(). How would that be done?

I don't think there's a way to do this for arbitrary txs that originate outside of the wallet, even if they involve a wallet address. Maybe there should be? (ie, an RPC that lets you pass raw tx to AddToWalletIfInvolvingMe ?)

But for txs that are created by the wallet, eg send or sendall rpc, then I believe they'll be added to the wallet via CommitTransaction which will also invoke SubmitTxMemoryPoolAndRelay() which in turn invokes broadcastTransaction.

You can create non-mempool txs by limiting -datacarriersize on startup, then using bitcoin-cli send to create a tx with a {"data":"deadbeef..."} output that exceeds the datacarriersize you set. Those will not be rejected by the rpc, and will enter the wallet as described above, but not enter the mempool. If you restart with a sufficiently larger datacarriersize, the tx will enter the mempool (and be trusted, since it's from you, to you).

I've added a test to wallet_send.py that exercises this behaviour.

ajtowns marked this as ready for review on Nov 19, 2025

ajtowns renamed this:
~~[wip] wallet: Add separate balance info for non-mempool wallet txs~~
wallet: Add separate balance info for non-mempool wallet txs
on Nov 19, 2025

achow101 commented at 10:20 PM on November 19, 2025: member

Concept NACK-ish

There's a lot of reasons that an unconfirmed transaction might be in the wallet but not the mempool, and I think giving an accurate balance of those transactions will be hard to get right. We absolutely do not want to mislead users into thinking they have more coins than they actually do, so I am hesitant to add something like this.

From a cursory glance at the code, I think 2 transactions that conflict with each other but aren't in the mempool would both get counted towards the nonmempool balance, and which I think is incorrect. But in that case, which one should be counted, if at all?

ajtowns commented at 12:56 AM on November 20, 2025: contributor

Concept NACK-ish

There's a lot of reasons that an unconfirmed transaction might be in the wallet but not the mempool, and I think giving an accurate balance of those transactions will be hard to get right. We absolutely do not want to mislead users into thinking they have more coins than they actually do, so I am hesitant to add something like this.

We currently mislead users into thinking they have less coins than they actually do (due to transactions in the wallet with long mempool chains, eg), which is very scary, and (IMO) very bad from an accounting POV. So I don't think the current state is acceptable either.

The underlying problem (IMO) is that the accounting is unbalanced: if we see two transactions (A,B) in the wallet, where B spends A (via IsSpent()) but B is not in the mempool, then because B spends A we will ignore our funds from A (believing it's spent by B) but we will also ignore our funds from B (believing it's not a real tx). There's two ways to fix that: we could not ignore the funds that are still in A, or we could not ignore the funds that are in B. Currently this PR tries not ignoring the funds in B.

From a cursory glance at the code, I think 2 transactions that conflict with each other but aren't in the mempool would both get counted towards the nonmempool balance, and which I think is incorrect. But in that case, which one should be counted, if at all?

That's accurate:

$ bitcoin-cli -regtest -named send outputs='{"bcrt1qperny2w6xvfkjvec44w4qtwwk3ykuw9py0ejrp": 1.0, "data": "54686520717569636b2062726f776e20666f78206a756d7073206f76657220746865206c617a7920646f67"}' fee_rate=1 inputs='[{"txid":"a6e88286d165dbe4f4aab7830f7b68931ef7f5b66d32f0ea573d906594ad6a0c","vout":0}]'
{
  "txid": "42ef1c7d7c2afee4bb2519fbfcf284ef40ae156ea193ce86a1fa670183a12322",
  "complete": true
}
$ bitcoin-cli -regtest -named send outputs='{"bcrt1qperny2w6xvfkjvec44w4qtwwk3ykuw9py0ejrp": 2.0, "data": "54686520717569636b2062726f776e20666f78206a756d7073206f76657220746865206c617a7920646f67"}' fee_rate=2 inputs='[{"txid":"a6e88286d165dbe4f4aab7830f7b68931ef7f5b66d32f0ea573d906594ad6a0c","vout":0}]'
{
  "txid": "ebbd3bf4807d8e5683d124cd726de982a4f36e2bae264ff5b91545dae41bacbe",
  "complete": true
}
$ bitcoin-cli -regtest getbalances
{
  "mine": {
    "trusted": 450.00000000,
    "untrusted_pending": 0.00000000,
    "immature": 5000.00000000,
    "nonmempool": 99.99999415
  },
  "lastprocessedblock": {
    "hash": "33e1b4932fb3a464aef972470ffed7650795a35f26214cfa58f76a787d548768",
    "height": 110
  }
}

ie spending a single 50 rBTC output twice suddenly gets reported as ~100 rBTC ex fees.

I don't think there's an easy way to avoid that with the "don't ignore B's funds" approach: if you have confirmed utxos A (1 BTC), B (2 BTC), C (3 BTC), you could have non-mempool txs D spending A,B (3 BTC out, 2.9 BTC change) and E spending A,C (4 BTC 3.8 BTC change). You subtract 6 BTC from your balance because each of A,B,C have non-abandoned, non-block/mempool-conflicted spends in the wallet, but if D were to confirm you should add 5.9 BTC (D+C), if E were to confirm you should add 5.8 BTC (E+B), and if you pretended both were to confirm you'd add 6.7 BTC (D+E).

The other approach, then, is to say "D and E aren't in the mempool, so A B and C aren't -really- spent", and not remove the 6 BTC from A,B,C from your balance; though IMO it still makes sense to separate those out into "possibly-spent-by-nonmempool-txs". I believe that easily avoids the double counting if you have conflicting possible spends.

With that approach, if I spend an immature coinbase, that changes my balances from:

$ bitcoin-cli -regtest getbalances
{
  "mine": {
    "trusted": 450.00000000,
    "untrusted_pending": 0.00000000,
    "immature": 5000.00000000,
    "nonmempool": 50.00000000
  },
  "lastprocessedblock": {
    "hash": "33e1b4932fb3a464aef972470ffed7650795a35f26214cfa58f76a787d548768",
    "height": 110
  }
}
$ bitcoin-cli -regtest getbalances
{
  "mine": {
    "trusted": 450.00000000,
    "untrusted_pending": 0.00000000,
    "immature": 4950.00000000,
    "nonmempool": 100.00000000
  },
  "lastprocessedblock": {
    "hash": "33e1b4932fb3a464aef972470ffed7650795a35f26214cfa58f76a787d548768",
    "height": 110
  }
}

Double spending the same tx at that point doesn't change the result. If I do the "A,B,C" (50 rBTC each) spent by conflicting "D,E", I get:

$ bitcoin-cli -regtest getbalances
{
  "mine": {
    "trusted": 5949.99999220,
    "untrusted_pending": 0.00000000,
    "immature": 3200.00000780,
    "nonmempool": 100.00000000
  },
  "lastprocessedblock": {
    "hash": "3ab4582226d5e8ad76438db48d76e822c31bce2cdbc7ba82a5d974a277515d0d",
    "height": 221
  }
}
...
$ bitcoin-cli -regtest getbalances
{
  "mine": {
    "trusted": 5899.99999220,
    "untrusted_pending": 0.00000000,
    "immature": 3200.00000780,
    "nonmempool": 150.00000000
  },
  "lastprocessedblock": {
    "hash": "3ab4582226d5e8ad76438db48d76e822c31bce2cdbc7ba82a5d974a277515d0d",
    "height": 221
  }
}

That approach is still "misleading" in the sense that those nonmempool txs are reported as how much money you're spending, rather than how much you're potentially keeping as change if those spends go through.

Another approach would be to report it as:

trusted: 6049.99
untrusted_pending: 0
immature: 3200
nonmempool-pending: -150

ie "your balance is this, but you have X funds that are currently not in your mempool that you might lose some/all of"

Could also perhaps do it more fine-grained as:

trusted: 6049.99 [-100 non-mempool spends]
untrusted_pending: 0
immature: 3200 [-50 non-mempool spends]

[EDIT: You could perhaps also account for locked coins similarly to non-mempool spends, which might be logical if you're locking coins because you're spending them elsewhere in ways you don't expect will make it to your mempool]

Happy to switch to one of those approaches, or something else, if that seems more acceptable.

achow101 commented at 8:40 PM on November 21, 2025: member

Another approach would be to report it as:
trusted: 6049.99
untrusted_pending: 0
immature: 3200
nonmempool-pending: -150
ie "your balance is this, but you have X funds that are currently not in your mempool that you might lose some/all of"

I would prefer this approach and docs just need to be clear that some of that amount may come back as change.

wallet: Have GetBalance report used amount directly without two calls 81e763f1e5

ajtowns force-pushed on Nov 27, 2025

ajtowns commented at 5:46 AM on November 27, 2025: contributor

Okay, so when a "transfer to self" tx paying 1310 sats in fees from 100 BTC of inputs doesn't hit the mempool, it currently looks like:

{
  "mine": {
    "trusted": 5949.99999220,
    "untrusted_pending": 0.00000000,
    "immature": 3200.00000780
  }
}

vs when the tx does hit the mempool:

{
  "mine": {
    "trusted": 6049.99997910,
    "untrusted_pending": 0.00000000,
    "immature": 3200.00000780
  }
}

That is, there's 99.9999869 BTC missing from your balance while the transaction is in the wallet but not in the mempool.

With the current version of this PR, it now looks like this when the tx is not in the mempool:

{
  "mine": {
    "trusted": 6049.99999220,
    "untrusted_pending": 0.00000000,
    "immature": 3200.00000780,
    "nonmempool": -100.00000000
  }
}

So if you add those figures up, you're still 100 BTC down, but at least you have a clue as to what's going on.

When it does hit the mempool (or gets mined), it becomes:

{
  "mine": {
    "trusted": 6049.99997910,
    "untrusted_pending": 0.00000000,
    "immature": 3200.00000780,
    "nonmempool": 0.00000000
  }
}

which is the same as previously (with the addtion of nonmempool=0).

I also refactored it to calculate the "used" value directly (ie funds held in coins with addresses that are already spent from, for wallets that care about that), since I couldn't figure out how to get the nonmempool figure correct otherwise, but I think that's an improvement anyway.

I believe there was a "bug" in the cleanup decorator for wallet_v3_txs in that coins in a wallet spent by non-mempool wallet txs wouldn't be cleared out by the sendall calls. That wasn't showing up in the balance checks previously, but does show up when the nonmempool figures are also reported. Addressed that by abandoning any unconfirmed wallet txs prior to calling sendall.

ajtowns force-pushed on Nov 27, 2025

DrahtBot added the label CI failed on Nov 27, 2025

DrahtBot commented at 7:28 AM on November 27, 2025: contributor

🚧 At least one of the CI tasks failed. <sub>Task test each commit: https://github.com/bitcoin/bitcoin/actions/runs/19727553059/job/56521733216</sub> <sub>LLM reason (✨ experimental): Git rebase failed due to uncommitted changes in the index.</sub>

<details><summary>Hints</summary>

Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:

Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.
A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.
An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

</details>

ajtowns force-pushed on Nov 27, 2025

DrahtBot removed the label CI failed on Nov 27, 2025

in src/wallet/receive.cpp:271 in 81e763f1e5 outdated

 272 | -                    ret.m_mine_untrusted_pending += credit_mine;
 273 | +                    bucket = &ret.m_mine_untrusted_pending;
 274 | +                }
 275 | +                if (bucket) {
 276 | +                    // Get the amounts for mine
 277 | +                    CAmount credit_mine = txo.GetTxOut().nValue;

achow101 commented at 11:18 PM on December 23, 2025:

In 81e763f1e5d878383487b5e4e695b3dca703e1d6 "wallet: Have GetBalance report used amount directly without two calls"

This could be brought inline with *bucket += credit_mine; below as credit_mine is only ever used there.

ajtowns commented at 12:32 PM on January 7, 2026:

The value is used twice, once for *bucket += and once for ...nonmempool -= ? EDIT: ah, I guess that only happens in the following commit. Seems fine to leave though?

in src/wallet/receive.cpp:265 in 183921910d outdated

 261 | +            case CWallet::SpendType::CONFIRMED:
 262 | +            case CWallet::SpendType::MEMPOOL:
 263 | +                // treat as spent; ignore
 264 | +                break;
 265 | +            case CWallet::SpendType::NONMEMPOOL:
 266 | +                if (!include_nonmempool || !allow_used_addresses) break;

achow101 commented at 11:46 PM on December 23, 2025:

In 183921910ddb6424805a05cca6f4e56f94b9c0b1 "wallet: Add separate balance info for non-mempool wallet txs"

It's unclear to me why these txos should be skipped when used addresses are allowed.

ajtowns commented at 12:58 PM on January 7, 2026:

Removed that case.

ajtowns force-pushed on Jan 7, 2026

DrahtBot added the label CI failed on Jan 7, 2026

DrahtBot removed the label CI failed on Jan 7, 2026

in src/wallet/wallet.cpp:756 in 57c9d93882 outdated

 751 | +        if (mit != mapWallet.end()) {
 752 | +            const auto& wtx = mit->second;
 753 | +            if (wtx.isConfirmed()) return SpendType::CONFIRMED;
 754 | +            if (wtx.InMempool()) {
 755 | +                st = SpendType::MEMPOOL;
 756 | +            } else if (!wtx.isAbandoned() && !wtx.isBlockConflicted() && !wtx.isMempoolConflicted()) {

achow101 commented at 7:11 PM on February 5, 2026:

In 57c9d938824e833fea4f2c2f58ba2800444c23cb "wallet: Add separate balance info for non-mempool wallet txs"

This could be simplified:

            } else if (wtx.isInactive() && !wtx.isAbandoned()) {

ajtowns commented at 10:26 PM on February 5, 2026:

I think you still want the && !isMempoolConflicted() check though? If it's changed, the matching code in IsSpent() should change too. Not sure if there's any reason why this shouldn't be wtx.isUnconfirmed() now that I look.

achow101 commented at 7:21 PM on February 5, 2026: member

ACK f77bf4cf1a510a9b1b50dcbc6d045e28876220fa

DrahtBot requested review from vasild on Feb 5, 2026

whitslack commented at 4:47 AM on February 20, 2026: contributor

I got freaked out just now because I appeared to be missing a rather large chunk of coin and I couldn't find it anywhere. The spending transaction does not appear in listtransactions, and the new unconfirmed outputs do not appear in listunspent (even when called with minconf=0). The unconfirmed transaction here is a spend-to-self consolidation of several outputs. It paid the minimum standard fee-rate (0.1 sat/vB), and at some point it got evicted from my node's mempool due to memory pressure.

I can find no means via RPC to discover that these coins are in flight except that I can call gettransaction, passing the TxID, to see that the transaction is still unconfirmed. If I didn't already know the TxID, I would have no way of finding it via RPC.

Why in the world does the wallet not keep its own internal record of all transactions that involve any of its addresses? It is simply unconscionable that the wallet appears to "forget" about an unconfirmed transaction simply because the transaction gets evicted from the node's mempool. The only time a wallet may ever safely discard knowledge of an unconfirmed transaction is if it knows that the transaction has been invalidated (typically because one or more of its inputs has been spent in some other transaction that has reached sufficient depth in the blockchain).

If the wallet is going to act like the spend-to-self transaction never happened, then it also needs to act as though the previous outputs were never spent. Alternatively, if it's going to treat the previous outputs as spent, then it needs to treat the newly created outputs as unconfirmed, even if the transaction is no longer in the mempool. The wallet should expunge the transaction only if/when the transaction has been invalidated by some other sufficiently deeply confirmed transaction. (The wallet does already watch for conflicting transactions, right?)

achow101 commented at 6:16 AM on February 20, 2026: member

The spending transaction does not appear in listtransactions

It should, but you may need to set a higher count parameter.

If I didn't already know the TxID, I would have no way of finding it via RPC.

You should be able to get it with listtransactions

Why in the world does the wallet not keep its own internal record of all transactions that involve any of its addresses?

It does, that's what gettransaction is looking against. The node has already evicted the transaction; the only place in Bitcoin Core that would know about evicted transactions is from wallets.

The only time a wallet may ever safely discard knowledge of an unconfirmed transaction

To be clear, the wallet never deletes a transaction unless the user has explicitly called removeprunedfunds.

whitslack commented at 7:56 AM on February 20, 2026: contributor

@achow101: Thank you for responding. I'm replying below.

The spending transaction does not appear in listtransactions

It should, but you may need to set a higher count parameter.

Nope. listtransactions returns the three previous transactions that each created one output to my address, but it does not show the still-unconfirmed transaction that spends those three outputs.

To be clear: I created the spending transaction manually using bitcoin-tx -create, deducted a suitable fee from it using fundrawtransaction with {"add_inputs": false, "subtractFeeFromOutputs": [0], "fee_rate": 0.1}, signed it using signrawtransactionwithwallet, and broadcast it with sendrawtransaction.

I don't know if this is relevant, but when I called sendrawtransaction, I did not specify the wallet to bitcoin-cli with any -rpcwallet= argument; I just let the RPC go to the default endpoint, assuming that broadcasting a raw transaction is not an operation that requires specifying a wallet.

To be clear, the wallet never deletes a transaction unless the user has explicitly called removeprunedfunds.

That's great. So, how do I query the wallet for a list of the transactions that it knows about but that it's not including in listunspent, listtransactions, or getbalances?

achow101 commented at 7:58 AM on February 20, 2026: member

Nope. listtransactions returns the three previous transactions that each created one output to my address, but it does not show the still-unconfirmed transaction that spends those three outputs.

Please open a separate issue for that as it is unrelated to this PR.

in src/wallet/wallet.cpp:724 in f77bf4cf1a

w0xlt commented at 6:34 PM on March 11, 2026:

The function CWallet::IsSpent can now be simplified:

 bool CWallet::IsSpent(const COutPoint& outpoint) const
 {
-    std::pair<TxSpends::const_iterator, TxSpends::const_iterator> range;
-    range = mapTxSpends.equal_range(outpoint);
-
-    for (TxSpends::const_iterator it = range.first; it != range.second; ++it) {
-        const Txid& txid = it->second;
-        const auto mit = mapWallet.find(txid);
-        if (mit != mapWallet.end()) {
-            const auto& wtx = mit->second;
-            if (!wtx.isAbandoned() && !wtx.isBlockConflicted() && !wtx.isMempoolConflicted())
-                return true; // Spent
-        }
-    }
-    return false;
+    return HowSpent(outpoint) != SpendType::UNSPENT;
 }

in src/wallet/wallet.cpp:750 in f77bf4cf1a outdated

 745 | +    std::pair<TxSpends::const_iterator, TxSpends::const_iterator> range;
 746 | +    range = mapTxSpends.equal_range(outpoint);
 747 | +
 748 | +    for (TxSpends::const_iterator it = range.first; it != range.second; ++it) {
 749 | +        const Txid& txid = it->second;
 750 | +        const auto mit = mapWallet.find(txid);

w0xlt commented at 6:34 PM on March 11, 2026:

This can be simplified as well.

    const auto range = mapTxSpends.equal_range(outpoint);
    for (auto it = range.first; it != range.second; ++it) {
        const auto mit = mapWallet.find(it->second);

wallet: Add separate balance info for non-mempool wallet txs 25e063d950

tests: Add test for mempool-invalid wallet tx

Uses send rpc to create a tx with oversized OP_RETURN output, verifies
that it doesn't enter the mempool, and that getbalance rpc returns a
nonmempool value.

32325d1777

in src/wallet/rpc/coins.cpp:416 in f77bf4cf1a

 412 | @@ -412,6 +413,7 @@ RPCHelpMan getbalances()
 413 |                      {RPCResult::Type::STR_AMOUNT, "trusted", "trusted balance (outputs created by the wallet or confirmed outputs)"},
 414 |                      {RPCResult::Type::STR_AMOUNT, "untrusted_pending", "untrusted pending balance (outputs created by others that are in the mempool)"},
 415 |                      {RPCResult::Type::STR_AMOUNT, "immature", "balance from immature coinbase outputs"},
 416 | +                    {RPCResult::Type::STR_AMOUNT, "nonmempool", "sum of coins that are locked or spent by transactions not in the mempool (usually an over-estimate due to not accounting for change or spends that conflict with each other)"},

w0xlt commented at 6:39 PM on March 11, 2026:

Does this field take locked coins into account ?

ajtowns commented at 7:44 PM on March 11, 2026:

Err, no. (It was an idea, not sure it was ever implemented even as a draft though)

ajtowns force-pushed on Mar 11, 2026

ajtowns commented at 8:16 PM on March 11, 2026: contributor

Bumped to remove the stuff about locked coins. Planning on leaving any simplifications for followups; lmk if that's not the right choice.

w0xlt commented at 8:18 PM on March 11, 2026: contributor

lgtm ACK 32325d17777fcb58f36842fc8e679fbedf6b2b02

DrahtBot requested review from achow101 on Mar 11, 2026

musaHaruna commented at 12:15 PM on April 16, 2026: contributor

Code Review ACK 32325d1

Extends the getbalances RPC to account for transactions that are neither in the mempool nor confirmed in a block, by introducing a new nonmempool field.

The GetBalance() function works by scanning every UTXO in the wallet and classifying each one into balance buckets based on its state. These buckets represent whether the coin is confirmed (trusted), unconfirmed but present in the mempool (untrusted_pending), or still immature (coinbase outputs). Each UTXO is evaluated independently using its confirmation depth, trust status, and spending status to determine the appropriate category.

The key addition is support for UTXOs that are spent by transactions known to the wallet but neither confirmed nor present in the mempool. These are classified as NONMEMPOOL by HowSpent(). In this case, the UTXO is still included in the normal balance classification, but its value is also subtracted from a special adjustment field, m_mine_nonmempool. This adjustment ensures that, even in these edge cases where wallet state and mempool/blockchain state diverge, the total sum across all balance fields remains consistent and does not overstate available funds.

Not sure whether the getbalances RPC would benefit from additional release notes explaining the new nonmempool field.

Bumped to remove the parts about locked coins. I plan to leave any further simplifications for follow-ups—let me know if that’s not the right approach.

I’m happy to add those simplifications in a follow-up once this PR is merged.

achow101 commented at 10:47 PM on April 22, 2026: member

ACK 32325d17777fcb58f36842fc8e679fbedf6b2b02

achow101 merged this on Apr 22, 2026

achow101 closed this on Apr 22, 2026