 And then I'm going to, Chris, make you an organizer. Okay. So you now can kind of drive and take over. I will be here for the first 60 minutes of the call. I do, however, have another meeting at 11 that I'll need to leave for. Brian is on. Okay. I think we can get started. So on the agenda today, as we discussed, one of the key items that I want to get through is to go through and have David will lead us in a review of the white paper. That's the most important thing that we can do today. I think there's a couple of items in the action item review that we can briefly cover before we dive into that. And then if we, you know, we'll use at least an hour. And again, we'll see how far we are into it, Dave. And if we have to sort the workgroup updates, we can get those e-mail. So the first item up is the HackFest preparation. Both the Hackathon, which is over the weekend of October 1st and 2nd, hosted by AB&MRO, IBM, and the Lakes Foundation and a few others. And that registration page is up. And Greg, if you wouldn't mind, I don't have the link there. If you could paste that into the chat, that would be helpful. And then the other is for the HackFest itself. So this is our face-to-face on October 3rd and 4th, Monday and Tuesday, following SIBOS. There's a registration page up. And please post that link in there as well. I think we have time. A couple of times. And then there's an agenda draft that we can be noodling on over the course of the next few weeks as to what we want to handle in the agenda. Any questions on the Hackathon and HackFest? All right. The next was my action to pull together some thoughts on the Hyperledger release text on me, and I haven't done that. So I owe that, but I've been focusing on a few other things in traveling. So I'll try and get that done today after the call. And Brian, you've joined. So we have the Wiki and the new communication tools that have been out there to allow people an opportunity to poke around and get their thoughts and feedback. So Brian, do you want to first talk about the Wiki and plans for migration of the GitHub Wiki to the... Sure. Sure, this is Brian. I'd love to get other feedback from people on the TFC. I feel like we are behind on getting people to look at it. There's still been pretty minimal participation on it. And I'm not sure exactly what's best to do now. This is something that I think is pretty important for us to keep unified with the rest of the project. So, you know, I can wait. Can I make one more call to the TFC to try to spend and put some time this week? I see that Greg Haskins has touched it. I see that Nicholas has touched it and Mark. So we've had... And Jeremy, of course. We've had four other people, and Jeremy gave some substantive comments on it. But I'd be really happy if we could have some more TFC involved and touch on this before we decide to make the point. So that's kind of my take. And then on the... Well, let me stop there before going on. What are the people on the TFC? So I played with... I didn't create any pages, but I simulated that activity. And I poked around and saw it was there. I have no issues with it. You know, it supports markdown. We've had the discussion about whether or not we can transfer the stuff pretty much verbatim. I get the sense that that shouldn't be a problem. So I'm okay. But I agree I think we have to get others to play around. This is Jeremy. We can't transfer it verbatim. That was the substance of my investment. You think you could if you wrap it with the tag, right? Jeremy, did you try wrapping it with the markdown tag? No, I tried pasting it directly in and then migrating the markdown from GitHub markdown to the markdown that it supports. Is there a way to completely escape out the markdown? I think I responded to your note. Maybe it was just on Slack. But let me go back and look at this. But there's a plug-in for the wiki we're using, for doggy wiki, that we're using that supports. It claims being able to paste in standard markdown. I don't know how different GitHub standard markdown is from others, but let's pretend for a second there's a standard. And if you use a tag, and I'm pretty sure it's simply marked down in brackets and then flash marked down at the end, then it will parse everything in there as clean markdown. Let's see if I can find anything else about this. That needs to be tested. But that was the last status I had. I hadn't seen that. If you can point me to that, that would be great. I can give it a try. I think what it was, I think I sent the link for this around in the chat window on the last key of the call. I will respond to this more directly and get it out. GitHub markdown is not the same as some of the other markdowns. I don't know that there's a quote unquote standard that Brian said. How many should choose from? Yeah, right. Okay, well, let's give it at least one more week. Yeah, so everybody has a homework assignment, create a page using, you know, or copy a page of yours and, you know, get a sense of the experience and if we're good, then we're good. And Jeremy would be great if you'd be willing to sort of rerun that experiment. I thought, and again, I recall the conversation that said that there's a plug-in and that you can surround the GitHub markdown with a markdown tag and it should support. Just to wrap this up so we can get on to the white paper with at least one more week, I will send up what I can find. And if people on TSC could really just take, you know, the 20 minutes to give that a try, you know, I think we'll be significantly further ahead. Thanks, Brian. Anybody with a Linux Foundation ID can go create draft pages right now or it's only TSC. So anybody with, anybody with a Linux Foundation ID. Okay, great. We'll ask a couple other people to take a look too. Okay, cool. Thanks, Tien. So what about... Oh, and so I believe Todd sent around information about Discord. Yep. And that is also something that is something that I haven't pushed to me further and I don't know if anyone else here has poked around in it. So let's do that kind of two slides for a second. Yeah, I mean, it's a typical form, capability. I haven't, you know, explored the complete edges, but I put up a post and Rai and I have been going back and forth and replying to each other and so forth. The question I had is, can you access it further from the, in other words, would it be the same as having public archives with mailing lists? So I would love to use it to replace most, if not all, of what we use mailmen for and I believe it's designed to support participation by email, by directionally, so that you not only get new notifications when they are posted in the categories that you track, but that you also can reply through your mail client and reply in a very natural way and have that reply woven back into the thread. That would be my number one criteria, frankly, because we don't need just yet another form tool. We need something that improves substantially upon mailman. And that could actually be an upgrade to mailman because there's a mailman three out there which apparently, like all upgrade fixes every problem, no demand. But this is something that other communities use very heavily in the open source world. This is something that I think just visually has a much better pop. And the other key criteria for me is search engine familiarity. If your message is in here and get indexed and turn up in responses, that's something we'll have to figure out. All right, so let's have everybody sort of get into discourse and at least just get familiar with it and let's see if we can make a decision next week. So the other thing that I wanted to mention before we get into the White Paper Review with Dave and that is that we proposed to cancel the 29th, I believe it was, because many of us will be at Sybos and or traveling up to Amsterdam. And so that will be an awkward time to try and have a TSC meeting. So we're going to cancel the 29th and then I've also proposed that we, because for the most part except for this call and I think it was last week when we ran over because we had really good discussion around some of the proposals that we cut the time of the meeting back to an hour. Because I think if we look at the past history, we've been ending roughly at an hour on a consistent basis pretty much since the spring and with a few exceptions obviously but I think we should probably just cut it back to an hour and then that way everybody has another half an hour back in their lives. And if you find that that isn't working out and we need to go back to 90 minutes, we can think about that or we can maybe do it periodically. We have a longer meeting to get into more substantive discussions but that's what I'm proposing and I'll entertain any comments or thoughts on dialing it back to an hour. I suspect that I'm not going to get a whole lot of pushback and I'm hearing no pushback so either everybody's on mute or there's no concerns with that. So that's what we're going to do. So starting next week we'll go to an hour and Todd will adjust the calendar and we'll press forward. It'll start at the same time. So we'll start at 10, go to 11, Eastern, 7 and the reason for that is I think Richard, you routinely seem to have a commitment at the top of the hour and so we're going to try and help you with that and keep you for the full time. Plus we do have people in far-flung time zones and I think the earlier time is better. I understand that for the Californians it's a little bit awkward but I'm afraid that's the only other thing would be to sort of have a rotating time but that gets complicated and confused when people offer those meetings. I've done that and it ends up being more trouble than it's worth. As Californians have it easy in so many other ways, I think we're happy to take one for the team. So you can have your cheerio as well. So let's get right into it. Dave, I'm going to turn over the presentation to you. That's okay. That sounds good. Probably pull up a copy of the white paper and then we'll just go through section by section. Does that make sense? Yeah. If you give me the ability I could share my screen. Way at the bottom. There you go. Okay, let's see. My screen. Let's see. I think I want to change my monitor if I can. No, I don't want to be sharing my monitor. My calendar. Screen. Share my... Okay, I think we got it there. Can everyone see the Hyperledger homepage? Can people see the Hyperledger homepage on my browser right now? Oh, David, we see CIB emerging technology. You see a symphony. You see a symphony. Emerging technology. What? A symphony chat window. Yeah. Probably. Okay. Sorry, one second. I'll try this one more time. I have three monitors. Maybe this is it. How about now? Yes. Okay, there you go. All right. Very good. All right, yes. Thanks, everyone. We'll be walking through our white paper this morning. Of course, yesterday we had a walk-through as well and we had very good attendance and good feedback. We really appreciate that. Getting feedback from the community is really important and we really appreciate everyone's involvement. Since yesterday also, I see that we've got some more feedback from Jeremy. I see that you had submitted some feedback through the channel and Chris, I had a chance to look through some of your feedback that you had submitted and that really looks some very valuable and good suggestions there. Not only just making it a little bit more readable, but some important content-related comments. Of course, we haven't been able to incorporate that in there, but just quickly, I wanted to just make sure everyone understood how where the paper is and how to the feedback channel we have. Of course, this is perfectly wonderful as well. In fact, it's much richer. One of the things, if we go through our Hyperledger site now, which is really nice by the way, just yesterday I didn't realize it was updated so nicely, but of course, if we still are pointing to the older Wiki, we're going to have to change this, but when we come into the Wiki, we have the White Paper Working Group section here and this is where we've been creating the link for the most recent version. Right now, what we're going to be reviewing is what we're calling draft2.0. Our goal is to remove the draft labeling in time for CyBus and so this review is important so that everyone gets a chance to look at it and give us their feedback so we can incorporate that into our CyBus version. There's a link here that will allow you to fill out the form and then what we typically do on our weekly meetings is we'll go through that feedback and we'll discuss it and we try to get back to everyone though yesterday one of the our community members pointed out that we failed to respond but that was really an oversight. We really mean to do that. Just a reminder, here's our members. Everyone's been very active and appreciate all that. The goal here is we're going to try to get through all 10 sections of the paper in under an hour and we were able to do that yesterday. I'm just going to keep this up here. Morale Krishna he's going to kick things off with a review of the abstract and background and then Hart Montgomery it's going to cover a couple of sections in the paper via a new blockchain, our vision stuff on, following by stuff on and then Ram is going to who leads our architecture working group he'll be covering the architecture section back to Ram and then all we're acting up. We've allotted this amount of time for each section if it looks like we're running over I might jump in but my job mostly is just to keep track of notes and keep the thing flying. If anyone has any questions about the format please raise them now otherwise we'll go ahead and jump right in. Just one thing since we do have Greg on and I don't think everybody knows who Greg is Greg is our marketing director for the Hyperledger project and the website is really cool I'm going to give Kudos to Greg and his team for the complete overhaul because it's gone from looks like somebody just threw it up in an afternoon something that's really I think quite impressive and so I just want to give Kudos to Greg and the team. Thank you. Great job. Thank you all very much. I'm excited to be part of this group and the website will be a good resource for all of us and a nice website will be an even better resource. My pleasure. Great. We'll just pass it over to Morelle. Rather than just reading through the whole thing the approach we're taking with this is much like a code review we ask ourselves what is the intent of the particular what is the intended function of the section and is it easily understood and so basically the format will explain the intended function of each section maybe highlight a few key passages and then open it up for discussion so that's sort of the layout and with that I'll pass it over to Morelle. Sure. Thank you David. Like David said the white paper is a working of all the workgroup members and we'll go through for each of the sections giving a brief synopsis. So the first section is the abstract and we all know that Hyperledger is a consortium of many companies and industries and the abstract sort of highlights or sticks to that co-penance this platform that we are developing is for multiple industries across the board and so the white paper collects all the different industry use cases and then based on the industry use cases we derive principles or any functional or non-functional requirements are based of those industry use cases so that's what the abstract talks about it being a cross industry and industry use case driven which drives the principles and the requirements functional and non-functional so any comments, questions, feedback on the abstract? Yeah when Brian first joined I liked the verbiage that he brought in with Hyperledger family of blockchain technologies and that might be a little bit more specific than referring to it as a platform here Okay family of blockchain technologies Yeah and one thing I've wrestled with is design as I've read this and obviously we're evolving as a project from fabric strictly as the full project to one where there's a series of projects that potentially represent different approaches to your core distributed ledger and my contract platform and so one thing we may want to wrestle with is to what degree is this a fabric white faces or is this a called arms for all the project out to the Hyperledger we certainly will be encouraging the project at Hyperledger to be working with each other, to be building on top of each other to be merging their efforts where appropriate either merging or usefully differentiating and then there's been this phrase that I've been using in the same way that Darwin cinches on a Galapagos usefully differentiated over time you know I'd be you know that's a path to take I think most of this paper is written with the idea that it's a fabric white paper and I think that's fine yeah you know we really did go to great links to try to remove any direct reference hi yeah no I was just responding there that we did go to great lengths to remove direct references to fabric it is not meant to be fabric it is meant to be much more generic this is Jeremy I don't think this reads like fabric I think this reads like something that says one size doesn't fit change a plugable component so I think about it so this is Chris somebody is on the phone and not on so here's I don't know if I can do this I think I can maybe mute everybody and then or maybe Greg you can do that I muted everybody but it muted you as well Chris if you well I can unmute myself everybody can selectively unmute themselves but somebody is on the phone yeah in the background let me try that again mute everybody and then then Morale you can unmute yourself I think if I mute everybody you have to I have to unmute somebody so who am I unmuting Chris oh I think I think we're okay here yeah we are okay now so I'll take the first response there that we really went to great effort because we did get some earlier feedback that it appeared to be too fabric like we went to great measures to do that but I think there's still a really good point here and in fact Chris Ferris in your feedback you also highlighted this the fact that we're talking about hyper ledger in sort of the singular form and so this is something that we did discuss as a working group I think our original original idea was that we would all be converging on to a single code base but of course we've certainly seen now and there has been language coming out and in fact back to you know the hyper ledger website if you look at the latest blog from Brian it really goes into more detail about hyper ledger as an umbrella organization and so I think I think we can in fact revise this abstract section to along the lines that you suggested Chris where we can speak in terms of more of not so much as in the singular but allowing for a bunch of things that will allow for sharing so that's good feedback it's something that we've been talking about but I think if you go through if you look in the details of the paper as a whole we've totally went to great lengths to ensure that we weren't specifically talking about just one of the stacks under incubation and Hart I'm sorry I didn't mean to cut you off I think you had something to say on this as well I wasn't going to say anything yet oh okay sorry alright sorry Morali I'll pass it back to you yeah sure no problem David so on the background let me move over to the background I think we all are aware of the background as to why we are interested in the blockchain technology because of the new opportunities it makes available and also the potential to reduce operational costs without which the current systems have an individual system of record where every company has an individual system of record and there is the cost because of the reconciliation that happens after the fact so it's not just the new opportunities that the blockchain technology presents but it also the opportunity of reducing cost and in this case we all know about two very popular blockchain technologies which are the Bitcoin and Ethereum which are primarily permission less and I think where the hyper ledger not a singular but where what we are trying here at the consortium is to start with can we do anything on the permission space where we can have a permission network with many different participants coming on board and one of the other key technology tenants that we can have is a plug and play in terms of the consensus or any other components we should be able to be able to plug and play which will allow the adaptability of the hyper ledger itself right so whether we have one or multiple code bases the idea is of those let's design it in a plug and play fashion that down the road we could either interchange or or have the networks talking to each other so that's what is presented in the background section and I'll open it up for any questions or comments on this section also okay so again if people do have some extra comments and they are a little shy of speaking up we have our feedback channel so I just encourage people to kind of read through this and again I know Chris has made some very nice suggestions around readability but for the most part I think looks like we're pretty comfortable with the background so with that we'll pass the ton over to Hart for description on the next two sections hi so the next section is why a new blockchain and Murali did a great job of introducing this in the previous section discussion but basically this section sort of briefly emphasizes why we need hyper ledger why we're working on hyper ledger and why you might want to use hyper ledger so kind of the point of this section is right now that the main blockchain technologies as Murali emphasized are sort of Ethereum and Bitcoin and they really don't solve a lot of industrial applications that we're interested in solving so hence why we need a new blockchain I expect this section to change a lot sort of as time goes on and to be to really become sort of why hyper ledger as more blockchains come out as technology changes sort of the reasons why you might want to use hyper ledger might change so I expect this section to evolve a lot as time goes on are there any questions about this hi it's Richard here just check you can hear me I can hear you Richard probably okay good so I get one comment on this and then one on how it impinges on the rest of the doc so an argument for why new blockchain technologies need to be built I think is important and the case is well made here but I think actually Bitcoin made a similar comment in the forum we need to I guess before we need to use plural rather than singular so to make sure the reader fully understands that at least the introductory sections of this paper are setting the scene for a family and a brother project we should pluralize it and while I have the Michael it relates to stuff that's coming later as I review this again having sent comments a few times in the past what I'm wondering is what we may end up is whether we should clearly delineate two parts of the white paper so there's an introduction these sections and maybe the conclusions that make the case for a family of business style blockchains and so forth and then later on where there is specific content that the team has done a good job of generalizing but it's still quite clearly fabric related in terms of some of the diagrams perhaps we just embrace that and we say here is make the case for the project for the need of a for an umbrella and family approach and as the most advanced or as an exemplar of it now let's give an example of one of these platforms which is almost to say acknowledge and and own that otherwise the sort of tension causing delin? Yeah, so I think I'll address a bunch of this in the next section so we actually are working, we're not is working a lot on the diagrams and I think our goal is to have everything you know at some point be modularized enough where we can have diagrams that sort of apply to the entire family rather than just one one instance I guess, does that make sense? Yeah, it does it's if we can achieve that, that will be awesome I mean I must admit I was probably just taking the sort of the lazy way out by saying given where we are and the compelling need to have something ready for Cyboss I was kind of offering an easy way out which is to just clearly mark which pieces are talking about the overall family vision and which pieces are specific to a technology but if we can get the diagrams to that state then great All right I guess are there any other questions on this short section before we move on? I guess not obviously if you have feedback please feel free to submit it online or email to the working group or anything else so I guess if we can go to the vision section so this is probably the most controversial section so get out your pitchforks I guess so this is about maybe a page or two where we summarize sort of where we want hyperledger to go and I think this is more consistent with sort of the family approach so after a lot of discussion we kind of thought that we wanted hyperledger to consist of sort of lots of modular pieces that can talk to each other so this kind of fits the family theme and we want to have these pieces we well defined and we want sort of really plug and play aspects so if someone has a really good consensus algorithm but someone else has a really good database then we want people to be able to use these things and kind of our point is that lots of people have lots of different applications and use cases and each use case and application is going to kind of need different features sort of no to use cases are exactly like so people want to mix and match parts and they'll want to maybe even write some of their own parts and they want all of these to fit together nicely so this is kind of our our long term view is a sort of modular plug and play pieces that can all talk to each other and work with each other and I think this is more or less compatible with this sort of family idea so I guess does anyone have any questions or comments or I'll just point out one important point that Chris made in his feedback was about using the term standards and we have to be kind of careful with that and I'm looking for the line here I think it was in the first paragraph somewhere but that basically this isn't a standards initiative it's really an open source initiative and we want to be we just need to be careful when we use that word standards and make it clear that there is a difference between the two and it's clear that what we're talking about here is an open source project or initiative definitely I mean I saw that comment I think it's a good comment from Chris I think we need we're obviously going to have to have de facto standards if these things are going to talk to each other but we should emphasize that we're not a standards body the goal is not to do standards the goal is to have buildable technology so I agree that that's a good point that we should emphasize yeah great right because the last thing we need for want is to have a bunch of people that know nothing about what they're talking writing some specification to tell us what the standard is so I don't want to see us encouraging that in any way and it's going to happen there's a couple of working groups going on at ISO and they'll publish something and hopefully it'll be irrelevant but that's this is Brian one of the points I made in my rambling first blog post probably should have been three or four different posts was about this distinction between the implementers the standards bodies in the global governance organization and I think it's very useful for us to be able to deflect some of the political pressure out there for people to converge on one wire protocol to rule them all over to these other groups and instead to say we're going to be building what we know we need to build for our needs and if some of these de facto standards become candidates for promoting upwards of places like W3C or ISO or insert insert industry standards group here then great but I you know I want to make a firm distinction between what we're doing which is building running software that might consume standards all day long and throw some off versus the standards body which is just different properties different characteristics yeah okay we can go through and rewrite that so it's a little less de-emphasizing sort of the use of the word standards and sort of more emphasizing the fact that we want the components to be able to talk to each other and be plug and play I guess if that makes sense yeah it does and I you know I think it's important to talk about interoperability and portability so you know you can highlight I think the theme that you're on there that you know if we're going to have these various you know this sort of family of components that can be you know assembled into useful solutions that the set of interfaces need to be interoperable and you know and if you're going to write smart contracts I need to be portable from one platform to the next and I think that's it's perfectly fine to talk about those two characteristics and I'd even okay so interoperability is important within a chain right everybody who has set up and is participating you know the 20 banks on the banking network all need to be talking the same protocol to me though that chain can have a very different set of characteristics in terms of consensus mechanism in terms of block size in terms of you know anything that you might parameterize as initial configuration you know when you mine your Genesis block so to speak right and kick the chain off and the more that we can make those runtime configuration variables rather than you know completely separate sets of software you know I think we do everyone a service and so the modularity thing is somewhat to some degree also a customizability thing you know we're not trying to say there's only one consensus mechanism to rule the world which even distinguishes this from the side chain point of view because side chains are still fundamentally about tying into one big chain at some point in the life cycle and using pretty much the same consensus mechanism so I like the modularity I think interop is useful but I don't want to overplay interop because this is not like TCCIP this is more like a distributed database right well so I was going I was using the term interop in terms of you know as we were discussing for instance the blockchain explorer Mick and I were you know we obviously you know saw tooth has a set of interfaces and apis and then fabric has another set and we were going to do this sort of a pluggable approach but ideally we align on some set of interfaces I wouldn't call it a standard but it's an interoperability interface or you know API layer that we would maybe strive to get to the point so that we don't have to build in these sort of intermediary you know abstraction layers that to try and do convoluted things that and that's the expression that is like a first principle of good engineering rather than a mandate right yes I I definitely agree I'm not talking about interop between blockchains that's a different okay well I think that's good I think we got the point there we'll just make sure it's clear you know we're talking about that make it clear that we're not a standards body and we're not actually you know taking that task on but you know achieving the other aspects so why don't we go ahead and hi it's Jaros I'm going to be in a while good Jaros I just want to I guess make a suggestion that I know we don't want to assert your standards body we don't want to dictate standards but I do think synthesizing engineering principles is perfectly one would be kind of compatibility of languages it would be helpful it's the most part to try and find the minimal number of smart contract languages so in terms of compatibility as you do kind of like find that one so this is my first time in the committee I'll probably try to go down here but that's just one thought that came to mind so I think you're trying to make is on trying to get to fewer programming languages than more I think I tend to agree with that although we've got sawtooth that's primarily or maybe exclusively Python and we've got the fabric which is primarily go but then we have a set of SDKs that are moving obviously the language specific so that the application clients can be written in whatever floats your boat which is I think as it should be is that in terms of smart contract languages so the underlying language of what each thing is written in is less important so the smart contracts yeah I think that's obviously something that will I mean right now we have go and Java in the fabric and obviously in the transaction families are Python first sawtooth but I kind of hope that we can get to a point where we are less concerned about the language that you have to write the contract in and it becomes a little bit more obvious that there's you know whether it's something like solidity or if there's a DSL that we can all come up with that there's various ways that you can develop it I think will and then we generate the code that actually executes and that's not really relevant to the developer that may be where we get yeah I'd agree with that it's almost like the languages whether the DSLs or more generic it's something we want to encourage a plurality there over time there's just so much research going on in that space I just had one other comment on this section I was read through it again I think it only requires one sentence or something just to clarify it in the eyes of an inattentive reader a quick read of it can give the impression that we envisage a single logical architecture and that the plurality comes from competing competing implementations of different components and I think that is actually a worthy goal but I don't think that's what we'll achieve in the short or even the medium term I think we will see very different architectures which can still share some common components because a consensus library could be used by multiple architectures even though the architectures themselves are very different from InstaTooth and a number of examples of that and obviously others are as well so just on a quick read the reader can conform to the trap of thinking we're proposing a common conceptual, logical architecture where I've done it and we are so I think it just needs a sentence to clarify it yeah I think that's good feedback thanks Richard okay so just to kind of keep things moving along and any other thoughts please you know submit them offline we appreciate that so why don't we go ahead and pass the over to Stefan who will talk us through industry use cases and future requirements yeah hi good morning I just give you a brief overview of our section industry use cases the idea is basically to come up with some sample use cases where Hyperledger might play a role across industries and here up front I would like to ask you for feedback if we have not over emphasized financial industries please have a look and give us feedback there the use cases we mentioned is financial asset depository, core production, supply chain, master data management and internet of things I go into a bit of detail of each now financial asset depository basically the workhorse of financial industry how to tokenize assets, how to make them interact and how to come up with post trade or even trade applications then corporate actions is what to do with assets on the blockchain, how to pay dividends how to pay coupons for bonds and so on supply chain covering basically the producing industries supply chains i.e. value chains from raw products