DeFi Security Summit 2024: Day 1, 8 November

Transcript

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e e

maybe you can start the slides from uh the back I don't know can you start the presentation I see it here still not in the screen uh yeah it's in the laptop and it's connected and everything oh it's coming great okay so I'm excited to be here as Rajiv mentioned four years ago I started the DSs I didn't know that it would be such a good success it's a I think it's a was a fantastic experience for me as academic sort of taking things from Academia to practice the this is a joint effort many many people work and help me

here particularly I want to point out UI Christian who's been with me from the beginning actually four years ago he's was unable to come he will come later I want to point out V which is hiding here but she's actually running the whole thing amazing thank you V maybe you can clap if you can uh I think I want to point out Rajiv and Moody to actually been helping us with content from day one actually from the beginning from the covid time it's great and also I want to point out uh other people including F fiorella from Satora who help us so much thank you all for this work uh the idea of defi security subit

is that we try to get very good content in this field and the way to get contest is get people to help us get contest so these are amazing set of the people who volunteer to help us in C curating the contest basically you submit your work and then we uh let uh tell give them to the to these uh fantastic reviewers and they actually create create the contest and this is how you get the contest so please thanks them uh it's a huge effort please help us and we want to make this like a very very good conference in this in this field and we want and the way to do it is to curate the

content so why are we here why are we here that's of course obvious uh answer is bugs but this is actually for this uh we actually started to to see what are the effects of the bug I think last year we had Peter from coinbase explaining this so we tried to do it on our own so Yura shman from C actually went into re and tried to classify and the results were actually surprising to us so of course not surprising that many many bugs in smart contract but the interesting thing that they equally and even more bugs not in smart contract related to Key Management so here I uh according to re is around1 billion

dollar which is lost due to Key Management but in fact according to mudit which is not here at the moment it's more than five because the idea is that a lot of the bux which happened and so these are connection between web two and web 3 and these bugs are really really important and they're costing a lot of money the other problems DNS servers supply chain attack dependen on other things they're all sort of costing bugs and maybe the last but not least even Twitter Hax we see good companies who actually been hacked in Twitter and these are all problematic things so you see a lot of money is lost due to bugs and maybe something which is

I think also you can measure there is some kind of reputational damage so once you have a bug if a protocol has a bug the effect of it is that other people lose the trust in that this could be internal this could be external this could be the value of the coin and I'm you can actually look at it and measure it and you can see for example protocols who has bugs versus protocol who do not have bugs and you see that the value is different so these are all effects of bugs many of us are interested in smart contract so in smart contct it's a it's still a domain you we see that the billions of dollars are lost and here you see the characterization of

the bug again according to re and you see reeny is still an issue but rounding errors is also picking up uh price manipulation attack is still a problem other logical mistake but the biggest mistake is Access Control actually if people are doing something wrong which is actually affecting so all of these are bugs that comp that that we in DSS and others as security res and as protocol developers are trying to prevent so what is our solution there are lot of very good uh initiative in this Space etherum Foundation trust x what we try to do we try to create an

annual conference and this annual conference is supposed to educate the field it's inspired by very good conferences in web 2 in particular Devcon and CCC are very very good amazing conferences but it's bit a bit different it's not just focus on the security research it's connect the security research and the protocol and here you see Raj session at last year DSS so you see actually that here is the panel of the Auditors if you haven't see it see it live so these are things that actually people connect together and they talk about things and hopefully you will see also this here in DSS we already seen in 101 we are creating discussion

to educate this space so how do we do DSS so DSS was inspired by another conference called the Stanford blockchain conference and it has some principles which are a bit different than what you usually see especially in web three so one principle this is a marketing free event and it also means that when you are actually providing sponsorship or anything you are not actually expected to get anything but your web name here and I want to acknowledge all the sponsors in particular I want to acknowledge Electric Capital which is actually a VC FM which is support developers and they have been supported DSs from the

beginning and actually this year they are supporting us on the diamond level I want to also acknowledge all the gold sponsors and I think you have an interview with them during lunch I encourage you to these are uh companies whove been helping us to create create this context and thanks them all so Quan stamp Sigma Prime Aptos aen l a hexen stellar and new one actually Black Horn please they just came late please give them thanks they came late and their sponsor is very good thanks them please so these are gold sponsors you will hear about them later they are sponsoring us and without them we could not do this this

event there also silver sponsors also some of them has been with us since the beginning since the first time open Zeppelin fand is a new security company in this space Lio also supporting us H tenderly starware and the so again thank them please I'm getting I should be so there's bronze sponsors spear beat trail of beat ddab uh thrash block etherium France immuni etherium Foundation Civic Sherlock rare skills and an asymmetric research and new security film in the Solana thank them

please and there other volunteers they here please thank them they are helping us all the time and they will please thank them okay so this is not a technical presentation but still I want to show you how review things in terms of security so basically review security is a four things so of four things going together the first one is shift left you have to start early think of security and think of security early the second thing is the artifact you want to create artifact that prove your your think these are things that you do wow it's going F and the third thing is tool and finally is the process so how do we do this we com communicate we we we have we we connect

the community the First Community is the builders you see all the builders the second Community is the to the tool providers you see the tool providers and in the middle you see actually the the Auditors the services and they're all together they're all together and you see them in DSS uh we educate about existing attack tools open problems and of course we create more talent and you see 101 thank you all here are some nice stories and please give us more the most important for you especially if you are new in this field we have career OPP this is new please apply we have very good

teams and DSs is a recurring event you see the first time it was small increased it in DSS uh last year and we are even increasing this year hopefully next year we are creating more and more content uh this year we have done three new things we have the SE partnership that is coming later we have career opportunity I also mentioned and there are technical Workshop this is very new here and please attend some of them if you don't attend three of them you cannot say that you attended DSS so please attend three of them you have many of them during the two days and request from the speaker including myself time your lecture do not promote your product and educate

us there are many ways you can help us I'm on time now so please thank [Applause] you think have to move thank you mly for uh the motivational talk about the history of DSs and why we are all really here so with that we're going to get into our technical sessions and uh we have the first technical session by Philip keer of zirut who's going to be talking about enhancing Layer Two

security with sequencer level protection insights from the circuit Network so please give a warm welcome to Philip keer [Applause] this doesn't work I haven't

yeah works okay all right all right thank you very much um my name is Philip keer and yeah welcome to my talk where I'm going to inform you about sequencer level protection on layer twos um I'm going to tell you first what sequence level security is then I'm going to tell you why it's important on layer twos finally I'm going to also show you how this is implemented on circuit and I also want to give you some insight from our uh sorry May net okay let's take one step back first

and look at how transactions are flowing on layer twos you have a an RPC endpoint where users are transacting to um and these transactions are Then followed to the sequencer the sequencer is performing validation of these transactions and is then responsible for ordering these transactions it then builds layer two blocks puts them into badges push pushes these badges to layer one where they then have data availability and then they can be verified through a validation mechanism such as fraud proofs or zero knowledge validity proofs well with sequenc level security we take one step back to this step of validation with the validation at the sequencer we have an extra step but we say we make use of an AI based

Oracle which tells us is this is this transaction not only valid is it also safe if it is safe yes we can include it in the layer 2 block if it's not we have a new transaction status which is called the quarantine for potentially malicious transactions the rest of the transaction flow is then the same as with a normal normal rollup the layer one never knows about these quarantine transactions so now as we have explained what is layer sequence level security why is this important and particularly why is this important on layer twos well first of all layer twos uh bring with it a new ecosystem of new applications the lower fees lower block times lead to

new applications and there will be new vulnerabilities and it's not enough to just check for smart contract uh vulnerabilities with audits so yeah there's there is more issues now and we have to take it up to the infrastructure level to also verify uh the that these transactions are benign additionally there is higher transactions through report as I already said hex can be executed faster and it's also harder for the protocols to track it so yeah we want to take it one step step further and introduce Security on the sequencer level and finally if you have an exploit well today sequencers are still relatively centralized and what has happened on other rollups once there

were hacks well one opportunity to protect users is to actually hold block production however this kind of goes against the principles of decentralization and yeah with sequence level uh security you can proactively prevent hacks and and prevent collateral damages because of this sequence not being hold um yeah the good news is we have this on circuit circuit is not only the first ZK roll out built on the op stack it's also the first roll up that introduces sequence level security in a main set main net setting and uh how did we implement this well our execution client is is like many others is based on a leading execution client in the ethereum ecosystem it's based on G what happens

with a transaction in G well G maintains two transaction pools tools a q and a pending que um and when a transaction arrives in G it will first have some basic validation for example is the signature correct is the rlp encoding correct is the gas limit sufficient and then if it if it has been validated it can go into the pending queue the pending queue means also the nons is matching and the fees are good and then it can be included in an a layer two block well with sequence level security we introduce an additional validation step between this que and the pending que which tells us hey we doing a risk assessment of the transaction before being able to include this in a

block um yeah so to sum it up it's placing a transaction in a quarantine which is the new transaction status it means we skip it in the process of moving it from the que to pening que and put this transaction on hold um we want to do this in a way that does not prevent a sensorship resistance that means we also are being transparent what we quaran there is a public dashboard where you can see what is quarantined you can see the contents of the transaction you can see why we quarantined it also we have additional RPC calls which tells tell you whether a transaction has been quarantined and what you can do against it um to have effective effective sequencer level security performance is really important

on our Network we have a block time of 2 seconds uh this means we have to be able to uh do a risk assessment of transactions very quickly to not degrade the developer experience also it comes at the cost of some computation costs you never want to do the risk assessment of these transactions on the sequencer itself because in terms of high through put you would risk that the sequencer would get halted um another technical detail are deposit transactions you the op stack I don't know if you're familiar with it introduces an opportunity to incl and transactions via the layer one so we also need to scan those in a in a quick time to ensure they're being included and also scanned for transactions and we

also need to record this on the da so how do you test such an AI based Oracle well it is based on machine learning so you need to have several things in mind you do not want to overfit on P Tex so we introduced an extensive testing Suite with bite code variance and even uh reproduced temporal States smart contract States and also tested on multiple reild exploits to test our machine uh learning Oracle well good thing is this is live more than 400,000 transactions have been analyzed since our menet launch in August so far uh there have not been any exploits and also zero false positives we also aim to be in uh in collaboration with the blockchain security and let them know if

there are for example if we see anything any suspicious activity if you want to learn more about this we have a paper we tell you how to decentralize this also I invite you to read our documentation or talk to me we are live on mainnet we are testing this on on real world TX and yeah with that I thank you very much if you want to talk about layer twos or sequence level security or circuit in general come find me around or I also invite you to other events at this conference thank [Applause] you e

thank you philli so our next speaker is hot from open Zeppelin who's going to be talking about hooks security considerations when building hooks in Unis swap V4 so please give a warm welcome to hot thanks e hello um hi everyone I'm kodar banelli

from Oben Zeppelin work as head of security for the team um and today I'm here with you to talk about security considerations when building in new swap before hooks or at least basic security considerations because many many things can happen when you are implementing hooks um short agenda for today because we only have 10 minutes uh we're going to talk a little bit about unap before what Hooks are and we're going to go through four main but also very very simple security considerations to take into account and we're going to see some uh code Snippets and some examples in in real code or at least CHD generated code

that I use to create these slides and then I'm just going to list a couple of other considerations but again the list is literally infinite so uh let's get started so to start what unof before is uh I'm going to assume that most of them know unisoft B3 unof B2 know kind of like how the protocol Works um but basically in unisoft before we have a main contract a Singleton that is a pool manager the pool manager differently to un swap V3 has all the operation logic so basically in V3 if you wanted to have a contract uh a pool uh you had to

deploy it so you would have as many contracts as pools uh you had in this case this is not like that all the pools leing the pool manager and the pool manager defines all the different functions that we already know from unisoft like uh swap add liquidity remove liquidity mint burn Etc um in this example I also set uh some sort of like a pool operator contract that in unisoft before at the moment could be the unisoft router could be also the position manager but actually can be any contract any contract that you want to build and talk to the pool manager you just can do it um the flow works as follows the user first calls this uh random contract or

router let's just take the example of the Unis router um what happens here since um these contracts Implement transient storage and given that we have transient storage we can um uh preserve State throughout uh a transaction from the beginning to the end um we first will call an unlock function the moment we call the UNL function we can basically do whatever we want in the pool manager and interact as much as we want with as many pools as we want so basically if you want to perform a flash loan taking all the USD from all the pools that exist in the pool manager you should be able to do it um this then triggers an unlock callback function

that uh goes back to the router for example and then the router takes uh care of calling the following function that can be for example a liquidity or or uh or or a swap so that's what I call here operation um and again this operation could be many operations could be anything and finally when everything is finished uh the same uh unlock function will call the uh lock function so that no one after this specific operation or set of operations can can be run what is a hook um a hook is a smart contract this smart contract has defined uh in its interface many functions uh a

hook is basically as we said or as we saw in ERC 20s back in the day when we had the before transfer function so basically or after transfer function it's basically code that you can run before and after an operation in this case we don't have transfer because it's not a token we have swap initialize at liquidity uh remove liquidity so we have functions like before swap after swap before initialize after initialize all the ones that you can uh see here um these hooks you set them at initialization of a pool and it's going to be the same could not be the same but ideally it's gonna it's going to be the same for a specific pool throughout the the life

of that of that pool um and implements logic uh all these functions you can Implement basically whatever you want um and we're going to see a little bit of of that now so what can hooks do uh in this list I give a couple of examples a hook can be an oracle can basically say a price of a specific token of a specific pool can be another router or another position manager could be Unis swap B2 we can set for example uh um we can kill the range implementation of B3 and B4 and just have swaps on the whole range of a pool we can Implement lending borrowing let's say that we want to me a

u token that represents the position of uh liquidity of uh a user we can give rewards we can uh give access control to a function um for example not everyone should Swap this specific token so kind of like a block list or allow list if we wanted to basically you can do anything you can since you can uh code whatever you want you can Implement whatever you want that's why I'm kind of like here talking about this because I think this is going to be very interesting um next year a lot of uh protocols will be building on un of before Hooks and implementing their protocols there so since it can do anything also means that we can have out

of out of date oracles we can take positions uh of users we can uh blog list a specc uh uh specific uh list of addresses uh we can introduce bugs um we can take tokens from users we can basically introduce any bug and that's why we have to um talk about security considerations to start um multiple pool management so here we have an example of actually actually it's not an example is a simplified version of the initialized function in the pool manager that unisoft before implements it has um three main parts the first one is checking whether you're passing uh a

hook contract um then it calls this after I mentioned uh before initialize hook and then it creates the pull and finally uh executes the after initialized hook so uh as I said before these hooks are like uh contracts that anyone can Implement anyone can deploy and as we saw in this example what we're sending here in that pool key um parameter initializer has information of this hook but again this this uh function can can also be called by anyone so anyone can initialize a pool and therefore anyone can set for a

specific pool uh any hook so something we had to take into account is that a specific pool can have um or sorry a hook can interact with many pools so one thing to take into account in this example of this hook we have the before initialized function and we're setting the pool info which is basically just a an address as anist 721 let's say that in this before initialize what we want to do is just Deploy on your SE 721 that we're going to use later for liquidity providers to to me them an nft let's say a cat or something like that so as I said since a hook can uh be part of many pools um it's very

important for us to do proper Pool Management we cannot expect that multiple pools are not going to interact with a hook so every time we play with the storage of a hook we have to be sure that we that another Pool is not going to override that storage so in this case that address uh pull info the CRC 721 that we deployed if the pool a calls the hook and initialize it then the pool B can also initialize it again and that would break things um how to fix it very easily uh we have to uh do proper uh Pool Management maybe use a mapping so that

we can track uh every single pool in a different storage slot Access Control second one uh in this example also implementing the before initialized function um we're basically doing exactly the same as before U deploying the ERC 721 uh as you see this function and all the functions defined in a hook are all public and therefore I mean external and since they're external anyone can call them and that means that if I wanted to just call the before initialized function again for a specific pool since the all the information that I'm showing there in the parameters I just can set them uh when I send the call data to to the

blockchain uh I can uh without any restrictions uh for example override a specific storage slot lot of a specific pool um how can we fix this as we saw before here the pool manager is the one that usually calls the hook this is not necessarily always like that and I think that the unisoft team decided not to add any sort of like modifier in the hooks just to give full customization uh for developers but most of the cases you would want the pool manager to be one the the one that calls the hook and uh modifies its storage so um very easy way to fix this just add a

only pool manager modifier and avoid uh these hooks to be called from other from other contracts logic checks this is more like not that related to unisa before but something that I'm pretty sure we're going to see a lot in odic next year when when we check Hooks and it's basically that since these hooks are going to be um developed by uh anyone um you're going to have bugs and these bugs can be like very silly things such as in this contract we see this before add liquidity um hook that in the last line is this is basically it um it mints some rc20 tokens as a reward let's say for

liquidity providers and as we can see in this code every time that a user adds some liquidity will override its uh its rewards easy way to fix this uh just add a plus there this is a very silly issue uh of course and I just want to reinforce that again like logic issues is something that we're going to see in hooks very often and it's important to get this code uh code base uh and hooks audited finally um unexpected reverts uh this is a very interesting one and it's also uh kind of like uh can happen in in Uno before because of the flexibility

that it gives um let's say that we have a before remove liquidity function here um that in the last line checks that a specific price is greater or equal than a minimum price and also let's say that for some reason the price recal is always uh lower sorry higher than this uh specific price what will happen is that this before remove liquidity function will always revert uh which can be a problem because if we add liquidity and then we want to remove it um we are not going to be able to do it so uh this sort of interactions in Paris as in like at liquidity uh remove liquidity we always have to take into

account and be aware that if we want to for example interact with the uh contract with the pool and for example we add liquidity we have to make sure that we can remove liquidity um this is again a very uh simple um example that can get your liquidity logged and uh you're not going to be able to collect fees because uh the collection happens in in this operation um but there are other examples that can trigger this and other things some of them um arbitrary calls to external contracts that's something that can definitely happen again because if you want to do a swap and after or before swap implements an arbitrary C to anary address someone could uh take all

our tokens for example that's a very common issue in the past upgradability uh all these hooks can be upgradable so we have to be aware to interact only with those hooks that we know that if they're going to be upgradeable the process of upgradability uh is set on Place properly and that we are not going to see any or we're not going to have any sort of surprises um Doos is via long Loops or external calls that revert very similar to the example that I gave before but let's say that in that specific example we perform an external call in the remove liquidity uh contract and that function call reverts well we're not

going to be able to remove the the liquidity it could be that that contract is also upgradeable and then upgrade they upgraded it and it also revers because of that so also uh be aware of that uh since we can basically build protocols in hooks uh we have to be very careful that uh we don't write INE inefficient code that will uh make all these operations very expensive we can have or Oracle price manipulations spot price uh issues or a price issues in uh in our oracles so basically any known issue in defi can be can be present in your in your hook so as a general recommendation when we build hooks we

have to be aware that things can go wrong not only because of how hooks are implemented and some of the examples that that are inherent to um to un of before but also the fact that Builders are going to be building on top of before through hooks can introduce normal bags that we see every day in defi um and that's it thank you so much [Applause] thank you H our final speaker for uh the first

session this morning is going to be arbas from imuni who's going to be talking about the Bug Hunter guide to high quality reporting so please give a warm welcome to our [Applause] buz e so morning everyone uh I'm Aras and I

have been a smart contract triager on imuni so imuni is a leading bug bonti platform for smart contracts and blockchain so I will be presenting topic on bug Hunter's guide to high quality reporting so using my own triaging experience uh I will be sharing what are those qualities that makes reports truly exceptional so let's dive into the topic so the whole agenda of the talk is divided into two parts so I will be doing a high level overview of five key

qualities of a great report then we will be exploring each of these quality with uh good examples versus bad example to see like how it goes so starting with the one of the first quality is uh the neat and clean title uh and the whole purpose of having this neat and clean title is it should summarize the whole issue so just by reading the title itself you could uh get the whole picture around the issue and uh the next next we have this bug description where it's all about like what the bug is and where the bug occurs within the code base and one of the key

qualities the white hat follows who submits a great quality of uh reports is they always explain uh the issues with uh with doing a comparison between the expected normal workflow of the functionality versus the malicious behavior around the functionality so this is really helpful uh when it comes to bug bones so as a triager and as a judges who are not much familiar with the code bases new code bases so having this expected Behavior versus uh malicious behavior functionality it it makes a lot more easier to uh understand the whole issue around the uh around the bug and uh the next thing they do is they use the proper

formatting so whatever the option the platform offers uh like bullet points or the markdown options so they use all the options with the whole purpose of increase increasing the readability uh and then next thing they do is they follow this proper referencing of the code so we know that bu submission could get complex uh because you have to go uh you have to explain the Nate structure of the code so going inside inside of the function going into another internal function so it's really important to keep the flow and explain each of each of that flow with a proper referen of the code lines so uh that's that's the bug

description the next key quality is uh White hats always go beyond the attack surface they always focus on the impact uh so one of the example is let's say the white had reported a vulnerability where he mentions he found a reeny vulnerability in a specific function that's cool but what's the impact outcome of having this attack Vector like what damage he could do to the protocol or the user of the protocol that's what the impact is so they always go beyond the attack Vector so instead of just focusing on the attack Vector they go and determine what what is the final consense like consequences of the impact that AER can achieve so that's

where the impact comes and the next we have this proof of concept so beside just submitting The Code PO uh High quality reports often they provide uh dependencies that is required in order to run the POC and as well as the environment setup unit in order to uh run the POC so also it's really important uh to have this PO output within the submission because uh it's super helpful for triers and as well as judges so looking at the PC output you can reproduce uh the uh like you can understand the whole whole issue around the issues like without even reproducing

in most of the cases so it's super helpful to have this PC output filled within the PC uh the last thing they determine is they think about any feasibility limitations so whether uh that could affect the course of the exploitation so they think about are there any limitations uh that could uh interfere with the course of exploitation so they be very open transparent and think about like what are the walkaround like uh they can bypass this feasibility limitations so these are the high level overview of uh five key qualities of a great report on on in the next slides we can explore each of these quality with some of the

examples so starting with the title uh here's the bad example of a title uh which totally focuses on the attack Vector which says uh delegate call vulnerability in a proxy manager uh which does not give much of the context and here's a good example of the title so good example of a title is always a mixture of three composition that is like attack Vector then the source then we have the final impact outcome so here unprotected delegate call is the attack vector and source is a proxy manager is the contract then we have this delegate function within the proxy manager and

then it leads to the gri So reading the title it should sum up the entire issue so you can get the whole picture around the issue uh next we have this bug description uh which it's really important to keep the bug description neat and clean just explaining what the bug is and where the bug occurs within the code base and also explaining this uh uh doing a comparison between this normal operation of the functionality and versus the malicious uh behavior of the uh functionality to just draw the difference like how it deviates from a normal

operation and the third we have this impact so here's the bad example of impact or this white hats often do so whenever they submit their impact uh like in the case you can see the white hat reports there's a reentrancy vulnerability in the withdraw function where he mentioned like which can lead to unintended behaviors and unauthorized State manipulation uh which leaves you a mystery like what are those unintended behaviors and all so here's the good example of impact so using the same example of reeny vulnerability in a withdraw function uh the white had wrote like uh he it could result in an impact of direct theft of funds from the

contract uh then we have the bad examples of Po's so generally we see only two cases uh the first one is a lab grown POC where the white hats develop the poc in a very control simulated environment just to demonstrate uh the attack vector and the vulnerability around the issue but it's not uh really applicable in a real world scenario so it's not actually demonstrated on actual code base so so we don't accept that as a p because it's not uh real world feasible uh then we see a lot of this onchain Fork

modification so here are the two examples of it uh where white hats go and actually go and modify the storage of the contract they go and modify the storage to wh lists uh to perform certain operations uh which is totally not acceptable because that's not how the actual conditions where are on the uh main net deployed contract uh then the another example we have this uh fundry cheat she uh cheat code they use uh I call this as uh unlimited money glitch where they meant like lot of token Supply uh Capital uh just to demonstrate that act we do

accept the cheat codes but it should be practical uh they should always provide the source like from where they are going to get the uh Supply so it's not like uh using the uh Capital which is not actually feasible within the ecosystem so so here's the uh examples of bad PC uh then the last we have this feasibility limitations so feasibility limitations are uh to think about the uh think about the questions that uh that could interfere with the exploitation of the issue so the questions you could consider like uh how cost effective the attack would be

to carry out for an attack like how much the attacker is investing into the attack what are the capital requirements he is putting there and how much profit he is getting out out out of the attack and things like uh are there any specific conditions the attack uh attacker need in order to execute the attack or if the attack uh is being done for a long period or over the multiple blocks are there any chances of risk of detections or are there any timeline for execution so you can always determine this Factor based on like the gas cost the attack is inquiring and as well as the capital requirement the attacker would need in order to carry out the

attack and things like the M Market slipage effect uh on the profitability the attacker would be making so and there could be many factors depending on each and every uh different scenarios and cases so the whole purpose of this having feasibility limitation is to be very open transparent to the project that yes there are some limitations and also think about what are the work ARS they could come up to bypass those feasibility limitations uh finally here are the advantages of high quality reporting so we have seen like high quality reporting

often leads to faster rewards uh it's mainly because uh it makes uh very life easier for our triers and as well as the projects to go and understand the issue and reproduce as well as this leads to a faster uh resolve resolvement of the issue because it removes the whole Hassel of back and forth communication to gather the more information and often we we have also noticed that high quality reports Al also leads to a very high end rewards it's mostly due to the effect uh effects of the efforts the white hat is putting into the submission and uh also there has been potential uh chances of getting the Goodwill payout

like even if your submission is getting duplicate or uh or if it's a know issue the projects always uh they go ahead and they always do a Goodwill payout for your efforts over there and lastly the white also build this reputation dist trust and this inv this gives them more opportunity where uh more opportunity from the project side to get him involved in know some private audits as well and private programs to get him participate just based on the high quality submissions he submitted so yeah so these were the five key qualities and uh the advantages of

high quality reporting so that's it thank [Applause] you great tips arbas thank you for that so with that we come to um the conclusion of this first session this morning and I believe I can see breakfast uh being catered so for those of you who are just coming in or came in earlier please feel free to go get some food coffee tea and uh we are going to start the next session in the next you

know within the next five minutes so thank you e

e e e

e e e

e e e

e e e

e e e

e e e

e e e she was in the main frame check the

computer check check the computer the main frame computer I access the main frame Jin is more of a f currency but it can con it can be converted into crypto quadria CX which is Canada's largeest Bitcoin exchange you can access the main frame by remote I hacked into the main frame at the bank the main frame I can't find a Canadian server I've got to break into the the main frame I sent an engineer to check the main frame look like they dumped their entire main frame onto our facts and into our computer cross check fat B's profile with the main frame at Lang um I you know from the FTX finances perspective we had infrastructure but from the customer risk and finances perspective

much's they're calling it the Roman half spell r o n i n system that would take some sort of super Mainframe computer so the market cap is 2.68 trillion dollars and now the mark oh oh it went to zero tough fight 100 lowest cryptocurrency could make you a million they've only up the main frame cou jez in the main frame just to tap into red star's main frame Anita yeah going to run that against the main frame for me okay check the computer comp the main frame computer I access the main frame check the computer the main frame

computer God damn it you're in the main frame hello I'm excited to open session two of DSs on behalf of Co by talking to you about how to secure the future of crypto but first a quick introduction for those who don't know me yet I've been a research partner at Paradigm for over four years now and I found at se over two years ago I've also been to security researcher for my entire life so what exactly is Seal well seal stands for the security Alliance we're a nonprofit organization whose mission is to secure the future of crypto we do list various initiatives some of which she might have heard of and some of

which you'll be hearing more about after me so how exactly do you secure the future of crypto well I think it's a three-step process one identify a problem that's affecting cryptal security two come up with the solution to the problem and three implement it now you might think that the hardest step is to come up with the solution to the problem however I would argue that the hardest step is actually to implement it after all you might think of a solution that's blindingly obvious so obvious that all it needs is someone to do it but that's the hard part you need to convince other people that your solution is the right one you need to

convince them to work with you on the solution and then you possibly need to convince the rest of the community to adopt Your solution ATO we've gone through this process a lot of times while implementing various initiatives and so I wanted to go through one example with you to show you how we at SEO secure the feature of crypto and also to give you some ideas on how you might be able to work with us in the future if you have a solution in mind affecting a problem that you see let's talk about living in the wild west what I mean by that is crypto security back in 2018 back then security best practices weren't really as well defined and projects were being launched every other day although these projects were not

quite as big as the projects we know and love today rather these were much smaller maybe one or two contracts there were also various small communities of security researchers working to try to further best practices the best they can for example he might have heard of the white hat group which was responsible for rescuing the Dell or the eat security telegram Channel back then eat security was a small private Channel where you had to actually apply to get in now back then the way the security scene worked is that there are a few individuals in the community which acted as trusted points of contact this means that most of the time if you had a security question or security incident you would end up reaching out to one of

these people I found myself serving in this role so did a few others like Zack xbt now obviously in such a system it's very easy for these individuals to get very overwhelmed and obviously this is a problem additionally these Community bases were growing larger and becoming more accessible which is really good for welcoming more people into the space but it's really bad for keeping confidential information in a close loop at some point we were actually really concerned is it possible that there were bad actors lurking the shadows in these group chats waiting for people to post something like hey does anyone have a contact at some protocol

at which point they would know that they have about 30 to 60 Minutes to find a bug in that protocol before the white hats could get there in time so we were also facing a second problem how do we quickly coordinate or announce sensitive information that we didn't want to make public right away I actually ended up writing a design doc about several issues this being one F back in 2022 uh although at the time I called it the rapid response Group which isn't quite as catchy you can see the framework Reserve though the thought process of the fact that there are so many people who are these individual nodes in the security ecosystem but while every individual node has a broad

network not every node has the same network and so if everyone was in the same group operating together then that Network could be much more complete and response times would be much lower however the reason this never got implemented is because there were some very obvious problems for example does everyone actually agree that this is a problem and does everyone actually agree with a solution and if people do well where is the activation energy to get people on board and how do we quickly build momentum so that progress doesn't stall then one day there was a perfect opportunity and by the perfect opportunity I'm referring to the Viper Zer day which caused Ry locks to be

totally ineffective now there aren't many proes out there that use Viper today but one of the big ones is curve and because the Ry locks can be bypassed this meant that the curve pools could be drained and sure enough a few attackers drained multiple curve pools for over $50 million at the time as the incident infolded the security Community created multiple War rooms to try to in triage the incident these groups all worked on Rec causing the incident at the exact same time and these groups were all trying to contact curve in down projects at the exact same time needless to say this entire situation was extremely disorganized and chaotic and although by the end we had all Consolidated into one place the

process had still left much to be desired in fact I was talking about this very situation after the incident with white hat named P Cacho when I realized that this was very similar to the rapid resp resp group idea that I had come up with just a few months earlier and so I shared the idea with him and he agreed that it seemed like something that we should try and so I gathered a group of 40 people that I trusted put them on a group chat and within that within a few hours we had the beginnings of what with later become c911 within a few days we were ready with the bot and we announced a project to the world so what do product Market fit

looked like well today c911 has handled over 1,200 tickets and we resisted in numerous critical incidents including the attack on radiant Capital numerous Twitter account takeovers and too many malare and fishing victims to count one incident I'm particularly proud of how we handled was the tapioca social engineering attack we created a war room and rot caused the issue within minutes and finally were able to recover over $700,000 before the attacker was able to take it we're also setting best practices for war rooms and creating dedicated hotlines to communicate with large projects and chains in the event of an emergency overall we're optimizing the

incid response process so that what happened with curve doesn't happen again it's worth noting that the reason this worked is because of the curve incident after all due to the curve incident everyone could see exactly what the problem was and everyone could agree that the solution had a chance of working the incident itself also served as Catalyst energizing people to put a solution in place very quickly finally a very loud and public launch helped drastically improve the chances of this project working out but just catching lightning about a once isn't good enough Our Hope with C is that we can make this process repeatable we hope that thir SEO you can quickly gut check

your solution with the community to see if others are interested in it we hope that seal will also serve as activation energy for people to start working on your initiative knowing that It ultimately has a good chance of success finally we hope that seal itself can help promote the initiative to the rest of the eego system presenting it through a better lens than if it were just a solo project ultimately we hope that through seal we can take this three step process and make the hardest step not about about implementing it but about coming up with a solution instead thanks for listening if you want to learn more about seal feel free to visit our website or our Discord server

or just message me [Applause] directly thank you so much um so next we're going to have kelc and ISAC and they're going to talk about the War Room initiative uh at [Applause] seal e

okay okay great working so this session is about the security Alliance War games and War Games is just one initiative of the security Alliance so if we go to the next slide perfect so this is how the security Alliance initiatives fit together so you'll hear from a number of people that are involved um over the coming sessions in this block and uh really they're all complimentary so try and think about um each part of the picture kind of fitting together and so my name is Kelsey nabin I'm kind of I'm a seal but I'm also laughing as a seal in a way so I'm actually an academic by training and I'm doing research on the security Alliance as an example of

security in the digital economy and obviously it's an exceptional example because uh they're First Responders to you know a number of issues as well as build building um social social and Technical infrastructure across the ecosystem to secure the future of crypto uh so next slide so this was my first experience of War games uh stepping in uh to this welcome message which happened uh on a scenario which was an exercise with a major defi protocol and now I'd like to hand to Isaac PKA yeah hi everybody um I'm Isaac uh I lead the war games Initiative for seal uh I'm also the co-founder of a company called field three which focuses on incident response training um I started working with Sam a

couple of years ago um when the security Alliance was just forming um about how do we solve the problem of teams just completely melting down and panicking in war groms once an incident finally happens and so what we wanted to what we were trying to solve was just how can we prepare teams for these high pressure scenarios so that when an incident inevitably happens as it does like no matter how big you are or small you are um it's not uh it's not meltdown scenario and like you uh trust your team you know what to do you know your tools work and so what could we do to prepare those teams and so when we do in these war game scenarios or you could also think of them as just like incident response drills but we like to think of them as war games um is that we' just

help teams test and improve both the social and the technical resilience of the team it's one thing to know that all of your tools are going to work uh Under Pressure but it's also another uh to know that uh you trust your team and you know that everybody's going to be able to uh perform prop properly and so we're not just trying to incite panic in teams when we do these drills but we want them to practice emergency response and so in these drills there's there's three main phases uh we do just a lot of Open Source intelligence gathering which just basically means we read every public dock we read every contract and we understand how the protocol Works uh we do a tabletop scenario in which we come up with four or five different uh possible things that we think could go wrong tailored to the protocol and then

we ask questions like how did you discover this issue do you have internal monitoring that alerted you to this or did you wait for somebody to just post on Twitter like looks like you know this exchange is getting hacked again and so like is there monitoring that exists how does thees is there a Playbook that exists who is responding who's awake how are you communicating with these people the the tabletop exercise helps us understand uh th those components of like what is the structure of the instent response maturity of this protocol and that helps us lead into the third phase which I think is the most fun where we actually do a live attack simulation and so we set up a forked Network we Fork all their infrastructure we replicate all their monitoring and then they get uh and then in some uh period of some hours on a certain day um

there is an incident that takes place and then everybody has to join a war room and respond as if it happens for real um and we learn a lot of very interesting things about how teams respond under pressure and it helps teams just understand like uh how ready they are uh so one thing one reason why I think that these war games are important and uh we could also zoom out and think of this more as like an oper operational security uh in uh training um a lot of the recent hacks have been not due to Smart contract bugs which is great an ATT Testament to the tooling that a lot of people here have built it's like we're making fewer and fewer of the same dumb mistakes on the smart contract side but we're making as the protocols get more uh complex and large

and become really critical Global Financial infrastructure the operational side is suffering and so what could we we do to help teams prepare operationally for how to actually run these things long term these are cross functional exercises so we're not just going in and working with the devs um but we're working with their Auditors often one thing that surprised me that I learned in this is that a lot of the times Auditors will have like these really longg goinging retainer arrangements with these protocols where they're not just auditing your contract but they're there for you to join a war room maybe they're on your guardian multisig um to help support the protocol uh so we're dealing with the devs the Auditors the Guardians who are actually supposed to be there and available to pause like are they going to show up on the day of when you actually need to

pause um or are they like off in the woods and forgot to bring their Ledger and can't pause the protocol um and then as far as like the communications team there's a lot of tension we see in these War rooms between like okay the devs want to say publicly this thing is happening on the protocol right now but the communications people that control the Twitter are like no maybe we should uh rephrase it so you want to have the communications people in these things as well and legal because once you start having these like uh conflicts day of between like devs legal and Communications of what can we actually do what can we actually say you want to have that worked out in advance far before uh an incident actually takes place um so we've had the opportunity over the last year year and a half to

