A time lock is only as good as whoever is watching it

A time lock on a Squads v4 multisig makes an approved proposal wait before anyone can execute it. That wait protects you only if someone notices the approval, understands what it does, and can gather enough signatures to cancel it before the wait ends.

This post covers what the Squads v4 time lock does, a gap that catches teams rotating signers, why faster finality on Solana makes the time lock the only window left, and how to check your own settings with a read-only tool.

What the time lock does

In Squads v4, time_lock is a number of seconds stored on the multisig account: "How many seconds must pass between transaction voting settlement and execution" [4]. The execute instructions check that at least that many seconds have passed since the proposal's approval timestamp [1][2][3]. The program caps it at three months [4].

Four details matter in practice:

• The clock starts at approval, not when the proposal is created [1].
• One member can execute. Once the wait is over, any single member with the Execute permission can run it [1].
• Cancelling takes a threshold. Members with the Vote permission cast cancel votes on an approved proposal, and it is cancelled only when the cancel votes reach the multisig's threshold [5]. Stopping a proposal takes as many people as approving it.
• Zero is allowed. A time lock of 0 means an approved proposal can run at once.

Drift's Security Council is the public example. Chainalysis and BlockSec both report that it was a 2-of-5 multisig with zero time lock [8][9]. Chainalysis wrote that this meant "eliminating the delay window that could have allowed detection and intervention" [8].

Approved proposals that are still executable

When a multisig's members, threshold or time lock change, Squads v4 marks every transaction created so far as stale, by moving its stale transaction index up to the latest transaction index [4][10]. Nobody can approve or reject a stale proposal [5].

What happens to a proposal that was already approved depends on its type:

Vault transactions and batches are the ones that act as the vault: moving funds, or upgrading a program whose upgrade authority is the vault. So rotating signers does not void an approval made by the old set. Take a simple case:

1. Members approve a vault transaction but nobody executes it.
2. Later, you remove a member whose key you no longer trust.
3. The old approval is now stale, but it still meets the execute checks. Once the time lock has passed, any member with the Execute permission can run it.

The fix is explicit. Squads v4 lets members cancel an approved proposal even when it is stale ("CAN cancel a stale proposal") [5]. List the approved, unexecuted proposals and cancel the ones you no longer want before you rely on a rotation.

One more setting overrides all of this. If a multisig has a config authority, that one key can add and remove members, change the threshold and set the time lock without a vote [10]. A time lock does not slow down a config authority.

Fast finality leaves the time lock as the only window

Alpenglow's voting protocol, Votor, has been live on Solana mainnet since epoch 1064, which started on 21 October 2026 [6]. Anza, which built it, states it as "Finality in 150ms" [7]. The Solana Foundation's page compares this with about 12.8 seconds under TowerBFT, and notes that 150 milliseconds is a target, not a constant [6].

A finalised transaction could never be reversed. What has changed is the gap between "it is visible on chain" and "it is final": it is now far shorter than any person can react in. If your monitoring alerts on execution, it alerts after the fact. The only window you have is the one you build yourself, between approval and execution, and that window is the time lock.

Who watches

A time lock without a watcher is a delay nobody uses. A workable setup has five parts:

• Watch the multisig, read-only. Every proposal, vote and status is a public account. A small job that polls the multisig and its proposals needs no keys.
• Alert on approval, not execution. The alert should go to people, through a channel outside the multisig's usual tools, and say what the proposal does: the decoded vault transaction, not just "proposal 42 approved".
• Make the time lock longer than a cancel takes. Cancelling needs a threshold of signers [5]. If your threshold is three and your signers share one time zone, a one-hour lock overnight protects nothing. Size it to the slowest realistic cancel, including weekends.
• Practise a cancel. Run one on a devnet copy of your multisig, with the same signers and devices, and time it.
• Clean up before and after rotations. Cancel approved vault transactions and batches you no longer want, as above.

Check your own settings

Our scanner, solana-authority-scan, is open source and read-only. It never signs or sends a transaction and holds no keys [11]. For a program, it reports the upgrade authority and, when that authority is a Squads v4 vault, the threshold, time lock, config authority, open proposals, and approved proposals that are still executable below the stale index [11].

cargo install --locked solana-authority-scan
export SOLANA_MAINNET_RPC_URL=https://api.mainnet-beta.solana.com
solana-authority-scan --cluster mainnet <your-program-id>

Replace <your-program-id> with your program's address. If your provider refuses the bulk read the scanner uses to find a vault's multisig, pass the multisig with --multisig <your-multisig-address> [11]. Rules to look for in the report:

• multisig-time-lock-zero: the time lock is 0.
• approved-proposal-still-executable: an approved vault transaction or batch at or below the stale index, which Squads v4 will still execute.
• multisig-config-authority-set: a config authority can change the multisig without a vote.

The scanner is not an audit. It reads only on-chain data: it cannot see who holds each key, how keys are stored, or whether anyone is watching. By default it reads the newest 50 proposals at or below the stale index, so older approvals need --stale-window [11]. "No rule matched" does not mean the setup is safe.

What we do: our admin-plane Snapshot reviews who can change your program and how fast, including time locks and monitoring. It is not an audit. See https://centrob.co/#solana.