Time locks: coins that can't move until a certain moment

Most crypto security is about who can spend: which keys, how many signatures. Time locks add a second dimension — when. A time-locked coin can't be spent before a set date or block height, no matter who holds the keys.

It sounds like a niche feature, but time locks quietly power a lot of crypto: payment channels, vesting schedules, inheritance plans and governance delays. Understanding them also explains a design choice you'll meet in most wallets.

Two kinds of time

Blockchains measure time in two ways, and time locks use both:

• Absolute time. "Not before 1 January 2030" or "not before block 1,000,000". The coin is locked until that moment, then behaves normally.
• Relative time. "Not until 1,000 blocks after this coin was received." The clock starts when the coin is created, so each deposit gets its own countdown.

Absolute locks suit fixed dates, like a vesting cliff. Relative locks suit rules like "if nobody else acts within 30 days, this other key may spend" — a pattern that shows up in recovery and inheritance designs.

How Bitcoin does it

Bitcoin has time locks at two levels:

• Transaction level. Every transaction has a nLockTime field. If it's set to a future time or block, the network won't accept the transaction until then. This locks the transaction, not the coin — whoever holds the keys can still sign a different transaction without the lock.
• Script level. Two opcodes, OP_CHECKLOCKTIMEVERIFY (absolute) and OP_CHECKSEQUENCEVERIFY (relative), let an address's own spending rules require that time has passed. These lock the coin: no transaction can spend it early, whoever signs.

The script-level versions are the powerful ones. They let you build addresses with several spending paths, such as "2 of these 3 keys at any time, or this single backup key after one year".

How smart-contract chains do it

On Ethereum and similar chains, a time lock is just contract logic: the contract compares the current block time to a stored deadline and refuses to act before it. That makes time locks flexible — vesting contracts that release tokens monthly, governance systems that force a waiting period between a vote passing and its execution, and upgradeable contracts that announce changes days in advance so users can react.

That last use matters for security. A delay between "an admin key decided something" and "it happened" gives everyone time to notice a malicious change — one of the questions worth asking about any contract's upgrade powers.

What time locks are good for

• Inheritance and emergency access. A backup path that only opens after a long period of inactivity lets heirs recover funds without being able to touch them while you're active. Planning for inheritance often comes down to exactly this kind of rule.
• Recovery keys. A recovery key that can act alone, but only after a delay, is far less dangerous if it's stolen — the owner has time to move funds first.
• Payment channels. The Lightning Network relies on relative time locks to give each side a window to dispute a cheating attempt.
• Vesting and commitments. Locking tokens until a date makes a promise enforceable by the chain instead of by trust.

The trade-offs

Time locks aren't free:

• They lock you out too. A lock can't tell an attacker from an emergency. If you need the money before the date, it stays locked.
• Complexity has costs. Scripts with several paths are harder to build, audit and recover. A mistake in a time-locked script can make funds unspendable — and it may only surface years later, when the lock expires.
• Relative locks need maintenance. "After a year of inactivity" schemes usually require the owner to refresh their coins periodically to restart the clock.
• Wallet support is uneven. A time-locked address is only useful if the software you'll eventually recover with understands it.

Time locks and SSP

SSP's vaults today are pure multisig: an M-of-N set of keys, with no time-based spending conditions. Your 2-of-2 vault can be spent at any moment when both keys agree, and never otherwise. That's a deliberate trade-off: a simple script is easy to verify, easy to restore with standard tools, and has no clock that can surprise you years from now.

Recovery in SSP works through your keys and their backups rather than through time-delayed paths. How different multisig set-ups compare covers the choices that matter for most people, and for teams, SSP Enterprise vaults let you choose how many signers must approve.

The honest summary

Time locks let the chain enforce when coins can move, not just who can move them. They make inheritance plans, recovery keys and payment channels possible without trusting anyone to wait.

They also add complexity and can lock out their owners as firmly as their attackers. Used carefully, they're one of crypto's most useful tools — and the simplest scripts are still often the safest.