build
Build a TimeLockVaultDestination for this contract's current index that unlocks at a wall-clock time — epochSeconds, Unix time — instead of a block height, and cache it as destination.
No conversion to a block height takes place. The timestamp itself is committed in the locking script, and CHECKLOCKTIMEVERIFY natively reads it as a time: the BIP-65 nLockTime split makes the network interpret any committed value at or above 500,000,000 as epoch seconds, gating the spend on the chain's median time-past rather than its height. The template script, derivation path, and recovery layout are exactly those of buildDestination — a timestamp vault is a height vault whose committed value sits on the other side of the split, and isVaultMature, send, and rediscovery already handle both sides.
epochSeconds must lie in LOCKTIME_THRESHOLD .. MAX_UNLOCK_EPOCH_SECONDS: below the split the network would read the value as a block height, and above the ceiling no claiming transaction could ever become final (nLockTime is a uint32 that must sit strictly below the uint32-capped chain-time cutoff), stranding the coins forever.
Named distinctly rather than overloading buildDestination because the JVM cannot overload on parameter name alone (both take a single Long).
Like buildDestination, this re-points the CURRENT leaf rather than allocating a new vault — advance the leaf (nextDestination or the index overload) to open an additional vault.
Otoplo compatibility caveat: the on-chain script and BIP-44 path are identical to Otoplo's, so Otoplo's seed-restore scan will rediscover a timestamp vault — but Otoplo handles only the height side of the split (verified against its vault code): creation is height-only (its "Future Date" option converts the date to an estimated block height), the UI shows any committed value as "Locked until block N" and keeps the claim action disabled while the height tip is below it — for a timestamp, effectively forever — and its claim transactions set nLockTime to the current tip height, which sits on the wrong side of the split and cannot satisfy a timestamp vault's CLTV. Use height-based buildDestination for vaults that must remain fully Otoplo-operable; libnexakotlin claims timestamp vaults correctly either way.
Jump the cursor to index and buildDestinationAtTime there, keeping its timestamp-range checks — the epoch-seconds counterpart of the buildDestination index overload. See buildDestinationAtTime for the semantics and the Otoplo compatibility caveat.