work with a lot of protocols in the space and we've learned a lot from how uh the best teams operate um but the thing that I wanted to emphasize on this slide is like how can you work with us uh there's a few different tracks one is we just published a open- source toolkit for how to run war games um on the seal GitHub there will be a link later in the slide with like a long video walkthrough that I do saying how do you do this stuff what to look for and so you can look at the open source uh the open source repository um I'm holding a workshop at Devcon on how to use it um there's the like seal sponsored non-for-profit track and so if you're a big protocol that wants to get one of these drills um it at no cost to you you

can come in and like get on our schedule there's a waiting list but like we can get on the schedule and we can work with you um to do a drill at no cost of the protocol and then there's also like a a new like paid track that we're working on with like external uh companies including my company where if projects on an accelerated timeline they can get a drill uh within uh within like a month or two um so the reason why we do war games again is uh uh that Under Pressure like here's this quote that we found online that I actually found very hard to attribute um that Under Pressure you don't rise to the occasion you sync to your level of training I just think that that's very applicable um and it was either attributed to an ancient Greek poet or the Navy Seals but we couldn't

figure out for sure um each build for this is actually quite custom uh there's a lot of moving pieces that goes into this and so for each drill it changes how we actually set up the live environment because so many Protocols are different but the core components stay the same when we're doing a live drill we of course need a fort Network so we could use like Anvil for that we can use Tender Leaf for that we need a block Explorer because like we need to make the environment feel like a real scenario when the team is debugging and so they need to have some ability to go into like a tenderly debugger or or like an ether scan looking UI and actually click around and figure out what's happening we need to have their monitoring replicated so if they're using for toot or if they're using like

a custom solution or if they have like things like hyper native or hexag set up like all of that stuff should also be connected to this forked environment um so that it feels as realistic as possible uh we create a lot of bots that simulate user Behavior so we'll have like the these networks are like very noisy and so we like we actually have Bots that are scripted to be if we're working with a lending protocol we have Bots that are doing deposits and lending and swaps just so that like the Explorer is filled up with a bunch of junk as it would be in a real scenario if you were like dealing with an incident and working on ether scan uh we have like of course the exploit Bots where at some point they'll like ramp up an intensity and exploit of the protocol and then

often there's uh additional like internal uis and things that we need to Fork so there's a big like week two we build process that goes into each of these drills but we're trying to make it more and more consistent so that we can do these at a at a faster Pace yeah I think it's difficult to emphasize how much background research and work goes into preparing the scenarios and actually building the infrastructure to run these and I don't know if anyone noticed in the previous slide but on the optimism base which was our first um multi-chain war game uh seal 911 was actually called in the response which was really cool and so these are some of the scenarios that uh have been included for different war games that we've run and one way we think about prep comping these is

through uh vulnerability uh mapping which is a methodology that I've um written about and um especially in relation to Dows as well so thinking about the socio technical legal and economic uh dimensions of a protocol and protocol ecosystem and like I said as we've expanded the war games into like multi-chain scenarios looking at those cross-chain uh dependencies and potential Cascade effects as well and so obviously as a social scientist I'm really interested in the human and organizational dynamics of uh security uh and so uh these are some of the things that have come up uh or the this in the scenarios and also in the responses or or room for improvement uh

in the various things and we do a a massive debrief with every war game we work with the team on that and try to provide them written documentation and help them reflect on how they actually went in that and uh each war game uh has also um sort of builds links into the other seal initiatives so as I mentioned 911 um one really interesting aspect is that mindset of uh security which uh p p Pascal kavio um as Sam mentioned as well said in a quote you know absolute effing paranoia is the mindset that you have to have when it comes to blockchain and then also uh a recent initiative um by the security Alliance uh from the seal um ISAC of the

intelligence um and anal is platform uh is around uh dprk workers or IT workers and some of the social engineering that's happened um behind the scenes that has that have led to to Major exploits and so um that's another human and organizational Dynamic which we're looking at in the scenarios that we're running and so we aim to help uh Foster a an attitude of continuous Improvement uh each war game results in a big debrief um the ethnographic observation which is uh myself is allowing for kind of generalizable insights to be published across um not just academic papers but um blogs uh book chapters books Etc

forthcoming uh as well as practical teams for tools so as Isaac mentioned um the open source War Games tool kit and then we're also running a live event in Bangkok on the 10th which has some really uh exciting uh scenarios that Isaac has prepared and so so we did want to save time for questions we've still got about uh 10 minutes if anyone has one on their mind while you think about those I'll just throw to Isaac for um some best practices that are arising from seal war games and I don't know if we have a microphone Runner but I okay I will run if I need all right we do yeah so in before we get to uh the questions just

while you have a chance to think about them uh I just wanted to go through like just a few slides of like what have we learned from how the best protocols respond act um so that we can uh so that we can just share some best practices one is like maintaining multiple channels to reach not just guardians but everybody who's kind of critical an incident response something that I always like to ask teams to think about is like what happens if there's an incident and telegram is down the day of the incident like how are you actually reaching these team members do you have backup ways of reaching them um are you sure that all of your pager systems are working uh in cases where pre-signing critical like pause transactions is appropriate that's another thing that we've seen lot of teams do um where there's certain like you know one bullet

in the chamber pause transaction that sits somewhere accessible by certain people um in case certain things have to happen or more teams I think are also using kind of these sophisticated autop paw like uh service providers which uh which is really great to see as well um one thing that we learned we learned a lot of things from from how the urine team operates they like this was like one of the uh this was like a really cool one for for me to learn how it works um and this is all about like Risk isolation and so a protocol like urine which has like assets deployed into many many many different protocols throughout the ecosystem it was to me very interesting to understand how minim how like little contagion there was from like one strategy to another and so the idea of like each uh uh component of a

protocol being like Atomic and isolated so that it can't leak and cause issues with other parts of the protocol and also every time a new strategy was deployed um there were there was like an extensive like Risk diligence process and an emergency procedures card so that when the incident happens it actually says step by step one like this is the right person to call but also if this person's not available you take these steps to rescue funds from where they were deployed so that no one's questioning the day of like how do I actually do it because the emergency procedures are defined before the funds are actually deployed uh another thing on risk isolation from a which I thought was very interesting was how like different collateral assets are can be isolated with these different like Risk

Flags so that it can also minimize like Contagion between different asset classes and individual collateral assets being able to be paused or Frozen without affecting The Wider protocol like Risk isolation I think is a key thing that we've learned um incident post-mortems is super important this is another like shout out to the urine repos GitHub just because like they have a really great like a postmortem uh process for every time there's been something that happened and how that gets integrated back into the Playbook uh and F uh also monitoring mirroring mirroring monitoring and so like if you have an extensive monitoring setup on Main net you should also be running that monitoring thing on any like test net or any like Forks that you

have so that you know uh so that you know that these monitoring tools are working and also perhaps like do things to trigger those monitoring tools because uh the biggest stress of a lot of these like backup tools is like how do I know it's actually going to be there the day of when the thing happens and so if you have like a test net setup or a fork setup run your monitoring against your fork setups as well uh in the same way that you would do it on on Main net um yeah so coming back to the high level these are some of the actionable recommendations uh that have uh Arisen from SE war games and we're going to pause there and invite any questions from the floor which I believe we have some hi a quick question on what are

your findings for best response teams have like from psychological not necessarily technical perspective operational psychological how do you prepare for the incident yeah uh something that we saw in some of the with some of the larger protocols is that there's a very clear like Incident Commander who just is taking lead of the of the scenario and so there's one team member who is like always sharing during when when there's a war room call like there might be like 30 40 people on the call but there's one person who's like The Incident Commander who's sharing their screen and they're like taking notes live where they're like okay there is a Playbook that we're following we did this step we did this step and then they're keeping track of like all the different things so if they've directed The communic to prepare a public statement they're like that's like they're they're the

person that's like putting that on the Google Doc and saying like hey communication team what's the status of this hey did we check with legal on this hey the root cause developers that are looking or the people that are analyzing exposure like there's one person kind of managing the incident and keeping notes in a in a very public way um versus like kind of teams like kind of fracturing out um that's that's something that I thought was very important yeah I think one of the most um stressful to look at the other side of that um scenario is I saw for the response team was calling Guardians on a multi- so they went through the actual process and called the real guardians but that was I think five people across time zones so they woke up people in the middle of the night um and yeah that was quite

interesting because I think it's a common practice across protocols but for them to actually go through that process of making contact U was very precarious in terms of getting on to them and it was um quite a time delay as well in terms of um slowing down the overall time to to to pausing the protocol and ultimately stopping the the Hemorrhage any other question hey guys um you're amazing uh question about uh compound I think it is cu did compound have something happen after they had run a war game and I was

just wondering if there was anything on the feedback back cycle there because obviously it's somebody that you worked with and then they you would have hoped would be more prepared for what was coming uh we haven't like fully closed the loop on that and I think that maybe we'll just chat with the op zeppin our confound folks to ask like did the training we do actually end up helping you because that would actually be probably a useful data point for us to understand uh so I mean we could ask Michael I guess yes thank you let's I won't give numbers but there was a like uh amount of time for all the emergency signers to sign and we found very specific areas where some signers were not as fast as the others and we were able to correct

for that which was very helpful there you go anyone else I don't see any hands raised excellent uh if not then I'll just explain what we have on the slide here pleas uh so on the 10th we have a event that I'm very excited about with uh co-hosted between seal and tender League with participation from a number of uh of of great protocols including the folks from a and Unis Swap and and ur ur audit um so we're going to be doing an event which is like a like live War Games kind of CTF style event where everybody will be competing against each other to white hat rescue funds uh on a bunch of uh on a bunch of challenges

that we deploy um and so this will be a really good chance to show off your white hat skills uh and then so if you can make it to the event fantastic also if not I'm working on kind of like a take-home exercise version of it that we'll publish so that you can also like kind of go in and and do the challenges um very much inspired by the work from the uh red Guild with Dem vulnerable defi um and with the benefit a lot of like retrospective hack proof of Concepts from the immuni blog so very much thank you to those teams but yeah we're doing some very cool uh live white hat exercises on the 10th and is there prize money uh there is some prize money but uh it's mostly for the glory um okay uh there's this is a link to the

war games drill template I think we'll just tweet out all of this stuff after uh so that you guys don't have to see this or like write this stuff down but I recorded like a long video of me just walking through actually in detail how you do um a war game including all of the Bots and stuff that I've uh that I've written for that uh if you are a big protocol that wants to get on the wait list for like a seal sponsored drill you can uh fill out a form on the security Alliance website um if you're a protocol that is on like an accelerated Time Track and really wants to like hey we would love to do some like internet response training um and do a war game uh there's also a forum on my website uh Shield 3 where you can fill out just

information about your company and we can uh and fit you in as soon as possible uh if you're also interested on this on the open source contribution side or working with me just feel free to find me uh anytime throughout this week or even after thanks so much [Applause] okay um so coming next we have a panel titled what your order really thinks but is afraid to tell you sounds quite interesting um please welcome uh yanis Joseline medie Michael and [Applause]

Alejandra oh there are the chairs all right we'll wait for the chairs to come up or we'll just grab them actually if the panelists could grab the chairs I'll introduce everyone that's how we can make an efficient use of our time sorry you have to work for this panel all right so uh everyone we're looking very much forward to sharing a lot about everything that we've worked on uh with seal as well as as individual audit firms um so my name is Michael Ellen I work as the head of solutions architecture at open Zeppelin where I do a lot of high level security work with our top clients uh joining me will be uh medy from Sigma Prime Sigma Prime is also a very well-known audit firm and also maintainer of Lighthouse one of the major ethereum clients uh we have Alejandro who works at ammuni one of the

major bug Bounty platforms as well as an audit uh competition platform uh we have yanis from ddab who also does Audits and has a very good uh security scanning tool and uh Joselyn who is from Trailer bits we only have okay that's all right I'll Stand you guys sit hey I got a Podium oh never mind Perfect all right just some time chairs all right and last but not least Jocelyn from Tayla bits another very well-known audit firm in the space as well as a long-standing uh traditional security firm working with the US government telling them how uh blockchains might be taken down by nation states just in case they have to do that all right so uh we've got a load of questions I prepared but we're going to

keep it pretty free flowing if we have time we'll take some uh questions from the audience um uh but just to set it up the idea of this panel is even though we all are effectively paid to tell our clients one way or another how uh to write their code more securely uh at the end of the day it is a business relationship which means that we have to be careful about just how far we go sometimes and our feedback uh sometimes there are things that we are repeatingly seeing with clients or maybe multiple clients that we see as a problem we probably still provide that feedback but at the end of the day the client is free to choose how they implement the code and while we might still insist on our vision of things in the report um there are always limits potentially to that

and how far we can go as well as the fact that this is sensitive information it's something that you know if we do have a problem with the the way a client implements something uh you know we we can't publish about that if it's something that is sensitive and confidential um and that's not to say that this is always like the limiting factor on that problem but it's just we know we we see growing Trends in clients we see particular issues just in the industry uh and this panel is kind of an idea uh an opportunity to sit down and talk about that um so I guess what I want to do is just kind of go down the row give everyone a chance to give their own maybe introduction but then also say like if there's one thing that you've seen out there uh that you you've seen

in a lot of your audit clients that you wish would change or or something that you think has become a common Trend in the industry in the last couple of years um what what's something you've seen and and why do you think that's something that we should be looking to address so I'll start with you jelyn okay hi everyone yeah so I work at 12 bits um if you don't know TR bits we our security company where we specialize in high hand security technology uh we are working with blockchain client but also with traditional application security cryptography and so on uh I think one of our kind of differentiation is that we spend a lot of time doing research and open source tool you might know a or Med user which are tool that we have been built over the past years now to to answer to your question what

of you know one things uh I think people might kind of like not think about when when when they think about security audit or security riew is that security is not going to be solved by external provider like anyone of us is going to help your team is going to to help your company get better at security but at the end of the day your own security like if you are building a protocol if you are building a project security is your responsibility if you think security external provider is going to own security for you you are not going to need to make it in the long term um yeah Medi co-founder director of Sigma Prime um blockchain security and research firm um security assessments

throughout the entire stack for web three protocols and also proud Founders and Main containers of Lighthouse shout out to the lighthouse team who's been doing a tremendous job over the years um powering about 33% of the ethereum network today um one thing that I see too often uh unfortunately is it's kind of echoing what you've been saying Joslyn is that people think that they should they're okay to launch straight after a review from us just because we've we've reviewed um a smart contract so there's two things here um I think the fact that a lot of protocols still rely solely on onchain security to protect their users is obviously um

really dangerous right we've seen what happened um couple of weeks ago rent Capital few months earlier with other uh centralized exchanges um in fact the vast majority of the hacks happening these days happen through Standard web2 Security um Mal practice so that's something I work hard to try to change with our clients you know getting them to realize that security goes Way Beyond onchain um and smart contracts exclusively uh we'll get in there I think we're making progress but it's a slow and long fight um and just echoing what uh Joselyn was saying um we're in

fact completing a review right now for uh a protocol that is awaiting our report to go live right um these engagements are all time boxed mind you the more time you give us the like the more likely we are to find bugs right um we've got aite finite amount of time projects have a finite budget we can't you know keep searching for bugs um for years right we have to call it at some point if we keep finding critical vulnerabilities until the last day of the engagement chances are if you give us a bit more time we'll find more critical vulnerabilities so what I've been noticing is projects just awaiting the final report to go

live and that is terrible that is absolutely terrible just like Jus was saying it's your responsibility you're launching that thing not us um so it's really important that you own the security aspect of your protocol get external security assessors of course but that's not um that's not it you have to really do your own due diligence and we'll talk about some of that stuff I'm sure in a bit uh hey I'm Alejandro MOS McDonald um unsafe call on Twitter and I'm from immuni uh so I'm a triager at imuni been with imuni for um a little close to three years um so I see a lot of the um uh reports that are going through our

platform two projects about these live vulnerabilities um that are being fixed before they're exploited um so on that question um kind of related to what medy said about you know what mistakes we kind of see um you know uh one of the mistakes is just inheriting ownable and using only owner for every single function for Access Control um so uh I mean jokes aside I do see a lot of projects um taking that level of centralization for granted um and while it typically isn't something that's accepted as like a bug or a mistake um in an audit competition um it's it's something that I feel like doesn't get the attention that it really should um so you know

projects obvious should be practicing that uh principle of lease privilege um and uh as as well as consider that threat modeling for uh the accounts that are given that access um so I mean projects is kind of signaled pretty strongly at least on the audit competition side that they they don't really care too much about uh centralization risks um but um which I can somewhat agree with but we then have to ask ourselves at at what stage do we consider that okay um I'm jannis Mar dakis I'm co-founder of doob we security company uh we have a decompiler that you may have used uh for deployed evm contracts uh getting to the question of the panel

here uh I think I have to very strongly agree with everything that has been said first of all the message that security is your responsibility when you're being audited that's the strongest message you can have that's the most unpleasant truth about security we don't own security as auditor s you are the owners of security uh if you get a report from us if you get any bug report any any idea of a bug you're supposed to generalize from that you're supposed to ask yourselves why was this bug introduced why didn't we think about that ourselves what can we do to generalize the experience to other parts of the code and in the end everything is time boxed uh an external provider

cannot can only do so much about your security and they not the ones to suffer the most if you get hacked so ownership of security is absolutely the number one unpleasant truth the number two unpleasant truth follows from the time boxing is not all audits have the same confidence although we want to always leave an audit with having high confidence about the code uh high confidence is still a variable uh the time boxing is much more important than the highest confidence so the the better stage you can leave your code in your code and all the other artifacts including test cases documentation Etc

the more opportunity you give your auditor to have extremely high confidence that those are kind of the two obvious truths uh I just wanted to bring them up to begin with and we can get into more entertaining anecdotes a little later I guess all right thank you all uh definitely 100% agree with everything that was said I hope a lot of people here who are in a similar industry uh agree as well I think just generally speaking making sure that we're not putting all the onus on the last security step uh especially when sometimes this is not every client but sometimes occasionally you have that client that is um asking for a review and you realize that you're actually the first person to reveal that pull request other than the developer that wrote it uh and then you have to wonder maybe

that there should be some additional steps and checks before then um so given that as well as a lot of other like things that should probably be done between the code being written and an auditor or an external Security review happen like what are things that you've seen and this I'll just open up to anyone or we can go down if everyone has thoughts on this but uh like what's one thing you see where you're like you are not ready for an audit like you should go back and do a lot of other basic things before you pay me to look at your code and tell you all these things knowing that no matter how much time you give me at the end of it you're still not going to be ready to deploy I'm sure we all have heaps of uh yeah we start from that and come back uh

so number one if is if there are obvious security vulnerabilities at the design level I mean you're not ready for an audit if someone can find a flaw in your business in your fundamental design uh that shows that you haven't thought about things from a security standpoint uh even when you were designing the protocol you're not ready for a code AIT I don't care how great your coders are what can these flaws be things that suffer from obvious say replay attacks you create a protocol it's supposed to be doing something it's supposed to be sitting as an intermediary as a middleware somewhere and It suffers from obvious replay attacks you haven't even

thought about that because the API the way you designed it is flawed in that way you have never thought of what you can do there that's that's an that's just an example but the most it's the most telling sign that you're not ready yet for an audit that you haven't thought about security when you were putting together your design or even your business proposal when even you were going to investors uh sometimes you haven't thought about security and we've seen some instances of that uh so it's it's very that's a very hard message to give to a client right uh to go and tell them look this is not just broken it's fundamentally broken so before you go

for an audit please try to think critically of your protocol from a design standpoint and by critically I mean try to think a little bit as an attacker so like the answer you might get from the client is so you're saying I can't deploy next week so it's going to take another two weeks right I do I do have a slightly different perspective and I think you can go through an audit or a security overview whatever I want to call it from the moment you are ready to receive feedback you don't need to wait for your code to be finalized you should actually seek for feedback early on because security provider might help you with a

design they might help you you know at the early stage of your project depending on how long you're going to develop your project if it's like three months probably you know you're going to wait at the end but if you're building something for a year it is probably worth to have check you know over time and you know get getting feedback so I think from my perspective you should seek security overview from the moment you are willing to get feedback I if you give it for free everyone will follow your advice yeah I mean it can be a pain engagement like right we can do that you know at different stage but from the moment you're like okay the decision I'm going to take now are going to have an impact in the long term this is where like getting feedback is really as long

as the expectation is like okay you're not going to be ready to deploy immediately but you know which stage you're at expectation is really important like you know if you're like you know half with your development maybe some function are not written maybe you don't have access control Maybe you haven't figured out like you know how you're going to do like your year strategy whatever if you are okay to receive feedback from other component and you have the right expectation of what you are waiting and what you are going to receive I think it's a good time to to to go through that process if if I may I think the key word here is expectations yeah um just managing expectations on both ends um I get I get some of my testers um you get frustrated sometimes um and also some of our clients um they they can seek early uh

feedback U very early feedback and that's usually quite healthy for the protocol um but the problems arise and I think that's what you're probably referring to when um yeah the pressure comes from the business level of the executive level we need to launch um this week or next week is a good example everyone is rushing to launch their uh latest upgrades or latest protocols before Devcon uh and there's a lot of pressure on those developers and deployers um to ship so it's all about managing expectations but um I I can certainly relate to what you were saying yanis uh it's quite painful sometimes um and to go back to your original question on um what I've seen that kind of made me smile and and

and I just you know sort of shipped back sent the client back essentially um was this uh lending protocol shall remain unnamed um came to us for a security assessment um thousands and thousands of lines of solidity code terrible code by the way um and they barely had any tests barely had any unit tests so what we do at Sigma Prime I guess that somewhat differentiates us from the rest of the uh security provider space is uh that we Rite our own tests we don't trust our clients tests particularly when they're written in JavaScript um and uh yeah so we deployed the protocol locally and literally just tried to deposit stable

coins and withdraw them and that didn't work that failed so going back to your to your question that that to me was just a massive red flag obviously you haven't done any testing let alone endtoend testing um and it's a very tough conversation to have back to what you were saying earlier this is a commercial Arrangement right we're getting paid to spend time to review your protocol so we'd like to think that we're quite intellectually honest and you know instead of chewing through budget and wasting our clients's budget sh and wasting our time we just call it and we're like hey I'm just going to pause this we're not going to charge you for the remainder of the engagement fee I'm going to go back do what you need to

do and then you know Circle back whenever you think you're ready again but it's it's quite challenging because there's obviously you know scheduling issues that arise uh we're not a massive team so we've got you know a bit of a backlog to go through but you know I'd rather do that than waste my client's money and my my testers time Mak sense uh one more yeah yeah uh I was just going to mention yeah having those audits be part of the development process in pipeline rather than an afterthought or a final review before you go and get deployed like having that security um uh Consulting uh when you're developing the architecture of the application in the very beginning is super important especially for um also audit competitions when you're going

into an audit competitions you're not typically going to have people um debating the the root of your design of the architecture of the application people are just finding bugs um right in the in your app in your def app um so you could if you go out at competition or audit audit audit and you can end up with the kind of a ship of thesis of code where Parts have all changed but the the design is the same and and that might be flawed yeah I think I'll I'll add one counter example that kind of sets expectations that's what I've this is actually the opposite problem this is like the code is too clean why do you want an audit where we uh have gotten people that came to us have anyone here use like opens up in contract wizard like just spits out an erc20 token comes

from the library most people will just take the library on face value um we've had people come to us say like we literally used the contract wizard the output is exactly the same we've changed nothing but we want you to do an audit on this we're like well it's our code like and it's 100 lines of code and it's going to be kind of expensive because we usually don't do very small audits like this uh but they're like Yeah The Exchange needs an audit um which is ultimately what they're sometimes certain part of the business going forward the security value of like actually getting that feedback isn't what they're looking for they're looking for you know the stamp of someone said this is safe even though if someone spent five minutes looking at that and new basicity they'd be like oh this is just a normal token so that's the

challenge on both sides um even though that's still a better example I'd rather have someone who doesn't need an a get one than the opposite but that that's usually challenge of scene one quick plug I guess I'll say or or here's maybe the next thing I would say is um seal Frameworks has obviously been trying to do aot lot to put a lot of best practices into in front of people um hopefully in front of people before they're going for an audit so a lot of the things that we might be getting paid in the last stage to tell them to fix when it is most expensive to fix they can be incorporating early on so I mean obviously we would plug steal Frameworks because most of us have been involved in that but what are other things that you wish clients were required what would be

required reading for clients before they ever come to you for an audit or or just things that you would insist that they they absolutely should do before even you know other than the obvious things like do testing do other things like maybe more specific things that you think isn't as common as they should be sorry do you want to perhaps mention or explain what Frameworks is because actually I think I think you should explain what so you've been really in there okay so I invite you all to go to mata's talk at Devcon I'm sorry I forgot the actual date and time uh but just look it up on the Devcon website uh it'll be formally announced in a few days um this is a an initiative that's really really close to my heart um when it comes to security best practices in in web 3 there's a heap of different

resources out there and it's quite difficult to know which ones are outdated which ones you know you should be following which ones actually apply to you so we thought it would be a good idea to consolidate all of that and curate all of that information into one single um website at the moment um and that's called framework so if you go to frameworks. security alliance.org um it is live and it's um basically basically in the form of an MD book markdown um and it's got a lot of content and you can filter the content that's applicable to you based on your role within the project that you're affiliated with um say if you are a community manager you will have sections around hardening your X account your Discord server your

telegram channels um if you are a developer you can get detailed best practices in solidity and other languages same you're a devops person secure devops deployments cicd hardening all that cool stuff which you know again we're not Reinventing the wheel uh all of that information is U pulled from reliable sources but it felt like we really needed this um I'm not sure about you guys but I have a lot of clients that ask us um hey what am I supposed to do here I'm deploying I've got ec2 instances on AWS um I'm deploying all these this infrastructure but I don't really know how to secure it now we can all Point them to this one resource

frameworks. security alliance.org really excited about this Mata and Frederick have done a tremendous job in uh putting this off the ground yeah sorry I forgot your question so I guess in addition to that any other things that we should be uh getting people to do before their audit the specific things that might not be as obvious I guess the one thing I would say is um doing mainnet simulations as much as possible especially if there's going to be deployment involved especially if there's an integration or an upgrade or anything that they're already relying on existing as it should on on on an onchain context like integrating with the known protocol sometimes interfaces don't line up sometimes assumptions break sometimes it changed from a year ago when you were first writing the code um but yeah

curious if anyone else has other things to throw into that um I think actor modeling is uh something that's I don't see enough of um that I think is should really important so kind of like What actors are interacting with your protocol which ones are privileged the the level of privilege there as well um that I don't think I've seen necessarily A framework for that just yet that everyone is using and I think that could definitely be something that would be really helpful yeah I think invariant development is probably something that we have seen a few team doing like using fuzzing kind of writing down what is like the expected behavior of your protocol and trying to test it with different method we have seen a few team doing that and usually the team that are doing it are kind of better in term of

security uh but overall like majority of the of the kind of team that are kind of developing smart contract don't have this type of kind of technique and and and and framework within their development process and I'm hoping that you know with time we will get to a point where more people are writing in variant testing them with fuzzing testing them even with manual review uh I think that will help a lot to understand what is supposed to happen with the protocol if you're infamiliar with invariant it's basically the idea is to Define what your protocol is supposed to do like for example if you have a a near C20 token you should not get to a point where someone balance off is above like the total Supply like if you have 1 million token and like a user has 2 million token probably something

you know is going on so if you can Define like a list of 20 or even more invariant of your protocol and and see on how you can test them you are going to get you know better overall in term of security yeah very much strong vote of confidence for that I mean definitely do variant testing as much as possible we have amazing tool Suites nowadays you can do a lot of very good testing Beyond basic unit testing you can set up your entire environment to be pretty much a faithful simulation and then if you do invariant testing uh you're already ahead of the curve that's that's wonderful still there there can be very mature code that has very deep bugs uh even though it has excellent test

coverage just because there was a recent change that was not really uh didn't really agree too well with the initial design the initial design made some assumptions then you make a late change like initially you were only accepting eth now you're accepting other uh you're accepting ERC 20 tokens and suddenly all sorts of things break everywhere and your test Suite even though it has excellent coverage it has excellent coverage of in terms of code paths but it doesn't have excellent coverage in terms of the breadth of tokens that you can accept so the things there there are always caveats there's always a certain tension there in the end it's all again up to you but the

shallow things that an auditor will look at are things like do you have good test covered uh because that that is very much a strong indication of your code quality overall and let's let's be honest auditing is not about testing primarily right aiting is about understanding the code in depth and and forming a deep mental model uh so the Auditors focus on the code primarily but when they see something their that's that's not more normal their first question would be why is this not caught by test cases why isn't there a test case for that unless it's a very exotic scenario that obviously is a corner case would

never be touched by a normal test case U and that's that's really a bad sign if this could have been caught by regular functional testing of most of the code I think a good takeaway could be if you're a founder and you know you want to go to deployment you should aim for 100% test coverage if you cannot reach 100% because maybe there's some condition that cannot be reached you should have explanation and documentation don't go live if you don't have 100% test coverage that's a really basic simple rules but no one follow you're here yeah if I may uh there's two more things I'd like to add to that wish list um

dependency management I don't see that enough and I know for a fact one thing that keeps us up at night security researchers are supply chain attacks yeah um so and having this conversation last year with some seal members and supply chain attacks seemed so far-fetched like ah it's never going to happen to us and we've seen a lot of examples um since so just being aware of what your protocol relies on in terms of external components and monitoring um the I guess security posture of those components is is really really important and echoing uh something Alejandra said around um

and what you mentioned as well yianis around known limitations today you are again peing on lending pools not not sure why but um if your protocol does not support nonc compliant tokens non erc20 compliant tokens to not name names usdt um and you know all of a sudden next year you've hired new developers you've let go of existing developers and all of a sudden these new devs have introduced support for the for usdt specifically um having documented somewhere that limitation will help you down the line um so I think these two

things know limitations dependency management is something that I'd like to see more often um and something I slightly disagree with Yan Nissan is um your take on Auditors aren't necessarily testers um as I said for us we found that writing our own tests whether you know integration tests n2n tests or fuzz tests has allowed us to uncover some really intricate edge cases in uh critical protocols that would have gone unnoticed had we only relied on our manual review capabilities um yeah that's just how we roll I really like that you mentioned the erc20 tokens that

are supported because um you know when we're looking at reporting and and and live vulnerabilities on chain uh we can only support security researchers when a project has signaled intention to integrate that token either through governance or or through documentation or something so that's that's really important if you intending to add anc20 token it really helps in uh incentivizing security researchers to disclose those issues I'll actually add to that we've we've found cases where we have effectively reported critical vulnerabilities not because the code necessarily was insecure but the way they had documented the way they would deploy the code would have led to a critical vulnerability and we've had people like debate that and say well we wouldn't have actually done it like that we would have figured it out eventually no it's in the it was in

scope the documentation was in the code base you know it's it's in the scope list so um and we've also had cases where we've had clients that we've worked with for a very long time and they have had a lot of turnover and they're asking us like questions about their code base because the developers are so new and we've actually had more experience looking at that code than they have which is always a very stressful situation to be in because you're like wow yes we do know but like if you if we're the ones stopping you from potentially doing unsafe Behavior you know even sep security view just like knowing what you're capable of that is a little terrifying um um so I guess like with that like what are some what are some cases where if you've had clients um like asking you to do things that are

just so far out of scope for like what you think a security like firm should be doing like like like just like weirdest requests I'm kind of looking for some fun stories here but also maybe some things that like signify areas where the industry needs help uh like I mean one example that we've seen is just like unfortunately incident response for like social media takeovers um which I mean granted we we have tried to help out there and like chat out to seal 911 because they're the real heroes and helping in a lot of those scenarios which is we've just gotten to the point where we refer them to seal 911 because they're going to be the the fastest and most effective at helping um but yeah what are other cases where you've had a client where like okay you clearly have a security need but we're not we can't

help you you have to build this yourself or you have to go to someone else that is more suited for this um yeah I'm not sure I like a specific example in mind and one of one of the thing here is that because we are walk with tr additional client like people working in web web two uh I do think we see more less the same problem that we see in web two in web 3 U so like some of the things that our client are asking on the blockchain side are also some of the things we see you know in traditional application Security in cryptography or all type of things so I'm not sure there's really like one thing which is completely out of scope of what we can do usually um I don't know if you have never had a client ask

can you just write the code for me yeah a very prominent L2 back in the days this was two or sorry three three and a half years ago we've done A Very Long Engagement this is a massive L2 with a lot of tvl today that engagement ran over the course of a couple of months we found countless numbers of criticals and high severity bugs to the extent where they had to throw away the code base and start from scratch I had a call with the co-founder and CTO and he straight up asked me whether my team could just build the thing obviously that's not what we do uh for reasons primarily Independence reasons um but I kind of echo what you're saying we we're comfortable diving deep into

the stack when it comes to security and we've had clients come to us for like you know web app security um it's not the most costeffective way of securing your front end to because the sigma Prime to do that but if if you want we can take a look at that stuff um same with securing your clout deployments there's plenty of of great uh traditional security firms out there that can do a great job at that but I understand that some Founders want to leverage existing working relationships for that sort of stuff uh and we're some we're quite happy to oblige um whenever needed um but yeah what gets me is the hey can you just build it what why don't you just build it you broke it the first time so okay that's a good point like we do have like no partnership for things like

know web application kind of type of we can do it up to some point but we are probably not the most cost effective to to do it uh but yeah even engineering like for example we have we have cryptographer that can build kind of an engineering protocol in term of cryptography for smart contract it's true we might you know we have a couple of relationship with specific you know company that does that so yeah like usually if we canot do something we know someone that can do it you know in a good way all right yeah the uh another question I had was going to be what are what are some interesting things you've seen like that clients think is secure but actually doesn't make a big difference or or maybe yeah what are like common Trends you've seen like where like okay clients seem to be

implementing this feature it's adding a lot of overhead or it's doing a lot of things but it's not actually addressing the core security issue like so what what are some things that people think are secure but actually don't either make a big difference or really just aren't worth the effort anything either like what are overhype security like features implementations and it's not necessarily you say they're a waste of time but like there are other things you wish the client had implemented first for example uh multi sigs with very low thr thresholds um that's something thing that you know projects automatically think oh I'm using a multi I'm protected um but you know if you have a one of X multisig you're just increasing your attack surface there so you know understanding how to properly Implement um a multi strategy

understanding you know again threat modeling those actors that you're giving those keys to like who's who's uh who has access to those private keys where are they stored you know if you have an even if you have an eight eight eight of 11 multisig and seven of those keys are held by one person or like on the same aw AWS instance like you're just as insecure as we've seen that by the way this has happened this exact example has happened last year that's actually a core problem like there is no way to actually verify that keys are held independently um like it's almost like you'd have to do a signing cemon where everyone's like in person and like in a hoodie if they want to be anonymous or something and still you you can see okay everyone keep their hands away from the keyboard and then this guy sign and then

this guy sign um I've seen people try to do signing ceremonies to protect for that EXA sort of thing and I've also seen what was the other thing I had with multi6 that came up um oh having a large multi where the mass majority are not technical because in effect the majority of those non-technical people will just follow whatever the most technical person says which means that your threshold really doesn't actually hold in practice so let me be devil's advocate for a whole bunch of things that we've said here if it was up to an auditor or a security expert to say say is this code secure sign here or should this code go live you know we would always say no right so it's not our business and for us our business is safety not

progress so we are not going to make money off of the protocol being launched so we want to be extremely conservative so everything we've said so far is extremely conservative and clearly there are best practices from the security standpoint that are not best practices from a business standpoint you cannot audit 17 different times until deployment because you it's it exceeds your budget uh same thing like Devil's Advocate objection to multisig a a one of n multisig yeah it doesn't make make you more secure it makes you less secure but it's better than no multisig because in five months I mean it's convenient for now and now what I want is convenience and in five months I'm

changing my policy and now it's five of seven and the five are completely distribute all over the globe to Independent Partners so it's not just one recipe and it's over you need to take ownership of security if you violate best practices you know why you're doing it you're doing it for convenience for now and you keep in mind that my policy will be that later I will upgrade so for anything that we say that it's good or bad there's there's always a Counterpoint that there are good reasons why people do these things in practice yeah I think that's a good point are you consciously making a tradeoff or or are you yeah or are you taking a risk without realizing there were better

