DeFi Security Summit 2026: Pearl Room, Day 1

Transcript

two out of three bigger. Well, you just make your tree bigger. Next slide. And since we're working in a finite field, so everything's done modulo Q, we can have as many as Q branches. Next slide. Now, that leaves a question. Okay, if you have Q branches and you have a big finite field, how is the prover actually going to interpolate that polomial? That's kind of crazy, right? Uh so we need a shortcut to not actually explicitly create this entire tree. uh otherwise it's it's just the exponentials are just crazy. Next slide.

Okay, so here's how we're going to do it. Again, like I said, every node is the sum of its left two children and that propagates upward. You can say in general that a given intermediate node is the sum of all the boolean leaves underneath it. Right? So, and one more slide. So, what does that mean? If you want to know what's the polomial that represents a certain level, then that level, you leave that variable free and you sum up all of the boolean leaves afterwards. That's what you can see right here. Right? So x2 is free and we're only going to sum up all of the blean leaves afterwards. So only these leaves get summed up and we're free to

pick any direction we want to because x2 is not chosen. But x1 is how we arrived at that point. So this sum over here is going to capture only these and then that's going to create the that that's going to actually generate the polomial over here. Uh next slide. So generally the interpolation polomial is what's the p the random path the verifier took so far. Leave the next variable free. Sum of all the boolean leaves using the same polomial.

Next slide. And then that gives us the algorithm. So if you ask whatever your fa favorite AI is, hey, give me the sum check protool, it's going to spit this out. But what does it actually mean? Well, we start with our polomial. Give me the polomial that interpolates the children. I'm just going to check that the left two children add up to the sum. Then I'm going to pick a random path. Then I'm going to repeat. Okay, I've taken this random path. I'm going to leave this variable free and I'm going to sum up over the rest of them. That's going to give me the next interpolating polomial. I'm going to check do the left two children add up to the note I was just at. Okay, I'm going to pick a random path again until we get to the leaves as and then we're done.

So that is how the sum check protocol works and that's the geometric interpretation of what the AI tells you. All right. Two minutes. So, okay. What do we do now? Just wait. Okay. Thank you for the talk Mr.

Next on the we have Rdra Pradat Singh and he's talking about SA EIP 7702 reference implementation One sec. Yeah.

Okay. Hi everyone. Good morning. So first of all uh this talk was originally going to be presented by Arada from Certic but unfortunately he's not able to make it so I'm replacing him. So myself Rud Prattab Singh and I lead triage at CERTC. So this talk is going to be some of the design observation that we made on chain and uh some of the uh things that we noticed about EIP72. So next slide please.

So let's first understand how u EIP702 works. So a user signs a pupil in a type four transaction namely chain ID delegate and announce and anybody can carry forward. So basically anybody can send it onchain or the user himself and once it's confirmed onchain the account points to a delegate contract that the user provided and uh the contract that he uh delegated to would run under the context of the EOA. Next slide please. So at launch winter mule uh noticed that 97% uh of the delegated account pointed toward the same sweeper contracts and we looked into the current uh uh statistics

where uh we looked into top 15 delegate addresses and we found out that it constituted uh for 8.51 million accounts and that are u marked as me uh fishing. So that does not mean that all of these accounts are uh by themselves uh uh malicious but it is more like some of these accounts are owned by the attacker themselves as throwaway accounts. Next slide please. So how does uh these accounts end up there? So there are two major reason. First the attacker compromise the private key of the victim. Secondly uh the victim fall part of our fishing campaign. At the same time, a simple 7702 contract, sorry, uh

delegate contract has three major observation. First, it does not have any any allow list. Second, a valid signature can do anything in the account. And the last that the signature travels through across the multiple delegations. Next slide, please. Yeah. So once we delegate, there are eight powers that a delegate can hold. First the entry point who can make the account act. Secondly, what happens to the incoming value? Third, what hap uh what uh outgoing uh calls does the delegate makes and what call data it carries. Last fourth uh what a signature can authorize and does it have a replay

protection or not and gas storage owners upgrade and some side effects. Next slide please. So let's now look at a simple sweeper contract. So I hope you can see this. So it is very straightforward contract where we have a destination address and initialize function and a receipt. So if you look into the initialize function, there is no uh protection on there. So once uh like anybody can initialize it and if you uh if you can read out the receive function, it basically transfer whatever ETH that is uh being sent in the same transaction to the destination address.

Next slide please. a sweeper waits for what arrives. So we ran our uh test suite against these sweeper contracts and we found out across four properties that we tested two of them passed while two fail. Namely the the one that passed was a third party cannot move the existing fund that the account hold and uh the front running does not move fund. But the two properties that broke were that any incoming aid that were forwarded uh after the delegation automatically moves forward to the attacker and if you try to rescue and send additional funds it goes to the attacker rather than staying in the account itself. Next slide

please. Five ways uh a transaction get replayed. So the top three one are pretty widely known but the two uh that are delegates and time are not widely known and adopted. So uh we are going to understand it uh better. But for the context a signature can uh does not automatically get cancelled out if we uh we delegate to a new address. Meaning that if we sign some request on a previous delegation, it carries forward. And the next one is time. The thing about time is that if let's suppose that we have an allow list and if we signs a request that is not valid right now but does not mean that it would not be valid

in the future delegation. It might be a case where uh in the future the signature becomes valid. Next slide please. The next thing is revoking does not means that it clears the code. Suppose that you uh delegate to a buggy delegate which writes a owner uh variable in the storage. When a normal user tries to revoke uh the delegation, he assumes that the uh the storage is automatically cleared. But that's not the case. We need to uh whenever we are redellegating, we need to make sure that we clear the storage ourselves. Uh next slide please. Two doors, one gate. So basically we are moving forward to a

design uh suggestion that we are making. So there are two ways a transaction reaches onchain. One a user signs a transaction himself or he can give the signature like a signed request to another user who can submit onchain to save gas. But all of these like in in either of these cases it goes through the gate. We are going to zoom in in the g uh the gate itself in the next slides. But you need to understand in any In any of these cases we are making sure we we are making uh a check against the policy in the gate itself. Next slide please. Now let's understand the gate. So there are two levels. Uh first is the contract

that we are uh interacting with and the function that we uh we are calling is it in an allow list or not and who is the recipient and the sender and whether they are approved in the allow list or not. If in any cases something breaks it uh the transaction does not go through and if uh everything seems to be good it leaves it. But there here are three u major observation. First only the owner can make changes to the policy. Second when we change like make changes to the policy it takes up to 48 hours. Last removing anything take effect at once.

So for example, if you're trying to remove some recipient from the list, it takes uh the effect takes immediately. Next slide, please. Signature can't travel. So we talked about in the previous slide about two major problems that are generally overlooked. So how do we come up uh across those? So first when we say when when I mentioned that uh when we sign a request, it travels through the delegation. So we want to make sure that when whenever we are signing a request we embed uh a delegation information within the request itself so that the delegation know who it was meant to be.

Next across time we need to p we need to maintain a policy where we are uh checking against the request whether this policy that uh the user signed was meant to meant for it or not. And after re uh revocation we are wiping all the policies that uh that was uh in there at that time. Next slide please. There are some caveats to uh this design we I'm going to discuss two of them. First as I mentioned that whenever we we are making a new changes we have to wait for 48 hours at least. Secondly, for any new configuration that we are making, we have to go and add it ourselves and there are few others as mentioned. Next

slide please. So we ran some of the tests against um 35 uh of the testes and across that we also implemented 21 deliberate bugs that uh we wanted to catch and our test suite actually caught 21 out of 21. that then we ran we we fogged the network and ran it against the those buggy implementation that we saw and it got four out of five properties that were failing meaning like the ETH that was uh supposed to be transferred were automatically being transferred to the attacker account. So the properties were failing. Next slide please.

So we have open sourced uh all of the uh things that we discussed the design implementation the attack suite and the test cases in our uh in the repo that is under the certic dev repo. So that's it for me. Thank you so much. Thanks for the talking.

Next up on we have Raj Kumar and Sabenu 77 talking about web security monitoring system internal from chain data to incident response. Over to you. Hey, hey, check check.

Hey, hey, check. Check check. Hey, hey, >> hello. Hello. Hello. Hello. Check. Hey. Hey. Hey. What? Hey. Check. Check. Check. Hello. Check. Check. Check. One. Two.

Let's check. Hey, hey, hey, hey. This one is just check. Hello. Okay. Hello everyone. I hope you all

doing great. I am Raj Kumar and I'm a security researcher at Settora. The topic of the talk today is uh monitoring system internals from onchain data to uh incident response and I will be giving this talk with my co-sp speaker. >> Hey uh myself Pul I work as a senior threat researcher for Zcaler and my area of interest in web3 is cryptography and mainly the monitoring systems. Over to you Raj. So now Raj is going to explain you what are all the topics we are going to cover in this talk.

>> Great. So what we have done is we have divided this talk into multiple parts. First we will explain why we need monitoring. Second one is system architecture behind the monitoring system and third one and fourth one is about the detection rules and the incident response and then we will take the case study of Wasabi and then of course references and the Q&A right so why we need monitoring so basically if you are doing let's say testing we are doing formal verification and uh we are doing uh manual audits uh so why we need a monitoring system so there is al always a possibility that uh in production are trust can you know assumption can break and audits manual audits are also time bound. So there

there is a a possibility that there might be a critical in a protocol that can cause basically huge loss uh to the protocol and basically we what we would like is we would like to detect that uh uh risk and take action against uh uh against that risk. So yeah you can take it from here. >> Okay. So now I'm going to explain uh what's the monitoring system architecture looks like. So we'll start from the left side. So first we take uh input uh data you can say input logs from uh two sources. First is block data that is the transaction which have already been happened. Second is the pending transactions most of the times from the uh memp pools. Then after

getting that uh data we need to decode and enrich it because the data is in the hex format and making a detection rule on a hex hex format is not uh so much useful. After decoding and enriching data we then passse it into elkstack. So basically elkstack is uh elkstack is a system where we can uh store the uh data in a decoded form and then uh store store the data in decoded form uh index it search it and write the detection rules. So on basis of the data which we uh stored in extra we can make detection rule on top of that and on the basis of the detection rules or the cluster of the detection rules we can uh take uh

response or action actionable items based on the based on that. So uh let's talk about block data and mele data and how they are different and why we need to treat them differently when you're talking about the monitoring. The first thing is uh confirm transactions that is block data. So when we are retrieving block data that means confirm transactions from a node it will give us a receipt locks because the transaction is already been completed that means we will get all the events that has been emitted the state change which occurred due to the that transaction. On the other hand we have pending transaction mostly uh mele transaction. So basically mele transactions are not executed it.

So we won't get the receipt logs that is we won't get the emitted events what what will be the state change what will be the new state. So in order to uh get the same we need to uh simulate the uh pending transaction which we have it from the meool. So uh while uh the mele is important because mele gives us time that the data has been decoded and

enriched. So we get this in a beautiful JSON format. Here we can see okay the chain ID is one. This is the block hash. This is the transaction hash. Log index is seven. RO event is ro granted. And uh similarly the mode is observed and policy version is version 12. So after getting uh so till now we got the data we grab the data we enriched and decoded change it into the JSON format. So what next? The next is basically uh injecting that data uh uh indexing it and uh making it prepare so that we can write detection rule on the same and take uh different actions. So for that we have used elkstack. Uh there

are other uh other sources too which can be used for example splunk Microsoft sentinel or google sec ops that depends on the depends on protocol to protocol. So after getting the logs in JSON format what we do we you lo we you use log stash. So basically log stash what it do it take the JSON format and then rectify uh the rectify the data on the basis of what is required for example we are getting a data in JSON format and we don't want certain type of fields or maybe certain types of fields are sensitive we can directly remove it so basically what log stash do it take the data uh rectify it

change it in into a unified schema and then forward it to Elastic stack. So in elastic stack what happen? The same data get stored and index index because uh uh yeah index. So for the fast search. So uh once the data gets stored and indexed in elastic search uh then we will move forward to the kibbana. So Kibbana is basically a graphical user interface which help us in order to get logs from the elastic search that will be a lifetime uh live uh live data historical data uh yeah anything. So it gibbana gives us a good uh control to any security analyst who is sitting there and wants to uh maybe monitor the events

or write the detection rule based on same. So uh now next uh we have so till now we have uh got the data uh encoded it enriched it and then feed it into the elkstack. So now Raj will explain what are detection rules and how to make it. So yeah uh what are detection rules and uh basically to detect everything uh like every type of risk internal or the external we need some rules uh based on the threat uh uh that uh we were thinking about and based on the detection rules we can also write the uh incident response for that and uh the

approach for detriting the detection rule is like pretty simple. We can think about uh detection rules in three questions. The first one is what can go wrong? Let's say if there is a trust assumption that we were making it can break in the production and if there is a security property or intended behavior but that can fail in the you know other runtime and the second question it is like what we will observe basically the detection rule and uh when we will uh basically use that and third one is what action can it still help if we have the detection rule but if we don't have the actions that we can take then there is no uh nowhere to write the detection rule Now uh for writing the detection rule we

can use the systematic approach which is we can take help from the threat model and uh for writing the threat model we can uh use a poor a model which is uh we have to map everything in the protocol like uh assets and the invariance assets uh like everything that can like assets that we have and the invariance that can break in the uh let's say production And second one is actors and the roles. Uh let's say we have a role abuse etc. Uh so we have to detect that as well. And third one is the internal assumptions or external assumptions uh that can uh break in the future let's say liquidations or the keepers etc. And fourth one is the

attack vectors. And uh we we have to think about uh think about every attack vectors. And according to that we have to write the detection rules. And for every detection rules we have to write the incident response. And we can divide risk into internal and the externals. For internals like uh accounting bugs, role abuse etc. And uh externals are mostly the assumptions that we are making. Let's say DEX, Oracle failure or compromised signers. Next. Yeah, here is a example of the vault theft. Let's say we have a vault. A user can deposit the asset and means that's there. And what we can do to detect that uh there is a theft of the funds. Basically we

can use the invariant which is the if if there is a drop in the share uh price it means that something is wrong with the protocol and uh if uh we detect this it means we have to take the action as well which is the incident response. Yeah. Next part is about the incident response. So if we have the detection rules but we don't have a book for the actions you know like what we will do uh when something goes wrong then there is no main to write the you know detection rule. So we can take uh action according to the so basically we can take action according to the protocols and uh uh the rule that we have written right and it can be like uh alerting the team pausing

the protocol or disabling a strategy and uh basically impro including the you know circuit breaker etc. So yeah and uh next there is example of wasabi hack which we'll uh we'll explain. Uh so let's talk about the Wasabi. Uh it's a real uh life uh example that why we need monitoring and threat detection. So what happened with W wasabi that g they got exploited for 5 millions over three chains uh Ethereum base and blast. So the attack vector was pretty simple. It was a developer key leak. So this key had authority of granting admin rights to anyone changing moving the funds of vaults to any uh other strategies and

third is basically updating the pool contract. So basically what happened the once uh the malicious actor got the private key first he uh granted the admin access to one of his uh contracts. After that he changed he moved the fund of uh vaults by changing the strategy and next what he has done he upgraded the pool contract in order to move funds from the same. So uh the next question is how and at what point we could have detected it. So the first point is basically admin grant. uh if an admin access has been given to a contract or

to a address which is not in the white list that's a first red flag. Next is basically uh strategies. I guess in most of the firms the strategy which will be uh deployed for any vault will go through governance and have certain kind of approvals. So if a vault is redirected to any strategy which is not uh whitelisted or which is not approved that's still a red flag. The next next is basically uh the third step that is uh the pool contract has been uh update uh upgraded. So when we have to upgrade a contract in any uh protocol we go through multiple security audits other things and certain of approval. So if a pool uh contract is been up upgraded uh

to a unknown contract that itself a malicious. So uh in terms of Wasabi the first reported signal was at 746 admin was granted at 748 and the first wall drain was 749. So as we can see there is a 1 minute difference between admin grant and first wall drain. That's enough in order to have a successful uh or we can say a good incident response. Also incident response in this case depends on many factor uh depends on what kind of if they have a multiple role separation that is a role is been granted for pausing the contract and etc.

So I guess uh okay uh so thank you. That's was the talk by me and Raj. These are the references which I have used for the talk and yeah we are open to any questions. Thank you. >> Thank you so much everyone for listening the talk. >> Thank you. >> Okay. Okay. >> Yeah yeah please. Okay, that depends on the blast radius.

For example, that depends on protocol to protocol and blast radius. For example, in this case, if a vault, if you get to know, okay, the admin right have been transferred and there will be effect on the vault. So, in that case, it will be good to just pause the vault and keep the protocol as uh you know working instead. >> It's automated. Exactly. because uh we don't have much time to response uh when we detect something right because everything moves so fast so there is I don't think there will be a good option to you know human intervention and taking some kind of uh like authorities and all so everything should be >> yeah right >> exactly these are pre-made rules which we made and we test it out in de dev

environment so everything is automated yeah >> basically for every detection rule we will have uh incident response guideline so that we can take action. >> Yeah, sure. >> Okay. So, yeah, good question. So, basically uh most of the hacks goes through private block builders. So it's but if any go with the public meool what we can do we can uh have the transaction from the meool we can simulate it and on the basis of the results if it's harming the protocol if it's causing some uh damage we can frontend that transaction >> okay all right so this is not for the

whole Ethereum chain That depends on protocol to protocol. So if any protocol wants to opt in for the monitoring thing so we can have data of there and we have a log retention policy. We can apply for 30 days, 60 days, 90 days based on the requirement. >> No, that's I can we can use S3 bucket of it's pretty cheap, right? we'll be able to uh so what what we can do for remediate it we can only store 7 days of data in elk and after that if the data is 7 days old we can directly store that in S3 S3 is pretty cheap so in order to query the historical data we can directly go to the S3 and in order to get the live data or anything we can

just directly get it from the EL right thank you yeah Yeah, >> exactly. So basically elk don't work there is an option is elk we can basically how elk

store the data they store data in shards. So basically when we store data there will be multiple charts of the tables which we call index and that gets stored at certain values. So in elk we can also have multiple instance of uh for example elk and multiple data base uh what we can say uh basically multiple backup databases. So what happened for example there are four databases 1 2 3 4 and there are four elkstances which people are accessing right if one database goes down the other will be able to give them the uh data so basically we that depends on it's very flexible we can make multiple uh like we can make it centralized we can make it decentralized

okay okay I guess uh thank you thank you so Thank you for the talk. Next up we have on stage with the topic smart contract security. >> Yes. >> Over to you. We wanted a space of two to 128. We end

up with 2 to the 39. That's uh way smaller. Way way way smaller. Do the math. It's It's actually worse than that because for some reason there's a multiplication in the the code that multiplies the high bits and the low bits of a number. If you do that, you'll get collisions because uh imagine you have the number bytes uh two and four that has the same output that if you multiply the high and low bits of four and two, which is kind of obvious when I say like that, but it was missed for some reason. So after some math, you can see this leaves you with 37 bits of randomness. 37 bits of randomness is

awful. By the way, I I do want to mention something about the code base. I already have the slide so why not? >> I'm going to explain briefly the the rules. You can join online on menty if you are in the room or online. Just if you're in the room please add DSS to your name at the beginning so I know who is in the room and who is not. Um because there will be a prize and I cannot give it to you obviously if you're online. So I called it a big quiz but we don't have too much time so it's going to be only four rounds of solidity questions. Um, and each of them is actually taken from a real finding we had in some chain security audits. So, it's going to be slightly simplified and also anonymized, but it's real stuff we

found. Um, for the people on stage, so the first to answer with a reason is going to raise their hands. And by reason, I mean you should at least at least try to explain what's going on in your mind. Um, because there will be always like four possibilities and I don't want you to guess randomly, right? So please just explain give your thoughts then we can discuss. Um so online you will get like 30 seconds or 45 seconds per question to to answer in the audience as well and there will be a prize for one of you and a price for one of you as well. Um I hope everyone is online and uh let's get started. So we have a bunch of >> Okay. Yeah, that makes sense.

Okay. So, I think you guys should be uh should be on. Great. Um, yep. This is not what I was trying to do. Okay. Um, let's let's do it quickly. So, um, the first round is this uh this one. So, you have a revenue sharing protocol and it lets anyone register as a recipient. So, it could be an EOA, a multi-IG or a contract. And this registration has this optional notification hook and a faint notification must never block registration. Um, this is part of the specs.

Um, yeah. Okay. Let's just I'm going to give you 30 more seconds. [laughter] [gasps] Okay, good. Uh, no, you can go ahead. The question changed. It did. Yeah. I'm sorry. Okay. Yeah, [snorts] the first round is not not going to work. Um, so I'm sorry you didn't have enough time, but please

take a look right now and try to think about the question and we just do the second one. Um, yeah. Do you guys have an idea? Also, you can come on this side if you want because it's maybe easier to read on the on the screen. [clears throat] Yeah. Yeah, that's good. That's good.

So anything? Okay, I'm sure it will go better for the next rounds if you guys have enough time to to look at it. Um, so the answer was actually C and the transaction reverts. Um, in the 30 seconds you had on the quiz without reading the question, no one answered C. So, um, no one was lucky enough, I guess. Um, but let's let's go into it a bit. Um so what you should remember when you look at external high level solidity calls is that it's just not a call it's a pipeline. So you have multiple steps right the first one is that to you evaluate the arguments then there's this external code size check um so you might see where where this is

going there's the encoding of the call data and then there's the call itself and then you decode whatever you received from the call right and the try catch actually covers only one of those parts it covers only the call so all the other blocks they're doing in your frame so if there's a revert at this point it's just going to bubble up but it's not going to get caught by the try catch Um and that means in this situation that if you register plain EOA with no code, it would just revert during the external code size check. So answer D had something about solidity 0810. And some of you might remember that since 0810, the external code size check can actually be bypassed and skipped by the compiler, but only if you expect a

return value. So let's say you had you add um a boolean boolean return to your interface then the external size check will be will be skipped but even then the try catch only covers the call and the decoding would fail because you expect a return value but you don't get one right so in both cases it will revert and um let's say that the EOA has an EIP7702 delegation um can you guys think about what might happen this time if you have an idea So basically um it would work because the EIP772 it basically acts as it as if

