Web3 Wallet Security Full Course
Cyfrin Updraft Courses · 2:06:42
Patrick Collins, Cyfrin co-founder and educator, teaches wallet security and transaction verification for users and developers in the EVM ecosystem. The course moves from signer choices and recovery planning to typed signatures, multisignature transaction checks and practical tools for examining what a wallet is asked to authorize.
Speakers
Topics
From Cyfrin Updraft Courses, hosted by Cyfrin.
Transcript
In crypto, everything you do flows through your wallet. And the power of this industry is that you get to have custody of your assets at all times. But with great power comes great responsibility. Which means you as a cryptocurrency owner and an owner of a wallet need to understand what your wallet does. Otherwise, you'll end up like this. So, in reality, it's not that funny and it is very serious and a lot of people do lose a lot of money every year because they don't understand how their wallets work. But because you've shown up on this YouTube video, you've already taken the first steps to rectifying that issue. Now, the only thing that you can do to make your job even better is to actually head over to siphon updraft where we have this curriculum which will always be up to date. One of the issues
with YouTube is that it's very difficult for us to make updates to long videos or long courses. So, if you want to watch this course and make sure you're using the up-to-date content, head over to siphon updraft to watch this course. But, you should leave this on and play in the background so we get the bump from the YouTube algorithm. But, of course, some people prefer to like watching long videos on YouTube. So if that is you, feel free to continue watching here. But for most people, the better learning experience will be over on siphon updraft and I highly recommend you go over there to watch the rest of this course. With that said, without further ado, let's jump in. Welcome to the Cipher Updraft Wallet Basics, where you're going to learn a
highle overview of everything you need to know about cryptocurrency wallets, how to use them, and what to do with them. If you're here, you've already been through the blockchain basics portion, so you've probably already used at least MetaMask, one of the most popular browser wallets. Now, understanding how to work with wallets is one of the most crucial and fundamental parts of working in the cryptocurrency industry because your entire gateway to blockchain is through your wallet. And what's even more important is understanding what wallet you want to use and why. Maybe you want to have your main wallet be something like a MetaMask. Maybe you want to have your main wallet be something like this little device that I got holding in front of my hand here, a little treasure wallet. Maybe you want something big and clunky like a Grid Lattice Plus. Or
maybe you don't trust yourself at all and you want to use something like Coinbase, which would be considered a custodial wallet where they hold on to your money. Understanding the fundamentals of wallets is incredibly important, but the fundamentals are actually really straightforward. And just understanding a couple of highlevel principles will keep you safe from being hacked. In the blockchain space, somebody getting access to your wallet would be the equivalent of somebody breaking into your house and breaking into your safe. And we don't want that to happen. We want to make sure that you stay safe and secure and you understand the trade-offs of working with different wallets and some of the wallet hygiene that goes into self- custodying one of these wallets. So, in this course, you're going to learn the trade-offs of using different types of wallets and hopefully with your understanding of how
the wallets work, it'll let you choose which wallet you want to work with because you're more informed on how they actually work under the hood. So, at the end of this course, you'll be able to choose a wallet solution that works best for you. But then additionally, you'll be able to do what I think is one of the most important things that people who use wallets need to do is going to be verify your transactions. Every time you send a transaction with a wallet, you're essentially signing something. You're saying, "Hey, yeah, I accept that we do this." If you send Ether or Bitcoin or USDC or some other token to somebody else, it's as a result of you signing something on your wallet. Now, if you went to make a deal with somebody for a lot of money and they handed you a contract and they said, "Oh, but uh you
can't read it." Would you sign the contract? Probably not. Well, the same should apply to when you're signing transactions on the blockchain. If you don't understand what a transaction is going to do, you should not sign it. Just this year, a few months ago, we saw the largest hack of all time where $1.4 billion was stolen in a single transaction. And they could have protected themselves against this if they had just checked their wallet to see what they were actually signing. But they didn't. As we go through this wallet basics section, we're going to be going through this wise signer game. application that's going to help train you to actually be able to understand what you're signing. Now, for this wallet basic section, I'm not going to expect you to get through some of the more hard ones because verifying wallet transactions for sufficiently complicated transactions can be really
tricky. However, we are going to make it really clear and really straightforward how you can double check what you're doing for a lot of the straightforward things that most people are going to be using such as sending tokens, interacting with DeFi, sending Ethereum, and the like. For people who want to go the extra mile, highly recommend you go to the qualified signer or the advanced wallets signature course. For anybody who wants to be on a security council, for anybody who wants to be on a multisig, for anybody who wants to deal with finance at a company that works in crypto, you're going to need the qualified signer certification in order to work there so that they know you actually know what you're doing for some of these more advanced transactions. But for our wallets basics course here, we're going to give you the necessary tools that you need to verify your
transactions for most things in the industry and show you what you shouldn't sign or what to at least look out for and then also give you the tools to learn more later if you wish to go the extra mile and learn more about signing transactions. The two takeaways you're going to learn from this are number one have a better understanding of the trade-offs between different types of wallets and what to choose and the number two have a basic understanding of how to verify what you're actually signing when you send a transaction. And then number three, this course is going to set you up for success if you do wish to get your qualified signer certification where you can go from this course to the qualified signer course to actually learn the necessary skills to become a qualified signer so that you can apply for jobs where that
qualification is required. So with that, let's jump in. So let's begin our journey by talking about some best practices. That way you can get the absolute most out of this course and be as effective as possible. Now, you're either watching this on Siphon Updraft or on YouTube. And I encourage everybody to watch this on Siphon Updraft because we've got a ton of features to make the learning experience that much easier for you. So, if you are watching this in Siphon Updraft though, there's a couple links I need you to be aware of. The first one in the top right is going to be the GitHub resources page. This will bring you over to what's called a GitHub repo or a GitHub repository or basically a site that has all the code and all the information and basically all the
materials that you're going to need to learn everything in our curriculum. You could basically think of this as your bible for the duration of your blockchain developer journey. Additionally, in this GitHub, there's a discussions tab right here that you can click on. And in here is where you can ask questions, discuss with other people taking the course, interact with members helping out, and it's where you can discuss anything that you're having trouble with. Then on the other side, you'll see this tab called written lessons. If you cannot stand the voice coming out of my mouth, you can just flip over to that and just read the course curriculum as well. If you prefer the written content over the video content, and it's good to go over to the written lessons anyways to maybe copy paste some stuff. If you scroll down here, right now it's blank, but if
anytime there's an update to a video, something's changed in the video and we haven't swapped out the video yet, you'll see a little updates section with information saying, "Hey, the video says this, but you should do this instead." Now, like I said, this is a very fastmoving industry and sometimes things change and sometimes things need to be updated. So, when you're watching one of these videos, be sure to look for the updates tab at the bottom. And then additionally, whenever you're working with the code that we're working with, I will give you a link to the finalized edition that you can use as a reference as well to make sure that the code that you're working with actually is going to match what we are going to build.
Additionally, if you think you found something that is different or doesn't quite work, be sure to make a discussion for it in that GitHub repo. Like I said, it's going to be your bible. Additionally, there's a link to join the GitHub discussions. This is your platform to ask questions, engage with the community, and learn with both other people taking the course and also our TAs who are going to be helping you out along the way. Additionally, there is a link to the Discord for more realtime communication. I urge you to ask questions in the GitHub discussions as well because those are going to be indexed going to make them much easier to Google search later and have them show up as opposed to Discord. Discord is still phenomenal for you to join them. For those of you watching on YouTube, hello. you should scroll down
to the description and in the description are going to be links to these resources as well and additionally a link to Siphon Updraft. If you've been watching, you've already seen some of the advantages that Siphon Updraft has, including written lessons, single videos, and there's also ways to track your progress instead of having to scrub on a giant YouTube video. So, for all of you who are watching this on YouTube, definitely be sure to go over to Cipher Updraft, sign up there, and watch the curriculum there because your learning experience will be much better. but leave this video playing in the background on YouTube so we get the bump from the YouTube algorithm. Thank you.
That being said, as we go through this course, we're also going to teach you some best practices on working with artificial intelligence, how to best prompt these AI so that they can give you the best results. Just keep in mind they sometimes get things wrong and it's a good idea if you are going to use an AI to fact check it with a human or another resource. So, be sure to say hi in the discussions and maybe meet some like-minded peers. And additionally, once we do get to the coding portion of this course, it's a good idea to code along with me as I'm explaining things. So having the video up as well as your coding screen is a good idea so you can follow along with me as I'm explaining it. If you're watching this on Siphon Updraft, you can just click the little
video pop out button and have the video pop out as such and code next to it. All of this is to say if you run into an issue, jump to that GitHub repo and make a discussion. We will also be giving you some tips very soon about how to best make a discussion. Yes, asking questions to other human beings is a skill and we're going to try to teach you to be the most effective because asking well formatted questions is not only the secret to being a fantastic AI prompt engineer, but also becoming an incredibly successful developer. We're going to learn how to ask well- formatted questions. And whenever we post on discussions or forums or whatever, we're going to work on formatting them as best as possible.
Take breaks. I cannot tell you how many people have tried to rush through these courses and be like, "Oh, I'm going to finish in a single weekend." Your brain doesn't work like that. Your brain needs time to absorb the information. So, take breaks. Maybe every 25 minutes to a half hour. Take a 5-minute break. Or maybe you like working in longer chunks. Maybe take a whole hour and then take a 15- 20 minute break. Don't try to rush through the whole video in a day. You're not going to retain the information. Go outside, go for a walk, grab some ice cream, get some coffee, go to the gym. Your brain needs time to have the information settle. Maybe every two hours just step away. Maybe be done for the day. Work at whatever pace makes sense for you. Everyone's going to have a different learning pace. There is no
right speed for this course. I've had people take my courses in 2 weeks, in 3 months, in 6 months. It doesn't matter. Pick a pace that you can do and stick to it. Not only work at your pace, make sure that I'm talking at a pace that makes sense for you. There's a little gear icon in the YouTube video here where you can change the speed of how I'm talking and how fast the video is going. So, if I'm talking way too fast for you, then you can slow me down. But if I'm talking too slow, then you can speed me up. And if you're watching this on Siphon Updraft, you have the same dials as well in the bottom right hand corner. Additionally, if English isn't your native language, we have seven different subtitles in the Siphon Updraft video player as well. So, make
the adjustments you need to make me go the speed you want me to go. And of course, this course is modular, so you can bounce around topic to topic and go to where you want to go. If you don't want to do any full stack stuff, then skip that section. If you want to go right to the advanced stuff, do that. Like I said, go the pace and take the learnings that you want to do. And after every lesson, it might be a good idea to go back and reflect on each lesson to really make sure the knowledge gets ingrained. Repetition is the mother of skill, and we're going to be repeating a lot of smart contract development. Now, the last bit here is in the Siphon Updraft platform, we're going to have quizzes that you can take to help see if you learn the knowledge that you were
supposed to learn. If you're watching this on YouTube, you don't have that. So, go sign up for Siphon Updraft and then play the YouTube video in the background so the YouTube algorithm bumps us up. Blockchain development and open source development world is incredibly collaborative. So, be sure to use tools like, of course, the GitHub discussions tab, Ethereum Stack Exchange, the decentralized Q&A forum, Piranha, issues on different GitHubs, artificial intelligence, and more. And like I said, we'll give you more tips on how to most effectively use these sites in the future. And the reason I'm putting so much emphasis on this and that I will continue to put so much emphasis on this is being a successful smart contract developer is more than just knowing how solidity works. Knowing where to go for information and how to collaborate with people is often more important than your smart contract
knowledge because oftent times you're going to run into issues you don't know how to solve. So, we're going to teach you to unblock yourself on this and really anything in life. Plus, syncing with other people in the space makes it way more fun. For those of you who are here and are not a developer, fantastic. We're not going to be doing any coding for this course at all. However, we are going to be doing some interactive demos. So, there will be challenge videos. There will be challenge sections where I ask you to pause the video and go ahead and try to set up a wallet, solve a challenge, etc. Now, to get started, we're going to talk about Now, to get started, let's talk about wallet recommendations. Now, the wallet that you should use is going to depend on your skill level with wallets.
So, we're going to start with people who are not very skillful with wallets. There's a GitHub link to this article in the GitHub resources associated with this course, whether you're on Siphon Updraft or on YouTube. This is the Siphon Web3 Wallet Guide for developers and protocols. Like I said, this is going to be very high level, but this is what to keep in mind on the different trade-offs between these different types of wallets. And as of recording, we have no sponsorships on these wallets. So, this is just kind of the raw unbiased opinion. At some point, we'll probably will have sponsors for this, but we'll obviously little leave a little asterct saying this is the sponsored wallet. But so the biggest consideration to keep in mind when you're choosing a wallet solution and you should do this before you deploy your smart contracts is what
are my threat vectors? What do I need to keep in mind? Who is this wallet for? What is this wallet going to be controlling? Etc. And to get started, we're going to start all the way at the bottom, which is going to be our total noobs. These are people who may not really know what a cryptographic signature is. These are people who don't know what public private keys are. As blasphemous as this might sound coming from me, they might not be the best person to keep their private keys safe. So for people like that who don't understand this technology but want to be in crypto, maybe they don't trust themselves enough to keep their private keys safe. Maybe they see a private key and they stick it in av file, which you should never do. Those people, the recommended solution here is going to be
a custodial wallet. Now hold on before you crucify me. I highly encourage anybody to move past that stage by getting educated on how these wallets work. Obviously, Cipher Updraft, we go over a lot about how wallets work. Get educated so that you can keep control of your private keys. So, let me just reiterate what I just said there. If you get a popup on your MetaMask or on your treasure or on your ledger or on your grid lattice plus or on your safe wallet or whatever wallet you're using, if you get a popup says, would you like to sign this transaction or would you like to sign this message and you are not 100% certain what that is doing and you have real money associated with that wallet?
You should not sign it. That's the first thing I want to tell you. And then additionally, if you're the type of person that says, "Hey, you know what, Patrick, I don't think I'm ever going to be that person. I don't want to have to I'm so sick of listening to you. I'm done with this course right now. I don't want to have to go to the part where you teach us how to verify transactions. Then I'm going to say fantastic. Stop the video. You should use a custodial w. You should just use Coinbase. Just use Kraken, etc. Because what's going to happen because it happens all the time is you're going to go to send a transaction. You're going to hit confirm. it's not going to be what you wanted it to do and you're going to lose a lot of money or you're going to leak
your private key somewhere and you're also going to lose a lot of money. So unfortunately that is my recommendation for you. Now obviously the downsides of custodial wallets is that they are centralized and somebody else technically controls your money and it's not that much better than putting your money into a bank account which is like the opposite of why we invented crypto in the first place. But working in crypto does require you actually have a little bit of hygiene and you understand what you're signing. So, if you know you're not going to do that, go ahead, pause the video, work with Coinbase, work with Kraken, work with whatever custodial wallet that you want, and stop. But for total noobs, for people who do not understand private key cryptography, you probably want to use a custodial wallet. And this is going to be something like an exchange like
Coinbase, like Kraken, even something like PayPal. The pros of using an exchange, of course, are going to be they're easy to use and you're basically outsourcing your security. And this is the pro of it. if you're a noob. That is a double-sided sword, though, because the con of that is that exchange can rug you. They can rug pull you, and we've actually seen this happen in the past where the exchange goes, "Oh, yeah, we have your money. We might have swapped it to this thing called FTT tokens. Trust me, it's good." And it wasn't good. The exchange can go under. The exchange can actually freeze your account. The exchange technically owns your money in the same sense where if you put your money in a bank, the bank technically owes your money. So this is going to be the baby step to getting into web 3. This is the web twoiest web
3 approach you can take. You have crypto, but your crypto is remember if somebody else controls the private keys like on PayPal, like on Kraken, like on Coinbase, it's not your crypto. They're holding it for you. They can block you, they can stop you, etc. It is the centralized version for this, but it might be good for the people who do not understand this technology very well. Some potential suggestions here are going to be Coinbase, they're going to be Kraken, they're going to be PayPal, etc. And because you're here, I know you're not a noob, but this is what you can tell your friends. If you say, "Hey buddy, do you know what public private key cryptography is?" And they go, "Hey buddy, what the hell are you talking about?" Maybe you just say, "Okay, just use PayPal, Coinbase, Kraken. By the way, they control your assets and you
really should learn about cryptography and wallets, etc. You should go over to Cipher Updraft to learn all about that stuff." Cool. Anyways, so you're not a noob. you are at least a beginner experience and maybe you have some small money. So for beginners here and for small monies short-term storage desktop browser and hardware wallets are fantastic solutions here and this is going to be your MetaMask your treasure your my wallet your rainbow wallet your rabby your frame etc but so Patrick what do you mean by beginner experience and small monies? Well, at the end of the day, what I mean by small monies is I mean an amount of money that is okay if you were to lose it. And that's
different for everybody. Maybe for this struggling college student, maybe anything more than $50 would be terrifying to lose. So having $50 in their MetaMask might be okay, but you know, maybe having $1,000, if they lost that $1,000, they would be devastated. Maybe you don't use a browser wallet in that case. Maybe you do move on to the next stages which is going to be hardware wallets or multisigs, etc. But maybe you're a massive hedge fund and $1,000 is nothing. So if you lost five grand, it wouldn't be the end of the world. And maybe you just leave 5 grand, 10 grand, 50 grand, whatever is comfortable for you. That is like, hey, if this loss, this would suck. Like I don't want to lose 5 grand, but it wouldn't be the end of the world. So So that's what I mean by small monies here.
You want to treat especially these browser wallets like literally a wallet. like you're carrying around with you like these. You you ever you ever seen one of these before? Like like that's what you want to consider these browser wallets as. So you wouldn't walk around the streets with a hundred grand in your pocket. That's ridiculous. You're asking to get destroyed. So same thing with the browser wallets. Hardware wallets are much better than the browser wallets for that, but we'll talk about that in a little bit again. So you want to think of browser wallets as being equivalent to walking around with money in your pocket. Like literally like a wallet in your pocket. Now, there's this terminology often thrown around about being a hot wallet and a cold wallet.
So, a hot wallet is typically just a wallet that's actively connected to the internet at most times. You know, this is going to be something like like your browser wallets for example, MetaMask. I click my little MetaMask logo here. Boom. Wallet pops up and it's connected to the internet just by nature of being in my browser here. This is your Phantom, which is going to be more for like Salana. This is going to be your Rabby, etc. This is the hot wallet. it is connected to the internet versus your cold wallets or your hardware wallets. The cold wallets are going to be not connected to the internet. They're going to be what's called airgapped. Here's what makes the terminology kind of weird. At some point to interact with the blockchain, you will connect your cold wallet to the internet. And at that moment, it's like considered a hot
wallet kind of. But just the rule of thumb here is if more often than not it's not connected to the internet, it's a cold wallet. And if it's connected to the internet, a lot of the times it's a hot wallet. Hot wallets obviously are a little bit more dangerous because they are much easier to move money. The harder it is to move money, the better it is for long-term storage. So, that's the other thing to consider. If you're doing short-term storage of money, again, like in a wallet, that's fine for like a browser, a hot wallet. If you want to keep money for a long time, that's better for cold storage where it's much harder to move your money. I digress. So, so you'll notice that I put hardware wallets in this section as well, but they are a little bit better when it comes to securing money for long
amounts of time or for securing more money because they are what's called again airgapped where they are not connected to the internet. And these are going to be actual physical devices. So, here's an example here of the treasure. It's literally like a physical device you plug in. There's some software that will help you connect and interact with your money, but literally this holds your private key. Using a hardware wallet is another great option for beginners or small money or for short-term to medium to even long-term storage because they are what's called again airgapped. They have a gap between the internet and it makes them harder to move money. The thing with these hardware wallets is the private keys and seed phrases of course are stored directly in them and sometimes they have
proprietary code which depending on how you look at it can be good or bad. on actually encrypting these private keys and seed phrases. But again, hot wallets great for carrying around small amounts of money for beginners who are looking to get into the space because they are so much easier to use. Whereas hardware wallets are actually good for the same reasons, but a little bit more advanced, a little bit tougher to use. And we'll go over hardware wallets even more in the coming sections. So the pros of both of these is, hey, we've moved away from custodial. These are now your keys. So your crypto, you are now in charge of your private keys. Browser wallets especially are really easy to use with web 3 apps and sometimes hardware wallets as well depending on the hardware wallet. So these are great for
keeping small amounts of money like a real wallet. They're great for trying out the web3 ecosystem. And often times what people will do, they'll move money from their cold wallets, their long-term storage into their hot wallets into these browser extensions because again it's like working with a wallet. The cons are now that we've moved away from the custodial wallets is now you are the sole security checkpoint. And especially the cons with these is if you're using a hardware wallet, if you're using just a browser wallet, just a hardware wallet, you now have a single sole point of failure. If your private key gets exposed, it's done. If your computer gets hacked, it's done. If somebody gets a hold of your hardware wallet, it might be done. So, if you make a mistake with
these, you can get wrecked really quick. Hot wallets mean you're connected to the internet, so if someone hacks your computer, you're wrecked. There's some other cons here, too, that are kind of tricky to think about. One of the biggest ones being supply chain attacks. If you download a bad version of the software, or you order a wallet from a site and somebody swaps it with a hacked wallet, and even worse, some wallets track your data, and you'll need to customize your wallets for more privacy. Some potential suggestions for working with a hot wallet are going to be MetaMask Rabby Frame Rainbow My Ether Wallet. And additionally, there are some tools you can use to actually upgrade your wallets, such as web3 antivirus, fire.xyz, and MetaMask somewhat recently launched MetaMask
snaps, which are customizations to your MetaMask to add even more. For example, there's a block sack MetaMask snap, which will actually check for malicious transactions as well. So, there's a lot of different snaps you can use in your MetaMask. And then finally, we've arrived at the advanced or the strongly intermediate section, the multi-IG or the social recovery wallet. And this is where you developers watching this course will thrive. And this is where we have
another exercise or in action for you. If you do not have a multisig setup, we're going to walk you through setting that up today at the end of this video. Why? Because multiigs are probably my absolute favorite methodology of storing crypto for a number of reasons that we'll get into here. Social recovery is another one and they're pretty similar and we we'll talk about both of them uh in a bit here. So multi-IG wallets unlike hardware wallets, unlike browser wallets, these are actually smart contracts deployed onchain where the money is stored in this smart contract and you have defined parameters on how to actually interact with this wallet.
Probably the best multisig wallet out there is going to be safe.global which we'll walk through that as well. There's some other wallets that are fantastic as well. Aragon has a multisig feature for Dows specifically. So a multi-IG wallet is going to be when you have multiple signers to send or do anything. For example, in a three of five multisig, that would mean three people need to sign a transaction in order to send a transaction. So three separate wallets would need to sign a transaction. For example, maybe there's a MetaMask wallet A that approves to send five ETH. A treasure wallet B approves to send five ETH. And then a Frame wallet approved to sends five ETH. You have three of five achieved. and the ETH is sent. The
beauty of this is you no longer have that one single point of failure in any of these wallets. If you have all your money in MetaMask and somebody hacks it, oh my god, you're wrecked. Somebody hacks your treasure and you had all your money in there, oh my god, you're wrecked. If you're on a multi-IG and you have 305, somebody hacks your MetaMask, you're okay because it's only one wallet. And then what you can do is you can just say, "Okay, we're going to swap out that MetaMask for a different wallet in a transaction." So this is hugely hugely beneficial to the point where if you're using a DAO that's not some type of onchain governance, you 100% need to have a multi-IG as opposed to a single externally owned account as opposed to a browser wallet or even a hardware wallet
similar to the pledge. I should make you all do a multi-IG pledge where you promise if ever you have a smart contract that is ownable, that has roles or that has only certain people being able to send transactions, those roles are governed by at least a multi-IG. This is a great option even for solo developers and non-developers who want to have a safer, longerterm holdings passing various safety checks. Again, again, if one of these wallets gets hacked, it's not the end of the world. you just say, "Okay, well this hacked wallet is no longer a signer of my multis." And an extra piece on this, if you are doing a multisc, don't store your all your private keys on the same device. Don't do that.
Now, another phenomenal wallet choice similar to the multiscake is going to be social recovery. And this is a great option for more advanced users. And this is actually one of Vitalic's personal favorite options. Basically, how it works, there's a single signing key that can be used to approve transactions. and there's a set of at least three or or a much higher number of guardians of which a majority can cooperate to change the signing key of the account. So, it's kind of like a multi-seg where there's multiple guardians who can cooperate. However, there's still just one signing key. The advantage here is yeah, like from Vitalic's blog, under normal circumstances, the user can simply use their social recovery wallet like a regular wallet. However, if they lose their signing key, that's where the
social recovery functionality would kick in. Now, the issue is, oh well, wouldn't they have access to my wallet? Isn't that bad? Well, this is where a Shamir backup would come into play. You give shares of your keys to trusted users. Each individual can't have your key. They get like part of the key basically. Treasure T is a hardware wallet that actually comes out of the box with this Shamir backup, this social recovery, and it's a great choice for people who who want to have this social recovery backup. Pros of multisig social recovery backup are going to be many signers meaning multiple steps to take actions and if a key is compromised well this is for the multisig in particular you don't have to move funds you would just swap out the compromised key this is actually why I highly recommend all developers at
least make a one of one multisig wallet where they have one signer and one is required to send a transaction this way if somebody does hack your private key it becomes a little bit of a race to swap out the hacked wallet Additionally, you can have a two of three multisig where if where that's going to be even better where if one of your keys get hacked, you just swap out the key for something else. The cons are that multisigs are probably the weakest for working with web 3 apps. Transactions take a little bit more gas because you have multiple signers and then most importantly is the address is going to be different on multiple different chains. So when we look at our our MetaMask for example, my address on ETH mainet is going to be the same. It is on
linear mainet. It's going to be the same it is on stylus test net on base etc. because of how a regular EOA or externally owned account works for multi-IGs. These are smart contracts. So every time you deploy them, guess what? They're going to have a different address. So, this is something that can be really confusing to a lot of people who aren't used to working with smart contract wallets and something that you'll definitely need to keep in mind. Potential suggestions are going to be safe for multisig, potential suggestions for the social recovery are going to be safe, argent, and of course, treasure as well. And that's what we're going to be doing right now is we're going to be setting up a safe. But before we do that, I actually made a little bit more entertaining video about this. So, let's go ahead. Let's watch this video on safe
just to give you more context for how the safe multisig wallet works. Safe, a term that should instantly notify you that the crypto project it's associated with is except in the case when it's preceded by the word nosis. Nosis safe or as they are now known as just safe, is the most popular programmable smart contract wallet, often used for its multisig capabilities and customization. With a traditional wallet, also known as an externally owned account, that wallet has a single private key that secures your funds. These are going to be wallets like MetaMask, Ledger, or Rainbow. But if you expose or lose that single key, that single point of failure, you'll lose all your funds faster than sandbank a black hat hacker steals from a DeFi protocol.
Additionally, the code on some of these wallets can be closed source, and we can't guarantee how secure they actually are. A smart contract account or wallet, on the other hand, is an account controlled by open- source code, and you can customize your account to be more secure, including requiring multiple keys to sign a transaction. These are often known as multi-IG wallets. If you expose one of your private keys, for example, in a two of three multi-IG wallet, that one key won't be able to initiate a transaction without the other key. Since the wallet is a smart contract, you can then replace the bad key with a fresh new key, and your wallet will continue to be safe. And these keys connected to a smart contract account can be from MenMask, Ledger, or even other smart contract wallets. The NOS safe or safe multisig wallet is
currently the most popular multisig wallet out there used by protocols like a synthetics and hopefully you. To get started with safe if you're a paranoid hardo, you can first do a quick month-long audit on the codebase and then copy paste one from source. But if you want, you can also just go to the website and open the app. And we'll go ahead click create new safe. And to create a safe, we'll need at least one private key. I'm just going to go ahead connect my MetaMask, but you can use whatever you want. Give it a name. It'll automatically detect your address as in one of the owners. You can even switch to a test net to practice. Hit next. Confirm creation. And your smart contract wallet will have been deployed.
We can go ahead and start working with our wallet. We can now copy the address of our smart contract wallet, send it some funds from our externally owned account, and you can view it in the safe UI. Then when you and your friends are ready, we go ahead hit send tokens, choose a recipient, choose an asset, choose an amount, and we can either just sign the transaction or sign and execute since we're a one of one. If there were more keys required on this, we would just have to sign it, wait for everyone to sign it, and then we could actually send the transaction. You can also create and interact with safes from JavaScript, the command line, and kind of JavaScript/comand line. And if you want to add even more customization, the safe codebase is extendable with modules and guards. safe multisigg wallets are used by some of the largest DeFi
protocols in the space. And I highly recommend everyone at least get familiar with a oneofone smart contract wallet because if that one key does get compromised, you can come here, swap out your private key before your funds get stolen. And according to Dune Analytics, these 101 safes are the most popular out there. Anyways, this has been a Lilyad look at safe multisig wallets. Leave a like if you want to see more videos like this, and we'll see you next time. All right, welcome to your first challenge. This is going to be pretty straightforward. All you need to do for this is to download and install MetaMask into your browser. Now, we have this video in the blockchain basics course of Cipher Updraft. So, there will be a link in the GitHub repo associated with this
course to go ahead and rewatch that. All you need to do is download the MetaMask extension into your browser and then come back when you're done. And as you're doing that, I want you to notice something important. As you're installing MetaMask, it's going to say, "Hey, write down your seed phrase. Write down your private key." Now, your seed phrase or your secret phrase or your pneumonic phrase and your private key, these two things must be kept secret at all times. And if you're actually going to have a cryptocurrency wallet that you want to put funds in, you must never reveal this. Revealing this is essentially giving somebody the combination to your safe with your gold in it. So, it's crucial that you keep this safe and secure, but it's also crucial that you yourself have backups of it and you don't lose it. There is no
support line you can call if you lose your private key. If you lose your private key, you're screwed. So, as you're downloading MetaMask, be sure to keep note of this because we're going to be using it later. If your house burns down and you have $100,000 associated with your private key and you didn't back up your key, you've essentially just lost $100,000. And unfortunately, people losing their private key happens all too often. So, pretty soon, we're going to do a drill, a disaster recovery drill, where we have to practice actually re-uploading our private key or re-uploading our secret phrase in order to reaccess our funds. So, pause the video, go download MetaMask if you haven't already, and I'll see you soon.
Now, the reason we had you download MetaMask is because now we're going to actually have you do something called disaster recovery. Like I said, this private key or this secret phrase is what's required in order for you to have access to your money. And what a lot of people do is they write down their private key or they write down their secret phrase. Maybe a year or two goes by, they forget about it, they forget where they put it, and all of a sudden their computer crashes, their house burns down, they lose their their hardware wallet or whatever. They need to get their funds back, but they forgot where they wrote it down and then forgot where they stored the information. So, what a lot of people do is they set a calendar reminder every year, every 6 months, or for however long you feel
comfortable to practice restoring their key from its resting place to make sure it still works, that you know how to do it, etc. This is called disaster recovery drills, where you're actually doing a drill. You're actually practicing what it feels like to, "Oh my god, I lost my private key and I need to restore it." So, right now, the reason I had you download Metam Mask was so that you can practice doing a disaster recovery drill. And that's what we're going to be walking you through right now. So, first thing first is you're going to take your wallet, wherever it is, and pretend it's been deleted. It's been destroyed. You no longer have access to your wallet. The what you're going to want to do is find that slip of
paper that you stored in a safe and use it to reinitialize your wallet. Now, if you haven't done this already, you 100% should. What you can do is you can come to your specific account, hit the three dots, account details, and select show private key. Enter your password or hit the three dots, account details, and go to show secret recovery phrase. Remember, the secret recovery phrase has access to all of the accounts associated with that phrase. The private key is the one specific account, right? So maybe you've written down your secret recovery phrase, maybe you've written down your private key, maybe you've done both, right? So whichever one you want to
recover, we're going to grab that slip of paper. We're going to grab that iron plate. We're going to grab that whatever we've done and we're going to use it to import into a new MetaMask. Now, I want you to actually do this. And like I said, ideally, you pause the video right now. You go to your calendar and you set a reminder for every year to do this disaster recovery drill where maybe you go to your safe or maybe you go to that secret hiding place or maybe if you did social recovery you call a couple of your friends and you say, "Hey, we're doing a disaster recovery drill."
Whatever your backup plan is, run through it and actually test to make sure that you can actually get your keys back. So, what I'm going to be doing is we're going to go ahead. We're going to redownload MetaMask here and add this to Brave or whatever browser that you're using. It's going to pop up and I'm going to say sure. And instead of create a new wallet, I'm going to say import an existing wallet. And here's where it's very straightforward. All we have to do is import our 12word seed phrase like so. And you've written it down. So, you just paste your 12word seed phrase in here. Boom. confirm secret phrase, add a password,
uh, and import it. Tada. It's as it's as simple as that. Now, if you don't have your seed phrase like so, what you could do as well, you could hit add or import hardware account by private key and simply paste your private key in here. Or since it's not stored digitally, obviously type it out yourself. But if you haven't gone through this process with your private key, please pause the video and do so now. Every wallet, no matter if it's a hardware wallet, a treasure, a ledger, a meta mask, a rabbi, is going to have a secret phrase and a private key. And you should have a backup of those somewhere at all times. Sometimes people store them on multiple slips of paper.
Sometimes people chisel them into iron plates. Sometimes people store them in a password manager. Just keep in mind there have been instances where password managers get hacked and they leak your private key. So maybe double think using the password manager. And obviously if you write it down on a piece of paper, make sure that is hidden somewhere appropriate. And what's nice about this is even if you have a treasure, a ledger, a grid plus, a meta mask, they all still work with a private key or secret phrase. And you can restore your accounts. You can restore your cryptocurrencies in any of them so long as you have that private key or that secret phrase very similar to what we did right here. So, for example, maybe
you have a Ledger hardware wallet and you wanted to update it to a treasure safe 5, you would be able to do that. Or if you had a treasure safe 5 and you wanted to update to a MetaMask, you could do that as well. Now, we're going to walk through a real transaction happening on the actual Ethereum chain because I want to show you what it looks like and I want to really give you the feel of like, hey, like this is really what people do and really what people should do. However, we're not going to have you send real transactions to actually test this. We are going to actually walk you through a simulated environment, a simulated version of this so that you can get some practice verifying transactions yourself. Now, if you're here, you've probably already worked with different
DeFi protocols before. The one in front of me is one known as a and they are a borrowing and lending protocol. You can kind of think of them like a bank. You can deposit different cryptocurrencies and you'll gain a yield. You will gain interest on your cryptocurrencies. Kind of similar to you depositing money in a bank and you gaining interest on the money in the bank. The only difference is the beauty of a is they are non-custodial. Meaning the bank doesn't have control of your assets. In the same vein, the A team doesn't have control of your tokens. It's all governed 100% by code autonomously. So you always have control of your assets, which is the beauty of web 3 and the beauty of cryptocurrency. If you wish to engage with such an application, most of the time working with websites, they will
have a little button up here called connect wallet. You go ahead and select it. Select the wallet that you're using. In this case, I'm using MetaMask. My wallet will pop up and it'll say, "Hey, would you like to connect this account?" I will say, "Go ahead and connect it." And I will have my wallet connected to the application. So for this, my MetaMask wallet here with $23 in it is connected to the A application on the Ethereum chain. If I look at my wallet, I see we're on the Ethereum mainet chain. I can see this is the wallet that's actually connected. And I can see the different functions I can use to interact with this application. for example, supply my USDC or my ETH, which again is going to be like depositing
money into a bank to gain this yield on it, which is really nice. So, if I wanted to actually supply some money into this to start gaining interest, I could come to the website and I would hit supply. I would get a little popup like this. Maybe I say I want to supply 0.001 uh one ETH because I'm incredibly poor and I want to supply $244. say the website will say great, it'll be 1.88%. Uh, it'll give me a 1.88% interest rate and it's going to cost me a $1.27 in gas. This probably doesn't make sense to do in the Ethereum chain. It probably would make more sense to use on ZK sync or some other layer 2. At the moment
with this dummy account, I have the dollars on Ethereum, so so be it. I'm going to spend a dollar for this demo here. I can hit supply ETH. And what's going to happen is I'm going to get my MetaMask or my wallet popup saying, "Hey, are you sure you want to go ahead and do this and it'll give me some estimated changes as well as some other information here." One of the most important sections is going to be all the way at the bottom of this transaction request where it says the data. So, this data section represents exactly what you're signing and exactly what this is going to do. Now, you don't have to be a developer to understand this section, but what you do need to do is you do need to actually understand what you're signing, and you need to
verify every single piece of this so that when you hit confirm, you actually are sending money to the right place, and you're not actually going to hit confirm on something that's going to steal all your money. Like I said before, the largest hack of all time for $1.5 billion happened because the BBET team signed a transaction that they didn't know what it did. The website that they were interacting with, like for example, A was hacked and it sent a bad transaction to their wallet, but instead of checking what they were signing, they just went ahead and signed it. So, we want to make absolutely sure that whenever we're signing something, we actually know what we're signing. So, let's go ahead. Let's walk through this MetaMask request so we can get a better
understanding of how this works. So first at the top we have estimated changes. This is a nice to have feature that MetaMask comes with where it does exactly what it says. It estimates some changes. This isn't foolproof. So this might give us a good idea of what happens where we say okay we'll send 0.001 ETH and in return we'll get 0.001. But this could also potentially not happen. So we want to make sure we actually are understanding what's going on here and not just trust the estimated changes. Here is some important stuff.
So request from this is the website that's actually making the request to our wallet. So first we want to check is this the correct URL app. That is the website we're on. And I know that this is the correct website interacting with. This is the address of the smart contract that we're interacting with. And it's incredibly important that we get this right. So we can copy this address and we can go to Etherscan and we can paste it in and we can double check with Etherscan that this is actually an A smart contract. We can see here that it's tagged as a ETH staking contract. So if we trust Etherscan, we can say, okay, Etherscan says this is
indeed the A smart contract. What we could also do is we could actually just straight up Google it. We could scroll and look for any saying what this is. Or we go to the A documentation and maybe paste the address in here. Don't do that. And scroll down to developers smart contracts or where are we looking for? Excuse me. Scroll down to addresses. And we can look for this address. So it's 0xd016. Let's look for this 0x016. So it looks like it's this address here. And if we copy this address on our MetaMask, paste it, it looks like it's the exact same address. So we verified on the actual A
documentation that this is correct. Now what we can do with MetaMask that's nice is we can actually then give this a nickname called A ETH staking contract like this. Hit save. And now it'll pop up as the A ETH staking contract. It'll come up as this nickname for us here. This is obviously preferential because now anytime we work with a in the future, our MetaMask will have that address saved and it's a lot easier for us to check that this is what's going on. Then we have the method which MetaMask could get wrong. So we're going to ignore that for now. But this should give you an inclination that we're calling the correct method. Anytime you interact with a smart contract, you're actually secretly calling a method or
you're calling a function which is basically saying you're doing a specific action on that smart contract. Uh we obviously have some network information like how much gas it costs. If this is something absolutely outrageous, we should obviously cancel the transaction because maybe something malicious is hap happening. But then the most important things are going to be down here in this data section. Now, MetaMask has done a great job of doing something called decoding the data. So, in here, we see data. We see, and if you don't see this, go ahead and click this little button to show the advanced details, but we see data, we see a function, we see parameters on behalf of and a referral code. So, technically, if you hit this little copy button here, and we open up
a little text editor, and I paste this in here, this is actually what we're signing. It's this data. It's this raw hex bunch of numbers and nonsense. And MetaMask has done a pretty good job and taken this nonsense and basically converted it to something that is a little bit more human readable. Basically this hex this nonsense here stands for deposit ETH with this first parameter this second parameter or on behalf of and this third parameter. So you don't need to understand what this hex nonsense is, but you do need to understand what this is. So let's go ahead and let's learn how to actually understand what we're calling when we're
calling deposit ETH. So what we want to do is we want to go back to the AI documentation and we want to look up this deposit ETH function. And it looks like they do have some documentation on this write method, this deposit ETH. And we can see that if we zoom in a little bit here, this deposit ETH function takes these three parameters, an address, an address, and a unit 216. You don't need to worry about what those are at the moment. Just know that this is like an address like an Ethereum address. This is an address like an Ethereum address. And this is a number. And we want to understand, okay, what do those stand for? So we have PM one is some address. Uh the parameter 2 on behalf of is another address. And then
there's a referral code. Are these parameters correct? Is this going to actually deposit our money so that we start earning interest? So we can scroll down in the documentation and we can see it actually explains the input parameters. This is kind of an example where the first address in here is a dud, right? It just says address and there's no name. Deposit ETH pram one is nothing and it can be whatever. It doesn't matter. It's a dud there. the function actually doesn't use it which doesn't normally happen but sometimes it does but we can learn what on behalf of and referral code is on behalf of is going to be the address of the user who will receive the a tokens representing the supplied tokens the a tokens are
basically the interest earned so we should expect to see on behalf of be ourselves if on behalf of isn't our address we should deny this if we go back to the transaction we look at on behalf of we see it's this address. What I could do then is I copy this address and then double check to make sure that it is my address that I've labeled small test net. Right? So I go to Etherscan or I could just copy paste it, you know, just basically just make sure that this address is indeed the one that I want to be using. Okay, cool. So I know that this is my address and I know that I want to actually deposit my ETH for myself on behalf of myself. So this address looks good. Okay. And then the
next is the referral code which is zero. Okay. So what does referral code stand for? Inactive can pass zero as a placeholder. Oh, okay. So the first parameter can be anything. On behalf of is correct and referral code is zero. That's correct. I've now verified that the data of my transaction is correct. Why? Because I've checked the documentation and I've checked that this is indeed what's going on here. And I can feel safe to actually confirm. And so if I hit confirm then I'll get my little hey this transaction has been submitted close the extension and once this goes through I can view this on the explorer. So now that this has gone through I can view on the block explorer where I can see some more information
about this uh and I can double check that this actually did what I wanted it to do. So, first off, the two address is that ETH staking contract that we checked in the documentation, right? We checked in here. We went to addresses and that was this wrapped token gateway on the Ethereum chain. Great. So, we sent it to the right address. If we scroll all the way down to more details, decode input data, I can see the three parameters that this sent. We have the first parameter or the zerith parameter was undefined. So, it can be any address. it doesn't matter. The second address was the on behalf of which we needed it to be us so that we could actually get the interest and it was indeed us. And then finally the referral
code which could be zero. And now if we go back to our to the A UI it says all done. We can say okay close. We'll do a little refresh here. And we can now see we have successfully supplied some Ethereum into the AVI protocol because we've verified that it is correct in our MetaMask here. Now, like I said, don't worry. Pretty soon, we're going to be going through some simulations of working with this. But I want to show you one extra step that if you get more advanced, you're going to have to do, especially when working with hardware wallets.
So, I want you to go to this website, wiser.siphon. siphon.io. This is a website that the cipher team we created to help people train actually verifying transactions that they send. So, you're going to go ahead, you'll hit start training now or hit the play now button and go to the simulated wallet section. So, if we skip the first couple of questions, we can actually get to our first simulated question here where we see sign or reject this signature. Assume your wallet is address blah blah blah and you want to sign into OpenC to see your NFTs. Will signing this accomplish that? If so, please sign.
Otherwise, reject. And we have a little fake website here. And we can select sign with Ethereum. And we get kind of like a fake MetaMask popup, which is reminiscent of something we would see if we actually were using MetaMask. For example, if I went to OpenC right now and I were to go ahead and sign in, we would actually see something similar here, right? Hey, uh, OpenC wants you to sign in with your account. Click sign in to blah blah blah. You know, I'm going to go ahead and cancel for now. So this is pretty much reminiscent of exactly what we would see on the OpenC website which openc is just another web3 application. However, if you look closely at this message to sign, it says app.nosispay.com wants you to sign in with your account.
It has a URI for app.nosispay.com version ID blah blah blah. So right away some red flags should be going off in our head. Hey uh app.nosispay.com that's not openc. Um, OpenC, was OpenC hacked? Why is OpenC trying to have me sign into nosispay.com? And this is going to be one that we would want to go ahead and reject. But I'm going to show you what happens if we sign this on this simulated site. So, if we go ahead and hit sign, you get a little popup. Oh no, you signed something you shouldn't have. You allowed this site to impersonate you on Nosis Pay. You could hit I understand.
And then it'll give you some feedback as to what happened and why you shouldn't have signed that. It'll give you some feedback and this is how you're going to learn how to verify different types of signing and different types of signatures. So the next one, execute or reject this transaction. So we've been using MetaMask a lot, but this will be an example of what it looks like on a hardware wallet. Hardware wallets have different interfaces than MetaMask and sometimes they're a little bit harder to work with. So for this scenario, it says this transaction requires your Treasure hardware wallet. You're attempting to send your friend at this address 0.5 ETH on the Ethereum chain. Assume your
wallet is blah blah, which is the number one wallet from the standard ETH derivation path. If you don't have a Treasure wallet, this might not make sense to you, so don't worry too much about that right now. Only trust what the wallet shows you. If sending this transaction will get you want, sign it. So, one of the first things we want to look at is, is this URL actually correct? So, I know that metamas.io is a trusted domain. So, I can feel a little bit better about sending this transaction. But then again, MetaMask could still be hacked or there could be bugs, etc. So, I shouldn't say, ah, it's the MetaMask site. I'm good to go. But this at least says, okay, I'm not on a website that's trying to fish me. Then we look at the contents of the website itself. Says recipient address here and
amount is going to be 5 ETH. Oh, that's weird. We're trying to send 0.5 ETH, not 5 ETH. So, normally we would change this to 0.5, but I've disabled that intentionally. Um, so what we should do though is we should hit the transfer button anyways and see what happens. Sometimes websites will show information that's not correct. But maybe if we hit transfer, we'll actually get the correct information. Anyways, so when I'm sending Ethereum, I want to send to the correct uh address. So it looks like we're sending to here on my treasure.
Let's go ahead. Let's grab this address that who we're sending it to. Let's just make sure it's the same. Yep. I did a little command F here. Looks like it's the same. So I'm going to go ahead and swipe up. Send from ETH account number one with that derivation path. Yep, that's who we want to send to. Swipe up. Ah, summary 0.5 ETH with this much of a maximum fee. So, even though the website here said five, the actual wallet says 0.5, which is correct. So, I'm going to swipe up again and I can feel confident that I do indeed want to sign this. And this was an example of the website showing incorrect information. So, we always, always, always want to trust only what shows up in our wallets. So
even though the website said 5 ETH, our wallet said 0.5 ETH, which was correct. So I felt confident to sign that transaction. And then you can read a little bit more from the feedback section here. There's another challenge that I'm going to skip for now by going to question six. All right, welcome back. Did you get through question 10? Did you get some wrong? If you got some wrong, that's okay. I expected you to get some wrong. And that's why we have this Y signer challenge to actually drill you and actually teach you the methodologies associated with getting these correct.
If you got some wrong, you should go back, understand why you got them wrong, and learn those tools as to how to get better and how to actually verify what you're signing. This is going to protect you from signing something malicious, if a website gets hacked, if your computer gets hacked, etc. always only trust what's in your wallet and the like. Now, we've been doing a lot of this with a MetaMask type example. Now, MetaMask is a lot easier for hackers to hack than something like a hardware wallet, which is why we always encourage people as they get more funds, as they get more money, you move over from a MetaMask to a hardware wallet. It's much easier for you to
accidentally download some browser update that exposes your private key than download some firmware to your treasure or your ledger or your grid lattice or whatever that exposes your private key there. For incredibly serious people, I would recommend doing safe wallets. But like I said, those are going to be more for advanced signers, people using multiigs, which again, highly recommend you do something with multiigs. And I highly recommend you check out the qualified signers curriculum, which comes after this. But at least with this knowledge, you know, there are tools out there that can help you decode your call data and help you understand what's going on with your transactions.
Welcome to the qualified signer curriculum. The prerequisites for this are of course the wallets basics or the introduction to wallets, introduction to cryptocurrency wallets, etc. The only difference between this course and that one is that we're going to be working with a lot more advanced signatures such as EIP702, safe wallets, etc. The purpose of this course is to get you prepared so that you can be on a multi-IG wallet so that you can actually verify call data on any single type of transaction and then also verify any signature that you're working with. A lot of companies of the future are going to need people to move money and they're going to need people to
actually understand the security implications of signing different transactions. So whether or not your wallet has good UX, it doesn't matter. If you sign something that's wrong and you lose your company a lot of money, at the end of the day, it is going to be your fault. So the purpose of this curriculum is to teach you so that you can reject those transactions that are malicious and additionally so that you can have the skills in order to get a job where having this knowledge is essential. The beauty of this is that using AI is actually highly encouraged if you're unsure what a transaction is doing. However, you still need to understand every single piece of something that you're signing at the moment. someone clever could actually
trick an AI into saying a transaction is good where it might not be. So, you need to understand all the tools you have at your disposal to make sure what you're signing is what you want to sign. At the end of this, you should be able to get a 100% on the wiser.io. This is a website to help train you to verify different transactions and different signatures you're signing on the blockchain specifically with safe multisig. Now, unlike the wallet basics, a qualified signer does need to be somebody who is a little bit technical. So, ideally, you've also got some solidity fundamentals under your belt so you understand smart contracts at the basics. Even more ideally, you have a little bit of security and auditing experience under your belt as well.
However, if you don't have those, that's okay. But you will need to understand call data. You will need to understand how smart contracts work at a deeper level. So, some solidity fundamentals is required in order to become a qualified signer. But with that being said, let's jump in and let's learn some of the more advanced techniques to signing and making sure we're signing the correct information in our wallet. All right. And now we are actually going to make a multi-IG wallet and I'm going to walk you step by step through the process so you can have a multi-IG wallet. Remember, multiig wallets are great places to store a lot of money to be the controlling wallet address for a DAO, for a large organization, etc. And
for all you protocol developers, if you have an ownership or ownable contract, or have any type of permissions, any role in your smart contract should never be an externally owned account, neither a hardware wallet nor a browser wallet, but it should absolutely be one of these smart contract wallets. So, let's go ahead. Let's jump in. We're on the UI app.safe.global. And you'll get prompted with a UI that looks something like this. And I'm going to zoom way in just to make it a little bit easier to see. If you have an existing wallet, you can add an existing one here. You can of course create a safe wallet directly from the smart contract code on chain, but we're going to use the UI and then just verify our transactions here. So, for us to get
started, we're first going to choose a chain here. I'm going to be choosing the arbitum chain. going to get MetaMask to pop up. Say, hey, would you like to connect your account? We're going to go ahead and select next, connect. And now we should be connected here. And this is where already we can see some of the prowess of working with a safe wallet. We could have worked with our MetaMask. We could have worked with Rabby wallet. We could have worked with even a hardware wallet, etc. We could do switch wallet. The UI comes with a lot of different wallets, but for us, we're just going to use MetaMask here. So, what we're going to do, continue with MetaMask. In the GitHub repo associated with this course, if we scroll down in here, there's a recommended test nets section, which brings you to this link
in the Foundry Flow course, which has some test net faucets. And these are going to be the ones that we recommend you use for deploying your safe on a test net. And actually, we're going to use the chain here. We're going to switch to Seolia. Looks like I have some test net as well. Great. You can use whatever you want to use. Arbitum, Sapoleia Straightup Arbitum Guerelli or just as easily ZKSync era here. Really, whatever EVM chain that you want to use here, great. Whatever test net, whatever network you want to work with. If you've never done a mainet one like Arbitum or Ethereum mainet, etc., highly recommend you do that as well. But in any case, we're going to switch to Sapoleia. I think we've already done that. Oh, whoops. I was on Seolia Arbitum. We're going to switch to
Sapoleia. We're going to give it a name. We're going to call it um security stuff. Next, this is where you're going to add your owners, right? The different accounts associated with this multisig. Ideally, you want to do at least a two of three. For us, we're just going to do a one of one. And you're going to see how we can actually change this and how it actually works. So, for us, we're going to do a one of one. I'm going to say this is going to be Patrick test wallet. Since this is a test net wallet, if I wanted to add more owners, I would hit this little add owners. And then down here, we would choose the threshold to send a transaction. If it's one out of three, that means if one person signs something, they can send it. Ideally, you're doing always at least a two out
of three, maybe even a three to five for a Dow, for an organization, etc. Okay, let's do a one out of one. Again, this is just for for testing, playing around. Going to hit next, review. Okay, who will pay gas fees? Oh, it looks like it even has a sponsored by safe fee. That's great. So, we won't even have to do pay money. Oh, that's awesome. Okay, great. Sponsored by safe. Okay, let's go ahead do next. Your safe account address is being validated here. We're validating the transaction and it's indexing. So, we didn't even have to deploy this. We didn't even have to run this transaction. It looks like safe is actually paying the gas for us. Normally your MetaMask would pop down, sign a transaction, and you would need to be the one to do it. But it looks like for
test nets safe actually does it for us, which is great. But now this is kind of the UI for working with this smart contract wallet. And I can actually view this wallet by clicking this button here. Go over to the Nosis Safe. We can see the contract in here. This is the Nosis safe proxy. If you want to be extra safe, you can actually verify that this smart contract does indeed match the Nosis safe proxy in the GitHub associated with this. Uh we can also see the contract creator here. We can see who actually made this call, who actually deployed this smart contract.
But so one thing, if you're going to be using a serious smart contract wallet, I would definitely recommend verifying that this codebase here matches this contract matches the deployed by code of source code contract here. This is indeed the smart contract wallet you want to be working with. For the test net, we don't have to worry about that too much, but for real money, be sure to check that out. Now, we're in our interface here. Boom. This is it. And there's a lot of stuff to do here. So, if ever we want to connect to an application, we would use either one of the apps. Again, these are thirdparty apps or we can just use wallet connect.
So, for example, if I wanted to go to unis swap, go to unis swap, launch the app right in unis swap, I can hit connect and this time I'm going to say wallet connect and this will give me a wallet connect. I'm going to copy this link here. Go back to my safe and I'll hit this little wallet connect button. Paste it in. Hit paste. I'll approve. Oh, let's go ahead allow that. I'll approve. And after a second, what'll happen is this little wallet connect icon will say we're connected to unis swap. And then back on the unis swap site, we are now connected to our smart contract wallet, which is over here. So, we're not going to be connected to our MetaMask. We're actually going to be connected to our smart contract wallet.
But here's where it gets a little bit tricky. So, our wallet here currently has no money. So, I'm going to actually send our wallet some money from our MetaMask. So, I'm going to do send it. Oops. So, I'm going to copy the address. Get rid of this se bit. We're going to send it one Solia ETH. Next. Confirm. Once this goes through, we'll see one Sapoleia ETH in our newly created smart contract wallet. Right. So, now that that's gone through, we actually see we have well some money in here, but it's not real money. It's Seapoleia. But now back over here, do a little refresh on the unis swap side. Our smart contract wallet now has some ETH in it. Now, if I wanted to swap ETH or 0.5 ETH or maybe like die on this test net, for example,
well, looks like unis swap only works with a real network, so that's no good. But if we were to send a transaction here, we were to send one ETH, maybe want to set and one ETH for some die, we would hit the approve button, and over in our safe, we would actually get a transaction would pop up. We would go ahead and hit approve. And then the owner, one of the signers here, would be this wallet. And we'd approve in this, which would approve in our smart contract wallet, which would then send the transaction. We can actually do that by hitting assets. And we can actually test doing a little send here. So, we're going to send back to our MetaMask. So, copy our MetaMask address, paste it in here. We're going to say 0.5 or 0.75
Sapoleia. We're going to hit next. And this is what a transaction in your smart contract wallet, your safe wallet is going to look like. It's going to have a nuns. It's even going to tell us a little bit about what it does, right? So, this is just a send. There's no data here, right? If there were data, this would be populated. And then, of course, we could use that data to actually verify that the transaction is doing what we want it to do. We can simulate it with Tenderly to make sure the transaction will actually go through. And then, we could say, hey, do we want to execute it since this is a one of one? or we could say no later and we could just sign it. If there were multiple signers needed, we would just sign it and then have to wait for
everyone else to sign it in order to send it. I'm actually going to do connected wallet here just to show you what this will look like. So, we're going to go ahead and hit execute. We're going to execute this transaction. MetaMask pops up and this is because MetaMask is the signer. We can see the hex is kind of this weird exact transaction thing. Whenever you send a transaction in a smart contract wallet, one of the signers is actually going to be the one to send it once everyone has actually signed it. And we're going to have this exact transaction which has all this stuff. Because it's a smart contract wallet, we actually need to tell it which address to make a call on.
What's the data? What's the function selector? And we have all these parameters we need to tell our smart contract wallet. For example, we wanted to interact with unis swap. We'd say, "Hey, send unis swap. Call the swap data function. use the swap function selector blah blah blah. We would need all that data in this exact transaction bit. But once you've verified the data, once you've verified it looks good, we can go ahead and confirm. Transaction will actually start processing and our meta mask. We can actually go ahead look in our MetaMask. Click this view on block explorer. We can see our MetaMask is actually sending this transaction to our smart contract wallet. So it actually makes a call to our smart contract wallet, which would then make a call to unis swap or whatever app that we're working with. In this case, it's just a
call to our smart contract wallet to send the money. And then once it's done, once it goes through, we will now see in our MetaMask or whatever wallet we're using, boom, the new value. And we'll see our wallet has gone down in value and we have successfully sent the transaction. So, the Safe Global app has a bunch of amazing features in it. As security-minded people, you definitely want to take the time to doublech checkck the transactions in here. Don't trust the UI, trust the code as normal. But now hopefully you have a smart contract wallet set up. If you have mainet funds, I highly recommend you setting up a smart contract wallet to work with those mainet funds as well. So now you know a little bit more about the basics of using a smart contract wallet.
And at the end of this, you will set one up and congratulations, you now have a general understanding of what to do. Now, for one step further, if you have a smart contract wallet, I highly recommend using hardware wallets as the signers as opposed to hot wallets. Why? Well, because again, they're airgapped, a little bit harder to access, etc. And then the last bit of what you can do is you can of course use your own tools. You can roll your own tools. You can roll your own private key. You can roll your own key handlers. You can roll your roll your own cryptography functions.
However, don't do this unless you really absolutely know what you're doing because you can screw this up a lot. Each of the above options has some issues, right? There's some dependency. There's some verification you need to do and if you run your own tools, maybe you're the only one who knows how they work and that's kind of a layer of security in itself. Although a lot of people would argue that obscurity through obscurity is really bad and I would actually agree with them. But there's a number of other options that you can take too. You could do what's called a brain wallet where you literally just have your private key committed to memory. A paper wallet where you only have it written down on a piece of paper. That's it. You could use your own self- encryption tools. And and there's even more advanced setups that
you can get depending on your threat vector. For example, maybe you rotate your keys between some self- encrypted databases every 6 months. You have keys stored all over the places. Maybe you have some social backups. Whatever security solution works for you. Of course, if you're going to do something really novel, I would definitely recommend having a security expert check it out to make sure you're not doing anything ridiculous. Pros: A, you don't trust anything except yourself. Cons, this can be very difficult to do and you really need to be an advanced user to use your own strategies.
And last bit, here's just a couple of tips on good private key management. Number one, don't tell people how much money you have. Try to not dox yourself. You see a lot of profiles where it says like my ens on their profile which just say, "Hey, here's my ETH address and you look in it, it has like a million dollars." Don't do that. One of the first steps for a hacker to take is going to be to pick a target. So, ideally, keep a low profile and don't make 32 to 50 hour videos teaching people about smart contracts. Should you get a hardware wallet from a hackathon?
Absolutely not. Absolutely. Absolutely not. You should only buy hardware wallets directly from the company/ vendor or official resellers. Be sure to make sure the official reseller is actually official. Hardware wallets from a hackathon, from an event. They could be tweaked. They could be meddled with. Do not use them. Can I use the same private key for years? You can, but it's better that you rotate them. You swap them out for different ones. This again is why multi wallets like Safe is great. You can keep the same address, same wallet, but just change the signers. Maybe ideally every 6 months, 6 months, every year or two, whatever you want to do, you should do a security review of your keys. Where are my keys? Where is my money? If my house burns down, will be I be able to recover my crypto. And
here's the next exercise. Take out your calendar and set a recurring event where you review your keys every 6 months. Take maybe 3 4 hours. You just say, "Okay, where are my keys? What happens if my house goes up in flames? my computer breaks. Do I have a backup? Is my key being shared too many places? You do a review. You figure out what's best for you. Some tips about where to back up your secret phrase, your secret key. Uh, I want to say this out loud, too. Never take a photo of your key. Never upload it to the cloud. Don't text it. Don't email it. Don't give it to your cousin Jared who's known for gossiping about. And then most importantly, if for even one second your key is lost, shown on screen, potentially accessible by somebody else, consider it compromised and start moving your money to a new
wallet or swap out that key, etc. Even for one second. And another tip on wallet safety, wallet hygiene, is to not store your private keys, especially in plain text, in a password manager, especially a cloud password manager. A few months ago, a ton of private keys were getting stolen, were getting hacked, and people were getting their crypto stolen from these private keys and and people were racking their heads of how did this happen? How did these private keys get stolen? These were really cryptosavvy people that seem to have lost their private keys. And it turned out that and it turned out one of these password managers, Last Pass, actually disclosed a breach where hackers stole password vaults containing both encrypted and plain text data for
more than 25 million users. Some of those users had stored their private key into LastPass and hackers got in, took the private key, and then stole all the crypto. So ideally, you don't store your private key in a cloud provider. If you absolutely must, then make sure it's encrypted so that even if LastPass gets hacked, then the person just has your encrypted data. That's at least one step better. Remember, you want to constantly be asking what if, what if, what if. There's a lot of people who say, hey, if you store it encrypted in these password managers, that's fine. A lot of people say, oh, the AWS secrets manager, that's fine. Just remember, who are you trusting if you put their keys in the cloud or you trusting the cloud provider a little bit? So, keep that in mind when
you're assessing your threat vectors. And with that, we now have a basic understanding of smart contract wallets, smart contract wallet security. We're going to have a bonus section that you can watch with an interview that we did with Wallet Scrutiny. They are a team that reviews Bitcoin wallets and checks to see how good those wallets actually are. They don't do EVM or Solidity smart contract wallets, unfortunately. But the same methodologies that they take to reviewing smart contract wallets, you can take those, you can apply them to Ethereum and to ETH or EVM smart contract wallets to make sure that you stay safe. Hello, my dearest Siphon Updraft students. Now, we're actually going to show you how to verify signatures and transactions using a safe multisig. If you want to, I highly recommend you use a hardware wallet and
practice just trying to execute random stuff on your safe multisig and actually verify the signatures in the hardware wallet with the methodology that we're about to show you. At this point, you should have a safe multisig set up. And now I really, really, really, really want you to follow along with this video and send some type of transaction. So in the safe UI, there's a transaction builder. Send some type of transaction, sign the transaction, and actually make sure you actually understand what's going on. So in this next section, in this next video, we're going to walk you through step by step how to actually verify these transactions, how to actually verify these signatures using a hardware wallet. Now, if you don't have a hardware wallet, that obviously becomes kind of hard. So, highly
recommend you go out and you buy a hardware wallet. If you don't have a hardware wallet, but you still want to watch this, this is still great to watch so that you are aware of the tools and the methodologies available and bookmark this video so that when you actually do need to verify a signature, you can just come back to this video, follow along with the video, or follow along with the tools that we're going to show you here. So, have fun. $50 million is how much you could lose if you don't understand this. The Radiant Protocol signed a safe multisc transaction without verifying it on their hardware devices and it cost them $50 million. You absolutely need this knowledge if you want to be on a security council, being a delegate on a DAO, being on a DevOps team or a response team, or if you have any money
and you want to make sure you don't lose it. Multisig wallets are incredibly popular because of their phenomenal security principles. So, you need to be able to know how to actually verify that what you're signing is what you want to sign. This is especially for the security researchers and the developers who are going to be signing and initiating transactions. There needs to be at least one person who knows how to do every single step we're talking about here and understand it deeply. Now, in this video, we're going to teach you how to verify your signatures and then also verify the execution of these transactions on your hardware wallet.
So, let's get started. Now, the first thing that we need to get all this started is we need to go to the Ciphern SafeTx hashes GitHub repo to download the tool that's going to help us and decode the data to verify our transactions. This was originally based off the work from this repo here. And if we scroll down in here, we can go to the installation and you can either build from source or grab the curl. So, I'm going to copy the curl and open up my terminal to install the tool and paste it. But wait, the biggest thing I want you to take away from this is learning what to trust and what not to trust. And running random arbitrary code on your machine is not the best idea. So, I just want you to keep this in mind as we go along here that you should always be
considering what are the security assumptions of what we're working with cuz especially when it comes to signing and verifying transactions, you should absolutely know who you're trusting. What's important about this entire process that we're going to be following here is that we want as few dependencies as possible. We want to make this as difficult for hackers to hack us as possible. So if you want, you can of course go to the repo, go to the install script, and view the install script yourself to make sure it's not doing anything malicious. Or if you want to be even more paranoid, because being paranoid is great, you can build from source yourself as well. But let's say you want to use the script here. After it runs, it'll have installed it and all you'll need to do is source your shell
path or just exit and reopen your shell. Once you do this, you should have the tool installed and you can run safe hashes-v to see what version you're on. We can additionally run safe hashes-help and we can see all the different usage and the different commands we can use as well as some examples of how to actually use this tool. So now that we have the tool installed, we can come back to our safe and we can initialize a transaction. This can obviously be whatever transaction that you want. pretty common transaction that you might want to send for example is you want to take a ERC20 token like the USDC token and you want to approve a D5 protocol for example the unis swap v2
router so you could of course initialize this from a UI using wallet connect or we could even just go straight to the transaction builder and we could do this through here this will import in AI there is a little bit of a risk here but approved transactions are pretty small so we should be able to very easily see what's going on here so I'm going to say okay I want to take the USDC token address and it's going to actually import the ABI. If we wanted to, we could put our own ABI here as well. And what we want to do is we want to say, okay, we want to approve the Uniswap V2 router for, you know, 10, which is secretly 0.001 USDC or something like that. You get it.
I digress. So, we want to approve the Uniswap router to do 10 USDC. So, I'm going to go ahead. I'm going to select add new transaction and create batch. And this is the only transaction that we're going to send, meaning this is the only batch we're going to send. I'll hit send batch. And the safe UI is actually pretty clever. It says, "Hey, uh, it looks like you're trying to allow access for tokens. Here's how much. And here is the spender, which is great. It gives us the advanced details, which are the ones that we actually care about, which are right here, and a whole bunch of other stuff. Now, the important bit for us, though, is obviously signing this. So this is an uninitialized transaction.
This transaction doesn't exist anywhere. This transaction is not in the database. The first way we're going to verify the signatures here is directly using exclusively the hardware wallet. We're going to learn later how to also use a MetaMask wallet to help with the verification. So I'm going to go ahead and connect. And once we get it unlocked, can actually now connect here. Now that we're connected with Treasure, we can go ahead and sign this transaction. Now, the main thing that we want to trust is our hardware wallet. We don't want to trust the safe UI. We don't want to trust Etherscan. We only trust what's on our hardware wallets.
So, keep that in mind as we go along here. So, once we hit that, I get a little popup. I'm going to say go ahead and allow here. And my treasure says, "Okay, we're going to sign a transaction." Now, looking at this address in here, this is indeed my address with my treasure. And this is Treasure telling me here is who's going to be signing. And I say, "Great. I would like to continue. And here's the most important piece. It gives us this confirmation message. And if you're working with a wallet that doesn't give you this, throw that wallet away immediately cuz this is the most important thing that we need to work with here. What this is is this is the hash of the message that we're going to sign. And this is the most important thing that we need to verify before
actually hashing it. So if we pop back over to our tool here in the GitHub repo, there is usage for not initialized transactions. So what we need to do is we need to verify that this hash matches what we're expecting to sign. And remember what are we expecting to sign? Well, we're approving 10 USDC on the unis swap router. The first thing that we can do is we can trust the safe transaction service API with this command. and then we'll also show you a way to do it without this command. So we can scroll down in here to the section safe message hashes. Now what this script is going to do is it's going to call the safe servers and basically ask for the data inside of this transaction
so that we can verify it without have to manually input the data ourselves. This is relatively safe because if the safe UI gets hacked, whatever they give us will obviously not match what's on our hardware wallet. There is a bit of a trust assumption here on the safe transaction API. The safe API goes down, well, we get in trouble. So to get all the data prep-populated from the safe API itself, we pull up our terminal and we run safe hashes- address. And we pass in our address of our wallet, our safe wallet here. We got to get rid of this ETH thing. We do d-network ethereum or whatever network that you're on. And then we do d-nuns and then we
pass in the nuns and we hit enter. Now since this transaction is uninitialized we get no transaction is available for this nuns. So we have to add d- untrusted in here because this is a quote unquote untrusted transaction because nobody signed it yet. It exists right here but it's not a signed transaction. But at the bottom here we see what's actually important. We see this safe transaction hash. And this is what we want to verify is on our hardware wallet. And if we go over to the hardware wallet, we want to compare this hex to what we see on the screen here with our safe transaction hash. Now, you can still mostly trust the safe UI because if a hacker were to
manipulate the data, the hash would be different. And this is also why on screen we also want to look at the parameters, we want to look at the call data, etc. So this is indeed the address we put in. This is indeed the value we put on. So the parameters here look correct. If it didn't have an AI, we could do the raw call data, which we'll do in a second. So we look at these two, we compare, and they look good to us. Now, this comparing process is obviously kind of annoying cuz there's no way to like copy paste this and like check it on your screen. So this brings me to one of my first improvement asks for wallets. I wish there was a way for me to maybe grab a base 64 QR code or something off of the wallet so I could
easily copy paste it onto my machine so I could compare more directly because right now I kind of have to eyeball spot check. Now some wallets make this a little bit easier and we'll see an example of that in the future. So after I manually confirm that this signing message is exactly what I expect, I can now on my treasure I can hold to confirm or do whatever approval that is required on your wallet. And then back on screen we'll see we have indeed created a transaction that we have signed in our safe wallet.
What if we were extra paranoid and we didn't want to use the safe API? Well, in that case, instead of passing this in, we could just get rid of the untrusted and instead we would pass in the raw hex data of what we expect this transaction to be. We would need the exact hex call data, which we can get using cast call data, which requires a signature and then any data. So we're going to say cast call data and we're going to call the approve function. Going to take an address and a UN26. So we'll say address UN26 like this. And who are we approving?
Well, we're approving the unis swap v2 router. So we'll paste that in here and for 10. And then we hit enter. And this is the call data that we would expect. Now, with this call data here, I can go back up to my safe hashes command. I'll get rid of the untrusted. I'll do d- data. Paste in here. I'll do d- offline to say we want to stay offline here. And then I'll do d-2 and give the two address going to be the USDC coin address. And I'm just going to copy the address right from the safe UI.
If you don't trust the safe UI, you can obviously go to Etherscan or the official Circle Docs. Paste that in here. Hit enter. And now we get the exact same safe transaction hash created for us. But instead, we did not use the safe API. Now you'll notice it says skipping decoded data since raw data was passed. We do not get the AI here because we passed raw call data ourselves, but we get the transaction hash. And so once again, we can manually spot check. And this is indeed the same thing. So now that we've already initialized a transaction, if you want to use the safe API again, you can just do the exact same thing. Just remove the untrusted and boom, you would hit enter now. And
we once again get that exact same transaction hash. So any other wallet now that signs would just sign with this. So let's go ahead. Let's do this again for a different signature. I'm now connected to a completely different wallet, a Ledger Nano X. And we can see on my safe UI that I need to confirm this transaction. I can go ahead to confirm. And my recommendation is always going to be no later. Hit do not execute first sign and then execute separately cuz the process for verifying the execution is different. But we're going to follow pretty much the same pattern here. We're going to hit sign. Back over in our Ledger wallet, we're going to be asked to review the message. And here
once again, we're going to compare this to to what we saw in our output from our script. We're going to make sure that this exactly matches what we see from our script. And you'll see that some of these wallets have different outputs. Now, the Ledger Nano X is a bit odd in that it uses this weird binary string literal, which we've added here in our script, so you can compare against that. Uh we've also asked the ledger team to update to a regular hexodimal hash because this format is bizarre. But we can once again compare and contrast to our script. We can see that this does indeed match. So we can feel confident to sign the message.
Now, for some wallets, like what we're showing here, the Keystone wallet, if we want to connect, we don't get an option for working with Keystone. So, what we can do instead is we can go into our MetaMask wallet. And just keep in mind, this does put a dependency on MetaMask. However, we're always just going to trust what's on screen on our Keystone. For the Keystone wallet, I'm going to go ahead. I'll select the little three dots. Connect software wallet. Select MetaMask. It's going to give me this QR code. that I'm going to select. And then in my MetaMask, I'm going to go to my accounts, add hardware account, add hardware account, QR based. Scroll down, hit continue, allow to use my camera, and I'm literally going to show this QR
code to the screen. It'll be blurry, and that's fine. And it'll pop up a list of wallets associated with this wallet. Now, what's important to note is we are not exposing our private key. We're simply just telling our MetaMask what accounts are on our keys store wallet. So I'll select the wallet. I'll hit unlock. And now it says keystone one. And it is now in our MetaMask. And you can see it as one of our wallets in the MetaMask. So what we can do once it's in, we'll hit connect. We'll do MetaMask. Now I'm actually going to have to switch to the Ethereum network. And now same thing, we could execute or we could sign a transaction here.
So this is great. Everyone has signed this and we're ready to execute. We have two of three here. All we have to do is execute. Now question is how do we verify this is now correct. Now once I hit execute, this is where it gets a little tricky. But if you've followed along with cipher updraft, you already know how to verify call data when it comes to a basic transaction. And if we look on our treasure, we can see the call data for this transaction. Now, we do obviously want to make sure that this transaction that we're sending on our hardware wallet is actually what we want, right? What's nice is we can see the top four bytes here. This is clearly the function selector for the execute transaction for the hardware wallet,
which is good. But we obviously want to, you know, verify all this call data. And on this specific wallet, that's kind of hard to do, right? because this is kind of a massive massive piece of call data. Uh there's a lot here for us to spot check and read. And additionally, we're not exactly sure what this call data should even look like. First of all, we should verify what this call data should exactly look like. We could do cast call data decode or straight up call data exact transaction and then add all the parameters in here so that we could get the resulting call data. Uh I even have this saved locally on my device. So I can grab this very easily cuz this is the function signature of the safe multisc. Now that's obviously going to be kind of timeconuming and is really
rough. So what we can do instead is we can one more time run our safe hashes script. But now we add this print mst for multic transaction call data. Hit enter and we'll now see pretty much everything we saw before. We see the safe transaction hash again. But now we additionally see the full transaction call data as well. And we can still scroll up. We can see the parameters. We can make sure the parameters still make sense. Those indeed still make sense for a multi-IG transaction. And now we can see this. So now we can much more appropriately view all the call data and match it back to what is seen from our script. Now we can actually see on our
call data here. We can see for example this does indeed match the function selector of the multisig transaction call data from our script and we can actually show all and we can go through all the call data and make sure it actually matches. Now, of course, this is kind of awful manually verifying all this call data, but we can have at least some assurance by checking the two and the function selector because at the very least, this will be a transaction to our multisig safe. And that by itself gives some assurance that we're not signing something malicious on our transaction. It's at least a function of our multisig. However, this still isn't great. back on our Ledger wallet, if at least we go to settings, we can actually turn on debug contract, which will give
us a little bit more assurance of what we're doing. So now, if we hit execute, this is a little better, but it's still rough. We can at least verify just the selector, which that's the function selector. We can approve that. And then we can actually manually go through each field of that exact transaction data and manually confirm this as well. Go through and keep confirming. Now, this is much better, but obviously this is still very tedious and we will very quickly run into security fatigue where it takes us, you know, 25 minutes to send a transaction. For these types of wallets, what you might still want to do is actually go ahead and connect it with your MetaMask again. So, go ahead add hardware wallet for example with Ledger.
I'll go ahead and connect this. We'll continue. I'll connect here. I will unlock my account as well. And now back in my safe wallet, instead of connecting through my ledger wallet, I'll disconnect here and I'll connect directly through MetaMask. At least now, and let me switch to the away from the Keystone to the ledger. At least now when I hit execute, MetaMask will at least pop up and give me that transaction data. So I can scroll down, I can see the data. I can very clearly see everything very quickly. If I wanted to, I could even click the copy button.
I could go to something like a new window and then I could paste the call data and I could view the call data right here. And then I could compare this very easily with what my script gave me. So I could just copy this, flip back over here, paste it in, and do a little command V to check that these two are indeed the same. What we get from MetaMask and what we get from our script. We're still trusting MetaMask a little bit here. So it would still be better if we could do this directly on our device. However, when you go to confirm this, you can at least confirm okay that the parameters look the same here that are what in MetaMask that the hash looks good, etc., etc. And it's important to note that the last bit
might be a little bit different because this is just all the signatures added up and it doesn't really matter the order that these signatures are in. One last bit that's really nice when it comes to your wallet choice. If we use something like Keystone, we can we still connect to MetaMask, but we at least don't have to trust MetaMask. So, what we can do change to my Keystone here. What we can do is we can execute while my Keystone wallet is connected to my MetaMask. And what I can do is once again, I can review all this data in the MetaMask. I can confirm and everything.
When I hit confirm here with my keystone, I can go ahead and click the little scan thing where I can scan this. can literally raise my device to scan the MetaMask code and this will send the transaction details to my Keystone wallet where I can see everything such as the from which should be this wallet, the two which is the multisig. I can select the details and I can see everything that I could see in the MetaMask right in my hardware wallet here without having to actually trust that the MetaMask is being honest. And even though we're interfacing with MetaMask, we don't have to trust MetaMask because we can verify what we're signing right on the device. But in any case, once you're happy, you can send the transaction with the knowledge
that you're actually going to send the data that you want to send cuz you know how to verify these transactions. So to recap, whenever you're signing a multi-IG transaction, make sure you verify the hash of the signature that you're signing. You can do this using the script that the Siphon team has built. Big shout out to Pascal for being the initial creator of this script. You can do it with our script by either trusting the safe AP AI which is a little bit quicker and you still don't have to trust it that much because if the data they send you is manipulated the hash will be different or you can say I'm just going to manually do this myself. Use offline mode and generate the message hash there as well. Then once you have enough signatures verify the execution of the transaction itself
with the call data. Now, if you are a hardware wallet company, I have a couple of asks for you. Number one, you should all add clear signing, like what we saw with the Keystone wallet, which had clear signing, so that I could directly see what was going on with my transaction right in my hardware wallet without having to integrate with something like MetaMask. Number two, it would be cool if we could export the call data so that we could match it to the tools that we write. For example, maybe add a QR code that allows us to scan the QR code on our hardware wallet so we can import into where we use our tools and then make sure that it works the same there.
That's also a little bit spooky to me because scanning QR codes is very spooky. So maybe there's something more clever that you can do. And if you do do a QR code, you should have it be like a base 64 encode so it could work in offline mode. Like that would be even cooler. I digress. Additionally, it would be cool if you showed the hash of the call data because that would be much easier to spot check than the entire call data. So, that's another ask that I think might be very helpful here. Private key attacks are the number one attack vector from last year, and they're looking like they're going to be the number one attack vector for this year. Use this to stay safe, and we'll see you next time. I lied to you. I made this video saying it could help protect
you from $50 million, but it should have said $1.4 billion. The BBET exchange was hacked for $1.4 billion. And here's the CEO talking about what happened. We were doing a a regular code wallet transfer. Bybit uses safe, which means we use the the safe product is the safe.global. I was the last signer of this transaction. When this transaction came, it was a normal URL. I double check and then I checked on the UI the destination address. All of that checked out. So I clicked on sign. So after I signed and I also checked the ledger screen. So, I checked the code, but I didn't check fully. After I signed in 30 minutes later, then we got the emergency call.
So, we're going to be showing you exactly what the transaction was and how the hacker put together the transaction to do this hack. And then we're going to speculate on how this hack actually happened. So, if we go directly to the transaction that this CEO or co-founder linked, we can see this is just one of the malicious transactions that was called. This is a sweep ETH transaction. And we can see that around 400,000 ETH was transferred from their cold wallet to the buy bid exploiter. Yikes. But it gets worse. If we go to the actual cold wallet and we scroll down to the list of transactions in here, we see 13 hours ago this exact transaction. And being familiar with the safe UI, I know that this exact transaction is how you initiate any transaction on your
multisig wallet. But above these we see sweep ERC20, sweep ETH, sweep ERC20, sweep ERC20, sweep ERC20. So it's these collection of five transactions that were the ones to actually steal the money out of the multisig. And it was this one that was most likely to have given the hacker access to actually steal all the funds out, right? And if we look at some of these transactions, we can very quickly see how much each one of these stole. We can see this one stole $90. So probably a test transaction. The next one was the 400,000 ETH that was stolen. The next one for 8,000 ME, around $22 million.
The next one for around 250 million ST. And then a final one for around 52 million CME ETH. So in total around $1.4 billion. Now to see exactly how this hack happened, we can go directly to this transaction here and see what the hacker actually sent. So if we scroll down in here, we can go to more details. we can see the actual input data of this and if I decode the input data we can see all this information here and this is the input data to the multisig contract itself. So whenever you want to call a transaction on your multisig you're really calling this exact transaction which has all the data that you want to send a transaction. So, for example, if you wanted to send some money from an ERC20 token, you would
say, okay, I'm going to have my two address be the ERC20 address. I'm going to have value be zero, and I'm going to have the bytes called data to be the call data for a transfer function. Going back over here, we can get tipped off to some of the issues that this transaction has that the signers didn't catch. And we'll talk about why they didn't catch it in just a second as well. We can see first off, the two address is this address here. And this is kind of one of the first kind of confusing things that can make it a little bit tricky for users to get slipped up here. Now, the two address is this address in the input data. However, the actual two is to the multisig. Now, even here is where it can get kind of tricky because on your wallet, the wallet's going to say, "Hey,
the two address is the multisig address." And that is correct. You are sending a transaction to the multisig address, but that multisig is then going to call some other malicious address. And that's actually going to be hidden in the data over here. So if all you did was spot check the two address, you would see the two address being the multise and you go, "Oh, okay, cool." Like that looks good to me. But that's not enough. So hidden in the data, we have 2B this other address here. And if we click on this address and we go to this address here, we scroll down in here. We can see this was created 3 days ago. So this person was prepping this for 3 days. We can see in the contract, this obviously isn't verified, but it's this incredibly minimal contract. This code is actually small enough. There's
like barely any bite code in this that I could literally take a day and I could read every single one of these. Like this isn't that hard to decode. So, we're sending to this transaction and we're sending this data here, which I'll get to why this is actually kind of clever. This operation being one is the next thing that should absolutely been like, holy we cannot do this. So, in the multi-IG contract, if operation is zero, then it's just going to be a regular call, right? These are a little bit safer. But if operation is one, it's going to be a delegate call. And so if we go back to the actual transaction here, we can see the operation is a one, which means that we're going to be delegate calling whatever function this random contract is doing. So basically,
we're trusting this random contract to do whatever the hell they want, which is obviously bad. And then the rest of the parameters are pretty harmless. And then we can see the actual signatures here. Now, we can see a couple more interesting things here on this exact transaction on Etherscan. We can go up to state and we can actually see the differences in the contract's state that were changed. Obviously, in a proxy contract, all of the state is stored in the proxy contract. And we can see that a couple of storage slots actually did change. So, we can see storage slot zero changed and storage slot five changed.
And we can actually view this even easier outside of Etherscan. Using cast, I can actually call cast storage on this contract address and pass in the block right before this was executed and cast will attempt to get the correct storage layout based on the verified contracts. So if I hit enter here, this is going to give me a horrible formatting. I know this is super tiny, but essentially you can see that at storage slot zero, we see this master copy variable set to this value here. And if we grab this, we pop this into Etherscan. First off, we can see that matches what we see here.
And if we paste it in here, we can see this is like a regular safe master copy. Basically, a safe implementation. This is like a good solid piece of code. However, after this transaction is executed, we see this implementation changes from this to this. And this is actually where Etherscan I don't love because if we go back to the actual contract address, if we go to contract, it says read proxy. It still shows the old implementation here. However, that was actually changed that was updated to this address which if we paste this in etherscan we can see that this is indeed a new malicious contract. But essentially we had this setup where the
proxy calls the safe which called malicious one. This had a delegate call which basically told our proxy uh hey the new contract the new safe contract is this one over here and this is going to be so now you should instead point over here to malicious 2 which had all this malicious functionality. So that's essentially what happened and the transaction itself is not that sophisticated, right? It's pretty basic and this is also like I said where I don't love Etherscan cuz Etherscan says hey AI for the implementation contract at this address. However, we can see from here the state was changed the implementation was changed. And if we pull back up our cast here, we can now do a little clear run that same cast
storage call but update the block to the block right after the hack happened. And we can see even the cast tool tries to fetch the source code from the wrong contract. But in any case, we can see that the master copy at slot zero has now been changed to this different value. And if we pull this over, it's been changed to this new address. This is also why we should maybe get in the habit of using block scout. Block Scout actually correctly knows that this is a proxy contract and actually uses the implementation of the contract itself and knows that the implementation has changed. Also, Block Scout is open source. So maybe an additional reason to use Block Scout here. And then additionally, what was kind of cool
about this is if you decode the input data, this right here, this piece of data is the function selector for the transfer function. So it looks like this is going to call transfer on some contract address. However, this is obviously a malicious transaction that's not actually doing a transfer. And if you go view this in the decoder, you scroll down, you see the go to the byte section, it says decoded. It just looks like it's oh function transfer address 2 and amount zero. So it looks kind of harmless, right? Except for it's not kind of harmless because it's not actually doing a transfer function here.
There is this little little bit here saying, "Hey, this might not actually be what it does." Haha. And like, yeah, that wasn't what it did at all. So, the transaction itself, pretty basic. A delegate call to a malicious transaction saying to upgrade the implementation of the proxy to a new one, which they have access to where they can steal all the funds and do whatever they want. So, before we look at how this probably happened and how this could have been prevented, we can actually look at some of the keys here that should have tipped these signers off. Number one, we see the address here is clearly wrong. Right? The way to have seen this was you read the data from the exact transaction. You see that it's you're sending a transaction to this weird address. Okay, that's super weird. Uh we shouldn't do that. Then the data itself
almost doesn't matter because this should have already tipped you off. But obviously like decoding the data here was just like an extra step these hackers used to possibly trick people like, "Oh, it's just a transfer. Haha, it's all good." Wasn't a transfer at all. But then the other thing that absolutely should have set off alarm bells was the fact that this was a delegate call literally means the users can have your proxy do whatever you want. So this operation should have been a zero and that would have tipped users off as well. And the rest of these are whatever. And in that video that I referred to at the beginning of the video, you can and should absolutely verify all these in your hardware wallet and not on your computer screen. And that was the step that they skipped. So the question is, how did this happen?
How did they get access to being able to do this? Well, if we go back to our cast, we can look at how the multic was set up right before the hack actually happened. Uh, excuse me. We can see the owner count had a value of six. So there were six owners and the threshold was three. So it was a three of six multisig. So the hacker needed to hack three different users in order to send this transaction. Looking at these signatures section, we know that the signatures are actually just concatenated strings concatened into signatures. We could count the number in here and we know that a signature is going to be around 65 bytes or 130 hex characters. We know that this is basically three signatures. So what this tells us then is at least three wallets signed this malicious data and at least
three wallets caused this to happen. And that's where we have to start the speculation because we're probably never going to get like a true postmortem. So basically the co-founder says it appears that this specific transaction was musked. All the signers saw the Musk UI which showed the correct address and the URL was from safe. But basically they're saying hey on the UI we saw all the correct stuff like it didn't say we were sending to this random wallet address. It had all the correct stuff. This looks like nearly the exact same attack that happened for the War ZX exchange or the Radiant Capital hack and now the Bybit exchange where they said, "Hey, the the the website showed me the correct information, but when I went to my wallet, I signed the wrong thing." So,
it looks like it's almost exactly the same type of hack. Big shout out to Zack XBT who basically traced this theft back to North Korean state sponsored threat actors. So, it basically looks like they're running the exact same playbook. North Korea said, "You know what? hacking smart contracts is getting too hard. Let's just hack the humans. Humans are way dumber. And that seems to be working. Now, the thing that makes this kind of frustrating for me is that literally a few weeks ago, I made a video on how you can actually prevent this type of hack with some caveats. Of course, the safe team actually sprung into action here to help figure out what went wrong if it was an issue on their end. They found no malicious dependencies or no malicious issues on their side. So it was probably the users of the buy bit exchange that were hacked
instead. And most likely this was the setup. Their computers were hacked. So on the computer screens when they went to the safe website, it showed them, hey, this transaction is actually good. And when they said, okay, hit send. The data that was actually sent to their wallets because their computers were hacked was the bad transaction. And there's a good chance that whatever wallet they were using just showed the raw data or blind signing, if you will, instead of the decoded data or the clear signing. And so the user just said, "Well, I don't know how to decode this. Sure, looks good." And sent it. And this is where the hack actually is sophisticated. How were they able to hack three different users computers and know all three of them weren't going to check the signatures and weren't going to check the transactions? And this is
where we can speculate more. Maybe all three devices were the same device. Maybe they were all in the same room. Maybe was an inside job where somebody on the inside sent them list of transactions. There's lots of different ways we could speculate here, but this is where, in my opinion, it is more sophisticated. if they actually hacked the computer and did something really clever there. So, based off that being the issue, there's a number of ways we can solve this. Number one, you can kind of do this the raw and badass way. And if you're a technical person, if you're on a security council, if you're on incident response team, you absolutely must know this because well, it's not acceptable for you to be caught slipping, right? And understanding how to decode call data is really important anyways for you very technical people.
So, watch that video, learn that video, and don't sign transactions on your multic unless you follow this up. Now, some other people in protocols have been talking about just making sure your wallets must absolutely be able to clear sign and not blindside. And I agree, all wallets should absolutely have this anyways because it's kind of crazy to have to decode every single piece of data on your harbor wallets, but it must be in the hardware wallet itself. Props to Keystone actually for adding this. And some people want to go even further saying, "Hey, we need human readable transactions," which I actually think there are a lot of issues with. Human readable transactions are susceptible to frontr running attacks. So the human readable thing says, "Hey, you're going to get 10 ETH back and you only get five because you get front run."
Additionally, we saw in here, for example, the decoded transaction said, "Oh, this is safe. It's just calling a transfer function. No problem." Now, obviously, the fact that the two here was wrong. That should have tipped people off. But I digress. There are still risks associated with just purely being like, "Hey, we need to make these more human readable." But yes, I do agree that walts should not have blind signing. That is a huge issue and you should not be blindsiding at all. And as always though, there is no foolproof solution. As Tavano so gracefully puts it, to some extent, if a hacker is sophisticated enough and they get access to your devices, you are. If your wallets do not have clear signing capabilities, you must know how to decode the call data yourself. And if
you do not know how to decode the call data yourself, you should not be signing transactions on a wallet that handles $1.4 billion. Yes, the web 3 community needs a lot of improvements in this area because we keep seeing this type of attack, but until we have those fixes in, you should not be signing anything on your wallet unless you actually know what the transactions are doing. That's it. Hope you learned something. All right, so at this point in the course, we've set up a safe. We've learned the basics of verifying a safe multisig. Now, let's go ahead. Let's actually go through a demo ourselves and then I highly recommend you take the time to try to go through the entire
wise signer challenge and get a 100. Get every single one correct. So, I'm going to go ahead hit play now and I'm going to skip ahead to question 11 in here. And so, here we see sign or reject this signature. And there's going to be a number of ways that we can solve this. So assume your wallet is this wallet and you're a signer on a valid multisig at address here using safe version this. You're attempting to send one to address so and so on the arbitrum network. Please sign or reject the transaction if doing so will bring you closer to executing. So here we have a basic safe UI and this is indeed what a safe UI would look like. Let me go ahead and get rid of myself here. So I'm going to go
ahead and hit next. And this is indeed what the safe UI might look like. It would have all the transaction details here, which is great, but I don't really trust the website. So, I'm going to go ahead and hit sign. And we see my MetaMask pops up with some signature information. Now, there's a number of ways that we can verify this. Let's first talk about what this is. So, this huge chunk of data is known as the EIP712 strct. And this is actually what we're going to be signing. We're basically going to be hashing this into a hash and then signing that hash on chain. What we can do is we can copy this, bring this into an editor of choice. I'm going to go ahead and bring it into my VS Code.
I'm going to call this JSON. And I'm going to go ahead and format this document so I can see what this looks like. So, we have some types here. Uh, so this is a valid EIP712 strruct. highly recommend you pause the video and go ahead and look up EIP712 or ask your AIS to tell you a little bit more about it. And there's a number of different important things in here. Number one is going to be the domain. So this is going to be a combination of chain ID and verifying contract. We should validate that this chain ID is correct that this is the arbitum chain ID. So 42161 maybe I'll take this and I'll go to like chain list 42 uh 42161 looks like chainless says that's
correct. I could also go to the arbitum documentation etc. So that's good and then verifying contract for our safe multisig. The verifying contract is indeed going to be our safe multisig itself. So what I would say is okay let's hit X here and you are a signer on a valid multisig wallet editor is here great copy that paste it great it looks like that is correct awesome so then what this message is going to be the safe TX or the safe transaction so this is basically all the data a normal transaction would have except for this is what we're going to be sending to our safe so the two is going to be the contract that we're sending a message
to. So if we go back to the UI here, it says we're attempting to send one WT on the arbitrum network. So what we'd want to do is we'd want to look up like W on arbitum. See wrapped ether on arbitrum. Hit explore. It looks like ether scan. So basically looks like unis swap is saying it's this address and that looks correct. Maybe we double check. We do a little bit more googling. We could even read the contract itself. whatever we want to do. But great, this looks correct. The two address looks correct.
Now, here we have the raw data and we can use any of the tools we've used historically to actually decode this. So, I could go to tools of the Y signer. I could go to the Swiss knife decoder again, paste it in here, and I would see, okay, we're sending to Vitalic with this much way. So, Vitalic, is that who we want to send to? Uh, let's look up Vitalic.eth looks like resolved addresses here. Let's take that address. Okay, you were attempting to send one to address this.
Okay, great. So, that is indeed who we're sending to. I don't know why we're sending Vitalic more money, but awesome. So, the two is correct. Now, let's look at the format. So, we know has 18 decimals. How do we know that? Well, we can go to the actual token, hit contract, read as proxy, go to decimals, and it says 18. Great. So then what I can do is I can say, okay, so 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 period goes here. So I know that this is indeed one W that we're sending. So okay, cool. So I've decoded the call data to Vitalic for one W. That is
indeed who I want to send it to. Indeed the correct amount. Now remember though for some of the tools highly recommend you get used to working with some command line tools. It's much better to use something like the like Foundry or Cast or some other command line tool rather than a website because if one of these websites get hacked well that's not good. So it adds a dependency on these websites. Whereas if you download a tool locally, you can always have that tool. So great. So most of this looks correct so far. Let's go ahead and finish verifying this. Operation zero.
If this was a one, we should be nervous. Safe gas looks good. Base gas looks fine. That looks fine. That looks fine. That looks fine. We could double check the nuns. Nun says 29 on the UI. Doesn't say anything about the UI, so that's probably fine. So great. So the rest of this looks correct. So what I can do then is I'll sign. This looks fine to me. We can go ahead and hit sign. And we do indeed see that says this is correct. So and it gives us some explanation of how to decode it. Blah blah blah. Now, I'm going to do one more together and then I'm going to say you should do everything yourself because what we just did was a huge pain in the butt. Going
through this entire strct and making sure everything here was correct can be very challenging, especially getting this information off of our hardware wallets. So often what we want to do instead is we want to hash this data, check if our wallets give us the hash, and then compare the hash that we expect to the hash that our wallets give us. So we have another example here where it's going to ask you to use the siphon safe hash to actually get this correct. So if we go ahead and hit sign, swipe up, all it's going to give us is the domain hash and the message hash here. Now, we went over this already in one of the prior videos. So now is the time to use that knowledge that we learned. I will say
though uh this safe hash RS has some this is the a new version of that tool and it has some very nice features that make getting this hash a lot easier and quicker, but you can use whatever tools that you want. So with all that being said, now's a great time for you to pause the video and try to get a 15 out of 15. If you do not get a 15 out of 15 or however many questions are in there by the time you watch this, understand where you got each one incorrect and try to adjust accordingly. So, pause video, go get a 100% and I'll see you soon.
All right, so that's it for the qualified signer curriculum. At this point, you should understand how to verify call data in your wallets, how to verify signatures, different messages in your wallets, and you have a good understanding of some of the different tools available for you to do some of these things. You also understand that at the end of the day, if you sign something incorrect, you are ultimately responsible for that signature, and you should not be signing anything that you do not understand. This knowledge is essential for people who want to work in the finance department of a company that works with cryptocurrencies. If you want to be on a security council or a multi-IG or a DAO, or you just want a better understanding of what you're
actually signing as a person who deals with money. So, I highly recommend you all go to Cipher Updraft and you get the actual certification for being a qualified signer because in the future jobs are going to require you have the certification in order to get hired for different positions on the team that deal with money. So, since you're at the end of this curriculum, now is a great time where you can go actually get the certification and then go start applying for jobs where this certification is required. And if you want to practice, be sure to head over to ysigner.sciphon.io.
We have a tenderly edition on the road map on the to-do list which will give even more examples and even more challenging things for you to sign so you can practice some more as well. Thank you all and happy signing. So optionally go ahead and watch that video next but other than that you now have a basic understanding of smart contract wallets of wallets some of the different trade-offs between wallets what to choose and most importantly for you developers how to use a wallet. The answer for you developers is for any of your protocols, you should be using a multisig. Doesn't matter if you're the only person on your team, you want to minimize that single point of failure.
So if you have multiple wallets for an ownership role, that's much better because if one of your wallets gets exposed, you can just swap it out. So that's the takeaway. And then something we didn't talk about, never store all your keys on the same cloud server, especially not in plain text. So that's a whole other conversation how to keep secrets private in the cloud. But you have the basic understanding. Go out and be better and I'll see you in the post deployment section of this course. This section will probably get a lot of updates as we interview more people on especially cloud private key safety. But the rule of thumb especially number one never have your private key in plain text. At this point that should be drilled into you. But number two don't be storing your private keys in unsecure places. Remember if somebody else
controls your private key they control your crypto. Now for some exercises here. Number one, of course, set up your safe if you haven't already. Number two, review some classic key leaks like AEMV leak with private key. Be sure to check out wrecked.news. Unfortunately, a ton of these hacks came from leaked private keys from bad key management. Review them. Check out what happened. For example, one of the top ones here, the Mixen network. Boom. There was a blame of the Mixon cloud service provider was attacked and that ended up resulting in the losses here. Of course, if the cloud service provider was hacked, that means they gave their keys to the cloud service provider. No, no, that's a no no. So, check these out. And then finally, check out Keep Me Safe, which
will hopefully be launched by the time this course comes out. All right, cool. Good luck. Have fun.