Web3 Security in Argentina

Transcript

So we are live I guess. So welcome everybody. Uh I'm Theo from Certora. I'm part of the marketing team at third and I also uh I'm leading DSS and today uh we have like a special webinar because this is the first webinar of the stino dev connect because this year DSS is happening during dev connect week. So we wanted to be part of these uh events happening during uh or before dev connect. So we prepare everyone to to the dev connect week happening here in in Argentina. By the way, uh I'm from Buenosire. Uh I live near B near Buenosirus. So uh I'm super glad to host

everybody in in the city this year uh for the connect. So, um I wanted to uh do a brief introduction to DSS uh and some announcements before we have our uh amazing panelists. So, I'm going to share my screen. Let me know guys if you can see it. Thumbs up if you can see my screen. Okay, awesome. So, uh as I said, uh DSS will happen this year during the Dev Connect week in Buenoses. Uh so it will be in November. Um and for those who don't know DSS uh defy security summit is our annual conference uh for the

security folks uh auditors, security researchers, developers, everyone uh working and learning about security and DSS is a nonprofit. So we want to educate people about the different tools and and applications uh to make this space more secure. You know security is a key pillar of um web3. So that's why we want to bring together everyone um discussing these topics and we have you know panels we have workshops deep dives of um what is going on in the security space. So this is the fourth edition of DSS and we are super excited of having it in of having

it in Argentina. Um so why in Buenosirus? Uh you may ask not only because Devcon connect is happening here but also because Argentina have uh has a great uh community and builders here. You you you will meet some of them uh in the in in this webinar. Uh so basically we have like you know web three builders uh in in all the different um areas of web 3 not only DeFi but also uh NFTs security. Uh so that's why we are bringing the SS to to Argentina. It aligns with um with the ethos and and also what what is going on in the in

this space. Um so as I said like we have um different sessions in in def sorry in DSS uh which include um 101 sessions. This is super important for beginners beginners because we always have questions about like people who are starting in the space and they say like okay uh so but you have like the top minds in the security space. do you need to be a PhD to to come to DSS and know uh we have a workshops we have 101 sessions for those who are starting so um if you are just beginning in the in in developing or in your learning

solidity just come to DSS because this is the place where you learn how to um build with a security mindset uh build with a security mindset from from scratch Um so yeah you will have uh networking opportunities uh hiring sessions with uh with some companies in the space. So we are opening DSS to everyone who wants to learn about security. Um this is a a little bit more about 101. So I'm going to skip this slide and how to collaborate. This is super important.

Uh people ask me like I want to join how can I do it? So there are many opportunities you can join as um as a speaker uh at the event. Uh so if you go to uh defy securitysummit.org you will see that applications are are already open. So you can join as a speaker as a panelist as a sponsor. If you're a company in the space and you want to show yourself you can also sponsor DSS. You can help us spreading the word by joining our Twitter and and retweeting our tweets. And if you see anything uh important about security or that you want to share, you can tag us uh and we are going going to also uh

retweet you. Uh you can share your feedback if you came uh in previous years. We are super open to uh improve. So you can share your feedback and um you can join the event. Of course, uh event tickets are coming very very soon. Uh so that's it. I want to give the mic to Nathan uh who will be the moderator of this space. Thank you, Nathan, for the for the time and for allowing me to present DSS. Thank you so much, F, for the introduction. It's also, I think, the first time that we see the new branding from DSS. Uh hope you all liked it. I think it's a great great improvement. Uh but we're yes very very happy to have

you all uh here today for the web3 security um uh panel um in Argentina. So we have people that are experts uh from the space not only in Argentina but worldwide. I mean Open Zeppelin, Wonderland Balancer, the Rail Guild are top security uh companies and we have the we are very lucky to have to have them uh today in the panel. uh most of they're all from Argentina. It shows how much you know like uh like how many developers and people and companies founders we have like we have in Argentina and and hopefully this this panel will give you a good overview of

uh the security ecosystem but also what you know Argentina produces best. Um we will focus on security uh even though these companies do much more than only security. uh and so I will give the mic to every uh each and every uh one of them uh so that they can talk a bit more about themsel what um what they'll do with their with their company and we'll deep dive into a uh a Q&A session if we have enough time at the end. Uh so feel free to ask your question as well in the chat uh and we'll cover them at the end.

I think it's um not every day that we have the luck to have such a um a great panel and such great people in like accessible live. So you should feel free to ask your questions. It's a unique opportunity to get in touch with them um sees the chance. Uh so before that I'll I'll give a few just a few word uh few words about dev connect and what it is. So historically it was a decentralized week of events compared to Defcon which is like a massive conference. Last one happened in uh in Thailand and the last Defcon connect in Istanbul. This time it will happen in Argentina in Buenosares next November