the EOA has code. So the external code size check um would work. So let's move to the second question. But there's a takeaway from this round. It's that basically try catch it protects the call but it doesn't protect the calling process. So you should be really careful when you use it. Um and this time hopefully you will get enough time to uh to answer the quiz. Uh but this is the second round. So you have this governance proxy which keeps pending changing um changes in a storage array. And the change can only be executed once its time lock has passed.

And the queue right now um has like three changes X Y and Z in this order. Um X has passed its time lock but Z hasn't. And then a caller submits execute change for X for X. So they want to they want to execute X. The question is for which change is um execute call. So the sub function, right? And you still cannot answer. [gasps] Okay. Um well, please do it in your in your heads. Uh the online quiz is kind of dead, but I'm sure we'll get the the third round. So, we'll just give you give you a few seconds to think about it.

I would say also we were supposed to have some like really nice quiz music but I guess there's no sound on the presentation so it might be a bit awkward but [laughter] think about it in your mind. Play it in your mind like some game show stressful music. Um yeah. Um, so if the contestants has a have an idea, please. No idea. >> Same. No, sorry. [laughter] >> So, it's again it's it's again a big of a of a trick question, right? Because otherwise it's not fun. Um, and the answer is actually that Z would be would be called um not X, right?

And this is because if you look at it um so change is a storage variable and storage variables they point at their pointers they point at the at the slot in storage right um that means that in this case if you look at it step by step so at first in change you put x right x because this is what what you want to call um in slot zero and then you have y and z the time check is done at this point so So it's going to pass because X is in your change variable storage variable.

And then you do a swap. So you just uh basically point Z to the storage variable. And this is when um the execution is done. So basically you didn't change yourself the variable, but um because it's it's a pointer, Z is the one that's going to be called. Um, so basically that's the takeaway is that always a storage variable is a pointer. Its content can change even if you don't want it to change. So you should always be mindful of that. Um, and maybe use a memory variable or something like this.

That would make your life slightly easier. Um, and let's move on to the round three. And I swear this time you will get some time to participate. So the round three is is this. So you have smart wallets. um and they share reusable scripts which are deployed with create 2. So the registry first examines the deterministic address to check if we should redeploy or not. Um so you have like those three branches and we just check on the code hash see if there's already what we want there or something there. And the question is someone sends one way to the address first. Um and so what happens?

Question three. Okay, this time you guess we get some time to do it. So please look at your devices. This Okay. So, um we have two people who found the the answer. Um [laughter]

[gasps] um so a lot of people had um actually most people answered for C. It deploys um as expected. But yeah, I'm sorry this is not the case because otherwise it's not fun, right? Um you guys might have an idea of what >> what did it say? It's not C. >> It is not C. It is not C. Yeah. Um, so I mean I guess you you you were thinking about C because everything looks fine. >> Yeah. Yeah. For me that was the one of the use cases of this uh of the create 2 is to be able to prefound an address.

But I guess I missed something. >> Um so it's not really about create 2, it's more about this specific cut snippet. And um in particular you have like three cases, right? Um so those three branches and the three cases are that so the address was never touched and in this case the code hash would be zero and then the deploy would work because you would end up in this branch. Um the second case is that so it's already been deployed it has the code hash you expect and then you just reuse it. So that's the second branch. And the third one is that actually when you send one way to an address, the code hash changes from zero to the hash of the empty value. Um and that's because

an account was created and you have really those two separate states between no code no account and no code with an account. Um so if you do such checks, just be mindful that code hash zero doesn't necessarily mean um that it has no code only. It could be something else. And that's the takeaway. So cod hash zero means no account, but it's not the only uh cod hash that means no code. There are multiple of them. Um so good job to the two person who who found the answer. Um and let's move on to the last round. So you have this uh zero knowledge rollup uh settlement contract and it's running on this L2 with a 10 million block limit. So every roll of block appends exactly one hash to block

hashes and nothing else you can assume everything is relatively cheap in terms of gas everything else in the function and also that block hashes is called at the start of each transaction and the question is after roughly how many rollup blocks does post block stop fitting in the L2 block. Um so there are your possible answers and please um answer on your devices. Yes.

Okay, so most people answer D um which is that it would always fit because p which is 01 and I'm sorry but this is not correct um because again otherwise it wouldn't be fun, right? And for the three other answers, actually most people voted for two, which is the correct one. Um, so it's about 5,000 blocks. Um, maybe you guys have an idea of why. I mean, you know, sorry, you answer D. Yeah. I mean, it's it's what you would expect, right? Um, because obviously it looks uh it looks pretty right, but when you look at it a bit closer, you have three facts. The

first one is that block hashes is in storage. Um, and storage is expensive to read from, right? But your viable hashes is in memory. So when you do this call, basically you always move everything from storage to memory. And by everything I mean the n um the n like hashes which were already in there. So if you do the the maths um you have block hashes in storage, you have your hashes in memory and each load is 2,100 g. So end times at every call. So that means that the more hashes Welcome back. So the speaker for the

next session couldn't arrive and here we have a video about DSS 2025 and the topic is how do you even write secure code anyways. So let's have a look at it. Thank you. The speaker for the session couldn't arrive. So here we're going to play a video of last year DSS about the deputy security summit and the video is going

to play here and the topic is how do you even write secure code anyways. Um there is some technical glitches.

We'll be like on soon >> [music]

[music] [music]

[music] >> on. N >> [music]

>> I love you. >> [music] [music] [music]

>> Heat. Heat. N. [music] [music] >> [music] >> Hey,

hey, hey. >> [music] [music] >> getting home.

You [music] [music] know, hey [music] Hey, [music]

baby. N feeling. Baby.

>> [music] >> Hello. Um, next up we have the talk on why blockchain security has failed. Single points of failure by K. Welcome This one is not me. There we go. Here we are. Okay. So, why has blockchain security failed? If those of you were in Peter Jagrinsk's talk this morning, we can all agree blockchain security is currently failing. We're not doing enough. There are way too many hacks.

There are billion dollar hacks. There are hundred million dollar hacks every week. And it's it's becoming a serious problem for our industry that we need to fix. And so the point of this talk is to explain to you why this problem is occurring and how they are fixing it. And some of the inspiration for my talks has come from what banks actually do in practice, which is a lot of risk management. I know we all kind of hate that word and it sounds gross, but it has a lot of practical effects and we can definitely learn from it. So the problem is arising because defenders only need to break one component of your system. They get to see every single component. They can map it all out. They find the weakest point which is often a

single point of failure and then they break that one single point and they have your protocol. So the job is a lot harder for the defenders than it is for the attackers because we have to secure every single component whereas attackers get it easy and bug bounty hunters if you're a bug bounty hunter get it easy. You just need to find one hole and you can get your way in. So what are these holes? The most obvious hole and the biggest hole that pops up is a single point of failure. So a single point of failure is anywhere in this whole system. Uh I'm I'm talking abstract here. This doesn't need to be a literal piece of code. This could be one trusted signer. This could be um your smart contracts. This could be your choice of blockchain if you pick a

centralized or one with weak security. It could be any part of your smart contract. It could be the oracles like are you getting your price feeds. So you don't need to think of this as like oh this code function is a single point of failure. You need to think abstractly. You need to work out what is your system doing and then what can one of these things do. This is what I want you all doing. I want you all mapping out the whole system. I want you all there like this connects to this connects to this. This is the entire abstract system. And once we map it through threat model, risk analysis, work out what the problems are. And when we find a single point of failure or a high-risisk component, there's three things we can

do. The absolute best we can do is diversify redundancy. Think of this as like a multi-IG. You don't just have one person signing. You got three. You got multiple people signing and you got to hit two or more of them to break the system. Then we can do bound. So bound is limiting it with something like a rate limit or something along those lines that you can slow the flow. You can you can lower the impact. Maybe rather than having all your funds in one wallet, you split it into a couple. So okay, if they break this one, they now only get $1 billion rather than $6 billion. [snorts] Um and then the last one is harden, which is add everything else you can just to make it as hard as you can for them. Like cause the

attacker as much pain as you can do. Okay, so we're going to run through a few different parts of this stack. Uh, this one when I wrote this was absolutely the hot topic because everyone was talking about how AI is breaking cryptography, how AI is the most powerful thing in mathematics. Um, and one of my funnest topics that I've spent some time on is ECDSA is can we use uh AI to actually break the algebra underlying elliptic curves. Right now the answer is no. But if we could, this is a single point of failure. This is something that would give you access to pretty much every single wallet on Ethereum. It would also break most of the internet. It would break TLS. It would break a lot of other things. Um,

but it is a single point of failure. Uh, and there's different ways to break it. And you don't actually just have to break the cryptography itself. You can do dumb things like using a very weak private key generation. And if you only make a 32bit rather than a 250 bit uh private key, then attackers can brute force it. 32 bits is about four billion and a computer can do that in a couple minutes. So uh what you really need to do is diversify.

Don't have one single protocol you're lying on. Don't rely just on the elliptic curve discrete logarithm problem. Don't rely just on ECDSA. if you can change them up and have two protocols in parallel and notice there's an and there not an or you have to make sure both of them are secure. Uh there's a few protocols out there like NIA that support uh SECP curves. They support EDC curves and they support a few other hashing [snorts] mechanisms, but they're put together in ORS. You can have private keys on each of them, which actually increases the single points of failures because if you break ED, it happens to have a flaw in it. That's one path in if you break SECP, that's a different path in. And either of these

paths can actually uh act as a full break. So, we need the and, not the or. Um, but I do understand that no one actually is implementing this right now, although I want them all to, but if you're doing these onchain, it's pretty gas expensive. Cryptography is one of the more gas expensive parts. And so, if you can't diversify, if you really can't, and I mean like you think about it and you cannot, then the option is to harden, which is do as much as you can to make sure you're securing this single point of failure. Put everything you can in there.

Okay, consensus clients. Consensus clients is one that I think Ethereum actually kind of does well. Uh I put this as as a pro to see what can happen when we're doing things right. uh if you have under one-third of validators, if one of the uh consensus clients is buggy, it has bad uh fork choice rules, it doesn't do balance checks and user transactions or whatever it happens, the other 2/3 plus of the network will reject it. They're going to say, "No, you're wrong. Ignore it." Uh if you have one your consensus client that gets into that 1/3 to 2/3, the network still continues on. Uh but what happens is you just lose finality and then the really

bad case is is what happens if one client is over twothirds of the network then if we have a bug uh and that bug is exploited on chain by some malicious users we end up finalizing and we're in a world of hurt all the exchanges around the world are like finalized yeah that's good block we'll start paying out the money and then it it's very hard to unroll it when you get to that point we we can't just do the Dow hack where we just go ah send the money back to us We want it all. No. And this this did happen. Someone was attacking Nethermine, which only had 8% of the network at the time. And okay, the Nethermine nodes went down and that was a bit annoying for some people, but the rest of the Ethereum consensus managed uh Ethereum execution and

consensus managed to keep ticking on. We still have finality and the network was safe. Now look look I I I am kind of drumming up how good this is because if those of you who do know the stats uh know that GU had at a similar time almost 80% of the network. So if we did have a bug in the GU execution client, this would cause fine um finality bugs and this would have been bad for everyone. But yeah, this is this is what the defense is. We we just need to tidy it up a little bit more. make sure that each of the clients gets down below that 1/3 threshold and then we have this perfect situation where none of the clients are acting as a single point of failure. Um that being said they they

all ran the same hash functions. They all ran the same elliptic curve algorithm. So there's plenty of other single points of failures in there if you want to get into them but the core node and the software itself uh is not it it'd be a spec problem at this stage rather than an implementation problem. Cool. It also allows us to do some other fun things as well. So there's benefits of having multiple clients and multiple protocols and that's things like differential fuzzings. So you get other security benefits that are auxiliary. Um and you could also do adversarial spec tests where um if every every pass bug from any of these clients can be fed into all of the

clients and that way you you get the compounding security benefits. Okay, next up, this is a pretty interesting one. So on uh Ethereum or Solidity specifically, any of the EVM chains, we will see that there is essentially two compilers. Um but as a smart pro uh smart contract protocol, if you're writing a Viper, you only get a choice of one compiler. This becomes a very interesting single point of failure because if there are any bugs in your compiler then there's absolutely nothing you could do uh and your protocol is going to be vulnerable to those bugs.

Now uh this did happen and this caused a $70 million hack. It happened because of the non-reentrant check was being optimized out by the Viper compiler and so that meant anyone who was relying on this non-reentrant check is therefore vulnerable to the bug. Uh there were a bunch of other protocols not just curve who are vulnerable to it but Curve is by far and away the biggest uh protocol using Viper as a language and that's why Curve got hacked by this. Um so how do we fix it? Again, uh this is a tough one because people don't normally have multiple compilers. So, it makes the versifier problem a lot challenging uh because Viper doesn't

necessarily run through the Slitter compiler. It's got its own compiler. So, this is where we need to get into the harden and the bounds as much as we can. So, pin and track your compiler versions. Make sure you have pinned uh your version control. Uh then testing the actual deployed bite code is another way to check up on your compilers. So if what they had done is compiled the compo code uh put it into test net and then run their tests on the test net they would have found this bug. Um but they didn't because everyone just assumed that the compiler was valid and they hadn't done uh thorough enough risk management.

Uh yeah bound don't put everything under one version. Uh some potential ways to get around this diversified problem would be to have multiple versions of your code. uh run it under multiple different versions of the compiler and see if the behavior is different across these. And so it's it's not quite as powerful as diversify, but it is testing different things. Okay, admins, admin keys and upgrading. Oh, a little bit of a touchy topic at the moment, I think. [laughter] I don't know if you guys may following the news.

No, you all you all have. So, we know where this is leading, but what happens uh as an upgrade key. So smart contracts, we often claim that these are decentralized. They're neutral. But if all of these come under one proxy key, >> uh that is if you have any proxy in your smart contract and there is a key that can update the proxy, that is a single point of failure. They can take complete control over the smart contract, all of the funds in it and everything. And it is one of the biggest single points of failure that happens in pretty much all of the protocols that we review because everyone wants to have this upgradability function. Uh Ethereum

deliberately didn't add upgradability because they wanted it to be immutable. They wanted the code out there to not be able to change. Uh but that's not really that practical for a long-term commercial engagement where you build your product over the time. You want to add more features. And so how do we actually deal with these admin keys? Well, we could uh just just be hacked. Uh [laughter] that's one way to do it. But no, it is it's a single point of failure. Um, and you guys may not have know this one, but they um, yeah, now they they didn't when they

upgraded, they didn't upgrade properly securing the initialization function. So, someone hit the initialization function with a new trusted route which was their own and therefore they had control over the entire protocol. Uh, single point of failure. This one again is a bound. if you want to have the capability to upgrade, it's it's really doesn't make sense to have diversifiers or redundant. So, um these are all things that we recommend in every review and I think every security engineer in the in this room is going to nod along and they're not going to be surprised. But things like timeouts, stage stage rollouts, uh make sure when you do the upgrade process as well that you are actually doing like a mainet

fork and you were testing the code on the forked code. Uh it's amazing how many people will come to us with migration scripts and we're like um yeah but but do you have actual tests to run this on the mainet fork or are you just kind of hoping it works after you've written it and they're like oh no no no it'll work and then of course it it doesn't work. Um that's what we can do. So keys signing and bridges. So a five of nine threshold is great. This is exactly what I've been talking about. Diversify. Don't have a single point of failure. Okay, if if you want to get the keys to our bridge, you need to have five keys out of nine and you have to have many signers. Uh the but the threshold only actually exists if every

key is separate is a separate single point. Uh it does not count if you put five of the nine keys on a single device that is held by one company because then it becomes a single point of failure again. And so this is what I really want to get across to you that you have to think abstractly. You can't just look at the protocol code and be like great this is a multi-IG it's got five of nine. You actually have to analyze the architecture see what they're doing not just in the code but the broader system run some risk analysis and be like hey uh no you've you've actually got five of your keys on the same device. You've made a single point of failure again.

That's not great. Uh by bit is also another very interesting example of this. They had a single point of failure that is a little bit different too. They had a multi-IG. They were doing everything right. They're like, "Okay, uh we have this multi-IG. We all have to sit down. We have to review the code. We have to make sure it's good before we transfer anything from our cold wallet." But what they didn't consider as a single point of failure was the front end of the safe software itself. So, it showed all of their signers when all of them sat there, they all looked at the same front-end UI, and it said, "This is a valid transaction doing exactly what you want it to do." But what the front end was doing is switching the backend uh transaction. So, it was different to

the one that was being displayed. All of the signers didn't check their device that that matches the front end. And so, when they hit sign, the 1.6 $1.4 billion went went over to the hackers. And even more recently, what happened again? So, diving a little bit into this Binance one, it was a single point of failure. They didn't have just a single private key sitting on machine. No, they had some MCP uh set up in the background where they had a bunch of different servers. And what the single point of failure here was that it was one path to approve this MCP to sign everything. So, one of the DevOps had their laptops uh breached and then they went in and the

attackers using that proposed a malicious transaction to the MCP and the MCP went great this is a good this is a genuine real transaction. Um and so that interface there was the single point of failure because it is one point that allows the attacker to do whatever they want and unfortunately the pains of EIP7702 mean that you can exploit bugs like this extremely quickly. Uh so one transaction allowed them to drain the entire contract. So what did we do in in some of these cases? They they'd already diversified.

they did have independent signers but have independent stacks, have independent ways of reviewing this code. Uh add second paths as well. Uh what you need to do is add limits, delays, monitorings. So once the transaction is proposed, have someone else come in there and prove it as well and harden your wallets, harden your infrastructure, everything along those lines. Okay, lastly, we're running out of time here, so I'm going to breeze through this one, but oracles are absolutely another single point of failure. Even if you are using an oracle like chain link, that doesn't mean which has a distributed set of nodes, that doesn't mean that it is not a single point of failure. If someone can adjust the config, an admin

can come in and switch out your Oracle to something malicious. These things have happened. Uh, Oracle's been manipulated, configs have been changed, hacks have occurred. um oracles all need to use a median not a mean and infrastructure needs to make sure that we have multiple front ends so we don't end up like by bit and bound and harden them too. So what I want to leave you with uh is what is a single point of failure. Do not get too caught up in the specifics of the code. Keep it abstract.

Think of it high level. Brainstorm. Understand your system. And when you understand the system, you can tell where the risks are and then you can build a threat model and then you can understand how to solve these problems. Beautiful. And considering the state of our industry, look, just make yourself as hard to hack as possible and they're going to go somewhere else because they're easier targets. [applause] >> Um, thank you for the interesting session. So, next up on we have on stage a talk about can AI really audit your smart contract. To talk about it, we have on stage Muhammad Mansuri. Over to

you. Hello. Yeah, all good. So, um, so I'm a pointer. How do we use that? >> Okay, thank you. Um, so I'm Ahmed Mansuri from DOB. So I'm a security research researcher at DOP. Uh at DOB we are a security company in web3 field and we do security audits. So that's why we are doing a research on uh how uh security how AI can do security audits.

So basically the main question is that uh would you ship your code and deploy it on chain if it was only audited by AI? This is the main question. So how how many people are working on security in the room? So there's there's quite some people right working. Okay. Sorry about that but it's okay. So uh in order to answer this question uh so what we did actually is that in one line what we did is that we hid our audits

and then we ask the to audit our the codes that we have audited before and generate reports and see how well they do. Right? So this is in one line what we are going to to show you the results of uh it's going by itself. I'm not touching anything here. Should I be good?

>> Okay. Reset my timer please as well. [laughter] [snorts] Okay, we'll try with that. [panting] Good. Okay.

So again we what we are doing here is to answer the question whether we can rely on AI to audit code and by this means that audit code to deploy without having human people auditing this code and as a security company who have done a lot of audits and we have a lot of clients that we have engaged in security assessments of their protocols. We have a lot of uh data sets and what we wanted to do is to check this by uh uh by hiding our reports from the AI and ask it to audit itself this code at that version we audited and see how well it does. Uh so uh here's how the uh experiment works in in specifically. So uh we chose eight

of our uh past uh client audits and uh what we did is basically uh ask the eye to audit these different agents different models. We'll talk about this and from the reports they generate we will try to first match them with the reports to see how many of these are existing in our reports and for the one who doesn't match we will try to triage that by first doing some uh AI filtering and for anything that looks serious we're going to do manual revision and take a decision on it um please so from these eight eight audits uh there's six audits are in solid solidity with different code sizes uh one in move si chain and one in talk for chain uh

with different sizes different types of different periods of engagement in total there's 61 bucks in these uh reports and there's different amount of time spent on these to find them uh now let let me tell you that we have done this several times so we've done this entire experiments on much more than eight audits in June and this is the recent one we did lately in the last month. So we're going to present the recent one and also compare it to previously. How was AI in in four months, five months from now was doing please.

These are the agents we are trying to test. So the ones in blue here are ones that we are internally building and developing and using in our internal procedures. Uh we start from different we do different tiers. So we start from let's say a an AI that is basically just a plain model basically just a simple prompt that uh asks the model to to audit this code and with the flagship version and all the way to audit factories which is like a very well uh you know pipelines of of using AI to to uh to find bugs and there's like things in between like light skills only using skills with lightweights with light

workload. So to make this fast also there's like the public tools that are existing now which basically relies on uh running security tools and then triaging the results with LLM. And there's the audit factories. We have two agents there. One is more lightweight and the one zos is the more you know uh heavy metal stuff that we really takes a lot of token consumption but does everything from fuzzing to to understanding the protocol threat modeling and everything to to find to find the bugs. Uh let's jump directly to the results.

Do you have any can anyone give some expectation? What do they think? So we're going to measure the recall how much the percentage of uh uh bugs that are in our reports that a will >> half. >> Okay, let's see. So basically it's 45% if we took the average. So for every two bugs in our report, serious bugs, medium and above, there's a 50% chance that almost 50% chance that on average an agent would find it. If we combine the results from all agents together, they're going to go

up to 73. Now what's interesting is you can see from June it was much much less almost half of this results from June. So basically in four months the LMS went to a better version where increased this results. Uh but interestingly the uh the agents found all the critical bugs. So critical sorry high is wrong here. So only critical bugs. Uh this is only the result on uh the solidity codes. Now if we go over the entire eight uh eight eight projects with Suie and Don in them then it's going to be a bit bit less. Uh but interesting from this slide we can see that the higher critical bugs more severe

