 Hi, I'm Antoine. This is Philip. We're from Enuma Technology. Enuma is an engineering company, so basically everybody in the company is a developer. We've been around since 2015, worked on different blockchain projects. Way back, we started with Bitcoin, multi-chain Ethereum, worked with different blockchains. So we got a grant from Ethereum in May to work on Sprites payment channels. So I'll show you what we've done here. And we've also been building kind of like, after we've done the work on Sprites, we started working on decentralized exchange and how we can make them more performant because you've used the decks that are available out there today, but a lot of them are really slow. You have to wait a while for your transactions to be confirmed. So we're trying to solve that problem also using state channels. Let's see. So I would have done it live, but I was having some problem with the Wi-Fi, so I recorded the demo just about an hour ago here just to show you. This is the Sprites demo. So what we have here is, on the left side is a merchant website. So imagine you're going to the convenience store and you want to buy, like I live in Hong Kong, in Hong Kong we have this card that I can top up with money, go to the merchant, swipe it and buy things. So that's my merchant website. I think it has not paused. So I can select some items and we're using the dye stable coin here because I don't want the price of my Pepsi Coke to change day to day. So I select some items. So 1.6 dye and then click on checkout. So I get a QR code. And then using the application, this is on my iPhone. I'll tap to log in and unlock my wallet. So this is, by the way, we're mostly back in engineers. Sorry for the UX. If anybody here is talented in UX or we're hiring. But this is mostly a dev demo to show that you can connect to the channel. Then the balance will show up and the history of transactions. Then I'll click on make payment, scan the QR code. It's very fast. And confirm that payment to the merchant. And then it says payment successful. The merchant should see the balance of 1.6. So by the way, here there's like three parties involved. So there's the end user going to the shop. There's a payment provider who's the middleman. And then there's a merchant. And where Sprite comes in is that we use the conditional payments so that I can pay the payment provider. The payment provider can turn around and give the money to the merchant. And then that payment is done once I reveal the pre-image. And then the merchant can at some point decide to withdraw, which actually does a, this is where the on-chain transaction comes in. So typically the merchant would withdraw maybe just once a day or once every few weeks. All the other transactions are done at later too. This part was just to show the blockchain transaction idea actually. And now I'll pass over to Philip to talk a bit about what we've done since with decentralized exchange. Thank you, Anton. Hi. So as Anton mentioned, we are also working on a secure decentralized exchange. And we've been working on this since a few months. And our initial approach was to use this payment channel here to techniques with the idea that all the user would be part of a network and create a channel between each other and then be able to exchange tokens. And after analyzing this and trying a lot, we realize that there are many shortcomings to this approach. For example, if you use these payment channels, in general you need to have collateral in order to ensure that the payments go through. Then, okay, we need to build this network, but how do we do this? I mean, it's not easy to build a network. It's not only about code. It's about incentivizing users to join the network and so on and so on. So we have more questions than answers. And also there are technical challenges. Like, okay, we have plenty of orders that are spread across this decentralized network. How do we match these orders? Who is going to do that? So after thinking a lot and banging our heads on the wall, we decide to step back and think again about the problem. The problem when we build an exchange is that we want to avoid to be the next empty gox. So what does it mean? It means that if you want to avoid that, users should be always in control of their assets, their token. So having a decentralized network is a way to achieve this, but maybe there are other solutions. And that's why we end up with this concept of trustless exchange, more than decentralized. And the nice thing is that we get kind of best of both worlds. We have first something that would be more like hub-based. I didn't put centralized because it's like a word you want to avoid, but it's the idea that we have a coordinator that would take all the orders, match them, and update the balance correctly. But at the same time, it would be trustless. And if we have these both things, we can be both efficient and secure. So at the very high level, how it works, we'll have this hub that will take the orders and match them. And from time to time, it would synchronize the blockchain to ensure that all the balances have been updated correctly. And users will use the blockchain only to deposit and withdraw, and all the rest will be made through the hub. So yes, there's still quite some work to do on this, in particular, analyzing the security in detail. When you build a new protocol, you need to verify, be sure that there's no flows and problems, and also being able to implement the features of an exchange like atomic swaps and partial order. And now Antoine is going to show a little demo of what you have so far. Thanks for that. Yeah, the demo may not look so impressive, but what we've done is we've implemented all the theory of how at layer two an exchange would be done, atomic exchange, completely trustless. And so what's missing from the demo would be the on-chain part, like depositing and withdrawing at the end. But just to give you an idea of how this would... Actually, some of the code we have, we actually create an exchange object. We create multiple different trading pairs. There's two parties involved here that are going to deposit money in the channel and then trade with each other. So they do create order objects, and then these orders are being matched. And each order you see, when I place an order, the order has to be signed by the first party. And then to take an order that's been placed in the order book, I also have to sign. If you're interested, come see us after. I'll give you all the details. But when I run it on my old MacBook, this is a 2015 MacBook, we take advantage of all the cores. It should finish pretty soon. So I just got under 2,000 transactions per second, like at layer two. So we are working on mechanisms to handle the deposits, the withdrawals, and also there's some synchronization that needs to happen on-chain at some frequency. But this is the kind of number we can expect, even from an old machine. And this is horizontally scalable, so we can add more nodes to the network. Hello, thank you.