Spendability exclusion log repeats every scan for designed-gated contracts

[tiero]

Every getSpendableVtxos pass logs, per VTXO per reason:

[spendability] getSpendableVtxos: a766def1…:0 at 51208df4… (contract type 'vhtlc-v2') is not generically spendable

The exclusion is correct — RFQ lockups register with genericallySpendable: false precisely so generic spending cannot forfeit a live covenant — but logExcludedVtxos (src/contracts/spendability.ts) emits one line per VTXO per reason per call, and getSpendableVtxos runs on every balance refresh and coin-selection pass. A funded lockup is a designed, long-lived gated row, so the wallet console repeats the same line for the swap's whole lifetime: expected steady state reported as if noteworthy, drowning the log the comment says is "the only field-diagnosable signal for why a coin is missing from a spend."

Proposal — dedupe, don't demote. Keep the line (it earns its place the first time: it explains a missing coin) and silence repeats with a module-level seen-set keyed on (source, script, reason) — first occurrence logs, later scans stay quiet, and a new lockup or a new exclusion reason still surfaces. Alternatives considered and why not:

• Dropping to a quieter channel loses the one field signal the comment defends.
• Logging only for explicitly-named coins misses the "why is my balance short" case the current design serves.

One nuance worth keeping: if an outpoint's exclusion reason changes (e.g. gate → intent-lock), that's new information and should log again — keying the set on the reason string covers it.

Observed on the wallet's feat/arkade-swap branch with @arkade-os/sdk@0.4.60 during normal Lightning-send operation.

[arkana-ai-bot]

Root cause confirmed on the `feat/arkade-swap` branch (`a3fc6e0`):

Primary location: `packages/ts-sdk/src/contracts/spendability.ts` — `logExcludedVtxos` is a stateless loop: each call iterates all vtxos × all exclusions and emits a `console.debug` line per match with no memory of what it already reported.

Caller: `packages/ts-sdk/src/wallet/wallet.ts:1226` — `getSpendableVtxos` calls `logExcludedVtxos` unconditionally on every invocation. Since `getSpendableVtxos` runs on every balance refresh and coin-selection pass, an RFQ lockup (gated for its full lifetime) generates the identical line every cycle.

Second call site: `wallet.ts:1261` inside `logUngatedInputs` — triggered only on explicit-input spend paths, so much lower frequency. Same fix applies but is less urgent.

Implementation notes for the seen-set approach:

• Key on the full `${source}:${script}:${reason}` string so a contract whose exclusion reason changes (e.g. gate → intent-lock) still surfaces the new message.
• Module-level `Set` is fine for the current single-wallet-instance usage; if multi-wallet scenarios arise later, a `WeakMap<object, Set>` keyed on the wallet avoids cross-instance suppression.
• The `logUngatedInputs` docstring already says "diagnostics only / never throws" — the seen-set fits that contract exactly.

[tiero]

Alternative to the seen-set: filter for what is spendable, instead of diffing against what isn't. @pietro909

The filtering is already right — wallet.ts:1221 does !gated.has(vtxo.script). The noise comes from logExcludedVtxos afterwards, re-running every exclusion over every VTXO only to narrate the result.

The contract manager owns the spendability answer (isGenericallySpendable, isOurs). Ask it for the spendable set and filter positively, and the structural case needs no narration at all: vhtlcV2.ts:394 is isGenericallySpendable: () => false — a constant, so that line can never become actionable however many times it prints.

Keep reporting the two exclusions that are temporary and actionable, pending recovery and intent locks. Those explain a coin that will come back.

This also avoids adding a seen-set, which is cache state that then needs invalidating.

[Kukks]

Still present on master and in 0.4.64/0.4.65. There's a driver here I don't think the thread has accounted for yet: the repeats don't need an application calling getSpendableVtxos at all.

VtxoManager.initializeSubscription starts the boarding poll for any wallet whose settlementConfig isn't explicitly false, and DEFAULT_SETTLEMENT_CONFIG.pollIntervalMs is 60_000. From there it's startBoardingUtxoPoll → pollBoardingUtxos → runPeriodicSettle → selectExpiringVtxos → wallet.getSpendableVtxos({ withRecoverable: true }) → logExcludedVtxos. runPeriodicSettle reaches selectExpiringVtxos whenever renewalInProgress is false — it isn't gated on there being a boarding input to settle — so an idle, sweep-capable wallet re-emits one line per gated VTXO every 60 seconds for as long as the process lives.

That raises the floor from how the issue currently reads: "every balance refresh and coin-selection pass" is something an integrator can do less of; this one they can't, short of settlementConfig: false, which also turns off boarding sweep and deprecated-signer migration.

From a mainnet Lightning solver on 0.4.64, one 73-minute window: 92 of 98 stdout lines were [spendability], and 91 of those were the same outpoint. Gaps between them cluster at 60.7–61.6s — the setTimeout chaining plus poll time, not anything the service did. A second, much sparser series in the same log lands on exact 5-minute marks; that's our own coin-selection pass, the driver already described here. Both are present at once and separate cleanly by cadence. The outpoint appears in logs from 30 hours earlier, gated throughout — the steady state this issue describes, a funded lockup waiting out its refund locktime.

One argument for @tiero's positive-filter shape over the seen-set, from that: the repeats carry nothing the first line didn't. vhtlc-v2's answer is a constant, so a healthily-waiting lockup and a genuinely wedged one produce byte-identical output at the same rate — watching longer never tells them apart. And with a 60s poll driving it unprompted, a seen-set would have to live for the whole process lifetime to suppress anything, which is the unbounded cache state you flagged.

Happy to test whichever shape you land on against this service.