Guardrail: Locking Down Delegate Calls in Safe

Discover how Guardrail adds a layer of protection to your Safe by restricting risky delegate calls. Learn how this beginner-friendly guard sets up time-delayed permissions and strengthens your wallet’s defense against malicious code.

Why Use Guards?

Safe allows users to secure assets with multisignature rules (e.g. requiring 3 out of 4 owners to approve a transaction). This multisig scheme ensures no single owner can move funds unilaterally. However, you need extra safety checks beyond just collecting signatures - and that’s where Safe Guards come in.

A Safe Guard is like a security officer for your Safe account: Imagine your Safe is a vault protected by multiple keys (signatures). A Guard is a smart contract that sits at the vault’s door and verifies that each transaction meets certain conditions - even after the keys have been turned. If a transaction doesn’t pass the Guard’s scrutiny, it gets blocked. This can prevent mistakes or malicious actions that signers might have missed.

💡 Important: Because a Guard can outright block transactions, a buggy or overly restrictive Guard could lock you out of your own Safe (a sort of self-inflicted denial of service). So it’s critical to use well-audited Guard code and always have a recovery plan (such as a way to remove or disable the Guard if needed).

Meet Guardrail - A Basic Yet Powerful Guard

Guardrail is a Safe Guard implementation focused on a specific kind of transaction risk: the notorious DELEGATECALL operation. In simple terms, delegate call lets your Safe execute code from another contract as if it were part of the Safe itself. It’s a bit like letting a stranger into your house and giving them permission to rearrange the furniture - powerful, but potentially dangerous if misused. By design, Safe’s modular architecture uses delegate calls for flexible features (Ex: Migration, Batch Calls, etc.), but that flexibility can be abused if a malicious contract is inadvertently called.

Guardrail puts guard rails (pun intended) around delegate calls. It ensures that your Safe only delegate calls pre-approved contracts allowlist, and it imposes a time delay for pre-approving new contracts. Here’s how it works in practice:

• Initial Setup: When you first install Guardrail on your Safe, you specify an allowlist of trusted contracts that your Safe can delegate call (for example, the official Safe MultiSendCallOnly library contract used for batched transactions). Guardrail lets you add these initial addresses without delay during setup.

• Time-Delayed Additions: If later you want to allow delegate calling a new contract, Guardrail won’t let you use it immediately. Instead, you (or another Safe owner) would initiate a request to add the new contract to the allowlist, and a timer starts (the delay period is configurable, say 24 hours). During that time, the new delegate call target is not yet authorized. This delay acts as a safety buffer - if the request was malicious or unintentional, there’s time to notice and cancel it before it takes effect. Only after the delay expires will the new contract be allowed for delegate calls.

• Instant Removal: On the flip side, removing a contract from the allowlist (for example, if a previously trusted contract is found to be vulnerable) can be done immediately. Guardrail allows instant removal of delegates to quickly react to threats.

• Comprehensive Coverage: Guardrail is designed to work with the latest Safe contracts (v1.5.0 and above) and covers both regular multisig transactions and those executed via Safe modules. (Modules are plugins that can initiate Safe transactions without direct owner signatures - Guardrail covers those too, ensuring a module can’t use an unauthorized DELEGATECALL operation either.)

In summary, Guardrail’s purpose is to provide a beginner-friendly example of a Safe Guard that tackles a real security concern (unsafe delegate calls) in a straightforward way. By using an allowlist and time delays, it gives Safe owners finer control over what code their wallet will execute. This significantly reduces the risk of certain exploits, such as malicious modules or compromised libraries, while still maintaining flexibility for legitimate use cases. It’s the first stepping stone into the world of Safe Guards, showing how adding programmable rules can make your multisig wallet even safer.

Why Use Guardrail?

For most everyday Safe users, multisig approvals might be enough. But consider scenarios like DAOs or treasury wallets that use complex transactions (batch operations, upgrades, interactions with many protocols). A hacked dapp interface or a clever phishing attempt could trick all owners into approving a dangerous transaction that calls an attacker’s contract via DELEGATECALL operation. Guardrail would catch that - “Hold on, this contract isn’t on the approved list!” - and stop it in its tracks. And because it introduces a time delay for new approvals, even if an attacker tries to rush something through, they’d have to wait out the delay during which vigilant owners (or any available monitoring services) could intervene.

On the flip side, Guardrail is simple enough to set up for developers experimenting with Safe Guards. Also, it’s simplicity makes it a very low risk addition to any user’s Safe as well, as it is compatible with the current Safe{Wallet} interface, and doesn’t break any the of the usual transaction flows. The project’s code comes with a sample Safe App interface (a React dapp) for managing the allowlist, and even formal verification specs (using Certora) to prove properties about the guard’s behavior. While you wouldn’t deploy Guardrail on a mission-critical $100M treasury without a professional audit, it’s a great way to learn the ropes of Safe Guards in a test environment. Think of it as “Guard 101” for Safe: it demonstrates what a guard can do, how to attach one to your Safe, and the benefits of having programmable transaction policies.

Using Guardrail (Plain-English Walkthrough)

Using Guardrail typically involves these steps: (1) Deploy the Guardrail contract to your desired network (it’s written in Solidity and can be deployed via common tools like Foundry or Hardhat). For testing with Safe App, there’s also an AppGuardrail variant provided, intended for demo purposes. By default already deployed in Sepolia and Gnosis Scan.

(2) Enable Guardrail on your Safe - this means calling the Safe’s setGuard function with Guardrail’s address. Once set, every transaction your Safe executes will first route through Guardrail’s check.

(3) Configure the allowlist - initially, you add known safe contracts (like the Safe’s own MultiSendCallOnly library, which is added by default when you enable the Guard using the Safe App) to Guardrail’s allowed list. If you forget one, don’t worry: if a transaction tries to use a delegate call to an address not on the list, Guardrail will reject it with an error. You can then add that address (if it’s legitimate) via a Safe transaction, wait the required delay, and try again.

(4) Operate as usual - when all signers approve a Safe transaction that involves a delegate call, Guardrail will automatically enforce the rules. Allowed delegate calls go through; disallowed ones are blocked. If someone attempts to add a new delegate call target, that Safe transaction will succeed only in scheduling the addition (starting the timer).

What’s next?

By introducing Guardrail as our first example, we set the stage for more advanced guards. It addresses one narrow aspect (delegate calls) but does it well, illustrating the power of onchain enforcement. In the next part, we’ll expand on this idea and look at Fiducia, a guard with a broader scope of control (including specific addresses, functions, and even an exciting concept called cosigners). Guardrail taught our Safe some basic self-defence; up next, we’ll teach it some advanced martial arts for black belt security control!

About Safe Research

Safe Research is the applied R&D arm of Safe, dedicated to advancing the self custody stack. Our work is grounded in the cypherpunk principles of security, censorship resistance, and privacy, and we focus on building trustless, user centric infrastructure for smart accounts and wallets.

• Discuss Deletgate calls in our forum

• Learn more about Safe Research

• Read our manifesto

Let’s make Ethereum’s original cypherpunk vision real, one commit at a time.