and so many side events including DSS will come to Argentina in Buenosares and organize their own um specific events on security. um ourself. So myself, I'm Nathan. I'm leading the Devcon connect team at the Ethereum Foundation and um with Defconnect coming to Buenosaris will organize three different things uh in the city. Uh the one important aspect of Defcon is the events that we'll host inside the big venue that we'll have. We'll also organize a co-work and then we'll have an application showcase where we'll invite all applications founders and projects to come and show their applications live. And so it's a big opportunity to um to showcase the

applications based on Ethereum. And this is something that we've been waiting for for a long time to have applications that we can use um and and we can yeah we can showcase and with the idea of like offering the attendees a touch and feel uh experience of Ethereum and hopefully that will leave them inspired by what they uh experience on the ground. So that's the idea behind TE connect. Um we'll cover many different themes hopefully throughout the week uh via diver like many different events um that DF won't organize everything. The idea is that many different entities will organize their own event and one of the big um item of course that will that

will be covered at devcon like during dev connect at DSS is security and so with that I would like to introduce the first panelist that will talk a bit more about this. So this is uh Mateo from Open Zeppelin. Um and yeah, I will give you the mic and let you share a bit more about what you do and uh and what Open Zeppelin work on. Okay. Thanks, Nathan. Well, uh I'm from Argentina as all the panelists. Uh I live in Bonositis and uh yeah, I'm an auditor at Open Zeppelin for I almost two years now. Uh and I don't know if everybody knows but open Zeppelin was originally founded by

by Argentinians. Uh this year we we are 10 years open Zeppelin. Uh so we have been there since the beginning of everything and yeah we have a lot of talented people uh from from from Argentina. Um I I can't really say why uh people in Argentina is is is talented in web three or maybe it's because we drink mate. I don't know. Uh but uh yeah and u I'm going to talk briefly about uh general smart contact security and give my experience as a as an editor and bring some things to the table and things I encountered as an

editor. So I'm going to share some slides. No, that's not sorry. I think I share my desktop. Okay. Can you see my slides? Oh, good. Yes. Yeah. Okay. Um Okay. Um building secure smart contracts. So why building secure smart contracts is hard and uh why libraries like opening libraries matter. So building smart contracts secure smart contracts is

challenging I think mostly because of two reasons. First because as any other system um anticipating every possible scenario that means every possible combination of entry point and contract state is really hard. uh as as you can I like to talk about like combos of entry point times contact state as a permutation and talking about like all the attack surface as a as a space. So that space is is is huge. Um second uh due to the to the blockchain decentralized nature uh once a hack occurs uh the recovery is is is really difficult. So uh that's why we use like

proving uh libraries like open sapling soulmate uh solid. So um we have our first first shield uh building blocks that are the the libraries. So um now let's let's see what are the limits of those um uh something important is that uh audited bricks uh is not the same as audited building. So every contract or every protocol glues a lot of primitive.

So uh you can use some libraries from other but you mostly you're going to use a lot of them and combine them to build a protocol. uh so in that way you're expanding also the the permutation space as I mentioned before uh and that breaks a little bit the the guarantees that libraries uh are are giving so some of safe uh blocks is not the same as being as being safe um that's why if we at open certain we even audit like some plain 20s with some little custom logic added on top uh and we do audit of of those and it's really important uh to to prove that it's really important for

example uh some some historical proof uh some recent uh hack that happened in CK sync uh the the Venus CK sync uh uh integration with a rap USDM um this happened I think uh this year but two months ago three months ago I don't know exactly uh but the rap USDM was an audit Ed uh ERC 4626 they were using our libraries uh the integration was audited. Venus uh is also a protocol that is audited but the integration uh some of say things is not safe. Um well the the the the hack uh particularly was a low liquidity rap USM vault. They

performed an inflation and uh because of the inflation and because of the the rap uh being used as borrowable asset uh the the deposition was was uh was uh liquidated. So um what is the the call to action here for for for de for developers? Um adopt a security mindset as a developer. Uh it is important to identify every entry point of your contract. Trace all your fund flow in and out. Uh ensure your account accountings. Prevent uh more withdrawals and deposits.

um verify each line with a security mindset. uh and also one important thing is to be very very careful about the assumptions we make in in every line of the code because uh uh using the the the Venus attack as an as an example in CK sync this was a new deployment uh of the rap USDM contract uh the liquidity was not very big and uh I think almost 50% of the liquidity of that token was present in in in videos So maybe if you're thinking about your protocol and you you see an attack path and you say no this is impossible because the attacker should have I don't know 50% of all USD tokens in Ethereum that's almost impossible but uh in new

