Interface WalletBalance

Asset balance entries (assetId & amount) the wallet owns.

Immediately spendable offchain balance — what generic selection would pick, so nothing counted here can be refused by send: settled + preconfirmed - gated - intentLocked. A dust carrier is reserved if any assets are held on outputs comprising this balance.

The subset of assets generic spending will accept, i.e. the asset analogue of available. assets - availableAssets is what is held but not selectable, for the gated and intentLocked causes plus recovery and unrolled — assets have no per-cause split of their own.

Boarding funds

Spendable-but-for-the-gate funds: VTXOs under a contract the generic-spending gate refuses — a VHTLC lockup, an unmarked arkade program, or a type whose handler this runtime never registered. Counted in settled/preconfirmed and total, never in available.

Tested before intentLocked: the gate is a durable property of the contract while an intent lock clears on its own, so a VTXO that is both is reported here — it does not become available when the batch settles.

Covers this bucket only: recoverable has the same owned-versus- obtainable split under a different predicate and is not counted here.

Subtract this from settled + preconfirmed, never from total. total also carries boarding, recoverable, pendingRecovery and unrolled, which are still the user's funds — netting a bucket out of it drops them from the figure with no signal.

Funds committed to an in-flight (non-terminal) intent, and not already counted in gated. Unlike gated, these return to available when the intent reaches a terminal state.

Reported as zero where the wallet cannot answer the question — no intent repository, or a repository read that fails — so this under-reports into available rather than misattributing.

Funds under a now-deprecated signer past its cutoff (EXPIRED) that have not yet been swept by the server. NOT spendable until they recover, so excluded from available/settled/preconfirmed and from coin selection — but still the wallet's funds, so counted in total.

Preconfirmed (unfinalized) balance the wallet owns, on the same owned rule as settled.

Recoverable balance from subdust or expired (swept) virtual outputs — recoverable in principle, so a lockup whose contract refuses a spend right now is still counted and total does not lose it. VtxoManager.getRecoverableBalance() answers the narrower question of what a batch would hand back today, and excludes it.

Settled (finalized) balance the wallet owns, including gated and intent-locked funds.

Total balance across offchain, recoverable, pending-recovery, unrolled, and boarding funds.

One known main-thread-only wedge: while a spend is in flight — send, sendBitcoin or settle — its VTXO inputs are withheld from every bucket, including this one. Boarding inputs are not: only virtual coins enter the set. That state lives on the Wallet instance driving the spend, so a service-worker client reading the same repository still counts them until the spend settles. Both sides converge when it does.

Funds whose unilateral exit already happened — the output is onchain behind its CSV timelock, so Unroll.completeUnroll is the only thing that moves it. Excluded from available/settled/preconfirmed, from recoverable (no batch can lift an onchain output), and from coin selection — but still the wallet's funds, so counted in total.