options in the first place um so I think we're at a good point to maybe take a few questions uh from the audience see if there's anything that uh people want to ask panel uh anything that you want to know going up to maybe your first audit any questions really or that's scary oh I see someone hi is an NDA a sufficient sort of um start point for engaging one of you external Auditors is that like a typical thing

that uh clients do is that sufficient is there more like you know as a Founder we're always kind of uh um OCD about like giving out our code to strangers yeah in India like you know as long as you interact with entity that you know you have some trust with like should be sufficient I think like as long as like you know like the jurisdiction of the company you are interacting with follow whatever you know you are trying to do uh that should be sufficient I think unless I'm missing something yeah I we're not not lawyers uh so clearly your lawyer will advise

you as to whether the NDA is sufficient to protect you but it's a very common step if someone wants to keep their code private and I think what we do is something that most auditing firms do we have a pre-signed mutual NDA uh pre-signed on our end so you just sign on your end and immediately there's NDA on both sides typically the auditor is fairly trusted if you combine this with an NDA which gives you some legal guarantees the auditor is not going to go in competition with you they're not going to launch a financial protocol to compete with you if you have a a new idea so you're not the auditor is not who you should fear in terms of competition in terms of confidentiality

especially if you also have an MDA I I think my opinion would be it's perfectly sufficient if you're worried about confidentiality of your code Andrew oh we have one more question hello hey oh over there okay uh so we were setting up the narrative that um ala is not liable for any loss or uh you know the project is solely owner of their security but do you think that if they have your recommendations and opt for all the security layers that you suggest uh would you be able to take the responsibility that this project is

secure enough to go live on production and uh we can can we can you know take it up from here that it's it's good enough to go live and you can take the responsibility of being you know being an auditor I understand that with security it's it's your reputation when you pass an audit it's gets staged but like is there a time uh when you can take the responsibility by saying that yes we have you know uh fully audited it and it can go live on production and second thing um uh you mentioned that uh you mentioned um you know U case where um they came and they don't have the test cases right and you send them back the lending protocol that you were

talking about right um and also you mentioned that um you have to you know um have a relation with the clients to uh um you know make them more clear that web3 security is not just on the onchain it's all the on on the web two side so how would you you know you know do you take any Community initiatives to you know instead of you know shipping the client back do you take any initiative to uh tell them that these are the things that we are going to take care of for you like for securing the project um yeah the first one first question you had which was the like question of like

will we like say like this is safet to the exact wording is going to kind of be important I would say if a client took every security suggestion that we gave them and implemented it to our satisfaction we would say this client has implemented every security recommendation we could give them and so in our opinion they have done as much as possible to be prepared for deployment in our opinion would we say it is safe and it is ready for deployment maybe kind of imply it but I I think I don't know I'm be curious to know what other people saying I answer that not my code not my call yeah it's up to you your code your protocol you go live you don't go live it's entirely up to you not my call to make second question question um yeah I mean we we can't do that for

them right we can point them we can explain to them the reasons why we're sending them back the stuff that is missing the stuff that we should expect to see that is not there we can now Point them to the framework website and be like hey you haven't followed these sections please go back to the drawing board and Implement these recommendations but for Independence reasons we're really big on Independence at Sigma Prime we will never ever come in and actually change your code basee what we can do every now and then is raise pull requests in your repository to add tests and that is it we will never fix your code we will never add features we will never do anything that uh I think you're suggesting so it's your code your call as to whether you

want to go live or not it's your code your call as to whether you want to increase your security posture before you come back to us but that's just how we roll again maybe other people have different T we we've done testing advisory we've even implemented some tests for them as examples but at the end of the day they have to know how to like build them and run them and maintain them uh and own them if they're just like oh they ran because those guys gave us the test and they're running successfully so it must be safe well then that's not we we haven't done our job because then yeah there's a lack of ownership and then we're not going to always be there to make sure those tests are running properly and like security is not binary it's not it's secure it's not secure it's like kind of a a

spectrum where you can you know get as secure as as you know as you can and yeah I agree like your card or your responsibility it's it's the way it is all right I think we're at time um so thank you to all the panelists for coming up thank you for all the work you're doing both uh as uh commercial businesses but also as contributors to initiatives like seal coming to these conferences and sharing your thoughts um and yeah uh look forward to the uh next panels that we'll have talking more about what SEALs up to thank you everyone [Applause] oh please leave them ch um so coming next before a 10-minute

break uh we're going to have a panel uh the last panel before the break uh the white hat Safe Harbor is going to be moderated by Kurt and the participants are charm Richard and also Kurt [Applause] all right hello everyone so welcome to the last uh Little Seal presentation here um as you just heard this is about white hat Safe Harbor um two of us are actually last minute Replacements so that should make this a bit more

interesting and we're just going to go ahead and do a quick round of introductions um I'll break the ice I'm Kurt Barry he him um my I have a few affiliations I'm with seal I'm a spear bit lead security researcher um and I spent four years with makerd Dow as a protocol Dev uh where I was involved in some of the early Safe Harbor discussions in fact Roberts so I'm Robert um I'm co-leading safe harbor initiative at seal and then I'm co-founding Scot which is another security startup that operates under the Safe Harbor agreement hey I'm charm I I do legal operations in the crypto space uh helped get seal and safe harbor off the ground and I currently work with a maker ecosystem

actor hey everybody uh my name is Kurt opsol I am a associate general councel for cyber security and civil liberties policy with the filecoin foundation I'm also uh on the board of the security researchers legal defense fund and uh prior to filecoin I was working at the Electronic Frontier Foundation uh where I was there for close to 20 years uh working on the coder's rights project uh trying to uh help defend security researchers when they got into trouble for their goodfaith security research all right oh yeah so let's kick things off um charm uh what is white hat Safe Harbor yeah uh so the white hat Safe Harbor is a legal framework that

can be deployed for protocols that might come under hacks what we call exploits and if during an exploit a white hat swoops in acts in line with the ethics and terms that are stipulated within that legal framework then uh we essentially provide a best efforts like to the Max uh legal protection excuse me Li protection and uh probability of reward for their their awesome work and saving funds and that's exactly what we're

trying to encourage with it all right yeah next question for all the panelists um what brought you into helping with this and what interest or background made you uniquely qualified to give that help I mean Hudson who isn't here right now but is originally the panelist is who brought me into this um I was working on Skylock which is my startup originally and we were trying to find a way where we could if we detected a vulnerability that was in the mol we could reverse engineer that vulnerability executed ourselves front running the hacker and then save the protocal funds and we wanted to try and craft a legal document that would actually let us do that without it being theft and Hudson gave me access to one of the very early versions of Safe

Harbor I think 3.01 although I might be wrong about that um and then I've been helping out on and off ever since uh yeah W 3.01 we're on like seven now that's impressive the versions of ballooned I imagine the Gabe is not happy about that um so I came in actually under Gabe Shapiro who is co-founder and most prominent architect of the Safe Harbor framework uh at the time I I was working with this other n city Lex Punk uh and SE saw what I was doing and was like can you can you help carry this and

it was absolutely my pleasure and uh yeah that's that's what I've been doing with it just helping flesh it out and get it ready to present to you all these guys have been incredible they've donated hundreds perhaps thousands of hours just to fixing the legal agreement and to building it and creating all of the things that need to be done in order for it to work and to protect white hats it's it's a community Affair it's incredible okay so I got into this space uh defending defending hackers defending security researchers uh this is about a commitment that finding vulnerabilities fixing those vulnerabilities requires having good security research and requires a legal environment in which

someone can conduct that research find the abilities talk about the vulnerabilities to get the problem solved and we don't want to have legal constraints whether it be civil lawsuits or criminal charges to get in the way of making a more secure world and unfortunately there's a lot of times where either uh you know the the companies's involved a vendor doesn't want their vulnerabilities to be exposed and they threaten or even go after a security researcher for what they have found there are times when prosecutors want to make a name for themselves and show how tough they are in hackers but instead of going after bad faith actors they find a goodfaith actor because they're easier to find and uh can try to cause trouble try to cause

interpretations of the law even when they're going after bad hackers that will have uh ramifications for good for so trying to ensure the space so we can have stronger security fine fixed vulnerabilities yeah and I'll add that I was brought into the early Safe Harbor discussions to represent the sort of defi protocol side of things um because you know ultimately uh we want to make Defi and other crypto protocols safer um but you know protocol is not going to add something that they worry could have potential Negative Edge case uh impacts and so you know I was I came on and you know made sure that it was something that protocols would be happy to

adopt and kind of on that note um I'll I'll open this kind of up to all the panelists um to explain you know how does white hat Safe Harbor work at a high level um why do we need it um and who is it protecting um so I don't know to say why we need it um maybe maybe Kurt you want to take that aspect why why do we need it well uh like at one level a key aspect of any sort of anti- uh hacking law is access without authorization and so one of the things that is trying to be solved with the wh hat Safe Harbor agreement is authorization having authorization ahead of time these are the rules of the

program you abide by these rules you go into there and you are authorized to do so taking away a key element of a claim against the the security researcher and by doing that ahead of time it makes it harder for an upset person uh a prosecutor to bring charges bring uh a lawsuit against the security researcher and so we're doing it to create the space in which this can happen and one of the biggest challenges one of the things that makes this like very interesting is that for a lot of security research like it's done maybe uh on the side or you know not not in a uh very public way but when there is an active attack going on in a D5 protocol it's pretty public like something is

going on right now and the time is super sensitive it is needs to be taken care of right now because if you wait to go through process and get authorization and so on the wallets may all be drained by the time you sort of get through that process into a good spot to try and do something about it and so getting it in ahead of time getting it signed up getting the you know the Dow or the the governance to adopt it beforehand protects you later I think that's beautifully put to to kind of jump off with that as well the way that it works is for a given protocol or for a given instance we go around to all the people who might again as Kurt mentioned under current hacking laws under computer

security laws that exist as they are's no sophistication like the the ones in the United States were created and under the Reagan Administration and they're like if you access a computer then you're hacking it uh which especially when somebody is like having funds drained or exposed they're not going to care who comes in and saves them they just want that help it's like you're asking for an ambulance um but as we have you know these Good Samaritan laws that somebody can come and help you and if you end up like giving them a booth boo boo they can't sue you for the boo boo while you were saving their life in the same way

we say in this instance hey we've gone around ahead of time made sure that all parties who could possibly act in that not so great faith way aren't going to have claims against you if you a white hat step in and actually Sav the day best efforts like like do your thing here we'll give you the information you need to execute we'll let you know what to do with the funds where to place them once you've recovered them and we'll reassure you that if you do this you'll you'll probably get like a pretty substantial reward and having this all clarified ahead of time would release

from doubt those who might hesitate and as Kurt said the really the 11th Hour when if if somebody's showing any sort of of like Bend towards an action it could cost potentially Millions yeah I mean buting on ch's point like for the white hat perspective the most important part about Safe Harbor in my mind is just how it's all standardized and how you can be confident in it once you understand how white hat Works we're being very pedantic very like certain that all of the different protocols that adopt Safe Harbor are going to adopt it in the exact same way that all of the protections extend ended to the white

hats are going to be the same protections no matter which protocol is adopted it and that the information that the protocols have to provide the asset recovery address the Bounty terms um any of the diligence requirements like K kyc requirements and all of the assets under scope all of that is provided for the wh hat and it's provided for the wh hat in the same way for every single protocol so you as a wh hat don't need to really care what the protocol that you're interacting with is you mostly just need to care that they've adopted Safe Harbor and and that there's an act of exploit and that you can save them and and I just one more comment there that's that's the real Beauty and and gab's work here is is that uh this is a legal instrument it's flexible in all the

right ways and it's standardized in all the right ways in in terms of adoption there's many different ways we understand that like not every crypto protocol out there is is going to be the most pristin like perfectly organized and lined up blah blah blah blah blah whoever you are in the crypto space you can use the white Harbor framework and that's what makes it incredible because on the one hand in terms of adoption we have and with this this has been so extremely vetted uh so much flexibility and on the other hand we have standardization so that when it's go time you can go into go mode

and that's I I just admire it as as kind of an object like that like it's almost an obar like damn yeah I like to think of safe harpus kind of like an extension of the bug boundy program for a project where you know if it's not under attack and nothing's going wrong you know bug boundy is how you would report things um but if something is going wrong and there's not time to report and be like hey you might want to fix that and you have to act immediately white hat Safe Harbor you know creates this umbrella of protection for white hats to to step in and take action and save funds which you know there that is an action that is not without risk right it's not like just sending an email with a PC right your transaction could get

front run and the generalized front running bot could end up with the funds that you were trying to white hat and so you can never guarantee that everything's going to go perfectly you know obviously you should have the best of intentions um but with white hat Safe Harbor you know it's a scenario where something's gone wrong anyway and you're at least going to try to help and you can have a little bit of confidence hopefully a lot of confidence um that you know you'll be protected for trying to do the right thing that's that's a really important thing to stress like Safe Harbor does not apply universally it doesn't just mean that white hats cannot suddenly hack your protocol if they've discovered vulnerability it only applies in the event of an active exploit if the hacker has moved first in basically all other cases contact c911

contact the bug Bounty provider contact the protocol directly disclose the vulnerability responsibly Safe Harbor is not the best approach in all circumstances it's a best approach when you have no Alternatives right it's it's seriously an emergency measure it is highly compatible with all bug bounties like like generally we recommend for incentive compatibility that you know the reward for a safe harbor white hat not be greater than you know the reward for an equant bug reported through the bug Bounty um so that you avoid an incentive for people to go and try to plaus in a plausibly deniable fashion you know create an incident that then they can white hat so that that's been thought about carefully enous but you know uh so so there are

great limitations on when you can use it um as a white hat uh but then on a legal level though um why should you trust it um because I've just highlighted that you know things can go wrong and you can get blamed for them so um maybe this is a good one for charm you know why why can we trust it who looked it over um and who is it protecting exactly and who's it protecting them from exactly as well I so I'll start from the bottom on that who's it protecting us from it's it's I The Meta is is that it's protecting us from blackouts it's protecting us from losing funds and and ultimately the reputation of this industry uh within the context of the Safe Harbor

itself it's protecting us from each other uh a protocol can include Bad actors in in the legal context who you know a lot of people here just after their bags no hate to that but if you're driven by greed and you've recently suffered loss you're going to go to any measure to to make recovery and for some it might seem ethical to them to Target a a person who was trying to help them and uh it's it's even happened in the past like like there's precedent for this as awful as it sounds and Safe Harbor kind of removes that from

from from the landscape it's it it it was a not so great feature and again a source of real hesitancy in in situations of emergency so I yeah protects us for from each other and then in terms of like who's been on this who's helped develop this it's oh my God it's it's more like who hasn't I mean we've had eyes from Australia we've had eyes from your favorite VC we've had eyes from the Department of Defense and it's it's like excuse me not doj I can't confirm I don't know about

the other uh but it's it's like I I can name a score of lawyers like I I the list would be like Santa's rolling off the stage here uh it's it's been vetted it's been battle tested we have faced criticism we have uh like put this through the paces and I'm I'm I I'm shocked that so many lawyers came together from every corner of the world and said yeah looks good to me no comments which if you've ever been doing legal work no comments

that's the holy grail and we it's I I've can't I've lost count of the Holy Grails so that's that's my word on that remarkable yeah exactly but let's entertain the scenario that something goes wrong a protocol adopted Safe Harbor um but then after a white hat you know acted the protocol decided you know what we feel like Prosecuting them anyway or maybe there was some user of the protocol that you know felt that something wasn't done quite correctly and they bring suit um you know or who knows maybe maybe a government just decides that it looks like a law was broken here and so we're just going to prosecute everyone who participated in the hack even if you

know they weren't you know even if they returned the funds you know which governance do things like that sometimes so um Kurt what what exists to to help out in this case and yeah yeah absolutely so just start like yeah obviously the agreement has been uh you know uh vetted put out there we believe that it is is really good but you know if you work work in the area of security one of the things is you have to make sure that even if you think everything is fine you got to also prepare in case it's not uh and so one aspect of that as I say I'm on the board of the security researchers legal defense frund uh and we worked with uh seal on this to make sure that there are funds available to

provide uh legal help if somebody gets in trouble for using this for doing some good faith white hat work on a protocols and nevertheless something comes up could that happen well you know it's a tough thing when when somebody loses a lot of money on to to a hack and there are some bad faith actors that they can't find they there's no way of tracking them down and then there are some goodfaith white hats who are presenting themselves to the world as having done this well you got you got one target for your your frustration and Ang over what happened and one of the things that that unfortunately can happen is when people are frustrated angry and they've lost a lot of money is they will lash out uh and uh you know a challenge

is often where it is not a legal action that um would have a very high chance of of success you know we eliminated the access without authorization but that does not stop someone from being able to threaten or even sue you know that they often times where people are trying to do that as a way of intimidation as a way of trying to uh uh put pressure on the other side and hopes that maybe that's a better bargaining position they can do some some compromising such uh and part of having the legal defense fund as a resource is to help give confidence to people who want to do this uh that uh you know while it has been

reviewed and vetted by a wide variety of people um so far it has not been challenged in in a court and it'd be good to have some lawyers if it ever was challenged to to help with those arguments to say why it is it is very good and some of the scenarios that we just talking about so uh you know a a protocol uh denying you know saying they repudiate the the agreement seems unlikely and that would be a particularly uh uh tough one to say well we we agreed to this thing but we no longer agree to it but perhaps a uh a member or someone user of that protocol says well I didn't agree to this this was done by some governance thing I don't you know agree with what the governance thing has done you can't hold

me to it and then that would put to the test whether the governance mechanism was functional be good to have some legal help in that scenario and uh also for for criminal charges uh the the victim does not have to agree uh the governments can press charges for alleged crimes even if the victim uh is like no I don't want you to press charges usually they don't uh usually it is a victim who is is cheerleading and pushing pressure to do it but it doesn't it doesn't always have to be that way so it is good to have is in case of emergency break glass uh and uh if it happens you know uh reach out to the security research your legal defense fund um and for that matter the

SEC res legal defense fund uh works for all sorts of security so if you're doing something uh independent of the white hat uh Safe Harbor but are doing some good with security research and and get in trouble for it also feel free to reach out to the security researcher legal defense fund if I could roll off one thing that Kurt said there um The Safe Harbor might seem it operates as kind of from a place of cynicality about the people involved I what it's it's really doing is is it's we're we're excuse me not about the people involved so much as like the the courts that you might face afterward like am I really going to end up being

indicted and then found in the wrong for trying to help somebody is that where our legal system is at no but even being yanked into the Civil system like even being hit with a lawsuit from one of these people who yeah those are the people we're getting a little cynical about because again you find this grade Drive sometimes in crypto we all know it uh we're taking away their ability to even harass you the white hat so that you can go forward do your thing use that talent that we know you have to actually get something done here that's that's going to save a lot of a lot of people yeah I mean fundamentally the way I see it the srdf exists because the

white hats are the ones that are taking on the risk in Safe Harbor for a protocol if you adopt Safe Harbor worst case scenario nothing really changes you get hacked like black Hat's not going to operate under Safe Harbor and if they do then it's not going to apply um but for the white hats if like Kurt and charm said if a badge protocol or if a mad protocol user comes after you you are taking on a lot of risk there and slrf at least makes me a lot more confident that I would not face that alone that I would not go bankrupt or I would not be ruined just by a single mad actor after I tried to help them yep now on that note um say Harbor doesn't get used if projects don't adopt

it uh which is its own battle now Robert you've been a huge help um with driving adoption and you know getting projects to to get on board um what are the non-legal Technical and onchain components of of doing this I mean the onchain components are really the onchain registry and then all of the corresponding protocol adoptions so the protocol adoptions are basically just onchain records of the details that the protocols Ed to adopt Safe Harbor so that's the stuff that I mentioned before the stuff that's standardized it's the assets under scope it's the kyc terms it's the Bounty terms and it's the asset recovery address the place where you return funds if you've recovered any um and protocols deploy this on chain and

then wh hats can see or any wh can see it just by querying the chain and then the second part is the orang and registry which basically just it's a smart contract Factory for the different adoption details it just keeps track of all of the different protocols that have adopted Safe Harbor and has a mapping of the protocol addresses are the protocols adoption addresses to the actual adoption details yeah so that's kind of technically what happens um uh charm is there anything else the protocol needs Beyond these technical components you know like how does a dow that doesn't have a legal entity adopt an agreement oh all right yeah so what we do here is we essentially have a process for the Dow to implement a

governance vote and we say is this is one of the the like striking parts of the Safe Harbor is we say if this government's vote passes then the the Dao and everybody who's part of it you know that amorphic group that has given legal Minds so many TR so much trouble we say whatever you end up being if you're classified as purple green or or whatever color under the legal rainbow it doesn't doesn't matter you consent to this agreement because it passed under your governance system uh

therefore the white hot is protected when they swoop in and save the day uh there's different configurations again this the the flexibility that the the white hat Safe Harbor framework has in terms of adoption is is really remarkable uh so I I I can't assure virtually any configuration that you're bringing uh to to the adoption process is going to be compatible with minimal imagination it's we we have templates and and guidelines for whatever you are and uh it's it's

fairly easy to follow them if there are actually legal persons who are coming to the table you can just have them sign on the DOT line otherwise if you're providing a product or service to other people add it to your terms of service so that users are are made aware that as they're engaging with your product or service they're also agreeing to allow these white hats to do their Jazz we we've been very thorough we've accounted for for most everything is it fair to say that we've we've done everything we could to make it easy to adopt absolutely absolutely and and and we're iring out Kings yet um I I I always love highlighting that this is a

community effort and it is to the very last and uh that's that really shows in the mindfulness of the document one fun thing that I forgot to mention but it's kind of an intersection between the legal aspects and the onchain aspects um and correct me if I'm wrong but for the Dows the actual onchain transaction to the smart contract registry is legally binding action that they take to adopt Safe Harbor um and I know that Gabe who is I think he's the one who came up with this yeah he is very interested in this idea and he's like working on it a lot that the onchain transaction that you execute can be a legally binding action um and I imagine there's going to be a lot of other stuff that comes out in the next couple of years that uses this same

legal principle to like start to combine the traditional legal agreements with more onchain registry stuff a lot of theory behind that yeah attestation yep great answers um question for Kurt um you've been in this security researcher protection business for a long time I'm wonder I'm wondering if you have some examples from your past experience to just highlight you know why this matters why it's important and you know how how it helps yeah sure I mean like I've been in this in a long time I have seen things uh it is you know it's actually improved quite a bit over the time uh there was a lot of misunderstanding you

were saying like the uh Computer Fraud and Abuse Act which is the US uh anti-hacking law came from the the Reagan Era and just a little Side Story on that uh as The Story Goes Reagan watched the movie War games uh which involved hacking into the uh nuclear defense system uh and that inspired the uh uh him to promote and and eventually sign the Computer Fraud and Abuse Act uh so uh going at it with a understanding uh a movie level understanding of of what uh what it could be but uh uh you over the years like in in the early days there was just a lot of uh challenges when industries were being confronted with

with security research that made them look bad you know they got they got popped uh they didn't like to be seen that and wanted to take it out on on the researcher and doing things pursuing them threatening uh suit at least at a minimum trying to silence the effort uh and there also had been some prosecutors who uh took things that I you know shouldn't have been uh cases and brought them anyway for their own political careers a lot of you know the the um uh prosecutors in places are often elected officials and such uh so one one prominent uh example is uh Aon Aon Schwartz who uh went into MIT uh that was lost awfully entitled to download

some uh academic articles uh you know under under as a student there uh went into a networking closet attached his laptop with with a cable to do it you know faster than they were anticipating uh and and perhaps more than they were anticipating but I don't think that should have been a crime because he was authorized to get th those articles and they hadn't anticipated that uh it would be done so fast but nevertheless a prosecutor went after him uh and was facing up to 35 years in in prison for for having done so uh the the organization that uh uh had these academic journals uh after a lot of public pressure said uh you know this this is fine we don't we don't have

a complaint with this but nevertheless the prosecution continued unfortunately uh this this led to Aaron taking his own life uh so we never found out how that that case would have end up and we lost one of the one of the RS uh in in both the open source movement and and doing security research uh and so like the this is this is sort of a bad place where where things started out uh for a long time the doj was also taking some very tough interpretations of uh terms of service so that uh with the assumption that if a term of service said you know you are not authorized to access our site under these conditions then that was access without authorization and th it was was criminal and just to give you a notion

of how ridiculous that is at at the time that we were doing some litigation around on this put an anecdote before the court that uh 17 magazine which is a magazine that is only read mostly by people under 17 uh had a term of service saying You must be 18 or older to access this website so basically their entire audience under the doj's interpretation were felons uh accessing without authorization hacking it by typing in you know 17 magazine.com into a browser push and return uh and so this is some of the bad places where it's G but I say it has gotten better uh most technically sophisticated companies are open to secury research now bug Bounty programs

have become common place uh and you know essentially what the the white out Safe Harbor is an extension of the idea of a bug Bounty program to a high Tempo uh uh you know immediate action scenario versus a slower one but it is an extension of that idea and so this is moving it forward but you know still we have uh still we have some problems uh just this uh this summer I was at the def security conference and then ended up getting pulled into representing a uh a speaker there who got a cease and assist the night before a talk was scheduled to uh stop by by the manufacturer so he was uh done some research and discovered flaws in these electronic locks uh and had done the testing on locks that he you know

lawfully bought and own owned the lock themselves so if anyone was to authorize any hacking on those computers and the the definition of computers is Broad enough to Encompass basically anything that might be considered a computer except pocket calculators and that's longer story on that but in any event he owned the locks he was authorizing to do it and but they nevertheless they brought the suit they brought a whole bunch of ridiculous claims that would have basically totally lost in court but there you are the night before your talk getting this letter uh anyway so it did work out uh we responded to them uh ended up delaying the talk to give some time to have the conversations and they eventually withdrew their threats uh and uh you

know uh thing was resolved peacefully the talk went went forward with the security research but like I was that it was still happening yep and so it's a a lot of good examples of how you know security researchers have gotten in trouble for a lot less than you know maybe uh moving a few million dollars on chain um in in an unexpected fashion all right we I want to be mindful the time because we're getting close to the end here um Robert um to date how many projects have signed up for white hat Safe Harbor um and where should teams go to get started on implementing it I mean we've got five protocols so far um balancer I think being the most recent one um and if you want to oh thank you

and if you want to adopt it then contact myself contact Dixon who's in the audience he is the one who is the real wizard behind all of the protocol ad options and um yeah like like we've said before it's it's pretty easy for protocols to adopt Safe Harbor if you're a dow it goes through the Dow process if you have immuni you can adopt using immuni if you are a regular protocol then like charm said it's as easy as just signing a legal agreement and when you do that you are giving wh hats the opportunity to protect you if everything else goes wrong um if the there's a vulnerability in your code that wasn't caught by the Auditors that wasn't reported to a bug Bounty and that is discovered by a black hat if got some zero day then we're not saying that it's going to stop the zero day but saying

that there is a much better chance that you're going to get your money back and that your users are going to stay protected a frequent criticism white hat Safe Harbor is that the the scope is so narrow you know only attacks that are in progress and you know most attacks are one transaction all the funds are stolen so they're so how would you answer um to that criticism of like well you know maybe the set of times that this actually gets invoked is is close to zero there's a thing to be said for how safe carber could be expanded where if a wh hat finds a vulnerability and can't contact the protocol or can't responsibly disclose it then they might want to be able to exfiltrate the funds and return them to users and there's

definitely I think a path where Safe Harbor could grow to Encompass that sort of stuff but right now we wanted to start off with what is most explicitly something that white hat should be able to do um like safe haror exists like Kur said it exists kind of as an offshoot of bug bounties and it only really exists because in crypto we have the opportunity where we can see what the hackers are going to do um or what they already have done and we have time to react to it on ethereum you've got what 12 seconds in the block time if a transaction shows up in the mle you've got maybe six seconds to respond to it um or if the hack occurs it's not behind some closed doors inside of a bank system it's on chain for everybody to see and and some attacks do fall into

this category of there are multiple actions taken repeatedly the the classic example of this is actually the nomad attack which was one of the sort of main motivating things behind it yes Safe Harbor could definitely be useful even in this initial form um which was where you know basically there was a way to steal money from this bridge and you know there was an initial transaction that then started being copied and replicated all over the place and you know some white hats participated but there were also many other white hats who were sitting there watching it happen and saying well I could save some funds but I might also put myself at risk and if I don't take any action I'm not at any risk so I'll just sit it out exactly it you know it's maybe not all maybe not all hacks and vulnerabilities

are like that but there are definitely ones that exist of that nature and so if you I think if you can add this and get you know marginally more protection at basically know downside risk U Still Still valuable you might have feeding frenzies like exactly as you described you might have an instance where a mle bot detects that a transaction is in the mempo and then front runs it you might have an instance where like someone deploys smart contract and you can tell that that smart contract is going to be used in a malicious way I know that there's a few people here actually who are working on that sort of tech um there's a bunch of different applications about 50% of exploits as of 2023 were code related exploits and most of those would be applicable for Safe Harbor I just wanted add like it is part

of a sort of Suite of best practices yeah so like you also want to have a bug Bounty program so you find the vulnerability before anyone's actively using it you want to have audits so you find the vulnerability before anybody in a bug bound he finds that you want to do you know secure by Design coding so that the audit doesn't catch it and so on so go all the way back the chain but you also need that thing at the end of the chain if the other checks haven't worked so far and somebody has to your this very short decision time period and if they don't have confidence that like they're they're not going to you know go to jail or get sued to Oblivion for taking an action then they might not take it and then the money is gone and we you know and we have yet another

horrible story a lot of people are upset so giving people some confidence when they have to make a very tight time period decision good or bad should I do this will it work out you want them to have the confidence to go for it save as much money as can be saved and that that is the purpose of the Safe Harbor music right I think we're slightly overtime so I want to be respectful of all the speakers later in the day and lunch and all of that so if you have any questions about Safe Harbor um come find any of us panelists or other sealed people afterwards and yeah we'll be happy to talk to you about it we've all got these lovely blue [Applause]

shirts nice um you missing something all all right thank you so coming next we have Dimitri sakarov uh talking about um how to inas how to inh test coverage you have will be like the screen or I have but I need to turn it off

e e e e

you want to click H you want to click that cck uh no actually it's from so it's like I think I have to perfect yeah yeah I think that can you see that it's not

fit uh let check it this is already fully covered right yes what on the screens here also like there is like here also same thing and you go to the no no okay yeah than ask

him my my mic is one I'm not sure what happened I'm running to see what's can make them smaller you have to from

the yeah if I know I could do that just a sec which one this one or this one this one this one okay no it's fine

yeah yeah okay yeah so hi everyone my name is Mitri and I'm CTO at mix bites and today I'm going to present my experimental framework regarding how uh you should write tests to catch some severe bugs uh before we start let me share a bit about mix bites uh so we're mostly focusing on conducting security Audits and research uh we have been working since 2017 and since that time we worked with more than 60 clients and performed more than

250 audits most of our clients are coming back to us with uh new protal versions and small updates in their code base uh so the list of our key customers are presented here so now back to the topic uh the general recommendation for writing test is often unclear for example preparing 100% test coverage is not save you from severe bugs also a general recommendation for using a hacker mindset while we writing the test is uh very hard

to adopt if you are not a whitehead hacker or experienced security researcher so today we will discuss the question presented here and the first one is a will 100% code coverage prevent hexs and the answer is of course not the second question is what exactly is a hacker mindset uh and the third one is is there any other type of mindset that will help writing tests and the last one how should writing test be approached to identify as many issues as possible before an audit uh before we go to next slide how many of you heard about about a hacker

mindset please raise your hand and how many of you know how apply to this recommendation okay it's nice uh so the framework like it's our experimental work and I went through a lot of different security audit reports and bugs that happened in our industry and uh came up with an idea that actually while we WR in the tests you should use three mindsets to cover all possible severe bugs and the first month mindset is a hacker mindset and we will discuss it in detail later the second mindset is a formal verification mindset or it also

can be named as the inent mindset and the last mindset is a system architect mindset uh so applying all these three mindsets should help you write very thoughtful tests uh in our company we promote an approach for writing tests which as follows uh not writing test for audit uh the audit is a process of generating questions regarding the code and answering them this approach is much easier to explain to new security researchers and web three developers with this approach it's much easier for you

to control the progress of of your audit uh and extremely help helpful with the code bases which are well written and like huge code bases around 8,000 lines of code so I think that's it uh that's why it's easier to explain this framework as a set of questions for each mindset uh and uh like the answers for this question should help you write uh good tests that will help you identify bugs so to use this framework you should select one of the mindset one after another uh get the questions from this mindset ask them yourself and uh like

the answers will help you generate the test scenarios that will help identify bugs so the first mindset that I want to discuss is a well-known hacker mindset and the like general idea of this mindset is to force yourself to think about your code not as a developer who developed all the use cases for users but as a malicious user who is trying to uh find a way to interact with your protocol to break it so instead of asking how is supposed to work you should ask yourself how is not supposed to work and that's it uh well no uh the questions for this mindset are follows what uh use cases

exist EX for the protocol that should not be accessible to regular users and this question should be uh asked for all the public and external functions that you have in the protocol to identify which of them should be called only by some uh special roles or special services and uh like write test that checks that this function can be called only by a verified Ro uh for example here we can come up with a with a test that checks that the function can be called only by a offchain service that should update some

parameters the second question is what limitations are there on the sequence and frequency of function calls by users and this question should help you identify all the re-entrance attacks and uh it should help you to restrict the user flows which with which users can interact with your protocol so you have to restrict all possible use cases that you designed before and all other question should be like restricted for all users and it should like uh cause revert so here an example of a test for example you have a function that should be called only once per an hour and if

it's called like more frequently then you have have to restrict This and like it can be done by Ed air chire and uh proper test should be written for that the third question is what constraints should be placed on user input parameters uh and this question is about restricting your protocol even more so the general idea actually of of a hacker mindset is to restrict your protocol as much as possible and this third question is about restricting input parameters and here we could think about a function that accepts unsigned in 256 and converts it inside the function to

unsign in 1 to8 and if you not restrict the maximum value of input parameter then your protocol will be probably hacked and the last question is which parameters cannot be controlled by users when calling the protocol and this question is about identifying which parameter shouldn't be controlled by users and should be controlled by some white list or by some constants that only admin or privileged role can update so uh the next mindset is a formal verification mindset and this mindset cannot be merged with the hacker mindset because here you should ask yourself about not how your protocal

shouldn't work but you should think about how your protocal should work according according to the specification and for these purposes you have to write specification it's like a very hard task nobody likes to do it but you have to and uh the spe the specification will help you a lot with this mindset because you will know like what to expect what to expect from your protocol and you need to write test that checks that it works according to the specification uh and so yeah it's like I identifying invariance from the specification and implementing special tests like fing tests or going through formal verification to check that your

protocol Works according to it and here are some examples of the invariance the first one in a function that calculates the number of tokens to be output during a swap it must be guaranteed that the number of tokens output cannot exceed the contract balance this invariant is uh like very helpful for new version of unisoft V when like only one contract contains all the tokens but there are a lot of contracts that could interact with this contract and if they somehow trying to transfer more than uh they can then most probably the protocol will not uh work

as expected and the second invariant is the variable that stores the total amount of tokens that the protocol control is less than or equal to the balance of that token for the contract address this invariant is uh really good for landing protocols or just regular vaults that um accept some deposits from users and store them in special variable and you should check that this variable is uh like the value of this variable is equal to the actual token balance for this contract the last mindset that I want to discuss is a system architect mindset

and this mindset is about thinking about all the protocol Integrations in a very paranoid way so like all the external integration could fail at some point uh like an oracle service can stop updating the price because it reached some threshold value and this happened with Luna I think when the price goes like really uh fast uh a offchain service could uh have a bug in a new update which uh leads it to misinterpret milliseconds as seconds which can affect your protocol external

defi protocol can update its logic and uh distributes uh more rewards uh to your product protocol and this reverse should be claimed with a special function that you didn't add because you didn't know that you should uh and the cross Chain Bridge uh can just fail to transfer your uh message to another chain because you failed to set correct gas amount or there was an internal error in the bridge so the here it's only one main question that you should ask yourself it's which of the protal

independencies are external and could fail and it's very easy to answer this question you should just go uh through all the Integrations that you have and mark them and after that you should think about like in which way it could fail your protocol like what can happen with this integration and uh I think it's crucial to prepare mocks for all of Chain Services that will communicate with the contract to check cases of how the protocol will react on a failure in the offchain service and another question here is which of the integrated Protocols are upgradable and here you should just think about upgradability feature of the integrated protocols and

