 So, RAID network, I'm going to talk about this off-chain token transfer network, maybe start again with why we're doing this. And the reason is with current state of blockchain technology, there are some problems. We can only do a certain limited number of transactions per second to reach finality, to be sure that the transaction will update the state. That currently takes 15 seconds for a block, but you should wait multiple blocks so that can add up to 100 seconds. And another issue is that all state of the blockchain is readable for everyone. And the throughput issue leads to higher transaction cost because there's like a limited resource of transaction or capacity on the blockchain. The reason for this is global consensus. Global consensus is very expensive because if Alice sends five tokens to Bob, then the world needs to know. And all the nodes need to reach agreement on this fact. And the problem is the latency and bandwidth properties of networks, there's latency and the bandwidth is limited. And you want to have as many nodes as possible participating in the consensus protocol. So if you switch to a different view on consensus, if it would only be between Alice and Bob, say Alice would send Bob like a check saying I owe you five tokens. And if you then add some state channel technology, which would allow Bob to be secure about the fact that he's able to claim those five tokens on the blockchain, then you have a pattern which you can use to solve this problem or to improve the situation. And that's what we base the read and token network on. So what we do is basically we have many or we have participants have state channels with each other, like say every participant has like five or 50 state channels with other participants, and together they form a network. And if two participants want to, which don't have direct channel, want to transfer tokens, we can find a path in that network to transfer them. And all transactions happen outside of the blockchain for the token transfers. We use the blockchain only to manage deposits and to eventually settle. So that's nothing you need to do, but you could do. Today I want to go into the implementation details. I presented them last year at last year's DEFCON. But let's recap the features. So we can scale out asset transfer capacity. We get good finality properties, like one second finality. We get better transaction privacy because only those nodes involved in the transfer are learned about the transaction. And we get very, very low fees. And well, the way how we build the system is it's compatible with the year C20 token standard. That is, it should be compatible with most DApps that are built currently. That's a bit unfair, but it's like Ethereum compares to the rain that works like an early bike to MacLev. Except for the cost. It's way cheaper than MacLev. So one concept I need to explain you, because we come to that later, is what we can do in raiden is we can entangle two transfers. So if Bob and Alice want to exchange tokens, say Alice wants to exchange 10 A tokens for three B tokens with Bob, then they can set up two transfers, one sending the A tokens, one sending the B tokens. And they can lock them together so that either both of them go through or none. So that's atomic, which is a night property. Something else we can do is so-called smart transfers. These are transfers which can only be settled on a blockchain if a certain condition on a blockchain is true. That could be the outcome from an oracle or the last price from an unchain exchange. And then you can build more advanced applications based on rain like betting or financial derivatives. So what's the status of the project? We've been working on this since last September. We had a long sprint starting in May, I think, and it ended maybe in July. But then we were able to do the first transactions on the raiden, sorry, on the Ethereum test net. Actually, the transactions have been off-chain, but the setup was on the Ethereum test net three. Well, we had a transaction initiated from a note in Copenhagen going to note in Florianopolis and finally the receiver of the transactions was based in Mumbai. So that's where our colleagues are, some of them. Well, we get quite good press coverage for that and we're happy that we could deliver. So basically raiden works. Because one of the better applications of raiden is probably in the Internet of Things technology, we prepared a demo for that. So here the basic setup is that we have a producer and a consumer of electricity. And the producer, he has some meters so he can account for how much energy units were transferred and there's a Raspberry Pi running a raiden note and the Raspberry Pi can control and relay to switch off the electricity supply. We have the same thing on the consumer side, there's also a meter and a Raspberry Pi with a raiden note on it. And now the producer requires that the consumer send some tokens and if he does so, he will start supplying electricity and you see the light goes on. And then there's this LED, it blinks and whenever it blinks, there's one energy unit consumed and whenever it blinks, we send one token using the raiden network. So here we can see that on the consumer side he has only 19 tokens left, that's all he has on account and the receiver side, the producer earns those tokens and the consumer has also some credits. So now those tokens are transferred, detailed view here. Whenever it just blinks, there should be a transaction going on here, so for every impulse the meter gives, we send a transaction. Well, then at some point in this demo the consumer ran out of tokens and also the tokens that he had on credit with the producer goes to zero on the upper right and then the producer will decide to shut down the electricity supply. And well, you can imagine if such a technology or similar is used and widely deployed in IoT, then we will see like millions of transactions in short time frames and that's something that you can tackle with technology like raiden but not so good with blockchains that use global consensus. We're working with the swarm guys and we try to leverage their network transport and also we try to convince them to use raiden for micro payments and swarm and in the light client protocol, we thought about how we could integrate raiden into the theorem clients, most likely a candidate is that we would kind of wrap the raiden API into the chasing the API of the theorem clients and there's already some early industry adopters who try to build applications on top of raiden expecting that it will actually work. We have a roadmap, like the most important part is probably the routing problem which is still to solve in a way that it's scalable. Currently we have required that we build a view of all the channels in the system but it will not scale to a large IoT setup but otherwise we hope that we will be able to have a test net of raiden network on the theorem, like a better of the raiden network on the theorem main net this winter. One more thing I want to talk about is decentralized exchanges. Let's look at how decentralized exchanges work on the blockchain currently. Basically that's a smart contract which implements an order book and takes token interest crow. So if someone wants to sell tokens, we call it a maker, he will send those tokens to the smart contract and says which price it sets for those tokens and a smart contract will take the token's interest crow and list the tokens in the order book. And if someone likes the offer, we call it a taker, he will pick that offer and send the requested tokens to the smart contract, the transaction and then the smart contract will give the transaction to both parties as they expected it. That works, that's good. But the problems here are again throughput, we can only do so and so much transactions per second, finality like you don't want to wait 100 seconds to be sure that your trade went through and transaction cost is rather high. So how could we build that on raiden? The easiest approach would be just to broadcast your offer to a group of interested traders or parties who want to exchange tokens and then one could decide to be one who picks that offer and a taker and make a good engage in this atomic swap which I showed earlier. You could just swap the tokens off-chain securely. But the problem is basically if one party, no, the set-ups, if two parties want to set up an agreement, the one who signs it first or commits to it first offers the other party a free option because the other party can decide whether it also wants to join the agreement or just waits. Maybe the price moves into his favour and then he can later decide to take that option or not. You have this problem if there's a long time, if there's a longer period where this situation can exist. So if you had that for a decentralized off-chain exchange, that would not work. So it would be exploited and that would not be a workable market. So the solution could be that you work with a third party. Basically the free option from them is only solvable with a third party. So that third party would, well, it would offer to take commitment deposits from both parties and notify both parties if both parties committed to do that off-chain token swap. And if they fail to later prove that they actually executed the token swap, he would keep or burn those deposits, otherwise he sends them back. And if we have the incentive set up like this, it could work and how it actually the flow of actions would be something like the offer of the token, the maker deposits with the third party. Then crosscasts the offer which has a reference to that deposit with the third party. Then someone who is willing to exchange your tokens also needs to deposit and if he does, the maker gets a notification. Then they both do the token swap. And if it goes through, both confirm to the third party that it worked and then third party can release those deposits again. And the properties we get here is that it's off-chain, none of these transactions goes to the blockchain. So we get high throughput, low latency, low fees, basically the rating properties. And while that looks complicated, I think we can abstract it in a way that the API and the user experience is similar to traditional exchanges. One more thing to note is there's limited trust required to the third party because it could run away with the deposits, but with the commitment deposits. But they're very small compared to the tokens they want to exchange. It does not take the tokens, it takes different deposits. And if it makes a business model out of this, then always the business would be at stake. So that probably will not happen. OK, one more thing. Should we plan to move Raiden to become a generalized infrastructure to run off-chain applications? And the infrastructure might be easier than actually giving developers good tools to develop off-chain applications. So therefore we also plan to provide a framework which makes it easy or at least easier to build this kind of applications. And we just last week met with some nice other people from the ecosystem and we think about joining forces to work on that. So to summarize what you should take away from the talk is Raiden Network works and will be available soon. We aim to go beyond sold token transfers. I believe that the Ethereum killer apps will somehow be based on Raiden or similar technology because if they're killer apps they need to scale somehow and should have a good user experience that has low latency is also important here. And we also think that if you want to see broad industry adoption of distributed ledger technology then we need something like the Raiden network or similar because again the properties of scalability and especially here transaction privacy are important. If you want to learn more about our project then here's some URLs and otherwise I'm done. Thank you.