chains this that changes so uh going to a multi-chain paradigm as we are going to um it is really important to be to be careful about the assumptions uh we make um another thing um that is reallyant important is something that I encounter a lot with with with uh clients we have is that they show up uh to audits and uh they don't have a solid test suits like they have a coverage of 50%. So us as auditors we have to be looking at okay this code compiles this code doesn't compiles um and I think this is really important or or or even maybe clear documentation they're saying that don't

have any any but any documentation other code so us as auditors are okay this function is meant to be doing like we we are there trying to figure out what this function is doing and uh yes we are not spending 100% of our time focusing on on on on edge cases and and not missing the basics. So, um yeah, I think uh I'm not going to say that it's the most important part of being prepared for an audit, but but yeah, so uh writing good uh test suits and and having a clear augmentation is is is uh really important. So, yeah, th those uh were my my my points and uh yeah, I'm going to pass uh Mike again to to you Nathan and

and thank you Thank you Matthew. There was uh these are the some sorry my last slide uh further readings. We have some guidelines to smart secure smart contract development. Uh another for audit readiness and we have a new blog about the ERC 4626 change rate manipulation risk. Uh it came last month I think. So uh go read them. They are pretty interesting. Nice. If you have also more resources about tests because you mentioned that uh people should come with a good test uh then yeah feel free to share to the attendees that might be relevant but yeah thanks that was uh very insightful um thank you Matio

um I'll then give the mic to Skeletor from Wonderland. Hey hey hey GM to all. Hope you can hear me okay I'm not in my current uh setup. Um well um nice awesome. Um let me quickly share so I don't forget on there you go. Can you see that? Okay. Yeah. Okay. I assume yes. Okay. Amazing. So uh there is first of all there is a great security talk Gory and Lumi did uh on Berlin. Uh go check that out. Uh hopefully some of them uh or some wonder

members are in the chat and can easily link to that. I didn't have time to to look that up, but it's very recommended. So I'm not going to go over uh the things that they went over. Uh I just stole their first slide. Uh also uh we have a lot of information regarding development security best practices for most of the things we do on handbook. Wonderland.xyc. Go check that out. uh easy link then uh this is what you will see just click security and you will have a ton of things we are always updating and adding uh more stuff there if you have any recommendation let us know uh okay I that's for ne for the future uh one

thing that Mattel mentioned is that um he wasn't sure why Argentinians were so let's say present on web 3 I Think most of us are very very obsessed with web3 and security and it's mainly because Argentina is a dark forest and Buenosarus is even a darker forest and it's an everchanging dark forest like nothing uh works as expected. Everything is honestly a mess and we were raised in this mess. So for us the chaotic ecosystem of web 3 is just natural like it's some somewhere that we feel very comfortable on. We don't really care uh about the craziness of volatility or

hacks or this or that or all of these crazy uh weekby- week uh changes uh that we experience. This is very very natural and very exciting for us and we literally leave our apartment and we are still on the same Argentinian ecosystem that has all of these properties for better or for worse. Um just a quick intro to Wonder. We are a big team uh 60 people more or less. Um we work with a bunch of great protocols. Uh we do from uh wallets to contracts to etc. A ton of things. You can find more

info on our website. We are always uh looking out um sorry looking for great talent. So if you want to work with us, please come join us. There is apply. Wonderland.xyz whatever you'll probably find it quite easily. And one of the cool things about working in Wonderland is that we do have a lot of internal departments. Uh we are as well very obsessed with security uh as a as a whole. So we do have a very our very own internal security department and testing department. For us, besides these two departments, for us, security starts uh from ideiation to deployment and and more. Uh like there

we do take things very very seriously. Um and we also try to nudge our partners or try to elevate the quality of our partners' work as well and their processes. uh because we know like this is a collaborative effort and if we just start raising the bar everywhere the the average uh security of the e of the whole uh ecosystem will improve. Um one of the the key things that we try to achieve with all of this obsession is to make auditors like hell. So sorry open sepine and other auditing firms because we want to make them work really really

hard to find even a single thing. Uh like our success is for external audits to not have found anything or very minor things and we do this because we know they are going to try really hard to find something if if they didn't find anything. We know this from experience and from talking with these different uh auditing firms. Uh so how do we do this? Uh sorry one more thing like security is not uh a linear thing or or a thing that you tick right it's doesn't have any tradeoffs it should have a focus on UX be anti-fragile it's a lot like it's it should globe or be part of every aspect of your organization you're as strong as

your weakest link and this is more so important in web 3 than anywhere else honestly Um so now nice meme uh keep it simple stupid uh this is one of the most important things that we try to uh achieve which is complex systems are very hard to review very hard hard to on board more eyes to them. So as simple as you can keep things the better. uh we do have a lot of uh back and forth and most of our effort is spent on the design and tech uh specifications not even coding. Um so this is a very very important thing that

