 So, hello everyone and thanks a lot for joining this session. My name is Chila Jigri, I'm VP of Strategy at BTP and John Stonewatt is the CEO of the company and we will be talking about provenance. So I'm sure you are familiar with the term, often it is still associated with the art world. When you think about the applicability of being able to record provenance information and share that, it can be applied and provide value in so many areas, right, beyond the art world so across plenty of industries. And just simply put, provenance captures the origin and the life journey of any asset, this obviously includes the ownership history, but it can be any physical or digital asset. So why it matters, I think first and foremost, it provides transparency and trust and I think we can all agree that we fall short of those things in many areas of life and business. And for example, you can use this information to fight fraud, contaminations, counterfeiting and actually counterfeiting is a huge problem. I think in 2019, I read somewhere that global market for fake goods was worth about, I know it was like I think like 500 billion dollars which is basically bigger than Ireland's economy and I think the pandemic aggravated this a bit so this is an area where we believe that a provenance solution can help. Also businesses can use this to demonstrate that their product is environmentally friendly and that it has been produced in a socially and ethically responsible way and when you think about supply chains, you can make all these transparency can make a supply chain more resilient. So that's why we are a true believer in provenance. We think it is a force for good and that's why we launched a product called Chronicle. But actually, again, simply put, what we are trying to do is just make it easy for organizations to record and query immutable provenance information and we do that backing all this information with a distributed ledger and we can apply that to any asset in any domain and across multiple parties and industries. So just a few words about Chronicle, again, it's blockchain backed, it's domain agnostic, it's a product that you can use to record and query provenance information, it is built on the worldwide web's provo specification. We also use other open source standards and technologies. I would highlight GraphQL which is a project that is part of the Linux Foundation. So again, we can record information about any physical or digital asset and for now the backing ledger is Hyperledger Sawtooth, it's a permissioned blockchain and Chronicle is easily configurable, it's domain agnostic but you can use it to configure so you are able to capture information in specific domains that are important for your business. So you want to take this over? Yes, and just to reinforce the point, we're here as members of the Linux Foundation, we are members of FINOS and also the LF Energy Initiative but within the sort of horizontal Linux Foundation initiatives, we're working closely with the Hyperledger Foundation, CMCF and of course GraphQL. In terms of the Prov-O, the provenance ontology, this is a very abstract but very powerful ontology provided by W3C and it talks about concepts like agents, entities and activities. So entities are the things you want to reason about. Agents are interacting with those entities and the activities describe the kind of interaction. Now that's incredibly abstract so while we support that, what we've created as part of our Chronicle product is a way of compiling a domain specific definition of an ontology so that as Chilla will show you in a minute or two, we can reason about in the context of this conversation about corporate actions but equally we could be reasoning about the world of art or the world of critical infrastructure but the idea is to be able to take a YAML file that defines the entities, the agents and the activities in a language which makes sense in your domain and then of course that's then mapped onto the underlying Prov-O concepts. The reason we back all this onto a DLT is so that this information is immutable. It doesn't mean it can't be changed but it means that any change is explicitly recorded. If you're capturing as we do the facts of the matter, you want to know what entities are involved, what agents and what activities, you want that stored immutably so that nobody can come in and then argue after the fact. Now when we say record, it's very important to understand that Chronicle records things but what actually it relies on is systems to actually essentially mark when certain activities occur and who's involved with that. So we're not doing anything, we're kind of lazy when it comes to that, but what we are doing is capturing the facts of the matter and that therefore then allows you to not just store those facts using GraphQL but then run queries. So with that slightly long-winded explanation, I'll pass back to Chila to talk you through a domain around corporate actions. Yes, so we modeled specific domain for this event which is corporate actions and more specifically we are recording some aspects of a stock split, I'm sure. You know what a stock split is? It's an event focused on finance but just in case, the stock split increases the number of shares in a company and for example, if you think about a two-for-one split that means that an investor will double the number of the shares that he or she owns but the value of each share after that event will be halved as well. So what we will model is essentially it's a simplified model. What we will model is three activities. So basically an individual investor, a person becomes a shareholder in a company so acquires some shares then the company will announce a two-for-one stock split and after that a transfer agent which acts on behalf of a company will update the shareholding of that individual investor. So in this using the Provo language, the domain is corporate actions. The entities would be the actual, the shareholding, the announcement. That's the type of assets that is being created. The agents would be the company, the shareholder itself as well as the transfer agent and the activities would be acquiring the shares, announcing and implementing a stock split. So this is the first activity which Duncan will be demonstrating. So this illustrates, as you can see, there's a company, there's a person, they have different roles. The company's role is the issuer, the person is going to be the shareholder and both these agents are associated with an activity which is the acquisition of shares and we are going to, and this activity will generate a shareholding entity. So let's demonstrate this. Okay, so if I now switch to the application, oops, sorry. So what we've got running here, and by the way, this is open source so you can go and look at these chronicle examples. So the one that we're actually playing with today is a corporate actions example. So if I just drill down on that briefly, this is the domain YAML which actually describes the kinds of entities, agents and activities that we're talking about here. And so it's my job to now capture an instance of a shareholder, acquiring a shareholding. So once you have this ontology, and by the way, in general, I would not recommend using the GraphQL playground to do this. This will be being done programmatically more likely than not. But essentially, the first thing that you do is, and hopefully, can you see that? Is that visible to people? Just, okay, sorry. Let me see if I can, hopefully that's a little bit clearer. So the first thing we're going to do is we're going to tell Chronicle that there are three agents. There's a company called FTX Corp located in the Bahamas. There's Ninja Chiller located, yes, located in Barcelona. And then there's a transfer agent called Bank, which is a bank. See, we're really imaginative folks. We sort of run out of ideas very quickly. So if I run this, what this is doing, bear in mind that stack is, I'm now speaking GraphQL and saying to Chronicle, please record the existence of these agents. Okay, so far so good. So now we want to define a shareholding acquisition. So that's that first diagram that Chiller described. So what I'm actually doing is, if I go to the right, I'm actually now creating an instance of the shareholding acquired. And I'm going to fill out all of these relationships. So first thing you do is you define the shareholding acquired activity. You're saying that it's associated with two entities. Sorry, two agents, FTX Corp, which is in the role of the issuer, a very reliable firm, of course, and then Ninja Chiller, who thinks it's a brilliant, brilliant deal, deal of this entry. So we'll set this up. Now that we've defined this activity, we have to do something else, which we actually have to say it's now going to have an instantaneously. So you can have activities in Prop-O that last over an amount of time. So for example, in manufacturing, you might begin a manufacturing process, then manufacture a batch of items, and then finish that process. But here it's an instantaneous activity of acquiring a shareholding. So Ninja Chiller is going to acquire 100 top quality shares with a nominal value of $1 from FTX. So if we do that, so what we've done is we've essentially, we've taken what is obviously an abstract model, and now within Chronicle we can actually sort of model each of these different scenarios. So now back to you to look at the next one, I guess. Thank you. So now I have become a shareholder in FTX. I don't know whether that's a good idea or not, but that's what happened. And now FTX is going to announce a stock split, right? So in this scenario, there's only one agent. It's the company's FTX Corp in our example, and it's going to announce this 241 stock split. And as you can see, the announcement itself, it's an entity, and it has some attributes that we are going to also show through Chronicle. It has a ratio, which is 241. It has a record date, a payday, and an XDA and so on. So this entity was generated by that split-announce activity, and obviously in this case, it's only the company who's associated with it. So thank you. So defining the split announcement, you'll see a pattern emerging here very quickly in that we're defining an activity we're saying who is associated with. So again, it's FTX Corp in this instance, and then we'll record the actual split announcement, which is saying that there will be a 241. The record date is today, the payday is tomorrow, and the XDA is the day after tomorrow. I don't know who came up with this, but anyway, so we do all that. So now what have we done? So to recap, Ninja Chiller has a shareholding. We've recorded that fact. We've also recorded the fact that there has been a share stock split announcement. And so the final thing is to then process that. And so here, it's the same idea. We now have the company involved. This is still FTX Corp. We now have, though, in the role of a registrar, the transfer agent, the shareholding, and this is important, will be revised as a result of this. So where you see there was a revision of what that's saying is essentially, you've now mutated a shareholding from one version to the next version. So this is how you build up over time, the complete timeline or history of this kind of activity. So in the interest of time, and I've lost track of time, but I'm sure it's getting perilously close to you guys getting a drink of some description. We are going to go through exactly the same process as before. It's a little more complex, the number of participants involved, but we're defining the shareholding updated activity. We're saying that there is a bank involved in the role of registrar. FTX is acting on behalf of FTX Corp, again, as the registrar. And here we're saying that it's also using, as part of this activity, the existing shareholding and the announcement. So this is building up that picture again of the state of the world. So if I do that, I then finally record the actual update itself. And so this is where we're saying the revised shareholding is a revision of the original shareholding, and now we have, that should be 200. I'm just going to 200, rather than two, at a nominal or power value of 50 cents. So if we do that, what we've now done is we can now query this, and this I promise you is the last bit of graph QL Playground. And if we run this query, then what we can see is the timeline of activity. So you can see the split announced. You can see the shareholding acquired, and you can see, where is it? The shareholding updated. So that is basically the end of the demonstration. So this has been published in the schedule, so you can grab these slides if you want. Most importantly, though, I would commend you to go and actually look at the examples, and there's a full read me telling you how you can actually build these examples out, and once you've done that, you can run an in-memory version of Chronicle, so you're not actually having to roll out a distributed ledger on a Kubernetes cluster somewhere in the cloud. You can actually just experiment and iterate on and create your own domain. So the idea here is to create these examples to seed the idea of using Chronicle to actually capture provenance across multiple different domains, so art world, critical infrastructure, and so on and so forth. And I will have to put in a full request because the read me is out of date. So this is the joys of being in the open, OK? So it's warts and all. But thanks again for your time. If you've got any questions, of course, we're here to answer. Otherwise, I think it's time for a booze crawl. Thank you. Oh, sorry. Sorry. You can revise things. What you can't do is delete things. So immutability is not the same as saying something is you're fixed for all time. So you make a mistake. It cannot be amended. You can make an amendment. But what you've done is you've recorded both the original and any update. So that's a feature of really this approach, is that you can't just sweep things under the carpet, pretend something didn't happen, or change something after the fact. So it's one of the... Sorry? No, you've recorded a change, but you have the full audit trail of the original and the updates. You can actually see that... So in other words, it's completely transparent. So we're not saying you have to get it right first time and it got forbid you don't. What we're saying is it's fully transparent. So any mutation... I can create a mutation, but the previous mutation is still there. And when you run the timeline or run more sophisticated queries, you will actually see each step of the way. So it's important to distinguish between the two. So immutability means it's tamper proof. You can't change it on the fly. And that's thanks to the consensus algorithm that's enforcing that across the DLT. Good question, though. Any more questions? If not, thanks again and enjoy the booze crawl. And thanks.