bugs are most more likely to be found uh than medium bugs. In total for the eight eight audits it's still 50%. So like 29 bugs were found out of the 61 that we have in our reports. Uh now if we look at the results per per per per per uh per per uh agent so zos which is like the heavy metal agent we have done the best but it also has like a highest token consumption around 7 750 like seven times or even more like 10 times more and here I'm measuring the token consumption in dollar cost so that you can get a relative value of this uh we have Argus at 55% our Hermes is at 38

create plain models as like doing a bit less than that. Now the other question that you might want to ask is basically okay this is how much agents I'm finding from the bugs we have in the reports but what about the bugs that you don't have in the reports did they find new bugs that you missed well yes they did so they are also finding bugs that we missed uh out of if we took the 10 most severe findings in their reports and we analyze them 4.5 of these 10 on average are ones that we have in our report and they reported there's on average 1.1 bug that is basically a new bug that we missed so

of medium and above and the others that are reporting basically are uh less severe bugs. So out of >> [snorts] >> uh these eight uh projects there was 16 bugs medium and above that we have missed. Now none of these are critical there's two of them are high and 14 as as medium. Okay. Now one disclaimer here to say that all these uh projects that we run the audits on the experiments on are old projects. At that time we were not using AI. So all these results does not rely on the fact that currently we use AI. So basically the results will be much much different when you are actually

integrating AI yourself when you are doing security as a human. So this is comparing pure human review to pure AI review. Now this is a very important slide also for people interested in u uh seeing the difference what did change from June to until this point with the new uh just to give you a reference in June we were talking about opus 4.1 4.8 8 for for Antropic and GPT 5.1 I think in June. Right now we're talking about Opus 5.5 and Soul 6.1 uh and also like the Fable and Astra

which are the flagships. Um here in the plane models, this is very interesting here that you can see that the plane models in the current versions now Astra and Fable are doing much better than our previous agents the the full agents we have in June. So you have much better performance if you just have a single prompt with Astra and Fable now than whatever tool you were using in June, right? Uh also uh another thing you can notice that previously uh we would having like double performance of plane models. Our agents

were doing double of what pre the plane models were doing. Now it's it's a bit less than double. So the gap is closing but you still have better performance when you actually build pipelines over the agents and uh one uh biggest improvement we have seen is the languages that are not uh were very common in June like they are learning more trained more on languages like move and tone than in June. So they are being trained on these new less common and famous languages.

So um to answer the question so can AI audit your smart contracts? Now based on these results what I would conclude is no not on their own. Now if you are interested in in doing some sort of a bug bounty uh well it's very interesting the the AI can do a lot of good stuff and find bugs because in bug bounties what you are interested in is basically finding a bug in a protocol. Right? It doesn't have to be a specific protocol. It doesn't have to be any specific bug.

Any severe bug would give you money. Now, audits, you don't you specifically want to find bugs in this report and all bugs that you can find. So, your goal is to provide a security assessment of this protocol and like say this is a good posture for the protocol to be deployed. So that's why relying only on AI agents is not it's not yet something that is a good decision yet. But of course we as security auditors we are using AI in our pipelines to do security audits which are increasing a lot our efficiency increasing a lot our uh coverage and the the overall performance.

Uh so thank you and uh this is the results for now and I'm happy to take questions. [applause] >> Uh I have some time so I'll take some questions. Right. That that's a great question. Um so um basically in the pipelines you have uh you guide the LLM to look where to look and where to focus more. Uh this is what

what you get best improvement. Of course, you also add tools uh but you also seen that uh uh like pipelines that basically use tools and then triage them. But our like heavy metal uh pipelines is basically more than that which is make makes uh people redirect makes redirect on specific parts of the code and do multiple rounds and do different uh uh instructions of how to look at this. So do you want to look for what types of bug? So some of them based on like invariance that you infer from the protocol and then ask the protocol to to to check. Now what is u the recent models and flagship models is trying to do is basically do this in themselves.

So they try to uh uh do some sub aents create some sub aents and give them these instructions. But you still better uh as a human auditor with very high skills and experience in uh in auditing uh giving these instructions than AI yet. Now they might be more efficient in implementing these instructions but you're still better giving these instruction as a human that's why you get you get this uh this uh you know uh better performance. >> Yes please. You were talking about your own.

How do you ensure that both in terms of models report and maybe even >> Yeah. So, uh this is also a very good question and we do our best but we don't have a guarantee. uh what we do is basically of course we remove all the materials that can give him access directly like the git history and stuff like that. Uh but like making sure that the training data have not seen our bug is something that is uh not very uh not very easy to do. Uh now one suspect we have that the additional performance and

better performance we had is because we have trained we have did the experiment before. So they train with the new models they've seen this then they are getting better performance that's that that might be a limitation and there is and then we have to assess it this is an ongoing work some of these are not finished yet we are doing more and more we're going to continue doing it and please subscribe to the do to check our uh blog post to see uh how we going to give more and more results about this and yeah it's it's a limitation we don't we don't know that they are not trained on these bugs not all of these are public uh reports So also that's a good thing. Not all of them but some of them.

Yes. >> What what type of false positive you're talking about? >> Yes. Now false positive could be like invalid bugs or bugs that are flagged as severe but they are not they are likely because there's there's like a line that's hard to put there. Uh the line would be um some sometimes they will find a bug but when you assess it okay it's fine but it's has like very hard assumptions. You are assuming that the admin have done this mistake for that bug to appear and this is unlikely to happen. So it's not uh that severe or like it's an information. So if these

are counted as false positive, it's very hard to put this line to count the false positive. But if we're talking about invalid issues like hallucinations or like assuming things that are not correct about the code, then this is very very low and we have also done benchmarking of our benchmarking. So basically created hallucinations bugs and try to see how much they can agree that they are bugs or something like that. So we have done experiments on this. We couldn't prevent everything but in terms of invalid bugs they are unlikely to to report invalid bugs but yeahformational bugs and stuff like that that they are exaggerating. This is uh this is uh possible exact numbers are not in here. We can put some some stuff

online uh soon when we have more experiments. Okay. Thank you a lot. [applause] >> Thank you for coming. Next on the stage we have George Kak talking about certified orchestrating S4 certification. Over to you. Thank you. One one two. Yep. Okay.

Thank you very much. Okay, perfect. Hi everyone. So today we're going to be talking about orchestrating swarms um specifically for certifications. That was the use case I took for this, but I think this can be applied actually quite a bit across the board for security work and it's quite quite um appropriate especially nowadays. Yes. So a little uh butterfly certify ASKI butterfly.

So a little bit about me. Uh my name is George. I work with consensus diligence. Uh in particular I work quite a bit kind of in my own spare time outside of audits and security work on standards and frameworks. Some of those are BSC standards uh EA the uh old school OG Ethereum uh enterprise alliance and uh most recently as well Seal Frameworks though haven't done as much work there as I have with the other two. Uh special shout out to BSSC. They've recently released a uh second version of their smart contract security standard which is uh actually going to be a big target of my presentation today. And as part of that release, they've also added audit

guidelines for each control in the standards, which was actually very very important for my work. And then in some of the uh other time that I uh that I have, I also work quite a bit on AI security internally diligence. Uh most recently, I've been working a lot on vulnerability mining to actually well mine vulnerabilities using agents and swarms and AI and whatnot. So why standards? Um this is not a very popular I would say topic in our industry sadly but it is actually quite crucial. If we take a look at some of the other missionritical industries out there in the world, we'll see that all of them have very strict standards that um their suppliers such as their software

suppliers or they themselves have to abide by um across aviation, energy, healthcare, banking, you know, they all have actually fairly strict standards and uh this allows them to have common solutions to common problems. This allows them to have common interfaces to share expertise that they can build upon uh amongst their employees or partners. It's it's very much u a very useful thing within Ethereum. We don't really have all that much success across standards in general. We do of course have a lot of success across technical standards. You know, uh we can talk about the actual very infrastructure level and kind of foundation level standards. You know, network standards.

You know, Ethereum itself is a specification. it is a standard. Uh but we can talk a little bit more higher level like even token standards like ERC20 tremendously successful um technical standards for common you know use cases and communication for tokens but anything that has that has has to do with processes we really really aren't very good there and as we can see lately a lot of processes are the places where things get exploited and in fact just recently BSSC also released a uh transaction life cycle uh framework and standard that potentially could have helped with a lot of the signature based exploits we've we've seen lately.

Uh speaking about standards, we can we of course have to talk about certification as that is the uh the the main topic here. Um it's very quite it's very simple. So for us we can define it as just a an attistation to standards compliance. Uh it is very much uh based on the reputation of the certifier I would say. So how much you trust a certification depends on how much you trust the certifier. So reputation is very important here. And in fact this is going to be a big problem for doing stuff like certifying things with agents because of course reputation is quite finicky there.

For web 3 specifically uh certifications standards are very hard to scale and make work. kind of as I mentioned earlier some of the challenges there are and that's also shared with other mission critical industries is it's very expensive to do these certifications you need expertise you need very very uh knowledgeable people and their time is simply expensive they simply do not like to do that and oftentimes all of this is helped by frankly the government it's helped by uh government bodies that subsidize these things and enforce standards and frameworks to be uh to be done within certain companies and industries. Uh we of course are famously not very good with governments. Uh you

know lately we have a lot of institutions coming into the space. So maybe that's going to change but that certainly has been the case up until very very recently and people simply aren't excited about performing standards for certifications for processes across the board. And I understand it even I am not really into doing all that. that I like to contribute to them certainly get a lot of value out of it but actually applying them is not so fun. Agents however don't have a concept of fun that like to do menial work. They thrive with instructions especially when they're within an isolated kind of independent control and that is precisely what certifications are. And of course we can parallelize our agents and we can do

hundreds of thousands of hours within just a few hours if you have enough compute to do that. So it could be quite quite interesting. Uh very quickly I want to touch uh a little bit about swarms um because of course that's what we're going to be talking about today. So if we think of an agent as a singular item, a swarm is a plural of that. That's it's really quite simple. Uh, of course it's not actually as simple as that. Nowadays, many agents that we use are actually swarms underneath them. For example, our favorite clot code and codecs are actually systems of agents. So, they're technically swarms and they are incredibly valuable and actually very useful and we'll see how just how much

they kick ass later. Uh, they are what's called a form of a central orchestrator type of an agent or or a swarm. There are a bunch of others and I'd like to give a special shout out specifically to Langraph. It's something that we're going to look at later in the presentation, but that is what allows us to actually create much more controlled swarms where we can provide proper instructions and actually control what the agents do and do not do. Um, all of this is of course very very new. All of these swarm technologies are really just coming up this year, maybe a little bit last year. Uh so it's it's all bound to change soon enough of course but the point is there are trade-offs to the swarm architecture that you're going to pick.

So certifications are many isolated tasks to be checked and controlled together and swarms are many agents that like to do these tasks. Clearly there is some fit. So I decided to see if it's actually going to work. What I did was a series of runs roughly 44 45 runs. There's the 45th one on my laptop right now. Um, across a couple of different targets, a couple different standards, and a couple different modes. So, I picked very, very simple standards. I picked ERC20 actually, and we'll uh we'll see just how simple it can be or how complex it can get. And I picked a subsection of BSSC uh smart contract security standard, its

development section, and then I picked its full standard for the sake of well, seeing how it's going to work with a bigger corpus. Uh, as far as the modes go, I actually picked uh just a singular agent. Again, it's a bit incorrect because I use cloud code and codeex and that's technically a swarm underneath, but for all intents and purposes, it was very, very simple. I picked sub agents, so several cloud code models and agents working together through a loose orchestration of MD files and prompts. And I actually built something out more custom uh certify which ends up using u line graph custom VMs u controlled environments with actually a little bit of a human review there which could be a

little bit of a cheat code but we'll see why that's critical for certifications. And as for targets, I used unis swap v2 very small, very battle tested um codebase and morph blue. Uh likewise, small enough and a battle tested codebase. So as far as the actual results, I'm happy to say that swarm that I've made with certify actually did test kind of the best. It actually only tested as good as clot code itself without any additional prompts. Uh it's kind of a testament to just how powerful these native agents are. Um but as far as actual verifiability, which is critical

for certifications, we'll see that I tested even better. Um an important note is I've tried different models for my swarm and it is a just a night and day difference. In fact, uh swarms with set uh tested the worst across the board. As far as the actual rubric here, uh I cheated a little bit and I used agents as well to verify my reports. I used Fable to go through all the reports together in a blind test and to go through a rubric of verifiability uh correctness and if there is actual argument that follows these reports and stuff like that.

as far as the first mode goes. So the first uh single agent one prompt. Yeah, that really did incredibly well. It is a very efficient way to actually uh certify things. It's a very efficient way to review things. Um I think a lot of the uh people here in the room who use a lot of custom agents to perform uh vulnerability mining and auditing can attest to just the sheer power of these native kind of rappers like cloud code and codecs that are very very very good. Uh it's it scored the best across the board and uh it was incredibly cheap.

Now 30 cents is a little bit of an outlier. I used uh codeex and that one uh 61 on a low thinking. Uh I mean it was still a good model still scored very well and it was very very cheap. The problem was that when you give a very simple prompt and it was indeed literally find the certification in your folder find the target and apply it. It was one sentence. The output of course looked very very different uh for each each run. So the output was different. oftentimes they actually disagreed with each other because they interpreted the certifications differently um because the certifications often didn't have actual guidelines uh sometimes they were too lenient. They

rated something as passible and sometimes they rated as not passable which of course you kind of need to actually have a decision there. uh they interestingly did not follow directions or some quite strict things like actually editing the targets like the code like the unis swap code and whatnot. They ended up sometimes editing it as well as of course agents sometimes go rogue and um they really sucked up with evidence. They didn't have enough evidence around their decisions and that of course is a really big problem for certifications. But all in all, it's very good.

Uh the second mode where I've uh tried to kind of parallelize things myself and do it all through loosely orchestration, loose orchestration of MD files. In fact, I had something like 17MD files that gave guidelines and said how to create verifier agents and how to do this and that and kind of create a hierarchy of sub agents. That was a catastrophe. That did not work well whatsoever. And I think again people who uh have experience with reviewing agents will know that if you if you go about it wrong, it can go really wrong. And that's exactly what happened here. So the good stuff, yeah, the workflows worked. They were good. They were

getting in the right way and they were feeding the right context and it was fairly structured and indeed it was parallel. In fact, it was so parallel that I ended up running something like 40 agents at the same time at one point. The bad thing is uh that was 40 agents times the initial context times token cost and I ended up ballooning my token cost to hundreds of dollars for each run and that ended up going on for hours and hours and hours. Now if I had infinite token compute I guess this could have ended up working at the some point but the problem is that it is just incredibly inefficient. And if you think about it, if you had just a few people and if you had a 100 controls to go through, would you rather have two people go through all 100 controls or

would you ra would you rather have 100 people go through two controls each? And the answer is actually quite obvious. You would take the first one. Uh because you would need to have 100 different people in the second case go through the same context, the same target every time. It's just inefficient. So it makes sense why this works like that in the agent world too. Um and indeed it was quite bad. Another really bad thing here that happened was that once there was a failure at any one layer, it cascaded across the board. Uh there was a specific instance with a DNS failure. It was a tooling error, but regardless that cascaded across all the sub agents underneath it, the verifiers, the rereppers, and it just it was not a

good time. So certainly something to think about. In fact, just recently, Enthropic put out research and put out an article saying begging really people to stop using sub agents for a lot of the work that a single agent could do. So I took both of those learnings and I sat a little bit with my VIP coding agent personnel and we came up with a certify which is a land graphbased uh swarm meaning it actually orchestrates in a very direct manner and controls what agents can and cannot do connected with an actual uh little Python script a program that didn't let agents to actually write the report themselves but

picked out from the agents output and wrote the report. Um, I only settled on two agents this time. I mean, I did sometimes run a few instances of that in parallel, but really I only had two agents, a producer and a reviewer. I had a custom VM that would actually be running tooling and um like fuzzers and like static analyzers that would produce very determined deterministic, excuse me, output. And all in all, it worked into something like this. Uh yeah, as I mentioned, agents only proposed reviews and the actual code was what decided whether or not this is going to make it into the report. Uh an important thing here is that certifications are not just

a report. Certification is a lot more and with agents, it is very easy to um not actually have any of that work to be done and to kind of hallucinate the answer. So one of the things you could have is you could have a report and you could even have evidence with that report but it doesn't necessarily mean the agent went through that review. So how I did about went about this is I had some visibility for all processes. I had some verification checks like hash files uh or hashes of files that were were checked. Audit trails to make sure that agents actually read it. Had canaries where I placed incorrect or things that should trip up the agents um certifications in the code to see if

that actually showed up. And then finally I actually had the human in the loop to attest. And how I did that was for every verdict of every control, I provided a certain amount of metadata that has to come with a verdict so that somebody else could go along and certify that. And that could be a human, could be not necessarily human. In my case, I did a little bit of a UI here where I had an actual evidence kind of portal where a human could come in and verify this. And the idea here is that maybe it's not agents that need to verify and test everything. Maybe it's still humans, but agents and swarms can help us get that information quickly. In any case, it ranked as best as the the best agent. Uh, but it also had all the

evidence alongside with it with the reports, with the um tooling and with everything that goes alongside it. Um, so yeah, be very very careful uh creating uh swarms because of course they can spiral out of control. And uh note that in the future you might be creating swarms for other swarms. So specifically in the case with certifications, we might be creating certifications for other agents to kind of have that reputation network of code. Um that's it.

>> Thank you for the talk. We have questions and we'll be back by 12:30. The next session will be at 12:30. Thank you. Hello.

So next on stage we have Shvin John talking about guarding the guard engineering a denied by default policy. How about you? I hope now you can hear me. Okay,

better. So, uh what I was saying? So, every safe can install a guard and that is one of the best defense contracts out there for a safe at the same time that is one of the most dangerous contract because it can basically refuse any transaction even. So, the case and any transaction which is being executed is checked by a guard. Who checks the transaction which removes a guard? Is it the owners? Is it something else? And that is the paradox we are trying to figure out for the next few minutes.

So be want to make sure that everyone understands how a safe works. So there is a set of owners usually n of m uh is the configuration and n signers has to sign for a transaction to be executed and I usually uh mention it as the front door for the safe. Then we have the modules who have its own configuration. It has its own logic and that is basically the side door. Now to protect these two doors we have the guard which basically can be considered as the bouncer for the safe from uh safe 1.3.0 we have the transaction guard and from uh save 1.5.0 we have also the module guard.

So these are the three guards which we built uh over the last year and basically the guardrail is just a deny for a delegate call transactions. Then we have the fiducia which is some all list as well as the cosigner and then we have the holy grail of guards which is the policy engine. So as an analogy you can think that guardrail is just a single tool let's say a screwdriver. Fiducia is like the Swiss army knife. It can do a lot but not everything. And then we have the policy engine which is a toolbox for a developer and the limits are just the imagination of the developer.

So there are two ways through which we can use the policy engine. The first one is fail open and the second one is the fail close. So what are those? So fail open is when you only deny certain transaction in the policy engine and the rest is allowed and the fail closed is when any transaction which you want to be executed is approved specifically and then the rest is denied by default. And based on the coloring you can see that I align a bit to more towards on the fail close because this provides the highest amount of security for a safe.

So before we move forward how a transaction moves through safe let's look at that. So if it's a normal transaction the owner signs it then the safe uh goes through the execution through the exact transaction. The policy guard checks if that is an allowed policy or within the allowed policy or not and then the execution is allowed. Same goes for the module. If uh based on the logic of the module if the transaction is allowed then it goes through the safe then it goes to the guard and the policy guard checks if any policies allows these module then the execution is allowed.

How do we select each transaction? And how do we select each policies is based on something we called as the access selector. Right now it is based on three things. Two selector and the operation. Two is the target address where the transaction is being called. Selector is the function which we are going to call and the op is the operation whether it is called or it'll get called. There are some zero bytes which we have reserved for future developments. So how do we select the policies based on this access selector. So let's say that we have a USDC transfer to say X uh YZ account. So we look at the token address the selector that is transfer

and the operation that is called and then we execute that transaction if there is a policy for that. If not we fall back to the fallback policy which may allow or may not allow based on its own particular logic and even and if these two policies are not allowing this transaction then the access is denied. So policies are basically small contracts. So there are like gated policies like allow policy, deny policy and one time allow policies. Shape of the call is another big factor that is whether it is a transfer call, whether it's an approve or it is something else.

Then we have the extra approval uh policies like cosigner policies or increased threshold policy and one of the best things uh is safet policies which we will talk further and of all these things uh there are sometimes batch transaction which is kn uh which safe is known for and that is where we use the multiscent policy which basically distributes it to its own particular policies. uh let's say that multi-end policies have multiple approve and transfer then it goes to the shape of the call policies. So let's look at the safet as a policy. So why this is important especially in the context of pulse engine is that pulse engine is much more static onchain it's much more

rigid and that is by design it is not a bug and this is where safet comes in and safet allows the flexibility which uh the policy engine requires. So how the safet works is mainly depending on three factors or three parts. The first one is the sentinel which basically checks the transaction which needs to be executed whether it is malicious or not whether it should be allowed or not. If there is a unanimous approve then it goes to the validators which does a frost at a stationation we use frost threshold signature scheme. And once that attestation is um received we can use that same attestation in the guard which is within the policy engine as a policy.

We call that as a safet policy. So let's look at an example. So you have a treasury which you own and you usually do a USDC transfer or a stable coin transfer and by human mistake or you were lazy at that day or something else happened you approved a transaction which was malicious and you didn't know that until the safet uh uh or the policy engine guard caught it. So there are two uh different scenarios here. One you allowed a transaction which was not supposed to be allowed and that gets executed which can basically drain your wallet and the another one is with the policy engine and that basically caught

it and you were saved by the dream. So now until now we looked at how the guard can actually save you. Now we also want to look at how the guard can hurt you because that is one important step we need to consider. So first thing is that you installed a guard which was only on the transaction side of things not on the module side of things. So basically you open uh you have a bouncer on the front gate but not on the uh side gate. So you need to make sure that when you install a guard you need to install it both on the transaction path as well as on the module path. Then the second one is not on the most dangerous side but also a a bit on the annoying side is uh on the configuration part. So before

you install the guard and install the policy engine guard you need to also configure it uh and you need to configure based on all the transaction which you do and if you do that that's much more easier when you install the guard those transactions are already allowed and the rest of it is denied. If not, it's a bit annoying. Not the worst case scenario. It's just that you need to now configure it uh and wait for the delay. So, how does changing the rule happens? You request a configuration, you need to wait for a delay. This is the public and the uh slow period where you as an owner can take action if it's not a um required configuration or if it is a malicious configuration and things like