if you integrate with such protocol it's better to make your contract upgradeable also so in conclusion I want to emphasize that test preparation is a very important thing and like developing a web3 protocol without uh thoughtful test preparation is dangerous 100% test coverage uh is uh not like very good uh recommendation but it's should be done you should have at least from 80 to 90% test coverage and you should cover all unit uh and integration tests so you should be

ensure that your protocol works as you expected and after that you should apply this framework that we discussed today to ensure that all severe bugs are covered with the test so while you're using this framework it's also can be beneficial for you to prepare a checklist of the test scenarios uh so when you will be developing developing a new version of your protocol you could use this checklist to prepare test that you prepared for the first version and also all mindsets are crucial and it's important to cover your code with all the

mindsets and uh like you can skip the system architect mindset if you do not have any external integration but uh I cannot like remember any protocol that I audited in a year or two that didn't have any external Integrations and uh yeah write tests stay safe uh thanks for your attention uh I would be happy to answer your [Applause] questions yeah we have some time I think hello

okay thanks uh thank for a talk uh usually when trying to find um interaction like um sequences of interaction that lead the system in a broken State um like writing a state machine diagram works pretty well do you have any tips or any automated tools to the that kind of stuff could you repeat the first part of the question it was um so it's the idea of like drawing a state diagram um to try to lead the system in a broken state do you have any tips or automated tools to do that kind of stuff I don't know regarding the automation tools here like most of them are not very good right

now uh but yeah like writing a state machine for your protocol it's very nice thing to determine like in which stes it could be and just like restrict the states that you want uh your protocol to be so yeah it's it's a very nice thing to do more questions uh I have a question about the different kind of uh uh test which part should be covered of the

business logic my point is um you have mentioned about unit test integr test even those kind of formal verification test uh I I say that a kind of test so according to uh our own business for example Landing protocol which part of the specific uh test should uh cover which kind of you know different uh TP as the method or kind of patterns do you have ideas ideas or recommendations to for uh the the protocol Builders how to

decide and how to uh consider that that is um we can satisfy all the the Logics we can cover you mean like uh for which functions each mind should be applied or yeah yeah uh you you are talking about the coverage mhm the the you I I consider that's what that was a a unit test coverage all the code of the the uh Branch uh just like basic testing to ensure that your protocol just works yes how about formal verification what uh what kind of integration uh test or formal verification should cover about the

business or the the basic code base so unit test and integration test like like General test coverage it should help you to be sure that your protocol just works and all the mindset that I discussed it helps you to ensure that you have additional layer of security on top of just like basic use cases so you have to write basic tests and after that you have to switch to the mindsets and cover like with a hacker mindset cover with a formal verification mindset and with a system architect mindset and how about uh fuzy testing fuzzing fuzing it's like actually it's about the same

with the formal verification but there is a small difference that formal verification gives you 100% sure that the invariant holds for all the states of the protocol and fing tests only some specific cases so formal verification is better but if you don't have like time or budget for this you can use fing test okay thank you [Applause] okay yeah so the next session will be uh

about pool pool Oracles in defi like is the security of them it will be by ZX monso from open saping so welcome TX monso [Applause] can

you yeah not working I want to use this oh

awesome all right good morning um I'm xerx Monsoon um I'm a security researcher at open Zeppelin I'm also a member of seal 911 and um today I'll talk about polar oracles um how to integrate them what are they and some security considerations uh when you're building or architecting your protocol and some tips this could also be useful for Auditors but this is uh mostly meant for developers all right let's start so blockchains are very good uh when you

only have to deal with intrinsic data so they're basically a computer a database without any internet connection uh so you cannot access exter interal data there's no post methods or get methods in blockchains so the problem is if you're building apps uh for normal users you'll have to get data from outside uh there's tons of data available um natively in blockchains but that would mostly be balances of users token prices using um uh amm but uh if you have to imagine build a stock market

mirroring platform you'll have to get you'll have to need you'll have to use an oracle to get those stock prices from outside if you're building a lending Market let's say you'll have to get asset prices um if you're if you're building a prediction Market you'll have to use an oracle to actually get the data transmitted to the blockchain uh that how that um what the outcome of that event was to settle the to close the prediction market so so that's the that's the problem we're dealing with getting data to the blockchain because that uh makes it more useful for everyday

users so there have been multiple ways people have been trying to get um external data to the blockchain um it all started um with push oracles then slowly uh different other types of oracles Al also came into the picture like Onin oracles and most recently pull oracles so uh let's first start about push oracles and how they work so a push Oracle is very simple uh what happens is whenever a user needs to interact with an app uh they just send a transaction to the app

Smart contract and that in turn reads data from the Oracle smart contract the responsibility of updating the Oracle smart contract uh is with the with whatever Oracle Network you're using so let's say Chronicle or chain link they'll continuously um update the prices or whatever other data you're using uh in their Oracle smart contract and you can directly just call this so push oracles are basically the oldest uh uh they started it started with Chronicle that was the first push oricle

then chaining came into the picture and tons of other other ones and they are responsible for the most tval uh secured they are the easiest to integrate with because all you need to do is call a certain smart contract with their interface a specific function of a certain smart contract and you can get the data [Music] and um sorry yes so basically this makes it very easy to integrate like all you need to do is just call a certain smart contract and but the problem with push oracles is it's very expensive

to operate because someone needs to Bear the transaction cost of continuously updating the push oracles push oracles actually work on um either price deviation thresholds or time thresholds so the data on the Oracle smart contract will be let's say updated every 1 hour or something or if it let's say de the price deviates by 5% or something so uh the Oracle Network constantly needs to send transactions to the smart contract for every data feed that they have on every Network so it makes it very hard uh and very expensive for them to um

support a lot of different data feeds on a lot of different chains so um let's let's come to what are pull oracles so what happens when you use a pull Oracle is the user the end user themselves are responsible for transmitting the data or Price whatever you want to use onto the blockchain itself so uh what happens is imagine I'm a user and I want to interact with a with the app with a Dap so I'll first get the price from the or networks

Network or server I'll retrieve the price from there I'll bundle it with my transaction and I'll send it to my app Smart contract whatever app I'm uh I'm going to use and that app uh will verify the data the whatever the price load is the price uh the payload is uh using the Oracle Network smart contract or it verifies it internally there are two different modes we'll talk about it so the benefits of using a pull Oracle is um it can support a a higher number of chains and um and pairs because uh the Oracle

network isn't responsible for transmitting the data so it doesn't have to bear the cost the cost uh rest with the user so pull Oracle are classified can be classified in two ways by either execution patterns or by the payload validation method so sometimes some types of pull oracles have Atomic execution so you deliver the price in the same transaction uh where the transaction is supposed to be executed so let's say I want to borrow um from a lending protocol so I'll give the price of all the Assets in

the same transaction and I'll also borrow in the same transaction so the execution happens automically then there's also another pattern that's uh in which the execution is deferred so what happens is um I'll intend to the DB smart contract that I want to make such a certain transaction let's say I want to open a position on a certain market so I'll uh I'll send a transaction indicating so the uh the app will record uh that I want to make this transaction and it will emit an event with all the data fields then anyone can

act as a resolver and send a transaction in the next block with the price what this helps with is it prevents front running so this is uh popularly used by GMX so that uh the transactions that users send to GMX aren't front run then we can also classify pull oracles by the payload validation method sometime in some types of P oracles uh when you send a update payload they are externally validated by an external smart contract which is usually the Oracle Network smart contract so if I send an update uh payload to a Dap the DAP will in turn

call the Oracle Network smart contract and that will validate the payload uh there's another way uh in which you can internally validate uh the payload some some po oracles support this in which you basically integrate a library uh um you do this by inheriting their smart contracts and their uh the smart the library smart contracts basically validate all the signatures that you have sent and if a certain threshold is met uh the price is validated for you so this basically gives us like four types of polar aricles so like pith is an example of a polar Oracle that's

externally validated by the Oracle Network itself but supports Atomic execution um the chain link data stream used by GMX is an example of externally validated uh polar Oracle in which uh the execution is deferred so the price is uh transmitted to the blockchain in another transaction and not in the same one then you have internally validated um polar orles so Redstone is a prime example so the Redstone pull Oracle supports Atomic uh execution and the Redstone x uh works just like chain link

data stream and it supports deferred execution the only difference is uh you have to inherit the smart contracts of redstone to do the validation inside your dap itself so this is uh pseudo code basically to integrate pit so as you could see in this uh example method uh there are some inputs by the the user let's say the user address and amount but you'll also notice another argument which is an array of bytes call data price update so basically this is an array of all of all the price feeds

you want to update so uh updating price feeds on pit can uh require sending them the native token of whatever blockchain you're on so basically in the first line you to get whatever the update fees is and then you call the pit uh the uh smart contract of the pit Network and call the update price feeds method send them a value and then um in the arguments you send them the price update AR you do this because um pit actually caches uh the price for some amount of time probably it's three

or five minutes so you can actually call The Pit smart contract just like a how you'd call a push Oracle smart contract but uh if the price is stale the call Will revert so it's always better to just update the price and then read it uh by calling there are multiple functions to get price um the recommended one is to get the get price no older than function pass in the price feed it which is a byes 32 argument and then the number of seconds right uh so this is how you would also use chain link data stream the only difference would be uh first you'll uh actually get your transaction

stored in their smart contract in the dab smart contract that will emit an event and people will anyone can uh observe that event and resolve it by calling another function in your smart contract and delivering the price and then your smart contract will verify it uh with chain link this is how you integrate the Redstone Oracle uh basically you import uh their contract and then just use a function they have called get oricle numer numeric value from transaction message and uh you pass in the data feed ID so to use Redstone their uh price

update payload is appended at the end of the call data so You' see uh uh there's no bytes aror here it's appended at the end and it automatically fetches us using assembly all right so things to keep in mind so uh when you're using pull oracles they are updated very frequently like sometimes multiple times a second so uh one problem could be that the timestamp of the price update can be from the future so it could be greater than the blog. timestamp so if you're making making an assumption that the price update timestamp will always be

less than equal to blog. timestamp this may not hold and may cause problems and uh this can also be Pro problematic if you're uh mixing blog out timestamp and the Oracle update timestamp in the accounting and business logic of your contract um if you're using any Oracle where you have to internally validate the data make sure you are um doing sufficient validation on the on the price update payload because if you're uh because if you're not validating that people can use past prices so always validate that the price delivered to

your smart contract the time stamp is always higher than whatever was delivered before because um we've seen this in audits before where um protocols have implemented this uh um in a very buggy way also um if you're using uh any Oracle uh which internally validates the payload uh make sure that uh in the same block you do not revert if anyone sends a payload with a older price time stamp

because that could uh result in a Doss for that user so in the same block always remember do not revert if uh an older time stamp comes just return at that point and do not change the price another problem with pull oracles is there can be multiple prices in the same transaction because all I need to do is provide the smart contract with a Tim stamp that's greater than the last updated timestamp so if uh my dap or the Oracle networks smart contract was last updated yesterday I could use all the prices since yesterday to today and then I can

use them in the same transaction and I could use them in a malicious way and even if the small in the difference between the prices is small it can be Amplified by using flash loans remember this all is happening in one transaction so you have the luxury to use Flash loans so if you're making um Perpetual or future protocols or syns and you allow Atomic minting and burning of sins uh attackers can use this to drain M part of uh part of your funds plus um if you plan on making an immutable

protocol using internally validated pool oracles can be problematic because they use public keys of um of signers of uh to see if whether the price the payload has a sufficient certain threshold of signers or not so if the private keys of those signers get gets compromised there's no way for the Oracle Network to actually update it without you having to upgrade your smart contracts uh in case of externally validated P oracles uh this can be done but uh internally validated P orles this

is not possible if your protocol is immutable you'll have to upgrade it plus if if you plan on using multiple types of oracles um in your protocol let's say a push Oracle uh different types of pull oracles you'll notice you cannot use the same uh function signature for all of them because different types of polar oracles would require different uh encoding methods a push Oracle does not require you to send prices along with it so you'll actually have to abstract away the price EXT extraction mechanism into a separate um price Oracle or asset Oracle contract and you'll have to have a a

contract for each asset you want to obtain the price for so what will happen is you'll have to make multiple calls imagine if I want to borrow something I'll first have to call that asset orical contract update the price then I'll have to call the borrow um function in the main contract so this could cause compatibility with EAS because EAS cannot make multiple calls by default so to allow the EAS to make multiple calls you'll have to use a multi call and you'll have to uh add some authentication functionality to it so uh you could you call the multi the

EA can call the multicol uh update the price and then call the borrow function um of the main uh main protocol and the protocol can rest assured that the user was authenticated by the multicol so it can be trusted because the message. sender for the protocol would be the multicol address and this is how um Oiler does it um using the ethereum Vault connector which is basically multi call with authentication in it so uh can older protocols um that were made before pull oracles and were made to you function with push

oracles uh can they be integrated with po orles um let's say compound V3 and actually the answer is yes because compound has some special functions that allows um anyone to operate on behalf of a user so it has Supply from transfer from transfer asset from and withdraw from fun functions and the liquidate function does not require the end user to to be the message. sender so a multic call can actually do everything on the behalf on the behalf of a user on the behalf of a eoa and can also update price

so so that's it mostly from it from me uh if you want to uh learn more about oracles uh and different types of oracles you can look into to OE oracles basically oev is a subset of me but it uh revolves around the extractable value whenever an oracle is updated so like oval and API 3 you could read into that you can read into ZK oracles and hybrid oracles too which is basically a hybrid of push plus pull used by by synthetics so that's it from me any questions

[Applause] yes please thanks um sorry in your example about P Oracle uh which is atomic uh I was just curious to like know how it's possible like to call the update function then have the of chain Oracle updating the price and getting the price if it's what I've understood uh I'm sorry can you repeat that um like how is it possible for nchain um service like uh the price Oracle Pi for example to update the price automically if it's how it's

working that is possible and but that would actually make it a push Oracle if there's a service that um updates the price at a certain interval like thanks yes please all right than yeah so the next talk will be from Li of folks will be about CK oracles and well how they are introducing now into

into production of Lio so yeah pretty interesting one so welcome Victor [Music] and [Applause] yeah e guess

okay awesome way all right folks hello um today we'll talk about the enhancing the protocol security with zero knowledge oracles and um my name is Victor I'm a Lia protocol contributor and my co-speaker today Eugen he will tell you about the technical details about the ZK Oracle in the second part but before that let me set the stage for that and explain the problem and uh set the solution framework um in the beginning just a few words about the ligher in case you don't really know about

sorry that's yeah um so it's a middleware connecting the users with is to the node operators it's more than 9 million e at the liquid staking this protocol there are some important properties of lier like the erc20 fible token we have also um um in lier there's also a permissionless withdrawals uh so everything that's St could be uh withdrawn if it's needed and also there's a uh um flexible Stak in rotor which

allows to set different um validator subsets and the most important thing it's uh Dow voting because every change to the protocol actually have go through the um the voting and um so the problem statement uh for the protocol it's needed to have some external data to count the um the value of the St token and uh to distribute the rewards across the um stakers and the essence of the problem is this external reported data

should be minimized the trust to this data should be minimized or it's better completely removed and um to explain you the implementation for that I need to talk about two main things it's a li out counting Oracle committee and oracles reports on Checker the first thing it's a committee so the stiff rebase happens uh every day with the Oracle report Oracle brings the values like a consensus layer validators balance withdraw W balance some other data and it's recalculate the value of the token um it's kind of protected uh with a committee of nine independent oracles

and only if there's five identical reports received from five different Oracles this data can come through but not really yet because there is a scien Checker in between because um there are some checks to basically tie hands uh for this system if there is a kind of abnormal or abrupt balance change coming let prevent some possible attack vectors however in the previous implementation of the sanity Checker there is a problem that's the negative rebase parameters was too limited it was about like setting x% negative fre base per day that is not

really enough so the solution is described in uh Lia Improvement proposal number 23 um and it consists of two main parts the first is the strict Cent checker so basically we decreased the limit of 5% of the consensus levators uh to 3.4 over an 18 days window it's a major Improvement because it's limiting the possible negative3 bases but the most interesting part that's the pluggable second opinion Oracle and based on the Su slaps ZK Oracle implementation uh based on the sp1 DVM

it provides this trustless verification um POS this data it's calculated uh data from the external and provides the zero knowledge proof for that data as well and uh this kind of guarantee are the better results because we can consult the second opinion before we can do the rebase so basically now I'm passing the mic to Eugen to explain you the technical details about the Z Oracle thanks Victor um hey folks um I guess the last thing between you and lunch so I'll try to not take too much of your time um so yeah let's Dive Right In so just a quick update of uh how the

problem translates to the technical part U basically like ethereum have two layers as you all know and they're pretty much isolated right so there's like only like a few windows from execution layer to consensus layer and in the opposite direction and that actually brings a challenge because all of the data that's needed for the Oracle report uh needs to be existing in execution layer but all of the data is on a consensus layer and normal solution is you know as as Victor mentioned there's a light Oracle and a committee that brings that data from from the uh consensus layer to execution layer and it's a full Oracle and everything is fine except you know it still requires

building and when you build an oracle there's still some challenges right because majority based majority V based oracles still have this uh like attack vectors one is a simply Brute Force you can still overtake five entities and then put whatever report your you would like uh the second one could be like slightly more subtle called the supply chain attack because practically your Oracle is still an executable code it has dependencies and if some of the dependencies is compromised U your Oracle could be compromised as well so if you remember that famous thing about left pad uh on mpm if the guy just didn't just R quit and deleted it but

put some malicious code into it pretty much like entire internet would be infected and obviously there's still uh implementation risks right everyone's like all of so far all developers are humans and humans make mistakes and if one of the mistakes is slip in that would open an additional attack Vector for compromising an Oracle and here's where zero knowledge Proof come um technically all of that data is publicly available so like completely onchain solution is possible the only problem is that you would need to like put entire beon state which is the like the data structure that captures everything on a on a uh

consensus layer you would need to put it on execution layer and last time I checked it was something like 230 megabytes uh SSD serialized and it's probably would be even even bigger ebii included and like run hashing like uh sha 256 hashing over like to produce Merkle roots for all of the validators that alone would take something like 3 million uh hashes so basically like over over over sorry overall this is not feasible because it will exceed any reasonable gas limits and ZK actually helps with that because kind like straightforward use of

ZK Solutions is to kind like conceal some knowledge and produce a proof that you have it like the oppos the thing is that this knowledge does not have to be private it could be like publicly available it's just you don't want to push all that data to the verifier to do the thing so instead we can just push the report itself plus a proof that the report was computed honestly and consistently and and that reduces the amount of data and amount of computation that we need to do on execution layer a few orders of magnitude if not like millions of times um okay so charting course on the on the technical approach so as I

mentioned producing report uh starts with like actual like correct algorithm right in order to produce a report you fix how this uh raw data that we have on a beacon State converts into a report and this is actually like an exerpt of of the actual code we have most of the complexity is hidden behind um how's this behind this prepare input thing but other than that it's just basically this uh and correctness and honestly requirements for producing the report is guaranteed by the uh ZK infrastructure itself uh and we'll touch about uh on

this uh slight later the second part of the equation is actually having the correct data pushed into the uh both proof and and uh verifier contract on chain the the tricky part here is that the this kind like Integrity guarantee is not like cannot be provided by the Z Solutions alone and um sorry yeah and practically when we're like pushing final report and approv to the execution layer we need to like compare something in the report with something on a block blockchain that we can use to like uh like confidently uh check that the

report was computed correctly and we'll touch on what that something is is uh in a few slides and finally if we have like correct algorithm and correct data like that that guarantees that the ex like actual execution report actual report would be correct yeah and the tricky part is that like when we're talking about this like in ZK uh circuit or ZK program 95% of the time actually spent on like proving all the data that we can actually ladder up to something on a block chain that we can verify against uh literally like the algorithm for Lio report is like for all validators if validator withrawal

withrawal credentials is not Lio skip it if it's Lio add the balance uh increase the counter that's it this is your report so practically like 15 lines at most but proving the data is kind of like oh we'll get into it so uh here's the thing we need to prove a lot of data about validators their balances um activation exit Appo etc etc uh but on the execution layer we the only thing we have is the beacon block hash and this is actually was added not sure in Capella or denb but pretty recently so there was like EIP 4788 that brought this pre-compiled contract that keeps

track of the beon block hashes on the execution layer and and down it goes so the next layer is that like beacon block hash is produced from parent root State root and body root and a few other fields that are like in a beacon block header and then State root is a Merkel tree root of the beacon State data structure that has like something like uh 30ish Fields uh basically like this is like entire Beacon State uh beacon beacon uh consensus layer State and the most important for us is validators Route this one is kind of tricky because uh we'll touch about on on this in the

later slid this but it's kind like a Merkle tree of a variable list that actually have two to the power of 40 elements only like 1.6 million elements are actually used but there is a trick that makes it important and then for validators Route like that route is computed basically from a Merle es of every validator and Merk hash of every validator is actually produced from mer like merizing all of the fields of that validator and that that's how how it comes to be and then there's also balances route because like we're practically reporting on a uh consensus layer balance for all of the validators and for balances is slightly different

because they are packed uh in ssz Spec uh their like balances are 8 bytes and and they're packed uh four items together into like packed balance and then this forms a leaves of the Merle root uh of the Merle tree and if you look at it this whole thing looks like this and if you don't don't know who this guy is he's a baron M Housen a fiction book character like main character in the fiction book and he was telling like cool stories like once he was traveling and got into a swamp and he pulled himself out of the swamp by his hair including himself and a horse and so and so forth and in fiction book you can do pretty much anything uh in

reality we're Bound by some laws of physics and Mathematics and it wouldn't be possible but there's a like a hook that we can use later uh that allow us to perform tricks like this uh just to touch on the technology side of things so this whole thing is built on the sein labs uh sp1 sp1 stands for sixin processor um and like this is the from their initial announcement half a year ago in in April or something obviously the benchmarking uh values might have changed since then but like the part that talks about like developer productivity I can literally like I can definitely get behind this uh 100% 100 times maybe even even bigger because the

the best part of it is that it allows writing ZK circuits in Rust and it's like a plain rust everything is supported even like third party Lang uh packages with some tricks that uh with some Cavs that I'll talk about later and thing that I love the most about it is that both uh Oracle like offchain code and uh ZK circuit can actually share code that allows for like a lot faster iteration you don't have to fire your uh ZK Z KVM uh ulator every time to test everything you can actually do a lot of unit testing a lot of integ testing um and that that speeds up the development a

lot yeah and one thing worthy of mentioning is that there's like a bunch of like performant pre- compiles for pretty much well at least main uh crypto Primitives like sha kak etc etc that actually makes it run a lot faster even on on zvm itself cool so initial solution I put a little bit of code on my slides uh I think it should be readable but you know uh if anything I'll still talk through it so this is basically entire code of the Oracle except like it you know hides some complexity in the library codes so basically what Li what Oracle is doing is that it reads the consensus

data and it orchestrates creating a proof and submitting it to uh sp1 prover Network where sp1 prover if you're on locally and finally just submits the report and uh and proof to the contract on chain uh this is also like the almost like a full listing of ZK program I just remove the parts that are not not really interesting so again it's written in Rust uh and compiled into elf I forgot how it's de abbreviated executable linkable file or something uh for a risk v32 virtual machine and like running this elf on on a virtual machine

produces the I air algebraic intermediate representation air Trace that is later compact like compressed into a into a proof and this part like provides part of the correctness guarantee right so this like encodes the algorithm and not 100% sure how it happens but practically the actually like the code in in your solution is part of the verification key that will be later used for ver in everything and even if like single bite change you get a new verification key and you've got to redeploy your contracts or update or like do some stuff and that's kind like part of the protection from malicious attackers that only the like ver like

bless verified uh algorithm can actually produce proofs that uh we'll be passing on on the when we do verification um yeah and as I've said major advantage is that almost any rust code can be used and and I guess we'll touch on it in a few slides so final kind like uh piece in the grand architecture is the contract itself that accepts reports and verifies them so the like the most important part of what it is doing is kind like anchoring the data uh that we're sending to a block uh to a blockchain state so most of the thing in as I've mentioned most of the operations

that the ZK is providing is like taking beacon block hat and proving that okay we had actual uh State root from like this given slot on on a blockchain then okay we have state root let's prove that we had like validator hashes we have validator hashes let's prove that we had all of the validators and like all of the data is correct below that and but finally this kind like this this whole tree like anchors on the beacon block hash and that provide us the kind like the the hook that we need to pull out cells out of the swamp you and second part is that it just verifies the proof um so contract

literally just send it to a onchain verifier that can uh verify the proof rerun those mathematical AR Trace uh algebraic intermediate representation rerun it and confirm that yes yes have all the constraints match uh all the data that was passed in it matches what we expect to see everything's fine and this kind provides the second part of the correctness guarantee and and kind like cements the the solution altogether and finally just stores the report nothing fancy just you know record it into a mapping and make it available for uh later consumption by the protocol uh a couple of challenges and I

think we're running up of time so I'll run really quickly one of the thing was that like Risk v32 is a 32-bit machine and n like if you remember number of validators in the beacon state is actually 2 to the 40th and 2 to the 40 actually like if you if you try to convert it into unsigned in 32 it will overflow and one of the crates uh I used to to build the tree hashing this is actually tree hash not sure if it's from Lighthouse from Sigma prime or one of the derived ones uh by the way kudos to uh Sigma Prime for Outsource open sourcing all that stuff uh it will just

basically overflow at some point and everything will crash so to kind of overcome this I had to do a conditional execution conditional compilation so this is like for your normally uh x64 uh machine and then this is like equivalent implementation on risk v32 that doesn't hit that problem there's a little bit of uh trade off that work like artificially limiting the number of of uh validators to two to the power of 29 but that kind like will sustain us for like 40 years from now taking into account the current uh validator account growth so should be fine more or less and the second second part was that like

like naively generating the proof was extremely expensive in terms of like risky cycles and that that impacts the cost of the proof and that impacts the time that takes to generate the proof overall it was kind like uh something like it would took one hour for 10,000 validators and was kind like scaling linearly so for like 20,000 validators would be two hours and like for 1.6 million validators would be like a couple of weeks and that's obviously not practical so what we had to do is to kind like uh do some caching uh and there was like kind like two options one option was to leverage the recru uh proofs that sp1 provides and K store them somewhere and if nothing has

changed in that part of the part of the tree of of the recursive proof just reuse them without regenerating the second approach that we took is actually storing uh this light validator State structure uh on like on chain through Merkle route as well and like only recomputing something that's change that is basically this validator Delta cool Final slide uh at this point we are we have deployed to sepolia we've run very extensive uh user acceptance test um verify that it works correctly for happy cases uh verify that it rejects the the proofs

for a lot of like data tempering attempts and anything I could uh think of putting my hacker mindset um things left to before we can launch isbc to complete the lap 23 compatibility there's like a couple of things that we had to uh push back a little and perform out it and basically like put it for a dow voting uh on Lio and future enhancements there's like multiple things we can support with like multiple withrawal credentials we can support like we should support pectra at some point and all the future updates uh precise validator match there's like a few horis that we're employing and you know coast and performance optimizations and yeah I guess we're

done here thank you all for coming we can take questions if you have sure all right thank you folks thank you [Applause] all Hello thank you everyone for for coming speakers and attendees so this is the first session of uh DSS Day 2 I want to inform you that lunch is um up and going in rooms three and four and also make sure to check room two we have a

co-working space for people who want to work and the workshop stays at room two after 1: p.m. we're going to continue the schedule uh at the main stage hereone okay e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e good hey everybody Welcome to session four I'm Jack Sanford CEO and co-founder of

Sherlock we have a very exciting session coming up for session four first we're going to talk about the state of defi security then we're going to go into some of the opsc issues which is very relevant because we've seen a ton of opsc hacks in the past couple of months way more than smart contract hacks then we're going to talk about how to build secure D5 protocol is going to have a great panel Builders up here and then I'm going to close talking about the state of the audit contest area of security um so please give it up for Peter krinsky who's doing our first talk he's been at coinbase on the security side for about six years and he writes

probably the best security newsletter in the entire web three industry um blockchain threat intelligence so if you haven't subscribed to it do so now and I'll take it away Peter soad crab welcome to the state of def5 security DSS 2024 Edition so in case we haven't met my name is Peter krinski and as you just heard I'm the editor of the blockchain thread intelligence newsletter for the past five years how many subscribers do I have here in the room by the way awesome okay I appreciate every single one of you thank you so as is now a tradition we meet once a year where we talk about

the latest trends in def5 security and most importantly identify what are the key issues you really need to focus so that when we meet next year you can push this security needle a little bit further and make the ecosystem safer the way we're going to do things this year is we'll jump into the threat landscape right away um something different is that will talk about who's responsible for all those attacks and finally what is it that we can do to what is the course that we can chart to make things safer so let's talk about the defi thread landscape so the last tab we met was middle of 2023 so a few things changed since then by the end of the year the one thing that really started jumping out is the stolen private key theft that went from I think it was like

number four number five to number two now with over 5 $131 million stolen by the end of the year um the other interesting things that popped out last year were the kind of like Black Swan events we had just one-off attack vectors having outsized impact on the ecosystem so we had the Viper compiler bug and the uh the third web dependency issues where a bunch of different projects got compromised but the issue is the same that said the last time we talked about this chart here is I ask you to focus on two things when you do code when you develop brand new smart contracts I really wanted to you to focus on price Oracle and reward manipulation so let's see how you did

for this year so this is up toate top 10 list right up to November so this is as recent as it gets you may want to take a picture um so let's start with the good news the price Oracle manipulation if you saw the previous Slide the losses were around $200 million this year we're only seeing 50 so you 4X reduced the number of losses to the ecosystem at the same time the number the instances of that attack Vector also about half so that's great what about the reward manipulation same story there we've seen almost 10x reduction in the number of

times protocols were hacked using this attack methods and about the same number of instances so what's behind those numbers though is very interesting is because the majority of loss comes from just a couple of really large hacks the reality is that most of the hacks are to really small tvl value projects around 100K each meaning that most likely they're small enough that they didn't even go through the full audit um so as Security Professionals we rarely get a thank you to say hey like you did a good job preventing all those hacks so this is my thank you to you whatever you are doing right now as code Auditors whatever you are doing as defi developers you're doing something right

you you really took down those top two issues that were prevalent in the past year caused almost $400 million in losses and you really cut it down now the bad news that Trend that we saw in the previous year with the stolen private keys well that's back and that accounts for the majority of losses in this year so far 4 almost $450 million stolen the other issue that we're seeing is the malicious Insider attack Vector that that thing did not even pop up on our top 10 list it was not even registering and yet this year we're seeing $95 million stolen across 17 incidents here's the key though between private key compromises and malicious insiders those are not smart contract

issues you're not going to catch those with smart contract audits because those are all operational security issues we got so busy focusing on Smart contract bugs that we're kind of neglecting the rest of the security pile so how bad is the problem so this Pi basically outlines the likelihood of your whenever your project does get compromised what is the likelihood of it being compromised by whatever attack vector and you see this like big red slab that's your stolen private Keys that's uh what is it it's around 64% and then malicious insiders now s and a half so in case of a compromise the likelihood that you will get hacked because of the operational security

issue is around 72 % and what stands behind them on the stolen private key side we have highly targeted fishing campaigns we have sophisticated malware that is replacing your transactions because before you signed it on your Hardware wallet OD days getting dropped at developers on the malicious Insider side we're seeing just single points of failure a single person making a few bad decisions can wreck your whole protocol so we've been doing well so far I I think we really moved the needle and security on those smart contract hacks I think we need to evolve and really step up our our security game and the way we're going to do this is first understand who are our adversaries what are there at ttps so tactics techniques and procedures and

based on that we can start building a strategy of how to defend against them the key here is we need to step out out of our smart contract comfort zone looking at solidity code all day is is good please don't stop don't stop doing this but we need to on top of that add a few more things like infrastructure security uh hiring practices governance and so on and so on okay so let's before we move on let's cover a really big elephant in the room that we rarely talk about you know we are introducing uh operational security issues today and we get we usually talk about smart contract security what about the users more than $461 million were stolen from our users not through scams

or rug Bulls no those were technical fishing attacks those are the drainers that you keep hearing about $461 million I think we can't ignore this anymore we really need to put a dent into that number soon because I don't want to end up in the world where we have a bunch of defi projects which are Super safe but users are just pissed off and don't want to use defi anymore so they all your Super Save defi projects are just sitting and no one uses them that said let's go back to thread actors so let's start our journey understand who are the bad guys doing and stealing hundreds of millions of dollars from us every single year uh when I talk about thread actors I roughly divide them into four categories

so those are the crypto natives criminal APS AP stands for advanced persistent threat those are basically kind of cluster together a group of people who are just persistently using the same techniques and targeting in the same way in the same similar targets nation state APS and we'll talk about one nation in particular and of course malicious insiders that's a new category so Crypt natives crypto natives are basically one of us anyone of us in this audience right here you know someone who is participating in the same talks Capture the Flag competitions audits but at one point or another they crossed the line um one example is uh Shakib Ahmed so he's a security engineer at Amazon so a security professional

found a few bugs price Oracle and reward manipulation in a couple of projects on salana so Nirvana and kemma and decided to exploit them unfortunately well fortunately crypto natives are not criminal so just one of us we made a few bad choices so often times they get caught very quickly because they're not very good at laundering money they're you know Googling things like defi hacks prosecution things like that so unfortunately this this person made a mistake got arrested now facing 5 years in prison so when we think about crypto natives we have to think like what motivates them they're financially and ego motivated you remember kyber swap you know like there's a lot of ego in there and pride like I want to be the

smartest person in the room so you have to kind of keep that in mind when negotiating for example they specialize in smart contract hacks and usually get caught due to opsec or when trying to launder funds and this year so far we can attribute around roughly like $300 million in theft of across 319 uh incidents new category malicious Ider right and this is someone that you trust this this is not really a hack it's someone that you you let in through your front Gates and you give them all the access that they need but we don't really know what's going on inside every one of us right so one example of that is Jared Reginal Dunn stack um who

basically had you know he was a smart contract developer he had full access to Smart contract uh private Keys got pissed off by the company so it was the uh pump. fun and decided to drain the wallet and revealed who he was pretty like immediately on Twitter hospitalized there were mental issues involved and you know like this is something that we have to keep in mind when we think of malicious insiders we think like oh there's this evil person that we hired and there were out there to get me from right away you know we're all people we all make mistakes and honestly we're we can mess up very quickly by just making a few bad decisions here and there so the key here is that you need to build your system accounting for that you you can't have a single person who had just

a single bad day wreck your entire thing you have you have to have resilience to your protocols so when we think about uh malicious Insider tactics they're usually financially sometimes just maliciously they're pissed off at you that's what motivates them they don't need to hack smart contracts or do any tricky things usually they have all the access that they need to your smart contracts to your infrastructure to your social media to do the things that they do usually easy to identify it's a usually the person who stops replying to their text messages and and slack and just like uh crypto natives they have limited resources and laundering capabilities so they get caught pretty quickly things are about to get darker let's talk about criminal

APS um so these are hardened criminals they don't necessarily specialize in crypto but if they see an opportunity to steal crypto from us they will they have traditional security or criminal security background like they used to stealing credit cards and identity and data and ransomware and all that crazy stuff they operate on N criminal networks where you have dedicated teams reserved for initial infiltration then stealing data then laundering funds and monetizing so they there's a very tight Network that operates around the world uh so one group you should be should be on your radar is it's known as the Comm uh also known as the scattered spider or octopus or ank 3944 the reason for all

those weird names is that every security company likes to use their own ways to name things just as a ownership almost so you always have this like alphabet or word salad of names associated with each thread actor uh so this one uh a couple of folks were caught so uh they're all in their late teens early 20s uh B based in Western countries so one was based in us and another one was based in UK their primary techniques are Sim swapping atos social engineering and these are the folks responsible for hacks like lbass uh they took over lbass they were able to exfiltrate that and then they realized ha like a bunch of people are storing pneumonic keys in their comets

which are unencrypted let's drain them so that was $50 million or Fortress 16 million doll hack and the way that it started was with retool compromise they got to retool they started scanning what they have access to they say oh people are dumping API keys by accident let's use that um MailChimp took over chimp looks like a lot a bunch of crypto companies are using that let's send out fishing emails notice a lot of these attack are opportunistic they're not like targeting the protocol I want to hack this one target I'm going to steal money from it like no they hack whatever they can get their hands on and then they see how much value they can exfiltrate from that so the key from here is uh things are about to get darker now so we uh