you need to consider before writing a single line of code. Um then elegance. If you ever saw a code and you were like, "Oh, damn." Like this code looks sexy as that's most probably good code, right? Like you should see what you wrote or your design and think, damn, this makes total sense. It looks so good. Uh that's that's the end goal, right? And most of the times you come to this conclusion by adding restrictions. For example, hey, what if we couldn't modify this core contract, which is most of the time a good restriction, right? Don't try to

add functionality on core contracts that shouldn't have that functionality. Just add restrictions until you figure out your way around the actual underlying problem. build primitives, build ways to uh modularize and and uh yeah create Legos of your own uh implementations and your systems. Um that's mainly it. I just wanted to keep it very very short. If there are any Q&As's let me know else we can uh get them or reply them uh after the session.

Nice. Thank you so much, scholar. That was uh that was very insightful. Uh you you shared some uh some good punchlines. I love that. Um uh I think keeping it keeping it simple for the sake of security is uh I think is very catchy and a very good uh yeah elegant. keeping it elegant as well is a is a very uh very important and simple to keep in mind as well. Um I saw that your teams uh your team has been sharing some links in the chat. So if you want to learn more about Wonderland or the handbook are ready to apply to Wonderland. Uh I realize I'm also Wonderland here with my shirt.

But uh yeah, water is a is a great company based and founded in in Argentina uh and doing some also important core dev work on many different chains. Uh so so it's a it's a good company based there. So yeah, check them out if you want to learn more. Uh and thanks again for for a quick chat uh that was great. Um and then uh with no transition, I'll give the mic to balancer. Hello everyone. Thanks Nathan and yeah, thanks for having me here. Let me first cast the screen as well so that I don't forget.

Okay. Can you see it there? Yeah. All good. Okay. Perfect. All right. So, first of all, I'm Quani. Uh I'm the smart contracts lead for Balancer. I've been working for a few years now uh in web 3. Um Balancer is a centralized exchange for those who don't know and it's also a platform for others to build uh innovations al always related to exchange. Um so yeah it's it's not only like a simple uh DEX but also yeah you can build components and custom pools uh custom hooks and stuff uh on top of the platform. uh and we always try to invite new partners uh and try to on board them so that we can

build cool products on top of what we already have without them needing to rewrite everything from scratch. Um so yeah, my talk is not going to be so much about uh Argentina. Uh but yeah, how to build smart contracts safely in general. So if you want to build your own uh protocol from scratch, uh how do you do that properly? How do you try to make it safe uh and secure? Uh so these days the problem is that you cannot just like build UNIB 2 again and be successful. You're probably going to do you're probably going to need uh something more innovative and therefore more complex and that brings a lot of challenges specifically in the web 3 ecosystem.

So this is going to be a bit of a speedrun, but let's say that you want to build a protocol where uh you want to make it immutable so that the core smart contracts cannot be upgraded and those are going to going to hold uh all of the user funds potentially holding millions of dollars at any given moment. Um you might have some sort of governance to adjust certain parameters or execute some uh administrative functions or emergency functions. uh we're gonna assume that it's well behaved because it's going to be behind a lot of signers. So, it's a bit hard to get it compromised. But even then, if it was compromised, it shouldn't be able to do that much damage because by design, the funds are with like not reachable by

governance. They always held by immutable smart contracts and the protocol is non-custodial. Uh and by non-custodial, it means exactly that the funds are held by contracts that are uh cannot be modified. uh governance doesn't have any access to them even if they signed uh bad transactions maliciously or or willingly. Uh and even then even if the system is paused or even if we are in some sort of emergency conditions we must be able to guarantee exit hatches meaning that if users have a position in your system they should be able to exit no matter what. Even if the system is paused, even if there's an ongoing bag or an ongoing mitigation, you should be able to exit your positions.

Uh with all of these um conditions you get that if you have a zero day uh bug that yeah maybe some white hack comes and tells you hey there's a problem with your platform you might be able to mitigate it by posting the system for example via governance in this case but you won't be able to fix it entirely because you cannot upgrade the smart contract and just apply a fix. So that's more or less the design constraints that you're going to have. Uh this has pros and cons. There are some protocols that are upgradable and that brings a whole different set of restrictions uh and possibilities, but for now we're going to focus on immutable contracts at the core. You might be able to update certain parts of the system or deploy new new new for example pool types or

new hooks or new innovations that plug into the to the base layer, but the base layer that holds all the user funds is going to be immutable. So this will relate a bit to what skelelet said. Uh and this is a like an ongoing cycle that you will want to do uh as you develop your product. So initially you will start trying to approach a solution in a very naive way. You're going to try to go straight to the answer. Uh you're going to want to do a very simple implementation. But in that process, you're going to get to an answer that probably doesn't model all the complexity that the problem has properly. And that's when you start iterating and probably you're going to swing back to the other side and add a

