 So my name's Tim. I work in corporate research and development at Thompson Reuters in London. R&D typically works on problems involving machine learning, which is my background in natural language processing. But I think for about the last year and a half, we've been looking very closely at blockchain and trying to figure out where we, as an organization, fit into this space. We're part of some of the other larger blockchain consortiums, like R3 and Hyperledger. But I think we spend most of our time working with Ethereum and building demos, proof concepts on Ethereum. Next slide, please. So a little bit of context about our business. So a lot of you will know of us as a news organization, but this is only a tiny piece of what we do. We essentially have five diverse business verticals, financial and risk, critical news and information about financial data, regulatory information and risk information. We have a flagship product called ICON, which has 200,000 installs. And you can trade and do analytics on all manner of financial instruments. Someone asked me last night, we have ETH on that yet. And the answer is not quite yet. That depends on customer interest, but we're working with Crypto Compare. And so there might be a conversation there. Legal information for legal professionals worldwide, tax and accounting. Again, for tax and accountants and governments. Intellectual property and life sciences, so information and data for pharmaceutical firms, for example, and lastly Reuters News. And I would say that it's these first four that we are looking at potential blockchain applications. We're not as opposed, I saw on Reddit, suggested thinking about doing journalism on the blockchain. OK, next slide, please. Just to my present of you. So I suppose many of our products and services manifest themselves as proprietary databases and analytic solutions. But one of the problems that we've had to deal with from, I suppose, a commercial perspective is one of entitlement. So who should have access to these tools and databases? Typically our users will sign a license agreement. We will know their identity. So essentially we're doing some form of due diligence. And to help manage this issue on blockchain, I emphasize it's really a management rather than a sort of control issue. We put together what we call an entitlement framework which allows developers to control access to their dApps. Next slide, please. So what does this look like? Well, we decided to call it block one ID for Ethereum and we're testing it at the moment. And essentially it's a delegated identity service connected to entitlement contracts. So we would host an HD wallet. We only hold encrypted keys. ID is delegated via OAuth 2 to some standard providers. So it might be Thomson Reuters or LinkedIn, Facebook, Google, et cetera. So this is in effect a bridge between the wallet and OAuth 2. This requires that you need to be logged in to use the dApp. And if you're not logged in, access to the dApp is blocked. We have some ID obfuscation and also isolation. So there will be a separate address generated for different apps to prevent interference. And then on the entitlement side, that's performed on-chain. We have a contract that is populated with addresses by us, and those addresses are allowed to use the dApp. The dApp developer can require that end users sign up to terms and conditions. And a few things that we're looking to add in the future, no sort of certainty about this, but essentially connect up to some of our KYC services and add more identity providers. Next slide. So I suppose this is what it looks like. You would get a wallet bar with a very simple API, allowing users to sign in and out. There's auto generation of Ethereum accounts on first use for each dApp. There's also a wallet admin console. And importantly, we have no access to accounts or passwords. We only store encrypted keys, and the system receives an encrypted blob from our server. And down at the bottom, I suppose this is just the hierarchical wallet structure. And it sort of indicates that you would have a different address for each dApp. Next slide. So what sort of dApps and services might we provide? Well, I've already talked to a number of people over the last couple of days about KYC and AML services. And this is actually a space where we already are very active and have a number of so-called flagship products that are heavily used by, for example, investment banks. And we're having a good think about how we can make these things available on-chain, for example, via some kind of Oracle service. So we have something called OrgID. And this is a sort of organizational level database of 190,000 compliance records. We also have something called Enhanced Due Diligence. This is background checks on individuals. So OrgID is more of a sort of business-level KYC. Enhanced Due Diligence is sort of businesses and individuals. And then there's something called WorldCheck. And again, this is sort of entity-level screening based on both business relationships and human networks. So those are a few of our KYC and AML products. But there's another space where we have a very natural fit we think in the blockchain space, particularly with regard to our financial and risk business unit. And that's with regard to financial data via Oracle's. So we have a product called Thomson Reuters Electron. And this essentially contains vast amounts of financial data. Sorry, I've got to click on to the next one. Yeah, there we go. These products are already used by some of the world's top 50 investment banks. So in many ways, we're already a highly trusted data source. What Electron is, it's essentially a low latency feeds platform. It covers exchange traded and OTC markets, all manner of financial instruments, currencies, equities, you name it. And you can also get company fundamental data and we've spoken to some of the prediction market guys about that sort of information. There's real time data. You can get news from there, reference data, third party data. And we also have something called TIC history, which currently contains about two petabytes of microsecond time-stamped TIC data going back to about 1996. Great. OK, so we've already built some of this stuff out. So this is sort of quite an old image of a sort of Oracle architectural model. So you might start off over here. You might deploy a smart financial instrument. That might, for example, represent a bond, for example. You would make a request and that would talk to our Oracle and that would generate an event that we listen to. We've got a load of sort of back end stuff listening for the event. It figures out what the price request is for. So if it's an interest rate, then we use a standard REST API to talk to TR Electron, which is up there. Pull down the price, send it back to the blockchain, and update the smart contract with the data accordingly. There is a slight flaw within this scheme, as things stand. And that is, as soon as the data is written to the blockchain, it essentially becomes sort of unbounded. And actually, a lot of our information is licensed from third parties. And at the moment, we can't necessarily write data to the blockchain that then everyone is available to see. So we're looking very closely at some of the privacy preserving mechanisms, so zero knowledge proofs and homomorphic encryption. And some of those will probably be necessary to deploy something like this on a public chain. And here is some Solidity, which you probably can't see. But essentially, you can import this as a Solidity file. And you essentially have to, first of all, make a request. And in this line here, there is a byte study to object called a RIC, and a RIC is a Reuters instrument code. And that is essentially the identifier of the asset that you would query the Oracle form. You also need to implement a function called onOracleResponse and onOracleFailure. And then whatever sort of business logic you want your, for example, your financial asset to perform on receivership of the price you can implement there. And I showed that there was a REST call in that process. So this is the sort of REST response from TR Electron. So this comes back as a JSON object. And we would essentially take this information out and put it into the transaction, which calls onOracleResponse. And you can see the sort of thing that's in here. So the RIC, the Reuters Instruments Code, is the Euro. So that would be the price of Euro in dollars, lots of timestamp information, bid ask, bid ask size, and a multiplier to go from float to int. OK, so I'm not really a UI or UX developer. So I put this together just to sort of demonstrate functionality. But essentially, this is a sort of trading system for contracts for difference. And so at the top, we would have an order book contract. You would send orders to that order book. When the orders cross, a trade is entered into a positions table, which is this thing here, I think. I can't even see it from here. And the positions table is what deals with the Oracle interface. So these contracts for difference are linked to major indices, so the FTSE 100, for example. And from that point on, the Oracle would send updates. And we have a scheduling service as well, so you can schedule every block or every minute or whatever sort of granularity you're interested in. This data comes back. And you can see in the logging panel, the events are written out. And this is used to update the data. And you can see the change in the value of these trades. There is the possibility to implement things like, I mean, in this example, actually, there were some implementations of things called stop losses. So if a trade drops below a certain level, so if it drops below 5% of its value, it is closed automatically. And similarly, if it rises above, say, 5% of its original level, you might close that and take the profit. So that's the sort of functionality that you can implement in that sort of on Oracle response function. OK, so just a little change of tack now. So that's some of the stuff that we're doing internally. That's all sort of very much under test. We had some good feedback from the Ethereum Foundation guys about 10 days ago when we held this hackathon, which is, we thought, quite cleverly named hack ETHON. So we held this in collaboration with the Ethereum Foundation, many thanks to George for helping out with the organizational side of things. And we had a lot of Ethereum guys down as mentors and judges as well. So we had a slightly unusual format to this. Next slide, please. We had speakers on all three days. So we've heard from Thomas. We've heard from Peter Thomas was talking about Oracle's. Peter was talking about elaborate ways of breaking smart contracts. And we had Jack Gavigan from Zcash or Zcash talking about things like zero knowledge proofs. And this is probably my favorite slide, but you probably can't quite make it out. We managed to get control of the Thomson Reuters news ticker. And just to show you the global importance of this hackathon, it was sort of juxtaposed against the news story of the day, which was North Korea nuclear test. So we were quite fortunate to get control of that. We had two main challenges. So the first one was data-driven smart contracts. And the winning team was essentially a sort of crack or pro team from BMP Parabas. And they put together a fantasy football dap. I think it was called Fantefi football, so it's a more eth play, I suppose. So congrats to those guys who won the overall prize. The Ethereum smart contract security challenge posed by Ethereum. That was won by a team called Truth of State. And I think some of those guys are here today. Wave, if you're here, there's a wave over there. And we had a runner-up team. And I can't remember what they're called, Bounty Max. So this was about providing a bounty for smart contract exploits. And that was deemed the runner-up prize. And I think those guys are here as well. So congrats to those guys. So just one more, I think. So that was a lot of fun. We really enjoyed that. And we're going to hold another one in Switzerland at our office there in Bas. That's going to be January 27th of 29th. Again, Ethereum-based with the Ethereum Foundation guys helping out more sponsors and some data providers to be added in future. And details about that will be made available through the usual channels. OK, and that's it. Thanks.