>_ Runtime Guard

Runtime Lockdown Guard

Safe-native timelock and panic lockdown controls.

Runtime Lockdown Guard is the planned timelock, panic-lockdown, and anti-coercion product for high-value Safes. It is designed for Safe v1.5.0, Ethereum mainnet first, with funds remaining in the Safe.

Timelock

Waiting gives humans time.

Owner-path and module-path transactions can be announced, wait through a configured delay, then execute as ordinary Safe transactions.

Panic lockdown

Freeze execution during suspicious conditions.

A pre-registered panic signer can lock down execution paths during a suspicious or coerced situation. The mechanism creates an intervention window; it does not remove the need for drills and operating discipline.

Reviewed fast lane

GREEN can bypass delay when policy allows.

The planned fast lane lets an allowlisted reviewer bypass the timelock for transactions independently reviewed as GREEN and policy-compliant.

Limits

Safe v1.5.0 required.

Lockdown depends on Safe v1.5.0 module guard support. Existing Safes may need an upgrade before full owner-path and module-path coverage is possible.

Lockdown Guard is not a magic anti-coercion promise. It creates delay, visibility, and a lockdown mechanism. It still depends on Safe configuration, panic-signer drills, and humans triggering lockdown in time.

FAQ

Runtime Lockdown Guard FAQ

Does Runtime Lockdown Guard custody or move funds?

No. Runtime Lockdown Guard is designed around Safe-native controls. Funds remain in the customer's Safe, and the product does not give Runtime Guard unilateral custody or withdrawal authority.

The goal is to add delay, visibility, and panic-lockdown mechanics around execution paths. It does not remove the need for careful Safe configuration, signer discipline, and operational drills.

What Safe setup is required?

Runtime Lockdown Guard is planned for Safe v1.5.0 and Ethereum mainnet first. The design depends on Safe module guard support, so older Safes may need an upgrade before full owner-path and module-path coverage is available.

Runtime Guard should not be configured as a signer that is either sufficient alone or structurally required for humans to reach threshold.

What happens during a panic lockdown?

A pre-registered lockdown signer can trigger a lockdown state during suspicious or coerced conditions. The point is to create an intervention window so normal execution cannot continue silently while the team investigates.

Lockdown is not a promise that coercion, operational mistakes, signer compromise, or all malicious paths become impossible. It is a control layer that must be tested before it is needed.