lot of complexity to your project trying to solve that problem. Uh and in some cases you're going to end up adding too much of it. You're going to like make it overly complex without a real need for it to be that way. Uh that's when you want to take a step back and say, "Okay, what are the requisites? What I what do I want to see from this uh uh from this this code? what do I want to really solve and what doesn't need to be solved by this code that's when you try to analyze the complexity try to uh polish it and yeah essentially strip it down to the bare minimum that really needs to be done to solve the problem that you want to do and that's where you arrive to this informed simplicity which is what scal said like when you see a code base

that uh yeah it shines because it's simple it's elegant and it solves the problem uh also related to what Matio said you reducing the attack surface because it's simpler. So you don't have to reason about uh complex interactions and things that might not be needed. Uh and this is a cycle that can only be done in an iterative way. You probably going to need to uh give a try to give a stab at the solution. Uh go back to the drawing board and try to do that cycle until you arrive to something that really clicks and you say, "Okay, this makes sense."

And all of that happens in the development stage. So I would like to talk a bit about what the stages are uh and what you need to do at each of those stages. Now talking more about testing and procedures. And I was a bit amazed about what Mateo said about uh projects going into audits with very low test coverage or very low documentation. And I think that's a terrible decision. Um by the time you go to the audit you should already have like a very good testing suit that tests essentially first. Uh you can start with unit tests and static analysis. There are tools with that essentially unit tests check that every function individually works as expected. With static analysis you

can uh review have a initial review of your code and see that nothing obvious uh is incorrect. There are also tools for that. With fast tests, you can uh test also function by function uh and try to essentially bombard the function with multiple inputs and see how they behave so that instead of testing just for one or two values, you cover a larger spectrum. And you can also do for example end to end tests where you put a whole system to the test uh and see that it behaves properly. Uh in that category you have stateless and stful fuzzing. Uh for stateless essentially you start with your system at a certain state apply some inputs check the outputs see what happened in the middle uh and check that

everything was all right and from iteration to iteration you don't save the state you just like start all over again with a different set of values and see what happens with the stateful on the other hand you can tell the program to say okay start with this state and then call any of these functions in any order that you think that it's convenient and try to break some of your invariants And so for example, if after calling functions ABC, some balances uh shouldn't be reduced. Okay, just start calling them in some random order with some random inputs and check that that never happens. And you can have a program do that for you uh in a smart way trying to actively break your code uh and that will help you find uh issues

if there are. And also finally mutation tests. I think that's also a very good technique. Uh a mutation test is essentially a tool to help improve your coverage. So besides a static coverage analysis that tells you if your tests cover or not the lines and branches of your code, uh you can also do mutation tests that essentially take your code, modify a few lines and run all the tests suit. Again, if uh no test is broken, it means that there's probably something that is not very well tested. So there is room for improvement uh on that front. So tools for this hardhead, Foundry, Medusa, Sumos, Lether, uh I think all of those should be indust industry standard at this point. Uh it's about using all of them during the

development cycle for pre-release. After you have all of that, you wrote good documentation, good tests, only then you should go into the audits. Uh my advice is try to get as many auditors as you can. Uh preferably top tier firms. Uh and if you can afford more than one, just go for it. uh try to leave a gap between each audit so that you can iterate on the code and if there's feedback from the first round you can address it and uh give the second auditor a more polished version of your code and so on and so forth. And finally after you went all through all of that it's also a good idea to have a public contest. Uh a public contest is essentially like yeah an audit but it's open anyone can jump look into your code

and if there's a bug you have to pay them. Uh all of this is very important because again after you deploy there's no going back. So all the work that you can do before deploying is always a good investment. Right before the release you should also have uh a bit of consideration uh in terms of fork tests trying to like predict what's going to happen after you deploy and if there's any integration with live smart contracts you can test it in a fork test uh by essentially testing your code against the actual state of the blockchain before deploying. And also artifact traceability is a good idea in the sense that you want to make sure that what you are deploying is actually the right commit and there's a right way to trace all of that.

And finally after you deployed uh there are still a few things to do. Uh you should probably have a back bounty because if there is anything uh wrong you want to you want you will want to know about it and be able to pause the system before it gets exploited. You want to have the these emergency permissions all set up and time locks in the case that there's something that needs to be executed only once in a while so that you ensure that uh it's properly configured and it's only executed in a in a correct manner and also monitoring. There are ways to know and predict attacks in advance and even post your system with automated systems if you have things properly configured.

So all of this is essentially uh the package to try to mitigate unknown unknowns. You can test the code as much as you want. You can uh invite people to see your code to audit it and everything. And that just will tell you that uh yeah there's absence of bugs as far as you can tell. But there was will always be uh a small portion of unknown unknowns and you will want to be uh prepared against that and try to make it uh as hard as you can for exploiters to try to find those uh and even if they find them let them try to go through uh the proper channels. set up your back bounty and try to get ahead of that so that even if there's an issue, you can