that. Once the delay passes, you have a certain window which uh you can um implement or apply this configuration and why this certain window is there is because so that you added a uh configuration and the uh delay happened and now you wait for another year for that uh application to be uh configured. So this is why we have this expiry added and once this uh application is done within this expiry period the uh policies alive on the uh confir uh policies alive on the policy engine. So where uh what you have to look at it here is that that when you do a uh when

you uh apply a configuration uh you can have that particular delay period where you can basically remove this uh configuration if it is let's say a malicious one or if it is something non-intended or the circumstance has changed. But once these policies are alive in safe and through the policy uh engine, it takes a delay for these to be changed. So now what the delay buys? We need to make sure that we understand what it does and what it does not. So first thing is time uh it basically gives you the particular delay period to react. It is visible in public blockchain. So any

change you make it is uh online uh on chain. So you have the time to react to these things and also if let's say that the configuration was the malicious transaction it is not one step draining of account you have more steps you have to wait uh out for these things to happen. Now what is it not promising? So this is uh uh the part where uh you need to focus when in terms of the policy engine what it does and what it does not. So immunity is one thing. If let's say that all the owners are compromised then in that case those owners uh or the malicious owners now can wait out the delay. The second is judgment and this

is based on human judgment. Let's say that you approved a uh configuration after a particular delay and that was a malicious recipient or something like that. This is something which you cannot avoid through ball changing. The third is the rescue. So the guard cannot refuse a transaction. It can only uh let's say that block it for a certain time or certain uh degree. And then uh the most important thing is monitoring. If let's say that you don't monitor your safe uh through these configuration then any uh policy change is basically something which you didn't notice and it can get executed.

So where the checks and the execution diverge in terms of even policy changes. So there are things which we can improve on the pulse engine. Some of these are mentioned in screen. Uh one thing which I want to u stress is about the multisen which uh was I think uh found by storaa itself uh during an audit is that a pre-state within the multis uh cannot uh be checked after the pre uh after the post state. So let's say that you uh in a multiscent change the owners on the first transaction. The rest of the transaction is checked still on the pre-state not on the post state of that owner change which is a known thing which we may uh improve in the future.

So today after you are going uh home uh from this uh talk I want to ask uh these five I want you to ask these five questions to yourself to your own setup. Where does your safe uh feed is it open or is it closed? What are the local paths uh half installed states and things like that? How fast you can change something in your own safe? What joins as a trusted thing uh in your safe and what is actually promised and what is only implied uh in your safe.

So uh we started with the paradox saying that a guard uh is checking its own transaction to be removed. Who checks the guard? And the answer is not let's say a clever transaction or a clever contract. It is basically some habits. Uh one of it is deny by default. So anything which you have been specified gets refused in the safe one policy per call. So that all the rules which you have mentioned is abided by within the safe. And the last one is any change in the configuration it is public and it is loud. So anything which you haven't

configured you get the time to change it. You you get the time to react to it and that is the monitoring ability. All the code which I have spoken today uh is audited and it is public. I would love you to take a part and uh get back to me with some feedbacks. And to conclude, I want to say that a guard you can quietly loosen is not a guard. Thank you. Thank you.

Next we have Namir as a speaker on the topic beyond the EVM. What auditing near taught me about ecosystem specific security. Oh, what you Hello.

Apologies. Hi. Hi. Nice. So, yeah. Uh I'm Nir. I am a security researcher at Sartoria. Uh earlier this year uh we had audited a lending protocol on the near blockchain and we found several issues there and some of those issue had uh nothing to do with the near chain uh some of those issues had nothing to do with the landing logic. It came from the chain itself. It came uh because of not considering all the scenarios enabled by the execution model of the chain. So today I'll be showing uh a couple of such example and what it taught me about the things that we take for granted.

What it taught me about the assumptions that we may bring from the past chain we had audited to the new chain and which not might always hold there. So let's get started. Let's first look at the simplest borrow function. This is something that we have all seen. We have all audited simple borrow function three line check the limit pay the borrower and update the debt limit is just something that the collateral allows the users to borrow looks pretty simple right check pay and update the debt what could go wrong here my question is can anything run between these two lines I'm not talking about the re-entry just

assume for the sake of this that the token contract is If can anything run between these two line in this and in that case? Well, most of us are right that on the Ethereum nothing can run between the two lines because one transaction one block and it's done. But on the near the answer is yes and uh that gap essentially enabled several attack vectors that caused some findings to this protocol. So let's uh uh in order to understand that let's first see that how these three lines are modeled for the near. Please remember these three lines and we will see that how these are actually executed

on the near. So near is a sharded blockchain. Everything runs in shard. One shard doesn't share any knowledge with the other shards. So the cross contract call your contract is making might actually live on the other shards. So calling another contract doesn't always happen right away. It's a sync. One transaction can actually span across multiple blocks. So in our example uh after checking the limit, the lending contract actually asked the token contract to pay the borrower. But the lending contract ends right there. The check is done. The request to transfer is sent. All of it is saved and that is

block n. Each of these boxes are called receipt and inside a particular receipt everything is atomic. Then in a later block the transfer would attempt to pay the borrower. It might work it might fail and then in a later block if the transfer was successful the call back would come back to the lending contract and the debt would be updated. So one borrow transaction spanned across three multiple blocks inside a particular receipt everything is atomic but across the receipt not at all.

Whatever the state changes that has been saved by block n stays saved even if the later transfer fails. And this is not something uh this is not the case with the Ethereum or the any other chain we know because one transaction one block and uh it's done but in the near it is possible and also uh the interesting thing is that anyone can come while the transfer is in the air and call any functionality of the lending protocol even while the first world transaction is not completed. fully. So this is also the interesting thing and let's keep this

mind and uh let's see our first example. Uh let's meet Sam. Uh Sam has provided 100 collateral uh to the lending protocol with the coll with the collateral factor of the 80% he is allowed to borrow 80. He puts forward a request to borrow 80. So the check would be 0 plus 80 and it it it's well below the limit and the check passes. So the landing contract asks the token contract to please pay SAM. But while the transfer is in the air and while the call back hasn't executed yet and the debt is not updated, Sam comes again and asks the lending contract for the 80 again. So my question is what

debt does the second request see? The answer is zero because the first request call back hasn't executed yet. The debt is not updated. So the second request check would also pass the two transaction two transfer goes through. Two call backs would come back. The first would write 80, the second would write 160 and the Sam has essentially borrowed 160 against the collateral of 100. And that's a bad debt. So pretty interesting. But uh how to fix it and the solution is again very simple that uh we we count we we should count the seat when the ticket is sold and not while the passenger onboards. So the

moment sam request to transfer we have to reserve that amount. So our updated check would be existing debt plus the newly uh the reserved in air and the new amount requested and that should be below the limit. So with this updated check when Sam comes with his second request our check would be 80 + 80 which is 160 which is above the limit and his second request would be refused and we are saved from the issues. So this this issue was about the timing the Sam made two consecutive request to bypass the limit. Now let's see one another interesting uh scenario uh that is enabled by the nearest execution model.

In order to understand that let's first uh know how what is the storage rule on the near on near blockchain the user have to pay for the storage that they are going to use. So for example if I want to hold a token I need to register in the token contract I need to pay for it. It's it's like a bank that if I don't have a bank account in a particular bank no one would be able to transfer me money in that bank. So for example, consider Dario. He's everything right in the lending contract. There's a plenty of cap. There is no debt.

Collateral is enough. But and he wants to borrow 80 of the borrow asset. But he doesn't have any token account in the borrow asset. So his his borrow request would be refused because it doesn't have an account there. This is not something that we always think on the Ethereum because we always assume that the ERC20 transfer to any address would always be successful because on Ethereum every address has account on every bank. So this is except it is a contract and we have a reward in the receive function. Uh but on the near it is very much possible to refuse the transfer to ourselves. But why would someone do that? Why would

someone make a transfer to himself revert? Uh let's let's understand that with the example. So for example, as I said, Dario has everything right in the lending contract. He wants to borrow 80 and the check easily passes. Uh but the lending contract does very sensible thing here. He puts aside a 80 in order to not promise the same amount to some other user. So the free liquidity would be 20 if the initial free liquidity uh is 100 and if we are promising 80 to the DARO the free would be 20. So as I said the check passes and the lending contract ask the token contract to pay

to the Dario but while that transfer is in the air Maya comes to the lending contract. Maya is a legit user. He asked the token contract to to please borrow borrow 30. But since the contract is only 20, Maya's request would be refused. And when the transfer tries to execute Daario's transfer, it would fail as well because Dario doesn't have any account on the token contract. So Maya's request is refused. Dario's request is refused as well. So Daario could do it repeatedly.

Dario could essentially uh consume the pool's liquidity with nothing but the gas. Dario can do any legit user from borrowing. He could prevent all the suppliers for from earning any any yield. And what's the cost to the Dario? Just the gas. So let's see how how to fix this. Again the fix is very simple. the moment the request was initiated we charge we start charging interest from the block n only. So even if the later transfer fails uh the Dario has to pay interest for the amount of time the

transfer was in the air. So if the Dario now wants to devise the other user and the lending protocol he would not only have to pay the gas but also the interest. So if if you notice there were two things that uh needed to be seen here. The the first was the storage rule on the near and also the call model on the near. Those those two things combined enable this attack. So let's just uh let's just bring everything together and again ask our question our assumptions that three lines were same but the guarantee it provides differs across the chain. I earlier I never used to check those assumptions because I always used

to believe that nothing runs between my lines. the transfer fails and everything before it automatically unders because the revert takes the whole transaction downs with it and a transfer to a user who has an account would always be successful and all of these hold true on the Ethereum but let's say what about Solana on Solana first two holds but third it doesn't hold because you need to have a token account on the token program and on near agents that are in the while or one you're building Okay. So, first of all, why do you even need an EVA or uh your own benchmark

when there are so many security public benchmarks? Well, basically because most of them are very broad and general, you probably need something that's like more domain specific for you and your work. Secondly, you need something that's hard and uh using which you can measure improvements in any AI agent, security agents or anything that you're building on your newer frontier models. So uh this year like one uh web 3 security benchmark got really popular but it had some problems. First of all it uses it used like public audit

contests as targets which were probably already in the uh training set of the models it was testing. Secondly, it used the answer key uh of basically all the issues that were found in that in those public contests and anything new that the models actually found were not graded. So let's talk about how to get like how to get your evals wrong. Basically um uh like if you pick the wrong targets, you won't have a good eval.

And um examples of wrong targets are basically using public repos or public audit contest because that risks contamination. If you're only using like one repo for testing every time you run your AI agent or your models uh you risk like overfitting and um if you're synthetically injecting bugs into let's say a code base then you're basically pattern matching what you're injecting. Or if you're depending on an a on an AI model to do that, you're basically just testing like what it tries to find or what it tries to inject and then find itself. Again, do not use like smaller toy contracts or CTFs because the models now are really

strong and they'll just find all of the bugs and you won't have a good eval. You can also have lo like wrong answer keys if your ground truth is fixed. basically meaning uh every time something unknown comes up whenever you run your AI agent on on the eval if you're not adding new issues to it then that's a problem. uh give um like if you're only testing for the correct issues then also it's not a very good one because you need to see how much noise it's generating and have a separate score for it or like have penalties for that and um don't count all the issues it has find like way by severity or like have like a better

metric for it. You could also give it wrong conditions like basically if you're giving it not enough access to tools and stuff then it's probably not performing at it at its best. Uh but don't give it too much information like hints and stuff because then you're not really measuring the performance like bug hunting capabilities of the model or the security agent. So what a good one does. So just to go through it really quickly, have a lot of private code bases that you've audited. Uh please take permissions from your client before using the code bases for evals. But this is probably the best thing you could do. Uh secondly, every time you run the agent and new issues

come up that you don't know about that they are not known false positives or known like true positives, try them and add them to either the uh ground truth or like maintain a set of like known false positives. uh give it all the tools that it could probably use. Maybe give it an give it the internet access give it internet access if you're testing for something specific and then benchmark your matching agent. Uh give it like tweak the ground truth issues a bit and see how it's performing and that's it man.

Um, just to start, gather a few past engagements of good code bases of various sizes, use them, see the answer key with the confirmed findings, and then run the tool with the repo, the test, maybe the internet, and then triage everything it reports that's not on the answer keys added to either the known issues and or or the list of false positives. And that's how your eval will keep on growing. And they it would be like domain specific because the public benchmarks they only like test against known findings. But what you need to do is you need to know how well your agent performs on like unknown code bases.

Thank you. [applause] Best of luck. Okay. Hello everyone. Uh we will finish this session by a little bit thinking about scope and how to choose it. Uh I'm Jan and I'm co-founder of EC3 and security researcher there.

And if you think about the free typical audit, what comes firstly in mind? It's probably list of solidity files where uh there is a smart contract repository you got it sent from the client you estimate it and you audit contracts and right that's it but usually it's much bigger uh so uh a lot of bugs are originating elsewhere or can have some uh complex behaviors between them. Uh so uh here is the call out that the scope should be much bigger. We were doing a research which is publicly available. You can also catch me after talk if you would

like to show it. And uh it's basically some data set of exploits from January to September and you can see that contract bugs have the highest incidences. So it is uh correct that we are focusing on them and we are auditing them but uh the value is also leaking elsewhere as you can see for example beckon compromise and other domains. Moreover, 71% of these exploits were out of scope while 23% were in scope, which is not very low number. But if you uh look closer at it, you will figure out that only 8% of it are actually recent

audits. So this is basically showing that audits are kind of useful, but they have also expiry. So I want to highlight here that audi scope is a security decision and not just a formality. So the scope should be defined by your system by your protocol your application whatever you have and you should follow the value there map all your dependencies build a trust and threat model. If you are not familiar how to do it, I think definitely there will be several humans and agents which would like to help you and just from our experience to give you some example what it can be like you are editing just a solidity files but it

cost you almost zero uh time to just run a git leaks and uh you can find some uh critical uh private key exposure or anything hidden in some of the comets which is exactly white tao get hacked if I'm correct in past then there is a lot of other review errors such as obviously dependencies some malicious version which is pinned or uh unfortunately loaded into some deployment then if you are reviewing also deployment scripts you can find some inconsistencies between actual smart contract logic and the intentions from the customer it can also help you and then there is a lot of integrations or offchain services where

sometimes times you are offloading some B validation to back end and not in the smart contract then definitely you need to also look at the back end and that's basically it. So we can go to lunch [applause] The next will be starting at 2:30. It's a 1 hour break.

Hi. So I think you had a great afternoon and food. So let's get back to session. So we are having another short talk session. So we are going to begin with Rudra Pra Singh and he's going to talk about nobody sentence. Sorry. Hi everyone.

Are you It's not working. So hi everyone. Uh so welcome to my a bliss talk about nobody audits the front end. So everybody's so focused on auditing their blockchain DT nodes or smart contract but nobody cares about web 2 as such. So I was curious about the position of web 2 security in web 3 ecosystem in general. So I ran a 3-week project where I was not doing anything fancy but just a guy who is using codeex in general to understand what are the system like uh security ecosystem in web

two stack and we disclose in this journey 200 plus security issues ranging from critical to low to across multiple projects. It includes some of our clients as well as some of the projects that are hosting their bug bounties. So one uh we need to understand that one front end expose multiple users. So for example, if you get a chance to inject a malicious JavaScript in within a front end, you basically can ask normal user to sign a something malicious that they are not supposed to be. So the

significance of front-end security becomes very valuable and as I mentioned in this experiment I did not touch upon anything manually everything was autonomous and it was run by agents. So, one of the snippet that you see is a full-blown remote code execution in one of the clients that we were pentesting where I was able to within 10 minutes of uh running the agents, I was able to get a remote course execution where I was able to get into their servers and I could have control anything on their front end.

And as I mentioned, it's nothing fancy. All I used was uh just a codec sub uh subscription and that's it. So what I want to bring up the point is that front end is as important as smart contracts and it does not need anything uh like you don't need to be very experienced bug bounty hunter or security uh guy in web two because these uh AI agents or general models are really good at web two stack. The reason being is that they are trained on plethora of data that uh that has been there for ages and uh like for example generally um a lot of DAPs uses NexJS which is a JavaScript

framework and they are really really good at chaining bugs and finding a lot of things and in this twoe setup I disclosed over 200 issues ranging from stored XSS cache poisoning leading to XSS and up to RC See and it also I found out two zero days. So a lot of companies uses third parties. So I instead of targeting random projects I just cured a list of all these projects that uh these projects were using and I trigger like fired my codec subscription. That's it.

And the the the end result was basically they were able to find autonomously two zero days and I all I got to do is I sent a bunch of emails uh to our clients and the projects and that led to real bugs and real bounties. So a uh it's just a small snippet of what I gathered within a one week but the real figure is more than that that shows the power of just these general models uh h having the tendency to find front- end issues and they are really good until unless you just don't monitor them right and contract gets audited but I I'm not

pretty sure how many of the projects does uh audit audit their front end. So it's very important for at least a project to run through some some sort of front-end pen testing or at least run some agents through it and uh the consequences are uh they can fall victim of fishing or swapping of malicious transaction. As I mentioned that AI knows web two way better uh than general web three stacks and they they are they are really good.

All all you got to point is to a domain or whatever stack you are operating towards and put the scope the questions and that's it. And that's it for the presentation. Thank you. So next up we have to talk about why security is dying.

Over to you. >> Hey let's Oh amazing. Okay to be honest I saw they have 30 minutes talk. So my presentation is 32 slides but but I will make it very fast. >> Yeah. Thank you. So what we do here? Okay. Okay. Let's perfect. [snorts] Let's let's do it. I'm Dimitro. I'm from Ukraine and actually I hold my life in cyber security as everyone is here. And uh today I would like to talk about especially crowdsource security since actually we do crowdsource for last 9 years. So uh yeah today I would like to focus only on a stuff that related to contest and

crowser security. Yeah. So if you actually remember we had a platforms before it was hacker one it was background and etc. Then actually new platform has appear on the market as you modify hack and proof and etc. And best years for everyone probably was 2020 where we actually had new models on the market which is contest. Yes. And then we have a new reality in 2024 and 2026. So here we should find the common name. Yeah. Crowdsource audits contest hackathon whatever everyone had trying to create over name for this space but the idea is one many researchers one

codbase and one goal find vulnerabilities and of course earn money but not on the slide and uh so I call this chapter is beginning of everything. So what's the problem we're trying to solve this time? So first of all, there was not enough uh security researchers in the market. Yes, new smart contract languages and etc. appear and everyone wants to know that everything is perfect. Uh cyber security firms was were fighting for security specialist and everyone was saying hell no we actually know how to do move audits, RAM audits and etc. But at the end everyone was uh find out that this is was the same specialist cross sharing through

each auditors also at the first time there was lots of security good engineers who had a full-time job as a developer who actually built a coder base and they like hm why I cannot just doing some part-time job legally they asked actually the HR to make some uh extra legal agreement to participate in etc. So market was growing more and more and everyone wants to have transparency because like if some languages appear have to learn bugs, how to actually be faster than bad actors. So what's happening then? Best times when actually Cod for Arena was announcing about first contest for more than $100,000.

Everyone was talking about this that hey we going to earn money not much specialist and at the beginning was a few guys who participated and they earned good money. So uh if you actually remember it's public all data is public yes so nothing is to hide here so you can make a photo and etc. So with those uh year actually was documented more than 160 crow stories on the market and more than 9 million plus actually rewarded boundaries and there was more than 200 unique critical vulnerabilities. Everyone actually could learn so many good actually initiatives was around. I remember even pure groups I met guy at the conference and then

they collected together good talent and created a new firm security. So lots of talented actually created on those time and the business model was pretty nice. Yes. So um companies so we talk about Kodifina for example they earn around 20 30% from each actually contest. So by having contests for 100,000 you could earn actually as a business to 20 $30,000 actually um and work. So if you remember there was an article unfortunately my designer didn't put it but actually there was article there where Kodina was promoting a guy who actually earned more than 1 million just for 40 months at the kod for arena for participating in the contest and then

actually became a boom. So when something is appear everyone trying to step in as a business work find models and etc and this is what what was happening. So uh spirit which is canina they actually raise money there was a public announce that they will going to crow security market and improve this market there also actually uh was opportunity for uh for this because everyone was knowing that kodarina was charging 20 30% for um leasing companies and they could actually build strategy to get investments into it and then actually if you remember there was a boom of million contest. So it was actually make a D on the share. There

was actually blast unis swap a etc. So there was like a boom of 1 millions platforms and even companies who wants to have an audit they were fighting to be listed in the platforms and actually show that they have money to make a contest and everyone was thinking that contest is cheaper than doing internal audits. But the reality always was and and is that contest is always expensive than actually doing private audience and actually so everyone wanted to be in yeah new talent learning boom everyone was just making some courses uh training actually pipelines and etc. uh and then

actually if you remember there was a canina elite security club they announced that if someone is joining they cannot participate in other uh publicly contest and etc. Everyone was trying to step in into this contest and then was a turning point which is actually happening. So crowd become too crowded and more researchers same price submissions overloaded early uh AI entries to the games more duplicates. So everyone trying to uh reync um technology. So if you actually take a look so previously there was around 500 that uh price pool for submissions. So

in 2026 there was less than five times public contest and price for per submission was just $8 $80. So there was a perfect storm. Yes. So crypto winter platform competitions hungry researchers uh AI wasn't the main boom yet. So actually what's happening the next I will take 1 minute extra. Okay. So zero. Yes. So K for actually release uh zero fee for companies. So come and not pay.

But the reality if you actually company and you have register your entity let's say in US or somewhere you also have to pay money salary. I'm talking as a co for you. Yeah. So to keep uh company at least for I don't know 10 people in US is more than $100 per months. So actually what happening? So companies platform start uh competing with each other. Everyone trying to show zero buck fee model uh conditionals pools if you remember let's say someone was saying hey you have to find 10 criticals to unlock one minion and etc. So that was a reality then severity based when like previously the main idea was there is a

pool and you take pool even you have low medium bug then actually critical high low and everyone has to participate so what's happening then two pioneers die yeah because of business model first of all second uh it's my last part cows cows actually was related to what everyone trying to do with AI everyone trying to participate in new models appear on the market paid submission and etc. And where we move last slide from my side. So we move to from hey we need more talents to we have AI. So next what we will see is actually we move to the way when AI researchers and actually researchers will burn their AI tokens to