everyone that we talked about so far are kids compared to the level of sophistication organization and danger to defi ecosystem this takes it to a completely new level uh nation state APS and one nation state uh AP in particular that we'll cover this is who you should stay awake at night thinking about are they looking into your protocol Lazarus AP Lazarus AP is a North Korean threat actor operating under the reconnaissance General Bureau RGB almost RS with KGB similar to kind of like a mix of CIA and FBI smos together and they have very simple task obtain hard to obtain foreign currency

Financial assets for the North Korean regime which is is a sanctioned country so it's very hard for them to trade and operate so they found this wonderful cryptocurrency industry as a ready source of income uh when we talk about Lazarus AP we often you know we think it's like oh it's just like one single group uh according to one report that was published in 2020 there around 1,700 members operating Under the Umbrella of Lazarus AP that was four years ago based on how successful they are I would triple a quadruple that number so just imagine like you have a a team of a few thousand people each with like separate

subgroups uh specializing in initial penetration exfiltration laundering funds U highly organized or uh group that is targeting your protocol very very hard adversary to deal with so this chart that you see here this is something that was shared by Paulo Alto team unit 42 and they roughly organize it into six groups here some the some are specializing in more like industrial Espionage and data theft the ones that we're going to cover are the ones that are targeting us they are the ones that are stealing funds from our defi protocols from our centralized exchanges and so on so the first group we're going to cover is ap38 blorf how many of you heard of that subgroup of

Lazarus okay wonderful um their primary tactics are spear fishing they impersonate you know VCS they they lead you on through social engineering and then they you know they hop you on a video call and some reason the video website is not working you have to download this video package you download the video package and now you're compromised um they the latest thing that they're doing they're they're dropping old days left and right the the one old day that dropped recently was targeting a defi game so they compromised a lot of users and just this morning I was reading yet another old day campaign that they're running so they are a highly sophisticated actor with custom malware capable of developing zero day vulnerabilities to Target you and their background is

fascinating way before a cryptocurrency industry even existed they were hacking all sorts of large like I started my career as malware reverser looking at the Sony Pictures malware and that was a very sophisticated piece of malware with all sorts of confiscation techniques later on they targeted Bangladesh Bank where they almost got away with a billion dollars that's a central bank that they hacked in a country um W to cry ransomware campaign yeah these guys are highly sophisticated and guess what they moved on to you now they're very interested in the cryptocurrency industry uh so the status there are a few uh actors that were identified so uh these are pictures from the FBI Most

Wanted chances are that we ever going to catch them non-existent I mean this is a nation state with nukes that we're talking about so if you are compromised or you're targeted by this entity there's not much that you can do the other group we really need to uh discuss is Trader uh Trader Trader AKA Jade SLE and there a bunch of other names that they uh that the security industry is identifying these are the big boys these are the ones that you really need to worry about if you're not worried already now get scared so the Wier 23 million hack Ronin 600 million Harmony I mean the theft is measured in hundreds of millions of dollars highly sophisticated highly organized if you ever watch how they laund their funds

they are machines they will go for days moving money from bridge to bridge to chain to chain with very little breaks because they operate as a very large team as I mentioned they a few thousand people operating uh under this umbrella these are the same folks that were running Apple juice malare campaigns where they were sending fake trading apps to infect machines these are the folks that are sending you sending your devs uh fake job offers like hey like we have a interesting interview for you download this npm with a few dependencies see what happens let's see if you got the skills you download the npm and then you're hacked um the latest one are North Korean IT workers and that really comes from a

separate group it's not necessarily sitting under the same umbrella as the rest of them those are IT workers that have legitimate jobs you know you may have seen documentaries how they're North Korean uh restaurant workers they generate currency for the regime um there are also 4,000 IT workers out there somewhere uh posing as Western programmers IT workers and so on making like 100 150 G's of pop so you can imagine like this this group even without stealing anything is already generating like half a billion at the very least for the regime that said sometimes they go Rogue sometimes they steal stuff so Cosmos they developed all of the um uh liquid staking for Cosmos munchables and tapio a few weeks ago sometimes they just take the keys that

they have and they run so nation state APS financially motivated intelligence motivated sometimes they can get destructive as we've seen with Sony Pictures well-funded and resourced spear fishing social engineering laundering tactics uh that's what they operate with so far these are the folks responsible for three and a half billion dollars lost to our industry um we talked about you know the OPC uh chart like how much of it how much of uh how much of the opsc total loss is Lazarus responsible how much can we attribute well about a third and that's I think that's a very conservative estimate like we didn't attribute every single hack due to operational security issues to Lazarus my guess is closer to 50% but you can you have to dig a little

further okay so the bad news if a sophisticated a team like nation state AP will Target you you will get hacked no matter how many defenses you put in you can do all your code audits you can train your staff if they are out to get you they will get you so you're not going to like the solution the solution is to be just a little bit harder to attack than the other guy and the way that we do this is we start building a more comprehensive Security Programs so we can't think just about smart contract security anymore we have to think about a whole lot of stuff we have to stop talking about application security as we had just an incident with uh 1 inch we

have to talk about cloud and infrastructure security how many of you have proper logging and minimized access to all your Cloud infra Key Management operational security can you wake every all of your devs and key signers at the right time at 2: am in the morning at Defcon to make sure that you can quickly move the funds while you're getting hacked Personnel security endpoint security and and I added social media security because I'm just tired of seeing Twitter and Discord and all those other getting compromised every week my grade for the industry today is green for smart contract security not because we solved it as an industry but because we know what to do we know what the code audits are we know we have a variety of code audit offerings out there but there's very little

information other than what was recently introduced by medy a few a few hours ago we have the seal framework that starts to address the rest of them so we need to start adopting those recommendations at the industry start thinking about things which are not cool you're not looking at solidity code anymore you're looking at boring Cloud infra but that is what we have to do four things that I would love for you to do today that will have an outsized impact on your on your security program for the love of God please have multi- sakes with time locks there's no reason why you need to upgrade a contract instantaneously just give it a few days sleep over a weekend let make sure that someone looks at your whatever code that you're

about to execute the Cod data and sees if it's actually doing what it's supposed to be doing have Guardians that can override that set up onchain monitoring practice incident response I don't care how many alerts you get if no one is looking at them it doesn't matter hire carefully protect your personnel teach them about spear fishing look at the latest attack Trends the last one please buy devs really crappy slow machines that are dedicated for administrative and designing functions the reason why they should be slow and crappy so they don't feel like they should use it for anything other than what it's designed to do so no email checking no social media no downloading repos from you know from the interviews

and so on okay so I think just to be on a positive note I think defi security ecosystem got a lot safer we graduated to the next level so this is a good thing but we also are now facing much more serious villains so now it's also time to upgrade how we defend ourselves through mature and complete Security Programs the journey continues and see you all next year not sure if we have any questions maybe one question Yeah couple questions yes sir

maybe you have a mic yeah so It's Tricky so you can't you're not controlling Twitter for example it's like highly centralized entity so you need to make sure that you establish security contacts and you have some kind of practiced Playbook that you can use if something happens every minute that you shave off especially for social media you're saving your users a few million dollars So the faster you

can react um you should probably engage uh brand management companies that have those like Insider connections with all these companies that something that honestly as a as a defi protocol you shouldn't be worried about so think of it as like a necessary expense just sign up to those brand protection things and they will fast forward your request to take it down yes all um I definitely strongly agree with like the operational security and uh how you feel about it but the the ask that you have for the industry um do you have any for that side of it because I think they were they were all smart contract related your 8020 slide says that ask

are deploy multi with time locks set up on train monitoring uh protect personal from beer fishing and have laptops for signing but what about the operational security side that you were talking about so those four there's a lot more the security program like I showed you like it takes a lot and even the graph that I showed you is like a subdivision of like a fully mature security program those four things are based on the most recent hacks so I could tell you like the radiant Capital like I wish there was a you know time lock or something like that I'm just watching like the most painful ways that protocols get compromised and those are the most the the smallest things that you can do they'll have the outsized impact on your security stance but yes like I wish we could invest into full monitoring and

threat modeling and all of the like understanding like every single way that someone can get attacked those are just that's just the beginning uh cool I think maybe one more question oh yes sir but but the beginning yeah as you said it's like if you're harder to hack than the next person you won't be the victim but the industry is still going to cop it right that's maybe that's something I'm taking away from traditional security where we just try our best I just remember like I mentioned Sony Pictures right and you know I remember there was

a discussion at that time like wow if a nation state attacks you what's our response you're not going to respond to yourself you can't hack back you don't have any legal background is your government going to respond on your have no as we've seen so if you don't have any counteraction you're not legally allowed to counter hack what's what's your recourse is just try to be better so it's uh it sucks as I said like the solution you're not going to like the solution but it's uh it's the one that we have cool all right everybody please give a hand to Peter thank you very much Peter as Peter said most of the fund lost loses this year are due to obsc

issues so for the next talk we're going to bring up Pablo sabatella to go deeper into how to do better opsec for your team and and deeper into the opsec area hey guys how are you

um well today we're going to talk a bit about uh operational security and how I I I say that professionals hack people and not systems right well for the ones that don't know me I'm Pito I do operational security uh research and trainings uh I'm a s911 contributor I also founded OBC doio where we do these Audits and trainings on operational security and I have the blockchain security series podcast perhaps you heard about it so um as Bruce sneer says professional hack systems uh amateur hack systems sorry professionals hack

people and as Kevin mnik said uh soier engineering can bypass all Technologies including firewalls right so as today ER Peter was was showing uh most of the funds stolen in in crypto nearly 80% are not due to smart contracts we have gotten far better in smart contract security but due to operational security issues right so today I'm going to share with you five stories or perhaps six depending on the time we have and some things I learned from them right so the first one this is something that is perhaps known by by most of you but has a small twist there have been

lots of scams regarding uh scammers in 18 recruiters BCS and journalists right so this is an example of one I got contacting me saying hey we want to invest in your company er very fast I realized this person was an scam was an scammer how because the I mean I follow three 3,500 security researchers and no one was following me in this account so if that happens for sure they are scammers but I said hey let's continue this to to to have a bit of fun we go to a telegram Channel they said that they were from Eden blog BC that's a real BC and one of the guys told me hey for you to check

that I am real and this is not an scam go to the website go to our website and check there you will have my profile you will have my Twitter and you will see that I have just followed you so I go to the the BC website and I see the the account link I go to the account and they see that this person has just started following me right so I said hey what's Happening Here we continue h talking a bit H I got tired of this but um basically what had happened is that this guy Yan D the real founder from Eden blog had changed his TW his Twitter username and when you change your Twitter username your old username becomes available for anyone to register

it right so scammers had seen that they had taken the username and they started impersonating him what do they do after this we all know it you have one call two calls three calls and after they have gained trust with you saying that they are going to invest money if they're ABC or they are going to offer you a job if they are recruiters or they're going to give you some uh something in fors or some media saying that they are journalist they uh you are in the fifth or fourth call they tell you that your video doesn't work please download this platform or this platform you download that as most of us use MacBooks and we have that very stupid idea of with MacBooks and Mac OS there

are no virus no malware we download anything we install it we are done right um so what do we have to know from this uh today it's full of C the exploits for you all know C the exploits are exploits that are not uh that exploit vulnerabilities that are not public and we also have lots of zero day Zero click exploits right exploits that can be sent to you you don't have to do any click anything and your computers are totally compromised one that is very used in this cases apart from sending you perhaps uh some platform to download which has an ins infected is using PDFs that are infected so it's very very

important if you use a cow reader to have it always updated to the last version this is very common just by opening a PDF you are totally compromised and as some people don't believe me when I when I say this H you have many companies that buy this kind of of exploits for example if you developed a zero click Z day exploit for Android you get paid two M two and and a half million dollars right so there's a very big market for this this exploits used to be bought by three letters agencies but now can be bought in the dark web for a bit of less money so they are been used by by thre actors so we have to be very very careful with this and here we have for example a price

proposal from inexa that is a company that sells this kind of exploits where you can see that you can H compromise any Android or iPhone device up to date with the last uh uh update you can compromise 10 devices for uh $10 million so $1 million per device so it depends on what you're what you're protecting how much you should spend in your security one thing that is very important to to think about this is there are lot they are targeting a lot of devs right and even security researchers and something that is happening is that when a Dev is compromised and he gets hacked then they don't go and tell their bosses hey I was

compromised yesterday because I was doing a series of interviews to go to another company so it's very important to have a very transparent culture with our employees and our teams so that if this ever happens to someone that person discloses very fast and we as a company can do what we have to do knowing that this person has uh been compromised right and the other thing to know is that 90% of these cases are not published right so we are just seeing a tip of the iceberg in Twitter or whatever when we see someone telling about this these cases so the second case is uh about social engineering right a bit more more

advanced in my opinion what happened here we had fund manager and an invest a supposedly investor right that was an scammer this investor contacted the fund manager and told him that he wanted to do a 3 million uh OTC operation he didn't want to use any decks any smart contract anything for the for the operation but he proposed to to use an escrow right and he proposed to Peter to use JN as an escrow someone that was very known in the ecosystem so he said hey I trust John and Peter was friends from John so he said hey we can use JN as an escro right so John uh joins the Discord and they say okay we're going to

do this operation we're going to we're going to send you the to um Theon investor is going to send the stable coins to John and Peter is going to send the other tokens and then John is going to send them the other way what happened here uh the supposed investor proposed to uh continue the conversation in telegram right not in Discord for security purposes and here comes the magic what did he do instead of creating one telegram Channel with uh the three of them he created two telegram two telegram chats in one he was impersonating Peter and in the other one he was impersonating John right so what does he do next they start talking and he starts copying the conversations and

the chats from from one to the other and from that one to this one so John knows how Peter writes and Peter knows how John writes but when he sees the messages he sees the exact same thing that Peter is saying in the chat right so there's no doubt about nothing they weren't thinking that they were going to be compromised or something so what does it happen they keep talking and talking and in a moment H John informs his address for the transfer and that's the only thing that the scammer changes here right John informs a fake address so what happens next Peter would have transferred and they would have lost everything right but what happened here luckily or not so luckily they had

thought about this for this kind of operations they have a second Channel where they confirm everything right that in this case it was WhatsApp so they talked in WhatsApp saying hey this is the address where I should send you the funds right and he said no no this is not the address what's happening and there they realized about this this scam but when I saw this really I said I could have fallen victim victim of this it's it's getting far more sophisticated every day so third case domain hijacks this is happening a lot a lot uh some weeks ago Athena Labs had their Twitter compromised uh we all saw this they had configured a register with domain.com

and domain.com did not even have the possibility to have 2 FAA for authentication right it was just username and password but in this case what happened the support was soier engineered right and our case either F they also had their their account hacked how was it done through social engineering the the support so uh how are they uh Soldier engineering the supports with fake IDs we are going to see a bit about that and also with Sim swapping right this is very very common we talked about this 1,000 times but it keeps on happening a lot and regarding this I did a bit of

research right I said okay the I think that the operational Security in in crypto is one of the worst operational securi standards that we have worldwide like we're the worst industry I think uh but I said okay let's check security companies right so I have a database of 350 security companies and products from the ecosystem that's us and they checked for examples where we have registered our domains right so 25% use god daddy right as Go Daddy domains can be hijacked in three days right and I say that because we we tried that and we could do it with a client obviously right then 20% name chip the same 7%

square space approximately 70% of domains of security companies security companies can be hijacked in less than a week right and it it must not be done by someone that is super sophisticated no it can be done by any any kid as Peter was saying in his H being a teenager so what kind of register should be using for this H Cloud flare uh AWS Mark monitor for example and something that is also very important is for this kind of of accounts for example for registers it's important important to use cold email accounts right a cold email

account is an account that you have really secure that is not public and you don't use for anything else and you don't have logged in your computer during your daily use and also using UV keys for TFA right not uh TFA with applications now we're going to talk a little bit more about that fourth case Twitter fishion or why we should stop using uh TFA with uh applications like oi or Microsoft Microsoft authenticator what happened here this is the from some weeks ago you receive an email at 3:00 a.m. saying that there was a login in your Divi in your Twitter account from North Korea or rush or

whatever this is obviously efficient but if you look at it from your phone it's very easy to to fall for it because it goes directly to the inbox it's not detected by uh by Gmail H fishing detection system you get to this website for this example I changed the username in the URL for my Twitter account so it it asks you for your password if you put the first time you put your password it says that it's incorrect but I don't know why they do this next time you put it uh it asks you for your tofa right and when you put your TFA here in real time it's being proxied to Twitter so your account is gone even if you use UFA with app or if

you are using UV keys with the OTP mode the traditional UV Keys use that can be fished and your account is totally gone so in this example I I put a code you are logged in here and here you have some options and you can click on some things but in this moment your account is gone and as we know if you don't have a contact inside Twitter there's no way to to recover your account it's very very difficult so some things for this we have said this like 500 times but in c911 we keep on seeing like lots of accounts being hijacked because of using uh SMS for um for

TFA uh so please remove your phone number from everywhere everywhere and if you are in some platform where you have to use uh your mobile phone because it's mandatory as UFA don't use your public number your public phone number you have to think that any day you're going to go wake up and it has been seam swapped right so you shouldn't put it anywhere you should use a call the virtual phone number right from Skype Google F or AO and keep it private don't let anyone know that that's your your phone number also as I was saying if we use normal TFA from applications or from the U Keys the traditional top from U keys that can be fished right because we

touch UV key the UV key sends a code and that code is proxied to the real website through the fishing website and our account is gone so when we use h u Keys we should configure something called fed2 or u2f and when you do that H every time that you use your UV key with a website it validates that the website you sending the the signature to is the real website right so this cannot be fished um if you have your U key and you download the U U authenticator there you will be able to disable the OTP uh function that is the unsecure one and

use fedo 2 or fedo uh u2f and also one more thing that I added here uh one password added the possibility of uh saving TFA in one password I think it's it's the most stupid thing they did as a product it's like it's not a feature it's definitely a bag so we it's obvious that we should not save to a phase in the same place that we that we save our passwords right so Story number five H Twitter account takeovers uh even if you have your Twitter account configured in the best best way it's very easy for that account to be H taken over what how here's an

example this was by Athena some some like one week ago an attacker attempt to take over their account and they did it H with social engineering right what did they do they contacted ER Twitter Twitter support saying that they wanted to buy ads more ads uh there with that first call they got information about their account manager then they targeted the account manager right using information from that first uh contact saying that H they wanted to ER change the the account access and for that they used uh forg uh IDs right H and forg company documents luckily as Athena had

a premium X account if you're protocol you should have a premium X account they are I think like $2,000 yearly they contacted them and they said hey is this account change real and there they could validate it was not real so the the change was not done but if they hadn't had the the premium account the they would have their account uh totally hacked uh so basically what they do what they did there they lock down the account and they were secure so important things regarding this this is a very long testt but because you will have this presentation then uh it's important to have H verification

protocols with your account managers right from X and if you have this premium support uh for your account you will have many more features that will allow to have your your account far more securely Implement ER multiactor authentication and change it like three every three or six months and conduct routine H security audits right and the other thing to know about this is that there are also lots of Twitter accounts takeovers due to insiders right you can do the best thing that you can but for really important accounts there have been many that have been take taken over with uh insiders people working at Twitter changing the email from the

account disabling to fa or whatever so in your in your plans you should know if you a big protocol that any day that account could be hacked so you must or you must know uh before that happens what you will do that day right exactly who will Who you will contact uh Etc so how do they do this kind of stuff for uh social engineering for example with IDs there are platforms where for 20 or $15 you can create a fake ID from any country like this is so far as a service it has a very very good support and you can example say Okay I want an ID from Argentina this type of ID with this name this year this this is

and that and the photograph that you that you want and you can create any ID from any country and these IDs H they can go for 90% of the kycs that are out there and they go with no no issue H this is very very dangerous because basically they can impersonate uh any of us and well the last one that I wanted to show you is er also about soci engineering and malware right this happened some weeks ago uh uh to two persons dard and one more guy he was basically contacted by someone saying that was from parafi Capital that they wanted to do some collaboration

whatever he wanted to verify that it was a real account so he checked his followers and he was saying that uh the other Founders from Pari Capital were following this account so he said this is real but what happened here all those accounts that were verified were all scammers also right I mean having the very having the verified uh blue check in Twitter it doesn't mean anything in fact the only people who who get some profit from paying this are scammers right so it's very logical to to pay for this if you're a scammer so the next thing is that they invited him to a telegram Channel they offered some things and they said hey ER come to this slack Channel where we can can continue

talking and we can introduce you to our clients when he went to to this uh slack Channel he got a server error right and as we can see here uh the real um invites for Slack are like join. slack.com and this this was app. slack.com but what happened after this he had that uh error and they told him hey uh yes this happened last week to someone and we found the the way to fix it here and they sent him a link from Reddit and this link had lots of abouts lots of comments this this and that and it explained in detail how this should

be fixed so he went to in part of of this it said that you had to go to this website to update some driver he went to this website checked for updates downloaded the driver and obviously it was malware gone um so about this it's it's very common for security researchers or people in crypto to not use antivirus not use firewalls not use anything because we say no we are we are sophisticated we won't click any link we won't download anything I do not believe that uh I don't know if you know Objective C but Objective C is a foundation that develops many products many security products for Macos one of

them is called Taxas task Explorer this will check all the tasks that are running your computer uh with virus total and if you have something infected it will detect it then you have Lulu that is a firewall so basically if you are ever infected when the malware tries to steal information from your computer this will this will stop it and then you have knock knock and block block that basically what they do is they allow you to detect H malware that has been installed uh persistently right these tools are very very good H I recommend to have them all and I also recommend

this is something that most of the security researchers don't agree with but I think that we should all use antivirus like some people say oh no but you use aspery is is Russian or you use malware bites and you you must give too many permissions to this to this antivirus and they could have complete control of my computer I never knew anything or that's my experience that had an issue because of installing antivirus but I knew thousands of people that had issues because of not installing them right um this I will show it a bit fast but something also very important is that there are lots of targeted fishing very targeted fishing for example this one in E Denver was H ether F even Bri

account was hacked and 1 hour before the event they sent a message to everyone going to the event saying that you had to mean your nft pass and the link and the amount of people that got direct there was terrible then the same thing happened to Tresor when they hacked their their uh newsletter system and they sent an email from Tresor that was validated from their servers and everything but it was fake and they are also doing this ER when they mix databases for example from The Ledger League coin market cap or other crypto uh newsletter or system s and they er then use that to to Target us so the important thing to know about this is

that the attack can and will come from a trusted Source right it's not that it will come from an email that seems to come from treaser but it will come from an email that is really really stressful so we have to be very very difficult H very careful with this uh well lastly some things uh that I recommend also for for conference es there are many people that have been robbed or hacked during conferences right so some things that I recommend first of all this is not for conferences but for physical security storing seed phrases in paper is something that is always difficult because you store it in some place and

you don't know hey could someone have gone there and seen it if you use these anti-tampering bags they are very very cheap you can put your seed phas there and if anyone ever wants to see that they will have to break basically so this is a very simple and in my opinion secure way to store them then hotel rooms uh I think it's very important uh more if you are like if you're the founder of a big defi protocol or you are a signer for an important multic or a security Council or whatever physical attacks could happen so whenever I leave my hotel room I use this free app called Alfred camera you can turn any old phone into a

security camera you leave it there and if someone goes into your room you will get a notification and it will be recorded in the moment very very easy to do and the last one is faray bags basically H I always bring this to conferences uh you can put your computer your your phone or any electronic device inside here and there's no chance that it will be hacked during that that moment so to finish some things that I really I'm really convinced of but most people H do not agree with me eventually we will all we are all going to fall for a fishing we are going to click a fishing link eventually like people say

no no I'm sophisticated I don't click anything whatever we will eventually we will click on ficient link so that's why it's important to have for example a 2fa with a UI eventually we are all going to be social engineered too right and and eventually we are all going to download some malware in some moment we are going to do it so that's why I think it's important to have tools like antivirus or task manager or a firewall to to stop that and the last thing as Peter was saying ER threat actors are closer than we think right I am convinced that some of them are even sitting in this uh conference room right now so we should be very very careful with the

information we share and with the with the things we do in every place more importantly and more specifically in crypto conferences so that's it many thanks all right thank you so much Pablo time for one or two questions anyone has any do you have your phone in the Faraday bag right now sorry do you have your phone in your Faraday bag right now like do you always carry it around with you yeah I have it there in my I'm impressed it's a small it doesn't

it's sorry mine's a trolling question too I've got this really big airdrop that I got to get right now and all of these different you know protocols and procedures that you put in front of me are preventing me from getting in my airdrop how yeah it I'm telling tell I'm like making up an example use case right of when I might want to be able to initiate a transaction immediately on chain right but all of these different you know processes that you're putting in place is slowing that down right why why because why are these tools preventing you from getting the a drop I didn't get that because I want to do it quickly I want to get it rapidly let's say that there's a specific like nft drop that I have to get before you know it all sells out right happens all the

time in your examples that you've kind of shown us right now it there are a lot of sort of steps that I need to take to make sure that I'm secure how do we get to a world where I can get whatever my mint is as fast as possible while also remaining secure I mean most of okay most of this stuff can be done before like if you invest good time in in in having a secure environment and having a good upset from that on from that moment on you will be able to operate in a more secure way but even ER even when you have that I think that trying to do things fast is the best way to to to be hacked to be so engineered

and to lose money because they it usually they they leverage from that that right like this are J is right now and you try to do things right now I I prefer to do things a bit more slower but to keep my Capital basically and the and the are things for for air drops and all that is to try to to to compartmentalized right to have many different wallets different browser different users as a minimum two computers and with that you you also make it more difficult to be to be hacked but anyways I think that you can do things pretty fast but paying attention if you try to do it fast and you're

tired and it's late and you're doing it from your cell phone in the car perhaps you're going to be wrecked okay okay thank you everyone please give a big hand for Pablo follow him follow him on Twitter pablo. eth check out his company opsac with a K and next up we're going to hear from some of the biggest D5 protocols in the world about how they've approached security while building and scaling their def5 protocols [Applause] we have Hari from spearit moderating the

panel Ernesto from a Sarah Reynolds from uniswap Eric from Oiler and Merlin from Moro hello can you hear me is that all all good okay perfect hello so let's get started right away um so defi as a concept was invented about six years ago and since then it's quite mature today and I wanted to bring some of the largest D5 protocols out here and ask about their challenges in building scaling and securing their protocols so today I have two protocols that are you know con synonymous to the concept of

defi a and unisab and then I have two more who are you know younger hungrier and like ambitious protocols uh Moro and Oiler I wanted to learn about their challenges in building the protocol and uh what we can all learn from it so let me start with uh um anesto um I genuinely think he has one of the hardest jobs in crypto maintaining the a protocol but we will get to that in moment uh but before that you know I would like to I would like uh for you to tell everyone in the in the audience you know what you do at a and what is your background yeah so yeah uh I'm to as har say like I'm the co-founder of of a

company called BD labs and we are one of the contributors to a like do core development maintainance and so on of the a protocol and well I mean my my story goes from back in the days like of the six years that that har mentioned because yeah I was part of ab back then in 2018 when AB I think it was not called even AB and and yeah basically what I do is is everything related with tech onab so that includes majorly like what surrounds the the smart contracts which can be upgrades of the protocol like Des sign of certain new features but also

basically everything around like so more related with this conference like um coordinating the security so thinking uh what new tools to apply what new procedures to apply and and so on and so forth so yeah to summarize I I do a bit of everything related with the other protocol okay great so moving on to Merlin um you ended up building one of the hottest projects of this year which is uh Moro uh tell us your story and how you ended up building Moro right um so I think if I remember I I met Paul during if Global aaton uh I think it was like during the the confinement and um he had this uh

later on he reached to me and um he wanted to BU like a new protocol um a security a researcher at the time had the first idea of Optimizer uh M Optimizer which was basically like building and uh on top of existing Landing pools and try try to improve rates for both suppliers and borers so uh Paul wanted to work on that idea and uh so he reached out to me at this moment I was uh building and trying some stuff in the def space I was uh playing with the credit delegation on a uh it was really fun and I wanted to create a project in in that space so he called me and I was like okay let's go uh starts Aline so um and so we created the the

first version like after maybe one year after during our um our studies and uh so we launched I think first Moro compound which was optimizing rates on on top of compound and uh after we uh we we launch on on top of a and so that that started and I think like during bur Market uh we reached like two billions of deposited asset on on optimizers okay great moving on to Eric he has an interesting background coming from V to security and he joined Oiler after the unfortunate hack you know tell us your story and how you started working at Oiler uh um I guess like uh so I'm the head of cyber security at Oiler Labs um

I I was in the web 3 gaming industry working as the head of cyber security there they were kind of the market wasn't doing well so they were doing layoffs and I came up with the opportunity to go work at defi which I was super excited because I love trading investing and uh I thought it was a great opportunity and uh yeah so I started working at Oiler um actually found a bug my on my interview they were doing um oh I don't know if I can talk about it but uh they were um not validating some input and I quickly found that I could just like spam it and uh I got the job

um and uh yeah so I managed the organizational security I do a lot of the stuff that paito e was talking about like uh ensuring that we're running antivirus and all the good stuff that he mentioned uh and I organized all the security audits the pen testing um and yeah it's been a great experience working there okay moving on to Sarah I think you have been quite involved lately on pushing transient storage to you know everyone's uh you know I know I know you were pushing it in the solidity compiler and convincing other people to use it as well tell us your background and the work you do at Unis web yes hi I'm Sarah I'm one of the senior protocol

engineers at Unis swap um most recently I've been working on V4 and even before V4 like Hari said I was working on really trying to Rally the community around transient storage I think it unlocked a lot for um developers like myself um yeah before un swap I was in college so great that's my story so maybe starting with uh you know you as well so what is something that you believe the unisoft team does that um nobody else is doing out there and something that you believe is like truly unique and I would ask the same question to everyone but

replacing unisoft with you know you're on team so tell us something that you do that's unique to your team and you think everyone else should be doing that's a hard one off the bat um I think that we it's hard to pick out as specific unique thing that we do I can maybe share like some unique stories um but I think you know we're all in the similar boat here of kind of building protocols in the open um we have a lot of eyes on our protocols all the time so I think there's a lot of I think similarities we share um one I guess unique story um as we were going through the audit process um there were moments where a lot of the

engineers on the team you know you know we had fixes for some of these things but they weren't great we didn't feel really good about them and you know in that case what do you do I think we were going to have to like settle with um kind of a fix and one thing that's really cool I think that all of us shares we we're building these things in the open we can have conversations in the open and we really leveraged that so I think we this was at eth Prague maybe I'm forgetting which conference but one of a Community member basically proposed a solution to one of our critical um issues and that's actually the current solution in the code today

and so I think like really leaning into kind of building in the open and um leveraging like sort of diverse expertise in a lot of different areas is something that I our team does and has worked well for us yeah I think that's a great story like I see there's tons PRS in the unisa repo all the time from random developers some of them gets in some of them doesn't but it's always good to have uh that kind of community getting engaged into building a protocol what about you Eric what is something that Oiler uniquely does I think um I mean we do many things but I think we start like internal reviews I think uh that's pretty unique

I don't bet you guys also do it so I don't know uh we start with internal reviews we start like uh even before we finalized the code we start like early we started like a VC so review even the code was unfinished but we started getting feedback uh on like the architecture the security design um something I think that is very unique is that we did a live CTF which is it was very difficult um and uh high risk but we we decided to put our money in first to kind of like actually try it out and see if anybody could take it um I think that was you know yeah I mean I know the behind the scenes behind would you mind explaining to everyone what you did I think that's a

fascinating story uh yeah so like uh in order to like Kickstart Oiler um we decided that it like it would be a good idea to actually put our funds from the governance to start the first landing pools and uh we wanted to be like super safe cross all the te's like three times we already went through a a Cantina company comptition we were still confident but we wanted to be like super 100% sure so we did a live CTF uh with hats and the idea was to put uh 5 million in and if anybody could take it they could take it uh and the idea is like you know try your best to break it uh and uh it was an exciting and scary uh moment um also it was

difficult with regulations and like trying to figure out like how to make it um in a way that you know we're putting money out there and like protecting it and so we had a very diligent process like reviewing the con I mean the terms of service of how this would operate which I think it's been one of the toughest things but it was a thrill and I'm glad that like we didn't lose anything yeah I mean that's good to know I I always always find it hard when Engineers want to do stuff but the legal comes and say you can't do this it's very annoying um so so on moving on to you Marin what is something that's you know unique to Mor for right um it's a

good question so we we do internal reviews but we haven't done the the the CTF um which is like a good thing to to try maybe next time uh anyway so I I think like um one thing that is different from on M for so we we've went from building optimizers on top of a to like creating our um own Landing uh protocol and I think like uh the the way we uh uh view how to build like a safe and scalable protocols have evolved a lot during those three two three years and now I I I'd say that the approach of Moro of building protocols is um like really about like minimalism um trying

to do just one thing but do it perfectly uh trying to remove as much as possible uh the governance in the in the process in fact it's really similar to how Unis swap like is building the the protocol since the beginning like simple code um uh trying to externalize like the the thing that you don't want to see in your particle like the or orles for uh dexes for Lending protocol it can be like a stable rates or leverage features Etc all those kind of things can be externalized and in fact you just like refine and try to simplify as much as possible your protocol so that at even before starting the the writing the

lines of code you have just all maybe remove like 90% uh of the the the likelihood and the attack surface uh and I think this is like a very good approach to um make sure that you're starting like uh the right way and and uh make like all the process of like stacking security layers after uh much much easier what about you Ernesto what is something that's unique to a I mean it's one of the most battle tested protocols out there I I would say like like the the thing that probably differentiates a is that we know how to find equilibrium which is a bit abstract but what I mean is that when you are

like for quite some time like in production and very high stakes is it's pretty important to understand like how far we are with new features you go with new features versus how much you are conservative or how much pressure you receive from competitors like from the market versus how much you need to take care of let say let's say your back office of clean up and so on so I think that that is one of the of the keys of the success of a because we know pretty well like on when we should improve some something or when we feel that maybe that should not be

touched and and still keeping the Rhythm like with with everybody else in in the market there are then probably some other aspects that I think a is pretty different but that is maybe some that is not not so so told publicly so frequently that makes sense so I have a follow a question to that which is uh so people talk about this idea of defense and depth and security it's the idea that you do multiple things hoping that even if you miss somewhere it will be caught at some layer and there was a great story about how a did this um and the story was about how a discovered a bug in the llvm compiler framework so

for those who don't know llvm is a compiler framework for creating new programming languages and for some reason I we ended up finding a bug in the llvm when it had no place in like finding a bug there so I want to I want to learn about the story from ero how did you find a bug in uh how did your team find a bug in llbm how was The Bu so basically what happened is that AB as you probably know like is in multiple networks and we we keep expanding like the V3 protocol to to new networks and so this was in the context of expanding to CK sync and well the process is that contracts get deployed the Dow needs to activate them be a governance proposal so on and so

forth but what we tried to achieve always is that the Comm the code is kind of the same like or or completely the same across all the networks so this case was very strange because we there was a deployment on CKC there was an activation everything seemed to be working perfectly fine and then in the yeah first seconds or so um it was not noticed like I will elaborate on that just after like it was noticed that very core a very core mechanis of ab was not working well like the related with the collateralization which is basically the most critical aspect of of the protocol so H well it happened to be that after posing the protocol and so on that was a bug in the compilation stage of the uh

llbm which is like uh the back end library for the compiler used by the CK sync compiler so very very deep thing um so yeah like when you tell that story looks that yeah other guys are are so smart like they they found like that but I I would like to highlight this is quite different what happened like I think that the key on why the the bug was found and this is related with well this ethos of ethereum and of the community of saying yeah the centralization and so on and so forth this B was probably found because of the decentralization of ab because um it's not only one team like in practice like who is involved into the activation

process of a new Ab pool like is okay we do the deployment on BD labs we do a lot of testing and so on on the initial stage but then we have likeor which does independent reviews we have Abel apps which for example in this particular case what happened was that all the tests were fine like the formal verification let's say was not possible to completely apply but seemed fine like from the Cur side the review and then while testing like the user interface like one particular Edge case like in this case have aabs that maintains interface they notice like that edge case and then that initiated like the whole thing like of okay what is

happening here but first we we pause then we try to understand but I think that that was the strong point because there are certain types of back that you it doesn't matter how smart you are like or even how much procedures a single company can have like when you have multiple entities involved into the chain then is when when those Pro problems are detected so I think that is like like a yeah a good point of view for yeah I think that's a fascinating story for so llbm framework is used by like pretty much every big compiler like clang like or or like pretty much every programming language out there us to it um in in the VAP to space so very fascinating to see like a building

