 At the EF, we have a lot of security researchers, they spend all their time trying to break applications and basically to figure out how the specifications of the protocol might be broken and then trying to sort that out. We also take in some external bug hunters from time to time and they kind of focus on a specific task at hand and also to augment that we use a bug bounty program. The bug bounty program is there in order to allow for external researchers to come in, do some vulnerability bug hunting and then basically submit reports to the bug bounty program. And this is done so that we can provide rewards and other incentives to the bug hunters. So our scope is kind of wide. We have, you can see a list there, basically all the clients. We have the deposit contracts, deleted bugs and the specifications of the protocol. But something that we don't have, which is kind of unusual I guess, is that we don't have any scope for websites or for infrastructure or for anything else. We focus solely on the protocol itself. You can use two different ways of having a bug bounty program. You can use bug bounty program as a service, basically paying a service provider. There are many of them. They will come in, set up your bug bounty program. They will provide often a very, very large set of bug hunters. They are ready to just start hammering on your application. Or you can do it in-house. And there are some pros and cons with each. But the reason we went for an in-house solution is that Ethereum is kind of complex. It requires a lot of expertise. A lot of digging through it compared to, let's say, finding an SQL interaction in a web application. So we didn't feel that there was that much value. So that's why we went with an in-house solution. And we also have a team that can triage any reports that we're receiving. But depending on your situation, you might feel the need to go with a service provider. So looking at the history, we can see that in 2015, we launched the first iteration of the bug bounty program. It had a very narrow scope. Some execution layer clients and the rewards were 5BTC for a consensus issue, which today would be quite a lot. But back in the time, it was 1,500 bucks. Over the course of the years, this was increased. And in 2020, the consensus layer bug bounty program was introduced. At that time, the execution layer had a bug bounty of up to $25,000. And the consensus layer received a max bounty of $50,000. We also have a specific thing where we will double the rewards basically just before hard forks. So this is done so that we will get additional eyes on any updates that we're doing to make sure that there aren't any obvious issues. And then in 2022, we merged those programs into a single one. We also upped the rewards to $250,000 as the base max reward. And you can also get a 2x for a hard fork. But for the merge itself, we increased it 4x. So we had a 1 million bounty out during the merge. This is what it looked like back in the days with the execution layer bug bounty program. You can see the leaderboard there and basically you submit reports via email. You could use encryption if you want to, but the majority didn't do that. Currently, we have two ways. We have the email system where you can submit a report or you can also use Google Form. What kind of surprised me is that the vast majority of people they want to use a form to do it. It's a bit easier to fill out because you have this kind of preset questions that you have to submit. But there are some security concerns with that, which I'll get into soon. So in the course of the bug bounty program, we've received about 200 plus vulnerabilities that were actual vulnerabilities, counting the spam and non vulnerabilities, probably 2,000 reports. But it's about 200 plus actual vulnerabilities. And you can find these vulnerabilities in a public disclosure repo that we have on GitHub. If you're interested in digging in a bit in what vulnerabilities we've seen. It's not completely updated. We update it after each hard fork. So right now I think the latest update is in May or something like that, March maybe. But we will update it very soon again, given that the merchants now happen. So there will be additional ones to be found in this repository. Oh, and if you're interested in some specific vulnerabilities learning more about like in detail, you can have a look at Marius talk that he had I think two days ago. So like I said, we're using the Google Form system right now, which isn't super good from a security perspective, because the reports we receive are plain text or clear text. Anyone can read them as long as they have access to the Google Form system. So if a user with access were to be compromised or Google Forms were to be compromised, then that would pose an issue. Especially now that we're dealing with vulnerabilities that could affect a lot of funds. So we have been building a secure submission form, which is based on OpenPGP.js. And this allows basically bug hunters to submit vulnerabilities. And before they're submitted, the data is encrypted on client side. And this means that even if someone gains access to an email account or something else, then they can't read anything unless they have the private key. That one is not yet available publicly, but we do have a smaller version available that people can download if they are interested in it, which is the secure drop. Looking ahead, we're working on building an encrypted vulnerability lifecycle system. This will allow us to basically follow the vulnerability from start to end. We will be able to receive the vulnerability, assign it to certain people, have comments, assign it to client teams, and then close it as needed, all while being encrypted. And we're also looking at additional incentives for bounty hunters. One of them that we've been looking at is basically creating bug hunting NFTs that will provide some value in real life at events, etc. And Remix Team has been doing something similar. So that's it from me. Thank you very much for presenting the stuff.