Shebin John from Safe on Operational Security for Onchain Treasuries

What we discuss with Shebin John
Operational security is becoming the biggest priority in crypto, here’s how top teams protect their onchain treasuries.
Safe is the gold standard for smart contract wallets, securing over $60billion for organizations like the Ethereum Foundation, Optimism, Polygon, Chainlink, Morpho, and ENS.
In this episode, with Shebin John, Research Engineer at Safe Research, we explore how they’re building the next generation of treasury security, bringing approvals, spending limits, and segregation of duties directly into smart contract wallets.
Shownotes
- (0:00) Coming Up
- (2:42) Thank you for Episode 100
- (3:41) Onchain treasury security challenges
- (5:50) Safe Modules and Guards
- (9:32) How Guards Work
- (10:59) New feature with Spaces
- (13:43) Delegate call overview
- (16:11) Guardrail protection explained
- (18:28) Get 2 months for free with Request Finance
- (20:08) Fiducia & co-signers
- (24:58) Policy Engines
- (30:55) Implementing Policy Engine
- (32:51) Zodiac’s Role Modifier
- (34:52) Safe Research’s vision
- (38:01) Other Safe projects
- (39:42) Adoption hurdles
- (41:25) Implementation barriers for finance teams
- (42:59) Concluding thoughts
- (45:35) Reach out to Shebin
[00:00:00] Shebin John: Let's say that without the Policy Engine, yes, you can batch transaction with Safe wallets, but then you have to check which address you are sending it.
[00:00:09] Shebin John: What is the amount?
[00:00:10] Shebin John: These kind of checks has to be done manually by a human.
[00:00:15] Shebin John: The second case of transaction was the DeFi processes.
[00:00:19] Shebin John: Again, the same thing happens.
[00:00:20] Shebin John: You need to check which protocol you are interacting with.
[00:00:23] Shebin John: You need to check what you are calling, and you also need to specify like the correct parameters and correct values.
[00:00:29] Shebin John: So these are some of the things which has to be done very meticulously by a human checking one by one.
[00:00:37] Shebin John: Now here comes the Policy Engine.
[00:00:39] Shebin John: For the first one, we have something like an employee salary policy. So let's say that your employee is earning X amount, any amount which is being tried to be sent by the Safe to a certain set of addresses, above X, it'll get flagged.
[00:00:54] Shebin John: The second case was with DeFi, and let's say instead of lending, you did the borrowing or the other way around.
[00:01:01] Shebin John: It's a mistake which can happen from the human side of things and that we want to avoid, and which in this case we can have like a DeFi policy where we specify these are the functions which we should call.
[00:01:15] Shebin John: These are the particular parameters.
[00:01:17] Umar: Safe is the gold standard for smart contract wallets on EVM chains. It's open source, permissionless, non-custodial, and free to use.
[00:01:27] Umar: With a TVL of $65billion, it's used by some of the biggest web3 projects, including the Ethereum Foundation, Aave, Optimism, Morpho, Polygon, and Chainlink.
[00:01:39] Umar: My guest today is Shebin John, Research Engineer at Safe Research, the R&D arm of Safe.
[00:01:47] Umar: Shebin and his team are focused on designing the next generation of on-chain treasury security, providing frameworks that embed the same principles we know from traditional finance, like approvals, spending limits, segregation of duties directly into smart contract wallets.
[00:02:05] Umar: In this episode, we'll unpack the evolution of Safe's security stack from Modules and Guards, to Guardrails and the new Policy Engine and explore how these tools empower organizations to manage funds on-chain without compromising self sovereignty.
[00:02:23] Umar: Shebin, what are some of the biggest security challenges web3 teams are facing today when managing on-chain treasuries?
[00:02:31] Shebin John: There are like few different things which comes to my mind, and mainly I would say there are three things.
[00:02:43] Umar: Before we jump into this episode, I just want to see a big thank you.
[00:02:47] Umar: Today's Episode 100, a number that honestly felt impossible when I first started this podcast four years ago.
[00:02:55] Umar: This podcast has genuinely changed my life, and I hope it's helped you deepen your understanding of web3 accounting and finance along the way.
[00:03:04] Umar: Without this podcast, none of what we've built would exist, not the courses, the Crypto Account Academy and the Crypto Treasury Management Academy, and also not our newly launched community platform, which I definitely recommend you to join.
[00:03:19] Umar: So thank you again. I hope I get to keep serving you for many more years.
[00:03:25] Umar: And if you haven't already, it would mean a lot if you could like and subscribe wherever you're listening.
[00:03:32] Umar: Now enjoy my conversation with Shebin.
[00:03:34] Umar: Shebin, welcome and thanks for making the time to be here.
[00:03:38] Shebin John: Thanks Umar for having me as well.
[00:03:40] Umar: To start off, I'd like to take a step back and look at the big picture. Now, most of this episode will focus on the features Safe has developed to protect users interacting with smart contract wallets for treasury management, while still maintaining their self sovereignty.
[00:03:59] Umar: Today, the two most widely used solutions are multisig wallets like Safe of course, and MPC wallets and each come with their pros and cons. So I want to ask you Shebin to start, from your perspective, what are some of the biggest security challenges web3 teams are facing today when managing onchain treasuries?
[00:04:20] Shebin John: Sure. So I wanna answer it like there are like few different things which comes to my mind. And mainly I would say there are three things. And the first one is that there are still teams which uses like an EOA in a cold storage and using that as a treasury, which is highly risky in my opinion.
[00:04:38] Shebin John: 'cause there is just a single key, which is storing all your assets of a particular DeFi or a particular protocol and the second one would be like using some unmetered or unaudited contracts. There are some which they build on in-house and might not be as secure as something which is audited by several people.
[00:04:58] Shebin John: And, being viewed by a lot of eyes. The third and the most biggest one, I would say is the human element of these things. Whenever you do a transaction, someone has to propose it. And a person has to look at all the parameters, like the addresses, the transaction, where it's going to happen what the parameters are.
[00:05:21] Shebin John: Then someone has to vet it, like verify it, check it. These kind of things happen sometimes, on a regular basis, which also brings up the human fatigue part, which makes them overlook some of the things. So these are the, some of the things which I think are the highest, I would say, in terms of operational security risks when you are dealing with a good amount of money through on chain crypto treasuries.
[00:05:49] Umar: Great. Now the listeners of this podcast Shebin, they're mostly working in the finance function of web3 organizations. A lot of them already familiar with Safes multisig wallet, but maybe if there are some listeners who are, who don't know what Safe is, let me quickly explain what that means.
[00:06:06] Umar: So an externally owned account, like an EOA wallet, like MetaMask, which most people use personally isn't really suited for organizations and you just went through that Shebin. And that's because it relies on a single private key to execute transactions. And if that key's lost or compromised, your funds are gone.
[00:06:25] Umar: Now a multisig short for multisignature wallet, it solves that problem by requiring multiple private keys to authorize a transaction. It's similar to a company's bank account that needs multiple bank signatories before a transfer is approved.
[00:06:41] Umar: So with Safe, if you can define exactly how many approvals are needed before any funds move and as many in the industry say, Safe has become the gold standard for multisig wallets on EVM chains. I said in the intro, it's open source, it's permissionless, non-custodial, but also it's free to use.
[00:06:59] Umar: Now Shebin is a Research Engineer at Safe Research, the R&D arm of Safe, and they're working on improving the operational security for on chain treasuries.
[00:07:10] Umar: I wanted to speak with Shebin today to learn more about their Policy Engine, but before we get there, we first need to understand what Modules and Guards are, because as I understand, they add an extra layer of customization and control to Safe accounts.
[00:07:27] Umar: So can we start by unpacking what Modules and Guards are, and perhaps walk us through a practical example of how a finance team might use them say to automate approvals, limit transaction types, et cetera.
[00:07:43] Shebin John: Sure. So Safe in itself has its own implementation of certain things which basically have like some kind of authentication, some kind of adding extra custom code, which is the module part and adding some extra checks, which is the Guard part. So there are like certain things which are like the core engine of it, which we can say is Safe.
[00:08:08] Shebin John: And then we have like these extra parts of the puzzle, which are the module, which let's say for an example, you want to interact with a DeFi application, but you don't want to interact with your own set of owners. You want to, let's say, provide it provide the access to a certain number of people who are like really good with trading and they want to do trading in just Uniswap.
[00:08:32] Shebin John: So you create a module, which takes the signature or takes the authentication from these particular people and you only interact with Uniswap. There is no other way you can interact with anything else. So the module is basically gives you like the extra custom code for the Safe, which gives you interaction availability to interaction with the Uniswap.
[00:08:53] Shebin John: And here what the Guard does is that it checks that, is the Module only interacting with the Uniswap app or like, this is just for an example, any particular protocol or DeFi, and then it checks that are these parameters allowed by the particular owners? If yes, then only this transaction happens. So these two basically provides you, provides a Safe, users some kind of superpower so that they can interact with, let's say a particular thing in a particular way and it's like highly secure in the sense that it's only done by certain authenticated people and it's only interacting with certain interactions.
[00:09:32] Umar: What could these parameters be for Guards?
[00:09:36] Shebin John: So for Guards, it's like every transaction, whenever it happens, you provide few different things.
[00:09:43] Shebin John: One of it is the address which it is interacting with. One of it is like, which function you want to call. Let's say that in Uniswap you only want to do liquidity providing works. You don't want to swap anything. So in the Guard you will mention that any transaction which goes through this module should only allow liquidity provision not swapping.
[00:10:03] Shebin John: So the person who is doing this type of investing, they will only be able to do the liquidity provision part like and nothing else. And the advantage is that we know that now that we have specified that it should only happen with Uniswap. You cannot use it with any other DeFi protocol. Now, let's say that you want to add another one, let's say Aave, and you want to add just the lending part of it, not the borrowing.
[00:10:26] Shebin John: You can again specify it in the Guard thing, like, yes, I want to interact not just with Uniswap, with the liquidity portion, but also with Aave with the lending then what happens is that when the transaction goes through, it'll check either this or that. Is this happening? If yes, let's go forward with the transaction.
[00:10:44] Shebin John: If not, sorry. This transaction cannot happen even with the authenticated thing. So it's like a double extra layer of security, like the Guard, the name itself, it's, is basically protecting you are Safe from these kind of unauthorized transactions.
[00:10:57] Umar: Great. That's very clear. For people familiar with Safe, when you create a new Safe account, that would be, that account would be chain specific. You would assign the different signatories in that specific account, and you need to navigate to your dashboard to switch between accounts. I saw that Safe launched a new feature called Spaces currently in Beta.
[00:11:18] Umar: Can you explain what Spaces are?
[00:11:21] Shebin John: Sure, Definitely. So, Spaces basically provides let's say an organization which has like multiple Safes. Usually a person who or company who uses Safe. They usually have multiple Safes for different requirements. Maybe some of the Safe is only for employee payments but some of them is for vendor payments, maybe some of it is for the DAO treasury.
[00:11:43] Shebin John: So these are all different Safes which might have like one of the same signers, including other signers, but you as let's say a CFO will have access to all these Safes as a one of the signers in the NFM setup. And then you have to now let's say do some transactions in one Safe, then have to do something in other.
[00:12:05] Shebin John: It's become a lot of cumbersome operation, I would say, and to make it easier based on Safe's user feedback and these things. We usually try to improve our setup every now and then. And what happen is that we got the user feedback that they want to have all these things to be handled in a single space.
[00:12:26] Shebin John: And that's the name Spaces comes from. And it's like we can now handle all these Safes in a single space and we can do some transaction, we can select which Safe we want to do the transaction, we can select the token and all those things. So it makes it easier for, let's say, a CFO to interact with multiple Safes, which they have in their control, and you can do the operations, which you wanted to do.
[00:12:48] Umar: You would still have to go to that specific Safe account to add the bank signatories. Like you could not allocate the same signatories across multiple Safe accounts, right? You have to do that individually.
[00:13:01] Shebin John: So, l let's say that you as a CFO has one of the signing keys and you are you can add all these Safes into a single Space. And if, let's say that you want to do a employee payment where you also have to sign it someone else proposed, might have proposed it, but you only have to sign it, then you will see that transaction in your wallet, your Safe wallet UI, and you can just sign it. And let's say that for the vendor payment, but you are initiating it. You can also do that in the same Space because the, that particular Safe is added to that particular Space and you can just select the Safe the particular vendor you want to pay and the amount you want to pay.
[00:13:37] Shebin John: So it's all in the same single window, I would say, which makes it much more easier for the CFO.
[00:13:43] Umar: Alright, so now let's move from Guards to Guardrail, new feature of Safe. So Guardrails, they had an extra layer of protection to your Safe by restricting delegate calls. Now, delegate calls is a technical term.
[00:13:58] Umar: I'd like to break this down for the listeners. So imagine your web3 project managing your treasury through Safe. You set up your Safe with multiple signers, say like a 3 out of 5 approval. That's your baseline control. Now to make treasury operations run smoother, you might install modules that extend what you Safe can do that we went through earlier.
[00:14:19] Umar: But before we continue, I'd like you to maybe explain what delegate calls is.
[00:14:26] Shebin John: Sure. So for delegate call let's say that there are two ways where a transaction can happen. One is the basic call where when you interact with a contract, the changes happens in the contract itself, not your own contract. So to give you an example, let's say that you are interacting with Uniswap to provide liquidity. When you do a transaction from your Safe wallet to Uniswap, what happens is that you send the particular amount of tokens or ETH whatever assets you want to send. And the changes happen in the Uniswap contract where the assets get updated that yes, Umar has provided this amount of liquidity.
[00:15:02] Shebin John: But what happens when you do a delegate call to, let's say a contract, the call happens from Safe to that contract. But the changes happens in the Safe contract itself, like the storage of Safes contract.
[00:15:15] Shebin John: So to give you an example of a legit usage of delegate call, we use Safe migration for, let's say from 1.3.0 to 1.4.1 version. So the Safe currently the latest is version is 1.4.1, and a prerelease of 1.5.0. So let's say that you have a Safe wallet of 1.3.0 and you want to upgrade the version of Safe to 1.4.1, you need to use a Safe migration contract, which we have wrote and we have audited it, and we use that with a delegate call so that you can basically update your implementation so that change happens in your contract, not the Safe migration contract. So, delegate call basically means that whenever you make a call whenever make a delegate call, the changes happens in your own contract. But whenever you do a normal call, the changes happens in that particular contract. So that's the basic difference when you when it's a call and a delegate call.
[00:16:11] Umar: Great. So now you've explained delegate call. Can you now explain this protection mechanism called Guardrail that you guys have built and how this works with the whole process of managing treasury on chain.
[00:16:24] Shebin John: Sure. So, Guardrail is one of the initial version of a Guard, which the Safe Research team has worked on as a three part system.
[00:16:33] Shebin John: The first one is the Guardrail, and the intention with the Guardrail was to make sure that your Safe, doesn't allow any kind of delegate call, which is not authorized by you, specifically with the particular time delay and it is created in such a way that it is so easy to use that you just have to activate the Guard and that's it.
[00:16:54] Shebin John: There is no configuration required or nothing to follow up unless you want to do some specific things. Yes, that's like for advanced users, yes, you can use some changes, but for a normal user like me and you, if we just want to have protection against delegate call, just activate the Guard and that's it.
[00:17:11] Shebin John: There is nothing special to be done in that. And what it does is that, let's say that someone tries to do some delegate call transaction in your Safe and you sign it, the Guard basically stops even with your signature that no, this kind of transaction is not allowed in the Safe because you have specifically told me not to do this.
[00:17:31] Shebin John: And if let's say that this is something which you wanted to do and you are knowingly doing this, you can basically add that configuration in the Guardrail. Say, let's say that you want to do a Safe migration, which is a legit usage of delegate call. Then you specify in the Guardrail that, yes, I want to use Safe migration, configure it, wait for a particular time.
[00:17:50] Shebin John: This waiting period is specifically mentioned in the Guard so that the owners has enough time to react to any kind of illegal or not required delegate calls. So this is specifically spec, mentioned in the Guard- that there is a time delay whenever you have to add a configuration so that there is enough time for the owners to react to it.
[00:18:12] Shebin John: And when the delegate call happens. The Guardrail checks, is it an allowed list of contract to interact with? Yes. Then sure, you can do the delegate call. If, no, sorry, you cannot do the delegate call, even if there is this number of signatures from the owners.
[00:18:28] Umar: Before we continue, let's take a quick commercial break from our sponsor.
[00:18:32] Umar: If you're serious about running your business using crypto, you need tools built for crypto. One of my favorite apps, and yes, one that I use multiple times a month is Request Finance. This app has been a game changer in how I invoice my clients and receive stable coins and crypto directly in my wallet.
[00:18:52] Umar: But hey, there's so much more to it.
[00:18:55] Umar: Request Finance is the all in one platform for crypto operations, accounts payable, accounts receivable, expenses, and even accounting. Plus they've got a killer multi-payee off-ramp to over 190 countries, meaning you can pay someone with crypto and they get fied in their bank account.
[00:19:15] Umar: Request finance connects to over 20 blockchain networks, including Ethereum, Solana, Base, Arbitrum, Near, and more.
[00:19:25] Umar: Here are some features that I love. Batch payments using your preferred wallet of choice. A single dashboard to track all invoices with real time updates. All invoices contain the transaction hash for easy audits.
[00:19:41] Umar: But hey, don't take my word for it. Try it out for yourself. Head over to request.finance/partners/theaccountantquits and get two months for free with all the pro account features.
[00:19:54] Umar: Join 3000 finance leaders today using Request Finance and make crypto operations simpler, compliant, and less stressful.
[00:20:07] Umar: Great. So we started our conversation today by going through what a multisig wallet like Safe does. A lot of the listeners already using Safe. Then we went through Modules and Guards. Just now we went through Guardrails.
[00:20:20] Umar: The next topic is on a feature called Fiducia. So a lot of this podcast today has been prepared based on the excellent articles that the Safe team has published, and I read this article titled 'Fiducia - Onchain Trust Rules and Co-Signing' where Fiducia is described as the next evolution of Guardrails for securing on chain treasuries.
[00:20:43] Umar: So Fiducia introduces more on chain control over what a Safe can interact with, what actions it can perform. And also there's the optional co-signer support to verify sensitive transactions. And this seems to be like the hallmark feature being like the co-signer, which adds an extra layer of oversight.
[00:21:06] Umar: Can you walk us through what Fiducia is and yeah, explain in simple terms, how it works, and why the co-signer concept is an important step forward here.
[00:21:18] Shebin John: Sure. So to explain Fiducia I will break it down to two different parts. The first one, what Fiducia as a Guard does and what co-signer does in the presence of like a Fiducia Guard.
[00:21:31] Shebin John: So the first one being Fiducia as a Guard, like initially I said that any transaction you do, you have to specify a few parameters definitely. One is which contract you are interacting with. Second one is like what function you are calling. And the third one is what the parameters are.
[00:21:49] Shebin John: So to give you like coming back to the previous example of Uniswap, so let's say that you want to interact with Uniswap, the contract address would be the Uniswap official v3 address, the function would be liquidity provision, the parameter would be the assets and the amount you want to transfer. So what Fiducia does is that, Fiducia basically takes these three parameters like the to address, the function and the parameters and specify that, yes, these three values make a set single thing.
[00:22:19] Shebin John: And this is the only transition which can be happening on Safe. So what it does is that it basically gives you fine grain control over what transaction to be done with Safe and when you can also specify based on the parameter, if there is something, specific and the function it's called a function selector, which is the technical term, but just, to let you know like it's the function, let's say the liquidity provision and these kind of things makes it easy for someone to say that, yes, my Safe will only interact with these kind of functions, these kind of contracts, and with these parameters and nothing else. So it gives a, let's say in a realistic example, a CFO more trust on a Safe that yes, that particular, Safe can only interact with, let's say, a set of DeFi protocols and nothing else.
[00:23:10] Shebin John: So if, let's say that I try to do something like let's say not a it's a DeFi process, but let's say an airdrop claiming, but it's not approved in Fiducia, then it won't happen and it might actually save you because that might have been a fake claim or something like that. So only DeFi processors should happen.
[00:23:28] Shebin John: And this is again, an example. If we say that only DeFi process should happen that is the only transaction which can execute through a Safe if the signature is there. And the second part of the, this is the co-signer network. So what we envision with this is that. Let's say that there is a new protocol in the market which you haven't interacted personally, but you have heard like good things and they are audited and they're like really good, in terms of whatever you want to do in terms of DeFi and you want to interact with it, but you are not sure.
[00:24:01] Shebin John: So a co-signer basically signs extra, it's like a extra stamp of approval that, yes, this is fine, you can interact with it. It should not be a problem. This co-signer can be any person, any, another multisig can be a network of validators. It depends on it. And we, in the Safe Research team has done it in such a way that anyone can it's an open source project so anyone can contribute to it.
[00:24:27] Shebin John: They can create their own co-signer network. They can create their own checks and all. So it is basically giving you giving the developers a way for people like the CFOs and the other operations analyst and all those people, a way for using these kind of technology, which makes their life easier because now you do the checks, yes, but you also get another pair of eyes to check these kind of values, which ensures that yes, this might be a good transaction and you can move forward with it.
[00:24:58] Umar: Great. So now this brings us to the most advanced Guard system, yet built by Safe, which is called Policy Engine. And actually it's after reading this article that I reached out to you guys at Safe to record this episode because I think the potential here seems genuinely substantial. I think the best way to explain Policy Engine is what you've been doing so far. Shebin is like going through example, so. Let's take a hypothetical scenario of a DAO. They have monthly payroll vendor expenses. They're transferring on a monthly basis to centralized exchanges. They're deploying funds into DeFi protocols on a monthly basis. Can you walk us through how that treasury might operate, let's say, without the Policy Engine first, the pain points and security risk, and then contrast it with how things would look like when the Policy Engine is in place.
[00:25:53] Shebin John: Sure, definitely. So let's say that you have a treasury and a part of the treasury is allocated for like employee payments. So, you have to pay every employee on 30th that this amount of money and every employee has certain amount of salaries you have to provide. Then you also do some transactions with a DeFi protocol, a particular DeFi protocol so that you can get some yield from your assets.
[00:26:23] Shebin John: And let's say that you also sometimes, let's say, claim some airdrops or do some transaction with a new protocol because there is some kind of partnership or something like that. It depends on it. So these three are like three different use cases of transactions, and we can go one by one with each of them.
[00:26:42] Shebin John: So the first one, we know that this has to happen every month. We know that there are certain amounts for each and every one of the employees, which may not be the same because of different positions or different rules. And then let's say that without the Policy Engine. When you have to do it, yes, you can batch transaction with Safe wallets, but then you have to check which is the to address like which address you are sending it, what is the amount.
[00:27:13] Shebin John: You also have to check which token you are sending because sometimes some tokens have different decimal values and it basically messes up your transaction. These kind of checks has to be done manually by a human, and there is no other way around it. The second case of transaction was the DeFi processes.
[00:27:33] Shebin John: Again, the same thing happens. You need to check which protocol you are interacting with. You need to check what you are calling you are not calling something wrong or something not intended and you also need to specify like the correct parameters and correct values. So these are some of the things which again, has to be done very meticulously by a human checking one by one.
[00:27:56] Shebin John: And then the third case is completely wild card because you don't know what you sometimes you are interacting with because you know it's a new protocol, but you are not that technically aware what it is being doing. And, but you still want to interact with it because you know that they are a partner of you or something like that.
[00:28:14] Shebin John: So these three requires some kind of human knowledge in terms of technical part of it, not the financial part of it, and sometimes not everyone is equipped with that information, which might require which might be helpful for doing that transaction.
[00:28:31] Shebin John: Now, here comes a Policy Engine. What it does is that it has three different policies for each of them.
[00:28:36] Shebin John: So let's say the, for the first one, we have something like a transfer policy or a employee salary policy. What it does is that it has a set of range that only this particular range of amount can be sent. Nothing higher than this. So let's say that your highest employee is earning X amount, any amount, which is being tried to be sent by the Safe to a certain set of addresses above X, it'll get flagged.
[00:29:02] Shebin John: It won't go forward because that is the amount of range you have mentioned. So even if there is a human mistake or a human error, this will get caught because it won't happen with this.
[00:29:13] Shebin John: The second case was with DeFi, and let's say that these are with correct DeFi process, like they are like legit ones, but you sometimes instead of lending you did the borrowing or the other way around, it's a mistake which can happen from the human side of things and that we want to avoid, and which in this case we can have like a DeFi policy where we specify these are the things which should happen. These are the functions, which we should call, and these are the particular parameters.
[00:29:44] Shebin John: And even these things can be customized based on some code, which was which we can implement by our own, or we can use a developer for it. But once developed, we can use it multiple times. You don't need a developer to help you in this part. And the third case is the wild card where the co-signer part comes in.
[00:30:03] Shebin John: A co-signer can be someone who is an expert in these protocols and these functions and they basically vet this thing. So you sign it? Yes. But the co-signer also checks if this is the correct intention. And based on this, you can get a signature from them and then the transaction goes in. So in each of these, there are like a second pair of eyes or a second pair of checks being done and the like.
[00:30:28] Shebin John: I want to clarify that it's not that the Guard just because of Guard, we should stop reviewing transaction. No, it's like a second pair of thing. It's like helping you achieve operational security. Not to avoid operational security. So you should do your transaction checks and all the things, but it's, if there is any slippage from your side, it'll get caught in these Guards and it'll help you out to not execute these transactions.
[00:30:54] Umar: Now, let's say there's like a finance professional listening to you right now. They're already using Safe, they're already batching transactions every month and using like the Safe multisig wallet. And they're listening to you and they're thinking, this seems interesting. I want to implement this Policy Engine.
[00:31:12] Umar: How technical is the implementation? How should they go about, could you provide us a walkthrough of that and where should they start? Sure,
[00:31:21] Shebin John: Definitely. Safe Research has been doing this like the first step towards it, like we have like three Guards right now, which is one first one is Guardrail, which is the simplest one.
[00:31:31] Shebin John: Fiducia, makes a step up from Guardrail. Then builds something over it. We have the co-signer network attached to it. Then Policy Engine is like the holy grail of Guards where everything can be checked and verified and all the things. And we do understand that user experience and user interfaces are one of the top security challenges in web3 as well.
[00:31:50] Shebin John: So, what we from the Safe Research team had did is that we created a Safe app, which you can use to interact with these Guards. You can activate it and for Fiducia and Policy Engine, You can also configure it. Right now, it's just a click away. Like you can just add the Safe app in your Safe Wallet UI and just, it's a custom app and it's open source.
[00:32:12] Shebin John: You can check the code and all the things and you can just activate the Guard. So for a non-technical person, it would be easier to activate the Guard and check the things. But to move forward it's like, as it's a research project we encourage other developers to build more policies so that it can be helpful for the CFOs and the accountants to like do more things with it.
[00:32:35] Shebin John: Right now, it's like the first starting step towards this, and we have been seeing some improvements even in general for like Guards and Modules being used in the Safe ecosystem overall. So we hope that this becomes a lot bigger things in the coming time.
[00:32:51] Umar: Now back on episode 83, I had interviewed Jack Gale.
[00:32:56] Umar: He was formally working or contributing at kpk, and we talked about Zodiac roles modifier developed by Gnosis Guild team. It's a project within the Safe ecosystem. Now, kpk is an, they are an on chain asset manager. They use the rules modifier to define specific permissions for their treasury management service that they provide.
[00:33:19] Umar: Essentially allowing them to act as an agent. Since that project is also part of the broader Safe ecosystem, could you walk us through how the Zodiac role modifier differs from the Policy Engine, and maybe in what scenario would a project choose one over the other?
[00:33:36] Shebin John: Sure. Great question. So roles modifier basically is a module and the Policy Engine is a Guard.
[00:33:43] Shebin John: So these are like two different parts of it, and both have their own pros in the way that some should use roles modifier when it's like more authentication based systems and some should use Policy Engine when it's like a access control system. So it, that's the major differentiation, which I can see in both.
[00:34:03] Shebin John: Both have their own advantage in the sense that pulse engine can be like fine tuned in the sense that a single policy is atomic in the sense that you can audit it, and that's it. It's tested, audited, and all.
[00:34:15] Shebin John: With the roles modifier. It has an SDK, which is easier for other, developers, not just Solidity developers to interact with it, and they can specify what roles and what kind of interaction has to happen.
[00:34:29] Shebin John: These are like best of both worlds, I would say. And in the best case scenario, you can use both in some way or the other. And it depends on like different projects, how they want to use it and what technical capabilities their team have in terms of integrating with their operations.
[00:34:46] Shebin John: And it completely boils down to what the team wants in that sense.
[00:34:51] Umar: Great. Now Shebin, my next topic is to go through the broader Safes vision. Now, Safe Research, like I mentioned earlier, is the new R&D team formed by core contributors from Safe for which you're currently working as a Research Engineer.
[00:35:09] Umar: I wanna ask you, what was the motivation behind setting up a separate research team? And how do your research results then get integrated into what the product team builds?
[00:35:21] Shebin John: Sure. So Safe Research has our own manifesto in that sense, like we are trying to follow the cypher punk values where we value security, censorship, resistance, privacy, and these are some of the things which we think that. there is a lot more we can do for the entire ecosystem.
[00:35:41] Shebin John: And we have the thought that we have to do it in an open source way, permissionless way. And that's like every guard you have seen up until now, it's all open source. Every code is there in GitHub. You can use it, you can like make the next product based on this.
[00:35:56] Shebin John: It's up to you in that sense and we personally, it's in Safe Research thing that there are a lot more improvements, which can be done in the privacy sector of the transactions. As for the Safe transactions. We are working on different projects. Some of it is called Harbor, which is on the infrastructure side of things for the privacy.
[00:36:14] Shebin John: There are like lot few different projects in the pipeline, which we are doing. And the major focus is on the cypher punk values to be promoted in that sense. And regarding your second part of the question, how it'll all integrate with the product. It's that we are working on as an open source project, as I mentioned, and anyone can develop it.
[00:36:38] Shebin John: Yes. Safe Labs is one of the biggest team we want to target and, but at the same time, we want to be very open source in that sense, Safe has been open source in their ethos from the start. So we as a project has developed these things and now the next developers can actually build, like take it to the next step in that sense and we like, to give you an example, the Policy Engine has initially created like seven or eight policies, which we think are like the stepping stone to understand what the Policy Engine is capable of but now we can, let's say that we want to develop a policy, particular policy for a particular DeFi in a particular way for a particular function.
[00:37:21] Shebin John: It's like very niche mechanism and someone who is interested to interact with that protocol can actually develop it. It's open source and maybe someone also can just create a PR in our GitHub and it gets accepted. So it's very permissionless in that way that any product team can adopt it. And we have seen, like there are some other projects which are either in a way inspired by these changes and inspired by these Guards and Modules, and they create their own, which is also in a way for us, a good victory because Safe ecosystem is building that operational security for everyone around.
[00:38:01] Umar: Great. Now speaking about the Safe ecosystem, I know that there's a marketplace of apps, right? Are there any projects worth mentioning that when they work in conjunction with. the Safe multisig wallet and everything we discussed so far around the Policy Engine, it makes the experience even smoother or even more powerful for the end user.
[00:38:24] Umar: Like previously I've used like an app like Coinshift for example. It's built on top of Safe. There are some of the other apps that connects with Safe like maybe Request Finance, for example, for invoicing. Are there some of these other projects worth mentioning?
[00:38:44] Shebin John: I would say that there are like a lot of Safe apps out there and mentioning one doesn't seem justified because there are like different sectors of things.
[00:38:53] Shebin John: It's not just DeFi processor, like you said. There are like projects which help you in invoicing. There are simple projects which just like airdrop for CSV airdrops. There are also some other projects which let's say that helps you in recovery of Safe there are like literally a lot of Safe apps and even custom Safe apps, not just the ones listed that help you in achieving a lot of things with Safe, which even sometimes we have, we as Safe researcher when we see it, we are like very astonished.
[00:39:23] Shebin John: Like, yeah, this is also happening and we are really happy about this. So. In terms of apps, it's like a lot of ecosystem players are building in that sector. And it's like really happy to see in that way that there are like a lot of things spreading in different aspect of the Safe multisig usage.
[00:39:42] Umar: Great now, so the Safe team is building this robust product to improve security foreign chain treasuries. But my next topic is around adoption and education for web3 finance teams. From your perspective, what's been the biggest hurdles like for web3 finance teams to actually adopt now these more sophisticated capabilities?
[00:40:03] Umar: I don't mean using the multisig wallets because those are already being used, but everything that we've discussed so far. Yeah, how do we educate like the broader web3 community to adopt it? And I mean, businesses.
[00:40:17] Shebin John: Sure. So one of the major hurdles I can see is the user experience and user interface problems which as I mentioned before, like that is something which we constantly at Safe takes user responses and feedback so that we can improve the product further.
[00:40:34] Shebin John: One of the results of that feedback is the Spaces part. And one of the other things is like multi chain wallets, like we have the same address across all the different chains like the same Safe address in different chains. So yes, there is a lot of steps to cover in terms of user experiences and user interfaces problems, and which I think is the biggest problem out there in web3 right now.
[00:40:58] Shebin John: In terms of multisig. But it's like we are trying to take these problems one at a time and trying to solve it especially at Safe and yes, the user response and feedback always helps us in that way. And we, I think are trying to do a good job in that sense and getting also good feedback in terms of that, that yes, we are create like going in the right way on that sense.
[00:41:25] Umar: Because like I mentioned in the beginning, this podcast is mostly listened to by finance professionals who in order for them to maybe implement, like the Policy Engine, Fiducia that we went through earlier, they would require developer support, right? It's gonna be something outside of their skillset.
[00:41:43] Shebin John: Good question. Like, so I would say is that if a person who doesn't have a technical knowledge, but they do want to try it out, there is a Safe app for let's say Guardrail which is safe.dev/guardrail, if I remember correctly. And you can add it as a custom Safe app in your testnet just to test things out.
[00:42:02] Shebin John: And you can see. where the transition gets stopped, which basically gives let's say an accountant or a CFO confidence that, yes, now this is built in my Safe, that I am at least one more step secure in that sense. So I would say that testing out how these things happen. It's not really technical in that sense that you can activate a Fiducia and you can activate a Policy Engine with just a click.
[00:42:25] Shebin John: And I personally have created some demos as well with videos in my YouTube and in my X profile. And you can basically look at it how these things are worked. Yes, there are some technical part of it. I am not disagreeing to that, but it is also easier to set things up and to test things out.
[00:42:45] Shebin John: It'll be like not that difficult, I would say.
[00:42:48] Umar: Perfect. And probably after we finish today, I'm gonna ask you to send me the links to your YouTube videos, and I'm gonna add it in the show notes of this episode.
[00:42:58] Shebin John: Awesome.
[00:42:59] Umar: Now, this was a great episode, Shebin as maybe concluding thoughts. Is there anything else that you would like to share with the listeners?
[00:43:09] Umar: The title of the episode today was operational security for onchain treasuries, or how would you summarize this episode for the listeners?
[00:43:19] Shebin John: So, operational security, I don't think is like a one stop solution. It has a lot of things going around for it. Part of it is human interactions with the Safe Multisig. Part of it is using things like Guards, things like Modules but also you can utilize tools which are available right now, like with transaction verification. What you are doing.
[00:43:45] Shebin John: And there are some articles and some online blogs which you can use to understand some basic things which might help you in the verification part of things. There is a learning curve. Yes, it's a hurdle in that sense. But on the long run, if you are someone who wants to do this on a regular basis, it'll definitely help you out.
[00:44:06] Shebin John: If you are doing these things on a regular basis. And I would encourage everyone to start using some kind of Guard, some kind of Modules to test things out. You don't have to do it on the treasury from day one, but test things out. Get a feel of it, how this happens, what's stopping these things and what is going to give me an extra layer of security.
[00:44:29] Shebin John: In your worst day, it is going to help you a lot. In your best day, you might not even notice it. So I would say that give them some chance it's going to really help you out in the long run.
[00:44:41] Umar: Perfect. Shebin on this podcast before we finish there's like a tradition on this podcast, I like to ask the guests for their favorite quote or maybe a maxim that they live by.
[00:44:54] Umar: Would you have one or is there something that comes to mind?
[00:44:58] Shebin John: I'm a big fan of Batman, so I would say that it's not who I am underneath, but what I do that defines me.
[00:45:05] Umar: Oh wow. Very nice. Shebin, thanks a lot for coming in today. This was an excellent conversation also to, to prepare it. I'd love to, in the future do. more educational in initiatives with the Safe ecosystem. I think there's so much more that people can learn and if people actually want to reach out to you, if they want to learn more about the Policy Engine that we've discussed so far, where should they go?
[00:45:35] Shebin John: You can DM me in my X profile (@Shebitweet). I would be more than happy to help you out.
[00:45:40] Umar: Perfect. I'm gonna share that. Shebin thanks a lot for your time today and we'll be in touch.
[00:45:46] Shebin John: Thank you Umar for having me. It was a great experience.