solidity ended up finding a bug in llbm and the story is you know always fascinating um so going on to Moro so so at speit we have work with Moro for a very long time we met them back when they were a very young protocol that had a simple idea let's optimize the rates uh for Lending protocols um and um since then Moro evolved quite a bit you know they went from working on top of compound and a to having an entirely different philosophy on how lending Protocols are designed so how did your team change your engineering culture uh during this you know massive shift all right um so first we so we deploy

the the optimizer on top of L uh compound and and a and in fact we realized like it we were like super deep into the the code base of those both protocols and like very at the same time like providing a landing experience for our of our users and I think we are also the user like as a prod like the closest to uh the underlying protocol a or compound so we had like those two two different views um as a both a user and uh a landing protocol and we realized that it was kind of hard to build on top of a upgradable smart

contract uh when you were so deep because like or like a contract that can be updated quite frequently because like any change to respers or um to of the code base of the logic like can impact you and like even break your um uh break your integration or like a block some features for your users Etc so we had to have like a constant monitoring of of that whenever there was like a posing some something that we we needed to jump in war rooms and make sure that everything is smooth um and it it proved to be like super challenging for us uh and also we were like um faing directly like what are the limit of like the

current design and like a current Paradigm of building Landing protocols and so at some point we we we told ourselves like hey instead instead of trying to improve like what's uh what is the the current Optimizer stack like let just build our a landing protocol like the one that we would have like to integrate and let's define like what are the the design principles and like what what really we want uh this primitive to do and that that uh that's uh how we end up like ended up like building our own lending protocol that is called muffel Blue that we've deployed like early um February this year I don't remember

exactly uh but U which is like totally immutable permissionless uh governance minimized where Market are isolated etc etc but that's U that's and how did your teams like engineering culture change you know you you went from building this upgradable contracts to fully mutable so I think like uh we we started like without bias uh so we we don't have a finance uh background like U most of the F founding team like we haven't worked for another company uh and except ourselves when um so um PA and and I like we started like on both side like trying to to launch like startups Etc um so I think we had no

bias so we were not like um we we we didn't have like any Affinity to like upgradable contract or immutable contract or a specific design and so we just like uh welcome like criticism and tried always to ask ourself like hey is there like a better way to to to do like landing and and if there there's like the answer is yes like so let's just like dive deep and try to find like hold to to make it better instead of like trying to uh to stick to like uh one one way of thinking that makes sense um moving on to Eric so the history of the oiler

protocol is a bit of a roller coaster there were a truly Innovative protocol uh that that innovator in landing back when everyone was trying to launch an A or a compound fork and Oiler was like one of the few protocols that truly innovated in what they were building and they they had a great team they put a lot of work into security but they had a very unfortunate incident um you know the oiler hack and the roller coaster was and they managed to get all the money back in fact I think at some point the money was even bigger than um what was lost so tell us the story about uh the oiler hack and you know some of the recovery and how you came into the team and moving on from that like you

ended up building a version two of the oiler protocol which I think is one of the most hardened protocols in crypto today considering all the work they put into security you know including the $5 million onchain CDF where anyone can try to hack and keep the money if they do it so tell us a story of how the oiler went from going through the hack to recovering it to building one of the hard most hardend protocols out there yeah um I mean I wasn't part of the company uh so I mean what I can say is that uh like it was probably very devastating to my teammates um it was difficult it was definitely roller

coaster uh I think if you really want to learn more about it I recommend reading the very well detailed called war in peace it's a block post by Michael really detail about like his experience it also has personal like side to it like I mean I think his he just has a newborn and all this things happen happening and the negotiation and everything that went part of it um but luckily yeah we were able to recover all the funds and try to make right with everybody um after that um I guess like the team decided that they wanted to continue um and uh they went into building initially we just wanted to fix the the the bug and relaunch but then

like I guess they got inspired about how to make it better make it more flexible make get more modular um we wanted to they wanted to build like something completely new and creative and be more robust and so we went on this giant Journey that then I became part of um I think uh I never seen I mean when I joined I was like pretty impressed of like the commitment we threw like three kitchen sinks or even like 10 time kitchen sinks into security uh the other day I was doing the math we did 700 days of audits oh wow like like it's more time than I've been in the company if you add it up uh we've done like amazing work working with spearit chain security

ctor formal investigation for like six months it was great help like creating all the invariants and all the work that we yoted has also been an excellent partner um and uh it it was really cool cuz like so as things were getting finished we started audits like for example DVC got audited about like nine times then once we had the EVC which was one of like the core components then we started working in the evk then we started audits with spear bit chain security y audit then there were smaller components so we work with other companies like Amnesia then we kept on building uh then we were started working on the price for and so like all the code got like at least I think our

philosophy was not to just rely on one single auditor but like try to get as many um I into the the the the development and design and then like then we went part of like doing the code competition with Cantina which was a another roller coaster cuz we wanted to launch soon but we got like uh I guess 472 issues uh 500 plus participants and uh we went through each SEC uh report took our time commented it was really fun working with the community uh it was stressful for my team try because we put like uh a lot of time into our respes um and then uh yeah we followed

by the live CTF and now we're working on like onchain monitoring and just making sure that everything is working perfectly we have uh some cool like features like if we ever detect like a dpeg or any assd deegs we can like set Supply caps to zero so we can unwind markets and there's a lot of things we're doing after the fact for like instant response and um I'm like you know really proud of what we end up building like it's pretty amazing also the internal security that we're managing we're doing Web Two PAN test and like um I could keep going on and on but yeah it's been a roller coaster definitely Harry yeah I mean I I I thank you for being part of

it I can totally imagine I feel like Oiler we2 at this point is one of the hardened you know protocols I I can't imagine any any other prod putting in more work uh to security um that brings me to Unis swap um so you know Unis swap is pretty much synonymous to defi today and back in 2022 um there was this ethereum merge and and the whole idea of the merge was you switch out the consensus protocol live um and it you know there was like few months ago or maybe like few weeks ago there was the the rocket launch uh of the SpaceX and it came back to Earth and somebody was asking the question what is the software equivalent of a

rocket going up and launching back um intact and somebody said it's the ethereum merge and I was thinking about how every few years UNICEF has to go through something similar where they have a perfectly working protocol trillion trillions of dollars in volume and they have to suddenly switch out to an entirely new uh protocol uh expecting billions of dollars in uh tvl in like you know a couple of days so how does the unisoft team you know do this swits every few years yeah it's a really good question and I really like that analogy because I think this is similar for unisoft but other protocols as well of our development process is definitely more akin to building Hardware it's a release

and there's no upgrades after that and so I think that's also a feature it's an opt-in upgrade for users and that's how we like to frame it as well and so as we're going into the launch of V4 that's kind of our framing is you know users don't have to use V4 if there are compelling reasons too you should um and you know we definitely think that there are um but yeah it's it's definitely I think sort of the nature of building really immutable protocols and how do how do you how does a team handle all the stress of like you know you launch it and you expect in couple of days that billion dollars are

going to flow into this protocol like like what does your team do that I feel like very few teams and and crypto has to manage that level of uh Insanity yeah um I think you know listening to Oilers kind of process on like hardening I think we definitely didn't spend 700 days um but we did put in a lot of time I think back in March we had like a um a whole like fiveish month plan outlined for what all the audit processes look like um we're going to start monitoring I mean there's it's it's everything I think everybody here has done um and it

is a lot of stress but at the end of the day I think it doesn't lie on one person it's like a lot of different people contributing to this and it goes through a lot of different eyes um and so we have to have trust and our ability yeah amazing so I want to give some time to the audience to ask one or two questions so if anyone has a question to like one of the team members this is your time cheers yeah H this is for Sarah I was just wondering with V4 um like when you're building out hooks what are like some of the common uh issues you see

with people building hooks or security issues that you see from like yeah people just getting into hooks in the beginning yeah that's a great question um I haven't done any specific like audits around any particular hooks um I think what I guess off the top of my head what I would talk about is certain checks that you should be doing in hooks like a really simple easy one is like checking that the caller is the pool manager that's a really simple check like every hook should have but if you're new to writing hooks maybe you wouldn't know um another thing to think about I think is like the interaction of different hook permissions um one thing that I'll talk about later today is how I think one

principle in building hooks is limiting those permissions and that permission set so a very naive hook developer might you know okay let's you know make an upgradeable hook and enable all the permissions and we're going to change you know um you know what when the pool is calling out to my hook that's definitely a scary hook and I think for a lot of users and a lot of other routers and other integration contracts down the line is going to be something really hard to integrate with um and so lean into I guess I think all that is to say is lean into the side of building hooks where um you have predetermined kind of permissions and

flags and things that you can do in your hook and if you ever need something you know different in that hook it's really easy to do a new pool and um I imagine seeing a a a V4 where there's lots of different pools lots of different hooks but it's sort of per pool um yeah that's what I would say yeah and that makes sense and and just one followup I guess uh how do you guys envisage like uh how people will access hooks once V4 goes live like will you guys have of a directory of hooks that you think are safe or like how do you sort of see like how you'll direct people to hooks that you know should be okay to interact with yeah so I think about hooks a lot like

tokens um so we built token lists and I think that something similar could happen for hooks right now we're working with the foundation on kind of establishing um sort of a standard around like hooks interfaces and this will be really great so frontends can build out like hey here's a hooks directory of like how to learn about Hooks and how to verify it actually on Chain by like calling into a contract um that's still being worked on but I could imagine it looking something like a IH hooks metadata interface or something like that perfect thank you questions there a great panel thank you so this sort of a flip sided question right

majority of the security conference is really about about you know as security researchers preaching talking about how protocols should do better developers should do better users should do better but on the flip side what do you protocol teams think that we should do better as in the security community in general maybe the security researchers or security projects what can we do better to support you know your Dev life cycle make your uh lives less chaotic less intense yeah maybe I maybe I can comment yeah I think you know I I think that sometimes

there is too much disconnection between like the the security community and and sometimes it even feels that it's growing as as more security like experts enter into the field there is more disconnection between them and like the developers of the protocol which is I would say quite unnatural especially in this field because like we as developers like are I mean almost there is no separation between development and security especially like in protocols like can it be AB because I mean obviously you you design the things and security considerations are maybe like yeah 60% of of of the whole design like so I think that this a good exercise like for security researchers to try to

always put themselves like in the position of the developer like try to understand like because yeah maybe the documentation sometimes is not so good like in some projects but but do a lot of questions to the developers like and try to understand like the point of view of why something was done the way it was done like because yeah I mean maybe with some teams that don't have much experience like it's just by default but knowing even that is very valuable but with with teams that have pretty good experience or like strong positions is good way to learn like of okay what what is the developer thinking like why maybe there was this mistake done that created this vulnerability so

I think yeah like improving the communication probably is uh yeah something that that will give a lot of value to security researchers okay uh what is the like one thing that each of you worry about at night like what's the what's the mo the highest risk for each of you on your protocols s sor I I I didn't get sorry what keeps you up at night oh what what keeps you at night you know do do you sleep well and you know if not like what is keeping you up a nice um sorry what is just the like one highest risk for all of you that that

you worry about the most what keep us awake yeah that keeps you awake at night uh no internet disconnected yeah I mean I don't know I think that is actually something very important like because is what har said like it's a bit insanity if you think too much like on what is at stake like you will just go to a cave and don't do anything anymore like so I think it's just very important to keep yeah the equilibrium that I mentioned before but also like personal equilibri in in the sense that you need to be cool you need to understand that okay like some some problem can happen some some back can happen like but if if you know that you did things like right of what you believe is right usually I

mean should be fine like I I personally don't have any any problem to sleep at night because of that like I know that there is like high responsibility like but but I mean it's only negative if you give too too much importance right same same I think we we are out of time to okay so thanks everyone for the panel I think it was you know great answers and we all learned so much from all of you thank you thanks everybody thank you Hari thank you to our wonderful panelists very cool to hear some of the biggest and most Innovative dii protocols in the world talking about

security and how much they care about it um I guess to transition into this next talk which I'll be doing fun fact every one of the protocols have done an audit contest in the last 12 months and so we're going to be talking next about a unique type of audit which is the audit contest so give me one second to set up the computer okay uh yes thank you this one e

good cool thank you so much all right hey everyone today we're going to be talking about the current state of audit contests um like I said some of the biggest protocols in the world are using audit contests as part of their security stack to make sure their protocol is safe before going to mainnet and on the other side side there are hundreds if not thousands of security researchers who are now making a living earning extra money on the side by participating in these open audit contests and securing some of the most important code in the world while they do it just out of curiosity how many

people in this room have participated in an audit contest before wow like probably 30% of the room um so as you can see it's a very important part of crypto security if you're not familiar with audit contests and how they work they kind of fit somewhere in between traditional Audits and Bug bounties um traditional audits have two to four security researchers audit contests have usually hundreds of security researchers coming in and participating trying to find bugs and code and they get paid based on the bugs that they find so the higher severity bug they find the more

they make out of an audit contest pot everyone is competing for the same pot the more unique the bug is so if two people find it rather than 10 people that bug is going to be worth more those people are going to get paid more um and as you can see here you have similar structure to an audit where you pay the full amount upfront um and that amount is put into a contest pot mainly paid out to the security researchers who find the bugs that are most impactful to the protocol and most unique um there is a salary paid to security researchers for a traditional audit on the audit contest side of things there's no salary but there's a fixed pot of money that

everyone can access and on the bug Bounty side of things which is usually something you put live once you go to mainnet um there's no fixed amount of money at all so you only get paid if you find a bug during a bug Bounty and protocol teams only pay out only pay any kind of money if a bug gets found in a bug Bounty program um bug Bounty programs usually last as long as a protocol is live on chain so it can be months it can be years whereas audits audit contests are usually going to last a few weeks um not everything on this slide is exactly accurate in terms of audits and audit contests and we'll talk a little bit about that um further down the

presentation so how are Auto contests going how popular are they are they these days as we saw probably 30% of this room has participated in in an audit contest which is awesome and crazy there have been 625 audit contests in the history of crypto pretty much um 336,000 close to 37,000 vulnerabilities have been found and almost 15,000 higher critical vulnerabilities have been found thanks to audit contests $36 million have been paid to the participants in audit contests I know there's multiple people who have become millionaires just from participating in audit contests and

we've seen a huge influx of security researchers um upand cominging and experienced participating in them because of this crazy opportunity to make life-changing money in a lot of cases um by participating so how's it going in 2024 we're only you know 10 months into 2024 let's call it there have been 221 audit contests it's a new record uh for audit contests this year so you can see it's thriving 800 8,000 vulnerabilities rewarded in just the first 6 months of 2024 alone and 3,000 higher critical vulnerabilities rewarded in those first six

months almost $10 million were paid out in the first 6 months of 20124 alone and that's going to be even bigger as we get to see the full year a lot of audit contests haven't paid out even if they finished in October so we're waiting on the data but there's going to be probably close to $20 million in rewards paid out just this year so some recent data October 2024 that was last month we had 26 audit contests across all platforms that's in comparison to 19 a year ago and I really wish we could see the number of participants across the entire landscape of audit platforms um but we can't see that so I'm just going

to show you Sherlock's data um I'm the co-founder of Sherlock by the way if you didn't um see that earlier we have about double the amount of audit participants in audit contests last month versus October a year ago which I think is really awesome and shows that the space is growing security researchers are are getting um up to speed are arming themselves learning about new vulnerabilities and I think it's really contributed to that slide that Peter katri ginsky showed at the beginning of this session that essentially not that many bugs in smart contracts have caused losses compared to last year which I think is really great so I would call overall the

current state of aut contests very healthy things are going in the right direction all-time highs in a bunch of different areas and this year is looking great overall in terms of audit contests of course there are some things we want to be aware of and I want to flag one of those things today and talk a little bit about just the different directions that audit contests are going in and where the space might go in the future as we saw on this original slide um it's not exactly accurate what we're saying here in terms of audit contests because there are so many different types of contests and there's a few new trends that have come out in the last

couple months in terms of how audit contests are being conducted so some of those new trends are fixed pay for security researchers to participate in audits this is something that's not that new we've actually seen it for a while now where Security Experts are getting paid fixed dollar amounts to show up to contests and this is very much like an audit you know if you're doing an audit you're getting paid a fixed amount you know you're going to make money during that time you can dedicate all of your time to looking at the code which is great um another area we've seen is a variable price for protocol teams so fixed pay for security researchers looks more like an audit but a variable price for protocol teams looks more like a bug Bounty where the

protocol team doesn't actually pay out until a bug is found or a certain number of critical bugs are found variability and contest length audit contests historically have been scoped a little bit like audits where you want to give every researcher enough time to look at every single contract but we're seeing some variations in contest length where maybe there's a ton of code we I think we've seen a 100,000 lines of code and you get like a month to review it which is definitely not enough time to review 100,000 lines of code but it's more like a bug Bounty where people say look you can look at it you can find bugs that you can find and then whatever you find in a month will'll pay you out for that we've also seen no guaranteed payouts so that's the same thing as

variable cost for protocol teams but for the security researchers so you may not get paid in an audit contest unless you find a medium severity bug or you may not get paid in an audit contest unless you find a high severity bug um and we've also seen a little bit of first come first serve findings payouts where the first person who finds a bug during an audit contest gets paid more or even in some cases gets paid everything and that looks a lot like a bug Bounty so we're kind of seeing a trend where there's almost two types of audit contests that are being created now or it looks a little bit like there's two separate types of audit contests you have one which looks a lot like an audit

so they can be open or closed they have reserved security researchers there's a fixed cost for the client fixed pot for the security researchers the length is based on how long it takes to actually review the code these are all um similarities to a traditional audit or a lot of them are similarities to a traditional audit and then we have this other type of audit contest which is totally open but there's no guarantee around what security researchers going to show up there's a variable cost for the clients the client could essentially pay nothing and there's unlocking vulnerability tiers a lot like a bug Bounty where you don't get paid unless a certain severity vulnerability is found and the length of that contest is often

decided by the client less how long it takes a security researcher to review that whole code base more hey this client wants to launch in 3 weeks so the cont contest is going to be two weeks long because of this I think there's two types of audit contests now or two types of contests sorry there's an audit contest and there's bug Bounty contest and these are actually very different from each other and I think it's worth separating them out and kind of understanding what a client is trying to achieve with their audit with their contest whether it be an audit contest or a bug Bounty contest um because doing an audit is very well I'll get to it on the next slide but doing an audit is

very different than setting up a bug Bounty program and has completely different security implications for a protocol team so audit contest and Bug Bounty contest both of them are extremely valuable in terms of having arrows in your quiver you want to be able to have both you want to be able to deploy one or the other based on the situation that you're in if you're looking for an audit a really robust audit an audit contest is a great choice if you're looking to do a bug Bounty program right after you finish your auditing um or go to main net very quickly then a bug Bounty contest can also be a good choice and can help you save money as a protocol team instead of paying out three million doll bug bounties you can do a $1

million audit contest and you get all three of those bugs potentially in the same contest uh which saves a protocol team $2 million in that case um so both are very valuable and both can be used depending on the situation however audit contests are essentially a type of audit um bug Bounty contests are not bug Bounty contests do not guarantee any security researcher participation they don't guarantee code coverage obviously an audit doesn't do that either but there's an expectation that the full code is reviewed there are dedicated security researchers whereas in a bug Bounty contest it's less clear exactly what you're getting in terms of um security coverage we'll say so I think

one thing that we should be aware of as different platforms are offering different types of contests is that we need to be very careful about how we use the term audit because audit has become kind of a restricted word in the security industry and we don't want to be selling a bug Bounty product and calling it an audit because I know a lot of people in this room have put in a lot of work to making sure that crypto audits web3 security audits are valuable are doing full coverage as Peter krinsky showed on that slide we're going in the right direction so I just want to make sure that we aren't going to start confusing people by calling bug Bounty

contests audits because bug Bounty contests are definitely not Audits and this is very important so overall the state of audit contest very very healthy going in the right direction top protocol teams are using them they're a great tool to find critical bugs before you go to mainnet before you put up a multi-million dollar bug Bounty which many teams are doing now uh but we need to be careful about it it's a very powerful tool and we need to know exactly we need to tell protocol teams exactly what they're getting um when they sign up for an audit contest and what that audit contest is achieving whether it's an audit or whether it's more like a bug Bounty so overall both paths are great whether you choose to do an audit contest whether

you choose to do a bug Bounty contest we're headed in the right direction things are really good but let's make sure to keep the bug Bounty terms dedicated to bug Bounty products audit terms dedicated to audit products and that way protocol teams will know what they're getting and we will have a lot of safety in defi thank you very much [Applause] any questions overall state of Auto contest bug Bounty contests anything at all uh yeah sure thank

you is it me or uh yeah on the C Cas uh so one question I have is like as um as an AA developer I am one of the developers of the AA protocol we have done many uh back Bounty programs and campaigns and a variety of of different um activities around like the security of the protocol so one thing I noticed is that uh it's really hard sometimes to discern uh reports that are actually you valuable and meaningful from reports that are maybe attempt to get a very easy Bounty or reports that have been

reported multiple times yeah so there are a variety of challenges around uh participating into these campaigns mostly because they take a lot of mental effort in trying to discern stuff that is actually meaningful and valuable from stuff uh that is uh less valuable or maybe just plain and simple waste of time so do you have an idea about how moving on in the future we can actually challenge uh this uh state of of things and maybe improve so that the experience get even better yeah great question so in and a of contest they're totally open you can receive vulnerabilities from anywhere basically anyone can submit vulnerabilities which means that you can

see everything you see people using chat gpts to submit things that look real but aren't real basically you know like every type of thing under the sun you can see in a submission in an audit contest um so there are some things that a lot of platforms do like only allow high and medium severity vulnerabilities so that all the fluff underneath isn't really a part of it isn't really rewarded isn't something teams have to look at another interesting thing is we've seen over the course of you know two years of doing audit contests now that judging is really difficult and I think that's kind of what you're getting at is how do you discern between something that sounds like a bug versus

something that actually is a bug or something that isn't that useful to the protocol team versus something that is and you get all these different um submissions and so I think we've seen platforms um moving towards dedicating a higher dollar amount to judging because it's become clear that you really need to have somebody who can discern well between what is a bug in that specific type of protocol for that team and what isn't and this is a really difficult problem I don't think there is a fully objective way of always determining that so having a great judge for those audit contests is the best way we know how right now maybe AI in the future like training against like pass submissions

and stuff could be an idea just yeah I mean we've got AI doing submissions so we might as well have ai doing judging exactly against it they ccel each other yeah yeah uh I think someone over here had a question so my question was similar to what you talked about just right now uh about the lows and gas optimizations not being awarded too much uh so in the beginning they were and now we have moved to a situation where only mediums and Highs are being awarded and do you see a future where uh only highs and criticals are being awarded and uh if yes do you think that this will be uh some kind of uh an entry barrier for

beginners who are uh looking for these low hanging fruits in uh lows and mediums sorry entry barrier for who uh entry barrier for beginners for amateur security researchers yeah yeah it's a great question um I think one of the great Parts about audit contests is that you can start out not knowing a ton about security and you can still make $50 in an a contest you can make $500 I mean a lot of people in this room have made $100 $11,000 $3,000 in an audit contest and said that's it I'm quitting my job I'm dedicating myself to this full-time which I think is amazing and awesome um but it is true that what's

valuable to protocol teams especially as they get close to mainnet is more on the criticals the highs and they care less about hey you can change your code in this way to optimize something because they're like look we need to go to mainnet we need to just be secure at this point so there is a little bit of tension there between having AIT contest that accept all kinds of vulnerabilities and making sure that upand cominging security researchers can make money gain confidence you know build momentum in their career by doing audit contest which I think has happened a lot um versus balancing protocol teams who in certain situations may only want high and critical severity vulnerabilities before they're going to mainnet so I don't know the exact answer to that

question but I hope we'll see a balance where beginners can still have the right on-ramps to get to become top Security Experts in the space like we've seen over the last couple years thank you uh yeah is it safe to say that there's more incentives and Bug bounties than audit contests I think if you look at the dollar amounts the dollar amounts are a lot higher in bug bounties um but the likelihood of getting paid is much lower so it's or in most cases I would say is is lower yeah

sure so would it be better to start off with audit contest and then go into bug bounties 100% 100% I think we've seen a lot of teams take that path especially doing you know more traditional consultative audits on this side audit contest here and then bug Bounty especially once you're live on mainnet um because it's it's like a risk reward type of thing so there's a lot of vulnerabilities that are going to get found in those early Audits and you're not going to have to pay a lot of money for them in audit contests there's going to be like a medium amount of vulnerabilities found maybe and you're going to pay a medium amount for it and then in the bug Bounty program there's going to be very few bugs found but you're going to pay a lot for each one

of those bugs cool I think that's it we can end the session here thank you guys for attending session four hope it was informative and uh yeah looking forward to session five okay so we start session five hi

everyone my name is Emilio I am like VP engineering aabs I will presenting this next round of talks uh we start with a P panel that is actually exciting one because it's going to be very spicy at least I hope so and I have my good friend here moderator that I hope he made a good job with the questions so the next panel is going to be the battle of the languages and is moderated by Mei Zer did I spell that right amazing so I guess we can start all the panelists can join on the uh on stage thank you good luck thank you on though it is now beautiful all

right chman grab a seat yeah doesn't matter go for in the middle cuz it's better there we go all right hello everyone um we'll kick off with a quick round of intros introduce myself early this morning so I'll Be Quick Med co-founder and director of Sigma Prime blockchain security and research firm I'll pass it over to Harry hi I'm Hari I'm one of the founders and the CEO of spit and cantina we are an in security Marketplace we work with unisab coinbase you name it we work with them today but before that I used to build uh the solity compiler at the ad Foundation um I work with a lot of uh Engineers uh building solma contracts and you know I'm happy to

share my thoughts I'm Dave Grantham uh currently on the security team at polygon but uh prior to this I work worked at um protocol Labs on the LI P2P team I was head of security at the Linux foundation hyperledger for a long time uh the reason I'm here for rust is I was on the security team at Mozilla when rust was invented I ported the tool chain over to all the BSD platforms I ran the tier 2 build servers for many years was part of the team that like realized that C++ was the bug right so yeah I I I think it's pretty fair to say that I'm one of the first rust programmers that wasn't on the rust team because yeah we had to

learn it exciting Wolf Gang yeah hi I'm wolf Kang G Camp uh I'm at updos Labs where I'm currently leading the move platform um so uh what is move move is the new smart contact language and we will probably talk a little bit about here uh which also comes with formal verification that's what I actually did primarily before I'm generally tackling the language move right now updos updos is the L1 blockchain uh which came out of the Libra project exciting thanks for the intros um so this panel is around programming languages and you know it's a bit of a tribal topic everyone has some sort of

preferences so I'm going to kick this off by asking Wolf Gang if you could please tell us a bit more about move and what perhaps sets it apart from solidity U if you could highlight some of the key advantages of move over other programming languages like solidity when it comes to Smart contracts yeah so like uh I would say one one of the key advantages of move is to be frank that it's later than solidity it was created after solidity many years after and uh it was around 2018 when move was incubated at Facebook at this time they still called themselves Facebook uh as a as a kind of uh long discussion process whether to use an existing smart contact

language or whether to use rust and they concluded that uh there need to be a new smart contact language and the main concern is very close to the objective of this conference is basically security so what differentiates move from uh other languages it has uh a virtual machine uh based on a pretty high high level bite code uh which can be fully verified you can add loading time add execution time basically verify type safety reference safety so move has a similar reference semantic than rust uh and other kinds of uh important safety aspects of the code and you can also take the move bite code and easily

decompile it back into Source because there is no information lost in the move bite code uh this also reflects in the fact that you can easily use tools like program analysis or formal verification on move because move is was basically designed for being analyzable and transparent exciting and I believe there's a new version of move that came out very recently move V2 yep would you be able to perhaps highlight the main differences that were introduced in this version compared to the first one yeah I'm glad to so like uh the new compiler and I want to say right away a new compiler is considered a big risk factor in the industry we know that oh yeah uh

the new compiler was created to basically unify the move verification or move Prov architecture with a compiler architecture which were developed independently back at meter but share a lot of common commonalities if you know a little bit about formal verification you know that it's basically a compiler to an smt backend now so you compile just a different to a different target language if you want so in a lot of complex steps and that's really the same like compiling to bite code so that was one of the reasons so we can innovate faster in the move space By by unifying those both architectures by the way I forgot to say uh that's also important for the move compiler uh a property of

move is that it's not finalized now so it's still evolving and uh the compiler was also created to make it easier to evolve the language we created move two which is a new version of the language which has a couple of interesting aspects thank you uh I might change this up a little bit and go go with you Dave if that's okay sure um if you could tell us why in your opinion rust has become so popular amongst developers over the past decade when it comes to its security properties and security guarantees compared to the nightmare that you um pointed out earlier C++ oh okay so let me think so I I was a C++

programmer for my whole career uh I've been a programmer since since 94 so like 30 years this year so wow um was anyone [Laughter] born I think that the reason that rust was popular or has been popular comes down to a couple of things so like when we were at Mozilla looking at rust um the goal was to figure out how we could slow down bugs security bugs specifically going into Firefox right it's like we got tired of getting just hammered at P to own every year yeah you have Fu geohot I like you but I would flip you off I'm I'm not Lin I'm not going to flip off on stage anyway

uh so when we were doing this you got to remember Firefox is C++ dlls and JavaScript code flying inform formation that looks like a browser okay and so you either had to be JavaScript or you had to be C++ and if they were going to rewrite components in a new language it would have to be a dropin replacement for C++ which is exactly why and probably the only reason why rust is a dropin replacement for C++ that it can expose a c uh calling interface and a cabi and all that stuff um that has certainly helped it because it allows you to incrementally change from an old in an old code base and a mature code base to rust um but I think

at the end of the day we all fight in our and our engineering teams we all fight bad habits and I think rust is the first language that we can honestly say that bad habits generally don't compile right I think it was some very basic things like flipping the default mutability on on variables to being read only you have to like explicitly say this is a variable I'm going to change right um I think it's very opinionated and very unforgiving borrow Checker um also really hammered home sort of the you know you can only have one mutable reference to something uh again that's a bad habit that we all carried over from C and C++ like oh it's just a pointer

I'll just throw it around who cares um and which is we all know probably the source of most security bugs and then um let's see the last thing about Russ that I think it was really cool is that there was like we basically accepted that the long time um assumption that long compile times were a bad thing always right we we were just like look no we're going to do a ton of static analysis and we're going to take a hit on our cicd pipelines our compile times and all that stuff for all of the wonderful static analys analysis results we can get out of this and so at the end

of the day it rust is very programmer friendly it's just highly selective as to who it thinks as a programmer and it will mock you but it will if you persist you actually end up being a better programmer and going from rust back to languages like JavaScript or CN C++ or whatever you're actually a much better programmer so I don't know I I think that it eliminates whole classes of security bugs we've been fighting for decades but at the same time it forces Engineers to level up their skills and in the end um you get better code generally out of it um and your engineers get better I don't know I it

just seems like the right thing to do that makes sense we're Big R fans at Sigma Prime so I can't really disagree but yeah yeah and then because you can just drop and replace it they could write a rewrite a dll and rust and put it in to replace a C++ one everybody's like well why wouldn't we do this yeah in fact Linux has officially accepted support for rusta yeah that'll be really interesting right yeah yeah how that goes r as well performing as C++ it is it's exactly the same there are projects which come to a different conclusion not because of the language but because of the way how people use the language interesting yeah I would love to dig into that but you know in rewriting components in Firefox we found that there wasn't really any hit at at

execution time but we did see things like the URL parser and Firefox which was like an endless source of security bugs when we rewrote that in Rust the number of security bugs literally went to zero it was like it's done right like there's no more security bugs I mean at least for a brief while I think there might have been sounds dreamy but it went from like just a constant pain in the ass to like nothing that makes sense yeah all right I would love to save some time to take some questions from the audience so I'm going to move to Harry Harry you've been involved in solidity probably safe to say since almost day one um you uh you obviously have a very strong security background in solidity so solidity has perhaps the largest deel Vel oper Community when it comes to

Smart contracts and it's its ecosystem but at the same time it's probably the uh language that suffers from the most hacks over the past five years uh we've lost a tremendous amount of money on on chain smart contract exploitation uh so from your perspective what steps do you think developers should be taking to effectively mitigate or avoid these security foot guns so I will get to that uh but I want to maybe like tell a wider point which is you know I love rust I love you know when I was younger I mean I used to love hasal and you know rust is practical like a like an objectoriented um H H it is um I also I think like rust is great for building

um like systems level um software but I don't think rust or even move for that matter is well designed for blockchain applications the safety um advantages that rust has built in it doesn't even apply for blockchain like period like uh I meet a lot of people that learned solity for the first time that was their first programming language ever they don't understand anything about moves manics Bor Checker these are not the issues that the uh that the users are facing and I feel like in that sense um building a programming language where you don't truly understand your uses is uh fundamentally flawed and this

is the mistake that a lot of uh like compiler engineers make where they like all this programming language I mean I love Haskell but if I if I were to build a solity to be like hascal then there would be no blockchain there would be no smart contracts in the world so solity made a lot of pragmatic choices in its design it's extremely simple you can talk to a lot of people here where they learned their first programming language was solidity course so I think that's where a lot of the success of solidity came came from making it extremely simple um a lot of the security um issues that these languages solve They Don't Really apply in blockchain like you know for example memory like memory is like Emeral like after a transaction you throw it away so you don't really

have to worry too much about uh memory management issues which is a big thing in systems level languages um so a lot of the designed choices and solidity were made to like make it extremely simple to write code uh it was purpose build for building smart contracts and as a matter of fact a lot of the bugs are not necessarily an issue with the language but rather you know bugs that you have when you write any software a classical example is um rounding issues yeah so if you look at the history of uh rounding in Computing you know Computing um you can look at many rocket launches

that fail because of a bug in in rounding um the same thing in uh smoke contracts if you don't really pay attention to um rounding issues you can have a defa protocol hack um the the issue the bigger problem with uh the crypto is that it's such an adversarial environment where anyone can now come and interact with your software it's it's even worse than even I think Aerospace where I don't think like when there's a rocket launch people are trying to adversar attack it whereas if you are trying to launch a defa protocol billions of dollars on the line people are going to be coming in and trying to find bugs in it unforg so I think the bugs the kind of bugs that are in solidity uh smart contracts that will

always be there in like pretty much every language the kind of bugs that rust and other languages solve are non-existent in blockchain like memory management issues I don't know a single bug in you know in a def5 protocol or some other protocol that is because of poor memory management um so to answer your question um the kind of box and solidity are really um logic issues and you have to be extremely careful when you're writing code you have to almost uh think about it as uh writing um like mathematical code like you have to be very precise in your um building software and if you're coming from web to you have this

philosophy of building fast and you know breaking things that doesn't really work in building smart contracts you have to be very methodical about writing software you have to plan out very very well and if you want to get good at security I think the best way to is to understand like how previous hacks has happened um there are ways to level up your security skills if you are a engineer you can do things like competitions or boundaries it's it's a good way to like learn about uh security issues so I know that was a lot you know no no no thank you so if I were to summarize the reason why we're seeing all these hacks and solidity is not due to the language it is due to the popularity of the Lang language exactly and I want to give Wolf Gang an opportunity to react to that because

obviously move is meant to bringing a whole set of built-in protections for safer smart contract development so would you have anything to respond to what Harry just said well I mean I by the way I I love solidity now I I know solidity quite well because I also built a compiler from the move language into the evm oh yeah and as part of that I I was getting acquainted with solidity my criticism would be not actually on solidity but on the evm so like uh the target of solidity now and that influences a little bit back to the language the problem with the evm is that uh it's basically a lowlevel fomon architecture with memory

but even worse than that the control flow graph is obfuscated by by having basically indirect jumps over values on the stack where to jump tun it makes really hard to reason about I like you like a real computer scientist looked at it and was like H I don't know about this I mean definitely I I I have a lot of appreciation for the yellow paper now so and it's a great piece of work and it started this industry but it was not written by a comp compiler specialist yes obviously so like so that's unfortunately uh like like a like a weight which solidity and evm has to carry uh which is hard to remove today you know thank you I mean I agree like in in that sense where a lot of the solidity like quirks come from the evm um we have

to be somewhat close to the evm we have to optimize the language so things are optimal in the bite code so you have to make certain design choices that make sense if you understand the evm but may not be as intuitive and as a compiler designer you have this question where okay you can make the intuitive thing but it's going to be way more expensive or you make the the most optimal thing so this is like the hard design challenge where know people want to optimize for gas people want things that are that are like you know efficient um and you have to make this trade-off of like do I make this intuitive and make it less efficient or do I make it very close to the evm and maybe add some quirks that makes sense uh I asked you how to upscale in terms of security had

