 All right, so thanks for coming, guys. We are at Rise today, as opposed to our usual venture in Leicester Square. So thank you to Rise or Sponsor. They're an incubator. They have all sorts of interesting projects, so I really encourage you to check them out. In terms of all the sponsors, we'll go straight to the sponsors. So we have Crypto Compare. You probably know them. Vlad, unfortunately, and Charlie couldn't make it. But they asked me to tell you that if you have any need for information around the pricing of crypto and things of that nature, feel free to visit their site, Cryptocompare.com. It's pretty cool. There's also a bunch of forums where people discuss things and there's no trolls there, which is nice. It's a big change, right, from Reddit. We also have the Blockchain Connector, a new sponsor. Where's Antonio? Where is he hiding? Antonio, you want to say a few words, maybe? Yeah, you need the mic, though, if you want to say something. You'll do a lightning presentation at the end, yeah? But basically, if you guys are looking for developers or if you're a developer looking for a job, I would recommend you talk to this gentleman over there, Antonio. And there's Socket. Yeah, Socket is a small startup. It's pretty interesting. I like it. I think they're pretty good. So a lot of people are saying, hey, what are you doing since the dark? Blah, blah, blah, you know? So I thought that I'd show you a little bit what we've been up to. So this is share and charge. It's a project that we're doing in partnership with a giant company called Enoji, which is a big energy giant in Germany. They used to be called RWE. And what's different about it is that it's live. It's a real project that uses Ethereum today, not in 30 years down the line. And what people do, this is translated, by the way, you have to forgive the broken English. This is translated straight from the German because it's in live beta in Germany. If you have a charging station and you want to share it because you want to recoup the cost of your investment, you just do so and it's completely handled by the blockchain transparently. And similarly, if you're a user and you're looking for a charging station, there's a little map here and it tells you where to go, where to find it. So why this is important is, hey, it uses Ethereum, which I think we all agree is cool. And second, it allows to have up to 25,000 new charging stations in Germany, as opposed to the existing 5,000 that are opening up thanks to peer-to-peer technology. And I think that's really important for electric vehicles because a lot of people don't want to buy an electric car because they're wondering, where am I going to charge my car? So that actually answers a need today and it's in beta. We have feedback in there that you can go and have a read and people can just choose how much they want to charge out their own electricity, if you will. Yeah, so have a look at that. That's what we've been up to and we continue working with these guys and others on right now we're really focused around mobility solutions. Okay, so without further ado, let's go back to the main presentation. I'll just press the right button, there they are. And yeah, a couple of admin stuff. So if you want Wi-Fi, this is the password. Feel free to take a picture and if you can use the hashtag, that'll be awesome so that way people know next time to use the ETHLDN hashtag. Speakers, tonight we have some an interesting mix of speakers actually. We have PWC, you also may have heard of this little company. We're going to present a solution that interfaces Ethereum with the enterprise world so I really look forward to that. We have another small company called Thompson Reuters that's also gonna present small, tiny startup. And these guys have some interesting stuff going on around ID, identity that is. And they recently run a very successful hackathon as I understand it, and I'm sure they organize others, they'll present that to you guys. We also have Alice.si, who haven't arrived yet, is Alice in the room, oh, you've arrived. So that's completely different from the other two. I think it's a charity. So it's gonna be really interesting to see how we can apply Ethereum to more not-for-profit causes, which is something I'm really interested in too. And that's about it, so in terms of volunteers, I also wanna thank Andy, Andy, where are you? And he's over there. I give him a hand, he's done a lot of work. I mean, he was helping raising this big box of beer, you know, all the way here and all that. So thanks, Andy, and organizing the whole thing. So thank you very much. That's it, I haven't forgotten anyone. Have I, Andy? No, oh good. All right, so without further ado, please welcome. I believe it's PWC first, Fergus and Ajit. My name is Ajit Tripati, I work with PWC. I'm also widely blamed for having started our blockchain practice in the UK, well credited. And Fergus was there before me. So Fergus has been there from the times that the only thing on blockchain was cryptocurrency and Fergus was going around the firm saying, hold on, the revolution is taking shape, we really need to get behind it. And since then we've built a 20-member engineering team, we have done some really cool things for some very big clients. Now in this community, I mean, we're now gonna talk about some of the coding we have done, because I mean, that wouldn't go down very well with some of the coolest folks in town, right? I mean, I'm sure a lot of developers here are way better than anything that are doing really cool things that you won't see in the enterprise world anytime soon. But what we're gonna talk about is something more around how we essentially are gonna help our enterprise clients go from POCs to production because over the last few years, there has been tremendous activity in blockchain, but at the end of the day, we gotta get out of POCs and we have to see some of the more industrial applications happen outside of the public blockchain as well. I mean, the technology is tremendously useful. At the beginning of this year, we did a project with the central bank, the Bank of England, and that was on Ethereum, where we helped them build a trade, a settlement POC. And one of the things that we tested as part of that, or demonstrated as part of that was that, well, let me take a step back. October 2014, the Bank of England's real-time gross settlement system went down, right? And this is the system that processes 500 billion pounds worth of payments, interbank payments every day. Now, when that happens, then the economy sort of doesn't really move on that day. So it took eight hours to come back up and that's one thing that the bank never wants to see again, right? So one of the things that they are really focused on is resilience and we help them actually explore the technology and take that central bank note down in the distributed ledger and then demonstrated that banks can continue to do what they do and the central bank can actually build a system that doesn't require the central bank systems to be alive for the transactions to continue. So that went on really well. I mean, that was taken by the governor of the Bank of England and publicly he spoke about it. And since then we've done a lot of work with our enterprise clients and today we're gonna talk about where we're going from here and how we see our role as big boring auditors. I mean, I was an engineer before and I didn't imagine that I would end up an auditor but today we're gonna talk about how as auditors we are essentially helping our clients and how we can sort of helping some of this stuff go into production. But yeah, what we'll share with you today is really some of the observations I've had over the past year of working clients and the conversations we've had. Again, there'll be some, you know, a slight banking and financial services slant to it because that's my sector. But some of the things we'll talk about are relevant across sectors and for all sizes of business looking to experiment with Ethereum, whether that be the public chain or private chains or third party solutions. And we'll come on to sort of cut it into six distinct areas where I think recurring themes that clients keep talking to me about that need a bit more clarity before it goes prime time. Outside of work, I'm a crypto enthusiast. I love Bitcoin, I love Ethereum. I was lucky enough to get involved in the crowd sale. I wish I'd done more but I'd been stung by Litecoin by $24. So I'll always blame Charlie Lee for me not having more ether and still having to be here talking to you. I've also recently done the B9 Lab Ethereum engineering course which I'd highly recommend to anyone. Eduardo, sorry for shouting out a competitor. So hopefully I can give you some insight and hopefully it's not too consultancy related. Regulation and law, we all know the challenge is there. Key management, a subject close to my heart and security obviously really important and maturity and integration. We'll go through each one of these quickly. And then we'll have enough time for Q and A at the end. So I won't labour the point around AML. It's a non-starter with banks. If you walk up to a compliance team and you say I want to go and play around on the Ethereum public chain, I need to buy some native tokens to decentralize peer-to-peer network that sits outside of the financial system and there are no AML controls, there are no customer controls. It's just not happening at the moment. A couple of areas I do think that are relatively interesting to know around data. So data privacy, both in a regulatory point of view and also from a business point of view, a lot of banks don't want public transparent transactions across a network. You will have all seen the hype around Zcash and that coming out recently in zero knowledge proofs. Some of you might have read the Hawke White paper around smart contracts on Ethereum that implements the Zcash protocol. I think that has a lot of potential but I also think it's two early days and I don't know anyone that actually really understands zero knowledge proofs. So if you go into a bank and try and explain that, I'll be really interested to know how you do that. The other area I've seen popping up recently is this idea of the right to be forgotten and the right to erasure in current European laws. How does that even work with the mutability in the blockchain space? How can you ensure that you'll be able to actually erase and forget people's data if it's on the blockchain? I don't know about the applications that are being built but I'm sure some of them will look to put data on chain. Perhaps you'll need the Accenture editing blockchain. I don't know, maybe that's the use case they were thinking about. And then there's a new regulation which I don't know a lot more about than I do the general data protection regulation which is coming in which has much more owner as terms in terms of banks and companies needing to delete people's data that they hold on them within 48 hours I think for a request coming. So if you think about that in the context of Ethereum and blockchains and the mutability, how does that play into that's one area. Moving on to legal uncertainty. Again, we've heard this all before. Are smart contracts legal? Are they legally enforceable? I think one of the past Ethereum meetups a couple of months ago, there was a great panel of lawyers on there talking about these subjects. So please go and check that out afterwards. One area I'm really interested in is jurisdictions. If you're looking at public chain, what jurisdiction is a smart contract in who's accountable for it? And then in the private chain space our clients are talking about are smart contracts legally enforceable? Check out Nina Gilbride from Monarch. She's done some great blogs on the enforceability of smart contracts. There's a great deal of law out there already on electronic contracts which should really cover a lot of this. I think it's just a matter of time. But there are no precedents yet with smart contracts and blockchains, I don't believe. So that just causes concern amongst businesses. Next, key management or lack thereof? Key management, yeah. Key management obviously a hugely important area in Ethereum and all blockchain implementations. You lose the keys, you lose control. Now that isn't so bad in an individual case. And I've fallen victim to this where you forget your password, you lose your backup, you delete your key store folder and you lose your Ethereum which is annoying and costly. But you put that into the business sphere and suddenly you're talking about huge amounts of value going across networks. You're talking about smart contracts that control important processes in regulated environments. And I've not seen enough being said about key management where they're generated. I don't see anything on standards. I haven't seen any frameworks or best practices out there for businesses to get hold of, to educate their staff, to do training. I've not seen any real hardware security module work going on that I'm aware of that's appropriate for business. Again, I've got a ledger in NANOS for myself now after my losing of the ether. But again, who's doing that and where is that? And where are all the controls and frameworks in place to have that there? So it's another big area. Related security. Again, it's been an interesting six months through Ethereum. We've had issues at smart contract layer. We've seen bugs, we've seen not enough testing. More recently we've seen denial of service attacks going after op codes. We've also seen, I think just last week there was small incidences where variables could be overwritten. So again, we're talking about not fatal things and actually Ethereum I think will get stronger from learning through all these things and being tested in the open in the fire. But again, when you put it through a business lens people hear these things and suddenly they start questioning them. There aren't many people inside the business that really understand the difference or the importance of whether it's an issue at protocol level or just at smart contract level. And these things just delay projects. They cause people to rethink their investment decisions. And that's just one of the other features. And one thing I've been noticing recently actually is the massive decrease in the hash rate on the public chain. I think we're down to about 5,000 giga hash per second which was up at about seven and a half thousand. Say three, four weeks ago this is largely attributed to Zcash. But again, hash rate in a network is very important. So that's one to keep an eye on. Now coming onto that too this is just a bit around how mature is Ethereum as a piece of software, as an ecosystem. It's only a couple of years old, Max. We're not even hitting the metropolis or serenity releases yet. So everything I've just said you have to take with a bit of a pinch of salt. But again, established businesses and banks they want mature solutions. They wanna know that what they're buying or what they're using is stable. They wanna know that it will do what it says it will do. And interestingly, I think a lot of banks want to hold someone accountable which obviously doesn't really make sense in the public space necessarily, but in the private space. You know, if we're talking about them using early stage companies like Clearmatics or Monax are they bigger than have they got the balance sheet to really satisfy a bank's decision-making engine? So keep an eye out for them moving towards bigger players like Microsoft and IBM who may not have the best solutions that they may do but they certainly have a balance sheet and a reputation to make companies feel comfortable. And finally from potentially something that is not mature enough to something that is probably far too mature legacy infrastructure at banks and other companies. How easy is it for them to interoperate and how easy is for them to implement Ethereum into these legacy stacks? And it's not just the technology itself it's also do they have the devs do they have the right people internally? Do they have the guys that know how to develop deploy and maintain this software? Do they have, do they have those guys and I think Eduardo will come on and maybe talk about that a bit later? And also does it fit in with their current businesses good current business functionality and how they operate today? You know, a lot of the time I get pushed back saying but can we write our daily reports out of Ethereum or a blockchain? You know, aren't they write only aren't they optimized to write and append data to? It's this type of thinking around how business process will change and how blockchain technology and Ethereum in particular is a whole new different business model that people need to get their head around. And so, you know, that being said that's, you know, those are six areas I think need a bit more thinking before you'll get the business community really happy and really comfortable. So any questions? So I'm 25% older than Fergus so I have a lot of stories and I'm gonna go over some of the stories about each one of these things, right? So one of the things I think we need to recognize about so first of all, when we talk about blockchain there are two whole other two completely distinct communities, right? And there is some interaction but you have the open source cryptocurrency community and we are really excited about cryptocurrency and smart contracts on the public chain but then there is this and that's where a lot of real innovation is happening, right? So some of the most exciting ideas come out of this community but then there is a whole other market which is essentially big banks, firms like us which are essentially looking to first of all create new business models which are much more efficient than what we have today but at the same time upgrade the technology on existing business processes, right? So if we operate, let's say a supply chain a certain way or if we do faster payments a certain way in the case of the RBS announcement then does this technology allow us to do the same thing 50%, 25%, 10% better, right? And in that scenario there is a strategy question which is what's my role? Now if I'm an intermediary and this new solution takes away my role entirely then maybe that's not where I need to be and if it creates a better business for me that's much more efficient then maybe I need to play in that. So there is a whole enterprise marketplace opening up for the underlying technology and that's where I think you've spent a lot of time. Unfortunately or fortunately when you're doing then let's say the DAO happens then you don't get a call from the SEC at least I hope you haven't but when it happens for a big bank then immediately they get calls from at least 10 or 12 regulators around the world depending on where the victims were who heard about it and so on and so forth which is why large banks have massive compliance functions, right? After the financial crisis. So before the financial crisis I was a developer at Goldman and we used to make changes straight into production sometimes in SECDB which is our pride and joy. Yeah, you know make this change, oh push it absolutely beautiful. Functional programming in Slack, slang not Slack, it was beautiful but now you must have heard Barclays. You have to write 38 different artifacts before you change a single line of code. So it's completely different from how it works when I'm messing around with Ethereum on my wonderful Mac. So that's why regulation is important. Regulation is central to financial services. What we want to be able to do is make the task of complying with some of those regulations painless with the technology with by building some of the tooling technology and best practices around the kit that's already out there, right? So privacy is absolutely central to European regulation now and so R3 have one type of solution where they're saying they will only have data being shared between the nodes that should be involved in the transaction. Other people are saying they will keep the actual transaction off the node and just update the ledger with the transaction. None of these are really exciting. To me Zcash is much, much more exciting but at the end of the day I'm not really just about it for us isn't really just about it. It depends on the engineering problem we're trying to solve. Legal uncertainty, I spent three hours today at ISDA International Swaps and Derivatives Association and one of the things that came out was smart contracts are brilliant and derivative contracts are standardized. They are relatively straightforward in terms of implementing, the basic interest rate swap is quite a simple contract. You can easily implement it in an Ethereum like platform but the challenge is the legal precedents around the context. So for example, if your counterparty has defaulted, if your Goldman and Lehman are trading, Lehman goes down and that trade involved the smart contract implemented on an Ethereum like chain and the money has already been sent then you're in a world of pain. So there is a lot of stuff that happens outside of this wonderful world of blockchain that you really need to worry about as we found out with Bitfinex and with the DAO and so on so forth. But when you're actually trying to build a solution like that, you have to read through like 10 years or 15 years of case law to figure out how the courts actually ruled in each one of those scenarios. When bad things happened, what did the courts do? Because there are hundreds of thousands of consumers to be protected and at that point, anything goes wrong, there is a dispute, it's back to the courts, then court is not law anymore. So it depends. Key management, we saw this with Bitfinex, we saw this with MtGox. I mean, it just goes on and on. So we saw, well, let me take a different example, Swift, right? Swift is a system, a messaging platform that's been running for years and years. If you talk to the Ripple guys, they will say, Swift is gonna go away because we have a better solution. There are other people like JP Morgan and RBS who have built payments like FBOCs on Ethereum and they are looking for better solutions as well. But I mean, if you can't secure the endpoints as we saw in the case of Bank of Bangladesh where they had left four computers or something on the internet and then the hackers got through those computers into Swift and used the banks identity to essentially send money to Philippines, all bets are off, right? But the reputation still sticks. So Pakistan, I've spent a fair amount of time comforting our enterprise clients that hold on, hold on, hold on. Everything, it's not the chain, it's not the protocol. It's the entire ecosystem meant to end and when you're building enterprise solutions, you really have to worry about not just the protocol, not just the code, but the end to end ecosystem and the people and the processes, right? That's where it gets really non-nerdy and not a little bit more boring, but extremely important. In fact, some of the most important things are really boring. So security, again, Ethereum, early days, but it's, I mean, I've seen tremendous growth. In fact, our engineers in Belfast lab, they built the Bank of England solution in five weeks, and then, so we have a guy called Igor who should come and speak because he's, he can do some demos and really, really cool. He's one of our most technical guys. He's literally Igor from the lab, no jokes. So he said that six months before we built that thing, we built that POC, we couldn't have done it in the time we had, right? So the maturity is coming through, but then depending on the application that we are solving for, it's really important to focus legacy stacks. This is where a lot of things are gonna go wrong in the enterprise. When we start transform integrating with legacy, at those endpoints, we had really had to be careful. That's it, thank you for listening. So our role, what we're trying to do is create a whole ecosystem of processes, checklists, tools, software to essentially automate a lot of this thinking and checking so that we can speed up the adoption of the technology in the enterprise because when we are dealing with regulators and you know, market intermediaries and lots and lots of money, we really have to be careful. That's it, thank you. Okay, good evening everyone. So yes, Richard and me, how we, well I run a dev team in Thomson Reuters, have a few guys we've been working on blockchain for a couple of years and with Ethereum for about 14 months. We're an enterprise here, we work with some private blockchains, but really it's gonna be a very different presentation from the last one. We see all the same problems, it is difficult working with blockchain when you're a big corporate and we haven't got the solutions either right now, but at the same time, we think in, well, we made a decision a few months ago, it doesn't really matter if all the problems are there, can we solve some of the smaller problems so we can try to start working with the community? Because we are starting to feel quite embarrassed because we come to these meetups all the time, we work with the Ethereum community and we seem to be taking things out of it and we just thought, well, we wanna try using what we've got to perhaps bring some simple tools back and that's why we're here today just to talk about Block1ID and what it does and we've already presented this in a hackathon a few weeks ago that we ran, we had many, many, I think we had over 150 developers applied to come and I think on the first day we had about 80 or 90 turn up and really good attendance all the way through and lots of great solutions. So we're really serious about working in the public space, I think actually we were working much more in the private space and realized that we were in sort of, not in a real world, it felt like, we were taking Ethereum branching it, doing all sorts of things to it and really not making it what it was and we couldn't keep up and we realized that we needed to work in the public space and that's what we're doing here. So, okay, so, Block1ID then, I mean, just first of all, just so you know, some some ways isn't just about Reuters, the news agency, everyone thinks it is, but we have a lot of businesses and financial risks so we have a KYC business, for instance, what we do for banks today, we do data feeds, which we do a lot of Oracle services to blockchains right now because people need them. We also have a legal business, we do a lot of tools for lawyers, software services, et cetera, and for governments as well and tax and accounting. I mean, this isn't probably the most exciting work but there's a lot of blockchain use cases in these things and so when we're looking for what things we can do, we're looking at our businesses. The other thing we're doing as well when we're looking for what we can do is looking at the strengths that Thomson Reuters brings. We are always voted in the top 10 to the most trustworthy and ethical companies in the world and we have to be right, we're reporting the news so we need to be it unbiased and we feel that's a big strength to bring to this community. I know we talk about trust in different ways and we talk about consensus but when we start to bridge these worlds, trusted companies I think can really help especially on the edges of blockchains. So we think that we can really bring our brand to that and really help and we also have great scale. So we're talking to lots of banks, lots of governments, lots of different forums so we can get people into those meetings and see how we can start to bridge these worlds. And again, we don't know the answers, we're just trying to start to bridge these worlds and see where we go and the solution today is exactly that but we're just trying to bridge some worlds that we can get going. So we started with a problem and this was a simple problem for us which was if we're gonna try and use a public blockchain and what problems, what problem are we gonna hit and what can be solved? So the first thing that we came across and these were really, really simple problems was we really are used to knowing the users that we deal with. We don't just give out content, we don't just give out services to people we don't know and that's just a reality of our business. If we give out content, often it's not our content, it's licensed inbound to us so we have to provide a license going out. So we have to know what that person is so we can get them to sign our license or at least know they have a license to have that content. It's a very simple problem but it requires some diligence from us. We can't do that easily on a public blockchain today. Sometimes, as I said, we need to get the user to accept terms, very simple thing, but again, it's accepted around the world in web, it's just not in blockchain and we also then need to entitle based on that. In the blockchain world, we know we entitle on addresses, those addresses are opaque and you don't know who they are and especially when you're on the blockchain side, when you're enforcing contracts or interfaces to contracts, you really can't, it's not very easy to reach out and work out as this user with somebody I know. You might know an address but you may not know if they're a user or the user that signed up. We've also seen problems with key management and we thought, well, let's find a simple solution to that. Certainly don't have the best solution necessarily but we have a pragmatic one and we also wanted to preserve this user ID of obfuscation. We don't want to put users information all over the blockchain. That's not to say we won't put private information on a blockchain but obviously encrypted but we're certainly going to try and respect users. Now, all of these things are relevant to public. We also look at these in private and some of them aren't as important but to be honest, we're not really applying block one ID in the private space. It's very much in the public space and to provide a key building but to see how it can be adopted. So, what is it doing? It's very simple really and this might be really against some of the principles but what we wanted to do was create some sort of controlled spaces on the public blockchain and by control what I mean is that we can decide if our service is offered to users or not. And we felt that this was a pragmatic solution because a lot of what we've been doing is looking at private chains and we're thinking well actually, this really doesn't seem to be going with the principle of block chains and especially when you look at the private space a lot of them aren't really block chains at all. They just basically remove the whole trust element and go for a truth concept and we really felt that that wasn't what we wanted to go for. So, we thought well let's see if we can create a controlled space on the public chain and see if we can function that. And that's what this is trying to do. So, we started with a very simple interface which has been there for many years and that is when application owners or developers or service providers want to talk to their users and want to manage their users in some way. Now, we didn't want to go down an app store sort of approach where you enforce these relationships and try to control them. But what we thought is that we could add some value in this space and use Thompsons Royters brand and trust to try to help developers be able to understand whether users have accepted terms or whether the users are able to use their service. And by users I mean people, I don't mean addresses. So, what did we do? We built two services. Well, I think we built three services really but two, the delegated identity service. So, we wanted an identity service which was really compatible with the rest of the world and the obvious solution to that was to use OAuth. It's just used everywhere in all of our web systems. What we're also finding is when we add blockchain into these systems, even if it's public or private, it's not the only piece of functionality. We often have a lot of web services alongside. And so we wanted a simple system that would just combine these things together. And this is how we know our users today we use OAuth. So we thought, okay, let's use that and let's combine it with a wallet. So what we do is we manage private keys against user IDs, a hosted wallet. Now, we do not see the keys there completely. If all we do, think of us like a dropbox for encrypted blobs. We don't ever see or decrypt those or we're not able to decrypt those blobs. So the side, everything is just provided to the clients and everything is decrypted in the client. So, and that's done through the user and their passwords. We never pass those passwords around. So it's not about us acting on behalf of the user on the blockchain. Indeed, we can't. It's just about us managing the storage, if you like, in an encrypted form. But we felt that we had to build a wallet to make this work. It's not to say that we have to own the wallet in the future, but we certainly thought to get this to work initially. We needed to build into our OAuth system a basic wallet. On top of that, what we felt was really interesting was to build an entitlement or authorization service based on this user profile. So the idea being that when you're blockchain side, you can check whether a user has signed up to your application or your service or your DAF. And so what we do is every time a DAF is registered by any developer, we write a contract onto the public chain and we manage that contract in terms of addresses that are allowed or entitled to use that service. So think of it like a quite a simple authorization model, but based on users rather than, obviously it's implemented by our addresses, but it's opaque as to which user it is on the blockchain. Well, you can see all the addresses that are allowed. And we manage that contract on behalf of the developers. So it's a pretty simple system, really. A delegated identity system, along with an entitlement service based on that identity, and it's glued together with the wallet because it's a nice interface to blockchain. Just a very simple architecture diagram. We've got our two services. We have our developer console, where developers obviously get to log in and register the DAFs. And we have a wallet manager, which is our admin page. So you can understand your wallet if that's for any user. On top of that, then obviously we have the blockchain with the entitlement contract that we're writing. And then that obviously is associated with the actual DAF contract. And they use that to understand which users can access them. And of course, they're UI extension. Very complicated. Just in terms of where we're going with this, you'll see now we're going to do a demo in a minute. I want to get away from the slides. We're going to, at the moment, we're using pop-ups for the wallet. It's all web-based, the interface. And then we're going to move to also have a web extension, sorry, a Chrome extension, so that we can make the UI those quicker. We're thinking about APIs that we can add. And more interestingly, I think these are really APIs for developers to exploit more information about the users that are using their applications. And so they can understand which users are using them, how many, et cetera. So some user-level analytics, as well as basic users information. And also I think we're thinking about extending the APIs so that we can integrate other wallets into the system in the future and we focus more on the entitlement. And then I think we're on to the demo. So we're going to show you the full developer sign-up and how they go from signing up their DAP to actually constructing the contracts and then building a web app that integrates our JavaScript UI for the wallet as well. And hopefully that works. We'll see how the Wi-Fi is. Hi guys, my name is Mihai. I prayed really well to the demo gods today. So let's see if we can build a simple DAP and hook it up to the ProPoint ID service to our clients. All right, so I have this Ethereum node, a Go Ethereum node that is connected to our private Ethereum network. I chose that because of speed. We already launched on the public Ethereum test network but that is a bit slow right now. So in the interest of doing this quickly, I chose this one. All right, so let's see if it's really connected. All right, so we have peers. That's good. All right, this is our developer portal. So we log in and we have a choice of a few auth providers. I will choose Google for this. This is, I zoomed into this so it's a bit stretched. But it's a simple portal. It's register our DAP, register. So we're trying to build a color survey, the most complicated DAP ever. But choose your favorite color. I'm gonna choose the network to be used as Edgeware. I don't know if you're seeing this on the screen. Just play there. So this is the target blockchain where our entitlement contract will be deployed from our backends. Let's put in a unique identifier here. This is how our backend identifies our DAP. And this will be baked into our registry in order to find the entitlement contract that needs to be deployed. Explain what this is. This is where your DAP will be called back by our identity service to deliver JWT. So the DAP knows the identity of the user. All right, let's grab a very nice logo. And this is the license agreement that Richard was mentioning. Our users need to accept it. Lots of text there. All right, and I hit register now. Our backends go and do their job to deploy this on the Ethereum network. But in the meantime, we already have a template of a contract here that we can use to deploy our own. All right, I'm gonna quickly explain what's here. So we have our entitlement registry which is a DNS basically, which is hard coded at this address. And our backend will bake into this entitlement registry and the address of our code here are colors, our DAP. So we're taking that and we wrote a modifier which we will basically use to know if the client that is currently sending the transaction is open or not, there's all that. I'll quickly copy from the documentation. So there's a full documentation of what I'm building today. So you can reproduce it at home if you want. Grab this, put it right here. So basically it's just a function to vote for your favorite color, which is red or blue. And we're applying this modifier here to guard our function basically. All right, that's about it. So we're gonna quickly grab this to deploy on our node. Somebody with some blocks. Oh, actually I'll back in with some blocks. All right, all right, this is our contract. And now this is the web app that will be used to interact with the blockchain. We need to include the web tree and a block that comes from us which will govern the interaction with the identity service. We need to put the contract address here. And the other important bit that is needed here is from the colors, which is the ID of all that. Other things are the current blockchain network that we want to plug it. And these days are our standards, which says the services that the deaf needs to interact with will be applied away from here. Yeah, so that's about it. This will be hosted locally. I have a web service here, which I'm gonna restart, and it's right here, login. We will now login as this other guy, authorize. All right, and now this workflow is given by the way the blob that I showed you here that comes from us. It works the user to create a wallet before interacting with the app in the first place. We're going, this is our wallet terms and conditions. As you can see, we're using an HD wallet, so I'm gonna pretend to save those, right? This is the licensed agreement that the user needs to accept, all right? Now our backend is going and invoking the address into the entitlement contract, and now the contract of the DAP knows that this user has registered and is able to use the DAP. Let's see if it actually works. These buttons are basically, so we're pulling from the blockchain once every second, the values red and blue to be shown there, and this is the function to send the transaction, which is taking the current account, which is right here. Create secure signer is starting a popup, and then inside that popup, we will send a transaction. You'll see that in a moment. But before showing you that, let's go to the actual wallet. So this is a page that the user will use to manage his wallet, explain a few things. So inside our wallet, we get different namespaces, we call them. As you can see here, we are on the Edgeware network with this namespace and the same on this one. This default namespace used to hold your ether, you can get as many of these accounts as you want other accounts right here. And for each DAP, we're creating a separate namespace, so each addresses that are designed for the DAP will be separated from other DAPs and from your personal ether account. We also have a magic ether button here because we're in a network where ether doesn't cost money, so we can get ether for this as well. You can backup your wallet, change your password, et cetera. Yeah, so this is our wallet management page. Because we already have some ether, so we have money to pay for this transaction, we ask for it, let's see if we can actually use this thing. All right, so important fact here is that this popup is on a tonsil Reuters domain and not on a DAP developer domain. So that means the DAP developer and the DAP doesn't ever have access to the private keys. They only see the public key and then when they send us the role transaction and we sign the transaction and we deliver it to the blockchain. And we only deliver the fashionable transaction back to the DAP, all right? Here we, you can see more details. This is the unique ID of the DAP. You can see the account we're sending from, account, the smart contract address we're sending to and the actual role transaction if somebody is interested for the most technically minded. But for the day-to-day users, the information is very brief. You can see your gas cost here and you need a password. You can see we need to put the password quite so many times. So we're trying to get rid of that with the browser extension, we'll be doing that. All right, so let's confirm our transaction. And this is to demonstrate that the DAP got the transaction hash and we actually built it. So that's about it. We're at my own, this is Jacob and we're from Alice, we're a blockchain philanthropy platform. But before I explain exactly how that works, can I just ask everyone, is the last time that you didn't donate charity? So you know what I mean by didn't donate, right? The other day I was at Waterloo Station, I saw these guys walked straight past them, didn't talk to them, didn't donate anything. And well, actually I felt bad about taking their picture so I did stop and then they convinced me to give them something anyway. But you know what I mean, every day there are so many opportunities to give to charity. People doing fundraising appeals in the streets, there are TV appeals, charity shops, and yet we routinely just pass on the opportunities to give. And the question really is why that is. And if you're like most people, it's a question of trust. It's a bit like feeling like Mowgli in the Jungle Book and charities are just asking you to trust them and give them your cash exactly. And this year actually the charity commission recorded the lowest ever level of public trust in charities ever recorded. And when they looked and they dug into why that trust deficit exists, they found that it's very intuitive actually. It's down to the fact that people just have a perception that there's a lack of transparency and a lack of accountability into how the charities use your money. And so it's against that background that we decided to use blockchain for Alice. And the good thing is that charities are starting to look at blockchain technology as a way to enhance trust and transparency. So this quote comes from a report that was put out just earlier this year by a charity think tank, a charity aid foundation. And the fundamental, I mean, I'm not gonna, generally at this point, I do the whole what is blockchain thing, but I think you guys all know. But it is really down to them trying to figure out how they can really restore public trust in the sector. And certainly it's why we got into this space as well. So Alice's mission is to make it really easy for charities to be as transparent and accountable as possible. So the 160,000 charities in the UK can raise more funds for all the amazing work that they're doing, helping homeless people or helping people deal with their mental health issues and the other sort of loads of causes that they're involved in. And there are different ways that we're tackling this, but the very first one is basically a radically transparent way to donate to charity that we've developed. We're gonna run our first pilots in January next year with two homeless charities. And what they're gonna do is they're gonna put out their appeals to the public to donate to their causes. Except they're gonna give the public a success guarantee, which means that when people donate, they will get their money back if the charities don't manage to deliver on the outcomes and the impact that they promise. And that's gonna be the Alice promise, if you like. So the way it works really quickly is obviously there's a smart contract at the center of all of that. We took the decision that we were going to collect money in fiat because people are used to donating to charity that way. And so we take that, we collateralize it. Jacob's is going to explain a little bit better how that works in a second. Collateralize and tokenize it. And then the charities can then just go off and run their programs. And they will basically have to deliver on the outcomes. So if the homeless charity is saying that they are gonna help rough sleepers find sustainable accommodation, the proof of that is actually the fact that they signed the tenancy agreement. And we're not gonna ask them to self report because that would kind of defeat the purpose. So they actually need an external independent validator to sign off on the fact that the proof has been submitted and it's valid. And the every single piece of, every transaction, every validation, every donation is registered on the blockchain. And once that that proof has been submitted and validated, the charities can then redeem through these tokens, the fiat donations or whatever corresponds to those outcomes. And then it hits their bank account. So they get the money and donors have absolute transparency over how that will impact that money made, basically. So now I'm just gonna pass it over to Jacob to talk about the Ethereum integration. So for a user perspective, our sites look like a typical donating site, but behind the scene we process all of the integration with Ethereum platforms. Yet we still believe in the Ethereum idea of decentralization so whenever the donors are made sure enough to process all of the integration with Ethereum on their own, we get the ability to export the account and do all of the transactions manually. Another challenge is with accepting donation in Ethereum currency. We do not want to do it because we don't want to put extra burden to our donors to exchange the grants they use every day to Ether. And we are aware that Ether is still quite a volatile currency. So we don't want to gamble with donors' money. That's why we accept donation in a fiat currency and then we call it that ties them to our Ethereum tokens. We pack it one-to-one to a bounce and leak value and we are working together with Tronmolex, a company that gave the presentation last month. The first problem that we face was connected to the nature of donation. They are not evenly distributed in time. Usually around the Christmas time when you are with your family and you have a warm feeling and you want to share the joy with the less fortunate one, you want to make donations. So for us, actually it means problem because there is a very high peak in the volume of donation that we need to handle in a very short period of time. That's why we get the built up the mechanism of asynchronously processing all of the transactions of trusting them and for creating a steady stream of transactions to integrate with Ethereum. Yeah, we also want to have a peaceful Christmas time so we don't want to be down on our lounge today. So that's, we got this extra layer of protection between integration with Ethereum. If you've got more questions about the technology behind us, I'm available after the presentation. So these are our partners to date. So as Jake was saying, we work with TraminX on the fiat collateralization that was made public just a few days ago. They're part of the FCA regulatory sandbox. And the two homeless charities that we're planning our first pilots with are there as well. We got some initial grant funding from the Nominet Trust as well. So they're specialized in sort of social tech. If you're doing social tech, it's really worth applying for their grant. They're really great partners and we're also part of the social tech accelerator that's backed by the cabinet office and by Nesta called Bethnal Green Ventures. And all of that has been really helpful in helping us get everything off the ground. So that's us. We're Alice. We're helping bring transparency to the social sector using blockchain. We're looking for partners. We're looking for charities. We're looking for all kinds of people. If you're interested, please come talk to us. And in the meantime, if you have any questions, go ahead.