save tokens of companies to actually make EI audits. Yeah. Thank you. >> [laughter] >> If you want to connect with me, you're welcome to Yeah, I'm sorry. We have Joseph talking about benchmarking models. Which one is the best? Over to you. >> No, it's about for Never mind. I'll make it.

So, congratulations. That was pure efficiency making 30 minutes talk in five minutes. We can discuss it later. I was suggesting that the ending. Yeah. Yeah. You could finish Yes correct.

Okay. So, we have still some time. Yeah. So, you could end So now now we will speak about fuzzing. Uh it will be five minutes and and then uh I have a second talk uh about evaluating of uh AI. I did a fresh benchmark.

By fresh I mean overnight today and I'll present this at uh the next session. It will be the long talk. This will be the short talk. It's like evaluated from all different angles. So, how do you like India so far?

I I put on a Twitter yesterday that that at our hotel room in the bathroom there were like two buckets and I didn't know what was it for and how should I use it but then guys explained me that this is some kind of like local technique how to uh get your higgy and dance. There are like two buckets instead of shower. Yeah.

Or I can connect my laptop if it would help. Oh yeah, that's it. Nice. just doesn't look like slides, but okay. Uh yeah, let's get started. Uh well, actually, it should be like one slide, but I guess this is all we can do. Okay, never mind. So, we'll be spoiling a little bit. So, yeah, nice to meet you. I'm Joseph and I'm from uh ACK3.

And now I'll speak a little bit about fuzzing with uh AI agents. So we at ACK we are auditing. We also are building Wake which is the testing and fuzzing framework and uh we are happy to be working for some of the top tier protocols and I'm also a professor at the Czech technical in Prague. Next slide please. green. Okay, so fuzzing seems like a mystery.

At least you'll be very excited what I am going to talk about and maybe I will not make it in time. Okay. Five minutes. Okay. So, uh yeah. Uh I have to go off stage and get back in five minutes. Right. Yeah. You you can continue. If it works now. Hello again. Pressing

the button. And pressing the button. No. Yes. Okay. Cool. Yes, it works. Yes. So, this is us. And let's get to the point. So, here is some of the guys who are doing formal verification. So, I'll just remind one thing with fuzzing. You have blackbox fuzzing, which means basically the fuzzer has no information about the code that is being tested. But this is the fuzzing that we are not using anymore.

Uh for years there is uh something that we at Eki we call it manually guided fuzzing which basically means that you're writing some kind of like puite that will help the fuzzer to get oriented in the codebase and be more efficient not to scan the whole state space but just some places where you think the bugs can occur. So this is just for explanation and um then we have a nice benchmark that's called del and here we tested some of the uh most uh known fuzzers and it looks like this when we did the pure black box testing which means the

fuzzers have no information about the code that is being tested. uh we can see that on this exercise where is up to 153 let's say bucks uh the fuzzles reach to somewhere like 70 to 75 and we tested wake we tested foundry we tested Akidna important is of course like during the time how efficient the fers are uh they are almost even there's no much like difference uh this is just like argument for someone because wake is written in python so you can see that it's not about the language that the fuzzer is implemented. Uh because even like in Python with some Rust internals wake is performing on the blackbox fastest thing

really good. But this is not what the talk about. The talk is about this and this is what happens when you let AI agent write the manually guided fastest which means basically they are giving specific instructions to the f to the fuzzer how the fuzzer should approach to the task and here what it did did uh you can see that basically uh it didn't discover like 70 out of 150 issues but it discovered all issues and not in eight hours but it discovered within in one hour. And how did it do? Uh, basically the AI agent has read the source code of the maze. So we cannot

call it anymore blackbox or gray box facesting. This is more close to white box facing. So it reads the source code of the of the maze and it writes an efficient fuzzing path in wake. It's uh done by uh it's done done by combination of uh flows and uh invariant testing and in this path it discovers all the bugs very efficiently. Uh then we did one more test uh which is less synthetic and the test is based on SC fastbench uh which basically contains known bugs and known human written fast tests and we tested on two projects with the same

approach. Uh so we let the AI agent write fastest in V using the manually guided fuzzing principles without exposing the actually fastest that were written by humans. So the AI agent knew the source code but didn't know any uh fast tests and it wrote the fast tests. If the fast test failed, there was a loop that basically uh was repairing the fast testing suite and it was going in this loop until it delivered. So how did it go?

Uh in this uh set of contracts that we are testing there are uh 12 known bugs but only six of them are discoverable so far by fuzzing. Uh which means the human written fastest have uh recall six of 12 bucks. Uh with AI we were able to reproduce that. So basically uh we delivered the same uh fast test as the human written fastest but there's a catch that uh basically the results are not that consistent which means that in single fastesting run uh the highest recall was four out of 12. Uh so there

had to be more uh fastest rounds. What is the reason? The reason is that uh when AI is writing uh fast test or tests the one of the things that are very hard for it to understand are time constraints which means like what happens after something happens. It can be like race conditions in ination of proxy or in that case it was like a test scenario that was missing that should happen after payment has started. So basically it tests the system like how it is but not how it changes in time by default. So this was something that the

fastest were the AI general factor was struggling with. Uh but overall like we get to very close results as humans. Uh so is this something that could be used as a replacement of human work? We still think no because the very edge case is missed and this is exactly what needs to be u done by some kind of like human narratives. Uh but to catch like 80 90% of uh the bugs this works really well if you would like to read more about the uh more about this test suite. So here is the complete source of that. Uh there's also link to actual version of wake and uh yeah I finished uh in time so uh next

speaker can follow. Thank you very much. >> Thank you Joseph. Next on stage we have the long Great Tik Tok. >> Hey everyone, full house. Nice to see that. Uh so I'm thank you so much for

coming to my talk. Uh I'm talking about cryptocurrencies in D5. Uh this is going to be a more foundational talk than some of the others. Uh this isn't you know solely strictly based on the ME uh literature which you all have seen or are used to. Uh this is coming more from the econ side from anything else. Uh I'm also my tax fellow at the University of Alberta but lot. So uh the the main primitive that we're going to be talking about here is going to be uh auctions and how defy auctions have been set up and how you can manipulate them. Uh there are a lot of

examples of auctions which you've seen in D5 till now. uh there's liquidation options uh trading options which I mean as intent based options like crowd swap so on so forth and there's also block space options which is uh the normal uh block space uh allocation and payments that are required by block producers so fundamentally an auction specifies who can bid um who receives what and who pays and the main adversarial attack that I'm going to be looking at for auctions Today is going to be civil where how can one economic actor or a bidor or an agent in a system is able to manipulate an auction by spawning

multiple other identities. So uh fundamentally an auction has an allocation rule and a payment rule and uh as as a very nice finite example we have two biders Alice and Bob. So Alice values a good at VA and so she bids BA uh to be able to get a chance to gain that good. Similarly, you have Bob who values that same word at VB bits BB I guess and [laughter] the auction uh specifies that exact function uh which would basically be a probability of uh whether or not Alice or Bob will win the

auction for that good and how much they'll have to pay for it. Uh there's a very simple example of a single item auction which is going to be specifically what I deal with today which is going to be the second price auction. So there's uh bids which are 10 7 and 4. I bid for a single good at 10 7 and 4. Uh you see that the highest bidder who bids 10, they end up paying the second highest bid which is seven. Uh there are different uh D5 auctions as I've talked about them. I'll just reiterate them once. You've seen them for maker dow which are uh collateral auctions which is the significant example of a Dutch auction where uh the collateral price declines with time and purchases they settle instantly. You

have intent based auctions on car protocol where solvers completely propose uh settlements and then on the more fundamental block place level you see flash right and then boost uh there are some adversarial questions that will probably detract us from what we I want to talk about today and I have limited time apparently so I'll go over something more specific so an attack [laughter] can exploit either code or economics that's the way I see it attacks are all of you are probably way better at that than I am. And so today I'm going to be specifically looking at economic attacks. Uh some of the examples of economic attacks right now are as I said civil uh which is one person spawning multiple agents. At the same time

there's collusion attacks where it's all of the agents in the system colluding to each other. There's a really subtle difference with it's basically that these are separat identities. Right. Right. So [snorts] the very basic model of an attacker is that exact action which maximizes their utility uh given the information conraints that they have and you uh also minimize the cost that you need to actually conduct the attack. uh right now some specific uh assumptions that we're going to be making for auctions is going to be that it's truthful where if you remember from our example there's VA and BA truthfulness implies that VA is going to

be BA no matter what because that's the highest utility uh for the agent at the same time civil proofness where as I said one actor they cannot gain more utility by dividing into several bits and the main point I want to drive is that if uh uh an auction is considered safe for one specific bid. It might not be this uh it might not be safe for multiple bids at the same time. So complete civil attack very very simple example think of a lottery right you have a prize which is say worth 120 and uh there is a lottery here where your probability of getting the item is proportional to the number of players in the game. Say uh if it's 120 then the probability of you getting and say sorry

if there are say n bids your probability of winning is 1 by right so let's have a baseline of three identities I have an attacker and I have two honest people right who are bidding alongside me uh I my way of attacking would be to divide my one bid into two or maybe you know I don't have to divide that one value I can have a value greater than that so on so forth the main thing that you have to think about is that when there's one attacker with two identities, it's my probability of winning the good is 1x3 which is $40 in this case. Similarly, if my uh once I deviate and I divide my bid into two, my actual probability of winning is 1/2 now, which is $60. So, you see that difference of $20 there,

right? uh this will give you some more intuition where you might think that in order to make the system or the option completely secure you're going to have to impose a certain cost which has to be at least greater than $20 in this case. So now that you think about it, when you take it across agents, across people, uh, attack search is an optimization problem and what you're actually going to be optimizing is that the utility you get from being a civil agent versus a truthful agent. Uh, you're basically trying to maximize that exact portion which is delta here as you see on the screen. Uh, there's several ways to calculate it which are great normal optimization techniques that you see in Python. Uh there's also some constraints

here with gas deposits tings you you get the gist. The main point right now as of today the uh second price auction is the only option that's proven to be civil proof for now in the single case. There's a lot of literature in the multi case as well that's been done by the wonderful people at all right you should definitely check them out. uh we have some more results for um civil proof options. Maybe I'll talk about it later once we pass the paper. So one really interesting aspect that I want to talk about is AI agents as attackers.

So AI agents are the way I see it on a pure economic level, they're not going to be very different than human beings about thinking uh about how to manipulate a protocol. Uh they're going to do the same exact thing that we do. They're going to read the rules. They're going to form a hypothesis about how to actually attack it. They're going to evaluate how much it's going to cost them to actually conduct the attack and they're going to basically revise their uh constraints from feedback, market feedback, people feedback, so on and so forth. Uh the next thing that I want to talk about is a very very simple >> infrastructure for how you as an agent or like you having an agent, please don't do this. Your AWS is is going to hate you. your bills are going to be

huge. I'm not going to lie. But the main thing that I want to talk about is how uh what a basic infrastructure might look like. Right? So [snorts] I have been in AWS Maxi all my life. I'm sorry if I find someone here with that. But I would basically take an S3 container where I'm going to uh query information or data from you or onchain data. Hopefully you have your mode set up of your own. You're going to take the onchain data. You're going to take all the code, the hash, the seeds, uh, and you're going to give it to your agent.

Your agent after pulling it is going to form a hypothesis, right? It's going to take the information at a microscopic level. It's going to skim through it, figure everything out. It's going to give you a structured point of attack. uh then in order to solve the deviation in order to actually see all the values all the bits that it has to do how much civil bit do they actually need to actually manipulate the protocol they're going to use uh uh an ECC worker that's what I would that's what I would technically where I would do computations at the millisecond level I assume I I I don't think that that's pretty slow but on top of that once those simulations are complete you're

going to know The agent is just going to know by the end of it exactly what the deviations are required. Then there's going to be an independent replay which is again like that's big words for saying back testing where you're going to take block data. You're going to see the uh civil deviations that that have given you more rewards than a normal person. Then you can back test it. Uh you can see exactly what uh gain what utility you're going to get as an attacker versus a normal agent. And then you're going to verify it. send it back to S3 as logs, right? You can pull it, you can check it, verify, so on.

So I am not going to leave you with just like, you know, just that just a way to attack the system. I'll also talk about I just want to talk about how a uh an sorry how a protocol designer is able to figure out a mechanism or learn a mechanism against an attacker. uh for that I the way I see it it's going to be a coupled optimization function big words but what it actually is is that you're going to have an inner problem where you're going to freeze the mechanism parameters and you're going to search for civil attacks for any option you have an option A with payment rule A B sorry and you're going to figure out a way uh you're going to put a million

civil bids to make as many biders as possible from one person and see what your utilities are in that case. Uh and then you're going to solve the outer problem where you're going to solve it for the protocol design. Now the outer problem is basically I want to increase I want to maximize my revenue at the same time minimize uh the instances of service. What I mean by that is that when you minimize the inner problem, uh you're basically figuring out exactly how uh expensive it is for a civil attacker to actually attack the protocol. You're going to increase that expense. Sorry, you're going to make that really really expensive as expensive as you can while at the same

time um improving your revenue, maximizing your revenue at that very instance. What I mean by that again at the end is that uh you're going to end up learning a mechanism where uh you know using neural networks deep learning that's what we did for our very recent paper uh hopefully when it comes out I'll be able to talk more about it but what it actually does is it's able to learn mechanisms where attackers no matter what they do do not have any incentive to attack the option at least using civil at the end of it. I have some final thoughts. I have like 3 minutes left as well. That uh the full performer of actually conducting a civil attack or

thinking about attackers in uh economic protocols in general is you have to specify the agents. You have to specify exactly how civil bids can be uh inputed into the system. You have to compare the utilities between being an attacker and being a normal agent. And you have to separate when I say evidence from guarantees what I actually mean is that separate back tested variables with the actual market conditions. And my final point that I want to drive with this small talk I guess not so small now that I think about it is that economic security it actually needs an adversarial model. It doesn't need like a specific it doesn't need like a best case model to be fair. Uh the worst case scenarios are always considered in consensus research. It's always consider

considered in even in auction literature but I've I haven't I'm yet to see ways in which people are able to combine those two and by finally I just want to say that I we have figured out a way to create civil proof auctions from the ground up turn any uh auction into a civil proof one using uh wastefulness so that is something I'd love to talk about um that's all I had if you have questions please come find me it was great to meet you Thank you so much. Hello. Hi. Hello.

So, basically my human management had announced earlier. So I'm trying to trans invite again for another talk. There was a topic earlier. Topic is benchmarking your models. Which one is the best EVM for watching? Thank you.

So, hello again. My name is Joseph and this is the longer talk and we'll speak uh about uh about uh benchmarking of AI models. So, let's get started. Um yeah, the timer. Okay, I'm starting. So yes um I'm co-founder of uh ACK3 and uh today uh we will look at some benchmarks that we run in the past and also uh I did run the latest benchmarks overnight so it is very fresh data that we'll present here uh today uh we at ACK3 we are developing tools we are doing audits we are doing

research and uh I'm also uh assistant professor Czech technical university in Prague and we are happy we could be working with some of industry leaders as for example Lido here. Thank you guys. And uh so let's get started. The question is how to evaluate LM auditors. It's not that easy. uh because the web two security guys they have more easy uh way of uh measuring if some attack succeeded because you can for example uh set a goal to the agent break this system or like get into this database and when you set the goal the

agent is just working on that and uh that's all you need to settle but our goal is open we don't know how many bucks are in the contracts. So basically we cannot set as easy goal. So that's the first problem. The second problem is of course data because when we have a uh when we have a project uh where we know the issues because it was audited it's probably also public which means uh the LLMs could have learned on it and now we are not evaluating how they would perform in the future but we are evaluating how they performed in the past. So it's very hard to finding some uh data set that was not public but was

audited. We have some of the data sets but it's of course a little bit limited and of course we need to care about zero data retention when we are doing stuff like that. So we cannot just use any Chinese API you know that we don't trust. Uh so the evaluation part one is that we looked at individual models. Uh this is an older benchmark. Uh we took uh these uh uh these LLMs. uh we took just a very easy workflow with codex and we just run uh that with some prompt I don't know find all bugs make no mistakes uh over a codebase that was consisted of five unpublished audits and uh we are looking for the recall because

we knew how many uh criticals and highs are there these are the only ones that we tracked there are 40 discovered by uh sorry 36 discovered by human and four [clears throat] with the later AI findings. So the total recall was 40 and this is how the single models perform. So the human auditors discovered uh in the first revision then then it was more uh 32 findings uh and the most performant U LLM uh is OPUS 5 that discovered 35 and uh then it went uh slowly down. But this is not the chart that you should be looking at because it

doesn't basically help you to prevent uh from the hacks. So more interesting is this chart where we looked at uh all the bugs. Uh this is this axis basically uh that are present in the data set. We looked at all the models and the humans and we looked who discovered what and of course like the oppus discovered most of the issues. But is it sufficient for you that in your protocol you have something that discovers most of the issues? No, you need something that discovers all the issues. And here I must uh shout out to uh Kimmy K3 because this guy the overall performance is very poor poor

but what it did is that this one issue discovered no one else but just this model and this is of course like very interesting that that it's able to find a unique issue uh which was uh high not a critical uh but only uh this model discovered that not even humans and not even oppus or uh someone else. Uh so what does it tell tell us this benchmark? It uh helped us to form like two hypothesis. One of them is uh what happens if we just run uh the benchmark multiple times and the second one is like maybe we need uh some kind of like mixture of models to be able to find the unique findings

because this is what we are hunting for as well. So then we did a second benchmark. For this second benchmark uh the inspiration was this hack. I don't know if you're familiar with that but it was like I think month ago uh quite headline news that uh that uh there was an like internal experiment within open AI uh where they have put some uh goal to the agents and uh what they did instead was that they hacked out of the sandbox and uh tried to uh or success ceeded in hacking hugging phase which was the benchmark they were

supposed to outperform. And the interesting thing about this is how the agents did it. And uh when you look at the report basically uh they the agents found a way how to communicate between each other. they were exchanging messages and they were like building on each other's uh findings and they even called themselves like a collective and uh it was pretty scary. Uh but I like that and so we said okay maybe we could replicate something like this and see how how it performs. Uh so we did uh this uh quick uh tool uh we call it swarm. uh we just open source it yesterday but it's still like quite

early internal tool and it's kind of like tool that help us to orchestrate us any experiment like this uh so basically you can put any prompt uh you can put any model you can put any workflow um every uh agent has is dedicated container uh and what works here like deterministically is that these containers with agents are sharing the evidence between each other and it's also running on subscriptions which means like it doesn't uh ruin us. And with this tool, we looked again at some benchmarking.

And uh this time we took a smaller uh set, but it was just like uh one code base, but very let's say big and complicated code base. uh and we took six models and uh because it this more recent so uh I will just point out that we were using the latest DeepSseek flesh model and uh this time the workflow uh was that uh the swarm that's the our tool was running uh inside of that the harnesses that are native to each agent. So we are running three harnesses those cloud codecs and deepseek harness and with this we are looking at a data set in the human

baseline there were um four critical and high issues. So that this was the 100% recall and this is how the experiment looked like. Uh this is the time window uh that we dedicated to this uh uh phase and this is 5 hours time window. So basically each this box is one how we call it wave and the wave is like uh one container one LLM and simple prompt like find all bugs make no mistakes when it finishes it just runs again but between these waves it shares the outputs with all the other guys. So basically uh between the waves is a synchronization.

So they are sharing the findings. So they can build on on the findings and uh yeah we just looked what happens also here uh quite interesting is that you can see something like u kind of like performance of the of the models that you can see that for example with uh Luna uh we finished 35 waves uh oppus finished only six waves but it basically doesn't tell anything how efficient the model is. It just tells like how fast it claimed that it has scanned all the codebase and here's the result. So first of all these are the findings when we looked just at the wave zero. So this is like apples to apples to the previous experiment. So here are the humans that

discovered four issues. Uh opposed three uh deep sea which is quite a surprise discovered three as well and the rest uh is uh uh at two issues. this after wave zero. Uh then we again look at this which is the uniqueness of findings. So here uh we can see that the uh H2 issue is discovered only uh by humans and H2 H1 issue which is kind of like uh problematic was in the first wave discovered uh only by oppus and uh deepse uh but this is not what this experiment is about. This is just like a the first wave. So now we look how it performed

next. So when we run uh the more waves uh we we did run up to 32 waves of Luna but we can see that the major discoveries happened within the first uh three waves and we can see that for example with OPUS it uh the next runs didn't bring any value. uh with uh Deepseek uh also uh not but uh for example uh GPT six soul which is the daybreak model uh it was productive uh in three waves which means basically this tells when you want to max out the performance of GPT6 you have to run the

same prompt three times after each other and uh the next uh interesting thing is of course uh who first discovered the harder findings. So we here we can see that it wave zero. Basically the discovery looks like this and then the single models were sharing the knowledge but the question is like who was the first model that discovered the uh harder findings and in this case it was uh uh in wave one uh this guy which is the GPT6 uh soul. So even if this guy didn't have the highest recall in the

first wave, it discovered the unique issue that the oppus missed and it discovered that in the second wave and then uh as they shared uh shared the findings, everyone did catch up and in the end everyone had everything and then the question is like if the theory that I presented uh if the sharing of information between the waves helped. So in this case it did not bring any new finding so we cannot tell for sure but uh it helped the weaker models basically to catch up and here are two uh cases basically that uh helped. So GLM uh discovered something which then

deepse finished as finding and the same here Kimmy was building on something uh that was presented in early waves which confirmed the finding. So on this data set we cannot say for sure that the replication of the hugging face experiment uh did bring the value but if we would not be using the best two models for these guys it would definitely help and uh yeah how did it end? So uh the recall uh after the first wave was uh 75% after the always combined it was 100%. So we can tell that at this uh uh benchmark we uh were able to discover

everything by the uh AI agent workflow. Just a comment on this we did not play anyhow with the prompt engineering. The prompt was like very stupid. So this was like brute force testing and on this experiment we spent about uh 1 million tokens. So it's not that much but it's also not very efficient. It's kind of like brute force uh testing. Um yeah and uh if you would like to uh learn more about it uh so here's the blog post where we are comparing the models and here's the interesting uh open AI experiment and also if you would like to try the tool that we just open sourced uh it's uh in our uh GitHub since uh

