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

With the Guard enabled, a transaction can execute through Safenet only with both normal Safe authorization and a valid secure attestation for the exact Safe, network, and transaction. 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

The delayed owner path requires no Safenet approval or attestation. Owners can execute the authorized action or remove the Guard after the configured delay. 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, owners must submit a fresh initiation transaction and wait for a new delay. 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.