Guarding the Safe - From Guardrail to Policy Engine
DeFi Security Summit at Devconnect Argentina 2025 · November 2025 · 5:00
Shebin John, who works in R&D at Safe, gives an overview of Safe's evolving stack of onchain security guards. They range from simple delegatecall protection to configurable rule sets and modular, multi-policy enforcement, and the talk shows how layering guards in a multisig smart account can strengthen wallet safety at every level, moving from a single guardrail toward a full policy engine.
Speakers
Topics
From DeFi Security Summit at Devconnect Argentina 2025, hosted by DeFi Security Summit.
Transcript
check. Uh hello everyone. Uh today we are going to speak uh to learn about guarding the safe from guardrail to policy engine. I know it's a bit mouthful and I'm here to break it down for you. My name is Shbin John. I am a senior research engineer at safe research which is a research wing of safe. I'm hoping everyone knows about safe. Uh in safe we have like two types of transaction flow. The first one is a normal transaction flow where you interact with the say smart account and the interaction happens in a particular protocol or the transfer happens and the second one is a module transaction flow and in module it's like a custom logic which you can add to your safe smart account for some certain actions you
want to interact with and in the safe uh module transaction flow what happens is that user interacts with the module directly and the um safe smart account uh module uh execution ution happens and then the protocol interaction happens. So now we bring the guard into this flow. What happens is that the user interacts with the safe smart account again. This time the guard has certain logic, certain checks for transaction verification and the safe checks these things uh in the safe guard. Then the protocol interaction happens. So it's like a second layer of checks which can happen in the uh safe smart account not just the owner signature and the same
happens with the safe module. The user interacts with the safe module. The module checks for the guard uh if there is any uh verification or uh to happen then that happens and the protocol interaction happens. So today uh I want to introduce you to three different guards. The first one is guardrail. So basically what a guardrail does is like it denies all types of delegate call unless you configure certain necessary ones. One of the necessary ones which I can think of is safe migration which we use for let's say you have a safe at 1.3.0 you want to upgrade to 1.4.1 you use a safe migration with a delegate call. For those who don't know what delegate call is, basically whenever you use a
delegate call to interact, the changes happens in your own contract rather than in the called contract. And it uh follows a deny by default method. So if it is not configured, then uh that particular transaction won't execute. The second one is fiducia. Fiducia works uh based on an access selector mechanism. So whenever you call a transa call a function you have to specify the two address the function selector and certain types of operation. So in this case it's either call or a delegate call. So this basically makes a unique set for every transaction. And what fiducia does is that if a particular transaction is not configured then it is time delayed. So you as an owner have
enough time to react to any type of transaction which is happening in your safe even if you have already signed it. And in here the configuration becomes important for guardrail it was uh like you activate it and you can forget but this case if there is a configuration that is much better. And here we also bring the co-signer into the mix which basically helps you to vet the particular transaction by some cosigner u uh services which are out there right now.
And the third and the most powerful one is the policy engine. Policy engine also uses the access selector mechanism. uh instead of having uh the time delayed for every uh access selector, what it does is that it can you can basically customize for every access selector, you can add a policy. What a policy does is that you can add custom logic. So let's say that you want to pay uh an employee every month uh employees every month uh and it should not go above an x amount then uh you can write a policy for this and every time the amount goes beyond that x amount the transaction won't execute even with an owner signature it the all each of these policies are very small and concise which makes it easier
for testing auditing and formally verifying it for your entire setup and there is also a fallback mechanism built in which if ideally paired with a cosigner gives you an extra layer of security. So to conclude my thoughts uh what I would like to say is that these are three guards which we have iterated over time. So uh it's easier to test things out. Uh these all these are in a beta version. So maybe test it out in a test net so that you can get a feel of it. And you can think of it in this way.
Guardrail is a single tool. Let's say that it's a hammer or a screwdriver. Uh, Fidia is a Swiss army knife. You can do a lot of things, but it's still limited by its possibilities. And pulse engine is like a toolbox with almost all the set of tools available and you can configure uh however you want with custom logics and all the things. Thank you.