Safenet Guard

The Safenet Guard enforces Safenet results onchain. When enabled, a transaction can execute through Safenet only if the Guard receives a valid secure Validator attestation for that exact Safe, network, and transaction. Without a valid secure attestation, the transaction cannot execute through Safenet. Safe owners remain in full control through a separate delayed execution path.

​

How Guard enforcement works

How the Guard decides whether a transaction can execute through Safenet. The Guard verifies that the attestation matches the exact:

• Safe.
• Network.
• Transaction.

An attestation for one transaction cannot authorize another. See Safenet results for which results receive Validator attestations.

​

Normal execution

A secure Safenet result receives a Validator attestation. When the Guard receives a valid secure attestation, the transaction continues through the normal Safe execution flow. The Guard does not replace the Safe’s existing signature threshold or other execution requirements. A transaction still requires normal Safe authorization in addition to the Safenet attestation.

​

When execution requirements are not met

Without a valid secure Validator attestation, the Guard does not authorize immediate execution through Safenet. This applies when a transaction:

• Receives an insecure result.
• Enters arbitration after Sentinels disagree.
• Cannot be checked reliably.
• Does not have a valid attestation for the exact Safe, network, and transaction.

The transaction can still be abandoned or replaced with a new transaction. Safe owners also retain ultimate control through a separate delayed execution path. This path is initiated independently and does not turn the original Safenet result into an approved transaction.

​

Delayed execution and exit

Owners, with the Safenet Guard enabled, can initiate a transaction through a separate delayed execution path without requiring a Safenet attestation. The configured delay must pass before the transaction can be executed. The same delayed mechanism allows owners to remove the Safenet Guard, so Safenet cannot permanently keep owners from operating or exiting their Safe. Removing the Guard still requires the configured delay, so it cannot happen immediately. Once the configured delay has passed, the authorized action can be executed before the delayed authorization expires. If it expires before execution, the action must be initiated again. Security-sensitive Safe configuration changes (see Safenet checks for which ones) follow the same model: they execute normally with a valid secure attestation, or owners can initiate them through the separate delayed path. Owners always remain in full control of their Safe’s configuration.