Companion

The BIP-65 nLockTime height/time split (Bitcoin Core's LOCKTIME_THRESHOLD): a committed unlock value below 500,000,000 is a block height; at or above it, a Unix epoch time (500,000,000 s ≈ 1985-11-05). The creation guards sit on opposite sides of it — buildDestination rejects heights at/above the threshold (exclusive ceiling: the highest committable height is one below), buildDestinationAtTime rejects timestamps below it (inclusive floor) — so every unlock value has exactly one meaning, with no gap and no overlap. isVaultMature branches on the same split. See BIP-65 and the Nexa interpreter's nLockTime handling.

Highest unlock timestamp a vault may commit to: 0xFFFFFFFD (2106-02-07). Anything higher can never be claimed, because the uint32 walls stack twice. A claim is final only when its lockTime is STRICTLY below the chain-time cutoff (IsFinalTx, nexa src/consensus/tx_verify.cpp: nLockTime < nBlockTime), and the block that would confirm the claim must itself carry a uint32 timestamp STRICTLY above the previous block's median-time-past (the time-too-old rule, nexa src/validation/validation.cpp). With header times capped at 0xFFFFFFFF, the highest median any minable block can be checked against is 0xFFFFFFFE, so the highest commitment that can ever confirm is 0xFFFFFFFD. (nLockTime is also serialized as a uint32, so nothing above 0xFFFFFFFF encodes at all.)

BIP-113 median-time-past window: the number of most-recent block header times whose median the network compares a timestamp nLockTime against. Mirrors GetMedianTimePast() in the node.

Median of headerTimes the way the node's GetMedianTimePast() computes it: sort a copy, take the middle element (size/2). Callers pass the times of the synced block and up to MTP_BLOCK_SPAN-1 of its ancestors, in any order.