fix: a failed lookup is not a zero — builders, send form, swap dialog

[BitHighlander]

#414 swept for the #411 bug and stopped at the EVM builders. Three more sites live outside them. Two commits: the builders, then the layer above them — which turned out to contain a bypass of the first commit's own fix.

Commit 1 — the builders

utxo.ts — a dropped xpub silently shrinks the wallet

buildUtxoTx aggregates across accounts with Promise.allSettled and warns on a rejected ListUnspent ("Finding 5: tolerate individual xpub failures"). The tolerance is right; what follows it is not. utxos is then a strict subset, and three statements describe the whole balance anyway:

path	before	after
MAX	built a valid tx spending only the reachable accounts and called it a sweep — a wrong amount, signed, no error	refuses to build
shortfall	Insufficient funds: have 0.005, need 0.008 on a wallet holding 0.01	names the failed lookups, quotes no subtotal
all-fail	No confirmed UTXOs found ... may still be confirming — please wait	blames the server, which is what actually happened

The MAX case is the one that can lose money. estimateUtxoFee had the same partial set behind its fee/net quote; it already returns null on error, so a partial set returns null too.

cosmos.ts — the ?? '0' that #414 fixed for EVM

Three MAX reads used (balResp?.data?.balances || [])[0]?.balance ?? '0'. A missing balance became 0 - fee, clamped to 0, then "Amount must be greater than zero" — user hits MAX on a funded account and is told their amount is zero. Fails closed, wrong cause, server fault hidden. All three now go through readCosmosBalance(), mirroring readPioneerBalance(): throw when the field is absent, pass a real numeric 0 through as the verified empty account it is.

Checked and left alone: ton.ts's data.result.balance || '0' sits behind an ok check and the caller only reads .initialized.

Commit 2 — the send form, and the hole it opened

The bypass. buildCosmosTx's token MAX read params.tokenBalance ?? readCosmosBalance(...). ?? only falls through on null/undefined. SendForm passes tokenBalance: token.balance, and for a degraded chain that value is the string '0' — truthy, so it won, and commit 1's guard never ran. Defeated by the single input most likely to be wrong. buildEvmTx (evm.ts:299) and the Solana path (index.ts:196) both gate on parseFloat(...) > 0; cosmos now matches.

The claims. A degraded entry carries balance '0', and SendForm read it as a figure:

• The "Low BTC for Gas" banner gates on !(nativeBal > 0), so a chain Pioneer failed produced "You need ETH to pay network fees. Deposit ETH…" on an account holding plenty. The ponytail: note above that line was already fighting a different false positive on the same banner.
• The "Available" readout and the small balance row printed a confident 0, and the USD conversion multiplied it into a confident $0.00.

All three now render — with a tooltip. isBalanceUnverified() sits beside balanceDisplayState() so the 'degraded' rule stays in one module — the send form has no global load state, so it needs the predicate, not the three-state machine.

Deliberately unchanged: the form still lets the send proceed. The builder re-fetches and either succeeds or throws something specific, which is the right gate; blocking in the UI would strand a user whenever one chain was degraded.

Noted, not touched: SendForm sends nativeBalance in the buildTx payload and no builder reads it — params.nativeBalance has no consumer anywhere in src/bun. Dead field, pre-existing.

Commit 3 — the integration paths (post-audit)

An audit of the first two commits found two bypasses and one inconsistency. All three confirmed against the source before fixing.

1. BTC MAX bypassed the completeness guard from upstream. btc-accounts.ts filtered xpubs on parseFloat(xp.balance) > 0 — the cached balance — before the builder saw them. A cached zero is not proof of an empty account; it is also exactly what a degraded chain looks like. The degraded account was dropped, every surviving ListUnspent succeeded, unreachableXpubs stayed 0, and MAX swept a subset believing it had swept the wallet. Commit 1's guard never saw the account it exists to catch — the same shape as the Cosmos tokenBalance: '0' bypass, a layer further up.

getFundedXpubs → getSpendableXpubs, filter dropped, three call sites updated. The name asserted a property it could not establish. Cost is one ListUnspent per genuinely empty xpub, which returns []. Behaviour change worth knowing: an unfunded xpub whose lookup now errors will block MAX where it previously proceeded on a subset. That is the point, but it widens what can block a MAX.

