Secure Governance for DeFi Companies

Transcript

and that counts down. So, uh please do stop when it hits zero. >> All right. Yeah, it's all yours. >> Okay. Hi everyone. So, we're going to talk about secure governance uh specifically about multi-seek transactions which is um the main part of the governance on on a blockchain based company. Uh I'm the CISO at Insuro and I'm mentioning this because we are an actual blockchain based company operating for the last the past four years and we use this a lot. So this is a set of tools that we built. Uh and the the problem we're trying to solve is uh that blockchain protocols evolve. We have to deploy new smart contracts when a new customer is on boarded. So we have configuration changes, we have permission changes and we have uh fonts being moved around and um the way that

uh the safe UI shows these transactions is hard to review. Uh especially for a nontechnical user which is the one that we um the ones that are authorizing uh these transactions on our company are not all technical. Uh so our CFO authorizes transaction and he's not technical. Our CTO authorizes transactions and he is technical and he can read this call data and probably figure it out. but the CFO can't. Uh so that's a problem we were trying to solve. Uh and the way we do this is uh first of all we defined um a chain set which is the definition of a multisig transaction that we want to execute. And here we say okay this is going to run through this uh specific multisig. This is going to be to use a time log and the delay uh defined for that time log. Uh and this is going what's going to be run

right this step. This is going to be a a contract function call with these parameters and the parameters are an address which is uh expressed as an address alias and uh and an enome in this case and it's expressed as the value in the denom not as a zero or a one or a two or whatever uh index in the enum corresponds. Uh and then and this is probably the the most useful part of it all. uh we can define tests right there in the chain set right there in the in the multisig transaction definition and these tests are run before sending the transaction to the safe multisig uh for sign in uh this is the first part and this uh can be created this chain set can be created by a nontechnical user it it's not very difficult it's a very simple format it

can be uh created by an intern and can be created by a junior member of the team or it can be created by an LLM uh once we have this uh this is goes on a pull request on a GitHub repo because this is code in the end. Uh it goes through a review process and once it's approved there's a workflow in a GitHub actions in our case that creates the safe multisc proposal and that's the only permission that's that this uh action has. uh it's a delegator on the multisc. So it can only create transactions but cannot sign them and the one the person that created the changet has no permissions at all on the multisig only our workflow. So this creates a proposal on safe multisig uh and of course we were still having

the problem that when uh the users the signers were ready to sign this they were seeing this called data especially when there were time log and other uh complex contracts in the middle. Uh so we also created a safe UI app that is integrated into the safe UI that shows this friendly uh definition of the transaction uh which comes from the manifest that we saw before and uh and from some intermediate artifacts of that and shows uh step by step what's being executed. It shows the TX hash and this is very important because uh on safe there's several ways you can sign the transaction. You can sign an EIP712 uh strct uh but that's very difficult for a non-technical user to understand or you

can just sign the hash as a text and that's what we are using for signing and a hash is easy to verify to any user right you use your eyeballs and you uh check that the hash you are seeing on your wallet for signing on your hardware wallet for signing and the hash that you are seeing on the UI is the same besides that we also have uh notifications on our discore internal discore messages service uh and it also shows a hash and it also shows the the detail of the transaction that's going to be executed. This serves more of a as a as a call out. You know, hey, you have this uh proposal, this transaction to sign, but it also works uh as a second or third check because the hash that's being

shown here, the safety x hash being shown here is generated independently from what's being shown in the actual safe UI. So a hacker would have to compromise three different uh parts of code, three different systems uh to compromise us. We actually added this after the by bit hack analyzing how the by bit had happened and how we could avoid it uh with our uh tooling. Um so yeah, this is kind of it. Uh we just wanted to show these tools. Uh we want to make these tools available. Actually the safe UI app is already open sourced and the rest of the tools for creating the transactions and running the test and all of that. Uh we can make them open if anyone is interested. We just need to put in some work to extract

it from you know from our system and open source it and then uh as next steps we're planning on adding uh in browser verifications or even running the test right in the browser. So if you trust the app, you trust uh what you are seeing uh here and then you can deploy the app on IPFS or some static uh hosting and uh and you can trust it that it doesn't change. Uh maybe ENS support because right now we are using uh an internal address book like a mapping from names to addresses uh using ENS would be really cool. So yeah, here you have my contact information. If if you're interested in this, you can find me up there in a little bit and uh you know contact me here. Thank you.

Cool stuff. >> [applause]