yesterday and that's pretty much it. Thank you very much. >> Thank you for the talk. We are going on a short break. Please be back with me. Thank you. play a video recorded by him.

It is like I freed man. The topic is every safe is bind to its own back door scanning 2 million plus multi6 for shadows. The video is going to play in the background. Thank you. Boosting sales season

Hello everyone. I am Elliot Freriedman, the founder of Solidity Labs. We're an onchain. Hello everyone. Hello everyone. I am Elliot Freriedman,

the founder of Solidity Labs. We're an onchain engineering team where we embed with protocol teams to build and secure smart contracts. I'm also a SEAL member and help with the framework around custody. And today we're going to be talking about scanning 12 million multisigs for shadow owners and modules because Nosis safes are the uh largest and most widely adopted uh wallet with the the largest uh aum.

And so let's dive in. We're going to start here asking a question. What's the difference between these two NOS safes? So on the left we can see one has no pending transactions. On the right we can see there's some pending transactions that have been removed. Does anyone notice a difference? So, if you said there is no difference, um, you got the question right, but one of those safes has a shadow module that can steal all of its funds at a moment's notice, and the other was completely fine.

So, we have a paradox here. How can an owner both be and not be at the same time? And we have the same question for a module. If we made two calls to a safe, we could get contradicting answers because every major interface relies on linked list enumeration. And if an item is not in the linked list, it means it's not um it's not an owner or module. But as we can see here with this fun little diagram, all uh owners or modules in safe must be in a circularly linked list where we

start off at the sentinel. The sentinel points to the first address, the first address points to the second address and so on and then the last address will point back to the sentinel address. So it's a linked list. It goes in a circle. But as we can see here, if someone is able to write to this mapping outside of this circularly linked list, now this shadoweth will be a owner and it will not be returned in the get owners function and so no interfaces will be able to see it. We have the same issue with modules which are arguably more powerful than owners because they do not require cororum in order to

actually have a transaction go through. And so this brings us to the core problem with shadow owners and shadow modules which is that they are invisible almost everywhere across the ecosystem because no one bothered with the tooling to detect them. Um, and there are some websites about this, but yes, basically what happens here is we have a second owner that exists on chain. It's invisible to the save UI and there is no uh infrastructure checks for for shadows.

Um, but we're going to get into uh a site that we've built out that helps solve this problem. So here we have a Nosis safe that has a shadow owner. We can see here in the owner's array it has the owner, a sentinel that points to the owner that points to the sentinel. So it's a nice circularly linked list. We go down to check addresses. We paste the address in here. And then it says, you know, this is a shadow owner. This address is a shadow owner of this safe. And how does it get planted and why are we investigating this today? Because this is a known issue that safe can have

these shadow owners and shadow modules. We were building a safe-based wallet and notice that during the setup delegate call window, an attacker could inject arbitrary uh actions because the module setup function calls does a delegate call out to the target address that's passed. And so we said, well, wait a second. If you can do an arbitrary delegate call during initialization, then an attacker could quite easily get people to set up safes using some malicious way and then install a shadow module or a series of

shadow modules in that safe and right just don't don't write into the into the circularly linked list, but just add it into the mapping. This is now an owner. We wanted to know is this theoretical or has this attack already been planted in the wild? Um because if it's theoretical then hey you know it it doesn't really matter but we hadn't really seen anyone do a large scale scan of all all the safes that contain most of the funds that safes hold across multiple chains and ecosystems. And so we wanted to do that.

Before we get there though let's talk about the CPIMP. uh attack pattern. CPIMP stands for clandestine proxy in the middle of proxy and this was a hidden proxy inserted uh during proxy initialization and it made the proxy be owned by an attacker. And the same thing is kind of true with shadow owners and shadow modules because you get created by this hidden entry in the owners mapping. And both of these attacks they leave surfix logic and getters untouched. So the smart contracts work exactly as intended. But both of these things are invisible to auditors, etherscan,

tenderly and basically you know the infrastructure that people rely on. um on a on a regular basis to ensure their their safes are are secure. And as a as a category, as a crypto really we we under underweight um under index threat models that are persistent where an attacker gains access and then doesn't use it immediately because we're so used to instant smash and grab exploits and same block trains uh in DeFi. But I think that this category is very very concerning and we should be

spending more time on on finding um and hunting for threat actors that are you know exploiting these kind of methods. So can we even prove that a shadow exists? If we have the address of a shadow, shadow owner, shadow module, we can prove that um we can prove if it's a shadow or not, we can falsify that question. But if we are instead given um if we are instead given a arbitrary storage right inside of a safe that doesn't do anything that we think it

should be doing or we don't know what it should be doing. Uh it's actually impossible for us. Even if we used and we had all the computing power on Earth, we wouldn't be able to guess whether or not this safe was a shadow owner or just some arbitrary storage rate. And that's because you'd have to brute force all the Ethereum addresses in existence and then check them to see if they're either a module or an owner in the safe. So, how do we detect? How did we go about detecting shadows? So we started off by reading all the public state that we could from the safe and with that state we reconstructed the expected

storage tribe. We fetched the current storage hash with ETH get proof and then we checked to see if the current storage hash from the RPC match the expected um that we computed ourselves. And a mismatch is going to be imply that there's storage that that we don't uh that we can't account for which means yeah we're probably dealing with a shadow. So, we started off with a script that didn't have much state and we quickly realized that, oh, actually, um, we're going to need quite a bit more of a complex system for this. So, he

started off with, um, we had a lot of false positives because of approve hashes and signed messages because the safe could write these into storage and everything would check out. um in terms of this being a legitimate storage right, but we had no way to account for this. So, we had to build indexing into our service and crawl through the logs to find all of the approved hashes and sign messages. And then we also found another after we we fixed that um set of false positives, we found another set of uh false positive which were pass keys which basically we had these account

abstraction wallets on base where we configured um web off um pass keys basically or the owners of the safe configure these web off pass keys and uh it just made these three deterministic storage rights to these different addresses. And then there was different modules and different versions of the pass keys that would write to different addresses. And so we had or different slots. And so we had to go and update our um our eliminator service and reviewer service to understand this behavior so it could um clear all of these these false positives. So this is our funnel

on base. We had 60,000 um storage route mismatch is flagged once we had the logic to you know get rid of the approve hash and pass keys. um that that ended up eliminating uh you know most of of the of the safes that we found and flagged. And then we were we ended up with 12 unexpected uh safes with with potential shadow uh owners or modules. But these were on, you know, addresses that didn't have enough funds

um to to warrant concern and most of them were were unused anyway. So these are our results. We ended up scanning 12.1 million safes across base, Ethereum, Optimism, and Arbitum. And you know, the majority of them ended up reconciling against the expected clean route, which is great, great news. We don't need to have a seal war room. Yeah, it we we didn't really find um evidence of a large scale shadow owner or shadow module um you know, campaign.

And here we have just the UI, a couple screen grabs here. You can see the different networks. In the future, we might add more. It'll show you how many safes we've gone through, what what block we've indexed to, the different versions of the safe that we covered. Here we have an unexplained storage mismatch. We have this route that we expected. This is the actual route. There's a little drop down explaining, you know, what this could be. Here we have a a safe that cleared. So, hey, we can see, you know, we have our link list here. The Sentinel goes to, you know, these two modules and then it closes and there's one owner and so

everything kind of matched up there. Here's another one that's clean. Um, again, that's great news. You know, this is how the majority of them came back. Here we have a shadow safe where we have an owner goes to the you know sentinel to owner to sentinel uh modules. It says there's no modules but we check this address and it said hey this is a shadow. So here we can see the shadow scan URL and you're able to um look through all of the safes of version 1.4. 41 and 1.50.

Uh on this site you can get a real-time view of scan progress and flag safe and you can also see you know a recomputed uh storage route locally that gets checked against RPC. So you don't need to just trust the backend you you actually get that uh in browser. So we're going to end with uh a little bit of a tip here. If you see a safe that has been created that you're using and it has an unverified delegate call, uh if you see that, you should treat that as a potential uh full compromise and immediately contact Seal 911 and if funds are in that safe that has a potential compromise or a

potential shadow owner or module, um immediately migrate those funds to a new safe. So, yes, stay safe. Uh stay in touch. Um yeah, this was this was a a multi-month effort to get all of this together. And so I want to just thank the other engineer on the project, Prateique, who really uh stepped in and helped out a lot. So, and you can follow us more um on Twitter at Solidity Labs, and you can check the site out here. Thanks so much.

That was a good talk. We have some solidity labs here. If anyone have any doubt or want to get to the team, please contact them. Thank you. Next up, we have on the stage Benjamin Clo and the topic is formal verification in the age of AI. over to you. >> Thank you. Okay. Hello everyone. Uh thanks for being here.

So I'm Ben from Very and today we're going to talk about uh formal verification. Uh what we do first at Verity is that we formally verify critical code. Uh we work with great clients like Eternal Foundation or Lido that I see here. Um and um I heard a lot of things on Twitter recently about for verification, good and bad stuff. Some people saying it's the it's going to fix all of our problems. Some people saying it's a pure slop. So today I just wanted to uh reexlain where AI can help us on formal verification where AI um doesn't help us so much where it changes things and where we headed because we had access to um Gemini carbon recently. uh that is like the next the last model

from from Google and they they gave us free free tokens. So we spent a lot uh and we we did a lot of benchmarks and some stuff to understand where uh for verification is headed with the next frontier models. Uh so I'm going to share a bit of that work after. Okay. So let's start. Uh so just to explain what was for verification before I uh I will summarize it in three steps. So the first step was like any software development you uh write what you want to do uh in English specs uh if you're Spanish it can be English uh if you're Spanish it can be Spanish sorry but the idea is that in a natural language

you're going to write what you want to do um and uh this will be your specification your architecture um in English then the second step would be you're going to take this specification and you're going to try to formalize it under um under a specification that is mathematic. Uh so you're going to take uh for example a specification that is the beginning of all specification in our industry which is for example my user doesn't lose money. uh and you're going to you're going to try to understand okay what does it mean uh in terms of variables in terms of mathematics my user doesn't use money uh so you're going to take for example oh it means that in my vault I do not

create shares so you're going to write oh the variable share do not go up okay that's a that's a very easy example and this was pretty hard to do because you had to understand your world system uh software engineer as a your solidity system or whatever system you were building but also you had to had some I would say mathematical level to understand how can I translate this into a mathematical specification. So this was pretty hard to do. Um then you had the proving side. So now if I resume you have step one you have your specific specification in English then you have it in mathematics then you have to prove that your mathematical specification is correct on all state of uh of your code

of your implementation and that was pretty hard to do um for several reasons. So the first reason is uh that we had one main tool to prove code that was SMT solver. Uh and an SMT solver what it is is it's a deterministic tool that will try to take your problem and um divide it into constraints and try to find a counter example to your specification. So it's going to try to say your specification is false. Here is a counter example of your specification.

And the idea is that if it find a counter example then it's forced. You come back to the formalization. You you you try uh you try to reprove again and if it passes you're good. But the problem is I said hard or impossible because on nonlinear code on difficult code it was pretty much impossible to uh uh decompose your problem into constraint. You couldn't test all possibilities and find a contra example. So you weren't able to fully formally verify uh your um your code if you have some code that was that was difficult.

So what you do is that in general uh what what was done is that you would adapt your code or at least the model of your code to the tool that you're using that is the prover and you're going to say okay this times out because it's too difficult let's make it a bit less difficult. So what you do actually uh what you we did in the past was it's too difficult let's make my code less difficult let's adapt the code to the test which is of course not the good way to do things you want your test to test your code and not um adapt your code to the test right but I'm not I'm not criticizing it was very difficult again uh it was something very very difficult um and sometimes even impossible um so

that was before I now what Does II change in the wall process? This is uh tool agnostic by the way. This is like I'm describing the whole process without any names of tools just for it to be uh to be clear. Uh so as said uh like at the end the formalization and the creation of the spec is the most important thing because you can prove something uh that we don't care about. Uh and it doesn't say that you do not have bugs. You can prove some things you you we don't care about. you can forget to prove things. So the most the most difficult part was still the specification process but everything was hard in the process overall. Um and then um well I explained already but uh the

proof was hard for several reason and sometimes it was impossible. So now with II so I'm going to come back here. This I said easy because it's like uh it's still the same thing. Um and it was easy before but It depends on your system. Of course, you're going to continue to write your specification in English. And now we call this a prompt. Basically, uh you describe your system in English, what you want to do, what it the guarantees it must hold, etc. Now the formalization of your spec it's not easy uh very very easy but it's easier because you do not need a lot of uh skills in mathematics to actually ask an AI and go back and forth and take an

English specification and make it mathematics. This doesn't mean uh it's like very easy to fully cover your protocol with all of the specs you need. It means that the process of taking English to mathematics is easier with AI. um than than it was before. That's for sure. Now, this is where everyone is talking about formal verification on uh on X and on Twitter. It's basically because it changed a big thing here on the proving side. It unlocks a new way to do proving. So before if I go back I said hard or impossible because we use SG solvers that are deterministic tools that cannot formally verify um I would say nonlinear code or difficult code. Um

here we can still use SMT solvers and they work very well in some easy cases but we can use another tool that is writing manually a proof as a mathematician would do uh for a theorem. Um, and you I'm sure you heard about OpenAI. Uh, and they're doing a lot of this actually when they prove all of these theorems. They're basically sending a bunch of LLMs and they're saying to these LLMs, please prove this to them using this and this hint. Please try to prove that it's correct. And the LLM is going to use classical mathematical techniques and write, oh, if this, then we could infer that, etc., etc. because the LLM has been trained on all of the mathematics of the world and is better than 10 PhDs at mathematics.

Uh so now basically what was impossible before because we didn't have infinite money to pay mathematical PhDs is possible now to prove using uh a classical mathematical proof way because we have infin infinite money to pay uh PhDs in mathematics because they are very very cheap and they run in data center in Texas. So uh we can now use this new technique. So it it unlocks a a new way to prove and this is why everyone is talking about formal verification on X. It's not because like uh formalization is now easier. It's because we can unlock a new way to prove things which means we can prove every code that is correct. Um uh and that's

that's why everyone is talking about it on the formalization part on the spec part. It helps but as it helps on every software engineering task. Uh now what's left for us uh the human um this is still as said before this is still the most complicated thing to do is to ensure that the specs you uh that you've written in English and in mathematics have a full coverage of your code that you completely understand your code and your system and you're able to describe it fully so you do not miss anything and that's still the most complicated part. Now, uh if if um these models are capable of proving things

that no mathematicians uh ever found, maybe they're also capable of doing that. Uh and that's why we try to understand by uh partnering with uh with Gemini. Uh thanks to them for giving $400,000 worth of tokens. Uh and um now where where we headed? So as said we got the front access on the on on every Gemini models in the last few months and we tested uh with a lot of tokens if these models are good at proving we already know uh open has found that we has found that it's really really easy to prove but are they good at completely um understanding the wall the the the wall the wall architecture you have and

specking everything that you're doing. It's actually like close to very very good and close to like human expert uh to be honest especially if you contextualize is it uh in a way that makes sense. Um so I I do not have data here unfortunately because uh uh well they gave us the tokens but they do not gave us the the right to spend uh to to share the information yet but I I can share orally. Um so it's very good at finding gaps in existing specification. So if you give a context and say to the model with a threat model you're going to give oh look at that look at all of this specification for this exact threat. Do you think it's it's like full and correct? It's going to find gaps. Uh

in general these gaps are are are very good. Uh and it's also very good at writing specs from scratch by just reading the code. Ideally you want to spec to write all the specs before doing any code. Uh, and ideally you you have like your wall spec um ready before doing any code and you launch that to the AI. Uh, but it's it's still good at like going on the other way around which is reading your code, understanding what you're trying to do, writing the specs out of that. Um, and this is like very good at understanding misalignment in the architecture. So the the conclusion of that for us is that um to us at least uh the the future of vibe coding or the

future of coding with AI includes formal verification in some way. Um because these models are really really good at implementing but the bottleneck is the review is the fact that uh when these models are creating a bunch of slope you do not know exactly if this slope is correct. You can do some end to- end test but you will never uh you will never get the full length of it. Uh but with formal verification you can just shrink enormously the review by just reviewing the spec. Uh which permits you to then have a proof that the implementation follow the spec. So you can have trust in your code and trust on the output of the II. So we think at the end we're going to rewrite or at least

um use formal formal verification native languages or make our current languages native for formal verification in some way. So we can v code like this which is giving all the specs to the II. The II doesn't even like give me the code but just give me a proof that it matches the specification I give I gave the II. Um and we are doing a tooling that is like following this vision that's called Veri as the name of the company and it's a small lean EDSL. So basically LIN is the programming language for mathematics.

Um and the idea is that it's following all of the vision that I described you before. Uh you can either import your solidity deterministically and try to formally verify it with this new method of proving not with SMT solvers. uh or you can directly vibe code using verity and it's going to compile to byte code and it's going to verity which is lean at the end of the day it's going to compile to bite code and you can deploy your smart contracts directly in a fully uh lean native way or formal verification native way. Um and yeah that's uh that's it. Uh thank you for listening and uh have a good day. Be safe out there.

Do we take questions? No. Okay. >> Thank you. Next on stage we have a talk by Christine. The topic is finally showing over to you. me. Yeah.

>> Yeah. >> Hello everyone. My name is Uri. I work at Fortify, an institutional MPC wallet. And today we're going to talk about two different types of technologies for keeping your uh onchain funds safe. Um, one is going to be onchain multig and the other are NPC wallets. So today we're going to explain what an onchain is, what is an NPC wallet, how can you combine the two together and what are the remaining gaps mostly

on the wallet side. >> So I assume most of the audience already knows what safe is. uh safe is a smart contract uh that holds your funds and requires uh an M out of N signatures in order to move the funds away. So as you can see here in the screenshot whenever you set that you're safe you configure a set of signatures which are the owners and you set up a threshold and at least that amount of signatures have to sign before uh any action is executed on the safe >> and it's very very popular as you can see some metrics here on the screen and why do people use onchain multist so

the obvious one is that um that way you don't rely on a single key uh taking the funds away, right? And you can distribute it between different parties. Uh but also since it's onchain, it's transparent. You can see what the keys are. You can see what is the threshold. You can see the entire transaction history and that's a hard requirement for some users such as such as users that care about transparency and regulation. Um but the downside so from a security perspective the safe is only as secure as the weakest threshold amount of signatures.

>> Um also it has some operational complexities. Um it requires a lot of coordination between the parties um by design cuz we need all the different signatures. Uh but it also um makes it complex to rotate the keys cuz every rotation we want to add a key and remove a key. we we should regularly do will each time require a new round of approval and coordination and also since it's a smart contract it needs to be deployed on chain and if we deployed on several different event chains will have a different address and those uh safes could have different nons which is an operational complexity that we will need to manage.

So from a bird's eye level view, how does it work? Usually uh on let's say the name flow, you use a safe wallet UI to propose a transaction. Uh pass it on to the signers. Each of them will independently review it, decide if it's safe or not. If enough of them sign, we reach the threshold. We send it to the safe for execution. Uh but as we know this uh na setup is not safe enough. We know from pack where uh $1.4 billion were lost. This number was a lot more impressive a few days ago.

So we need to explore ways to harden on our security. And one such way to do that is an MC wallet. The key idea for an NFC wallet, which stands for multi-arty computation, is that you take a key, a private key, and split it into different shards. So, none of the shards can sign for that key, and we need to somehow combine them together. But that's where the computation part comes in. We don't actually take all the shares and reconstruct the key anywhere cuz that would be a single coin failure.

Instead of that, we do some sort of an interactive computation where each uh share key shareholder um is interacting and they are able to generate a signature together without any of them knowing about the shares of the others. And how this usually looks like in practice is that we usually split the key into two and require both shares to to construct and usually one share will be kept in a server or in a computer and the other will be kept in a mobile device. Um so the main reason to use that again if a mobile device is compromised it's still fine because there is another shared computer and vice versa. Uh so we're not um we're not totally wrecked

if a single device is lost. Also we can add to the MC wallet another layer of organizational controls which are offchain um and we uh can enforce them and since it's just a key it will be the same key across all chains. So we have a lower operation complexity compared to dealing with smart contracts. However, the downside is that since it's not on chain, it's not transparent and that's a nogo for DA and other institutions. And we also rely on our NPC provider.

>> So for most NPC providers, you are uh uh in self custody of your funds, meaning you have a backup and the servers don't have your share of the key. So it's not that the provider can steal your funds, >> is that if the provider malfunctions, you're not able to enjoy the MPC benefits anymore. So we rely on the provider for the security benefits. So we can use both. And the way that will look like is that we'll use the same flow as before except that each timer now will use an NPC wallet. So again, someone will propose the transaction and send it for all the owners to verify and sign except now

each of those owners will have let's say one share of the key on the server, one share on their mobile device. So each of them will be uh harder to compromise and then as usual we'll gather the signatures and send to the safe for execution. So what do we gain by joining and merging the two together? So we do not rely on a single key um to move funds away and that's because of the multi of the multi sync on chain right we do not just rely on a single vendor let's say NPC if you use several different vendors we can see that so each owner can use a different vendor it's still transparent

it's still on chain you can still see who are the keys that can sign for the safe I want the transaction history we do not rely on a single device that's because of the NFC side, we can add another layer of offchain organizational controls on top of our smart contracts. Um, however, there are still some downsides to this um to this approach. So, we still have uh the operational complexity of smart contracts on chain and whichever controls we add on top of the multisync will not be on chain, will not be auditable.

So there are a few capabilities that we expect all wallets including MPC wallets to support. One of them is risk detection. We expect our wallets to tell us if we're trying to do something uh potentially dangerous or misleading or let's say sufficient attack. Maybe we're trying to move funds to a known malicious address and so on. We want the wallet to tell us hey look more closely here. We also expect wallets to give us some sort of simulation where they're trying to predict what will be the outcome of the transaction. And we can compare that to what was our intent.

And also we want to be able to label addresses and not compare addresses by to by give them uh human readable friendly names. And um wallets usually have some permission and access control. We can set different user levels, different visibilities. We can um uh whitist certain recipients, allow only outflow certain amounts or for certain periods of time and so on and so forth and all of these rely on correct decoding transactions.

Unfortunately, decoding state transactions is not a straightforward uh way like we have with usual AI coding for smart contracts. And the reason for that I'll go into a little more detail on the journey that a transaction has to go through in safe. So someone has to propose the transaction and send it to the signers except that the signers are not signing the transaction um that the safe will execute. They are signing a permission for the safe to execute that transaction and that permission is a hash. So it's not just decoded with an with a

