A time lock makes a cross-chain asset transfer recoverable after a deadline; it does not, by itself, prove that the destination transfer was valid.
How the common case works
The standard pattern is a hashed time-lock contract (HTLC), an escrow with two spending paths. The recipient can claim only by presenting a preimage whose hash matches the contract’s hashlock before expiry. If that claim does not happen, the depositor uses the timelocked refund path after expiry. In an atomic swap, both chains use the same hash: Alice locks ETH on Ethereum, Bob locks BTC on Bitcoin, Alice reveals the secret to claim BTC, and Bob uses that revealed secret to claim ETH. The swap either exposes the secret on both legs or eventually returns the funds.
Where it fits
Use an HTLC for a direct trust-minimized swap when both chains support compatible hashing, contract or script conditions, and usable finality. The deadline needs slack: the second claimant must observe the reveal, submit a transaction, and survive congestion. It is a poor fit for arbitrary cross-chain messages, where verification and destination execution matter more than secret revelation.
Wormhole Protocol uses signed cross-chain messages called VAAs, while LayerZero Protocol separates message verification by DVNs from destination execution by an Executor. Their token applications can add expiry or cancellation, but those paths are not automatically HTLCs. deBridge Protocol shows the solver-based version: a user’s input rests in the DlnSource contract while a solver fulfills the requested asset on the destination chain; an unfulfilled order can be cancelled.
The same separation matters in universal bridging: custody, proof, execution, and recovery are different mechanisms. The wider design space is captured by Universal Bridge.
The edge case that changes the answer
A timeout is not an oracle. If the condition depends on a price, delivery event, or state change on another chain, the contract cannot know that condition merely because a deadline passed. It needs a verifier, oracle, or challenge mechanism. The practical verdict is simple: use HTLCs when revealing a secret can be the condition; use verified messages with explicit cancellation when solver fulfillment or cross-chain state is the condition. Choose the deadline from worst-case finality and execution time, not the user-interface target.