great answers contest there's a lot of resources now in solidity I want to ask the same question to these two gentlemen if someone was to try to learn move and secure move development what would be the perhaps two resources that you would like to point them to uh how compar to Zana I'm sorry uh best resources to learn how to develop safely in move ah okay um so this is indeed always difficult if you have a new language you need to come up with the templates and the patterns uh to use it and I I would not doubt that uh so basically solidity is more advanced here this point of time course of course of course of course because of all all the long because of

the size of because of the long time it was there so we're working on it and we getting better but we have the advantage that we can create tools uh easier okay and uh those tools can can be based on on Modern ml techniques like llm or but there can also be on synthesizing or analyzing the actual code and uh so yeah so like I I think in the long run I I would better move but who knows okay same question to you Dave if that's okay I mean we keep hearing that rust is hard right it's a hard it's a very steep learning curve do you have an advice for people watching or here in the audience who are willing

to spend a bit of time to learn rust and hopefully learn it securely yeah so I mean there's a there's a ton of really good resources out there about writing secure rust and like understanding it all I think the reason why people say rust is hard is because it looks like an algol family language and it isn't right you have curly braces you have parentheses all the things so you think oh it's JavaScript oh it's C++ it is not it is an ml-based language that looks like an algol language and so you have to think that it was originally designed to be a functional language which is why he was saying it's like a it's like an object objective like hascal and so you have to be willing to

break your brain and you have to program in the way that you uh realize that a lot of your habits as a c or C++ programmer or even a JavaScript programmer or whatever don't necessarily apply all the things they told you you were supposed to do in computer science class in college like you need to make a smart pointer to manage your memory you need to do proper error handling all that stuff rust will 100% punish you until you do that um and so you just need to go back to the fun fals of what you learned in in University and just accept that just embrace it because it's really about forcing you to do proper

things as a as a software engineer I know I sound like a rust Fanboy and I am but I'm going to be honest that rust has a very dark side that I don't think a lot of us are talking about which is the compiler is amazing at telling you you suck as a programmer and so it forces you to be better but then we have this other tool cargo which for some reason didn't carry the same like paranoia that the compiler the rust compiler has into the cicd you know your dependency management all that kind of stuff like you would expect that cargo when you're updating a dependency would somehow be able to diff like do a Delta and say like this dependency from

this minor version to this minor version 60% of the code changed like you should not trust this anymore right like want to upgrade yeah but it but it happily will do that it's like oh who cares it's the new version it doesn't matter it's been completely Rewritten it's full of black ho you know back doors and all kinds of really terrible stuff and so what I'm getting out here is that we have this really amazing compiler that makes you a better engineer writes code that eliminates whole classes of security bugs and then we have this build management tool that it uses hashes maybe you know to track versions and stuff but there you would expect it to reflect all the best practices in dependency uh management uh software

supply chain security Audi you know all the audity things we do like what was changed in these two versions you know was there anything related to memory management anything related to Secrets management anything related to cryptography anything like I just think Russ could be infinitely better on this front um instead of it just being yet another build tool you could leverage in theory the comp static analysis capability so that when you are updating a a library it is able to detect that there are you know cryptographic algorithms in here that are being modified there are you know basic types that are being modified like fix size arrays have changed size right

so all of the all of the uh type um assumptions that we have all through our code have to be Revisited now because this isn't 20 bytes it's now 24 bytes or something like that and I don't know I love rust to death but cargo needs some serious work thanks for the transparency yeah can can I add something to like the earlier uh comment like I think to truly appreciate rust I mean I love rust but to truly appreciate rust you need to write C and you need to write C++ and only if only after writing you know C and C++ would you like really appreciate like R like if you were a new programmer and if you were to learn rust like like

what the hell is a borrow Checker like it makes no sense yeah why would you do that right yes it makes no sense and then you you know but if you if you write C that it makes a lot of sense and if you if you write like C++ it makes a lot of sense so the way the Russ language was evolved and designed was to solve the limitations of CN C++ and you can only truly appreciate rust if you if you pain yes exactly you need to go through like a lot of segmentation calls in in see you need to like be able to debug a lot of things I'm like what the hell is going on why why is my memory getting leaked and only then you would truly appreciate rust being repeatedly humiliated at Pondo can't disagree I want us to take a

bit of time to talk about compiler bugs if that's okay um and how ideally how to prevent them uh not too long ago there's been a compiler bug in the sway compiler which resulted in funds being stuck in a lending protocol sway land um compiler bugs can be really really challenging to detect um especially relying on traditional testing techniques um so I'm just opening it up here to see if you have any thoughts on how we as an industry could be doing better at detecting and hopefully preventing from arising in the first place these type of uh bugs H I think yeah go for it I can just say

like we created just a new compiler so we definitely thought deeply about this problem and uh we also were advised by our security company AAC about it so you need to come up with uh a new testing approach now what we basically doing is comparion testing on all the transactions which forever executed on our blockchain so every single of those transactions will be running through the old compiler and the new compiler so that works if you create a new compiler if you create a new feature in an exting compiler which I think this uh I don't know whether that buck we're talking about was caused by that but that is indeed a different problem so there is

really no no silver ballet apart of being extremely careful to roll the thing out that's what we also doing by the way with the new compiler uh we have done it basically at already half a year ago but it's still not activated by default so you have to do it for a long time I remember when I was at Google when there was uh basically switching from GCC to uh to uh to this other C compiler architecture I forgot the L not yeah cang right uh that took them two years or three years no so that's what they took the time for ring or switching the entire company so it's just very difficult but and and and

laborsome and takes long but it can be done you know rust exposure to compiler bugs is like several layers right I to make it to to be able to say that it's legitimately a rust bug would be just a front end bug right and they're very transparent about changes in the front end in fact I think for the last few years Russ's front end has really just been about adding sugaring desugaring right like you know async a weight actually just dgar to it's just a shortcut for like some pedantic rust underneath it um and so they're not really changing the language itself but we are exposed to llvm bugs right because that is the back end and you

know I honestly as an engineer I don't I don't know that there's a way you can that you can prevent them I think Google's approach to finding Chrome bugs could be really helpful here where they just like they have headless Chrome instances millions of them and they just load web pages and they look at the memory footprint and you know the execution context and like you know do we ever have a pointer jump out of you know seg vaults page you know all this stuff right and so I don't know I think what we could do is Baseline a certain version of llvm like Wolf Gang was saying here is like once you have one that you fairly well trust because you fuzz the crap out of it that anytime there's a new update you

kind of make this managed transition from an existing one to the new one you know you're compiling in both comparing the differences you're running all kinds of fuzzing operations on it yep I it's really tough I mean I don't remember what the guy's name is one of the Unix guys you know wrote that famous paper like how do you trust the trusters or what you know it's about it's about you know compiler bugs you could actually inject something in a compiler to put back doors into software so I don't know you just kind of have to fuzz them I think honestly yeah to gain some kind of trust you just have to throw all kinds of junk at them and see any yeah any thoughts I mean first of all like this is like my nightmare like

you're nightmare yeah yes yes like you know I I would you know ship a PR and if there is a mistake in it in in solidity there's like billions of dollars okay um so it's a nightmare and we put a lot of work into securing solidity and you can see the results like there are zero Coen bugs in solidity that was discovered in in onchain so nobody has ever found a bug um that could be traced back to a compiler bug on the main net that is not the case for other languages there was the reeny bug in wiper recent ABI bug in sway nothing like that in the solity history and we put a lot of work into engineering the compiler so like we want

we wanted to have like zero cin bugs um couple of things we do like first of all like the entire compiler is kind of simple and it's self-contained we don't really have too much external dependency uh we get a question a lot why don't we just use an lbm framework or something to um build the solity programming language there are multiple issues there but one issue is that okay you introducing an external dependency uh of of something that wasn't even designed for the evm so that by definition adds a lot of unnecessary complexity so we have avoided to we have avoided adding too many external dependency like we tightly control like the entire like code generation Pipeline and we kind of understand the entire entire stack we

made the compiler quite simple um we have purposefully designed a lot of things so it's easy to write it's easy to write the compiler um and lastly we do a lot of uh fussing and that's been quite effective so solidity has you know there are some advantages in how we build the language the first thing is we put a lot of assertions into the the code generation pipeline uh the entire pipeline has a lot of assertions and what we can do with these assertions is you can you can create random solidity programs you can you have the grammar you can use a fusser to Generate random solity programs and you can try to compile it and you can see if one of

the assertions would fail and this is extremely successful in finding bugs before it goes into production uh the other thing we do is solidity has two different code generation pipelines and when you have two different Co generation pipeline what you could do is you can Generate random solidity uh programs you can compile it in two different pipelines and now you can send random call data into it and you can now compare if the state is different in two different um two different like code generation environments and this is also very successful in uh finding bugs before it gets into like production and we have discovered many bugs that would have gone into production this way we have also discovered bugs that we know

exist in in in like in well in in actual compiler but it's very very hard to trigger it like a lot of the time with fuzzes they generate code that a human would never write yeah so fuzzing very useful you know building with the the mindset of like you know building a secure compiler is very important making sure your dependencies are small so you understand what you're building is important the you know writing a lot of assertions and trying to like you would rather you would rather have solidity fail uh than generate Bad Bite code so so is build with that mindset that makes sense bav has been doing tremendous work over the years with the Ean foundation on SEC compiler yeah um I think can we take

maybe one question one or two questions from the audience yeah you you go yeah uh I have a question actually I really enjoy it because like as an application developer like for me it's really interesting to understand like the thought process behind like the development of compilers so one thing I felt over the years with solidity especially because I have been working with solidity since I don't know six seven years was like solidity 3.0 or something like that uh but recently I'm also starting to take a pick into move so that's pretty interesting as well one thing I felt

over the years is kind of getting better on the solidity side is that uh I some sometimes I felt kind of a disconnection between uh what the um compiler developers or even a lower layer uh like the infrastructure uh developers have in mind and the actual needs of application developers and so many times I ended up like saring and why the hell this thing is implemented this way I could have much more enjoyed one example the custom errors that were introduced yes I love them and I hate them because I hate the syntax but I love the idea so now it's better but back in the days like if using the

custom errors would have forced me to rethink completely the uh structure of the error handling that I we had in our protocol and we ended up not using them even though I love the idea so how do we improve on this aspect how do we get better in to make so that the experience for application developers is better because that's also helps in writing secure code I mean I I totally understand where you're coming from and so I personally believe there is an opportunity to make solidity 100 times better than it is today and people just need to work hard on doing it and I'm very you know I don't work at solity

anymore I you know it really pains me to see like the slow pace of like how things are done um but there is a opportunity to make it 100 100 times better the customer is a great example because you know we we shipped this feature um it worked but certain other features did not work well you know when it comes to customers like Tri cat for example and tri cat is a great example of like a uh a language design that is optimized for the evm but it's not optimized for the developer and this is like the challenge that we have to do like there there are ways to implement the TR cats so that it's very like obious to use for the individual developer but it's going to be much much

more much more like gas um INE it's very inefficient when it comes to like gas whereas the current implementation is like very tightly connected to the evm so this is you know I personally think we should have done the other way like you know optimize for the developer but the team wanted to make it like to be very close to the evm so this is like one challenge we have to always face you know like we have to make it intuitive but also optimal and very closely tied to the evm and the evm is also somewhat stagnant recently like right now we are making some improvements with the eof but in the last you know three or four years there was no major changes in the evm that actually improved the compilers or or languages so that was also like

one constraint we had as a compiler Engineers like the ethereum community was entirely focused on the merge which meant no other thing could be done um to improve the ecosystem so there was a massive backlog of uh evm changes eips that could not get in and all the compilers had to just you know do with what we have makes sense yep at the back hi uh I have a number of questions but I think the most important one is

for Wolf Gang I'm a fellow move developer and I think one of the major criticisms within the ecosystem is is multiple chains used move first it was DM now DM doesn't exist um now sui and move and I think another Cosmos based chain used move and there's major differences in these compilers and that's one of the major I've said major three times but I but it's like how I think somebody who's in the senior um development of the move language on Aptos how would you address this criticism and is there any initiative to try to make the make these compilers agnostic and like be like kind of bring this ecosystem together yeah let me paraphrase I think you are wondering

about the move dialects now right well sui and move on sui is different than move on the different move versions so so to say first the first year uh of of the startups uh Miss labs and updos we actually closely synchronized the two language version so Al you know that s already has a different po model from the very beginning which is completely based on objects and not on storage like uh like up move is and also solidity is no anyway so like we try to synchronize that but then we recognized in order to evolve those things and innovate in the

space of languages it doesn't make sense to to always have a it's very difficult you know to agree on language design uh things it's can take years until you agree so discuss a really long time and and whatever so we decided it might be better uh that we can evolve and innovate independently and maybe synchronize every now and then and we did for example for enam types which were recently introduced both in s and an abas um but uh we also recognize that there are basically different approaches and in the hope that we eventually consolidate it uh but yeah so so I I totally get what you're saying it's just not practical for us uh in different

companies to have uh to synchronize basically on every step no because we still evolving the language the language is not done at this point of time yeah do they all have the same base do they all like work from the same what base or are they like entirely different implementations they're they're basically very similar and and in or the same in in in core aspects no but but basically the the model how the how the blockchain is programmed in s is different than in updos or it was back at Libra and and d uh DM at uh uh at ma uh so that choose more like a Zana model

I think where you have basically uh you don't you cannot access storage from a contract you have to declare up front what the inputs are and uh we found that model too restrictive and I I don't want to really uh talk bad about our colleagues or former colleagues now so I don't want to we just thought it's not the way how to do it no and that's where this Divergence basically started and from from this different program models there are different requirements which are coming to the language and uh that's what's happening I now yeah all right unfortunately we're out of time we could probably keep going U for another hour thank you so much for our panelists give it up thank you great Engineers thanks for sharing

insights um I'm sure they'll be looking around so if you have more questions around their languages their respective languages go grab them ask them questions um and yeah what what are we on to next amazing guys it was a really enjoyable panel thank you and so the next coming up is a nice talk about me and like about the game of attack defense between me Bots the speaker is I'm sorry and the title is a cut and mouse game how to front round a transaction in the future thank you you want sorry do you want what's what's

that no I just stand here and oh how if you want the the not you have to oh got it wow I canot see it

am I good so you can see the yeah yeah yeah the monitor on can I hide the tab how should I how can I do it okay then I just keep like T that I don't need that I don't need that yeah I just use my AR Keys okay

good Hello is my M okay cool hi everyone uh my name is shei and I'm a security engineer at firstland so in recent years we have seen several cases where M BS forun attacking transactions one famous example is the curve Finance incident in 2023 the hack was due to the Viper compiler bug several map Bots they found run the hacking transaction and some of them returned the funds to the curb and similarly the security company blocky has also for run a few attacking transactions rescuing funds from hackers in 2023 and also earlier in this year uh

during the kyber swap hack $5.7 million were returned by Fun Run Bots to the protocol so in these instances mapballs were used as a force for the good uh outpacing attackers to protect users assets however in 2024 the number of and frequency of these stories declined our team has been exploring the ethereum mbv world since earlier this year and we have successfully prevented a few cases using the new methodologies so in this talk I will share how fun running works why it has become less efficient and the potenti potential future directions we are exploring first let's look at a normal um life cycle of a transaction and how

fun running Works assume you're a user and you want to send the transaction onto the chain and you have to send the sign the transaction first and um send it to a builder sometimes a RPC node or sometimes a uh RPC provider so block Builders collect and sort transactions and send them to build a block and then the validator when they receive blocks they will choose one block to finalize it onto the chain and usually they pick the one who's offering the biggest reward so in real world scenario there cannot be only one actor here uh there cannot be only one transaction one

Builder or one validator Builders will receive a ton of transactions put them in the men pool uh where it is a buffer for putting pending transactions they will they will form a block and then this block will give a max value and this is mbb maximum extractable value also there are more than one Builder validators receive different proposed blocks from different Builders and they will choose the one that offers the biggest reward so let's look at the F uh let's look at the Fun running so in the early days the process were severely abused because transactions are in the public m and the transaction in the public input they are basically visible to everyone

uh MB can monitor for profitable transactions like large traes or Arbitrage opportunities and just copy them with a higher gas price in order to be included in the first position of the block so this lead to a gas auction War where the original transaction Center will be out bit by Bots say I have a super uh powerful algorithm to find the optimal path to uh during diff for different pools but a cop cat he will just copy my transaction and add one gas to it and he will outbe me so all my computation power means nothing and yeah that's that's really bad for the um Arbitrage Bots and this is the process uh when the

fundr runner sees the transaction sent to the Builder or a public men pool he will just copy it and with a little bit more gas to it so the Builder will put the transaction in front of the original transaction and send it to the validator and the validator will put this uh block to the chain and because the first transaction is doing the exactly same thing to the second transaction uh so the first transaction will succeed success and the second one will um just revert this is really bad for the ecosystem so this environment doesn't incentivize beneficial meth actions no one wants to balance the prices between different pools and block Builders they consume most of the profits in terms in terms of of gas and normal users they

also suffer from Sandwich attacks to mitigate these issues private man pool came into play so there's this group of Builder who promis not to share the pending trans transactions with others uh that's pretty self-explanatory so private Mano they don't leak uh transactions to others uh reducing the risk of fund running this was beneficial because MOS now had to compete fairly for obvious arbitr orbit unities the mapos with better swap path or strategy would win the Ence of private mol also helped hide attack transactions and also let's look at how the process goes so the F Runner now cannot see the

transaction sent by the user to the private manool so uh if there are two Builders one is with a private manool and when it's not the one with uh private man who will build a block that will um have a higher reward to the validator and the validator will choose this block to finalize it onto the chain but does this eliminate all F running so according to our OB observations many hacking attempts happen in a two-phase style so the attacker first deploys a contract and does some preparation then sends the final attacking transaction which is a trigger transaction we call this preparation phase and the triggering

phase so in both phases the actions that the hacker performs are usually encoded in the contracts themselves we have seen many map bot exploiting these attacking transactions uh attacking contracts for quite some time essentially whenever a new contract need deployed onto the chain map boss will try to exploit them they will try call every function inside this contract so how do they do it calling a function uh involves extracting the function signatures since most contracts are often written in solidity or sometimes uh very little of them written in Viper they follow this um standard ABI conventions where you uh

hash the signature of the function so if the function called happen to be the final triggering function the mapall can Fun Run the transaction in the future they will know what uh calling which function will make them profit so the attack and defense game between the contract deployer and m boss begins here let's assume the deployer has to use this two-phase attack for some reason they're not using some uh uh like attacking in the Constructor uh then how can they prevent mfbot from exploiting their contract and this is really a problem of program analysis imagine in web 2 when you downloaded the software or program how does your antivirus

program detect if the program is performing some malicious actions or not and let's look at a few examp samples contract to um try to like fool the MV Bots this is a very common pattern we have seen a mapb can easily bypass this so here you have um two requirements uh the transaction origin and the message Ander has to be some fixed address there otherwise it will revert but really um this has a very simple solution is that you use a address hint usually these hacking contracts they are comparing the authority to their own addresses so you just need to pass in the contract Creator and this is another type of

authentication maybe this is this looks like a little bit complicated but it's not so it's hashing the message sender and comparing to Hash although hash is not reversible what we can do is on The Bu code level we just flip the equal sign flip it to uh less than or greater than that will be equivalent to a not equal to and this this requirement is just it can be be bypassed very easily so to conclude triggering functions with no parameters are free to exploit by mbots all a mbot needs to do is to explore all potential paths in the smart contract and there must be one

profitable path so contract deployers have to thought of a more complex functions so this is the complex function that a contract the employer had thought of uh so it takes one parameter you in 256a and it this parameter is a direct parameter related to the attack uh maybe there are some other parameters there but if the parameter passed in is related to the hacking process it's much harder to find the correct input because you know random inputs may not have to uh trigger the vulnerability inside the contract maybe it's a position loss it has to be a very exact value however we found that

fuzzing is perfect for these types of tasks so before going into how fuzzing works here let's define what is f what is fuzzing uh it contains of like five steps first is to g generate a random input this random is not like truly random from udev random um it's really uh it has some her istics and smart Generations but anyway let's just assume we have this random input and we execute the program or the smart contract with this input and we observe and analyze the execution collect interesting information from the uh execution Trace then we decide if this input is either interesting or the input is the one we

are desired to and uh if so if it's interesting some certain conditions are met we just exit otherwise we repeat and using the herotic information we collected to generate another input so fuz is a Technique we where we try different inputs to see if it behaves in a certain way in web 2 say a binary executable maybe this is memory corruption and in web 3 in the context of auditing this might be invar breaking uh I know like many solidity development they now contain this process of writing invariance and before they launch they will use fer to try to break these environment to indicate a bug and in the

map world of web 3 uh the purpose of fuzzing is really path exploring we want to find the specific path that lead to a profitable uh transaction and it's apparent that the key is to generate a good input generally input can involve various strategies for example you can just use random and that's uh basically the luck you need and also you have some constant values these are very special values maybe sometimes they do some good uh effects on the fuzzing for example some small values or some addresses of zero or Max of some uh types Etc and the final thing is her istics this is the

one uh makes different fers um effective or not so for example you can use a multiple of one to the uh 18th uh this is 10 to the 18 sorry uh so this is a very common constant in the math world or the ethereum world and also there are values collected during execution for example if you encountered a equal equal check during the execution maybe this value is very interesting maybe it's a password or something and also we adopted some uh methodologies uh open source in our etas our EAS was basically for um pre pre-employment uh fuzzing but it has also a lot of uh meth theologies

adopted from the uh Cutting Edge Academia site and next question is why fuzzing so the first reason and I think this the biggest reason is it's fast it's very fast comparing to symbolic execution for example and uh you know in math world uh on ethereum each block has a 12 12 second time interval so when you see a contract is being deployed you have 12 seconds to um to be the fast fastest one to do the triggering on the next block and it's very accurate compared to setting analysis for example uh if you're trying to do a full stat analysis A really thorough one to um to analyze a

if a uh hacking contract is uh exploitable or not it might lead to false positive but fuzzing does not because it's using concrete inputs to uh execute and the last one is it has very little effort to build a prototype uh f fuzzing it can be a dumb fuzzer and sometimes a dumb fuzzer can also lead to some uh profitable transactions but there are also some limitations of fuzzing so the first one is the number of input parameters as we see in the previous example we only have one input uh a but if the number of input parameters increases the search space will increase exponentially and the second one is the effectiveness

is really depends on the input generation if there are very poor inputs like truly random inputs it will never um reach the path you you desired and the last one is is that it's not thorough enough after all it's like generating like some pseudo or have um random inputs so some specific path like uh password generation thing cannot be reached without fuzzing only and I'd like to point out what we are doing next and uh we hope the community may take a look at this so now we are experimenting taint analysis and conol execution to solve the third third problem we mentioned before sometimes uh

the heuristics can be collected from taint analysis or can collect execution to explore more path and also we know some other methods that other teams are doing like binary right they manipulate by code and uh yeah and and also we we are really like th to see how this cat Mouse game continues where people bring more web two techniques into this web 3 world like maybe stackis can help some uh in the me world and maybe large language model will have as well and yeah I'm really here to see and that's all of my talk and I'm open to any questions [Applause]

you have a question hey thanks for the talk uh I just wanted to ask uh you had this slide with authentication and you mentioned that uh in that case you could change the bite code to just bypass the check right M my question is how do you especially in an environment where you're trying to fuzz very quickly how do you know which assertions you can bypass or not bypass cuz you know you you did also mention that the benefit of fuzzing is that it's uh reliable you don't generate a lot of false positives right but if you start changing the bite code you get false positives potentially yeah so it's really it doesn't matter like flipping one bite is really quick and that's the benefits of

fuzzing uh there's no much overhead to ex to like two or three times I think it happens in Nan okay but if you need to generate a lot of variations like if you have to come up with you know plenty of different enumerations yeah yeah so so for example for uh for example in this case uh if you fail this uh equal and the fails it's require you simply try another like there are two outcomes equal or not equal so basically if both path fails uh this fuzzing campaign fails but yeah that's very low overhead okay

thanks yeah I have a question also I don't know if there is someone else uh it sounds like the the problem sounds like a bit uh similar to uh gaming eyes where you need to find for example chess makes me think a bit like ideally find the right SE sequence of moves to to reach check Mid State so is there so there are some algorithms that fit really well this kind of uh strategies so for example mean Max algorithm and so on is this something that you might be exploring in the future so for example applying this kind of strategies to uh fing to reduce the

search the sides of the search tree of possibilities well uh cuz this is a like analyzing a program is a whole problem problem and it has no solution overall and fuzzing is like uh the fastest uh way of doing it so maybe machine Lear like it's more I guess related to stat analysis where you want to have a thorough understanding of the program but in the map world we need speed that's the reason okay um thanks for the presentation so most of the example that you show work because like that are not too

sophisticated right because the trigger function is within the bite code but what happen once the attacker gets know better and the trigger function is not in the B code directly and maybe you know they delate Cod to another contract later on but you don't know um do you have like aristic for that or are you consider yeah that's I think the is the final state of a like unbeatable hacker who hides his all his payloads in the final transaction and this a one shot transaction and send it to private manol and no no leak from private manool that's the final like state of a really sophisticate hacker but as of like 2024 uh we have see a lot of like two stage

hacking so far and I think we should like dig into it more okay thanks cool I think it's um it's done thank you thank you okay so thanks for the amazing talk about me and next up on stage uh we have a panel apparently I know but it

looks like a talk here I have panel but I think it's a talk uh the title is 500 Days of security Summer by Sara rainolds uniswap and it's about all the uh strategies uh employed uh in develop unit what before uh to guarantee smart contract security is Sara here okay

e for e great

perfect now it's allow I'll just let you do yeah okay great yeah perfect okay are we good okay hi guys um my name is Sarah I am a senior protocol engineer at Unis swap labs and this talk is called five 500 Days of security

summer um it's not actually 500 days we did not actually spend 500 Days on Audits and all of that but it's sort of a nod to I think this sort of robust process we went through in securing V4 and I'm going to talk a little bit about that today um but I'm also going to talk about the four I guess main phases uh at least how I think us at unisoft and probably a lot of other protocol OLS think about when we write a new protocol what are the four kind of big phases we think about and also how do we think about security at each of those phases so the design phase like what does the architecture look like what's going to be um a usable architecture but what is also um you

know less vulnerable to uh security issues at the building and testing phase how do we Implement really good um testing practices in reviewing PRS and then finally at the auditing phase um and so we'll kind of see like little examples at least from my experience of where we've thought about security and brought it into building V4 so first um I have been working on V4 for over a year now this was before um we really had hardened code for V4 and we had a vague idea of the architecture you know we knew we wanted a Singleton contract we had sort of this lock and call Style archit Ure um that's really

kind of the key like security mechanism in keeping um pools essentially solvent and then we also knew we have this like kind of flash accounting system we wanted to use transient storage there was no transient storage available yet in the evm um and so there was a lot of moving Parts with the architecture and I'd say it's quite complex especially if you compare it to sort of V3 where we have the factory models and each pool is their own contract um um right in V4 it's all pool storage is held in one contract so that was kind of complex and on top of that we had a huge feature set so like V3 it's a concentrated liquidity style amm um but you know it sort of

Builds on the expressiveness of V3 with hooks right so that's already scary in itself we're basically allowing at predefined points in the life cycle of a transaction you to call to an external contract um any external contract defined by the pool Creator um we have donate this is donating to inrange LPS that has some interesting implications that V3 didn't have um unlimited fee tiers Dynamic fees ERC 699 wrappers like this feature set is huge and on top of that there was one really big feature as well um that we wanted to get into V4 which was custom curves and I'll talk about that in a little bit um the first thing I want to

touch on though is um hooks we were we had a few different designs for how um we were going to design sort of this this call out to various hooks so um for some context hooks are addresses defined by a pool Creator and they basically allow the Creator to specify when at what point in the life cycle of a transaction can you call this external contract um and the key I think feature with hooks that is um really great is that you you have to predetermine what call sites those are so is it before swap after swap is it

before initialize after initialize before modify after modify um and those are unchanged they're defined in the hook address you can't change um what call sites or what permissions a hook has um the other key thing to know is that in creating these hook permissions we eventually realized that there were certain permissions that are quite scary so if you think about um modifying liquidity you can add liquidity you can remove liquidity you can do it in this at the same transaction let's say if you're rolling one position into another the scariest action is when you remove liquidity right you could build a hook

that isn't intentionally malicious but reverts on accident with like a bad parameter what happens when the hook reverts when you're removing liquidity worst case is now your liquidity is bricked in the pool and that was a really big kind of like scary situation and so one thing that we did in designing V4 is we actually added new um Flags into instead of just having the before modify liquidity and after modify liquidity we actually split these flags out into four Flags this was really important because we had to distinguish between adding liquidity as an action and removing

liquidity as an action and so really the key learning here in sort of going through some of the design for building Hooks and sort of defining some of these permissions is make these permissions as granular as possible um it has sort of implications when you think about building routers and um um liquidity management contracts right of if I can feel like okay I'm calling a pool but I know that I'm only caring about routing for a swap this pool doesn't have the before and after swap flag so I basically don't have to care what the other permissions are and you can kind of extend that when you think about the kind of plethora of permissions um that

hooks can have um this was a really interesting principle that came up as well when we were designing custom curves so for some context here with custom curves um it's really uh essentially the ability to bypass or override the concentrated liquidity model that's like the V3 or V V3 style or the X X Y equals K curve we wanted to basically allow hooks to be able to write their own curves or Define their own kind of exchange rates on pools um this is a huge design space we probably had around four or five different designs and all of them kind

of pulled and pushed at these different um kind of trade-offs so code complexity flexibility composability and in and sort of integratability and then security um and you can imagine like if you think about code complexity sometimes writing like uh a a ton of code actually might be worse for security um because you're you know potentially adding a lot of code to really hot paths in the code base um but reducing that maybe you know increases the flexibility of what what can happen at the protocol but then is a lot scarier um safety-wise for users and so there was all these various designs and

it was really a matter of choosing one that we felt good hit a that could hit sort of a mixture of these tradeoffs um so at one point um on the left you'll see this diagram for this super easy Uh custom curve implementation um it was a crazy design we essentially allowed a hook to be able to apply Deltas on behalf of a user if it had a certain permission turned on and what that means is is essentially you could do things like a user has asked to swap um you know 100 usdc a hook in theory could then say okay well

I'm going to give the user um 100 die but you know what I'm also going to like give the user um you know I don't know Point 2 eth or something like as a reward so you could have these really interesting features this is like a tripool you could natively have a tripool um what was scary about this design though was that we were kind of um adjusting the locking mechanism um it was not a ton of code but it was also harder to test there was sort of infinite possibilities a hook could do in this world um we iterated that a little bit and we actually ended up making the constraints more defined so one of the

key things um that I was talking about in the previous slide was sort of making these permissions more granular in the old design we had one flag that was any hook with a custom curve flag could have these um this permission in the current design um which I'm much happier with and I think really prioritizes user safety we have much more granular permissions you can see these four um permissions here outlined before swap returns Delta flag after swap returns Delta flag and the design basically is really hinges on this invariant that a user's balance always changes by their specified amount so if the user specifies you know swapping 100 usdc

they they will swap 100 usdc a hook cannot say actually you know we want the user to swap 110 usdc on the pool um so that was like a really important variant for us to keep and it meant that we actually had to increase some of the code complexity we have more checks more um you know kind of sanitization around our hook call sites um but it also meant that there's you know we could do more um specific testing around these kinds of behaviors for Hooks and so ultimately we favored sort of security and safety in this regard when we are building um custom curve pools um and again it hinges back on the fact that we liked this design principle

of separating out hook permissions and limiting where limiting them where possible okay into the testing phase of V4 um I put it kind of coupled with building because I think as we were building a lot of the features we were also heavily heavily heavily testing them um you know we had all the basics unit tests fuzz tests integration tests um but we actually made a switch very early on in the codebase to use Foundry and we were able to leverage a lot of their really interesting and great kind of testing uh Suite properties um we have some you know High fuzz runs in CI we use ffi for

some really interesting math testing like making sure the math makes sense we do we'll Implement something in JavaScript and we'll test it against solidity um but there was one really interesting contract that we wrote with regards to testing that I want to call out um but first I'll go into some of the testing Frameworks that we used so when we went to go write like you know an integration test for swap we'd have to go build these custom routers so we have this pool swap test. Soul contract and basically what that does is it unlocks the pool manager and then um processes the request and then settles all the

Deltas on core and so you need this kind of like router this test router for any kind of swap test you want to do so we built all these routers for swap we built a router for modify liquidity we built one for donate they were all custom contracts for each of these paths this was really nice for you know simple-ish tests where we're just testing a swap or we're just testing a modify liquidity it's not so great when you think about um kind of combining actions the more advanced flows um but those flows are really important because that's one of the huge I think benefits of V4 is you can couple all of these actions within one call to the pool um

so if you want to say you know uh initialize a pool and then swap or then add liquidity and then swap um or if you want to add liquidity remove liquidity all in one go you can do these kinds of actions um and so what we built was um the actions router which I love I think it's um a really cool testing kind of infrastructure that we built it's sort of this General very generalized contract um it allowed us to test all of these sorts of um interactions between swap modify liquidity sync settle take um mint burn all these things that you can do on core allinone um and it ends up it it's really quite extensible um

one of our Auditors even you know built on top of this actions router and added new types of actions you could test through and the coolest thing I think about this is that it allowed us to check certain properties while we were testing um swaps or liquidity so if we wanted to do a balance check in core we could do a balance check in the middle of the test or um if we wanted to check the transient storage variables we could do that in the middle of a test as well um and so this is kind of what it looks like um but you can see we have like all these actions defined like take syn we have like assert balance equals assert

reserves equals and this ended up being really important kind of contract that we built on um even in periphery so if you think about the periphery code this is all of our routing code it's our liquidity management code um we adopted this style of um actions routing in this like unlock call back for both of these contracts as well um which is kind of pretty cool because it started as just something we needed for testing and now is something that we use in production and is something that I would also recommend for people if they're working on Integrations with core is a pretty good framework to think about how do you batch actions on the pool

manager the last thing I'll call out for testing is I think this was a really cool thing we did we fuzzed certain um actions against V3 so I like to think about V4 as really like a superet of V3 we extend on all the math and everything that V3 uses and so if we could you know fuzz that swaps and modify liquidities are equivalent to V3 that's a pretty cool Benchmark reviewing this was honestly probably a lot of my time in the last maybe six months is PR reviews um and this is like we I think myself and also the rest of the team spend most of our time just look reviewing um and I would just say like we spend a lot of time

doing nits and we didn't really settle for finishing reviews quickly or trying to meet a deadline and the other thing that I think was really interesting is that we had to sometimes assume that code is malicious we've had V4 open source for over a year and get community contributions into the codebase and we always have to review those in mind with you know the assumption that maybe maybe there's a bug being injected here um and so that's a really important thing I think to keep in mind as we're going and reviewing Community PRS but also internal PR like we we have to you know not we have to basically doubt the code um when we review and then finally the audits this

was sort of the last phase of securing V4 um we had nine total audits um a 2.2 maybe even greater than that U million doll competition and we spent around five months um doing sort of a waterf flow of audits and competitions this is what it looks like so we actually back in March kind of scoped out what the audit process would look like and you can see it's sort of like a waterf flow uh sorry a waterfall of of audits where you know may we start the first two audits on core and then you know we start another audit a few weeks later and we incorporate those changes and then we do another Co like core code audit um same

with periphery and then finally the competition to wrap it all up um and I think yeah the key thing here from this is that we kind of liked this idea of audit stacking where yes by the time the first audit started the code was Frozen um but as we went on through the audits we knew that the code would change and so being able to incorporate audits later on in the process was really important for us and actually we had found mistakes from audit fixes previously found in later audits so it was like really key for us to have that audit stacking and then finally just like I think the last thing to call out is sort of having a diversity of expertise in the audit firms that we worked with so um and this is just a

call out that there were some really great findings I think unique to each firm that we worked with um and you know some I think found you know maybe more focused on like math heavy pieces or some focused on um you know like longer term integration wide but um we did formal verification so I think having all of these lenses on top of also opening it up for the community to look at the code and um find something was really really important for us so where we are today V4 core is Frozen um what is next we are going to