try to post things and save the user funds which is what we most care about. And yeah, I think that would be it uh for now. Handing it over to you, Nathan. Thank you. Uh very exhaustive not only on the on the security aspects I found but also on the development uh processes in general. uh how to approach uh the security of your protocol actually uh leads you to think about the development in general right um and I thought that that was very interesting to see in your in your talk um while you were talking I saw that also um Matio shared the audit readiness guide I think so that's that's a very

exhaustive resource that you should you you should check out um but yeah thanks again that was very insightful uh please in the audience make sure to share your questions. Uh you can go technical. You here have very technical uh people. So you can go as technical as you want. Um if you have urgent question on on your contracts, we can also discuss that even better if they're argentina specific. But yeah, please feel free to share your questions in the chat. Um and uh our last panelist of the day um I will give you the mic mata from the redgill to talk a bit more about hopsc for humans.

Hello. Hello. Can you see the screen? Yes, we can. Perfect. So, well, uh I work at the Red Guild. I'm a co-founder. It's a nonprofit profit organization and we do public goods for the Ethereum ecosystem. And today we have OBSE for humans a quick practical application series and we are featuring attack trees. So instead of focusing on theoretical advice and since only I have like 10 minutes I try to teach you something you will be able or should be able to apply right after this webinar and this is for all the times that we told you to be careful but never gave you a straightforward tool. Okay. So what is OBSC? Well, obsc uh I mean this this uh this summary I I'm going to read it

because it's like super succinct, but it's a systemic way of protecting critical information by limiting what you reveal. I usually say it's the art of not revealing information nor making yourself sus susceptible to an attack. So if you were to go to the security frameworks um you're going to find different frameworks and there's an entire section for operational security. I'm not going to delve into that. You can go directly to there. I'm going to share the link afterwards. So if you go to /opsec you're going to find the work in progress of the operational security framework and there's a new travel guide that I published which is on an early stage but it's pretty robust for for for starters and since this is um an

initiative which is basically created by community and super collaborative we expect anyone that wants to share their knowledge come and and and start there. So one of the best resources out there within the operational security realm are the threat models and each one of the organizations or you as an individual have their own unique one. So what are they? This is just an example an overview that I have on frameworks but let me explain it this way. It's basically a way to diagram all the things that you're protecting and who you're protecting them from. Right? And also there are some stuff like where or how risky things are. So this is an example like an instance of a fiction

fictional organization doing a threat model. But there's a moment in which you will identify a high-risk objective and you need to dig deeper to understand how to mitigate and that's where attack tricks shine. So why would you use an attack tree? Well, because they looked at like damn trees. So they're they're super visual and easy to understand and they only have a root nodes and leaves. So you can you can basically uh refine them, maintain them because they're super modular and it can be considered a communication tool because even nontechnical nontechnical profiles can can follow it since it's like super

easy. It helps you get coverage and allows you to prioritize by impact and probability. So super quick how we can create one in four steps. First we need to define a goal. In this case I don't want my funds to be stolen. Then we need to understand what's the all the necessary conditions that need to be satisfied in order to get there. So what does the attacker always need? Well, it needs to execute the sign transaction. And then what do we need to make that uh previous condition make uh be true. Like for example in this case trick me into singing into signing or the attacker steals my private key and then from now from now on we go down trying to wrap or

create like the S steps until we le we we we reach what we call the leaf uh which when you consider that there's an atomic action operation or something that needs no more delving into into the depth of of it. So I'm going to do like really quick uh walk through to to to make you understand this better. So the context is just to make something easier. I have a hardware wallet. I'm traveling. The recovery of that wallet is in the bank and I'm traveling only with my phone on my computer. So it would be a self stolen wallet that needs to be drained in order to steal my funds. And in order to my funds to be stolen, they need to be transferred,

right? So it's an an outbound transfer. So let's start. Okay. The one of the first things that I think about someone uh realizing or understanding how to execute an A1 transfer is like if I sign a malicious malicious transaction or if someone signs with my private key uh a transaction or if I accidentally get the address swap somehow or if someone I don't know like uh forces me or cores me into doing something. Okay. So let's focus just on the first one. and sign a malicious transaction. So, how do I sign a malicious transaction? Well, I can get tricked like IFX support or fishing email or I just going to a conference. I

pay for a cafe and someone put a QR code in front of it and then I sign that or maybe I get a a video call from my CTO but in the end uh it's it end up being the DPRK using the the fake technologies or AI. Now, the following one attack signs with the stolen key. So, what does need to happen for someone to sign with the stolen key? Well, they had to steal it first. Okay, how can they steal it? Well, uh, I could have a backtory on my hardware wallet. I know it's kind of a fetch, but it could happen. Or someone stole my hardware wallet and my pin because I have a pin and a password possibly. I hope you do. Or someone could have stolen that the recovery key or the or the or the C backup. So, how

