How to use GnosisSafe Modules for secure on-chain Automation

[Music] there you go okay yeah perfect amazing So yeah thank you everyone for coming um it's great that all of you came this early um I know yesterday there were some parties so everyone who's here uh thank you so much super grateful for um for your presence and for the interest in the talk um so as you can see today I'll be giving a talk on automation of Nosa safe modules so I can give a bit of context um of why I'm giving this talk in the first place um so I'm not working for say for phenosis I'm with a company called dialectic we are an asset manager based in Switzerland and we do a bunch of different investment strategies uh so we have a VC fund we have a liquid asset fund and we have a yield forming fund and for the yield forming fund we have developed a bunch of automation tools that allow us to do what we call institutional grade yield forming so there's a QR code down there the chronograph one that's a blog post that we recently published which goes over the risk framework and how we look at yield forming and all of the things that we need to do to do this that are like institutional grade um and so we basically use safe modules across the place we it's like the core of our infrastructure and it took us a long time to kind of figure out how it works because the documentation on safe modules is not that great it's like two paragraphs of text and so we had to go through all of the hassle of understanding how to set it up properly and so the goal of this talk was to give all of you kind of like a rundown and hopefully save you some time so that when you want to work with modules you don't have to go through all of the hassle um okay so let's get started um I'll give a brief introduction about what safe modules are in the first place um so most of you are probably familiar with safe uh safe is a multi-sig wallet um and it allows you to have an N Out of um uh Sino Quorum so every time you want to execute an action out of the safe you need a certain amount of sinus to approve the transaction now this is great for security it's not very great for agility because every time you want to execute something you need all of the people to sign the transactions and with big thous people in different time zones that can take a while and it's just a bit complicated so modules are like smart contracts that you can plug into the safe and circumvent the signing scheme so the once a module is approved once the module is added to the save you don't require any more signatures to execute the logic in the module so you kind of can bypass the signing scheme and have automation through the logic of the module so and the logic of the module gets executed from within the safe so the message sender in the external contract call will be the safe itself um so basic diagram you can have an eoa which can be a hardware wallet can be on a server whatever you want the UA calls the module the module calls the save the save calls the smart contract and and that's how it works so why would you use nosy safe modules um most of the dials around these days use safe for treasury management because it's very secure it's decentralized you can have multiple people have eyes on whatever is happening but a lot of the dials end up having very repetitive transactions so dials have to pay their contributor salaries some Dows may do treasury management they may do DCA whatever so when you have these kind of actions that are recurring and that you need to execute every month every week you don't want to go through the hassle of doing the signatures every time and in this case you could just write a module which automates this one very specific action so whenever you have whenever you find yourself executing the same action over and over again out of the safe that's when modules can come in very handy because you can just write the logic for that one specific action and then have it automated um as you may have realized putting literally a backdoor inside your nose is safe can be quite dangerous um so there are some like security considerations that I just wanted to put out there um so the important thing is that the module itself has access to all of the assets inside the Nosa safe so whatever vulnerability you put into your module will affect everything that is on the safe and that's very important so things like re-entrancy attacks need to be thought about carefully because if you have a re-entrancy attack that could drain your entire safe also passing arbitrary function parameters to the modules can be a bit of a problem um because you don't want anyone to put in receiver addresses swap amounts whatever as that then again exposes all of the Assets in the safe same thing with unlimited token approvals if you approve all of the tokens then all of the tokens in the safe are approved and you may have some issues with that the good thing is that modules can be always replaced so you can enable modules you can disable modules so if you have an application that you're thinking about you're not sure what the scope is you can write it with a very limited scope and then you can just disable that module and enable another module and that way you update the the logic um so this is just overview of of modules on a theoretical level um I'll show you some code um it's super straightforward so this is the interface of the Nosa safe contract you can find this at the modulemanager.sol and this is the function that the module will call so this function can be called only by a module that's enabled it will verify that the message sender sending the call is an enabled module and as you can see you can pass it the two address so that's the target of the contract that you want to call out of the save it takes some amount of eth in case you're doing a payable function it takes the call data that you are trying to call on the external contract and it takes the operation so operation can be the call or delegate call I don't really have time to go into delegate calls but if you know what it is and if you need it modules support delegate calls as well um so here just very basic module as an example so this module is only supposed to do one thing and that's buying it with usdc um and and as I said before we should always try to avoid having arbitrary function parameters so all of the important contract addresses are hard coded here so the safe address is hard coded the units for browser usdc address and so on um the path for the swap is also hard coded because as this module is supposed to do a very specific thing and then if we look at the function itself it takes an amount in it takes the slippage adjusted amount out and you can see you can add operators like normal solidity stuff so in this case this module can only be called by an operator um and then to actually do the call to uniswap what we do is that we just encode the function selector for the swap we pass in the the parameters as you can see the path and the receiver address are hard coded so the attack surface is pretty low and then we call that function that I showed before exact transaction from module return data it takes the unisob router as the target address and we pop pass in the call data for the swap so um as you can see like this module does something very basic um even if the operator private key even if the operator private key gets leaked the only thing it can really do is to execute this one function with very specific logic and so to then like further reduce the attack surface we can put in some more restrictions so in this case the operator wouldn't be able to spend more than 100K it wouldn't be able to do the purchase more frequently than every two weeks and so right now this module does one thing it buys ease with usdc it can do it once every two week and it can spend more than 100K so the point of this is that we can automate very specific actions that you would otherwise have to execute manually and especially when you need to do swaps out of a safe it's kind of a hassle because you have timeline you have slippage protection so if designers Take 5 hours to sign the transaction the transaction probably failed and so these are kind of like the use cases in which modules are super useful we have modules for swapping for bridging for all sorts of actions um and then through like writing modifiers in putting restrictions on who can call what you can narrow down the the scope of the module a lot and that gives you like very safe um where a very safe way to automate stuff out of the safe um I'll give a brief note on on the guards so the guards are another feature by the safe and basically what they do is that it's similar to modules where you can write the logic in solidity and then the gold get checked before and after every transaction is executed so instead of doing all of these custom restrictions in the module itself you could have one abstract generalized gold which gets checked every time so just adding it here so you could add like a list of operators that are allowed you could say you're only allowed to call this set of functions with these set of function selectors so chords and modules kind of go hand in hand and they are very strong together [Music] um whoops my memes disappeared I'm sorry um but basically the conclusion is that uh the safe modules are super powerful um they're very versatile they are a great balance between security and Agility if you find yourself doing repeated tasks out of a safe you may want to think about using modules to automate it and with as with all other smart contracts just security is very very important um yup so there's some more resources some of the QR codes disappeared apparently so there were supposed to be the documentation for the module docs you can find those if you Google for them there's some source code also you can add the modules directly from the safe UI so that's also not super intuitive but they have a blog post for that um yep so any any questions I went through this a lot quicker than I expected so we got some time yeah yeah so as I said we have like a stable Income Fund in which we do do yield forming um and so for that there's like a set of actions that we repeatedly do like swapping tokens bridging tokens um and then there's like Avi and all of those big protocols that that we use um so that the security or like the custody setup that we have is that everything is held in nosy saves um but then in order to have the agility that you need as a fund doing yield forming you need to like be able to move assets quickly across trains if there's a new opportunity you can't wait too long to get in um and so we have like a whole Suite of different um of different modules that allow us to execute all of these actions out of the safe now it it comes with some extra friction in the sense that you have to develop a module for every action that you want to automate and every time you develop a module you need to like check security of the smart contracts and so on um but if you have like the solidity resources in-house and if you have the people who know how to write secure smart contracts uh this is a a great way to go to go about things thus the module needs to be approved by hypnosis itself or its permission no no so the basically the security model of the module and I maybe skipped this but the security mode model of the module is that designers of the safe approve the module so you write the smart contract you deploy the smart contract and then you go on the north is safe and enable the module as part of the save so the security model is that designers should verify the logic in the module if the signers think that the logic is correct they can add it to the save so if you are a signer on a multi-sig you need to pay very special attention when you enable module because you're literally adding a backdoor to your otherwise multi-sig wallet yep the other question is do you have to build the UI as well because um okay so for example the different models like one inch or whatever you have there is a UI right yep yep so um it depends I guess on the use case that you have like in our case we have like all of the back-end system that do the automation that hold the uas and then we don't really need a front-end because we have like the the back end calling the modules um but depending on the application that you're doing you you may need a front-end any any other questions yep yeah my question is more of agnosis safe question so while you were developing did you encounter any you know any uh tools that they have to help you store um sensitive data so for example you know driven automation let's say there's um there's an external API I need to call and I'm going to go through an oracle for example so to get to that API I'll need to pass in an API key and um uh I'll need to keep that in somewhere somewhere secure that isn't too isn't easily uh retrievable by anyone else on chain so did you encounter any you know any functionality like that with uh safe yep um not not really because they're like the way at least that we think about the modules is that you have like your backend logic that has in our case like the trading strategies um and then the module is just doing the action that you would do from an eua but since we use Nosa safe we don't have EOS for security reasons and so those specific actions get automated through the modules so all of the like sensitive data stays on the back end and then the backend calls the module and tells it hey execute a swap a bridge the assets to optimism whatever so that all the sensitive data doesn't really touch the chain at all it stays on the back end good I have no more questions I'll give the next speaker some more time [Music]