isVaultMature

Whether the vault committing unlock is spendable against the current chain, or null when the wallet is too disconnected to prove it either way.

Branches on the BIP-65 nLockTime height/time split — the same 500,000,000 boundary that splits the creation API (buildDestination commits below it, buildDestinationAtTime at or above it):

• unlock <LOCKTIME_THRESHOLD: a block height. Mature once the wallet's synced height reaches it — INCLUSIVE, because the node's mempool cutoff for heights is tip + 1 and finality is nLockTime < cutoff, so a lockTime equal to the tip is final.

• unlock >= LOCKTIME_THRESHOLD: a Unix timestamp — committed by buildDestinationAtTime, or by a recovered Otoplo-style vault — gated on chainTime (median-time-past, see there) with a STRICT compare, because the node's cutoff for timestamps is the median time itself: nLockTime < mtp, no +1. 2147483646 (2³¹ − 2), a value observed in on-chain vaults, is really ~Jan 2038 under this reading, not a far-future height.

Median-time-past is monotonic along a single chain and the wallet's synced view can only lag the chain it follows, so in steady state a vault this reports mature is mature on every node at least as synced. (Mid-reorg the wallet's header branch can transiently differ from the network's, so the guarantee is same-chain; the cost of that corner is a rejected relay and briefly reserved inputs, not an invalid vault.)

isVaultMature against a caller-held chainTimeSnapshot, so a single operation on a timestamp vault — a send refusal and its reason, or a status line's verdict and countdown — reads the clock once and stays self-consistent even if a block lands mid-way. (The height branch ignores the snapshot and reads the live synced height; its messages are best-effort against a moving tip.)