can I have a back door on the har wallet? Okay, maybe if I if that harrow wallet was susceptible to a supply chain attack and how can someone steal my har wallet and my pin? Okay, maybe someone saw me introduced the pin and then target me afterwards or there's a hidden camera on the Airbnb I just uh booked and then I got a compromised room service that works with them. or in the case of Selma recovery key the the only way to do that is like to break into the bank's vault. So the following one send fund to incorrect address. How can we say fun to incorrect address?

Okay, clipboard jagging or for in order for this attack to to be successful. I would have to have malware installed in my devices that swap the destination address with the with the with the target address of the attacker. Or for example, I could get spoofed on and I copy the wrong arrays. And that that can happen because there are bots that do this kind kind of attacks. If you see a block on the block explorer, you're going to see sometimes right after you made a transaction that there are some addresses that are similar to yours so they can confuse you or just simple social engineer or impersonation like this most operandis of ABBA. I don't know if you know it. uh two Telegram groups and they bridge

between those two groups and they trick two sides of a of a trans of a yeah of a transaction and they trick you onto onto transferring to somebody else and then physically forcing approval one some I mean they would literally need to be there with me in order for this to work. Remember I have a hardware wallet. So it has to be on the spot transfer and it should be like an armory and they found that I have a hardware key a hardware wallet and they understand what a harrow wallet is and so ah okay I was going to steal your ring but okay now I see a harrow wallet just do this transfer or I was a highrofile target and I was target for an express kidnapping. So this is how the it would it would look like at the end. I mean this is not the only way

to do it. you can make a different kind of variations for it depending on on on each other needs. Um and uh and the most important thing is that you need to understand it or the person you're working with need to understand it. So what are the next steps? Well, the most important thing after you create one is try to mitigate each leaf. For example, I'm I'm selecting here all the all the all the leaves and uh in the case of someone trying to do a transaction, if I'm using a multisig, right? If I'm using a multisig, even if they steal it, they won't be able to to to do that because they would need another signers or if in the case of inst malware

installation devices, if I'm using updated antivirus, probably I'm going to end up um protecting from 97% of the attacks or for example, if you're in Argentina, uh we have a phrase which is not regal, which would mean like don't give yourself away. especially in Argentina, for example, don't use your phone distracted in public, particularly if you're close to windows on the subway or the train or or the or the bus. And uh don't take taxis from the airports or those terminals if you don't know them.

Prefer an application where you can share progress. Don't use swag or brag or don't share like you work at crypto, how much you earn to strangers. So there they're there depending on case to case you're going to see different mitigations. Um so it's important you address them and then for example you can prioritize it branch. For example you're lending this right now and you're traveling tomorrow to Argentina. How can you do to prioritize this? For example in my case I don't have money. So physically coercing me to I don't know to do an on the spot transfer it's it's not feasible. So I would ignore that branch completely. I will focus myself on signing a malicious transaction. So what more things you can take into

consideration to improve it? Well, you can also categorize the each one of the nodes and leaves on likelihood. How how how chance how many chances are that one situation happened? For example, kidnapping a not so high-profile target. It's like super low. Are all those scenarios possible? Do you think that for your profile someone would hij hijack into the van into into the banks just to steal your recovery key? I mean that in my case it would be considered impossible and the cost of execution like a supply chain attack might be super super expensive super expensive. I had to be like a large scale attack and so if you bought it from uh from a legitimate

provider you can just forget about that. So that would be it. I thank you very much for for this. If you want the slides, you can p me via Twitter or Telegram. Uh thanks to all the other speakers for rushing and giving me some extra finishes some extra minutes to finish this and some other we're we have a lot of initiatives. But right now we're working on the second version of the fishing dojo that maybe we have done I can show you afterwards of the Q&A. But basically we simulate safe environments for people to learn how to void how to avoid getting uh tricked or fished. Uh so you can go there and you can start with the old version. It's it's really really really cool. So thank you. Thank you very much for your time.

Thank you Meta. That was a great session on on Obsse. Uh that was almost like a design thinking uh security session on OBSC. Uh I think that was very very insightful and very concrete as well. Um, also like that you you included some very Argentina specific advice. Um, and so um, and so yeah, we we covered a lot today. Um, we covered a lot today. Uh, so anyone has any question for our panelists, please please share again.

Um, I wanted to add that u most of these topics will also be covered at at DSS. Um, oh nice. I see Pablo Sabatella also in the crowd uh working on OBS specifically. So I think that's a very uh relevant attendee. If Pablo you have any any question to share please do. Um in the meantime u I would I would say um I would ask okay F uh again like maybe to your take on why does it matter to bring DSS to Argentina. Can you share in one sentence maybe why does it make sense?