then later all the signatures are collected and all that part happens offchain. Let's say it's safe servers. Then it's submitted to the chain to the safe smart contract. The safe then counts and see if we have gathered enough signatures to clear the threshold and also make sure that all the permits actually agree with with each other for the transaction that the state should execute. >> So the signers don't see the execution at the end. They only see the hashes. So we as the wallet see the hashes and we need to decode it.

And that's not the only problem. So we have different hash versions for different state versions different versions of a smart contract say a safe can send a bash and that's another uh level of complexity they can use a multisand which is a fat format and not a we can have nested safes where one safe or another safe or we can send to several different safes in a batch. So that all adds a lot of complexity and the difference is pretty big. We can see here on the left how it looks like when it's not decoded and the right when it is decoded. [laughter] On the left here we see the recipient is a proxy token. We don't actually see

that it's a transfer. Uh we don't know which fund which token. On the right we do see when it's decoded. We do have some simulation results which we see how many tokens are leaving the sender entering um the recipient. Uh we can see that they have actually human readable labels. In this case they're both uh safe smart accounts and that's not just for us for conveniency for us to look at it. It's also um this data is fed into the risk engine of the wallet and also into its policy engine. So it's actually critical to unlock most uh security features.

>> So think I skip a slide. No, >> how does the coding work today? So you have an option to call safe API for decoding and usually we have to use safe API anyway for all the offchain operations I told you about in the last slide. uh proposing a transaction, verifying, signing and collecting signatures. The problem with that is that um we're using uh both the safe UI to propose the transaction and using safe also to verify it and we would prefer to use different vendors for this. We don't want to verify with the same service

that also proposed the transaction. And uh unfortunately uh no wallet today does this. Uh most wallets don't uh decode uh safe transactions at all. And those that do use safe API. So one way to circumvent this is to use independent verification decoding sorry u you decode separately at the world level not call the API. Another option is to propose safe transactions from the wallet and uh say initiate transfers or create safes deploy them uh add new owners to the safe change the threshold.

Um, unfortunately something that vast majority of wallets don't do today. Even the more basic action of just seeing the balance of your safe is usually not supported at all. So here I uh looked at uh three wallets that I found had the most advanced and robust safe support. All of them decoded but using safe API. Only Empire also decodes inter. The other two don't. Um, Rabbi and Empire are browser wallets and 45 is an NPC wallet. So, not exactly one to one. Um, in all of them you can see the safe balances but you cannot send

transfer out of the safe in 45. Uh, in 45 you do have an integration in the policy engine. So, you can reason about what the is trying to do. uh in Umbar you have it uh linked into the risk engine and in Ravi you don't and in terms of initiating uh safe transactions from the wallet we only have Amar that allows you to create an existing safe uh that exists on one chain on other chains and that's basically it. So to sum it up um there are two different types of technologies multiig and MC. You can use an MC wallet as a signer for your safe and the reason to do that is that you add another uh layer

of uh security by not relying on a single device being compromised and you can add another layer of controls by adding another policy layer that is offchain. If we do that, we do lose some transparency because that layer of offchain uh policy will not be transparent and auditable. And if we want to use an MPC wallet as a signer um for our onchain multic, we need to make sure that it can uh decode. Preferably, it can do it independently, but none of the wallets still supported today. uh we want to have visible balances and we want to uh be able to initiate uh as many transactions from the wallet itself which importantly today is a bit

lacking. So one of the calls for this talk for all the wallet builders out there uh please help us uh close this gap. >> Thank you. Thanks for the talk. Um, we are going to have a break right now. There was a speaker who hasn't shown up.

So, we are going to have an hour break right now till 5. Thank you. Hello everyone.

So we have a paradox here. How can an owner both be and not be at the same time? And we have the same question for a module. where uh for modification is headed with the next frontier models. Uh so I'm going to share a bit of that work after.

Okay. So let's start. already knows what safe is. Uh safe is a smart contract uh that holds your funds and requires uh an M out of and it's uh very very popular as you can see some metrics here on the screen.

And why do people use onchain mold? I call it

t check. Check. One, two. One, two. Check. One, two, one, two, one, two, one, two, one, two. Check check check check check.

One two one two one two. Check. Check. One, two, one, two, one, two one two one two one two one two. One, two, one, two. Check, check, check. Check. Check. Check. Check. One, two, one, two. Hello.

Heat. So the obvious one is that um that way

you don't rely on a single key uh taking the funds away, right? And you can distribute it between different parties. Uh but also since it's onchain, it's transparent. You can see uh what the keys are. You can see what is the threshold. You can see the entire transaction history. And that's a hard requirement for some uh users such as DAO such as users that um care about transparency and regulation. Um but the downside so from a security perspective the safe is only as secure as the weakest threshold amount of signatures.

Um also it has some operational complex check. Hey, check. Hey, hey, hey, hey,

check. Hey. What? Yeah. Testing.

Okay, there we go. Okay. All right. Crystal. Okay.

Hi all. Next up we have a talk on one year later surviving the operation by over to you. Thank you Aisha. Right. Hi everybody. I'm Roxan Bardnos from Zero Shadow. I head up uh risk and security management focusing more on the proactive security side at zero shadow. So I was supposed to be speaking on with my client and peer Ivonne from 1 in. Unfortunately, he

wasn't able to make it. So I will be taking over. So we will be focusing on assurance sock 2 ISO 271 and and how it works in terms of the framework that zero shadow has developed security risk management. So when a business achieves ISO 271 or completes its SOCK 2 audit, it's an important milestone.

But what happens next? What happens the next day, the next week, the next month? The risks are still there. The business is still changing and people still have to operate those controls. That is what I want to talk about today. security risk management or SRM, a security risk management framework that zero shadow has developed and I want to talk about how our partnership with 1 in developed from understanding their exposure into embedding security in the way they work.

Right? So there's been a lot of trening on LinkedIn regarding Binance. Um, and I thought that Binance, the Binance incident brings this conversation into focus. Um, here is an organization that has publicly announced sock 2 type 2 and ISO credentials and has now reported a serious security incident. That does not mean the standards are worthless or that the incident proves Binance treated compliance as a tick box. What it does remind us is that insurance or assurance cannot guarantee that an organization will never get breached. It provides confidence about

specified aspects of a program. It cannot remove every exposure or anticipate every change. The problem for any organization is achieving or or the problem for any organization is when achieving the report becomes the objective. So they work towards sock 2 um attestation or their ISO 271 uh certificate and they think hey the job's done. But this is where the work behind then loses attention afterwards.

A control still needs to operate when someone joins, when an application changes or when an unusual transaction appears. That is the connection between SRM. We keep asking what could hurt the business, whether our response is working and whether our people are prepared. So let me bring that back to how the journey with 1 in started. The first step that we took with 1 in with the partnership was developing a shared understanding of 1 in's risk exposure. Before we could build a useful

strategy, we needed to understand where the attention was required. Now that meant looking beyond a list of technical controls because technology is just part of it. the systems, access and infrastructure that supports the business. That's just a single part. But also what we need to understand is who operates those systems, how ownership works and what happens when an issue needs a decision. Then there is the operational picture.

What visibility does the organization have? How do you or how do concerns reach the right people? What would happen if a routine issue became an incident? The assessment that we did with 1 in gave us a starting point for those conversations. It helped us move from a long list of possible improvements to a shared view of what matters most. That was the foundation of our journey. Understanding the exposure, recognizing the gaps and agree where to act. The security strategy could then develop around the realities of the business

with a clear reason behind the work we were asking people to do. Sorry, I think I need to go one back. All right. So once we understood the exposure, we then started prioritizing. We knew we could not treat every gap as equally urgent and completing the easiest tasks would not necessarily address the most important risks. We focused attention on the areas that had the greatest potential to impact the business, then worked through how those

risks could be mitigated. That meant agreeing what needed to change, who could make it happen, and how would we know the action has addressed the risks associated with that control. Now, as the work progressed, the strategy became more informed. We were able to connect immediate improvements to the longer term direction, adding value right from the start, rather than dealing with each requirement as isolated tasks. So we've removed the siloed approach and we took a holistic approach. In one inch's own account, we saw the operational areas that needed attention. Um software as a service, access removal, cloud

resilience and configuration. Um endpoint enforcement and clearer control on ownership across the business. Now these are examples from their journey. This is SRM in practice. This is what security risk management does. The exposure gives us the reason to act. Prioritization gives us the order. Ownership gives us a way to get the work done. But even a welldesigned technical team or technical control depends on the people expected to run it.

Right? So this is the strongest example in one inch's journey. Policy acknowledgement move from 47% to 100% of employees in scope. The interesting part is what changed underneath that number. When the process relied on slack reminders and goodwill, people still had competing priorities. Once it became systematic, the organization had a clearer way of making the task happen. There was one source of truth. Monthly reconciliations between HR and compliance records helped keep the population accurate. But the 1-in

team built automated nudges. They named owners and leadership escalation meant outstanding actions had somewhere to go. That is how one in started changing habits. They started changing culture. They made their expectation clear. Made the action part of the routine and gave people the support and accountability to follow through. Acknowledging a policy does not on its own prove that someone understands it or behaves securely. But the example shown shows how an incomplete process became a repeatable process. The same thinking applies to the people running access reviews,

approving changes or reporting incidents. The first step is intent. Understanding the intent of the organization. Ivonne and the broader 1 in team deserve the credit for embedding that change. Zero shadow guided and challenged the program, but their leadership and teams inside the business had to make it work. So we know that preparedness starts with policy acknowledgements understanding the intent of the organization. So how do we take this further?

Preparedness is where we look at whether people can act when the situation stops being routine. Having a document available is only part of that. We need to ask can people recognize the s the signals that matter. Do they understand what needs to be reported and where to raise it? Once something is reported, who can make the decisions? The team needs to understand its authority, escalation parts and the actions it can take to contain the problem. Then we need to practice and exercise helps reveal whether people understand their responsibilities and whether the

response works with the systems and dependencies dependencies they actually use. Finally, we need to learn findings from exercises, audits and real incidents should influence priorities and controls. Otherwise, we keep producing reports while repeating the same weaknesses. Now those are the SRM operating principles. The point is that preparedness has to connect the plan to the people expected to act. Your people are your biggest assets but also can be your greatest weakness. Their understanding, judgment and ability to work together are part of the

organization's resilience. So let's talk about internal audits. and how expectation met operating reality. Zero Shadow conducted the first internal audit for 1 in bringing into focus 1 in's expectation versus the operating reality. The observation window that we had brought those lessons into focus. These are the themes that came through in one inch's own account.

One's expectation, one expectation was that you can fix the gaps before the audit. The reality was that the controls still need to operate throughout the period because when a failure appears, someone needs to see it, understand it, and understand its significance in order to act. Another expectation that the team had is that security will drive compliance. But security cannot perform every control across HR engineering and the rest of the business. Each team needs to understand their own part in the ownership and what they contribute to security um in the organization.

Then there's the assumption that strong technical controls will be enough. But those controls still depend on people making the right decisions and performing the right actions consistently. This is what embedding security into your organization means. The control becomes part of how the organization works and the evidence reflects that it works. That was an important shift in the journey. less dependence on someone chasing an order task and more ownership of an ongoing responsibility.

So the assurance milestones do matter in every organization. One in achieved ISO 271 certification in 2025, maintained it through its 2026 surveillance audit with zero nonconformities and reached its sock 2 milestone in 2026. Zero Shadow supported that work through activities including the internal audit ahead of surveillance and participation in auditor sessions. But the outcome depended on the program the 1-in team was operating. It is also important to be precise on what is so and what is ISO 271 about. Sock 2 type 2 examines control design and operating

effectiveness over a defined scope and period. It produces an attestation report whilst ISO 271 addresses a management system that already includes risk management and continual improvement. So security risk management belongs within that picture. It keeps the underlying disciplines active as the business changes. The issue with the tickbox approach is allowing the report to become the finish line for us. The more useful question is can the organization sustain the work that supports the assurance and can its people respond when something happens despite the controls.

So where is one inch today in their journey? Their journey currently reflects an ongoing proactive approach to security. They've reached important assurance milestones and made parts of their operating environment more systematic. The work continues as the organization changes. Our partnership extends through assurance support and operational security work. The broader SRM responsibility remains active, continuously reviewing risk exposure, assessing whether the treatments we have in place are working and respond when risks emerge. That requires ownership inside 1 in alongside advice and challenge from zero shadow. Now this

also supports the business conversation. A trady partner wants to understand who is accountable, how risk is managed and what evidence supports the answer. A functioning program gives one inch a stronger basis for the discussion. It also creates a foundation for assessing the additional requirements of new and emerging markets. That does not guarantee market access or mean a breach cannot happen. It means the organization is better placed to explain and manage its exposure. You can see the value of that ongoing work in how one in describes the payoff.

So this is what they look at it from this perspective. Their due diligence conversation became easier to support with an established certificate, a testation report and policy pack. Structured vendor management helped with assess suppliers and respond when others assessed them. They also described greater confidence from investors and leadership and an ability to strengthen their posture while retaining their DeFi operating culture. That is the commercial connection to SRM. A functioning program gives the business a more credible way to explain its risk management while helping the team operate more consistently. So let me close with the four lessons from their

journey. First stock two type 2 adds examination of operating effectiveness over the period. The important idea for our discussion is that the controls need to work as part of normal operations. The broad statement about 2026 losses is one in framing rather than a claim that an audit predicts or prevents every exploit. Second, compliance can help expose weaknesses and establish useful habits when the work stays connected to the underlying risk. Third, culture needs visible ownership. Their policy acknowledgement example shows the difference a systematic approach,

automation, and leadership escalation can make. Finally, a D5 business can retain its operating culture while developing the assurance its institutional partners need. Bring that back to our starting point. The journey began with understanding exposure and prioritizing the gaps. It developed through strategy, controls, and people's habits with assurance marking progress along the way. I will end with saying assurance is a milestone. Security risk management is what the organization does every day. Thank you.

Next we have Robert and the topic is why is AI missing these bugs? Over to you Robert. Thank you. All right. So, do I reset this? Okay.

Um, all right. Hi. Uh, I'm Robert, uh, also known as Rob Bri. Um, I'm from Hackhack and Accretion. So, we do, um, AI audits with Hack and Solana, um, human traditional audits basically with accretion. And I wanted to share um our learnings about AI audits over the past year. Specifically um about bugs that we've been um finding when the human team does an audit that like an AI run um missed either like in the same audit or like in a benchmark. Um and yeah, this should help us improve

um our auditing uh agents. So first of all, um, if we look at the trajectory of AI, how it's been improving over the past year, it's very clear. It's just going up and to the right. It's just getting better and better. And um, the message is clear. I don't think it's going to stop. It's going to just keep getting better. And if you think you're still smarter than AI, at some point it will overtake you. So basically we should generally think about um a paradigm where the models are smart uh smart enough to find all bugs or like to will be smarter than us and if we think we

we're smart enough to find bugs then they will probably be able to find these bugs as well. Um however this graph obviously is not about bug finding but it's like just generally I don't know um some benchmark that the that artificial analysis came up with. So from our own audits um we've run salana audits for like two years and also even more than two years outside of accretion. Um and in that time um AI has been getting better and better and um during our current audits and when we benchmark older audits against our current AI setup we see that AI

consistently finds like 80 to 90% and sometimes even better in some cases even 100% of uh the high or critical findings that we find with the humans. Um so the question here is obviously okay why is it not 100% and what's what is this 10 to 20% of bugs that creates this gap and this is basically what this talk is about. Um let's see so the auditing process we use at the moment is generally a loop. So we start with a um a human audit where we audit the codebase, the AI audits the codebase. We have a list of findings and the AI has a list of findings. We can

compare um and then figure out okay these findings were found by both of us. These findings were only found by AI. Maybe these findings were found only by humans. Um we analyze that um uh that result. we figure out okay what happened here and then basically we just try to improve the AI auditor also maybe we try to improve our human approach to auditing um and then we just repeat so that's basically the the the cycle we've been running for the past year or so um and what has come to our um attention is usually the failure points where AI doesn't find bugs is mostly about context or consequences or like impact so Just small detour to that I also

wanted to mention um AI definitely also finds bugs that humans missed and for me generally the the shape is something like this um if you look at this code I don't know if you can see everything um it's a lot of words and those words look very similar and it's for a human it takes a long time to realize what could would be wrong here um the mistake here is that in the last line we have liquid uh liquidity provider uh feebs Um, however, that should be liquidity protocol feebs.

You could say, okay, I will find this during an audit as a human, but it's super easy to to miss something like this as a human, while for an AI, this stands out like a sore thumb because the tokens are just um different than what it expected. Um, so yeah, I mean, this is the typical shape for what an AI would find that a human doesn't. Um, and now back to what a human finds that an AI does it. When we first started doing AI audits, um, the simplest shape of these bugs that humans found that AI didn't find was just missing dependencies. So you would give um your codebase to an AI auditor and the AI auditor would um try to find bugs in

there but it didn't have the context of maybe the programs that you would be calling from your program. So obviously to close that gap the first thing uh that you do is you add the dependencies that your program is calling to the context. Uh so now you have maybe instead of one program in the context you have three programs in the context. Now if you think about it, oh this is potentially recursive. So what if the bug that we have is really complex and it's somewhere at the intersection of our program calling another program calling a third program. So if you want to have all that in our context now we have like a context explosion. So now we would would have in this case what um seven programs.

Uh obviously this would go potentially even further. So this is basically the first main gap. Uh just dependencies. Um what we currently do is we just provide one level and that works quite well but sometimes you want even more. Um a concrete example here is we had an audit for metadow um where an admin instruction would call the metad program here it's called futur that's what the program is called and the future key program would call the squats program on Solana. Everything worked fine. Uh it works in the tests.

The AI is [snorts] like okay that's fine. However um we realized later on uh that if the admin is actually not a regular wallet but it's a squats program itself. So a multi-yc wallet um and the multi-stick admin calls the future key program and then the future program tries to call call squads again. this is going to fail on Salana because we have like a ABA type of re-entry which is not allowed on Salana. Uh so AI was missing this in basically all our test runs simply because AI didn't consider that the admin uh could be uh squads itself because the definition of this audit was simply not

explaining properly in the context that uh this admin could also be squads. Um so another version of this is um we had a AI audit bridge and it came up with one type of issue related to token 22 on Salana. So what happened is um whenever you transfer funds to the bridge and there's a transfer fee attached to the token, let's say a 10% uh yeah a 10% transfer fee, the bridge only receives 90 tokens instead of 100 that you sent and then the bug was that the m the bridge will mint a 100 tokens on the upper chain. So, um,

we saw, okay, that's that's an interesting bug. But I went and looked manually at that issue and realized, okay, that's actually not located just to the transfer fees, but it's completely ignoring um all this nasty stuff you can do with token 22. Um, and specifically uh with token 22, is that the next slide? Yeah. What you can do is you can create a clo closable and a permanent delegate mint. So um what we came up with basically on the same bridge um you could create a new mint call that mint ABCD with pump at the end because that's going to be what we use later. We make it closable and uh permanent delegate.

We mint a billion tokens. We bridge those tokens from Salana to Ethereum for example. Now we have a billion wrapped tokens on Ethereum and a billion tokens held by the bridge on Salana. Now, because um we have permanent delegate enabled on that mint, we can burn all those tokens without owning them because we're like the super admin on of that mint and the supply becomes zero of that that burn, but the wrapped token still exists on Ethereum. Um and what we can also do now, we could close uh the mint completely and now that mint is basically as if it had never existed. And what we could do is we could take that ABCD pump mint, go to

pump fun and create a new pump fun token under the same mint account. And uh Pump Fun would just accept it because it's a fresh mint and you can you know do your Pump Fun launch or whatever. Um and the problem now is that anyone who buys that token on Pump Fun and then later tries to bridge those tokens with that same bridge to another chain. Um, we can just take our previously bridged tokens and unbridgeidge them back to Salana and basically steal all the tokens that anyone tries to bridge. Um, so the problem here is if you look at the bridge by itself, AI will not realize that you can do this ecosystem type of attack. If you look at pump fun by

itself, it will also not realize that you know you could do this ecosystem type of attack. But if you give it the context of the bridge and pump fun together, then AI could figure that out. Um, but the problem is it's not like they're directly related. So um the the the bridge will not mention pump fun directly in in its code anywhere and pumf fun will also not mention the bridge directly. So if you want to prepare that audit automatically, you can't be like okay look for any protocol it mentions anywhere and then include that in the in the context. No, you have to like kind of realize, okay, this is a whole ecosystem and we kind of have to give um the context more um stuff about the whole ecosystem,

not just about this specific program. Um so this was like a also a relaunch type of attack and here's another relaunch type of attack. Uh we had a light protocol audit where they were trans transitioning from anchor to Pinocchio and we were auditing this new Pinocchio version. Um and if you feed that only that Pinocchio version to uh the AI to review it finds some bugs but it didn't find this bug specifically because it involved a state transition between the old version and the new version. So basically what you could do because the program already exists on chain in the old version, you could create an account on the old version of the contract using a anchor specific

feature um and then upgrade the contract and now you could use that account that you created in the past in an unrelated or like in an old version of that program to um yeah to steal funds from the new program. So if you only look at the new version of the program, it doesn't even know about this existing history. Um so it doesn't even know you could do that. Um more specific, you could create an account have a zero like in the middle and in reinitialization it would think that zero means that account is not initialized and uh you could also have amount somewhere else. So you could basically you could basically steal a lot of money like all the funds. Um but yeah, the main part of it is if

you're just giving it the current state, it doesn't have enough context to consider. Uh like if it's an update audit, there's also a path that exists on chain that we might want to have in the context. So I mean all that stuff was basically uh we just need to give the AI more context and more more what we're trying to do more like more dependencies. We give it all the consumers, all the inherited states. So it just has everything uh that we could imagine. Obviously, we run into a bit of a problem there because context is limited. We can't just give it everything. Um so yeah, this is basically one of the main problems here.

Um one further thing is that um Solana specifically is um developing quite quickly. So um the knowledge cut off for a model might be six months ago but in those six months Salana might have introduced like three new features um and even though the model might be able to research those things it's completely biased um during the audit to not consider these things. So a human auditor here has a bit of an advantage if they're following recent changes to the chain. So for example when Salana introduced uh reducing slot times from 400 millconds to 200 milliseconds uh in human audits we were always reporting hey if you're measuring time with slots then uh this