2. isBalanceUnverified said a missing entry was verified. It returned false for undefined, so SendForm's balance?.balance || '0' printed a confident zero — contradicting balanceDisplayState, which never returns known without an entry. My own predicate disagreed with the state machine it was written to mirror. Reachable since #410: the chain list is always visible, so Send opens for a chain with no entry. A missing entry is now unverified; an entry with no syncState stays known, since blanking cached and legacy rows would wipe every balance on cold start.

3. SwapDialog kept the claims SendForm stopped making. fromBalance ignored syncState, so a degraded '0' drove the displayed amount, the USD conversion, the MAX arithmetic, and the low-gas warning — and sendAmount fell back to fromBalance || '0', so MAX on an unverifiable balance submitted a 0-amount swap. fromBalance and fromChainLowGas now yield null for a degraded from-chain, MAX resolves to empty, and the amount field carries a one-line explanation.

The confirmedAssetCaips exception is preserved, as the audit asked: isBalanceUnverified takes an optional assetCaip and honours confirmedAssetCaips, so an SPL token proven directly over RPC keeps its real figure while its parent chain is degraded — precisely what mergeTrustedBalanceSnapshot merges through. Comparison reuses normalizeAssetCaip, so EVM contracts match case-insensitively and base58 ids stay byte-exact.

Commit 4 — two selector bugs (re-audit)

1. Checked one source, read from another. fromBalanceUnverified examined only the internal balances array — the !!cb && guard I added to avoid destabilising the dialog created the hole it was meant to close. fromBalance then fell through to the balance prop, so a degraded prop cleared a check that never looked at it: confidence resolves verified, the prop's placeholder zero drives Available/USD/MAX, and an account-model balance gets pre-clamped and submitted with sendIsMax=false — past the builder's own MAX verification. Reachable whenever getCachedBalances returns a non-empty cache lacking the selected chain, since the dialog then skips its live fetch.

Both now resolve through selectBalanceEntry(balances, balance, chainId), and fromBalance's tail reads that same entry instead of re-deriving the fallback. One object, judged and read.

2. A verified token vouched for native gas. Both screens passed the active asset's caip to isBalanceUnverified, then reused that one boolean to gate the native low-gas check. Degraded Solana + directly-confirmed SPL token ⇒ token correctly verified, SOL still a placeholder zero, shared flag lets the gas verdict run, and "deposit SOL to send tokens" returns — the exact false warning this PR removes, re-entering through the exception that makes the token case correct.

screen	asset verdict	native/gas verdict
SendForm	activeAssetUnverified	nativeBalanceUnverified
SwapDialog	fromBalanceUnverified	fromNativeUnverified

The native verdict uses the chain's native caip, so a confirmed token can never answer for the coin that pays the fee.

Coverage, stated plainly

selectBalanceEntry is real shared code, so finding 1 is pinned — reverting it to the cache-only lookup fails exactly one case. Finding 2's split is per-screen wiring; there is no React render harness in this repo and adding one is not this PR's job, so the tests pin the predicate contract the split depends on while the wiring itself is verified by reading. The test file header says so rather than implying coverage it does not have.

Also noted while verifying: fromBalance's EVM branch reads evmAddresses[].chainBalances, a third source with no syncState. It is judged by the chain-level entry, which is right — but with no entry for that chain at all, that branch can still return a figure. Out of scope here: that is the missing-entry case, not the degraded one.

Also: the "All Chains" total

Follow-up to #410, which taught the rows to say — but left the total summing those chains as 0 and printing a confident $X above them. It can't spin like a pending row — a chain the backend keeps failing would spin forever — so it renders ≥ $X with a tooltip when any row is unknown.

Tests

__tests__/failed-fetch-not-zero.test.ts — 30 cases. They pin behaviour, not wording:

• reverting only utxo.ts fails exactly 4 (MAX, subtotal message, outage message, fee estimate)
• reverting only the cosmos ?? fails exactly the 2 frontend-'0' cases
• reverting only the btc-accounts filter fails exactly the 2 getSpendableXpubs cases
• reverting only selectBalanceEntry to a cache-only lookup fails exactly 1
• the reachable-path controls stay green throughout

Also wires src/bun/txbuilder/cosmos.test.ts into make test-unit. It was green and unreferenced — 10 assertions that had never guarded a release, and the regression net for the cosmos changes here. It is script-style (own runner + process.exit), so it gets its own line rather than joining the bun test list, where the exit would cut the run short.

make test-unit   473 pass, 0 fail across 31 files, +35 btc-backend, +10 cosmos
tsc --noEmit     627, unchanged across all four commits, 2 below baseline 629

Not covered

Cold-start hardware validation, still outstanding from #410 and not made worse here.