Why it makes sense? Um so since uh as we discussed before like we we have a lot of uh builders in Argentina, right? like we have a builders everywhere building different applications uh and not only building uh applications um from scratch or from zeros but also builders working for other projects in the in the ecosystem. So I think it's it's uh key to have a security mindset as as everyone here uh highlighted. So that's why bringing DSS to Argentina is uh another reminder of that uh educating new developers uh future developers to

have this security mindset to build with um with the with security in mind from the first line of code. So that's why I think it's super important. Nice. Yeah, that makes sense. And I think again like today's session showed how much also security masterminds we have based in Argentina. Uh and also we we've seen I think today that uh not only I think like security evolved a lot in the workflow space like in Ethereum like just looking at the doc of open Zeppelin you can tell how much it evolved and how much now it's more professional that he has been um and um and that that is I think that's a good

example of like uh our ecosystem maturing and and learning about past you know best practices and mistakes. Um I also see so security is evolving uh best practices the ecosystem is evolving very rapidly. Mateo you asked you talked about um you know this ecosystem evolving into a multi-chain environment. Um can you share very very high level uh what kind of like some risk does it uh yeah some security risk does it um create?

Um yeah sure. Um basically it all results to the to the assumptions you make on your code basically. So, so if I I if I have to make uh uh emphasize something is on the assumptions you make on your code. So maybe in in a single chain you're making some assumptions and when you when you go to another paradigm um yes you you have to change that. So yeah, again with the example for example of the of the the the of an attacker having I don't know 50% of all the tokens of a specific token.

So maybe in one chain or maybe in in a chain like Ethereum that is older than than CK sync is is it's almost impossible that maybe in on chains on new deployment of new uh that can happen. So uh it all resumes to the to the assumptions you you make on the code. Nice very succinct and efficient take. Uh anyone has any also additional question or feedback even from the panelist feel free to share. Um I want to ask as well uh all the panelists if there is a good answer to maybe Argentina specific

uh security issues you see in the ecosystem like we we mentioned OBSC. Is there anything that you see any trend that you see that Argentina devs or user should be paying attention to while using or developing code uh on Ethereum? Does that ring a bell when I talk about this or is it even like there's nothing about Arina specific like nothing specific to Aratina regarding code or development like would that make sense? Anyone hesitate to to share? I think it's I'd say it's a tricky question. Um I mean I I feel like Argentina is more familiarized with some specific usage of

uh Ethereum related technologies or or blockchain related technologies uh because of of of the need. But I think that all Latin Americans feel or we share the same the same feeling in terms of operational security. I'd say that at least in Argentina up till today there's no risk of um like the usual petty thieves that you can encounter on the street knowing what the is a hardware wallet. Uh I'd say that this is the year that everything is going to to change. So don't um I'd say again uh like don't give

yourself away just because the maybe actual thieves or or criminals don't understand the technologies it doesn't mean they are not going to make a stupid decision. I am actually more scared about the people that are no no professionals and don't actually understand that they that and in some circumstances it's impossible to do a transaction. I'm more terrified of those people, those not having knowledge rather than the ones that understand.

Okay, this is R. They have everything in USDD. This it can get frozen or or oh, this is Har. Oh Uh I don't know. We we don't have enough information to do this. Let's just release it. No, no, it's not happening. If you've seen what happened in parties, uh it's it's it's been it's been terrific. So I say don't no regal and try to try to understand and be cautious about all the information you you display publicly even like uh hey I'm this I'm in this hotel and you're like showing some chains or like the rooms uh the hotel the name of the hotel the room the number of the room you are

it's it's not necessary just a little bit of cautious cautious uh being a little bit more cautious It's just it just changes the entire landscape. Yeah, that's a good very good general advice. Um I realized that we only have two minutes left. I have plenty of other questions, but uh uh I guess we covered a lot of topics today. Um so I'll simply I think take the time to thank again all the panelists. Uh, Matio from Op Zeppelin, Juani from Balancer, Mata from the Red Gill, Skeletor from Wonderland, and of course Fio from Stoa and DSS. Um, I really find found this uh very

entertaining, very interesting, insightful. Um, again, I think he he showed some of great minds in the security and web space. Uh, you should come meet them uh during DSS. Hopefully they will be talking or at least attending or around not far. Uh you should also come to Devcon connect. Um it will happen between the 17 and the 22nd of November in Buenos, Argentina. Um if yeah we you we will share I mean you can share you can sorry see their handle and information. We share them on X uh you will find the recording of that

session also on YouTube. Um and with that I will close the session. Thank you all for attending, participating and for your time. Thank you so much. Thank you. Thanks for the invitation. Thank you. Thank you everyone. Guys, byebye. No. your hand.