time is h havinging basically but the AI basically didn't really report these things yet because it didn't consider that this change just happened last week. Um yeah, so another version which is not really context but just AI maybe being a bit dumb um is that sometimes it tends to find bugs but not reported at the proper severity. Um and because of that it might even make that bug invalid or we might not even consider it. So just one example, we had like one audit agent um finds a valid critical bug, but it thought it's informationational because um it thought you need 18.4 billion USDC to exploit it, but actually you needed

only 18 uh 18,000 USDC to exploit it because it didn't really consider the decimals correctly. Um so because of this real bugs can sometimes surface but they might surface like as a incorrect severity or like incorrectly um incorrectly um yeah ranked. So whenever you continue doing that audit maybe you will not realize that there is a real bug and you might skip it. So basically to conclude here um all these issues we can theoretically solve quite easily by giving more context to the models. However, as I said context

is limited and we can't just give her uh get give them everything. Uh because if you give them too much context they get also overwhelmed. So at the moment the way we see it is um it's a quite difficult task to kind of weigh how much context to give to the models, which context to give to the models and also figure out which context to give to the models. Um for example, if you if you look into a protocol um and you try to figure out what might be a weird part of context to give to the model, you might already be auditing the code to some degree.

Um, yeah, that's kind of the that's kind of it. So, um, yeah, you can find me here, hack hack and Christian. And thanks for listening. Ia and Martin over to you.

>> Thank you. Hi everyone. Uh Martin you have the Thank you. [laughter] So my name is Sophia and I'm a third year PhD student at KT of technology and my PhD topic is around smart contract security. Previously I work a bit on like patching smart contracts and expert generation and today we we're looking at most effective protections that one can have in their code. But before our talk uh a bit of promotion we are coming from uh Sweden where we have this research group uh on blockchain security and so supply chain where our group leader it's here with me Martin who is a professor at KTH. So we will be switching between us.

So uh yes, smart contracting variance protects against cyber criminal. That's our claim and hope we convince you by the end of the talk. So before we continue, let's make like a clarification of the terminology we utilize throughout the talk and through the paper. So we often discuss about invariance, right? Like auditing varants and uh how to use them for auditing protocols and developing protocols. Erh here we define them as the specification of your code. So the overall logic that you want to apply on your protocol. For example, if it's a flash loan that you're trying to implement, one invariant will be money must come back

at the end of the transaction. Now if you have this specification right, you have to be h to you have to write it in the code otherwise it's just a documentation a natural language description and it's never enforced in your code. So to make this apply in your code, you have a programming variant in which you write this in your code in the state of a in a require statement or a modifier. And what this program will do is that if well defined every time someone interacts with your contract on chain on the transaction there will be a runtime check. So your required statement will be executed and will ensure that your condition is valid. In the case of flash loan, it it means that at the end of the

transaction, there will be a piece of bytes that will ensure that the money came back to the protocol. So now way to see it for us is invariant is the overall rule. The perm invariant is the code condition that you write and the runtime check will be the one that will revert when someone is trying to hack you in simple words. So building on this um as I said in our team we are a few PhD students and master students and Martin and we often go over the exploits of the week and we read the entire blog thread and Twitter and we're like okay what happened in this smart contract hack and here for scoping we're talking about smart contract hacks not general hacks so it's

not about the compromised wallet it's about the code that was uh with a vulnerability and then we came to this hypothesis that a real attack or like a a smart contract attack came from a property that was declared from the protocol but never really enforced. So our belief is if we find those programming variance that should have been written we could have prevented this attack. So our expectation is the expected protocol property was missing a runtime check and that's what the hackers found and that's how they got the money.

So we are software engineer research. So how do we apply science to evaluate this? So we started from our very good uh repository defy hacklabs which is a community contributions of trying to replicate exploits in the form of proof concepts and uh we have a rich resources to understand the exploits and to trace which protocols which contracts on the protocol were involved and so on. And then we also utilize uh the onchain evidence. So it's a real exploit. We have transactions to track. We have transactions that we know that are malicious and transactions that we know that were normal usage.

And utilizing this we proposed the hardened version of the contract. So we kind of asked the question what would have happened if the missing environment was in the code and how that hardened contract will have survived against the PC against the attack transaction and how it it behaves on the onchain uh traffic. So we have two oracles here. The first one is the PC by the fihack labs and the other one is the uh onchain transaction replay which is we collect transactions and we try to reproduce them on the hardware version that we very carefully uh wrote.

So what does these oracles will tell us? So first the hacklabs will tell us and then the P will tell us whether the attack is being prevented but then the onchain transaction replay will tell us if we can prevent the malicious transactions and we can't uh preserve the normal traffic of the contract. So how how we managed to do this? So we had to build our own uh transaction replay tool and uh we built on sources of truth. So this is attacks already happened and we have all the resources that occur before. So here we hence we have a onchain trace that's the onchain trace that happened. So what we want is that for normal usage the onchain trace on the harden version has to stay the

same and the uh the trace for the exploit has to defer with the um harden version. So we collect the onchain trace which is O. And then since we are we are modifying the bite code of the contract. We want to ensure that our replay mechanis is sound. So we recompile the source code H in the setup that we will do with the harden version. Just ensure that we are recompiling the correct way which if you are in this room you probably know that is not an easy task. And so if we can have some replay fidelity in our tool, then we go and we check our harder harden version of the contract which is the contract but plus the missing invariant. And here this included modification. It's

targeted to this required statement. So we don't change the logic uh or the way the functions operate. It's mostly like what properties were the protocol saying that should be there but they were not enforced. So if R can replicate O then we check whether the harder version can have a similar trace as the recompile. So from here we will uh expect and analyze these two cases. So for the onchain um for the transaction replay we will expect or we will look for in which cases we story is unchanged and here the hope is that we maintain the normal traffic of the contract and then we will look in which cases the story is not preserved. So this transaction that is

it happened before and it passed why is it not passing right now and here we had two options. So either our invariant is operating correctly and that transaction was indeed malicious or we have a over restriction. So imagine for example it was a price oracle manipulation and we put a threshold that was too tight. And now Martin the floor is yours. >> Thank you Sophia. Um who has ever submitted an academic paper in the room? Who has ever gotten a paper rejected in the room? Ah, you're a true scientist.

So, so you know, Sophia could stop here because she has this the theory, right? Can I go back? I can. So, that's the theory. In theory, everything is perfect. You write an environment and the environment protects against cyber criminals and you're happy, right? There's nothing more to do. But then comes a reviewer and the reviewer say, "Yeah, Sophia, I can't accept your paper because you have to validate that. you have to show me for a year for real attacks that it actually works and this is where you spend another six months of your PhD or even a year you know just to walk and more and more and more and more to actually prove and that's what we show here uh so we took real attacks in defy hack labs that's the environmental data

sets so you know they are real in all possible sense in the sense that they are onchain sure and also in the sense that they are real money like there are real funds of losses is here. So real attacks for which we identify the missing environment. We put the missing environment recompile and we check that the attack is blocked. That's perfect. In all cases, the attack uh is blocked. The the attacker cannot uh run with the funds. So far so good. So here we demonstrate that the invariant would block the attack. But you know the environment could say revert always. then it also just freeze the contracts. So all those those

attacks are on real contracts. So those real contracts are real transactions, past transactions more than 100k. It's a lot of past transactions. One by one we rerun all those transactions on the new contract with the new require statement and we check whether we have the same the same onchain semantics whether we have the same behavior. Is that the same? Is that the same? Yes. Yes. Yes. Yes. Yes. No. Interesting. Yes. Yes. 88 98% of of Yes. So it's the exact same semantics. The environment doesn't break anything. Now why do we have a slightly different not a perfect fully perfect solution. Uh this is where it becomes very interesting. Uh reason

number one is uh is gas semantics. So you know etherm is the only primary language in the world where computation may depend on execution performance. let's say and so there is semantics with gas and see we change a bit the gas with the environment there are some obscure changes happening here sure uh but the most important interesting is actually what comes next uh so that's here my it was one of the million tokens uh which was pumped and dumped at some point not even dumped because it was hacked during the pump because of a missing authorization check So most authorization are done. Yeah. So missing it's not here. That's the

original code. You don't see it. So the high any any permissionless attacker could call this obscure family uh function here. The fix the missing environment because smart contract environments is this required statement here that it's a permission method. So only the owner can can call this uh this method. Good. Uh there was some pumping on this token. So we have you know a few thousands of of past transactions to look at. So we replay the few thousand past transactions.

Pass pass it fail. We look at it and it's it's not the transaction that is in deflab. It's a transaction that happened you know six hours before seven hours before. So we what we actually detected in this case is that we we detected you know canary testing of the attack. Some people who tried the attack, it was not the final attack with all the funds, but they actually triggered the exact same violation of the security property on chain uh and we could detect it. So this fully validate the soundness of the approach because not only we detect the one big attack but you also detect all the canary tests before by definition because they violate the same security environment.

Um and that's the beauty on on chain all canary tests can be seen uh including uh the Binance hack you know there were some carrying test 23 minutes before the actual hack um which means you know people should do live monitoring but yeah I don't want to uh to digress here um another example is the why earn uh problem um so it was a it was also a missing authorization check like this one. And so you you make the the method the function permission. So far so good.

It blocks the attack. We're happy. Oracle number one is happy. Oracle number two is replay the historical transactions and we see you know quite a few of reverts. They all look the same and they look very legitimate. Um and so in this case it means the the the the reverted transactions were about the keeper transactions which are part of the protocol. The protocol add some permissionless methods to be called by keepers and in our manual analysis uh we missed that aspect of the protocol. So we wrote an environment which was too strict and by replaying on the historical transactions we detected that this environment was too strict.

So it also validates you know the soundness of the full approach uh not in yes we did a mistake uh but it does validate the soundness of the approach. So to conclude smart contracts environments are your best friends for sure. Uh and we know that in the community you know solidity is is perhaps the one language with the most the highest density of environments and that's good but it's still still not perfect. Um and we demonstrated here that you know so that's many of of of us are auditors here when when you get an audit uh you know finding you might say okay what's missing is I should actually call if then else do something else not

necessarily you know fixing a security problem doesn't mean necessarily being imperative in your fix it mean just restoring the security environments and then whatever goes wrong before there's a beauty on environment whatever goes wrong it will still be caught by the security environment So you have to as as developers and as auditors we have to understand you know the core security properties how they are translated into into require statements and a require statement becomes something which is falsifiable we can get it falsified on the PC uh we can get it falsified on the real attack and when you have historical transactions you can replay the historical transactions

and this is where you can say hey Martin yeah thank you very much uh for this research but uh you know for a new protocol we don't have historical transactions which is correct so this aspect of our work of the historical transactions is to validate the entire you know framework consistate framework um in practice you don't have this but what we want to to what we claim and what's what developers auditors all of us in the security committee should do is that we should be obsessed you know days and night by identifying the missing environments uh with our you know poor brains and also with super intelligence artificial intelligence or I don't I don't know exactly but yeah we can you can you can

use AI to find the missing environments to improve the environments and uh and to improve the overall security of of our protocols uh thanks a lot Sophia thanks a lot for your attention we can take a few questions questions identify.

>> Yes. So in the paper we proposed like a taxonomy actually on this area there's a few related work and actually the first one was by the mo in h so there are like um your classics access control your classes uh price page um there were approximately eight cases that we identify and a few of course are related to uh business logical But most of them could fall into these categories of uh admin roles, permission signed, uh price manipulations and dependencies.

>> 22. How many of those people for example authority are there some Um so I will say that um

um we maybe it's not easy for me to answer these questions because I got all the resources right I got sources afterwards so I was not in the mind of developer and it was not an easy task for us to you know abstract We found some cases in which everything was completely wrong like all the accounting was completely wrong but then we were thinking okay what property should they have thought about and so for example the one of them was like only uh money from the account involved in this operation should be modified and with that you will have prevented uh I would say that u many of them 20 out of 28 were like very tough to identify but we are from the

mind of postmortm. >> Thanks. >> Thank you. >> Thank you for the talk. So we are heading towards the end of the evening and now we have the last talk by yes and the topic is safe staking a runtime security framework for LSDs. Over to you. Yes.

Hello. Yeah. Cool. Thank you. Uh yeah. So my name is Yash and uh I work as a smart contract engineer at Ethofi. And today I want to talk about uh safe and in general how do you protect uh a D5 protocol? uh like if you're if you're building a protocol yourself or if you're just like a regular user of a protocol, how do you know that uh any product that you use onchain is actually safe for you to use and safe for your funds? And uh yeah, uh I don't need to talk about this too much. Uh this year has been quite uh quite a wild uh uh quite a while in

terms of uh smart contract hacks and D5 hacks. And uh like mostly if you look at uh what has been happening this year, it's not exactly someone figuring out a way to hack a protocol like hack a smart contract or hack like some in like uh logic uh in the code. It's mostly around uh access control. It's mostly around operational keys being leaked. It's mostly around like some pipeline going wrong and something like that. And uh uh and uh if you if you are a user and if you're using uh D5 protocols and you want to like uh be more confident that uh is the protocol I'm using actually safe or not. What are how how can you actually do that? So these are like

three questions that you can probably ask yourself before putting your money in any protocol. And question one is who can move my funds? Question two, excuse me, what stops a bug from draining? what stops a bug from draining them and three what happens when something breaks uh anyway like uh how does incident response of a team look like uh etc and uh the approach that I want to talk about this is something that we applied at etheri and uh I think it's a really good security model is the Swiss cheese model which is like very simple it basically means that at every single layer there are probably some things excuse me sorry for my my coughing uh there probably a bunch of

things uh that can go wrong and these are the security holes through which attackers can find gaps and uh try to uh access uh access your funds. But if you stack a bunch of these layers on top of each other, then the chances that a hacker is able to find a gap through all of them and is able to uh uh break into break into everything and actually access your funds is uh quite less. And uh that is the whole point of the Swiss cheese model is that you just like add more and more security layers and more and more security features as much as you can think of and that just like uh exponentially reduces the amount of uh uh like surface that is available for a hacker to exploit.

Yeah. So the first uh so the first layer that I want to talk about is operational security. Uh this is everything around admin keys. uh control matrix uh pausing ability etc. uh one thing that I forgot to add in the slides here which is like very important is control matrix and uh uh the fact that like a protocol should >> [snorts] >> uh have a very clear and defined uh differentiation on like what type of access controls can uh move what type of levers. For example, let's say that there's a smart contract. There are some funds on it and there are some liquidity operations that you want to run and you can very clearly define on the smart contract that funds can only move in a certain way and you just need like uh an

operational key to like do that based on your discretion. There is there is no chance of loss of funds if your smart contracts are audited and uh verified uh that the flow is not broken. Uh in that ca in that case you can just uh you can just like uh uh give an operational key access to move those funds and um uh uh operational key access to move those funds uh and you can uh feel that okay like this is like um uh like good enough because like there is no potential loss of funds in that scenario. On the uh on the completely other extreme, let's say that u you need to give access control now to upgrading your protocol contracts that uh involves huge risk. Anyone who

who can get access to controlling your protocol upgrades can like change the logic uh and like basically steal funds. uh even thinking about like lower access controls like uh who can set some uh config parameters uh may cause a catastrophic uh catastrophic uh uh attack vectors for your protocol. So these uh these type of u levers need a much more uh secure uh access control and that's uh and that's where time locks and multisigs and high threshold u and high threshold uh uh controls are actually like quite useful. So it's always a good practice if you're working with any protocol to like check how their access control looks like. Uh do they actually have a policy where uh

super critical functions like upgrades and conflict changes are actually behind uh secure uh uh secure thresholds because uh what we've seen over the last years a bunch of uh a bunch of hacks have happened because like someone just like uh blindly signed some transaction even it's even if it's behind a multisig uh uh it's not behind a time block. So you didn't get a chance to actually wait and see uh uh like uh what's going to happen on chain. Uh the next fever is like on smart context. Obviously like if you're trusting your smart context to have uh uh logic that protects you uh that protects you then you definitely need invariance as mentioned in the previous talk as well. And uh this is uh this is

uh like quite uh like quite the norm in the industry that you definitely need like in invariance imposed in your smart contracts. You need to get them audited if possible. You should also get them formally verified. You should always have your invariance first tested, integration tested and and uh like run a bunch of static analyzers on it and and yeah, this is like pretty standard. The the next is also uh crosschain risk and I actually want to like uh expand this also like to third party risk as well like you might have a protocol sitting on Ethereum mainet uh and uh let's say like there are some crosschain uh let's say you have a token that is like deployed on some other chains but

uh basically what I mean by this section is that you also need to account for all the third party risk let's say you have external protocols integrated you have a crosschain uh protocol integrated Ed uh then do you actually have the best possible config set of for the security of those external layers? For example, we all know earlier this year uh uh RSC got hacked because they were using uh layer zero's infrastructure and they were not using the correct config. So instead of using uh their uh their recommended config, they were using a one-off one DM which allowed them to get hacked. So can you ensure >> [laughter]

>> So can you ensure that before using any protocol are you actually use uh does that protocol actually have a correct config set for all the uh external external dependent dependencies that they have like uh there is no key that there is no like single operational key that has like very high privileged access. There is no like verifiers or for a crosschain protocol specifically there are like multiple verifiers etc etc. Uh and then yeah and then the final level is around active defense. This is basically like what do you do in the case that an a hack actually happens.

How do you act? How how can you ensure that you can minimize the effect of a hack? And uh the number one step for that is obviously detection. You you should always have monitoring. You should always have uh and that is where defining invariance is also incredibly helpful because if you know what can possibly go wrong, you can also create monitors to basically see if something suspicious happens. Uh basically that's how you define what being suspicious onchain is uh and if you def and if you detect anything like that you can uh start your incident response and go go move on to the next steps. The second step is containment and this is something that uh I feel has like the most value and that is because um you

need to have the ability to have granular control over what actions you can take in order to contain a hack. For example, a bunch of protocols have pausing ability, but uh but that is not really helpful if the only thing you can do is like pause the entire protocol. Because if the only thing that you can do is pause the entire protocol, that means that you would be hesitant in using that uh ability unless you're like really sure that something really bad is happening. And uh that is something that you should not have. You should never have hesitancy in order uh hesitancy in a situation where you believe something wrong might happen. So uh that's why having granularity and basically like

the smallest action possible uh is really helpful. If you know for example we at etheri we are a staking protocol we have a staking token called we and uh we have an integration with lido to manage uh uh like we hold some of our assets in Lido. So for example recently when the consensus uh validators uh got hacked when when what we saw was just that lighters having mass exits and we at that point of time did not know why that was happening. So we could uh uh since we have this granular control that we can pause like certain flows instead of pausing the entire protocol. We just took that action and paused uh flows related to lido so that if there is some exposure to lido that we're not aware of

right now we can uh contain ourselves from that and then uh and then after containing then we can investigate and find out what happened. Within a few hours we uh within a few hours we uh got the whole picture that there was some key compromise in some in some validators and that like there is no real issue to us and that's when we uh uh when we unblocked the flow and uh we basically like recovered recovered our protocol back to the original state. We were we did not hesitate in taking that decision because pausing does not mean that we are pausing our entire protocol. Deposits still work, withdrawals still work, bridging still work, rebasing still worked, everything worked. The only thing that we paused was our integration with IDO. And that

uh and and that granularity basically allowed us to have allowed allowed us to take that action that quickly without uh having any hesitation. Uh the way we have built our pausing system, it's also it also automatically. So like if there's if you're pausing a very critical action, it auto lists like within eight hours and um less critical actions have longer uh longer periods. We also have a feature we also have the ability to blacklist an address. This is something that we also did like very recently with the Binance hack where uh again like uh the Binance hack happened.

We did not know why it happened but the first thing we knew is that okay we can trace onchain like what are all the addresses that hold the uh that hold the uh stolen funds and we just started blacklisting those addresses and that is also like one lever that we could take there which just uh it does not mean that uh uh that attacker could not have uh could not have like move funds to another address bypass our blacklist by like rotating address faster than we were able to take action and then enter our protocol. But it's just like it's an extra layer of security. Like if we wanted to discourage the hacker from using our protocol to like launder the funds, he would not he would probably be discouraged because he could see that we

are blacklisting his addresses. So uh so that's what I meant initially like more layers of security. It's it's not a guarantee that your system is secure but it also add it just adds like more probability that your secure uh that your system is going to be safer and coming back to invariance. So if you have defined an invariant that means that if that invariant has gone wrong then like you are uh then that's pretty bad. Basically uh in that scenario if you have like defined like what going wrong actually means instead of defining just like what a suspicious activity looks like you can actually you can

actually wire uh wire that monitor to directly take actions without any human without any human intervention and that is what I mean by atomic pause but uh you cannot just wire that willy-nilly and you cannot just um uh you cannot just like wire any monitor to an auto pause because like if that monitor falsely fires for any reason then you probably have like caused uh caused your protocol to cause your protocol to like have some downtime that it it did not deserve. So we also have like a policy on like what it means for a moni what it means for a monitor to be promoted to actually firing an auto pause and that is a

number one policy is that the monitor should actually be deterministic. It should not be like monitoring something that oh it's over a threshold that means it's suspicious we should investigate. No it's a deterministic thing like we have an exchange rate for VA and the underlying TVL and if that exchange rate is broken then that means that yeah okay something bad has happened we should pause the protocol and start investigation immediately. we have a verified coverage of it like whatever we are uh whatever we're trying to monitor we can actually deterministically verify uh the sources the sources of like where the monitor is being fed from. Uh we test it and see that there are actually zero false positives over over a huge enough back tested window. And then finally the arm

is also uh the arm is also like our goal is to set uh set it to the smallest possible action uh that can be taken when that invariant goes wrong so that we can also minimize the blast radius if in case there is a false positive and uh yeah the same layers that I've been talking about also apply to all our other products for our for our cash product for our liquid walls and also for uh the a market that we So we basically follow these policies across uh uh all our um all our products and uh that's how we like ensure that we provide the uh safest product to the users. So if you are a user and you want

to put your money in any protocol um you should uh probably probably answering these questions and trying to find the answer of these questions would give you a very good uh understanding of like how the secure how seriously that protocol takes this uh takes its secure security and um yeah hopefully that uh will allow you to make uh better decisions with where to keep your uh money and uh yes same Yeah, thank you. See

you all tomorrow morning.