 Welcome, everyone. We'll get started in a couple of minutes. We're actually in a minute time. And I'm going to go ahead and start recording. Welcome, everyone. Thank you for joining us for the hyperledger in depth an hour with our member Simba chain today. I'm very excited about today's session. We have three wonderful actually four wonderful speakers from the Simba chain team. And that includes and John Roy, who is the VP of Simba chain, Joel Nidik, who is our CEO and Jeff Curtis, who is the VP of defense and supply chain. And we also have Ian Taylor from Simba chain. So today they'll be talking about connecting supplier and Department of Defense blockchains for transparent part tracking. We welcome them and want to remind everyone some housekeeping rules. Number one is that all Linux foundation hyperledger meetings and events are covered under our antitrust policy. So please, if you have any questions, see the full policy on the hyperledger or the Linux foundation site. But just, you know, for for a reminder, please don't share any competitive information that you shouldn't be sharing. Another reminder is that the session is being recorded on this will include the Q&A. So if you have any questions, just please go ahead and share those with us, but we will be recording them. And after the session, we'll go ahead and make both the video and the slides available for all attendees and for additional viewers in the future. Another couple reminders. This is as interactive as you're going to get with the Simba team. Normally, we would see each other in person at an event, you'll have you they would give a talk and you would come over and have questions and meet with them in the hallway. But we have an opportunity to interact with each other, raise your hand if you have questions and we can promote you to speak. If you have any questions, you can also pop them into the Q&A, which is just a regular zoom Q&A and in the chat. And if it would be great right now, we have a lot of participants, if you can go ahead and just say hello and where you are zooming in from today, that would be great to see kind of the coverage around the world. So without further ado, I am going to send it over to the Simba team. If you can go ahead and share your screen and we can get started. Welcome everyone again. Yeah, thank you very much everyone. And thank you, Daniela for inviting us in the hyper ledger community here. So I'm going to go ahead and share the screen. I think we should be a host disabled screen sharing. I wonder if it's... I think she has to make you a host. I think I have to be made a host or a panelist. There we go. Okay, fabulous. Well, thank you very much. And, you know, we're going to get things started and, you know, with this project we wanted to talk about and also a paper that was recently published and we're lucky to have three of the three of the four or three of the authors and co-authors of that paper here with us. I'm actually not one of them, but all three of my esteemed colleagues here are authors of this paper. Dr. Ian Taylor, our CTO, Joe Knight, our CEO, Jeff Curtis, our guru for all things supply chain and logistics. And so, I mean, I'm going to pass things off. I think to Joe, would you like to intro this and then, you know, we'll talk about and we'll go through the slide deck. And if Dr. Taylor, please feel free to chime in, talk a little bit more in depth about, you know, parts of that, parts of the paper and what we've done. But it really showcases, you know, this particular project relating to supply chain and visibility and traceability in real time. So with that, let's do, you know, the overall goal. But Joe, would you like to kind of start things off or one of our other colleagues here? Yeah, yeah, I think every, we'll have everybody introduce themselves. So my name is Joel Knight, I'm the CEO of Simba Chain co-founded with Dr. Ian Taylor here. And it's been very exciting. You know, Simba Chain started to build out, you know, solutions for blockchain and make it really simplistic for different organizations. And we found a great place in government that is needing authenticity and auditability and traceability. And so this project came about from the US Navy and currently funded by Nav Air. And it's been really exciting. It came out of a paper that we've been working on with the University of Notre Dame Boeing and Navy and other partners like a TM co. And so we'll be going over how this, how this project came about, what we've been doing in it so far. And also the paper that is very much more extensive than we can go over in a webinar setting. But it's, it's there, we'll show the link where you can go and look at that paper that's been published and it's been peer reviewed. So it's pretty, it's a very great paper to understand about how blockchain can be used in supply chain and even in a government setting is, as there's a lot of complexity in moving parts and stakeholders that are involved that need to know and have that verifiability. So I'll pass it over to Dr. Taylor first and then if you want to pass it over to Jeff and then you can bring him back to me. Yeah. Hi everyone. My name is Ian Taylor. I'm CTO of Simba Chain and also a professor of computer science at the University of Notre Dame. So over to Jeff. Thanks Ian. I'm Jeff Curtis. I've been with Simba Chain about a year and a half. I'm the vice president of the defense and supply chain. I came to Simba after about 33 years at DOD, about 30 at the defense logistic agency. And then the last three and a half, four years with the office of the secretary of defense, Anjan Joel. Thanks Jeff. Great. Yes. So hi and I'm Anjan Roy here, vice president of Simba Chain and I'm also the vice chair of the public sector SIG working group here at the Hyperledger Foundation. So again, this is related to that because at least it's semi-related to the public sector. I'm a part of it. So this is certainly exciting and thank you all for coming. So we'll get right into the overall goal of this project, Joel. Yeah. So the overall goal, we wanted to track the parts that were coming from OEM so that there's visibility into the DOD supply chain. We've all been through COVID. We understand the fragility of our supply chains. We have to now come together and realize that there's vulnerabilities in our supply chains. And so it was really fantastic about this project as we actually started it before COVID. So we actually had been able to provide a lot of value as COVID was happening to the Navians. Really exciting. So for example, OEM like a Boeing would be able to be making a wing or a component or a tail hook or whatnot. And providing that internal insight and sharing the progress both in the purchasing of that item, the whole logistics, the maintenance repair and operations of those different items, sharing that information, using fabric blockchains. So this is obviously a hyperledger fabric webinar. We are using hyperledger fabric in this project. And it's been a great open source tool to be able to communicate the value of what blockchain or distributed ledger technologies can provide to government and stakeholders within their supply chain. So then Navier then would receive these updates to gain more view into the entire end process so that they can make decisions and have a better collaborative way of communicating with OEMs and very significant partners that are in the supply chain. So the parts we're tracking are tail hooks and wings from the F-18 aircraft. So you can go to the next slide. So I'll go over this and then Ian, feel free to or Jeff, you know, you guys can hop into say anything that I might be missing. But the maintenance repair and overhaul is about the replacement test measurements. I'm not sure, you know, everybody that's on this call. So, you know, if some of you may completely understand this, you're you have a manufacturing background, you have a supply chain background, but we're going to kind of dive into this a little bit. So the preventive maintenance are tasks that are scheduled regularly. So they, you know, it could be regarding in the, you know, updated design of a component that continues to fail. It could be in the equipment, you know, the functioning, how well is it functioning and providing that so that it's ready, you know, readiness is a big thing. Sustainment is a big thing in the military. And we have to be ready to whatever, you know, may come come their way. So the corrective maintenance are tasks that are performed that failure occurs. So it's like fixing of an overhaul of the equipment, the machinery, the components that may be involved, that assemblies that go into that. So it's very complex assembly. So we're, we're digging down into the build materials of these items and providing that non-reputability, the predictive maintenance. So now we're, you know, wondering, okay, how do we now analyze, you know, if something's going to, if the failure might, might take place, how many flight hours does this have, you know, what, what are those different, you know, dials and set points that we need to be aware of to make the warfighter successful and what they're doing. So the maintenance repair operations, we really focused first on the tail hook and now we're moving into the, so Ian or Jeff, anything to add to that? I just want to weigh in a little bit. Appreciate that. Thanks, Joel. The corrective maintenance becomes more and more of a challenge, especially as a lot of these assets are older than we ever anticipated they would get. So that just becomes an increasing challenge of things breaking that you didn't anticipate with break. There may not be a supplier base. And so, so I'm sure we'll talk more about that as we move forward. But that's just kind of a challenge that just keeps getting more and more challenging. So over there. So there are different levels of the MRO process. And this is all detailed in the, in the white paper that we published, like I said, in Elsevier, the blockchain journal. So, and I know there's a lot of discussion about blockchain distributed technology for this on sense of purposes, we're using these for this, for this session, because we actually have connected with block, we've done some cross communication between blockchains. So that's why we're using the blockchain and DLT interchangeably because we've done connectivity of both. So you'll see that later in the diagrams of what we've been working on here. So there's an O level maintenance that occurs in the organizational level of the, you know, of the Navy. And, you know, it could be a single maintenance squadron, it's responsible for the parts. And the intermediary eye level maintenance occurs when it's specialized. So now we're looking at kind of like the, you know, there might be some kind of consuming diagnostics that are involved and some like back, you know, there might be a job shop that's kind of like, you know, back in the back corner that, you know, they're working, they're specifically good at like welding, or something specific like that, or one's great at bearing analysis, like, oh, this bearing's about to fail. This pin in this tail hook is, you know, things like that. So the other level is the deep, the depot level. So this is where the maintenance occurs. And this is a very highly specialized offsite repair. So they might even be into the fact that they actually have the diagnostic equipment that is specifically and they may have a, as opposed to just a welder, they may have a materials engineer. So they might have a metallurgist or something like specific that is like, they are like really almost down to like how the original design was intended and things like that. So that's, that's kind of where these, so just defining these different levels. So people understand like where this is taking place. And you can start seeing like, wow, this is where smart contracts and, you know, having non-reputability and there's a lot of things that go wrong. And if we can't immediately like pull up a system and say, I know by a shadow of doubt that this happened at this date and it's been time stamped, basically notarized, then you can kind of start seeing how communication can break down. If we don't have this kind of real time system capability to immediately validate and authentic authenticate and have that immutability. So, and you can even imagine in large organizations, when, you know, Boeing or Navy, nobody even knows, you probably are working on systems that you don't even know who the other person on the other end is. And this is obviously normal in a lot of different settings. But we have to have a moment of trust that like, you know, somebody's getting in a plane that's, you know, going to fly. I need to know that this, the maintenance worker had signed off and that this is all checked and everything is great. So having those capabilities and then even knowing that the, even down the lines of the manufacturing and the sub-tier supply chains that things have been done properly, that's very important. So, Ian, next slide. So, Ian, do you want to talk to me about the high level flow, just briefly, and then maybe a little about the paper? Yeah, I just posted the paper actually in the, in the chat. So everybody has a link to it. Okay, great. Yeah, I mean, from the previous side, this gets pretty complicated, but essentially this is how the high level flow of what I have things work. So we created a 28 page document that describes this end to end flow, but roughly what happens is, you know, using those things from the last slide. At the L level, so at the carrier, aircraft carrier, they'll look at an F-18, they'll inspect the tail hook, for example, that'll be the L level. If they can, you know, make a repair there, they will. If they don't, they'll take it to the high level. The high level may have some, you know, equipment to be able to repair, depending on what goes wrong. If they can't repair it, then it goes to the D level, which is basically the repair shops across the country, like FRC Southwest and South East and so forth. So the part then will get transported using a carrier from the carrier, using a transport carrier from the aircraft carrier to the depot. The depot will go through that process of overhauling that part or ordering a new one, and then that will go back to the carrier and it'll be installed by the LI level. So this is a complex process and it touches a lot of data systems. So we went through the entire process end to end, analyzing all the data systems involved. There's about 30 different data systems involved in this entire end to end process. The 200 plus decision-making points across that process is quite a complex workflow. There was around 18 tables that we ingested to get the data that we needed for this track and this flow, and that's about two and a half percent of the data. So by doing that analysis and going through this process, we essentially found the data we needed rather than using the 97.5 percent that we didn't need. So next slide. So that's the kind of outline of the problem. We thought we'd go through and give some slides about Sember Chain, how it kind of addresses these sorts of problems. So this is sort of a flow of how Sember Chain is used. And essentially on the left here, this is a supply chain tracking scenario. So there's a parcel here, but imagine it could be anything, it could be a telehook or whatever. This is just illustrating that a particular package could be tracked at different geographical locations and across different modes of transport, for example. What we do in Sember is we look at those entities, the assets, and how they're tracked using the models. So we use assets to represent, in this case, the assets that are tracked and then transitions that involve different stages of the journey, those transitions of state, if you like, of that or the update of that package as it's going through whatever system is going through. So by specifying that with those relationships, we actually write those relationships into the smart contracts. So the smart contracts are kind of annotated. So they have relationships explicitly between the different methods in the smart contracts. And what that enables us to do on the back end, the data that is recorded contains those relationships. So it contains essentially, you can think of them as, you know, a method and in Solidity, for example, have appointed to another method that it relates to. So or in Fabric, it works a similar way. And then on the back end, we can query that data and using tools. We have two implementations. One is GraphQL. And then we also have a graph database implementation. And the way kind of that works is we can, we can take in the graph database, we can query it as a single system, but we can have off chain data in the graph database. And we can also have on chain data referenced within the database to the underlying blockchain. And we can bring those together in one query. So from an application, they're querying a system, but some of that is tracked and some of that is not. And in the DoD, we will put, you know, flight critical components on that, you know, as part of it, they'll be the ones tracked on the blockchain, the rest of the components that may be involved in the entire process, but not a flight critical, maybe off chain, for example. So next slide. So simple chain that aside from the modeling we do on the input and the output, these are the various components in the system just to give you an idea of the sort of the, I guess, issues we address with, with simple chain in the, you know, in the blockchain kind of life cycle. So I'll just go through this real quick. So at the center, there's different, there's blockchain. We support eight different blockchains, Hyperlegia Fabric, we support that natively now. So we map from these smart contract, well conceptual set smart contract models directly to Fabric native. We also support the EVM, the Burrow EVM implementation of Fabric as well. And then the model that defines these assets and transitions also can be used to tie different versions of smart contracts together. And also it can be used to connect different smart contracts on different blockchains by essentially kind of marrying parameters across from one smart contract method to another smart contract method on a different chain. And that enables us to search both blockchain simultaneously and we'll touch on that a little bit later. And then sort of on the front end of this, we have transaction validation and resilience. So as transactions come in, we validate the actual content as opposed to kind of the method signature. So if you try and put a massive integer into a UNT, something that's more than 32 bits, for example, it'll complain at that level rather than clogging up the blockchain. And then we also have asynchronous workers that run for each transaction where we need to. So in other words, if a lot of transactions come in and the blockchain can't keep up, we'll farm out these workers and they basically monitor the transactions until they get a receipt. And then those are exposed through very simple APIs. So for each smart contract, we spin up a REST interface that is used to interact with the smart contracts and blockchain. So from an application standpoint, you just write into a REST API, a post will update your on-chain and a query will search the data on-chain, scoped by that particular method or the smart contract. And then on the back end, we have a transaction cache. This essentially every transaction that has a receipt that's recorded on-chain, we cache in a database and then we have an application that runs all of the time checking the consistency of that cache. And then when querying, you can use that cache or you can go directly to chain. It depends on which mode you want to use, but using the cache, it becomes super quick. And then we can search using GraphQL or Graph databases or we can search using direct queries to those endpoints and filtering. Those are all brought together in a dashboard and we have the SSTKs to interact with all this stuff. And we also support transactions subscriptions, which I'll touch on later, and the ability to off-chain data. So you can add a file to a transaction when you put it on chain and that will, you can retrieve that later. And that file will be stored in an off-chain file system and bound on chain using a hash code. So next slide. And of course, we have auth around all of that, which in the DOD use case, we're using cat cards for authorize authentication to the platform. So yeah, so next slide. Yeah, I think we can skip this one. So just to kind of talk about the model, I touched on that earlier. Essentially, we have assets, which you can think of like as a line of a business process and transactions or transitions, we call them adverbs or relationships. So in this case, the assets would be a wing or a tail hug, and the transitions would be the status from Boeing about what is the progress between zero and 100% of that wing. And they provide that information in real time. And they're querying our local systems to do that. And then they're adding that to hyper-legiafabric to transmit to Mava. So this model can be deployed in any supported blockchain. As I mentioned, we have several now. And then an API is generated. So if you go to the next slide, we'll show how that kind of works. The graph model as well, this will come in later, enables us to do these versions and connect to different blockchains. I'm going to show that later. So next slide. So once you define your model and generate the smart contract or even just import a smart contract that's written elsewhere, by using remakes or whatever, we can import those too. We go through this process. So the process of deploying the smart contract is quite simple. Basically, you choose the blockchain network you want to deploy it on. In this case, it's Ethereum and our private Ethereum network called Circle of Life. If you click the button, Angel. And then the next phase is, do you want off-chain data? And there's several sources there for where you can store off-chain data, if that is relevant to this particular application. Next. Then you choose a smart contract you want to deploy. In December, enterprise platform, you actually can select several smart contracts here. So pure application is basically a container for multiple smart contracts that each have REST APIs. So this is just choosing a container demo here. And then next slide. Then this asks you to choose the name of the API that you'll hit and the name of the app. And then next slide. And then once this is deployed on the blockchain, we ought to generate these interfaces to, you know, there's an ALRI dark and swagger interface to the result of REST API. So with the REST API, basically, a method in a, say, if you're talking about solidity, a method will appear as an endpoint, a post with the parameters of that method will transact on-chain and a get and do a query. Okay. So the next slide. This is smart contract designer just to give you a feel for what that looks like. So here is an additive manufacturing example. We have an AM component, the rectangle box there. Those are the assets and the blue ellipses are the transitions. So you can without writing any code, you can drag and drop these boxes in a web UI. So you can pick up a component. You can say, okay, the component needs to be manufactured. It's delivered. It's received somewhere and it's installed. In the case of MRO, that would be the kind of process. But a component in an additive manufacturing example, that actually points to a design, an STL file or a build file for that process, which can be updated. So just by, creating these different relationships about how these different things interact, builds up a model of what the data looks like and it gives a conceptual model about how that data should be queried after the fact. So click next. Each of these boxes, if you double click them, you can specify the parameters. So the boxes represent methods. For example, the parameters represent the payload of those. Next, click next. And then you click a button at the bottom and that auto generates the code, the smart contract code. This is an example in solution where it works a similar way for fabric generating the chain code. And then next slide. Okay, so back to the Navarro scenario. So what do we do here? And this kind of bubbles up into a more high-level architecture in a little bit. But essentially, the way we're connecting the OEMs with the DoD is through two separate blockchains. We have a quorum. In fact, we have three blockchains in the scenario in total. And I'll give an example about the connectivity later. But essentially, we have a consensus quorum blockchain within the DoD. That is basically bringing in the data from the MRO process we described earlier. And then we have a, that is connected to, you know, so the DoD have a simple chain platform that can access that network, for example. And then the OEM network is Hyperledge Fabric. So that we have that fabric network set up now. And that can, that is providing, you know, Boeing is transacting kind of data onto that fabric network to share with Navarro. So those two blockchains are connected through a single instance of Simba chain. So what Navarro are able to do there is prove both blockchains simultaneously. And the way they're connected is essentially through a PO order. So PO order ordering like a tailhuck or a wing, for example, from Boeing is tied to a PO order parameter, you know, on the kind of OEM network. And we also use that PO number to ingest or connect to other instances of blockchains that we already have created for other projects within the DoD that looks at public information. And I'll show that in a little bit. So if it goes to the next slide. We started off when we've initially connected with Boeing. We started off ingesting CSV files and writing those to Hyperledge Fabric. This was partly due to, you know, there was a delay in gaining that connectivity with Hyperledge Fabric and the right certain and the permissions from the Boeing side. So this was essentially a temporary way to test the system. So as what happened there was Boeing queried their systems, they generate a CSV file. We provided a secure service to receive that. And then we basically process the CSV file and write that into the Fabric network. Now, about a month ago, we've connected right to the Boeing instance. So now we can do this without using the CSV files anymore. But this was kind of the journey we went through in this project. So next slide. And then this is the overall kind of architecture for how this works. So essentially on the left side here, we have the data from the OEMs. So the way that works is they have a data collector component that queries their ERP systems for the information, which basically is extracting the status of a particular, you know, particular part. For example, a wing can take months to make under progress. But there's progress within that timeframe. So from Navar's perspective, they place an order and they wait until that order is filled and they can use, you know, historical data to understand roughly when that happens. But then when other orders come in within Boeing, for example, which are super urgent, that might delay schedules. So this information changes. So they're querying their underlying system and they're looking to see, you know, they're looking at the bomb, which is the bill of materials, they're looking at the wing and they're assessing the progress of that particular part. And they're collecting that information and then they're using SDK then to connect to fabric. So we have SDKs in Python and Java and Node and in .NET. They're using the Python SDK. And that just interfaces the data collector to using some code that basically just makes it even easier to connect to the REST API. And then they pass that data to the REST API using that authentication layer. And then that hits the REST API. And it goes through the various things I talked about earlier. So there's, you know, that goes in. It goes in a simplest transfer, transacts on the chain and they wait for the receipt and that kind of gets cashed. So all of that process goes on all of the time. And then from the Navar systems, they have a similar flow. They have already a basically at multiple levels of flows that collect all of this data from various places. And then at the bottom, these are the structure of the different, you know, networks and the OEM, the plot info is coming from Navar and then the part supplier info and updates is coming from the OEMs. So next slide. And this is the two smart contracts we were looking at using. So this is from the Navar side, looking at different work orders and connecting data through the MRO process, which then bubbles up into the POs that go out of the system. If we go to the next slide, that shows kind of how we connected this. So this is maybe a little bit hard to see. But essentially what this is showing here, I try to draw a line between these two networks. So on the right hand side here, you've got the Hyperledger Fabric. So this is running basically on the OEM network. And that's providing updates from the OEMs to Navar about the progress of the particular parts. And then what we did, which I mentioned the third blockchain earlier, and we'd written a parser or ingesta maybe for PubLog, which is public information about every transaction an OEM has with the DOD. There's a public database, it turns out, with all of these transactions in. So we wrote a parser for those for another project and ingested information from PubLog about the status of these various parts. And we rerun that process to extract information about the parts that were involved in this process, the wings and the tail effects and so forth. So we preloaded this blockchain with this information. And we connected these two together. So we connected using the PO, we connected these two together. And what that enable does to give is we were able to take those parts and automatically lock up all the suppliers for those parts or take that part and lock up a particular supplier for that part and even get the zip code and lock where that supply was. So all of this public information really enhanced the graph of information that is flowing through the system. So next slide. And then at the back end, we have these search and access APIs. If it goes to the next slide, I'll just show how the GraphQL works. So this is our GraphQL interface. So based on the relationships we defined earlier, this is basically showing some of the interactions. This is more aligned with PubLog. But the general idea here is we have a supplier part here, which has a relationship with a part, which has a relationship with a part extra detail. It also has a relationship with a supplier. And it also has a relationship with whether there's a long conformant record of this particular part. And the system we've created for querying basically enables the user just to walk through that process. So you just click on the data, click on the data set you want to extract in the query. So here, I click supply apart on the left here. And the green color there is saying basically those are the things that are selectable from here. So it's giving you a hint about where you can go in the graph in order to select data. So those are selectable. Now, if you click on a part, for example, then that makes the part detail also selectable because that has a direct relationship, but it wasn't selectable from the supplier part directly. So you can use this process to go walk through the graph, select the journey you want in terms of the query you want. And on the right hand side here, you can select the parameters from those transactions that you want to extract. And then you can also add filters. So you can do things like, okay, query this part of the graph, but just give me information when and then equals certain a certain thing or give me information if a, you know, if the part name contains, you know, tailhawk, for example. So you can do queries like that and that extracts the data. And then when you quit, you hit the query on that, you'll get data back to the next slide. The data then is clicked through a ball because it's a structured embedding, right? It's a graph QL structure. It's not a true graph per se, but in this example, but, you know, the first level gives you that first box on the previous slide. So that'll give you all the supplier parts. And then at the bottom of those, you'll have related information that you can click through. So in this case, you click through to the part in the second level. And then that's the part information there. And then you click again for the part detail. And that goes through the next level of the data structure in order so you can see the detail of each level. So this is the kind of query in that the, you know, that is capable in that graph. And you can do this across, like I said, across those two or three blockchains that we're connecting together and retrieve information connect data across those so you can enhance the experience. And then next slide. Ian, if I could for you, this very simple chart. The, one of the things that from what Ian was talking about about visualizing, when we talk about supply chain risk management, a lot of times we end up in a position still across DOD and across, I think even commercial suppliers of pay and chase, you buy something, it shows up, and then you find out that it's not what you wanted. It's not conforming, you know, the lawyers always say be careful about the word counterfeit, but it's not what you thought you were getting. And now you got it. And not only do you have to get your money back, you have to see if it's gone out anywhere, has it gone forward, and so on. But you can actually visualize this tool or use it to visualize so you can say I'm getting ready to make a buy from KH code X. What have we bought from them in the past? Has any been, have any been non conforming? Where do they come from? As this grows, you know, hopefully you have multiple upstream suppliers, you know, up to, you know, supplier number one, then all the way to end and see, you know, this one we've never had a problem with, or we have had problems with. And I can assure you every time you use your credit card, they're doing that. When you swipe that card, it's going to say, it's going to take a look and say, hey, does the Curtis family usually shop in West Virginia? Do they usually buy this type of thing? What's the dollar value? And I use West Virginia because my daughter's mom used to take her back to Ohio State a lot from here in Northern Virginia, and that credit card would bounce a lot in West Virginia just didn't match with the rest of our lives and how we used it. So they're trying to keep track of that and keep bad things from happening up front by blocking it up front. This gives you the tools to start to head in that direction. And it's just a great thing that, you know, I did many years at DLA and I don't know where they are with us now, but we were heading towards the part of, you know, looking at items supplier and price is the price way out of line. Is this an item that has a history of challenges? Is this supplier, somebody that could be cage hopping or is sharing an address with nine other companies doing lots of other different things in some Wyoming suburb, which by the way has happened. So this is a way to get in front of things and to visualize something that otherwise you'd just be looking at very bland data and there's like a chance you would miss something that was there, but this allows you to take that and really turn it into something that would be much more useful, kind of turning data into information, which is something before I see Anjan and Joe getting ready to talk. They've heard me say so many times that so many of us are data rich and information poor. Can we turn it into information and that leads us in that direction. And I will pause there and take a breath. Yeah. And I think exactly Jeff, it's just actionable data. You can set notifications to what you care about. And as we, as more and more OEMs and governments and groups start using systems like Hyperledger and, you know, various connectivity tools, you will have now a basically an Oracle service that you can know and there people can come to complete agreement and consensus on items. Because right now it's, it's, it's continually adjudication, just like Jeff spent probably his majority of his career adjudicating, you know, more majority of items, you know, that just were problem childs and different things like that. So, you know, Jeff, if you want to say something. No, I was just saying you mentioned the adjudication. By the time I ended my career and I was in a pretty senior position, but my lives were just kind of, or my days were kind of hellish because by the time anything came to me, nobody had solved it and they had tried. So I only got things and you as CEO of the company, I'm sure are going to are going through the same thing by the time they get to you or to me or to whomever. Other folks have tried, they failed and there's nothing easy about what's left. They're going to have to make decisions and fight the battles on this. So, yeah, but if this allows folks to identify things a lot earlier, that's just a wonderful thing. We'll try next slide here. Yeah, I think, well, if you go to the previous slide, this is just an example of a graph using the same data. So this is our graph, we're actually using Neo4j from a technical standpoint, but this enables us to essentially create a graph of the data which can, in the case of supply chain, you know, a graph enables you to represent a supplier and then have a supplier point to another supplier, you know, a relationship with another supplier, so for us to do multiple levels of supply chain. So when there's GraphQL, it's very hard to do that. And this enables us to put this data in this format and connect on and off chain data kind of seamlessly to one query essentially. This isn't something we present to customers, but we can run a query from a UI to get a very complex set of data across, you know, this graph and pop the data in a simplified user interface. We're using kind of simple user interfaces essentially up that side of things. And then the next slide, just as kind of really the last thing to touch on is the subscription. So one of the parts of the tool, the supply chain enterprise platform that I touched on earlier was the ability to do subscriptions. These can also support logic. So you can, you know, you can filter, add filters that can be chained together. So you can do things like, you know, notify me if the idea of a component is 8756 in this example and the name is Ian or whatever. You can do that and add, you know, quite complex kind of logic statements that where the conditions have to be met in order for the notifications to trigger. But you can add these on a basically a blockchain method level and then filter on the parameters of that method. And then you can connect this to through SMS or send emails or web notification targets. So you can connect it to other systems to trigger other processes. And next slide, which I think is the final slide. And this is the interface to that. So, you know, it's a very similar idea. You choose basically what you want to, what you want to filter on. You choose the conditions about how that happens. I mean, click subscribe. And then that you just get notifications as data that meets those conditions come into the network. So any questions or thoughts, comments? Not surprisingly, I had another comment. You know, every time when Ian was walking through this, there were so many pieces of information flowing in so many directions and so many literal physical parts moving around. Every one of those tends to be a chance for a hiccup and for things to become unmatched. But with blockchain hyper ledger, you're talking immutability, things are going to match. And back to one of my catchphrases that I learned at DLA was single version of the truth. I'm presuming we have some folks on here from DOD. You know, we all live the dream and continue to do so of reaching financial auditability. And that doesn't mean we were wasting money or that we were losing stuff. It just means that the books didn't necessarily balance the way they should, according to generally accepted accounting principles. This can help go a long way towards making sure things line up. There is one version of the truth, which is the right number of versions of the truth. And sometimes, you can look at medical records within DOD. You can look at book to floor and floor to book in depot systems. You're going to have mismatches. And this will help reduce that a lot significantly. So I'll pause there. Thank you, Jeff. And we've had some good engagement in the chat box. Great to see everyone from all over the world. I see California, Munich, Germany represented. But we do have a question from Nicholas. And thank you for the feedback there. This is what we're glad that you think this is a great presentation. A question Nicholas does ask is, what are the tangible benefits in terms of dollar savings or department of defense, Boeing, other vendors? It may not always be about dollars. Like you said, Jeff, it may be about risk. It may be about availability, which is a type of risk. It may be about auditability, which the DOD struggles with, but tries to get a little better. And that's obviously kind of worms. So your question on that, as far as the... And you did touch on it, but tangible benefits. And then also, how easy is it for a new vendor to be onboarded into a network like this? Yeah, I can take that. So we did analysis. So about 15% of items are scrapped. And that is a combination of... I have an article coming out here soon about this in one of the manufacturing magazines. But about 15% of items total scrap. And what we've been able to determine is we can improve that if not eliminate a lot of majority of it, because some of it is actually due to non-traceability. They actually throw things away, because they can't actually show provenance of where it came from. They literally just throw it away. And so you have a heat treat code that just didn't get put on previous at the heat treat. Well, there's a lot of things we can do to tie purchase orders, geolocation, and identification, and to find out when that heat code, that heat block came from. So that's just an example of a heat treated component and material example. And providing a immutable and non-reputable hyperlendrophabric and provide connectivity with your supply chain, you can then immediately be able to verify and validate query and find out where these items came from. So that's the value that we can bring. And I think about 40% of... Just to give an example, the tail hooks about $40,000 plus potentially with combining of the components. And about $40,000 worth of that item, 40% of it's like paperwork. So as we get to more of a digital world and provide a more digital footprint capability, query ability, instant real-time notifications, you can really start saving a lot of dollars on those different things. So about at the end of this project, I'm sure we'll have a very detailed thing by just trying to give us an anecdote. And then onboarding that government customer, obviously, these takes large partnerships a lot of time. This is not a fast-moving capability. But once we get things rolling and you get these networks built out like hybrid or fabric and these different networks, you can then immediately start realizing benefits about the data being shared. But that comes through a lot of like contracting, working together. There's OTAs, there's SBIRs, there's a lot of innovation capabilities that vendors can go after to get these projects rolling. Yeah. If I was to comment like what you just said, Joel, a lot of that time to onboard new vendors is largely contractual or otherwise human. It's off-line stuff. It's not, if the question was more about the technology, the onboarding of new vendors or new network participants is a very different conversation. If all the contracts and the bureaucracy and the human decisions are abstracted the way, which of course is not reality. But if they were, the actual technical plumbing is pretty fast. The DOD is fast-moving towards a zero-trust infrastructure so that we can not, these centralized certs and different things like that are causing very much problems, especially to get to more of a zero-trust capability, open source, where it's very transparent, hyperledger fabric, Linux foundation. And all the other hyperledger sawtooth, we support that too. And hyperledger burrow is Ian also described. So just different capabilities and kind of bringing partners together. But yes, definitely the onboarding can be fast. We have a continuous authority to operate that'll be going into platform one, which is Air Force's platform. So there's different things, especially if you're going into RDT, any network that's thought more complex. So it's a little bit long time for the risk management framework and ATOs that have to get processed. So to try and move towards more cloud infrastructures are obviously a lot faster onboarding. So I think we have another question. Okay. Do we have a question? Do we have another question? Maybe this is a question. If you'd like to ask questions, either raise your hand. Just a reminder, everyone, if you want to ask questions, please go ahead. You can put it in the chat. You can put it in the Q&A or just raise your hand and I'll go ahead and promote you to permit talking. So it'd be great to have an opportunity to ask some questions. I do have a question. And this is something that we've been getting very often specific to consensus quorum. So there's two flavors of quorum that consensus provides. One is quorum pro go, and one is hyperledger Bezu based. Which version does Simba support? So we're supporting the go version, I believe. Ian, is that correct? Yeah, correct. Yeah. And then the Bezu is Java based, I believe. Okay. Thank you. Yes. Yeah. And consensus, obviously we're very close to consensus. So we use, we're a great partner of ours because we use our technology. And they are moving, I know they're moving, the idea is to continue to merge those kind of more and more together to kind of build this capability where Bezu and the go consensus quorum can continue to come together. So I think there's all, obviously that's on the roadmap for what we've heard. So the great value to the hyperledger community for that to have that kind of integration. Great. Thank you. Yeah. There's another question in the chat. Is the DoD mandating that its vendors use this blockchain network? So the DoD is continuing to research, obviously they're not the fastest adopters of the technology, but they continue to provide, build out specific solutions is what they're looking for. And I think eventually there'll be mandates for different blockchain networks. What we envision is that department of defense within Navy, Air Force, Marines, just like a lot of them have multiple different cloud, multi-cloud, there's going to be multi-watching. So multi-cloud, there's not, just like we've seen with Jedi, there's not going to be like, okay, one group's going to have, even in an open source world, is going to have one capability. So there's going to be multi-cloud capabilities. We have to have lots of collaboration. And we know that we think the Department of Commerce will have something, Department of Energy will have something, Treasury, we're seeing this with central bank currencies. So all these different things. And I think there will be mandates coming out. And, you know, Symmet change is agnostic. We are an agnostic platform. We just connect to different, we're an API layer. So we just utilize, we're not at the protocol level, we, what, you know, hyperledger fabric, figure out the protocol items, and we just connect and help, you know, build applications. So that's our, that's our mission to make it easy. Yeah. And I think it's safe to say that, you know, yeah, there's not going to mandate on one particular vendor or standard. There's all sorts of reasons to, many good reasons to not do that. You know, and Jeff can probably speak to this, what we can probably assume is that, you know, certainly interoperability. And that's, that could mean 100 different things. There's so many gradations of interoperability. But to the extent that there is some type of, you know, because then it goes to the spirit of kind of open solutions versus kind of wall gardens and closed solutions. So to the extent that there can be interoperability to some greater degree, one would think that that would be seen more favorably by this particular institution, you know, or any government institution. I do have to say there will be like STIG requirements, you know, these security requirements that have to be stood up containerized requirements. And a lot of that is the continuous authority to operate, authority to operate risk management framework, all that has to be done. We are, we are working very hard to be able to publish what we've done. We don't have all that information allowed to be shared, but we hope to publish that to the community. So everybody can now go, oh, this is how I do a STIG hyperledger fabric implementation, you know, whatnot. So that's, that's our goal is like to continue to give back to the community. We've done some updates on showing users how to do hyperledger EVM 2.1 installations and helping like writing scripts and making that a lot more manageable, different things like that. So we, we continue to provide that open source, you know, we as much as we can as a private company to commit back to the community. But this paper itself, please do take a look at it. The team put a tremendous amount of work into this and months and probably six months of work with a lot of goals and yeah. And some of the hardest was the approval. And Ian can speak to that. Well, if he wants to, if he had to do a lot of that approving and re-editing. So we're certainly on the gas pedal trying to get as much of this out as possible. So please do check out that paper because that was, that went through a lot of approvals to get it. And we're trying to, you know, shed a light and make as much of this public as we can for the community. Yeah, and say what we can, because it, we can't do it all. We need the whole tire community to implement the blockchain technology throughout the governments, because we believe that transparency and quality will bring about, you know, great innovation. And that's our, you know, one of our main mission is to, you know, just make this a very mass adoption kind of play. So yeah. Daniel, Alfonso has a question. Yeah. Alfonso, you can go ahead and unmute and ask your question. Hi. Hello, Alfonso. Alfonso, if you want to unmute, you can ask your question. Hmm? Maybe not. I don't have one. All right, so he just raised his hand. Excellent. Well, if anybody else has questions, we're at the top of the hour, close to the top of the hour. If anybody else questions for the Simba Chain team, can you let them know how they would go about getting in touch with you? Sure. You can contact us. You know, certainly you can reach out to the hyperleisure community. They can put, you know, Daniel, it can put you in touch with us. My email is, I'll put it on here. It's anjanroy at gmail.com, sorry, at SimbaChain.com. You can get me a Gmail as well, but SimbaChain.com. And I'm one of the hyperleisure liaisons here at SimbaChain. So you're welcome to reach out to me and I can put you in touch with the right person at SimbaChain that you can be speaking with. And certainly Daniela has, the rest of the community here has my contact information. And we talk all the time. So it's always great to speak with this community. It's like a great community here at Hyperleisure. There's no doubt about it. And our website has plenty of information, so you can get the contact with us. We have an intercom chat function too, so you can communicate right with one of our customer service representatives. Yeah. And you can go to Info at SimbaChain.com. You know, at SimbaChain, they'll contact us. Absolutely. I want to thank the SimbaChain team today for this presentation, for sharing the work. And very importantly, Joel just mentioned this, the contributions that SimbaChain has done back into the community, right? It's not just about using the code. It's about sharing the opportunity, you know, code and bugs and stuff like that. So we really appreciate your contributions to our open source community as well. So I want to thank everyone for attending today. Feel free to reach out to the SimbaChain team with questions or myself. And we're happy to connect you. This is an ongoing Hyperleisure in-depth, an hour with our members series. We aim to have two of these a month. Next month, we have Cripsy is going to be doing an hour around best practices and major obstacles for upgrading to Hyperleisure Fabric 2.2. And then the following webinar will be on August 18th with Provinci talking about verifiable credentials and how to bring students and employees back to school in respecting their privacy in the COVID era, which is obviously something that is top of mind for everyone nowadays. So once again, make sure that you check out the Global Forum. We do have some great content from our July Global Public Conference with lots of supply chain use cases as well as others to take a look at, public sector, etc. So please do look at those sessions that are available online. And as always, please get involved. There's lots of ways to get involved within our Hyperleisure community, the special interest groups, the working groups, the technical projects themselves, the meetup communities is strong, and we are starting to see some meetup communities getting together in person. So hopefully we'll be seeing you all in person as well at events and meetups around the globe. So once again, thank you for watching. This will be posted on YouTube, as well as on our website, and we'll provide additional details for everyone via email. So thanks again, and have a wonderful day. Thanks, everyone. Thanks, everybody. Thanks a lot. Bye-bye.