Pre-signed transactions that never expire defeat timelocks

The timelock is the last line of defence in on-chain governance: approve now, execute in forty-eight hours, and if something is wrong the community has time to act. A signature that stays valid forever quietly nullifies it.

Part of Digital asset custody

What a timelock is for

It creates an interval between a decision and its effect. During that interval, participants can observe what was approved and respond — by exiting, by raising an alarm, or by triggering a veto if one exists.

The security property is not the delay itself. It is that the pending action is visible for a period before it takes effect.

How a durable signature removes it

Transaction formats generally include something that prevents replay — a nonce, a sequence number, or a recent block reference that expires. That mechanism also bounds how long a signed transaction remains valid.

Facilities designed to support offline and multi-party signing relax that. A durable nonce remains valid until consumed, which means a transaction signed today can be submitted at any future point.

Every row on the left is a legitimate requirement. The facility is not a bug; the interaction with governance delay is.

The attack shape

1. Signers approve a transaction during a period when it appears benign, or as part of a batch.
2. The signed transaction is held rather than submitted.
3. Conditions change — a timelock elapses, a parameter shifts, an upgrade lands.
4. The transaction is submitted at the moment it does maximum damage.
5. From the chain's perspective it is perfectly valid, signed by the correct quorum.

There is no forgery and no key compromise. The authorisation was real; only its timing was not what the signers understood.

Why observers cannot compensate

A monitoring system watching the timelock queue sees pending transactions. It does not see transactions that were signed but never queued, because they exist only as bytes in someone's possession.

So the governance visibility the timelock was supposed to provide is absent for exactly the transactions that matter most.

The two properties that restore it

# R1: short expiry
  statement.not_after = issued_at + 15 minutes
  → a signature that is not used promptly is worthless
  → the signer's context and the execution context match

# R2: one-shot binding
  statement.nonce = <specific execution nonce>
  → the signature authorises exactly one execution
  → consumed on use, refused thereafter

# Together:
  authorisation and execution are close in time and
  one-to-one. The gap the attack lives in is removed.

The tension with offline signing is real and resolvable. Signers can still coordinate asynchronously — they assemble an intent and a quorum — but the final authorisation that actually executes is short-lived and specific.

Separating intent from authorisation

This is the design pattern that satisfies both requirements.

The long-lived artefact is the one everyone can see. The short-lived one is the one that executes. That inversion is what the current arrangement gets backwards.

What to check in your own protocol

• Can a signature produced today execute next month? If yes, the timelock is advisory.
• Is there a facility that suspends normal replay protection, and who can use it?
• Are signatures bound to a specific execution, or to an action class?
• Does the queue show everything that could execute, or only what has been submitted?
• If a quorum signs a batch, can individual items be extracted and submitted separately?

The last question catches a variant that is easy to miss. Batch approval is convenient and, without per-item binding, authorises each item independently and indefinitely.

Why monitoring cannot compensate

A system watching the timelock queue sees pending transactions. It cannot see a transaction that was signed but never queued, because that exists only as bytes in someone's possession. The governance visibility the timelock was supposed to provide is therefore absent for exactly the transactions that matter most.

Objections and honest limits

“Durable nonces are a bug.” They are not. They support legitimate offline and multi-party signing. The problem is their interaction with governance delay, which assumes signatures expire.

“We approve in batches, which is efficient.” Batch approval without per-item binding authorises each item independently and indefinitely. It is the variant that is easiest to miss and hardest to reason about afterwards.

The resolution is to invert which artefact is long-lived: the publicly queued intent should be the durable one, and the final authorisation that actually executes should be short-lived and bound to a single execution.

Auditing your own governance path

1. Can a signature produced today execute next month? If yes, the timelock is advisory.
2. Is there a facility that suspends normal replay protection? And who is permitted to use it?
3. Are signatures bound to one execution, or to an action class? One execution, consumed on use, is the property you want.
4. Does the queue show everything that could execute? Or only what has been submitted?
5. Can individual items be extracted from a signed batch? Batch approval without per-item binding is the common variant.

Terms used here

Durable nonce

A mechanism that keeps a signed transaction valid until explicitly consumed, rather than expiring with a recent block reference.

Timelock

A mandatory delay between approval and execution, whose security value is that the pending action is observable during the interval.

One-shot binding

Tying a signature to a specific execution nonce so it authorises exactly one execution and is refused thereafter.

Frequently asked questions

Are durable nonces a flaw? No. They support legitimate offline and multi-party signing. The problem is their interaction with governance delay, which assumes signatures expire.

Why doesn't monitoring catch this? A signed but unsubmitted transaction exists only as bytes in someone's possession. It is not in any queue an observer can watch.

How do you keep offline signing workable? Separate intent from authorisation. The intent is long-lived and publicly queued; the final signature that executes is short-lived and bound to one execution.

What is the easily missed variant? Batch approval without per-item binding. Each item is then independently and indefinitely authorised.

Why doesn't monitoring catch a pre-signed transaction? It exists only as bytes held by whoever assembled it. It is in no queue any observer can watch.

Sources and further reading

• Solana documentation — durable transaction nonces
• Uniform Electronic Transactions Act (ULC)