be announcing something on Monday uh uni day so um stay tuned and a bug Bounty so I like to say that yeah security definitely doesn't stop at um the audits we you know are still continually thinking about monitoring we're thinking about hook security um I think there's a ton more we can do even once it's live um and so with that thank you all for listening [Applause] I don't know if we have time for questions but if people want to ask questions hi uh yeah I've built out like

a few hooks in the past and uh like some of the main issues I came across especially doing like more complex curves like you described uh was trying to figure out like the logic for for the unlocking the pool and like settling the Deltas um and I was just wondering when you were like kind of going through the process of experimenting with like new curve designs and stuff like that like how did you go about sort of yeah handling Deltas like did you have any advice for like hook Builders who were trying to like grock that um and yeah just any advice in general about like that that part of hook building would be really really useful yeah it's super complicated um that's actually why we added a fun function this is Midway

through the audits there's a functioning core that we added clear that basically just removes dust so like right now before that function if you had like some dust left left over because you didn't exactly calculate it or there was some Precision loss or whatever um it's really annoying because you just revert or whatever you can't figure it out why clear um is something that we actually integrated in our peripheral code so if you go look at the position manager um we have a action called clear or take basically that says if there's a Delta open and it's like you can program it like in our test we're like okay if

it's less than like a 100 way like clear it otherwise we want to take it that's a really nice way to be like okay we don't actually really care about you know dust um but and we want to make sure the transaction doesn't revert so we can use that that's really cool um the other thing wrote is there's a contract in I think a lot of contracts in periphery where we're writing integration code with core like a lot of those contracts hook developers can use and build off of so one like I mentioned is the actions router and we have a contract called base actions router that basically does nothing and so you can like inherit it and write your own

actions and do your own like customize this actions router which is really great great we also have this contract called Delta resolver so it handles like the sync settle sync transfer settle process of like integrating with core which is really gnarly and definitely like could be a foot gun for a lot of users um and so I would recommend looking at that contract as well um and it handles a lot of the like yeah integration with take settles Etc sorry what was that last one called again Delta resolver perfect thank you thanks great presentation um I'm

curious among all the pool requests that your team reviewed like the external one you know over a year have you noticed any pool requests that you know looked a bit Shady or maybe you know almost malicious no um most of the well pretty much all of the community contributions were like really positive um so it's more just something we have to keep in mind when we look at reviews there's definitely PRS that we didn't accept um I think sometimes when we look at code and there's a lot of assembly or it touches really core critical paths we a little bit um less likely to want to merge something like that with such big

changes um with that being said we still made some pretty interesting changes to to paths here that were written by the community thanks cool thank you [Applause] moving to the next session Michael you want so we're moving to the next session

without a break since uh we need to make up for some time and uh get a bit closer to schedule so our next session is going to be pretty fascinating because it's five fastpaced talks they're all short talks all 10minute talks one after the other uh and we're starting with Micha lellan of open Zeppelin uh who's going to talk to us about the security of Da proposals all right thank you everyone um so these and the next few talks are going to be pretty quick these are 10 minutes so I'm going to just assume everyone in this room knows what a dow is and knows the basics um if you don't the basics are uh it's a thing on chain that governs what what you do on chain

whether that's user funds or protocol funds uh and more of them are coming online so we have to deal with them um specifically we are seeing them come out a lot uh when it comes to governing both defi protocols which has been very popular for governing a compound uh it even does some treasury management for UNIS swap uh among many other Dows um and then also especially L2 rollups um many of you have probably heard of this whole thing called stage one or bust uh vitalic is not going to call anything a rollup unless it's stage one and typically that involves some level of calization which can typically be done through a dow that's not the only path but that's one major one uh we have major rollups such as arbitrum ZK sync and many others now moving towards a dow govern model for the protocol and how it

manages upgrades in addition to a lot of Treasury funds that can be many millions if not billions of dollars so we have to deal with these and there's likely going to be more Dows in the future um but they add a lot of complexity this is no longer just one team trying to figure out how to deploy code securely which given a lot of the talks we've seen today are already very challenging now we have to deal with the fact that this permissionless governance environment itself has increased the attack surface uh and we have to be very careful about how we manage it while still keeping some level of decentralization or some level of governance participation whatever the actual goal is um this is no not a theoretical risk we've already seen beanock tornado cach and the compound Dow suffer some sort of impact from malicious proposals um anywhere

from just having a misconfiguration that causes temporary downtime uh to having the entire protocol ultimately become compromised with funds stolen through upgradeable contracts so um this is a very real threat it's something we've already suffered losses from and if we want to actually secure the future of ethereum if we're going to actually govern all these rollups through Dows or something like a dow then we're going to have to make sure that we're taking this very seriously so that's why we're talking to talk about Dow proposals uh and how you should protect against them um so I'm just going to start up front with here's the proposal life cycle very simply put uh I'm going to divide it into four categories that you can apply pretty broadly to any Dow uh no matter what framework you're using um eventually you're going to start with

the creation process you have an idea for a proposal and you're going to implement it um this could be uh just a simple function that's going to allocate treasury funds to some account or multisig that's doing a grant committee or something like that uh it could be something as complex as doing a whole smart contract upgrade and uh changing the way the protocol works the way the governor contract itself Works um which actually involves new code and solidity code that might have to uh go through you know a rigorous development process and testing and things like that so we say that the creation process is then going to end when you've actually you know you finished defining the requirements you've hopefully identified some of those potential risks as you implement the code uh and you've eventually developed some sort of proposal payload uh that you're then

going to want to be submitting on chain to the Dow before you actually submit that to the Dow you should ideally have a validation process which means that you're going to go through some sort of external review um and in the case of new code and audit uh that's going to end with validating that proposal uh once it's going to be submitted on chain and it's really important that not only are we auditing any code changes you know if it's an upgradable smart contract even if it's a small little change you know even a small little change can potentially cause a massive impact on a protocol um so everything and all of its impact should be updated or uh audited um and then you should be testing it ideally with live main net simulations I'll talk about why in a second but not just testing it in an

isolated environment but doing it based on the Live code you're deploying it to uh because the Dow and the protocol itself are live on chain and you don't want to be making any incorrect assumptions about how that code is going to operate in production um and ideally you've then checked the proposal submitted on chain which says say even once you've submitted on chain you want to do some additional checks is this actually the same payload we were looking at previously um were there any issues or changes introduced uh during the deployment um and so you want to have some general validation even once it's been submitted on chain ideally in the review phase finally the approval stage this is when everyone's actually going to show up and vote um in many cases this as token holders showing up to vote um there could be multiple

stages it could be you know you could have some snapshot beforehand uh you could have a multisig that also has to provide additional approval checks um in addition to the Token holder vote so it could be a simple vote it could be multiple checks uh but what in your case what you're doing in this case is ideally you're publishing everything you did in the validation stage to show hey it's been audited hey we've actually uh simulated it hey we've done testing we've had several other people sign off on it ideally all of the QA processes have actually been published for people to verify on their own um you also need to make sure the decision makers are informed there's actually been some communication to token olders so that they know to show up to vote uh and then finally you're ideally monitoring activity on chain to

watch how the vote is progressing how is the vote going uh do we anticipate any issues with the proposal as it moves through uh you know the uh protocol or the uh Dow and then finally execution you know once you've gotten approval it's officially been approved there's usually some sort of period uh it can be executed immediately but in a lot of cases and in best practices you have a time lock so there's several days where it's sitting before execution um and during that time you know you should be watching that timeline watch for the exact time where that execution is going to occur um so that there's a team prepared to ensure that it goes smoothly and respond to any issues so you should have an instant response and Recovery uh plan in place if something goes wrong um and then of course you should be doing

some health checks after you've executed it to be sure yes the impact has in fact uh you know done what we expected it to uh and there's no adverse effects that we have to respond to so in practice let's talk a bit about what we've learned uh working on compound because uh the open zeppin team has been doing uh security Audits and security work for the compound Dow for several years now uh working as a primary security partner I've been pretty involved at the high level a lot of the Auditors that we have actually here today have also been working on that and just so you know the process is pretty simple you know you create a proposal it sits there for two days you vote for three days it either succeeds or it fails and then you have a time lock that's CED in for two days and so

these are the timelines in which we're typically working so the first incident that I want to talk about is proposal 117 which is a cth price incident uh this occurred on August 30th 2022 when we're basically uh upgrading the UAV system uh this was basically a system that was comparing unisoft prices to chain link prices uh that uh needed to be upgraded from Unos swap V2 to Unos swap V3 uh and the problem is ultimately there was a uh misconfiguration where even though it worked with uh erc20 tokens there was actually a native ether eth function uh or Market in compound V2 uh and this Oracle didn't actually uh know how to cooperate with that market appropriately it was only all the testing was only done with the erc20

market and this caused a denial of service where the price could not be updated and the market was effectively Frozen because I called to that market would fail when it called the Oracle um and that really sucked luckily um we were able to get a fixed proposal up very quickly um and then uh wait seven days going through the governance process uh to get it through and luckily the prices didn't go down in such a way that would have caused major issues um so frankly uh very lucky um and what ultimately went wrong was the ation process and I think this is probably one of the best case studies to show that audits alone are not uh going to ensure safety because three independent audits from reputable FS were done on this code and the problem the reason that none of these Auditors caught it is because the

bug wasn't in the code it was in the configuration and how it would work with the onchain markets um the code made an assumption in the interface about it only needing to interact with erc20 not the native ether market and so none of the Auditors were able to catch it because it was not in scope um and so so ultimately what would have caught this is if you did a mainnet simulation it would have obviously shown what honestly seemed like an obvious bug in retrospect that uh this Market would fail and you would not be able to actually do Oracle calls so what was changed a contribution policy was then put in place that said anytime you're doing a code upgrade you have to publish a mate simulation before you even put it through a vote um if there is no mate simulation that has

been conducted that people can verify that everyone should basically automatically vote no because that should be a critical stage in the process um and then finally in addition to requiring the developers to be doing that stuff uh opens upin not as a security partner we're not just doing audits now but we're also doing onchain validation of that proposal and doing our own testings in a best case scenario or in a best case effort I should say because um at the end of the day we still want developers to have the ownership of making sure the code is secure well the security Partners or security Auditors are doing their best to uh validate that and ensure that it's the case um the next incident is probably something that you have heard about recently if you're following any of the governance dramaa which was the humpy uh governance manipulation

attempt uh so on July 26 28th 2024 uh a fellow named Humpty you can read more about him online he's got a history with Dows uh he was able to accumulate enough comp over time and spread them amongst many different accounts so it didn't look like this person had as much voting power as they did in order to then cast all their votes last minute to pass an unpopular proposal that would have given them a a large portion of the compound Treasury and through that potentially control of the doubt itself because it is a vot voting token um and so this proposal was passed you can see the timeline up there uh that shows that like if you can see the vote like it's clearly you know on the red line like well into like not passing and then

suddenly you just see this in the last hour literally like Saturday midnight all these votes start coming in from all these random accounts that in hset are obviously all controlled by Humpty um that was able to pass a proposal last minute uh and so this is a problem because ultimately even though you could say well this is technically following the rules of governance uh it's actually uh you know really bad for governments for someone to be able to do this because if all the token holders were aware this person had this much voting power more people would have showed up to vote and it wouldn't have passed so what was changed a proposal Guardian uh multisig was put in place to ensure that in specific cases like this there's someone who has a check on token holders that can actually veto proposals in cases where uh some Community rule was

violated um there's also an upgrade to introduce Corum protection uh and there is a delate program that is now trying to assign more comp to act to delegates that are aligned with the community um I'm almost out of time so I'm just going to run through this really quick uh this is ultimately the takeaways I want you to have is documenting a proposal life cycle closing any QA gaps especially between the audit and then what you're actually submitting on chain so that you know what you're submitting on chain is still matching the audit uh monitoring all your proposals on chain and looking for any activity including suspicious activity that might be coming from token holders uh as well as any issues that might lead to the proposal execution going poorly uh and then having checks on permissionless voting systems because ultimately these are perm of system so

that means they have very large attack services and you consider having multisig or other things that have a check against them um and so the takeaway is ultimately without security these Dows are going to be more vulnerable to the very risks they are intended to avoid which is to have you know people that are able to then introduce things that affect user funds um and so to protect Dows we need to have security safeguards embedded into the entire government's process both onchain and offchain we can't just rely on the code alone we also have to have the people that are running these Dows and participating in them to take security seriously and implement it in everything they do so uh thank you for your time and uh on to the next [Applause] person okay thank you Michael so our

next speaker is Victor Euro from mix bites uh who is going to tell us about defi liquidations so we're going to learn more about that but uh we have a few seconds until he connects his laptop apparently okay excellent yeah can you hear me yeah good hi everyone uh my name is Victor uru and I'm a senior smart contract auditor and

security res Searcher at mix bites uh let me give you a brief uh overview of mix bites before we start um our at mix bites our primary uh focuses on uh security Audits and research uh since 2017 we have conducted over 250 audits for more than 60 clients uh around 90% of them uh come back to us with code updates and uh new protocol versions here are some of our key clients uh today I would like to

elaborate on the logic behind liquidations and different defi protocols uh a flash crash is a good test for liquidation logic uh as you know FL crashes are sharp rapid drops in asset prices uh often caused by negative news large sell orders or low liquidity so what usually happens during flash crashes sharp price drops are typically the trigger event uh as positions become under calized automatic liquidations occur leading to uh more forced sales and further accelerating price

declines uh when collateral is sold off during liquidations um a look of liquidity can [Music] cause sharp declines in asset prices triggering cascading liquidations uh as Market crashes and liquidations grow uh uh Traders uh rush to sell off their assets to avoid further losses exacerbating their price decline uh liquidity dries up as market makers and Traders

withdraw uh insufficient liquidity can cause the formation of bad debts uh gas research makes transactions more expensive uh slowing down the liquidation process Network congestion and volatility May delay Oracle price updates leading to inacurate liquidation triggers uh this chart demonstrate the impact of uh cascading Liquidation on the cryptocurrency market in 2021 uh so what can increase defy protocol resilience to uh flash crashes

uh gas fee optimized architecture is designed to liquidate multiple user positions uh uh in a single transaction rather than individually um this reduces gas costs and U improves uh efficiency partial liquidations start early by liquidating only uh a portion of under calized position at the time um this helps prevent from large sou self WS uh reducing Market impact and um making liquidation more

manageable for users uh by implementing flexible liquidation thresholds um and collateral offers the protocol can uh adjust in real time based on Market volatility uh this gives more flexibility to maintain system stability during uh turbulent periods uh by implementing multiple price oracles that provide real time reli real time reliable data from various sources uh the protocol can react faster to price

changes also using of chain aggregation with signature verification uh can reduce costs and delays in updating prices especially when the network is congested uh for instance the peace network is one of the new of chain uh Oracle approaches um that leverages uh of chain signatures it allows a high frequency of price updates and uh ability for protocols to access uh price data without updating the smart contract State uh I guess you guys are familiar

with AA and U all similar traditional uh lending protocols um uh where liquidation logic use um uh where liquidation logic works with uh each position individually ABA has successfully navigated through uh several flash crashes demonstrating the resilience of its uh liquidation mechanism and protocol stability during periods of extreme Market volatility the advantages of AA it's are it Simplicity and transparency support

for multiple collateral types partial liquidations and ability for to select debt and collateral for Liquidations in third version um however during periods of uh Network congestion and volatility and numerous uh user liquidations um execution costs can become uh extremely high in terms of gas fees uh this makes it economically unfeasible to liquidate smaller user positions uh also uh liquidation may not occur quickly

enough um leading uh to the accumulation of bad debt so let's move on to other Solutions uh in curd uh liquidation liquidations use an IMM style mechanism llama uh where un under culturalized debt for multiple users is gradually um repayed by swapping um collateral for cure FD uh this approach minimizes Market impact and uh maintains stability uh llama enables uh soft

liquidations Arbitrage opportunities and collateral rebalancing uh it breaks down the collateral into separate bands uh each uh band represents a a different price segment uh users can choose the number of bands uh the the collateral is uh divided into um uh soft liquidations require um lower gas fees due to the efficient processing of positions through shares and band-based liquidation um this make them more cost effective uh however curve USD supports

only isolated markets uh yeah fluid fluid is another interesting solution instead of uh assessing and liquidating each position individually uh as in traditional Landing protocols uh fluid groups multiple positions together within a TI H TI represent separate price range for collateral AET uh if the when um when the collateral price moves out of the tis range

fluid evaluates U the this all positions within the ti for liquidation if the combined collateral within a titig uh drops below a necessary colorization ratio uh fluid initiates a liquidation process for all positions within the ti in addition to that fluid has a logic for absorbing bad Debs uh if the current uh price uh drops below a threshold and liquidations is not profitable anymore uh fluid liquidates um unprofitable

ticks absorbs bad debts by liquidating unprofitable ticks and prevents uh Liquidators from doing unprofitable liquidation uh there are multiple assets within the same Market are not supported uh which can create inefficiencies for Capital utilization and uh at this space continues to grow improving the efficiency of liquidations U and reducing the impact on users will remain uh key priorities thank you very much guys if you have any questions feel free to reach out to me any time uh visit our blog uh this is my contact info thank

you thank you Victor so we're ready for our next speaker if they could come up next speaker is Marilyn agit from Moro Labs you have fans here I hope they're not in your payroll uh so so our next speaker is uh Merlin and he will tell us about the security that we can get through single purpose protocols in just a couple of seconds okay

next can you can you hear me okay perfect cool um so I tried to be fast last I have only 10 minutes but uh anyway I talk about like how to build like a safe and scalable protocols and we'll see the the PO of like single purpose protocols so first like maybe just a reminder on where uh we are heading to so uh basically defi so decentralized Finance is like building uh Finance but on Shain and much better so which means like uh more resilient Fair open transparent efficient system on chain um and also we want to do that

for the whole financial system which is like four 470 trillion of dollars something like that which is like 4,000 times like what we currently have in defi so it's massive and right now um the problem uh to me is like the current paradigma of like building smart contract and protocols in defi is not going to make it um so right now uh as of now we have um uh we had like 6.5 billions of dollars that have been hacked just in defi so I'm not not counting like uh uh hover uh scams Etc that are not part of defi which is like too much like to board like those trillions of dollars and um

for the past three years we have been working the space and working as close as it is possible to on overlanding protocols and defi protocols in the space and we have realized that there are several problems uh that uh makes this those paradig like uh not going to make it uh so the first one is like just like about security is in sense like you have like a thousand of lines of code for uh those protocols uh resulting in like a huge small contract risk uh and shrin with like economic risk it's usually like um sorry The Click Click does not work oh okay perfect um usually it's not enough

efficient to compet with trat Fi large spread uh large slipage uh low Capital efficiency and um usually Protocols are not scalable so you need you need to deploy a new instance you need to have like a heavy maintenance from the Dow uh or from like a trust uh third parties while uh we want to make this space like a as much as possible uh trustless and so we've been working for the past years uh and a half on like how to solve this and how to sorry how to make it um how to really build like a scalable and safe protocal first thing like you can have

in mind is just like applying the uh the Swiss Cheese model uh like um and to me in fact I think it's like a bit overrated so hot take here don't get me wrong I'm like a huge advocate of of this like uh We've developed like at Mor like some security framework with' like doing like multiple audits internal audits uh back bounties Etc it's just like we think that uh this is missing like the the the the very root of and the cause of all our problems which is like in fact the design part that is okay I need to

keep closure to to here uh which is like the one that is like the most underrated and um and overlooked uh points which is like just having like better uh design principles that will remove like most of like the the bugs that you could introduce during the the development process and this is starting like before writing any lines of code so we have developed like a several princip principles uh to um to to make like a much more uh much scalable and and safe protocols the first one is like just minimize governance um it will like reduce uh reduce like uh governance overhead and operational hovered uh

reduce the attack um Vector um so I think like two um uh the last panels I don't remember exactly was talking about like humpy uh governance attack on govern uh on compound so even on like large Dows you can have like governance attack and um compound is upgradable so in theory it could have like just rug all users so uh the more you reduce governance at the protocol of the better for your users and it increases the predict predictability of uh for all your integrators good example of that are uh of course liity which is like governance test Unis swap where the

governance can only set the the fee and a Moro where the governance can only set the fee and Whit list like new interest interest rate model um no yeah um second point is like really important for us is like uh immutability it's just like um we are here to create like a trustless environment so if Primitives are upgradeable that means like all type of integrators that are working on on on top of your protocol needs to be upgradable if they want to follow every features or uh logic changes that they will apply to your protocol this is basically um an anti pattern uh anti

defi pattern if you if I may uh if your protocol uh is upgradeable and uh so making it immutable will like just forer Innovation on top of it and um like U uh and brings more interop interoperability in the space good example of like what happened is like a upgraded their contract to add like some features and they needed to roll back some of their changes because it was breaking integration which can be super annoying for uh for integrators again good example of that uh liquid Unis swap moru are all immutable smart contract so Builders can build safely on on top of them uh first thir Point sorry

uh third point is like uh risk uh risk isolation so uh trying to separate like the risk management from uh the accounting layer so this is es especially true for uh lending protocols or reaking when whenever you need like some active and dynamic risk management uh this allows like to separate the smart contract risk from the economic risk uh um and if something breaks like it does not affect overs and uh and it reduce like a contagion so good example is like Unis swap if something uh a pool is bad or something bad happen on a pool it does not affect other pools uh same

thing on on Moro if something bad happen on Market um it does not affect other markets so you have like Risk isol isolation good example of that are Milo biotic Mor just put a graph of like um uh symbiotic uh U mow sorry where you have like you can have like different aeres that are like depositing Capital into like different um different networks if one break one network break it only affect aties that have deposited Capital uh into another very very important Point uh we think is like uh minimalism just trying to do as few um as few things as

possible I but doing perfectly um just like when you build your protocol ask yourself like if I introduce this feature will users like um sorry if I remove this feature will users still interact with my protocols if the answer is yes maybe you should just remove that feature from your protocol because it's not it's not core to it and you're just increasing the attack surface uh and the likelihood of like having bugs very good example of this is like UNIS V2 like the just the code is one page it's super straightforward um same thing for mle it's like six uh 600 lines of code so it's super simple and it's super um like

yeah you can read it and try it's easy to to find bugs in it and the the missing features that the one that you have removed and that are not core of your protocol just externalize them if it's still important just like build on your side like uh a protocol on top uh or let just like Builders Builders like what they do best which is like just building on top of your protocol uh good example of that is like in a deex you don't really want maybe to to have like everything in one place like limit orders TW oracles uh whatever uh Landing protocols same thing like you may not want to have like super um super um like Strat complex Strat uh

having like a variable rate fixed rate uh and leverage all in the same place um because it's just like increase and over complex complexify the the protocol good example like again Unis swap you have like B V2 working on on like a COR hooks uh Builders uh like like just building hooks that are can do like oracles Etc on Moro uh we have variable rate but we have like Del in our Pawn that are working on like fixed rates and this is not enshrine at the protocal level this is externalized so yeah just um uh just to to finish on that I'm out of time so um

you don't have to trust me but just like looking uh look on chain look at the hack uh look what protocols are hacked and like um and and and make sure like you understand like um those um those principles thank thanks um thanks for your time thank you very much Marilyn and our next speaker is going to be Heidi Wilder from coinbase so let's say you did everything correctly but through some small bug you still got hacked heid is going to tell us about how to use chain analytics and actually how to use blockchain analytics

and try to find who hacked you and the title is very clever so I'll let her repeat it hey guys can you guys hear me okay awesome well today I get to talk about the lovely topic that jannis just kind of uh mentioned which is what do you do when your protocol gets hacked and suddenly all of your friends are gone usually the immediate question is is well how do you fix your protocol but

the next question is is oh no we have no money we need to do something about that now this presentation is actually kind of fun and by the way this is some information about me while I talk because I only have 10 minutes but this presentation is kind of fun because this is also geared towards improving your security posture as well so all of the tidbits that I'm provid providing to you are also tidbits that you shouldn't just be thinking about your protocol but also how you can maybe better secure yourself down the line so our goal today is to find who the bad guy is and on our agenda we only have three different items those are doing contract analysis funds tracing analysis and ENT or open source intelligence

analysis we're basically playing detective so let's talk about contract analysis now I'm in a room full of auditors right now I'm not going to be giving you guys the whole Spiel of what contract analysis is you guys know that better than me but there's a lot of interesting stuff you can do when looking at attackers who deploy smart contracts on chain particularly TR in terms of tracking funds so look at who's funding that deployer right where is the attacker actually cashing out those things can tell you a lot about who this person might be especially what times that they're transacting at another thing though that you know I know a lot of you think about from time to time as Auditors but we as security researchers look a lot into which is actually looking at four byte analysis right

taking a look at those four byes those functions that these attackers are using and seeing where are they being reused right same thing with storage slots and there's a lot more here and we don't have time for it unfortunately but instead I'm going to spend a lot of time on case studies today because I think within this bit of time it's the best way to use it so we know that uh earlier this year wiir hack wiir X was hacked for about about $240 million and this was due to a multi- exploit uh upgrade involving um a m sorry involving a malicious contract upgrade right now we know the source of funds for the particular techer who was doing that contract upgrade those originated from tornado cach classic but if we were to

do four bite analysis on this particular attacker and their their particular uh initial contract that they deployed we'd see here that they're using the spe specific forbite in that contract and lo and behold if we look one day prior these guys were deploying a contract from a separate address entirely right an address that had nothing to do with this initial attack but using those exact four bytes some of you guys might say oh Heidi well this looks like a very simplistic function like maybe this was reused copy pasted no there were a lot of other examples of how this stuff overlapped now interestingly enough that employer address that deployed that contract on um July 9th so the one that

we think might also be the attackers it actually sent funds to tornado cash that same day so um interesting so maybe the funds came from this testing address and then was sent on to the actual deployer who deployed the malicious contract but we'll get back to that in just a second because we also want to talk about funds tracing analysis now investigations can be hampered by a lot of different things that I would like to call anonymizers so to speak so that that can be mixers like in the case of tornado cach Bridges as well increasingly um as they become more and more complex centralized entities and services as well as new services that come on chain and time and time again I have found that new attackers

like to leverage new Services because it's difficult for investigators to actually Trace through them to figure out where the funds are flowing to it's an obvious one right but there are of course workarounds let's take that Wier X case again right in this case right we know the source of funds originated from tornado cash and if we were to do a very quick analysis using Dune analytics taking a look at all of the different addresses that had both deposited deposited into that 0.1 eth contract and both withdrew around that same time period you'd find something interesting you'd find that this address here that was the address the one that deposited 0.6 eth into it that was the address that deployed that contract on July 9th

the one that we thought was the testing contract and we can see then down the line couple hours later that address that actually conducted the actual hack on wiir X we received then 0.5 eth and actually down the line another address of their received point1 e as well so it's very easy to match up you know the uh deposits and withdrawals from tornado cash in this particular case but it's fuzzy right we can't for 100% sure say that it is indeed the attacker or not but the 4 by analysis is at least a little bit more solid on that front so now let's talk about my favorite section which is the ENT analysis portion whop my bad people don't realize how many Clues they leave off chain so my big you know takeaway

for today should be find any web 3 to web two connections you yourselves have you don't even realize it right any profile picture you reuse and recycle maybe you want to have your profile profile picture recycled on your ens and on your Twitter but maybe you also don't when you're deploying a new contract for one of your projects right nfts obviously are amazing but another thing that a lot of people don't think about is poops poops really tell a lot about who you are so if you collect any of those just be worry of where you're saving those um they're also useful obviously when you're looking into attackers as well um ens handles that's an obvious one but there's also a lot of other data crumbs left behind

and now I'm going to go go into a really fun case study if I can click next um that involves a defi protocol um that paid out a very small amount of test funds to a developer to use and this was back in February of this year this poor unfortunate defi protocol got wrecked um last month due to a private key compromise the key suspect is dprk unfortunately okay we've kind of heard this story over and over again so what gives well there are a couple of things that went on with this Dev that were really suspicious so first off this Dev really liked to use profanity addresses I'm not hating on

profanity here it was just an interesting Insight because it made me realize wait a second it was easy to find some of his other addresses he then sent some of those test plans that he had receed from that D5 protocol to another address and that address connected to several others then when you looked at those several others you'd find that he had created several different ens handles over the years some of which actually linked to Dow exploits that happened one of them for example was yam Finance back in 20120 So this dude's been around for a really long time and then the icing on the cake was that he had sent some funds directly to an oact address um that was

related to dprk and it was not an exchange address it was address that it only ever received 20 transactions so this thing like it was dunzo like at this point it was clear that this poor protocol had at least one person working for them that was dprk which was pretty concerning so we've got some takeaways here though from today so first and foremost attackers are early adopters so it makes sense to always keep learning you you too should also keep learning because I'm sure you'll find some good Alpha there too attackers are very fun to learn from there are numerous free tools online that exist some of which that I showcased today in the presentation because I wanted you know I I wanted to use stuff that everyone has

access to and last but certainly not least um is you want to combine all of your research methods so in a lot of the case studies that I used a lot of a lot of the an analytics kind of overlapped right funds tracking ENT as well as contract analysis and with that uh thank you and uh yeah [Applause] thank you Heidi and our next speaker is Kirk from Sigma Prime you need a pointer no I last oh who's GNA tell us about brid security so we do have

is this is this yours whatever e we good to go lovely all right very last

Talk of the day welcome everyone uh hope there's still a little bit of room left in your brains for a little bit more information uh what I'm going to be doing today is common vulnerabilities and bridges now there's a lot and a lot of bridges in the D5 world and having reviewed I I don't know how many countless Bridges uh I'm coming here to give you some advice on what not to do so who are we uh I work for Sigma Prime uh we're a blockchain security firm uh we've done a lot of bridges extensive extensive uh decentralized technology all up and down the chain uh we also run Lighthouse that is one of the consensus layer clients for ethereum but I'm not going to spend too much time on us or me security assessments manager because

it's only a short talk and I want to give you get into Bridges so uh I hope everyone here knows how a bridge works but this is very very brief what we do firstly chain a someone needs to transfer some funds into the bridge you get a message and potentially an arbitrary number of tokens depending on the bridge something happens offchain their oracles or or trusted nodes or whatever's doing it they record all your onchain transactions on chain a they're going to submit some sort of trusted route onto chain B then as you as a user you make a proof on chain B and you can therefore submit it and receive your tokens on the other side of the bridge some interesting points to note on this is that most bridges that we review are

going to be lock release Bridges which means chain a when you transfer your tokens in they all get stored in the bridge means huge Target for attackers because we're can have tens of millions hundreds of millions of dollars stored up in this one contract now the most simple attack is a replay attack uh once you execute a message on chain B you should only be able to do this once almost everyone does this but they use a nons uh that's the most simple replay protection what it does is when you execute your message the nons is registered and you can't execute that message again now however some people like to take really big nonsense un 256 and cast them into un 32s to use them inside of a Merkel tree

and then they register this un uh 256 as used however this is going to have a lot of issues because if you take you in 256 and then you only use 32 B uh bits of that in a proof there's a whole bunch of extra 200 plus bits that anac can play around around with uh this happened to a client and that's why I said don't cast them into the tree because they did this and it opened them up to a replay attack where an attacker could have claimed all of the funds in the bridge luckily it was a white hack and they reported to a bug Bounty and they'll paid out I think a million dollars or something for this bug so be very careful with your nonces make sure you cast them properly and finally re-entrancy uh this has been

important with nonces non's uh State modification you want to use some reentrancy to prevent the nonsense being reused before um they're recorded lovely this this is a bit of a uh an interesting topic Bridges with unrestricted ear external calls it's a security user experience tradeoff that unfortunately way too many people take the user experience trade-off and I'm going to tell you why that's a bad idea and I want you to not use unrestricted external calls so this little code snippet uh the the function marked unsafe don't put unsafe function in your live smart contracts that's also a bad idea but this unsafe function it takes the message and it will send uh arbitrary data uh it looks like I've

actually copied it wrong it's meant to use a low-level call and it'll call an arbitrary address with anything and what happens when you make an arbitrary call to a contract from your bridge is you can call any token address any arc2 token address you want so if you're making an unrestricted uh call and someone decides oh I I want to transfer X number of RV tokens to my address they could do so and this actually happens on the Arbitron Bridge today I went and checked ether scan before I got here and there's someone doing ex exactly this it's a unrestricted call from Arbitron it allows you to call any dress with any call data and what they've done is every time uh an amount of tokens gets stuck in the Arbitron bridge in a contract

where there's not really meant to be tokens they'll drain those tokens immediately using uh arbitrary unrestricted exteral calls now the other reason I'm bringing this up is a lot of contracts have only bridge if you have an only Bridge modifier and anyone's allowed to call this well you're going to be in a world of hurt when someone deliberately calls uh your contract with an unrestricted call nice next call the joys of erc20 all right erc20 tokens can be a pain I'm sure we've all seen the uh weird C20 GitHub page being audited there's so many painful uh erc20 token implementations

that aren't genuine not going to dive into those you should all know those by now but when we do something like this from a bridge we have a batch of tokens they're really vulnerable to a denial of service attack where you can stop someone's Ms being executed by just having one malicious token in there that causes a revert and sometimes it doesn't even have to be a malicious token if if one of the tokens is paused they happens to be one blacklisted address in there then the enti message can't execute because you've got one dodgy token now decimals decimals are a pain there's some really interesting cases where you have tokens on one chain tokens on another chain and they have different decimals in each chain usdc

and usdt are both examples of this they have six decimal places on thether Main net and 18 everywhere else in the world so what happened uh I've noticed one Bridge did have this some time ago they patched it before they went live luckily but they just assume that the decimals were same on both Sid of the bridge so if your transfers tokens one way then transfering back you would have increased your balance by a factor of 10 12 last thing uh unbounded looping if you've got a number of tokens make sure you cap it if you have INF number of tokens uses too much gas you break following gas gas into resources now return uh return gas bombs are Absol in the ass when you're calling unrestricted uh functions and even

restricted if they have returned data because the main issue with this is when you have a batch of transactions often you're uh executing as an oracle you're executing the entire messages for everyone rather than letting them execute their own messages and if one malicious contract in there decides to use a return gas bomb they can drain the entire uh transaction gas balance and their noral transactions will fail so be very careful when you call any external address to make sure they can't give you a return gas pump or just spend the gas themselves now calculating fees can be quite challenging uh some l2s have fees for the gas and then they also have

their extra L1 fees as well so when you're calculating fees you have to be really careful to get it exactly right otherwise someone's going to make transactions that spend way more gas than they're paying for and then you will lose out as the bridge operator then finally the last one is quite an interesting one uh ZK evm chains often have a limited number of instructions that can be called so what that means is say the add instruction you want to add to to numbers that can only be called say thousand times over an entire block even or a transaction sometimes depending on the Chain now if you make any external call they can use up all 10,000 of these ad instructions and therefore the next message in the

batch can't be executed you could do that from any external call whether it's tokens you're a malicious token whether you can be the receiver anyone in a batch can consume all of your ZK resources lovely now trusted Roots I I did mention this a little bit earlier but be very careful of your indexes these can often be used as nonsense uh don't cost them and and make sure they're accurate there's an interesting case in open Ze lens implantation that if you provide an index bigger than the size of the tree they'll just kind of ignore that uh they will only use the index a number of bits for the same length as your proof so if your proof is

uh 10 elements long they'll only read the first 10 bits of your index and the remaining bits can be whatever you want this is a good way to apply some replay attacks then next up we have hashing if you ever have any data in your message that is not hashed and verified it can be changed uh this happens a lot when people add new fields at the end and they're not thinking they don't include it in the message hash these sorts of things and then all of a sudden you have fields in manipulable uh if these are token addresses or amounts or anything like that then someone's going to steal all your funds now lastly this one's kind of a challenging one uh it's consensus and I mentioned before that we needed to get a trusted route from chain a onto chain B

and how to do that is around complicated one a lot of people use multi- sigs they use some sort of Byzantine fault tolerance n ofm but all of these are vulnerable to something that Heidi was just referring to and that is offchain and multi- attack uh we've seen the Ronin Bridge we've seen a number of other Bridges where people have gone offchain directly to the multi and create their own fake trusted routs or do any sort of upgrade and we'll steal your entire Bridge deposit cool this is quick summary if you want to take a further all of this we'll hopefully work to you as a checklist if you can remember what I've said here today and this is the end welcome you

made it all the way [Applause] through thank you very much Kirk so this concludes our session and I'm asked to remind everyone that tomorrow we're starting at 8:30 so tomorrow uh tomorrow morning 8:30 and uh hope you have a wonderful evening I'm Janis from DB and feel free to catch any of our speakers uh for questions right now [Applause] e for