 Now we're going to Q&A session. Our first question is going to be for Anur, and it's from George, and it says, what would you say is the closest deployed work in terms of cyber-resistant record placement? Are there any aspects specific to this application that require the adoption of different mechanisms? We are not aware of any other work that are super resistant in an open decentralized system like Ethereum work that places records on other nodes. There's only the current deployed discovery system, which is based on a random walk approach. We also evaluate the built-in DHT approach where you route to the closes nodes, the nodes that are closest to the topic hash, and then you register or you look up there. How often your eval would a consensus instance get block hash from the primary without mempool delivering all messages in the block? This would delay the consensus protocol, I presume, and then the following one was, TUSK reminds me somewhat of Hedera Hashgraph, any comparison? For the first question, one sentence answer is, so the primary sends the certificate as they come to the consensus, but they run the same machine because the consensus just interpreted like, so there is no delay there. However, the primary creates the header either every 200 milliseconds or when it got about one kilobyte worth of hashes, that's about 33 hashes. Those are configurable parameters. For the second question, the difference with Hashgraph, there are many actually, the difference pretty much stops that we both use a DAG. Our DAG is structured, every header links to 12 plus one certificates of the previous round, not of any round. And also we have a DAG of certificates which guarantee availability. That's not the case of Hashgraph and others. Question on your mitigation slide. I think it said something like, no eviction of valid transaction that transforms existing valid transaction into invalid. This may be obvious to others, but could you clarify what that might look like? So on this case, we mean that when you evict valid transaction, there is chance that this valid transaction can transform other existing valid transaction into embedded transaction. For instance, in our previous example, if let's say you have a transaction with nonce one, transaction with nonce two, evict that transaction with nonce one that will make the other transaction a future transaction. So this sort of creates a future transaction out of a blue. And in our case, we also prevent that from happening. Did you look at this problem before the bug bounty or the bug bounty made you look at the problem and how interested are web-free bug bounties for academic groups? So I can speak on behalf of my case. I think a bug bounty is really helpful in terms of encouraging students to look at the code and find problems over there. We first read the Ethereum source code first and then do all kinds of brainstorming. We did find problems. And then we ventured out to interact with let's say program managers on those bug bounty. They are really helpful in terms of how severe the problem is, how much border impact the problem is. And they're also really responsive in terms of coming up with a quick fix to protect their system. So to me, I think this is really very useful and helpful platform for academia to support or to promote their research and deploy their research with production software. Yeah. Thank you. Thank you for your insight very much. I think it's a very useful tool and we are looking into deploying across web-free communities, right? This is on a larger scale, I would say. So I think this would be one of the topics of discussions tomorrow. So yeah, that was my question. Thank you so much.