 I think it's never really true that you're the only one that's wrong with you. Okay, look to number one. My name is Han Liu and I am a researcher from the Oxford Highland Blockchain Research Institute. And I will be talking about a research work on finding vulnerabilities in smart contracts. Okay, so commonly when you write a smart contract, you might want to do a validation procedure. For example, you can write a group of test cases to test whether your contract works or not. Or you can use a verification tool to verify whether a specific property holds or not. Or you can find an auditing team to send your contract to them and get their feedback. After that, hopefully you can get useful feedback and optimize your smart contracts and you can put them on the blockchain. But in some cases, those validations might not be able to work. For example, if there are a lot of large copies of auditing requests, it might take a while for you to get feedback from an auditing team. Or if something new, some new problems just come out and your verification and testing tool have not been updated yet, they might not be able to give you a good detection. So if you look at this CVE example which was reported last year, and you may find that this very simple integer overflow might be able to cause a zero pay transfer in this transfer proxy function. And it was happening in many other token contracts last year. And when we used some existing analyzers to analyze this security issue, they told us that nothing was found. So which was obviously a false negative in this setting. So the reason for this is that some of the analyzers, when they see an overflow, they will not directly report it. Instead, they will check whether these integer workflows will be followed by, let's say, a revert operation. If so, they might consider this as a protection mechanism, such like the SafeMath library. But this one is just not this case. So what we are trying to do is that when you have your contract, we would like to know whether your contract can be matched to some existing known security issues, and instead of directly analyzing them. So you can also do this for those contracts which are already deployed on the blockchain. And to this end, we are exploiting the idea of code clone detection technique. Specifically, we generate a birthmark representation for the vulnerable contract or the vulnerability itself. And you do the same for your contracts. And we analyze the semantics of them. And you do a sort of graph matching algorithm and identify whether they are semantically similar to each other. And given the contract, we create the control flow graphs for the contract. And we perform symbolic execution on the graph itself. And we refine the graph on the fly to make it as complete as possible. And for each basic block in the control flow graph, we first we abstract the path conditions to reach that block. And secondly, we analyze the dependency patterns in the block. For example, we will check which storage variable was first updated in the block and then used as, let's say, a perimeter of a message call operation. And such dependency pattern would help us better understand the behavior of this block itself and also the whole contract as well. And then we got a numerical form of a labeled control flow graph. And then we can do this at a contract level or a function level. And next, given a pair of contract birthmarks, we will first compute their numeric vector distance. And then we will adopt the similarity by construction ideas to calculate at what probability these two contracts or functions can be symmetrical clones to each other. And we also developed this econ tool to implement this idea. And we have done a bit of preliminary evaluation and it turns out that econ tool can manage to deliver better detection capability than baseline approach which only considers the syntactic information in the contract. And that will conclude my talk. And if you are interested in more details, you can refer to these two academic papers. And in addition to our contract security, we also do a lot of other interesting things including red tag or other secure protocols on our blockchain. And I will be happy to have any offline discussions. Thank you.