 Hello, everybody. Thanks for coming to the workshop on hunting and monitoring for on-chain attacks. I'm Christian Seifert. I'm a researcher in residence at the Forder Foundation. I primarily work with the Forder community to analyze attacks as well as develop strategies to strengthen the detection and protection value of the Forder network. Prior to coming to the Forder Foundation, I worked for many years in the Web2 security space on anti-malware, anti-fission and intrusion detection systems, both on the brief breach and the post breach side. Hey, hey, and I'm Dimitri. I'm from LiDAR and I'm the leader of the automation team. And this weird name is hiding a lot of things. We're working on security, on monitoring, on protection, on code analysis. That's all what we are doing in LiDAR. And prior to LiDAR, I've been working as the quality automation engineer for a lot of years and got a lot of experience in both security and quality. And I will join this workshop after the part of the Christian. Yeah, so the way the workshop is structured, there's two parts. So the first part is really around more kind of security research focused on how you can use monitoring to identify attacks on chain. And so we'll dive into some attacks. And then the second part, Dimitri will more work at kind of how protocols can use monitoring to secure their protocol. The Wi-Fi gods were not with us. So there's not going to be any kind of like online exercises during the workshop. But we've set up a GitHub repo with some exercises. And what we'll do here is kind of work through an example that hopefully gives you an idea on how you can put monitoring in place. So we all know that Web3 is getting hacked. Chain analysis last year estimated that it was $2 billion. This year, we already far exceeded that number. Now, that does not mean that all hope is lost. Now, one thing that is maybe a little bit of a misconception is that on chain attacks are atomic. And that once the transaction is mined, there is nothing you can do about it. But that is really not the case with the majority of the attacks that we observed. Really, what happens is an attacker goes through these four attack stages. So the first stage, they need to have some funding in order to pay for gas and execute the attack. Then they often prepare the attack that could include like deployment of a smart contract. Then they exploit the protocol, steal the funds. And then once they have the funds, they really proceed to money laundering. And even in the money laundering stage, as we've seen last week with the Binance hack, there are still some actions that can be performed in Binance, USCT, Blacklisted, the attacker essentially freezing the funds. So let's look at one particular example of an attack on kind of how these stages manifest themselves on chain. So we'll look at the Inverse Finance attack that was an attack a little earlier this year. $1.2 million were lost. Inverse Finance is a lending protocol, a collateralized lending protocol. And so the attack was essentially a price manipulation attack that allowed the attacker to lend or borrow essentially in an uncollateralized fashion. So let's look at each of the stages. So first of all, tornado cash funding. So what we see here is essentially the first transaction to the attacker account. So we're looking at EtherScan here. One thing to keep in mind is that tornado cash funding is an internal transaction, so you don't see it on the main transaction tab. So that's kind of the first signal. Now obviously, tornado cash is utilized for privacy reasons. So that in itself is probably not sufficient evidence for an attack. But it is a signal. So next, a few blocks later. Well actually, let me see here, time stamps. A few blocks later, the attacker deployed a contract that then was utilized to execute the attack. Of course, the contract on EtherScan was not verified. And so that is again another suspicious signal here. So this is essentially the action that they took in the preparation stage. Again, it's several blocks before actual funds are getting exploited. Then here what you see is the transaction where the tokens are actually stolen. And if you look in the top left here, what the attacker used is flashbots. So the transaction was not in the mempool. So it was directly picked up from the flashbot network by the miners. So it was essentially a private transaction until it was mined. And then you also see that a flash loan was used in the transaction to essentially obtain a large amount of RAP Bitcoin in order to then manipulate the price that the inverse finance protocol relied on. Then here you see this is the new BlockSec Explorer. I like this very much because they really nicely visualized the balance changes that are happening with a particular transaction. Whereas on EtherScan, you have to understand the storage slots in order to understand how much is moved where. But essentially what you're seeing here is the receiver that the address on the top, that's essentially the account of the inverse finance exploiter. They're receiving a lot of RAP Bitcoin and USDD and additional tokens. And then further down, you see kind of where those funds are coming from. So large, large amounts of token movable movements as a result of this particular transaction. And then lastly in the money laundering stage, what the attacker did here, again several blocks after the exploitation, is to convert essentially all the ERC 20 tokens that they have into native tokens. And that is probably a step that is being taken because ERC 20, depending on the implementation, can be blocked. I've mentioned USDT as an example. They have a block list mechanism in the contract. Whereas if you have native tokens, Ether, that possibility does not exist. And then once they have essentially native tokens and they use in this particular example tornado cash to launder the funds. And at that point in time, the attack is over. And as I mentioned, there's these four stages, funding, preparation, exploitation, and money laundering. For this particular attack, it took about eight minutes end to end. Now that is very quick. So a manual incident response is probably not sufficient. But if you're thinking about automated incident response, now it comes into the realm of possibility to mitigate this particular attack. Yes, please. They could certainly do that. But they often don't. Now I suppose that certain attacks are maybe some gas limitations that they run into. And let's please make this interactive. So there's additional questions. Please just shout out. Yes, sir. Yes. So the attack or smart contract was just deployed using regular mempool. And then the exploit transaction, where the smart contract was invoked, was submitted through the FlashBot network. So a lot of times with the exploit transaction itself, it opens up like arbitrage. So the MEV bots like pick it up and then backrun it as part of a bundle. Is there a way to tell if it's being submitted itself via FlashBots, i.e. like not showing up in the mempool at all, or if it's being in the mempool and then a bot picks it up and puts it up. I see what you're saying. Well, you can basically look at the FlashBot has kind of like a UI that allows you to identify the bundles that are being submitted. So you're able to monitor it that way. Yes, sir. Hey, has the tornado caches gotten so good that attackers are not really using peel chains as much as they used to to launder the funds? Or they seems like they're doing it kind of just in one big go here. Most of the attacks that I have analyzed, it's tornado cash usage. Now, given that now tornado cash is on the OFAC sanctions list, I don't know whether that's going to change anything. It certainly will reduce overall liquidity in the tornado cash protocol, which may make tracing a little bit easier. So we'll have to see what happens over the next few months. Thanks. Thanks so much. Is it more common patterns and people deploy these smart contracts? And do they use address obfuscating? Because if we can monitor that someone deploys this contract, and this contract was funded from tornado cash, and it has our addresses, it's a red flag and we should at least be warning about. Or is there are some tactics when they use some obfuscation? I have not seen obfuscation. So they get funded by tornado cash and then they just deploy the contract and kind of this detection logic that you're just talking about, where you're saying, oh, did the tornado cash funded account deploy a smart contract? That is actually something that we monitor for. But now I've seen like, for instance, Ronan attacker, what they did in the money laundering stage, they had, you know, they explored account that again was put on the sanctions list. So they couldn't go through tornado cash because that honors it. They just transferred it to a different account and then laundered the money to tornado cash. So there's a little bit of kind of like hopping across accounts that happens at times to kind of break the link. Yeah, but majority use smart contracts, not just direct intervention for EOI address. Say that again. So the major case is when people at first deploy smart contract and then interact through smart contracts, then it's direct interaction with your smart contracts. It's a question. I have seen that the attackers deploy the smart contract and then directly invoke the smart contract. Okay. Yeah, related question. Do actively continuously monitor like for such cases, like when like new account is just funded with tornado cash and deploys, deploys smart contract right away. And yeah, and again, and do you somehow like make it public or like? Great question. I'll talk about that in the next two slides. Okay. Yeah. So this might be covering the next two slides on the same realm. What is the how much time is passing between this right between the preparation, execution and finding the laundering? Is this all done in a couple of hours? Is this weeks? What are we looking at? Here it was eight minutes in this particular case. But you know, you see a broad range. Now in, yeah. So just a second, one last question. What percent of attacks are solved and solvable? You know, blockchains can be the worst place to do anything criminal. If we're thinking about defy protocol attacks about over half are not atomic. Whereas, you know, about 45% are atomic. I think in the 45% case at this point in time, that would be very difficult to solve in terms of being having some time to respond to it. But I think there are some things that protocols are able to do such that the attacker is no longer able to execute an atomic transaction. So think of the Binance hack last week. So basically there, the attacker was able to mint one, one billion tokens or one million tokens, right? Should you be able to mint one million tokens in, in one transaction? Could there be a time lock that kind of delays it where maybe, hey, you mint 10,000 that goes instantaneous. Whereas, if it's a large amount, you time lock it. So you kind of forcing the attacker to span their attack over multiple transactions. And then that potentially brings those attacks into scope for mitigation. Sure. Sorry. No, I love the question. That's great. Have you seen like an increase in attacks that end up in a different type of money laundering schemes? Like I've seen stuff like, since what happened with tornado cash, I've seen some, some of the hacks end up in depositing to curve pools and stuff like that. Yes. Yes. We certainly have observed that there's still some centralized exchanges that are being utilized as well. But tornado cash is still heavily used. But again, that, that's something that we have to kind of see how that develops as kind of liquidity potentially goes down in that protocol. All right. Well, let me, let me talk a little bit about then how we monitor for, for these attacks. Now, monitoring we feel like is part of a comprehensive security strategy for protocols. So if we're thinking about a protocol, protocol security strategy, there is activity that, that needs to happen in the pre-deployment stage that many of you probably are familiar with, like utilizing template contracts, like the open Zebulin library, conducting smart contract audits. But, but that is not, not enough. You also need to think about what happens after you deploy your protocol. And as it attracts more TBL and becomes more attractive for attackers to attack. So in the post-deployment stage, think about bug bounties. Fordi network is, is, has their bug bounty on immunify very effective program. Real-time monitoring and alerting. And that's really where the Fordi network comes in. And then kind of related to monitoring. Of course, you also have to think about incident response. And Dimitri will, will talk about incident response on the LiDAR protocol and how they are managing that. Because if you are getting alerted about an attack and don't take any action, well, the attack will just proceed. So Fordi is, is a decentralized, think of it as a security and alarm system for web free. So it's a decentralized network that allows you to monitor on-chain activity in a decentralized way. And it consists of, of, of Fordi scan nodes. And these scan nodes run community developed detection bots. And I'll talk about detection bots here in a second. And the scan nodes, they are hooked up to a, a chain, either through a node or infrastructure provider. And they forward transactions and blocks to these detection bots. These detection bots implement rules, heuristics, machine learning models where they are analyzing a transaction. And if they identify something suspicious, they raise an alert. The nice thing about this, this decentralized architecture is that you get a lot of redundancy, right? Like as, as I develop a, a detection bot and deploy that onto the Fordi network, it gets automatically deployed on multiple scan nodes at the same time, such that if one scan node goes down, you still have plenty of coverage. And so it creates some redundancy and reliability. So the Fordi network, you're, anybody can develop a detection bot and we'll go through an example on how that looks like. We'll also go through some, some existing bot examples. So you get an idea of kind of the capabilities that you have as a bot developer. And as these bots raise alerts, they can be viewed through the Fordi Explorer. So think of the Fordi Explorer as a, you know, block, block explorer for the Fordi network. So you're able to explore all the various alerts that are being raised. You're able to examine the network. You're able to search for bots that are already deployed on the network. And let me see whether this, this works. And I can show you some examples. All right. So this is the Ford, let me sit down. This is the Fordi app, app.fordi.network. And up here, you have the link that takes you to the Fordi Explorer. And this is how the Fordi Explorer looks like. So you're basically able to see all the alerts that were raised, you know, in the last hour or so. Fordi supports seven EVM compatible chains. I'll see my network is not good. Separate network for, oh, separate Wi-Fi. Yeah, it's okay. I have some screenshots, so I can show you. But thanks for the tip. So as you click on an alert, you get alert details. So here we have tornado cache withdrawal alert. You are able to see information like the transaction that is associated with this alert, the bot that is associated with the alert, and then a whole bunch of metadata, which essentially contains all the addresses that were touched in the transaction. And then down here, you see all the nodes that run this bot at this time. And so as you see here, there's currently six scan nodes that have that particular bot deployed. On the bot search page, you're able to kind of search for the the bots that are deployed. So let's assume you want to create a bot that monitors flat bot attacks. Well, before you dive into the developing a bot, take a look at what's already deployed on the network. There's hundreds of bots deployed on the network today. Then from there, you're able to jump into the bot stats page. Again, that gives you information around how many nodes it's deployed, historical information about how many transactions has it processed. You see the link to the source code, the documentation, and then if the bot generates some log data, that's also available on this page. Let me see here. So here we have another alert flash bot transactions. You can then jump directly into ether scan to examine the transactions. So here you see that it's a private transactions with flash bots. Here's the network activity page. So this gives you essentially information about all the networks that the 4D network supports, as well as how many node operators are tied to that particular chain. All right, let me jump back. Any questions? Do you have any statistics of how many real attacks you really captured? Well, that depends a little bit. So there is a concept of precision and recall with bots, right? Precision is essentially of all the alerts that are being raised. What is the percentage of true positives? Like, hey, it identified an attack. And then, no, that's recall, sorry. And then a precision is how many of those are false positives, right? And so you could have a bot that is extremely noisy, but has high recall, right? And so you could say, hey, it identified that particular attack. But that bot is not really useful because it contains so much noise that it's very difficult to consume. And so I'll talk a little bit about a layered approach to a monitoring that builds on top of noisy bots and then combines the alerts into highly precise alerts. In terms of statistics, I want to say that kind of combiner bot that I'm mentioning, I think it had a precision of 80 some percent and a recall of maybe 50 percent. But don't quote me on that. That's great. Can I ask one more? So are the node operators trusted or just? Well, anybody can can run a node. Now, however, the Forte network is secured by the fourth token. So as you are, if you want to set up a scan node, you have to stake Forte token. And if you misbehave, then your Forte gets slashed. But also keep in mind that there's some redundancy in the network. And so you could have, let's say six nodes that run your bot. One behaves maliciously and just output garbage. You still have kind of five that you're then able to utilize to kind of build consensus in a way. And one more question. Suppose I developed a bot that I really put some certain blood into and I don't want to publish it publicly, but I want to contribute. Could I somehow run it here or not? So there's a variety of options that you have. You can either obfuscate your code and encrypt your alert and deploy it on the Forte network. Now obfuscation is, you know, security by obfuscation is probably not the best approach. You can also run a private scan node and deploy your bot just on that node. But then you're kind of trading off the redundancy that the network provides. Can you hear me through here? Yes. A couple slides back there. There was a part of the website that said something about pausing when an attack is detected and pausing on chain. So two related questions. How many roughly people protocols do you have doing that? And then also how kind of open to that sort of automated third party pausing are protocols? I don't know of any protocol that hooks up to an alerting system and automatically pauses their entire protocol. I think there is, we need to continue to work on the precision of the underlying alerts because if there's a false positive, essentially your protocol is halted and that's not good either. Now pausing also, I look at pausing as a big hammer. Are there more nuanced mitigation techniques that you can implement that again kind of slow down the attack or mitigates the attack while at the same time leaving your users still being faced with a usable protocol and like time locks could be an avenue there. But I think that is something that still needs to be better defined. And so we have a large audience here. If you have ideas, we'd love to hear. Hi. I have a question. Is it possible to monitor governance attacks and like, you know, bolting power that changes? Are there bots for that? Yes. We have, we have on the Forty Network, there is this concept of threat detection kits, which are a combination of bots that detect generic attacks for a particular protocol type. So there is a threat detection kit for DeFi, for NFT, for bridges, for stablecoin and for governance. Thanks Dimitri. But can you tell me more about timing? For example, you detect some malicious activity. Basically, we have some developed system, monitoring system, but we definitely consider that if you find something you should action, maybe next block, so you should be pretty fast. In terms, you have a decentralized network. It means that you need some consensus between nodes and so on. So what's your common scenarios of using Forta? Should we manually check what's going on? So hire some guys, like it exists of monitoring hard technical system, like nuclear power stations or some who check all days of monitor, or we can write bots. But in terms of bots, how much blocks it takes to be executed before you found something to really make an action? So it takes about 40 seconds from mind block or mind transaction to alert being consumed, essentially. So there is some delay. In terms of your other part of your question, should there be a person that monitors? I believe no, but just because the attacks are too fast, you need to have some automated incident response. Now, does that make your incident response team obsolete? Absolutely not. Even if there is an automated incident response, you still need to have a team that then analyzes that and basically says, was that the appropriate action? Should we do something else? Another example that I have, the Ronin Bridge, the hack that happened earlier this year, that took a week to discover. Yeah, so let me add something on this side. So first of all, yeah, so speaking about detecting something and reacting on the next block is usually not the case. The case is detecting something not in a week, like Christian said. And the second thing is that we will talk about the how to react on alerts, what to do and how to make it really fast. And yes, you need people here for sure. And the details about it will be at the second part of the workshop. Perfect. Are you planning to monitor and run Fort on Mempool level? Where are you? I'm here. Sorry. Mempool currently not. However, the bot framework, the bot development framework is very powerful. It's essentially, think of it as a Docker container that either runs JavaScript, TypeScript, or Python. So there's a lot of things that you are able to do. So your bot is certainly able to inspect the Mempool and generate alerts based on the Mempool. But it is not a native interface to bots. I have a question about configurability. The bots are deployed by the bot builders. Are there parameters? Can they accept parameters from the consumer? Excellent question. So some bots, yes, are developed by builders and then deployed on the network. But you can also create templates that provide parameters that you can configure. And on the Forti app, there is a bot wizard that allows you then to essentially instantiate and deploy a bot with your specific parameters. Is there a way to specify the bot so that you don't have to redeploy? So say you want to have a signal at 80% threat versus 60%. Absolutely. You can within the bot have different thresholds and emit different types of alerts. It's not a one-to-one mapping where one bot is only able to emit one type of alert. Or after deployment. Well, after deployment, no. Then you kind of have one snapshot of the bot. So you can upgrade your bot or deploy a second instance with other parameters. Yeah. So really, that's not a big deal. We've been doing it for a while in Lido. So yeah, if you want to update the values, the constants, you need to do a redeploy. But it is done in such a simple way. So you don't need to worry about it. On one hand, and on the other hand, you are 100% sure that the bot is running on the actual values and there can be no changes made by either the Forta network or the malicious software or something like that. Dimitri, there's one more question over here. Yeah, sure. Very fast one. Maybe I'm running ahead. But do you have any examples when these kind of analysis help prevent or at least minimize damage? Well, I think it again, it kind of requires that the protocol teams consume the alerts. Now, and then kind of take actions quick enough. And I think that is still a problem. But we certainly have many examples where an attack occurred and the Forta network emitted a highly confident alert. And so I would reference kind of our blog or Twitter handle. Not prevent, no. Okay, not yet. But hopefully I come back next year and I can talk about some prevention stories. Okay, question here. Yes, sir. How is Forta decentralized? How do you manage to have it decentralized? Because it says there that the centralized bot to detect attacks. The first second is that why is it important to detect an attack after it happens if it already happened in blockchain, you don't have a way to revert anything. So first of all, it's decentralized because there's thousands of scale notes that run these detection bots, right? Does that answer your question? No. Well, you have independent node operators, right, that set up a scan note, right? So some of the security auditors, some of the infrastructure providers are running scan notes. And so then your bot is essentially deployed on multiple scan notes at the same time. So it's decentralized that way. Who's running those notes? Well, as I said, like smart contract auditors, infrastructure providers, you can run a scan note if you want to. And then your second question is like, why would you want to monitor if you can't prevent the case that I'm making is that attacks are not atomic. And we are able to detect attacks before exploitation occurs. And so there is a short time window that allows you to take mitigative action. Now has that happened yet? No, I think we still need to work on that in terms of identifying what are good mitigative actions. And then, so that's one part. And then the second part is to create alerts that are highly precise. So that the number of false positives are low in order to increase the confidence of protocols to then essentially hook up automated actions. All right. So I talked about the attack stages. And what you see on this slide is essentially a set of generic bots that are deployed to identify activity for each of these stages. So, you know, tornado cash funding, bridge funding, sleep minting, attack contract creation, also looking at whether the EOA that created the contract was funded by tornado cash. The 4Di network is not only looking at protocol attacks, but also looking at end user attacks. So there's a few bots that are deployed that identify activity like ice fishing, or somebody deploying token impersonation contracts, then a whole slew of bots around exploitation, and then money laundering. But as I mentioned earlier, if let's say the tornado cash funding bot emits an alert, that is not sufficient evidence to call this an attack. And many of the individual bots that I have listed here have the same problem. By themselves, they merely give you a signal, but it is not sufficient to then raise essentially saying that this is an attack. And so as I mentioned earlier, what we do, we have kind of like a hierarchical system. So think of all these bots here are kind of base bots that generate signal, that say, hey, something suspicious is going on. But then what we essentially do is we combine the alerts from these base bots, such that they are consistent with attacker behavior. And so essentially, we will raise, there's a bot deployed that will raise a high confidence alert if it sees a base bot firing in the funding stage, in the preparation stage, in the exploitation stage, and in the money laundering stage. So that is one flow. And basically, it combines them based on a common EOA or a common EOA cluster. So if the attacker executes an attack from multiple accounts, and we cluster those accounts together, then we're still able to generate that chain. Now, obviously, if we combine alerts all the way across the chain, then it's kind of too late, right? Like then the funds are already laundered. And so what we're really trying to do is push more and more alerting into the earlier stages of the attack chain. And so the community is heavily investing in detection bots in the preparation stage. And I'll go through some examples of those bots that in combination with funding generate essentially a high confidence alert. And in the inverse finance attack, that happened. There were essentially two alerts fired, one after the preparation stage, and one after the money laundering stage that were both highly confident. And so inverse could have, if they would have hooked up to the Forda system, could have taken some mitigative action. So this is kind of encoded in a bot. Now for security researchers that want to hunt for attacks, there is actually a Discover New Attack Explorer that a community member has created that is deployed on this link right here, that basically allows you to explore attacks that are happening on chain that may not have resulted in an alert. And let me see, oh, dang it. I don't have it. Oh, there it is. So this is how that looks like. So basically it says, hey, give me all the alerts over the last couple of weeks. And then it essentially ranks it based on the confidence that we have on some heuristic or some anomaly model that then allows you to explore those. So this, for instance, four stages fired. So this was the winter mute attack and an alert was emitted. But as you kind of scroll through the right here, then you basically see attacks where maybe that threshold wasn't met of four stages being triggered, but maybe only three. So that bot did not raise an alert. But now you have essentially security researchers that are able to analyze that group of alerts and manually determine whether an attack has occurred. So that is available on that URL. I think it's very neat. Okay, it will take some time. Just leave it as is and it will load. Any questions? Yeah. It's on the slide. Hi. Is there any metrics for the performance of the scanning node? Because if we're talking about the real-time monitoring, and we may have very complicated rules to scan, also you should you may reference the historical data as well. So how do we know whether a node is the hardware is compatible for such a complicated task? Well, the scan nodes have certain capabilities, right? And your bot may kind of have requirements that exceed those capabilities, right? And so then as a bot developer, you need to kind of incorporate logging that allows you to identify whether the scan nodes have issues processing what you're trying to do. So is there any metrics that can be quantified? So there's metrics on the bot stats page in terms of kind of transactions that are processed, or whether you're falling behind on errors that would help you to identify issues like that. All right, thanks. Db3, it's going to be question there and question there. Yeah, yeah, yeah. No problem. Is there some way to make in case bot fires so it will make also transaction and update some smart contract that it fired so I can create my smart contract, which will depend on this happening. So the Forta network does not natively provide that, but as you subscribe to a bot, there is a variety of mechanisms that you can kind of hook up. Webhook is one of it. The open Zeppelin defender product integrates with Forta. So kind of the logic that you're describing alert was raised, take some action on chain, it's supported by open Zeppelin's defender. I was just curious if you're aware of any contract reputation systems, because we talked about like there's the attack of what's actually happening, but also if something's suspicious, we've talked about if it's funded by tornado. Is there anything out there that's actually tracking that that you know of? No, I mean the block explorer have some tagging and source code verification. That's kind of the only mechanism that I know about. Now the Forta community is working on machine learning models to essentially predict whether a contract is malicious or not. So that would be kind of a way of reputation system for contracts. But there's probably more you can do if you think about kind of the deployer, who was a deployer, right? You could assign reputation to that and kind of propagate that to the contract. So are there any network economics at play here? I mean the node operators and bar providers, are they paid? Who pays them? How? Andy, you want to take that question? So as Christian mentioned, to secure the network, we have node operators are required to stake. So you have to stake 2,500 for minimum. And if you do something bad at the node level, you can get slashed. The Forta foundation is subsidizing node runner rewards. So if you meet a certain SLA every week at this point across the seven networks that we monitor, there's different sort of reward allocations for each of the seven networks. But if you hit a certain SLA, so let's say like you're 95% uptime, you're going to earn the maximum rewards that week. So those are coming from the Forta foundation right now. It is free to publish a bot. It is free to subscribe to that bot right now as well. We are introducing bot staking as well as a lever to reduce spam. We haven't experienced too much spam on the network, but it's a risk. So that will happen soon. In terms of paying to actually get the alerts, it is something we will implement. It'll likely be some sort of subscription model. So if you like the attack detector feed that Christian was talking about, that aggregates a bunch of these other alerts, there's a lot of effort that a lot of people put into that. So that one would probably be more expensive to subscribe to than if you were just monitoring for high gas transactions. That bot maybe took 30 minutes to build. Eventually, yes. And right now the Forta foundation is sort of coordinating a lot of this, what I'll call like more advanced bot development that uses data science and machine learning. But there are other audit teams that have approached us and want to put really valuable IP on the network, but they need to be incentivized to do that, right? So yes. So we need to enable that. It's probably more of a Q1 2023 thing. Yep. Okay. Let me talk a little bit about the capabilities that bots have and then walk you through a bot development real quick. So as I said, bots are essentially piece of TypeScript JavaScript, a Python code that runs within a Docker container. So they're extremely powerful. You're able to maintain state. You're able to reach out to external APIs. And so let me walk through a few examples. So this is the flash loan bot. So flash loan, right? You can kind of temporarily get some tokens as long as you pay them back in the same transaction primarily used for arbitrage, but also used for price manipulation attacks. So there is a bot right now that is deployed on the network that monitors for flash loans, but then has some additional heuristics that basically say, well, how much is the profit of that particular transaction in order to differentiate arbitrage from potential attacks? So it's a simple heuristic. This one is a rug pull a bot that basically monitors token prices over time. And this is actually a bot that utilizes time series analysis using Meta's profit library where it essentially learns based on historical price information to alert on deviations from normal behavior. The time series essentially is able to take into account volatility as well as seasonality of any sort of time series data. So this is an example where you do maintain state and build a model, you update the model in memory and then able to alert when when deviations occur. This one is the exploit simulation. And I think this is a really super cool bot. Basically what happens is when a smart contract gets deployed, the bot monitors for that action and then essentially locally at that point in time forks the chain locally using a Nash and then it invokes all the functions that are exposed by that potential attacker smart contract and monitors whether there is large token movements into either the contract or the deployer's wallet. And so that essentially allows you at the preparation stage to generate a high confidence alert that an attack is about to occur even before the attacker submits the transaction on chain. Now it is utilizing very simple fuzzing. It's basically just looking at the functions that are exposed and kind of guesses parameters. If any of you work on a fast black box fuzzer, I would love to talk to you after this presentation because I think that would be extremely valuable because then you're able to exhibit the attack behavior probably with higher recall. All right, so custom bot development. So down here is essentially the quick start URL. Anybody can develop a bot. It is extremely easy and I will walk through using some screenshots to kind of show you how that looks like. As I said, bots can develop in Python, JavaScript and TypeScript. My background is data science. So I'm partial to Python. So all the examples that you see here are Python. So you need to set up your dev environment. So obviously not something that we're able to do here right now. But if you go to the quick start page, it gives you instructions on what you need. So you need Node.js. If you use Python, Kanda and Python and then Docker. Once you have set up your dev environment, then you're able to initialize a bot using the CLI, the Forta CLI. And basically what that will do is it will generate a stub of a functioning bot that at that point in time, you could theoretically deploy to the Forta network. And let me kind of outline important files that are being dropped into your environment when you initialize the bot. So there is agent.py for Python. Don't get confused by the term agent. We used to call bots agents and so you see the term interchangeably. So agent.py contains the main bot logic. And we'll go into that in more detail. Agent test contains the unit tests. Docker file contains the Docker build file. So when you deploy a bot, basically what happens is the bot gets packaged into a Docker container, it gets uploaded to IPFS and then it gets registered with the Forta network. And then the scan node basically monitor these registration events and then pick up the bots from IPFS, deploy them and run them. And so the Docker file contains essentially the build instruction for your image. And so if you need anything in your bot that is not covered by the Python language, you can customize the Docker file to pull that into your bot. And then that obviously is available. Readme contains the documentation. This is essentially the documentation that is exposed on the bot stats page. I personally, when I develop a bot, I start with a documentation because it creates a lot of clarity for me in terms of what do I need to do in the bot code? What chains are supported? What sort of alerts am I planning to admit under what condition? So I start with the documentation. Also at the bottom here, you see test data. What is really neat about the development framework, the SDK, is that you're always able to back test your bot. So you may have encountered an attack, let's say that the Binance attack last week, you identify a technique that's not covered by a bot. You develop the bot and then you can basically just back test and make sure, hey, it actually detects that particular attack, which is super powerful. In the agent code, there is the main function, which is essentially the handle transaction function that passes in the transaction event. And that is essentially the transaction object. All the usual properties of a transaction are contained in that object. And your job as a bot developer is to essentially analyze the transaction event and then emit a list of findings, aka alerts. So basically, this function gets invoked and you return a list of alerts based on your logic. So the logic that I'll quickly walk through is a bot that basically alerts on large USDT transfer events. And this is essentially the stub that gets created. So in the bot, you basically have handle transactions and then you admit an alert. So here's the alert. It's basically a findings append, creating a findings object with information about the alert, like the name, description, severity, type and any metadata that you want to provide. In this case, the to and from. Now, of course, that does not have the logic yet. So let me go through the logic. So as you as the handle transaction function gets invoked, first, what you want to do is filter for events that are of interest to you. And so here in this particular example, we're interested in the USDT transfer events. So you're able to essentially implement a filter that basically says only, you know, kind of parse the transaction event and only kind of give me a list of transaction events where kind of your filter logic matches. And so that's kind of the loop down here. That basically then can be assured that you're dealing with USDT transfer events. From that event, you're able to extract information to, from and value, you normalize that value, and then you essentially just have a conditional based on your logic. Hey, if it's over $10,000, now I want to emit another. So super simple, but I know I've been speeding up a little bit. I want to make sure that we're not running out of time for the second part. And then you append the finding. Now, when you develop a bot, there's a variety of ways you can test it unit test, I love unit tests, back tests, I love back tests, and then life tests, you should do just because there's a lot of, you know, crazy transactions on chain. And you want to make sure that your bot doesn't error out. So best to do a life test locally. And then you deploy and deploy deployment of the bot is permissionless. So you basically just run npm run publish. You need to have some magic because basically what you're doing is you're signing a transaction that registers the bot on the Florida smart contracts, essentially, that then the scan notes monitor and pick up on. It takes a minute or two. It basically builds the Docker container, uploads it to IPFS, signs the transaction to register your bot. And then a minute later, the scan notes that are running on the Florida network, pick up that bot and start sending transactions to it. And then within five minutes, you see essentially a new bot on the bot stats page. And you see it starting processing transactions. You see it generating alerts. And then at that point in time, you can start subscribing to your bot. And there's a variety of mechanisms, telegram, email, Slack and Discord and webhook that then get invoked whenever your bot raises an alert. And that's how that that looks like. As I said, for this workshop, we don't have exercises that we do live here, but we have set up a few exercises on this GitHub right here that get you familiar with the general bot development process. And so one is kind of similar, large USDC transfers. The other is detecting low balances. And the last one is more security focus around flash loan resulting in losses of the urine dye vault. And then lastly, what I want to call out, we currently are running a contest, bot development contest. We've been running over the last year and a half. These are contests that we put out for the community. You can develop a bot and earn up to 3000 US dollars. And this particular bot is asking to develop logic to identify the attack protocol. And then we can see some context here. Often the bots basically just say, hey, this transaction is an attack. But it does not necessarily give you context around which protocol was attacked. It contains all the addresses. But it would be nice if it could say, Hey, inverse finance was attacked. And so this particular bot contest is all about analyzing the transaction in more detail. So we're able to identify what protocol specifically got attacked. Yeah, thank you, Christian. Folks, just let me leave all the questions to the end. We will have enough time and we will answer them all. So just to make sure that the core features that we want to describe here will be covered. So first of all, haven't the part that Christian just talked about was really excited. Are you excited? So like you can create a detection bot, a decentralized detection bot with a really limited skills in coding. And that's great. And that's really cool. And that's what I like about the Florida. And that's what we like in lighter about the Florida. And Christian tell us a lot about generic attacks detection. So like with the all the steps, this attack, oh, yeah, I guess everything was such so fragile. So yeah, the Christian told us about the generic attacks about steps of the generic attack about the early stages of detection. And it is really cool that everything that is developed in Forta is available on public. So having these bots on Forta, each one of you can subscribe, select addresses of your protocol, and give get the alerts about like some kind of this attacks related to your protocol. And that's really cool. But what about the protocol alerts? So what I mean, speaking the protocol alerts, let's do a quick comparison. So the generic alerting will allow you to detect any attack that will somehow fit into your bots logic. While the protocol alerting wouldn't allow you do that, but it will allow several other features and we'll discuss it. Next is the confidence of your protocol security. So like, let's say you have a number of generic bots that are precisely tailored for well known attacks. Are you sure that your protocol is secured? So like, let's imagine we have tons of histories about attacks. And if we cover them all with the bots, are we sure that our protocol is safe? No, not at all. Why? Because new attack can appear and it can be some modifications inside the attack, so that we are not 100% secure. And actually we cannot be 100% confident about the security, but we can increase this level. And we can increase this with the protocol bots. And why? We will discuss it just a bit later, but since the protocol bots will be tailored around our protocol, it will watch over the everything happening with our protocol. Okay, let's move on. So what is the main vectors of the attacks that can be detected by the by the generic bots, the generic bots detect attacks they are tailored to detect. While the protocol bots are not detecting attacks itself, they are detecting some strange changes or some critical events inside your protocol. So you might not know about the this vector of attack, but you will definitely know that something is going wrong with your protocol, and you can react. And that's cool about the protocol bots. And the last thing is set up. So again, what is cool about the generic bots is that you basically do not need to write them if you're satisfied with the bots exist that already exist on the for the network. While with the protocol bots, unfortunately, you should do it by yourself, but it's it's very, very interesting. And you will definitely do it after the workshop. I 100% sure. So we have generic bots. We have protocol bots. Do we need to choose between them? No, we don't. We need them all because in combination, protocol bots and generic bots will increase our level of confidence. So let's discuss the typical protocol alerts, and we will start with the things not related to attack to any attacks directly. We will start with really boring operational stuff, but which is also very useful for us. So first of all is the repetitive events. What repetitive events do we have in protocols? Like in light of protocol, we have Oracle reports, we have rewards distributions, we have funds, deposits from the, uh, let's say the lighter contract to the if 2.0 deposit contract, we have Dow votings and some others. Can you spot some examples from your protocols of the repetitive events of things that are frequently happening? Any? Okay. Okay, check check in prices from the oracle. Okay, cool. Anything else? Sorry. Almost so it is a now when I speak about here about the repetitive events, I speak about the things that should definitely happen. Let's say once a day or once a week. Okay, let's keep this things here. So what do we want to know about this repetitive events is that if we know that they should happen, we should monitor that they are happening. And if they are not happening, it means that there are some problems or maybe even an attack. So we can watch over the Oracle reports and so on and so forth. But the one thing that we can do on top of just watching over the events and alerting you, Oh no, there's no Oracle report here. That's the problem. We can also make a predictions on if there will be a problems with the, let's say Oracle reports. So we can watch over the quorum of the oracles and identify which one of the participants are really sloppy and miss the participation or mis-participate. We can do the same things with the other events. So with the operational staff, we are watching over the repetitive events and trying to predict issues with them. But that's not about the attacks. Yes. And our workshop is about attacks. So let's start speaking about the security. And from the security point of view, the first thing that we definitely should watch over is the protocol invariance. We will talk about executive invariance in details a bit later. But what I want to say right now is that there are, there can be like multiple invariance in protocol that should be always met. And if they are not met, it means that something goes wrong. And it can indicate that there is an attack. So simple examples here is bridge balance difference. So any hack of the bridge will, will broke this invariance. So some tokens will be minted on one side or too much tokens will be withdrawn on the other side. Okay, we can watch over it. The issuing of the tokens without actual backup is also the cool example of the invariant. Also minting NFTs, unexpected transfers and so on. The second thing about the security is, first of all, the events that should never happened at all. Yeah? So can you spot something except for one on the slide? So roles and ownership transfers to the EOA. So you have a huge protocol with a large TVL. And then you see that, okay, the ownership of the main contract was transferred to some unknown EOA. Don't you think that that's a problem? Yeah, that's definitely is. And so self-destruct of the protocol contracts, also the thing that should never happen. And you will see, okay, so there's, that's a really weird things. Why we do even want to have alerts about it. And the cool thing is that on chain, you have all the history and you can spot every event. But why we want to have alerts here is that because we want to know about such events happening as soon as possible and not sit here on the S. And after that, like, okay, one week ago, one of our main contracts was self-destructed. So we want to know about it as soon as possible to have the ability to take some actions. Can you spot some other events that should definitely never happen with the protocol? Any token transfers in the functions? Yeah, that should not transfer tokens. Okay. Yeah, for sure. Anything else? So like, let's say, yeah, yeah, yeah. And that's even can be a protocol invariant, you know, and yet changing value from positive to negative, where it should never happen, also can be the case. Okay, except for the events that should never happen at all. There are some events that might happen, but should never happen silently. Let's say you have some protocol that the part of this protocol is depositing funds. So folks can deposit funds and withdraw them. And again, you're a happy guy sitting on a beach. And after that, you understand that, oh my God, my protocol TVL got down by 50% and I didn't notice it. So that's the example of the huge withdrawals. And that's the event that could happen. That's not a problem. That's probably even not an attack that can happen. But it definitely shouldn't happen silently. And you can also have the alerting setup for it. Also a huge balance changes. And the other thing is the ACL changes. So if we have a truly decentralized protocol and we control it to not buy only one person or even a multi-seq, so we have the precisely designed ACL system, we also need to know about each change in the ACL. Let's move on. And since we've already discussed the main ideas and the main types of the protocol orders, we can move to the practical parts and dive into the examples. And we start with the idea of overall bot development. So since I'm a former quality engineer in traditional software development, there is a term called shift left. The idea of the term is that you should start testing as soon as possible, like on the stage of the requirements. So no actual software is provided and you also already start testing. The same goes for the alerting. So if you are one who is responsible for the alerting in your company, in your team, or just want to make cool alerts, you should start at the very first stage. So the ADR, at the architecture description record. And first of all, do a review of the overall architecture of the overall idea and identify some issues, maybe known hacks and so on. After that, on the development stage, you should be also involved to make sure that all the events, view functions, and other stuff is in the protocol. So once you will start building the alerting system, you will not get into the situation when, okay, I got this invariant, I got it in mind, but I have no way or like a weird way of getting it. Okay, cool. After that, on the review stage, you should confirm that everything described on the previous stages is in the protocol. And on the deployment stage, it's time for you to either start or even finalize the development of the alerting. And once the contacts are deployed on chain, the alerting for them should be deployed as soon as possible. Okay, now let's talk about the critical events, about the things like we mentioned that the things that should never happen or the things that are really, really important for us. So the first thing is the ACL changes. We've talked about it a bit earlier. And the first thing that I want to say here is each ACL change should be alerted. Even though you might think that, okay, that's not a critical thing or that ACL would never change, you should definitely have alerts for it because you never know the exact vector of the attack. And the ACL changes are usually involved in attacks. So also granting and revoking permissions for some critical stuff should be alerted with a critical alert. And we will talk about the alert severity in just a few minutes. The second thing is ownership transfers. And it's basically the simplified version of the ACL when you do not have separate ACLs, you just have the owner. And for sure the ownership of your protocol should be never transferred to EOA. It should never be transferred to the unknown address. And it should be never transferred to the null address. And the last thing is the state changes. So it's common practice for the protocols to have functions that changes the state and does not emit event, but that's a critical change or the changes that just might happen. So like let's say the commission of your protocol is set on one of your contracts and it somehow gets changed. You definitely want to have alert about it. So if it is the case when it was done by intent, it is your team, it was done over the voting, that's okay. So you just see the alert and say, yeah, I know that that should happen. But if it happens without any contours, you should definitely react on it. Okay. And so some examples of the ACL contracts have no idea why I've put it on the slide. So let's speak about the protocol invariance in a bit more details. I have three basic examples here and I think that we can spot several others. So first of all, yeah, if we speak about the protocols that are about depositing funds, then for sure the amount of the tokens of something minted should be equal to the amount of the, to the amount of the funds deposited. For sure the bridge balance, the source bridge balance should be always higher or equal than the target bridge balance. And you know the difference here. So in the first invariant, we have the equality. And in the second, we have not the not the equality, but inequality. And in variants of both types, why with the bridges we are using not a strict equality, because in most cases, the funds can move from one part of the bridge to another and it might take time and movement like on one side and on the other side can take different time. But you definitely should keep in mind that if you deposit funds on one part of the bridge, the amount of the funds here should always be higher than amount of the funds printed on the other side. And the third example is the collateral value. So collateral always should be larger than law. Can you spot any other examples? Maybe something is in your mind right now. So yeah, in my protocol, that's the thing that should never be changed. Or like that's the equation that should be always true for my protocol. Any ideas? You definitely know. Oh, I'm quite sure that you know. Okay, let's leave it as this. I think that in course of time, you will have some ideas about it. And let's speak in the details about the repetitive events. So as we've talked earlier, there are several repetitive events and there are ways to, there are possible issues with this. So for the Oracle report, it can be quorum not reached or something like that. That's why the Oracle report is not in time. And we can predict it by monitoring the quorum with the rewards distribution. Again, rewards are not distributed in time. And how can we predict it? We cannot predict it on chain, unfortunately, but we can predict it with the off chain executor monitoring. So let's say we have some off chain tooling that is calling a function once in 24 hours. And over the next 24 hours, there were no rewards distribution. Then we should definitely have the monitoring for the off chain executor here and possibly some other things. So the other examples, I think we can skip it for now. As we discussed at the very beginning, that we should start working on alerts at the ADR stage. So at the architecture decision record, at the development stage, we should identify that in our protocol, there is no things that are well known in the attacks in the hacks or well-known vulnerabilities. Where to search for these things? So first of all, if you are working in the Web 3 for a while, you live in the space and you definitely heard about some hacks. But most likely you heard only about the the hugest hacks. So to make a creative database in your mind of the hacks and of the things that you should watch over, you should definitely follow Twitter of the main protocols of the main, like folks tweeting about some security issues and you should redirect. You can do it in the two ways. So the first way is on the design steps of the protocol. You confirm that there is no hacks in the protocol. There is no vulnerabilities. And the second thing is once the new report fires, you should do a quick tour over this report and ask yourself, can my protocol be also affected by it and do a review over the existing protocol? So it might save you time and money. Okay. So as Christian said, no alert should be left unacted. Why so? Because if you create an alert, it means that something bad had happened. And you should definitely take the action. And if you create the alert that does not require an action, then such alert should never exist. And speaking about FORTA, for sure, everything that is produced by the bots is called alerts, but there is different alerts. So in my mind, I separate two things. So like high and critical stuff, that's the alerts. And that's the things that should be acted. While the law and info stuff, it's kind of feed, news feed, that you should not for sure take actions, but you want to be aware of. So speaking about the critical alerts, once the critical or high alert is fired, as we said, there should be some actions. But how you can be sure that these actions will be taken. So the simplest option here is to set up the on-call system that will ensure that either the person on duty or the other folks in the team or even the city or the company will eventually know about the alert and will take some actions. So there's basically two examples of the most famous, give me a second, of the on-call systems that you can use. But if your protocol is not that large, or you're just a part of a small team, there might be a situation when you will first start with the simple chats. So like we did previously before we got the on-call system. And the interesting thing about the chats is that you should also separate the critical feed into the chat that should never be muted, that should be accessible for all the folks in the development team, and that they should know that if there is a message in the alerts chat, you should definitely do something. While all the other stuff can be put into another chat that possibly even can be muted so that you can read at the evening like, okay, several events had happened. So speaking about the actions on the alerts, the alert has fired, the critical alert has fired. And there's a person on duty, but it is not him who created this alert. And you see the alert and like, what the hell? What should I do? How can I, like, I have no idea, like, I read the text, okay, there's something really bad happened. But what are gonna do in this case? To avoid such situations, you can have the thing called Runbook. So basically Runbook should contain, sorry, several parts. The description of the alert itself, so the person who is not aware of the alert can dive into the details. The definition of the severity. So if it is a critical alert or high alert, it's for sure it will be in the alert itself, but there can be some modifications and some conditions. The confirmation of the alert, because there is a chance that this alert was just a fluke and you shouldn't take any actions on it. Also, the resolution, the escalation process, and some notes and links. And if you really wanted to use Runbooks in your company, go check out the lighter example. I think that it will give you more details on how it should work and how you can create Runbooks of your own. So each critical alert that should be acted should have the Runbook for this alert. And speaking about the actions on alerts one more time, as Christian mentioned, and I think that someone from the audience asked this question, is okay, there is a critical hack in the protocol. We got the alert about it. We know that the hack is happening. And we don't want to be like a Ronin Bridge hack, not like a Ronin Bridge, but Wintermeand hack, where the folks detected the hack and they sit and look on the attack happening, and basically have no ability to stop it. Why? Because there were no emergency breaks in their protocol. So if you are designing a smart contract and you care about the security and you assume that there might be, there is a little chance, but there is a chance that there will be an attack on your protocol, please, at least at the ability to pause your protocol. Yes, it's not that good for the people, for the users, but it might save you tons of money and be like the factor that will save your protocol. Okay, and the last thing, speaking about the alerts, is that one alert is good, one alert system is good, and Forta is amazing alert system. But for the critical alerts, I'm highly recommending to have redundancy. So if you, let's say, have the alert for the ownership changes in your protocol, then take your time and not only implement the Forta bot, but also consider some other alerting system. It might be self-tailored by you or some other solution, but having a redundancy for the critical alerts also helps you increase the confidence. And yeah, so if we will have the good internet and so on, it will be time to create our own bots, and it is, but we'll keep it as the home task. So from my part, there are two basic tasks. So the first one is to create the bot with the operational alerting. And it's rather simple, as you might see, and also following the QR code, you will find the activity, for example. And I collected there the most useful code that can be used for both operational, yeah, mostly operational alerting. And the second thing is to develop a security bot. And that's a more complicated task. It will require you to get a deep dive into your protocol, to determine the protocol invariance, to determine what ACL changes might be, and so on and so forth. And since we want you to give you assistance to help you and to to be sure that after the workshop, you will come back home or come back to the hotel and will deploy your bot, there is a chat, the telegram chat that you can join. And in this chat, me, Christian, and other guys from Forta, will help you, will give you the consultations about, okay, I cannot deploy the bot, please can you help me, or how can I detect this particular case on anything like that. And for the tasks about the protocol bots, maybe someone of you does not have a protocol yet, then you can take the LIDAR, oh, no, you can look first at the existing LIDAR bots. And also, here's the alerting checklist, that's the important thing, and it follows the idea of the early stages of alert creation. So I think that's all from my side, that's all about the protocol alerts. And now we can move to the questions. Okay, so, yeah, probably I will move with the mic. Yeah, I just want to add something about the Forta bots configuration. So I think that the person that made the question related to that already left, but I think that is worth chatting with everyone. So let me start by introducing myself. I am Lazaro from Nethermine and I have been working with Forta for a long time. So I have been facing this configuration, let's say a problem, that once your bot is deployed, you cannot configure your bot anymore. So you cannot change anything and you will need to redeploy your bot to do some changes. But this is only true, it's your bot is the one that knows the configuration details. You can have your configuration in a deployed smart contract on the blockchain. So you can change any value on the blockchain and your bot will notice that. So you will be able to change the configuration. Maybe this is not worth on the three minutes because changing that values will be more costly than redeploying your bot. But probably on Polygon, this is fine for you. And this can also allow you to do interesting stuff. Like for example, I don't know if there is something already on the, someone already on the Forta network doing this, but you can create a community bot. Something like you have your project and your community is interested in monitoring something. So you can create a bot. The bot is consuming the configuration from the blockchain, and you can let the community change the configuration by governance or whatever else. So this is one of the approaches I want to share, like having your configuration on the blockchain. And the other one is like, if what you are looking for is simply having different configurations in different networks, like if your bot is meant to be around on Ethereum mainnet, on Polygon, on BSC and things like that, you can have an approach. The initialized function of the bots was not covered in this workshop, but you can check the Forta documentation for that. And you can use the initialized function to detect in what blockchain, in what network your bot is being executed. And given that, you can use a different configuration for your bot by only checking in what network your bot is being executed. So these are the two approaches that I want to share. Yeah, thank you so much. Really good idea about storing configuration on chain. Probably not that cheap on the Ethereum mainnet, but yeah. So that's one of the options. Thank you so much. Yeah. Like keep your hands so that I can detect who to transfer, Mike. Is there any configuration in the bot? Like I can tell them to start from a particular block number or something like that? Yeah, sure it is. So in the example of the, in the fourth example, in the example repo and on the lighter bots, you will see that they're like, give me a second. Yeah, for sure. You can, when you run the bot on life, on nodes, it will start from the latest block. But if you want to test your bot against the given block, against the given transaction against the given block range, you should, you can do it simply by using Forta SDK and it is mentioned in the readmes of all bots. Also, you have the transaction and the block that gets passed into the handle transaction and block function. And so you can evaluate what block is being passed and change. You can do it, you can do it locally. However, you have to keep in mind it's a long time, right? And so it's going to be challenging to backfill completely. Hi. Yeah, I have two questions. One is that handle transaction function that will be executed on every transaction or the filter is applied before that and the bot will only look for transactions already for some addresses. It's every transaction and then your filter gets applied. I filter it inside that. And the other question is in our protocol, we are sort of a factory thing. So we instantiate a bunch of contracts. I'm not sure if templates is a solution, but is it possible to create bots that people can then, when they deploy their own instance of all these contracts, to just reuse it easily without needing to rewrite it? Because the addresses will change. Imagine instantiating multiple instances of... I mean, I suppose that the pattern that you described could be utilized there, right? Where you now kind of monitor what is getting deployed and then potentially kind of change the addresses that way. Okay. Does that, do you think that would work? Yeah, but in this case, I don't want to change the address. I want to like basically set up like a parallel, because the owner of that new instance is somebody else, the creator of this, you know? It could be used by people that are creating safes, right? And so, but you'll have to like, you'll have to configure it for your multi-sig, right? But yeah, but the template exists. So if you have a similar product or protocol where your users are just taking like a template contract, yeah. Sorry. Yeah. Yep. Yep. What project are you working with, by the way? Okay. All right. I'll connect with you. Hi. Thank you for the workshop. Just quick question. Are you planning to expand beyond EVM to like some other L2s or different chains altogether? I don't know whether we have any specific plans at this point in time, but I mean, we've been adding chain support. And so there's a particular chain that you're interested in. Talk to us and we'll see whether we can actually, there is a small hack that you can apply. You can go to the Forte examples and find the bot that is actually monitoring Salana. It is done like in a pretty strange way, but you can do it. So right now, Forte does not support anything except for the EVM chains. But in the Forte examples, you might find the interesting example on how to monitor the, let's say, Salana chain or any other chain with the RPC available. When I create a new bot, I need the nodes, some of the nodes to pick it up and start executing it, right? Or they pick up it automatically and they kind of, because you're saying that nodes can select which bots they're executing. So if I create a new one, it's automatic. So basically what happens is you, when you deploy your bot, you create the Docker container, uploads to IPFS, and then you register your bot with the Forte network and then the scan nodes automatically pick that up. But if I run the node, can I refuse? I can say, no, I don't want to run this bot. I don't think so. Okay. So all nodes run all the bots. Not all the bots. Like the thing of like, you know, the bots get deployed on six or seven scan nodes at the same time, and then that is satisfied, right? So these seven scan nodes run these sort of bots and these seven scan nodes run different types of bots. Thanks for this great and interesting workshop. My question is related about some fundamental question about disclosing information how our bot works, because if the hacker is not very stupid, it's pretty cool to go to Forte, check how it works, test this unit test that no bots even meant in alert, because I can upfocate my addresses. I can really make some pretty complex logic not to be detected. And after that, I run the hack and I could be succeed without zero alerting. As opposite, if you have some hidden bots, which developed by your team, but nobody knows or limited common people, it could create some surprise for people who do not really expect what happens. So what's the policy and what's the possible solution? Just let me start and then Christian will add his thoughts. So that's a great question. And this idea on the first glance sounds like, yeah, why the hell do we make these bots public? But on the other hand, since all the Forte network is public, and since there are many numbers of the bot developers, as much as like the more Forte developers and the more bots we have, the less the ability to even try to execute your attack against all these bots. Since the network is watching over the main net, and you have no ability, like let's say to run all the bots in the Forte network at home, I don't think that any hacker would ever do it due to the fact that the amount of the bots watching over the main net on the Forte network right now is really huge, and it will increase in time. So that's my point here, Christian. Yeah, I mean, I think it's a strategy, right? You could say, hey, private, and I developed them in-house, and you got coverage. Contest at the Forte, which I'm personally super excited about, is that it is a community-driven project, right? And so you have hundreds of developers, security researchers, data scientists that basically look at attacks, and then essentially develop bots that identify this attack from different approaches, different angles. So you get a lot of diversity in the detection approach that makes it harder and harder for an attacker to evade. And so I personally think that that is the better approach, but I can see that there are maybe instances where you're not comfortable to have the bot public and the alert public, and there's options on the Forte network that would allow you to do that either through obfuscation and encryption of the alerts or running your private scan. I want to get back to what Christian was discussing as an alert that aggregates some other alerts. So how exactly that can be done? Are you talking about the hierarchical nature of the alerts? Like we have some basic alerts, and then we have more like a kind of on top of an umbrella alert. That's right. So today, the logic there is fairly simple. It is basically saying, if you have a bot firing in each of these stages, then emit an alert. And we're grouping together alerts together based on a common EOA or a common EOA cluster. But that is very rudimentary. I think the next step is really to use anomaly detection to combine alerts together where you're basically looking at each of the stage and say, how anomalous is this particular alert? And then you combine essentially anomaly scores together to create one overarching anomaly score that you can then rank and emit an alert. Yeah, and probably I will ask you a question. From the technical point of view, there is the GraphQL API, a wonderful API, so that the combiner bot is actually not watching over the chain. It is fetching the GraphQL API and consumes the alerts from other bots, and after that creates a decision. So as we've talked about the Solana example, so on the Forta bots, you cannot only watch over the things happening on chain, but you should do some other stuff. So like fetching external APIs or fetching the Forta API itself. And as far as I remember, there's even an example of the combiner bot so that you can do it pretty easy. So let's say you have developed several bots, and then you want to have the combiner on top. On the Forta examples, you can find the example of how to do it really simple. Is it answers your question? Let me add one more comment there. So currently, the two main interfaces on a bot is handle transaction and handle block. There is going to be a new handle alert that allows you to build hierarchical alerts. Currently, the way it's implemented in the bot is basically triggers on handle block and then queries all the past alerts and then aggregates and combines them. But handle alert would be a cleaner way to do it. So we're moving into that direction. Are you aware of any potentially big hacks that have been prevented by using the Forta alerts? No, I mean, there was a question earlier. I don't know whether you came in afterwards. So there are certainly alerts that the Forta network admitted for many of the attacks that happened over the last few months. But in order to prevent it, you need to have kind of these alerts hooked up to then take action. And we have not seen any sort of automated actions being hooked up to Forta alerts yet. I think there needs to be kind of two things that happen, the precision of the alerts need to be increased such that this mitigation mechanism doesn't fire on false positives. And then also the mitigative actions currently, it's pause, a big hammer. There needs to be more nuanced actions that mitigate the attack while not negatively impacting the users of the protocol. I'm sorry? Not through kind of Forta and automated actions, but there certainly have been attacks where Jonathan was saying this earlier where not just the protocol got paused, but the entire chain got paused, right? So if you want your protocol to be protected and not to get in the situation when it was hacked and then you go to the Forta and see, here was the alert. So what you should do right now is go to the Forta app and subscribe to the threat detection kits. And then you can, you will have time to take actions. Okay, folks, any other questions?