 Well, welcome everyone. Thank you very much for coming today. We'll be talking about how to be a responsible signer We'll be focusing on multi six basically because we only have seven minutes, but this applies to pretty much any proposal based governance system So picture the situation that you have a set of smart contracts set of assets that you want to control You manage them via the multi-sig you are one of the signers of the multi-sig and you are presented by this What happens 99% of the time is that no one is going to review this They are going to blindly sign it go ahead and pretty much defeat the purpose of the multi-sig like you only have the multi-sig becomes a Basically one out of an wallet where just a proposer gets whatever they want approved the scope for today Is go through a series of tools or techniques that we can do to actually verify understand what you are signing, right? Like you Understand what you sign when whenever you sign something in real life You should do too when dealing with with matching internet money And the important thing is that the tools should be understandable for non-technical people right in a multi-sig It's very often that you have the CEO CEO You have contributors to a project that are not necessarily technical So we want to make sure that they are able to review and understand what you're assigning So we'll begin by understanding the transaction understanding what's in a proposal and for that we'll go to first there It is so we'll start by going on. Okay. What's actually in a regular ethereum transaction, right? So we have a recipient we have something that we call usually contract that contract will do stuff We'll most likely call into other contracts We have a piece of data where we say hey we want you to execute this this and that in this case for instance a swap and We may have a value basically something that we send to it and the proposal in multi-sig is no different It's basically we are asking our multi-sig contract to be calling to be calling another contract with some information and Optionally with some money So they catch the first thing that we can do is this is actually screenshot from the noses a few Is understand what it what it's doing and like parsing that and we can see how much money sent We can see which contract we're interacting with and we can see which function is being called now the function May give us more less information, right and the first thing that we can do with this It's pretty obvious like go to documentation every serious project has a documentation attached to it and will tell us what the function will do That way we can actually see that that swap exactly for tokens what it's going to do what the each argument to it is Representing actually understand what we're approving But you guys are not here so that they tell you to read the freaking manual So we'll look into some more interesting stuff something something very very powerful. We can do is simulate the transaction So we can use different tools tenderly open suppling defender block native though for now It's a piano API only to simulate what would happen if the transaction were executed now Granted that will not be the same as when the transaction gets actually executed for instance You can swap you may get more or less tokens back later depending on price for activations, but it gives you a pretty good idea, right? And the idea is that a simulation will give you different information, right? It will tell you which contracts were involved state changes or events So in terms of contracts at the release you can see where as we're saying a couple minutes ago One contract can call another and another and basically have different different effects on the chain And so by spotting if there is any contract that shouldn't be there That's a first sign of alarm when we're signing something for instance here in the case of a swap We see that in is a pool is involved the router the tokens that we're exchanging things that makes sense If we are feeling a bit more adventurous, we can also look into state changes We can see okay. How each of these contracts involved changed probably the easiest thing to go through our balances, right? Like if you're if we're doing a swap, we would expect that the balances of one token will go up Another one would go down and again. We can see if there are any funky things there usually state however, it's Difficult to parts or to understand so the main thing that we want to look to look at our events So any reasonably designed contract will emit an event whenever something interesting something important happens So there are a bunch of events that should immediately catch our attention when we're reviewing a transaction Namely a transfer moving assets from one place to another an approval, which is giving rights someone else to manage our assets anything Related to role management to ownership and to upgrade and events will have some extra information that we can look into to get Better sense of what's happening Now speaking of upgrades this pretty much deserve a whole chapter of their own an Upgrade transaction usually looks more or less like this like calling the contract and telling it Hey, can you please upgrade to this new address and the only information we have is literally an address Okay, let's simulate when now we have something new on our toolbox. We can see what what it's like Sure the simulation will tell us. Yeah. Yeah, the implementation is moving to this new address and that's all the information we have Now that's that's a problem right like what what information does an address carry for sure The address should have a verified source code associated to it. Well, it's an ethers can source if I But the price that the source code is a bit long, right? This is an actual contract from from the graph that you are ill wrote your you're over here And it's like thousands of lines of code spread across the area spread across 16 different files like no signer is going to review this What the signer can review and can understand is this It's a report that they get from an auditor from a set of developers from someone that say hey You know, we have reviewed the code at this version It looks good to me and they contrast that they can they rely on that and that's what they should be using for making A decision whether they want to upgrade to another version of now or not But the problem that we have here is bridging the gap between that Identifier that version of the source code and what gets deployed at an address, right? So we know that there are a couple of steps involved We have the source code that gets compiled into them into a binary artifact And that in turn gets deployed to a particular to a particular address. So what we want to do is make this process transparent granted we could ask reviewers to write them to run a script like this and try to replicate the compilation and the employment but we're trying to give the tools to reviewers that are not technical to be able to do this and Let's tell the truth like even developers are not going to do this Like the and there's a solution here like it has been in traditional web development for years It's making deployments public reviewable auditable traceable Like just do a deployment on CI on some on anywhere that's public that anyone can go there can see hey This version of the source code has triggered this build that was deployed at this address Make it transparent and this is to understand them to read and embed that information in the proposal That's being that's being sent to signers so they can understand that they can bridge that gap from source code To an address with the code that they are approving an upgrade to So all in all what I'm pushing for is to make sure that multi six are actually multi that we make use of all the people That are appointed as signers Because they should have the tools to be able to understand that security to the process by reviewing everything That's happening instead of blindly signing And if this is not possible a reviewer remember the burden is on the proposer the proposer of something needs to give you Give you as a signer all the tools that you need to be able to review and fully understand what you're signing If that doesn't happen you go back and you ask for as much information as you need to be able to understand What's actually happening? Thank you