# Being a Responsible Multisig Signer (Verify, Don't Trust!) by Santiago Palladino | Devcon Bogotá

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2023-10-07
- Duration: 08:03
- Watch: https://streameth.org/watch/yt-YKGNcQXtMhg
- YouTube: https://www.youtube.com/watch?v=YKGNcQXtMhg

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/being-a-responsible-multisig-signer-verify-dont-trust/

So you have been trusted with safeguarding a project along with other members of your community, congratulations! But, alas, the first transaction from a developer on the team comes in. How do you proceed? Can you blindly trust the developer? Should you? It's tempting to just see what other multisig members do and roll along, right?

In this talk we'll go over what you can do to verify what a transaction will actually do, and what tools you have at your disposal for this. No coding required!

Speaker(s): Santiago Palladino
Track: Security
Keywords: multisig,verification

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

foreign [Music] 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 uh 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 VIA 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-seal like you only have the multisig becomes 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 we're signing right click you understand what you're saying when whenever you sign something in real life you should do two when dealing with with matching internet money and the important thing is that the tools should be understandable for non-technical people right now multi-seek it's very often that you have the CEO CEO you have contributors to a project that are not not necessarily technical so we want to make sure that they are able to review and understand what they'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 will most likely go 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 valued basically something that we send to it and the proposal in multisig is no different it's basically we are asking our multi-seat 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 a screenshot from the nosy safe here is understand what what it's doing I'm like parsing that and we can see how much money sent we can see which contact we're interacting with and we can see which function is being called now the function may give us more or less information right and the first thing that we can do with this it's pretty obvious like go to the 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 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 sampling Defender block native though for now it's a API only to simulate what would happen if a transaction were executed now granted that will not be the same as when the transaction gets actually executed for instance in swap you may get more or less tokens back later depending on price fluctuations 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 very least you can see where as we're saying 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 the first sign of alarm when we're signing something for instance here in the case of a swap we see that a unitary pool is involved a router the tokens that we're exchanging things that make 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 there is a thing to go through our balances right like if you're if you are doing a swap we would expect that the balances of one token would 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 parse 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 right to someone else to manage our assets anything related to role management to ownership and to upgrades 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 deserves a whole chapter of Their Own an upgrade transaction usually looks more or less like this like calling the contracts and telling it hey can you please upgrade to this new address and the only information we have is literally an address and okay let's simulate 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 whether it's an ether can sourcify the price that the source code is a bit long right this is an actual contract from from the graph that URL wrote you're you're over here and it's like thousands of lines of code spread actually there you are spread across 16 different files like no signer is going to review this what a 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 can trust 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 or not but the problem that we have here is Bridging the Gap between that identifier that version of The Source call 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 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 on the deployment 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 and there is a solution here like it has been in traditional web development for years it's making deployments public reviewable of auditable traceable like just to a deployment to NCI on some on any word 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 easy to understand and to read and embed that information in The Proposal that's being that's being sent to signers so they 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-6 are actually multi that we make use of all the people that are appointing assigners because they should have the tools to be to be able to understand and Dot security to the process by reviewing everything that's happening instead of blindly signing and if this is not possibly a reviewer remember the burden is on the proposal The Proposal 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 assigning 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