 Thank you very much, John, appreciate it. And are you going to do it? Tommy, I'm just going to go ahead and take it off here. Everyone, thanks for doing the hyper ledger Denver meetup group today. Really appreciate your attendance here. Today we have the pleasure of having Tommy Cook see from Simba chain, who's joining us. And he's a military veteran from the Marines with 30 years of experience in the it field. And he's also an AWS cloud professional. An AI champion trainer. And he's really been working in, you know, blockchain and leading the training for Simba chain for a number of years. And they've done a lot of great innovative work. And they have some great contracts in place. So I'm going to turn it over to Tommy just to talk a little bit more about his background and the background of Simba chain and what we're going to go through today regarding rapid deployment using Simba quick start. So Tommy, over to you. Awesome. Thank you so much, John. And thanks for inviting me to come and talk to your group today. So to probably give you guys an idea of really where Simba is layered in on any architect stack. You probably need to just kind of maybe even take a look at maybe the progression of the technology and, and how the technology has taken form. And generally speaking, when I, when I think about this concept, you know, and I, sorry, I was teaching another class this morning, but when I think about this concept, I always think about somewhere here, it's right there. The three P's, right? People processes and platform, right? And so what we at Simba chain are, our focus is, is that we want to focus in on the process and, and, and define structures for data that, that is going to be relatively standardized for maybe what the data governance should be. What data points do we need to collect about this transaction? Because our concept is, is that the internet is changing, right? The internet is changing from an internet of information to an internet of value. And that value is going to be stored based on our ability to capture that process and capture it accurately, whether that be through an ERC 20 standard as a utility, or if that be like a 721 more of a validation and a claim, right? And so, so we can start to look at the ability to create different types of architectures. And so with that, we want to stay as platform, agnostic as possible, give you the ability as the professional to define what your workflow processes should look like, and the data points that you're going to be using, and then just leverage the strengths of your people, right? Give them the tools that they need in order to be successful, right? And so we're concentrated on outcomes. And that's what we want to do is we want to create the appropriate outcomes. And so with that, at Simba, and thanks for the great introduction, just a quick introduction. I've been working in IT for a really long time, and I was teaching PeopleSoft. I taught PeopleSoft for over 20 years. And when I saw blockchain, I dropped everything and ran to this technology. And if you've ever worked in an ERP type environment, you probably understand that there's massive amounts of data that you have to trust somebody of holding it. And maybe that's inside of the hospital, and you don't necessarily trust that particular hospital network or that clinic, but they're reporting their data. And so Hyperledger is a really great adoption here because it's more of a private blockchain. It's leveraging the technology. It's leveraging your ability to define your consensus mechanisms and define how you're going to have that chain off-chain data, but still allowing you the opportunity to not necessarily make it publicly available like an Ethereum public chain. And so we like to give the users that opportunity to make that choice. They want to use an EVM on a Hyperledger fabric with borough, and that's what we try to do. But ultimately what we're looking at is we're trying to adopt these characteristics, right? These features and characteristics that we just don't have in our current workflow. We don't have decentralization and distributed data. We don't have immutability in anything, really, unless it's on a blockchain. We don't have cryptographic primitives built into our workflows. It's something that's bolted on later, but it's not something that's built in. And with the blockchain, with the appropriate smart contracts, we can start to bake that into our code. And I like to say, with the right structuring, we can start to bake the security in instead of taking it off. And that gives us the ability to start to also look to the actors, right? And their level of pseudo anonymity, autonomy in the workflows to be self-governed, and then have transparency in those transactions, and not really trust anyone. Just trust that the transactions are stateful and represent the state of the assets. And so with that, the big problem that we run into is if we have to learn how to write chain code in Hyperledger, that becomes somewhat of a lift. If we have to learn Solidity or Viper or IPFS, that's somewhat of a lift. And we want to make the functional user powerful still, but also give them the tools that allows them to communicate well with the developers, and also give the developers the tools that they need in order to unlock the value that might be already inside of their network, right? So how do they look to their data lake and figure out how to create data stores and things like that, right? So we kind of try to give them that tooling as well. But we try to remove all these barriers. We don't want to have rigid infrastructures and expensive proof of concepts. We want to be able to iterate, figure out if something works and if it doesn't, then try something different. And so we do that through our REST-based APIs that we generate. If you've ever used Hyperledger's sandbox that they used to have, I forgot what it was called, but that is very similar to that, right? And so we'll generate those REST-based APIs. You can still hit those REST-based APIs, see if it works for your workflows or not. And if it doesn't, then you can just change the iteration and re-mock it up. And so a lot of times we'll call that fail fast, but basically we're just reiterating to find the solution that works. More or less, it's, you know, the... Not Einstein, the guy that did the electricity. Gosh, why am I drawing a blank? Anyway, it's his money. Yeah, Tesla. Tesla created electricity. Who was the other guy? The guy that stole his invention? Edison. Edison, yes, the Edison man. Thank you very much, John. I don't know why I was drawing a blank on Edison, but yeah, Edison definitely would just re-iterate, right? If something didn't work, he would fail fast and try something different. So that's kind of what we're doing on our front end. We're creating the REST-based APIs that can be built into any existing infrastructure, see if that blockchain data point would create value. And if it doesn't, then try something different, right? So with that, you know, when we think of our storage, that's our ledger. Our consensus mechanism is in essence our network and gossip and whisper protocols are what we use there. And then the smart contract is, of course, our compute or execution environment. And so when we comparatively look to that, compared to what we have today in Web 2, Web 2 is still the Internet of Information, but what we've done is we've siloed power. And so by siloing that power, we've created the ability to even de-platform presidents of nation states, right? And we've seen that happen. And so what we need to do with Web 3 is we need to create more of a semantic web where it's an Internet of Value and not necessarily an Internet of Information. So now we know we can do secure communications. So in those secure communications, can we exchange datasets that represent value? And that's going to be extremely disruptive, I think. And that's where the Internet of Value comes into play. And so that disruption is all occurring here on the back end, right? We're just moving our database away so that we're not using that crud infrastructure. We're getting rid of the update and delete functionality. And we're moving to a dataset where we define structure and then we define content. Structure is defined probably more in like a smart contract infrastructure, maybe even in a YAML file that could define what Kubernetes clusters that you need to have, what code base you need to be running. And that is ephemeral, right? It just always uses that same structural state. But the context of the data and the assets that are being used within that structure, that needs to be immutable, right? And so how do we create that? Well, that's the immutable ledger. That's the blockchain. And so the blockchain is going to have immutable ledger of state to track value. And then we can also have structure that is defining the ephemeral context of the transactions that need to go through that structure. And if we look at it this way, I come from a PeopleSoft background, but I think of it from like ERP, it's kind of the same thing that we did with ERP. We would just look at workflows and we'd say, okay, what data points do we need to keep track of here? What has value? Where are we going to keep track of it? What's the relationships involved? And then we could start creating these ERD diagrams and really creating an infrastructure that shows you the relationships of data. But what if that relationship of data could be bundled and then packaged and verified and then used to provide value, right? Provide value to who? The user, right? So the user doesn't contribute their data to the infrastructure. The user just contributes their data as part of the utility of the infrastructure and then they own their data as a signed owner, right? And so now they have a wallet that represents all of their military record or a wallet that represents their education or a wallet that represents their medical records. And we're starting to see that slowly get adopted with Anthem and UnitedHealthcare and so on and so forth. So the important thing is is we're giving ownership of data back to the user. And with that, that is going to, in essence, what I call it, the spark that's really going to kick off this revolution. We just talked about Edison, so let's go back to Edison again. Let's think about the electrical revolution. We used Morse codes about 50 years before the Chicago World's Fair and are close to it. So electricity, even though it was available and highly available, I mean, it was adopted, but it just didn't create mass adoption until you could light up your living room, right? The same thing applies to blockchain. Blockchain's been around for a long time. The technology's around in Bitcoin and hash cash and things like that that we've meshed together, but we haven't unlocked the ability to actually see that light bulb moment that's just going to kick off that we call it the fourth industrial revolution or Web3. But in essence, it's going to be that spark that generates a lot of interest and wants people to start using the tech. We're seeing that in DeFi, but when we start to see that the same data points that we're using for finance can be used in order to track value that we consider value as humans, we're going to be able to unlock a whole lot, a whole new asset class that I think that is going to be available and it's just going to create a whole new revolution. So with that being said... Let me ask you one question before you move on from that because I think Tim brought up a great point. Is he had asked about... You talked about structure and state and what he was asking about was about speed and I think... Transactional performance. So maybe you can just touch base on that before we move on to the next stage here. Yeah, let's talk about that real quick. So transaction throughput is all scalability. So scalability... We call it the tri limit in blockchain. You got decentralization, security and scalability and transaction throughput or scalability. And so you pick two. And so with that being said, if you are using Hyperledger, then you don't necessarily have decentralization. So you can start to get those TPSs and things like that. So it really just depends on how you define your consensus mechanisms that you want to use in your network. We'll define how quickly you can push those transactions through. We also have an integration with consensus quorum, which in essence, depending on the size of your node, you can kind of size that to infinitely. So for TPS, but now you have chosen, decentralization is not going to be part of your model. So therefore you have massive scalability. So again, when you look at that tri lemma, that's really where you make those decision points. But we, we had some of the changes provided is the tooling and, you know, you can pick what path you want to take based on that. Does that help? Yeah, okay. Yeah, no, that's great, Tommy. I just want to make sure that, you know, some of these questions as they go along, I'd rather just weigh in on them. So go ahead, move on to your next stage, but thanks for addressing that. Uh-huh. So what we try to do is we just want to make it simple. We do want to make it like, like the question that just came in, we want to still make it scalable, but I'm not talking about scalable from a transaction standpoint. I'm talking about scalable from, um, you can build your solution one time and it's portable, right? Uh, because it's an EVM smart contract and that EVM smart contract, uh, has integrations with multiple, uh, blockchains that are built on top, including hyper ledger and, uh, uh, we have several integrations. So, so we'll look at those when we do the demo here in just a second. So what we do though, is what we try to try to define is define a method for you to bring in input data, define the data points like I had mentioned before, that you think is going to provide value. The value that it provides, you know, it's just metadata, metadata, creating the good keyword today, metaverse, right? We're all hearing that, but we're just trying to bring that data in, defining those data points, knowing the province where the data comes from, and then that data can get bundled and then provide either utility or functionality. And then that in essence is unlocking a lot of this Mary of, of the data points digitally with the asset that exists in the real world and which in essence creates a metaverse, right? If you're not familiar with this concept, I mean, think of the first time if you've ever played Pokemon go, or if you've ever seen that concept, that's probably the first time any of us ever really dealt with a metaverse, right? We had a, a screen in front of us, but when we were looking at the screen, it represented something digitally that was supposed to be in the real world that really wasn't there. But if I've interacted with it with the screen, I could get it from the real world. Kind of weird, huh? Well, that's, that's an, that's a metaverse, right? You're, you're marrying the real world with the digital world. And you're, you're making that leap. I like to say that when we think about the internet and the progression of the internet, you know, the first version of the internet was something that you, you would go to, it was a destination. You know, when I was in the Marine Corps, I would have to go to my squadron in order to get online. I couldn't get online unless I was at the squadron, right? So, you know, now just get our pocket. We're communicating over the internet. So it's no longer a destination point is just ubiquitous. It's just there and available. So that's in essence, what we're doing is we're, we're making this digital data just there and available. And you can just, you can easily verify it, whether it be knowing where your, your stake came from or whether it be verifying that you're over a certain age when you walk into an, a drinking establishment. So, so there's all kinds of things that we can do with this, but we're looking at this as what we call off-chain data. And then we're using our smart contract to designer to generate these APIs so that you can generate these smart contracts. And then you can also subscribe to them. So you can have a web hook or an SMS text or an email notification based on the state change that occurred with that asset. And then you, we also can, we can subscribe based on those subscriptions. We can build a caching model that will allow you then to generate, you know, dashboards and things like that about certain data points that you're keeping an eye on. And we have SDKs for Firebase, for, for VB, IOS. And so, you know, whatever, whatever your flavor of usages, you know, we try to build an integration point for you with our software development kits. Anyway, so, so that's kind of our model. And then basically with this model is it allows you to kind of generate this smart contract that's going to be your inputs from whatever these separate data points are, right? So these separate actors that are reporting data points, they're just bringing it in through your smart contract. And then you're defining them as assets and transactions through relationships. Once you've done that, then you can deploy this, like I said, on pretty much any blockchain as long as it understands EVM model. And of course, we use borough for that on fabric. And then with that, then we generate the API for you to be able to hit those data endpoints. But kind of the beauty of our SEPT tool, and we won't look at that today. We're going to only be looking at our Quickstart tool, which is only kind of the functional side. But if you look at the technical side, because it seems like some of you might have been technical users, especially in our first, first during the conversation. But you guys will really love this because we're giving you a GraphQL, we're giving you Neo4j, all the tools that you're going to need to basically look at your data lake and then start to build your data storage, right? To start to find out, okay, where do I have leakage? You know, when you start to do your top-down model in GraphQL, we can run it through those models and start to find problems that you have. And you're doing that all internally with our tools before you start to expose it to the REST API that you had built previously, right? So basically what you're doing is, is you're using these tools to kind of do your own Kafka, right? You're matchmaking. You're matchmaking. What do they want? What do I have internally? And once you're doing that, once you can kind of match make that and marry that relationship, now you're able to really start to unlock the value of some of your data lakes, right? And so I think that that's where a lot of enterprises get stuck on this, is they just don't understand where the value is coming from. Well, it's coming from the data that you just afraid to let anybody have access to you because you just, it's metadata, but you're just afraid of letting, letting it be validated and owned. So if we can package it in such a way, maybe we can unlock the value. So with that, you know, again, this kind of just talking about the graph model, and we, you know, it will query existing REST-based endpoints, generate the ABI for it, and then we can use that, you know, to kind of match up data points and stuff like that. So all kinds of fun stuff that you can do here on the back end. And then our smart contract designer, I'm just going to go ahead and bust out of here, and we're going to go ahead and start our demo. And I want to show you how this tool works. So, and all of you that are here today, you can go out to app.SymbaChain.com. And Riley Faye is another representative. You'll see her there in the chat window. She's another representative from Symba. She's here to kind of support me. But she is, she is definitely somebody that would be able to help you get started on a project, on some kind of an idea. Even, you know, another thing that we use this tool for is just to educate people, because sometimes just understanding the tech, there's just such a big lift. People just don't understand it, right? And so they just shy away from it. But a lot of times because of the simplicity of our tool, we get a lot of traction in the educational institutions. And of course, Riley can help you with that. If that's an idea you have. But basically what this tool does is once you get logged in and create your account, there's kind of three distinct areas. There's an area for your wallet, there's an area for your smart contract, and there's an area for your API. That's it. Okay, so as, as developers, you probably understand that if you're not a developer, or if you're just a functional user, let me explain. Your wallet is where you're keeping your identity for signing transactions, right? So anytime that you have to sign a transaction, you're going to see that the wallet is going to be signed. So basically, the wallet has the keys that sign those transactions. So inside of the head and shoulders area, you will see your blockchain wallet section, and we have three different walls. Well, the remote wallet is our hyper ledger borough standard. Right. And so I've went ahead and created the hyper ledger borough. And these conform to the hyper ledger borough wallet. And we also, of course, have, we have five standard for Bitcoin. And then we have the Ethereum wallet, which is the Ethereum standard for wallet. So we have those three different wallet standards that you can use just to generate your wallet for generating the smart contracts. Right. And the cool thing is if you're using like Ethereum, we also provide links to faucets and stuff like that with, with hyper ledger. Don't have to worry about any of that. We're just generating the identity and creating the keys. Right. So you'll be able to use these keys. And then to sign transactions. So if I wanted to generate another wallet, I just put in my name, John's wallet. And create it. And there we go. Now John has a wall. There we go. So, and then a very simple again, but powerful and powerful how, because now if I come over here to my solidity area, and since we're using borough, we can go ahead and we can create a smart contract that will just be solidity compatible and then just deploy it on borough. So I'll show you that here, but basically, as I mentioned before, we're concentrating on assets and state changes. So an asset is something that has value. So, you know, my car, maybe so car. And then what kind of things do you going to have about the car? Well, you're going to have maybe a string, which will be maybe the Venn number. The Venn, you know, the color, maybe. And notice that one of the things that we try to do here is even though this is a functional user tool, we try to teach the users like data minimization and good structuring of data. So I educate the users on what a boolean is, on what a string is, an address of course just means that it's a calling smart contractor coming from a particular EOS account, that type of thing. So the integers, we have unsigned and signed integers. I briefly just talk about, you know, using an integer for anything that would have a negative value unsigned for anything that only has positive values and then also date and times. And then bytes would of course be anything where you're doing machine to machine communication. So if you don't need to have any kind of human interaction, just passing data. Last time we can just do that through byte and get the get the attention done without any ambiguity. So anyway, so that teaches good data minimization just by instructing the user on what these data types are. And then they get to define their tuples or the key value pairs for not only the asset, but also for the transaction. So if you make a car sale, right, then you're just selling. So the with the sale date, what kinds of things are going to be important to be maintaining state on an immutable ledger? Well, maybe we need to know the buyer, buyer, right? So maybe the buyer ID, maybe the sale time. Date time. So we can start to think about all this data. And then notice here, I have this thing. This is off change storage. Well, off change storage is really amazing because what that does is it just takes the inputs, runs it through shot 256. And then puts the, the digest on chain. So the bundle hash is just the digest the, the 256 bit hash of whatever the inputs were. And then you can use that to validate state of whatever the, the claim is. So, you know, when we think optimistic rollup, you know, we're being optimistic that what's being rolled up and put on chain is valid and they're not lying about it. Well, this is basically what an optimistic role of it's right. We're not running it through any zero knowledge proofs or anything. We're just doing optimistic declarations. So this gets you kind of in that direction, right? Most things will be ZK starts it at some point, but optimistic is probably the first step to get there. And so this is, this gives us the ability to kind of create that functionality. Anyway, so that's that. And then once we've done this, then we just create a relationship and say, Hey, okay. Well, the car is going to have a sale. And then there's that and said behind the scenes, you know, it's just generating this really generic code. You guys, if you're a programmer, you're going to probably laugh, but it's, yeah, it's really generic, but it works, right? It's a very rough structure of what that input should look like. So think of it like this, you know, sandwich complexity. We're just generating the input tuples. And then we'll put the complexity in the, in the smart contracts that we're going to be calling after that. So, so that's kind of the, the model that we look to here. And so at that point, let me go ahead and actually, let's go back to this here. So at that point, you know, this is kind of what this does for us, right? It's pretty powerful, but it's a tool for that functional user to be able to put their intentions in place of what metadata points that they want to put on chain in order to unlock value from the data. That's it. That's all they're doing. And so how could I make that more complicated? Well, let's go look at our smart contracts and see if we can find one that's maybe a little more smart, a little more complicated and see what that looks like. So here we have this one. It's called our coffee tutorial. And if you can imagine, um, tracking coffee from the producer or the farm, all the way through the co-op to the sheller, to the batch, to the roaster, to the warehouse. Um, and then to your cup, right? And so we're keeping track of this and putting in those data points, right? Like, so I can just come in here. I can see the data points, the two roaster data points from roaster data points, the observations, the measurements that are being occurred, any off chain data, you know, and we're generating all of this logic. If I come over here and I look, I'm generating all this logic and as a business professional, I'm probably going to know that supply chain flow better than any developer that I talked to. So I have the ability to structure what I want and hand off to my developer, not just a, just a set of functional requirements, but I'm actually giving them a proof of concept that is REST based endpoints that they can hit and look at the data points that I'm looking for. And, and so, I mean, this is incredibly powerful, you know, I mean, even though, you know, it seems pretty simple, you know, you're giving that business professional the ability to unlock their intentions and, and, and provide the handoff to the technical team that defines those intentions much more granularly than ever before. And so with that, we now have the ability to just generate a REST based API on top of it, because here's the thing. I don't want to just hand that off to the developer and now the developers got to look through this, this code and figure out what's going on. I want the user to play with it. I want them to go through that Einstein. I keep picking on Einstein, man. I wanted to go, go through Edison. There we go. I want them to go through that Edison workflow and see if this works or not. If it doesn't, then let's know really, really fast. Let's, let's fail fast. We've heard that, hear that a lot, but let's figure out what works and what doesn't. And if it doesn't work, then we'll just try a different iteration, try different data points in order to collect what we need from a business professional. Once we figure that out, then we're ready to go talk to the tech team, but let's not, let's not be so quick to move to hardcore development until we have a relatively good idea of what our intentions are. Right. And that's what we're trying to do here. And so with this, I can come in and I could come and I can go say, okay, I'm going to build this on hyper ledger burrow. And then we're going to just do this on burrow. And what about the off chain data? Because remember we said we're going to have those rollups that we're going to be optimistic about, put that data on chain. Well, if that's going to be off chain traditionally with this tool, we just put it on IPFS. And if we decide to use our full tool set, we can put it in any blob store, right? It can be an Azure, it can be an S3, because remember it's just that s, it's just that house of the inputs, right? Whatever the data point is, that binary large object input, we just run it through a hash, put the digest on chain. That's it. And so as long as you have a URI to that, to that data, data set, you can, you can access it, right? And that's what we get with IPFS. So anyway, that's all we're doing here. And then we have our smart contracts. So we say, okay, well, what logic do you want to do? Do you want to do the card? Do you want to do the coffee? What do you want to do? Well, we'll do the coffee. And okay, cool. So what kind of API do you want to create? Well, I'm going to create Riley's API. So, and I bet you there's a rack. She does these demos all the time. So I'm not going to do a Riley. We'll do a Tommy, Tommy. We'll do a bunch of funny numbers after it. So, Tommy, bunch of funny numbers after it. There we go. So, um, so that makes our unique endpoint created out here at this secure endpoint inside of Simba that is exposing your smart contract logic. Okay. That's it. We got to go ahead and sign it with, we'll sign it with John's wallet. John can deploy this out on fabric. It's going to post it, deploy it, finish it up. And that's it. It's out there. Now here. You'll notice. What we have now is it's out here on hyper ledger burrow. It's got IPFS is my off chain data. If I look at my app info. It shows, you know, all this raw information. And then if I want to manage somebody's ability to hit those endpoints, I can come in here and generate API keys. So, you know, um, if there's a data provider, um, Dave data. So Dave's the data provider. Uh, and, uh, and so then we also maybe we have another consumer. Uh, so, uh, Connie, the consumer. Uh, and so now we got Dave and Connie in here. And so we could just then somehow securely give Connie and Dave their API keys. Then when Dave needs to access the app. He just puts that in his host header. Okay. Well, Dave doesn't have do that. Well, okay. That's okay. No big deal. Um, if he didn't know how to do that in his host header, then he can just come in here and look and play with our swagger tool and it'll show them. It's pretty simple. We just come in here and it's, if you've ever used a simple API tool, it's swagger, but we just say, okay, well, here's, here's Dave's key. Just come in here, put it in here. And then we can just give him a little lesson on how to do post setters and gatters on all those, those methods that we've exposed. Right. So, you know, if you just do a, a getter on a batch code, there's not anything in there right now, but the cool thing about this is when we use this tool, of course it's going to go ahead and format all of our curl requests. So whenever we have a form or, um, you know, something in our form that's going to be requesting data from the blockchain, it's going to have to send this curl request out to this endpoint and retrieve the data. Well, this is doing it for us. It's just generating that curl request for us. And then we can just integrate this with our components or anything else that we want to do. So, you know, this is what we're going to do right now. Um, So we try to give us the, you know, the front end tools for developing kind of that front end structure and integrating it with your existing infrastructure. But hey, you know, this is, you know, this is the functional user Fred, Fred functional. So he, he doesn't know how to do that yet. So what else do we get? Well, we also give him a simple method call, right? So, you know, we know that the smart contract. Uh, has been exposed, you know, and it's got exposed for setters and gatters. So here's just all the setters for all those methods that we created in the logic. And then I can just come in, put in my data points and then call it. And then I can, then I'll see the, you know, all the, the raw logic over here. So I see, you know, the, the transaction blooms, the, the receipts and all that kind of fun stuff. The important thing to remember though, is that is that what we're trying to do is we're trying to give. The ability to use this tool, API rest-based API tool, easy to use the ability to interact with components, simple setters and gatters, most friend and developers know how to do that. And so, you know, if you got a people soft, let's just pick on people soft for a minute. And I need to report all the supply chain logistics information, um, uh, from my, from my, um, SCM product for my, so my supply chain management product. Uh, and I need to report all of that for this particular business unit that happens to be this clinic that I think I have some nefarious actors over there. I can start to track that better and put it on a blockchain, right? So those nefarious actors can't change the data. If it does, it'll, it'll show up and I can start to, start to do things and build infrastructures around this. And so, so you can, you know, if you already have the infrastructure like SAP or people soft or something like that, and you just need to have a REST based endpoint to do a setter and a getter against, then this is a pretty cool tool to start structuring that up. Right. So, especially when you start thinking about the enterprise capabilities of hyper ledger and then, you know, the ability for this to generate those REST based APIs and do quick iterations of, of tools building. I think the combination of those three things, um, you can probably do a lot of, a lot of help for an enterprise and helping them find out what data points that they have internally about their customers that customers might want to have ownership of and provide value and even utility for our system. So when we start thinking about rewards points and we start thinking about, um, democratizing capital product, uh, uh, purchases, um, you know, those are two easy areas of, of focus, you know, so let's just kind of talk about that. Um, you know, capital purchases, you know, when we start to think about CAPEX versus OPEX, one of the reasons that we don't make these, you know, purchase of the big car or whatever is because, uh, because it's too much of a, of an expense for that object. Right. Well, I'll give a great, a great story and we'll open it up for questions. Um, first time I ever rented a bicycle. I rented a bicycle in Okinawa, Japan, and I was in the Marine Corps and, um, I was 1992. And I had a secret clearance and I gave Hawk, the guy that owned the, the bicycle replace, uh, my father's address, my address, my social security number, my unit, my MOS, uh, all the information that he felt comfortable that he needed in order to rent me a United States Marine bicycle in Okinawa, Japan. He was a Japanese national. I probably violated national security because I gave him more information than he needed with smart contracts, data minimization, data blinding mechanisms. And we're all probably familiar with that. We can start to define mechanisms, you know, one way door mechanisms and all these kinds of things that we can do with cryptography that I can do that same interaction and mitigate his risk as well as mine. By the time I left Japan, I could go into Hawk's building and take any bike I wanted. He'd say, pay me when you get back. I didn't have to show him anything because it was all about building trust. What do blockchains do? They mitigate trust, right? What is a big barrier for business transactions is trust and blockchains help us to do that. I'll give you a great example. We've all seen the Lime Scooters setting around the cities. Well, that Lime Scooter does the same thing that Hawk did for me. It provides transportation to anybody that wants to use it. And all I have to do is provide my information to their smart contract through their application and mitigate the risk. If I own that data and I could do that in a blinded way, I could create a decentralized platform that would allow me to get that same resource, mitigate their risk, and also mine. And I don't have all of those pain points. I don't have Hawk keeping my personal information in his file folder that somebody could break in and steal it. Not that he was a bad actor, but I don't necessarily trust his security, right? So when we start thinking about data and we start thinking about how to protect data, it's going to be new ways. And blockchains are just a tool. And they're a tool to get there. So I'm going to open that up for questions. And hopefully you guys enjoyed the lecture and hopefully you enjoyed my demo and leave it to you guys. Yeah, no, that was a great demo. Tommy and we have some questions coming through. One of the things I'm going to ask you about first, before we jump in the questions is you have this great easy to use tool. And you talked about your outreach to the educational community. Is there any way for the attendees on the call here to get access to that tool just in a demo mode so they can go ahead and learn about Simba chain and try that out. Absolutely. 100%. And as a matter of fact, I will put the link in the chat window for you. This is at Simba chain.com. And you can actually use this tool for free. The only limit is that we'll limit to you to the number of transactions and the number of smart contracts that you can create. You'll need to get one of our subscription models. If you want to get something a little more enterprise related, but if you just want to get started and just start mocking some stuff up, you can certainly use our free version. And if you do decide you want to maybe put this into your curriculum and start to educate. We even have high school students that were able to build solutions out of this. And we have some pretty cool stories on our, on our website where some high school students were able to leverage this technology and build some really cool stuff with NFTs and things like that. So, so anyway. But yeah, you can certainly get started with that link in the chat window. And Riley will certainly help you with the, with any questions that you might have as far as sales and stuff. Yeah. Yeah, go ahead. Riley, jump on in. I was just going to say also put in a link to a tutorial we have where you can, it walks you through how to set up a free account and build an application. Perfect. Yeah. And I know that, you know, Simon chain really has a nice interface and easy to use. And it's a good introduction demo for people who just want to see how the platform works. So one question we had in here, Tommy was. Yeah. So one of the things that I wanted to ask is. Louisa asked about giving an asset to a new wallet. I know you went through some of the transactional stuff, but maybe you can just kind of address her question around this. And Louisa, if you want to ask her question directly, feel free to come off mute. Yeah, I think I understand the question. We, from our wallet interface, it's, it's generally just web three standard. So if you wanted to attach a wallet interface for the front side of the wallet, if you wanted to attach that in our set tool, we don't have that in this quick start. So the quick start is just a web three hot wallet. It doesn't really have ownership mechanisms and transfer mechanisms, other than just the keys and having ownership of the keys. Right. But there's no built in wallet functionality with this tool, other than just key management. That's it. So if you were to build an application that was going to transfer assets, then you could import the asset into the, the, you know, the import, the very first smart contract, and then you could have a second smart contract that would be responsible for that transfer. And so you could just, like I said, build it in that sandwich model. As long as you define who the, who what all the state changes needed to be for the transfer of the asset. So that's it. Hopefully that makes sense. Yeah, that's great. The other question we have is from Mike. He wants to know, you know, if they're in 2.0 is moving to proof of stake. And I know we talked a lot about hyper ledger borough today, but is that going to have any effect on your service offerings going forward? Yeah, you know, we're, we're keeping a close eye on, on really the EVM. That's what we watch closely. And when the EVM has standards that change, we can form to that. With the consensus mechanism. That really is just how do we come to that conclusion mechanism? So, you know, when I, when I usually compare proof of stake versus proof of work, you know, proof of work is like everybody's playing bingo proof of stake is everybody is trying to build a road together. You know, proof of stake is we're trying to see who can, who's the best and who can win the, who can win the random game of chance. And proof of work is let's trust that everybody's going to work in a combined effort, but verify that there's no bad actors by looking at everybody else's work. And so I kind of call that the trust, but verify or maybe the Ronald Reagan model, but it doesn't really change the mechanisms. When I, when I said earlier, it doesn't really change the way the EVM works. So as long as we still kind of look at the EVM and the logic of the EVM, we should be fine. It's an abstract at a different level. So when they change the consensus mechanism, it just means that we're going to have to change state quicker. No big deal. We can do that. So I think it'll be fine. Yeah. Okay, perfect. Another question we have is from Alex. And it sounds like he's got quite a big data set. He's got two million records a month. So he wants to know how that will process through Simba chain. If he wants to run it on Simba chain. And Alex, feel free to come off mute if you want to add to that question. Yeah, yeah. So that's a pretty cool question because, because I'll just answer that as more of a cloud architect. And not necessarily a blockchain architect. So what I would do is if you're, if you're processing those transactions, that would be internal. I would be, I would do that. And that would be in my optimistic rollup. And really I would just look at velocity and how I would need to handle the velocity of those transactions. So I would do that with things like, you know, as an AWS guy, I would be used like DynamoDB and those types of things to, to track state. But then, you know, once we have that signature of that state and we want to report it, whatever, whatever that interval needs to be and whatever those data points need to be, that's what you're going to be reporting through your smart contract. So, so since you have one actor, that one actor is only reporting the, that state information based on the velocity that they need to have that recording. And so I would really probably want to look more at the transaction model and what's being recorded, what the velocity is of it, you know, because like, like for instance, when we do things for like race cars, I mean, like, Holy cow, I got to record all these things like right now. And it's like 10,000 data points that are coming in in two seconds. Or if I'm, you know, recording information about, you know, a dam and the velocity of water and the quality of water that's going through that dam, that's a little bit different data point is a little bit different velocity, right. So again, it really, I would silo it down into wherever your data stores are. And then look at the data points that need to be reported and then figure out what the velocity of those need to be. And I would guess that's probably not at that same level of two million per second or whatever you have. Yeah. Okay. And then the Vika has a question about, I know you guys have had a lot of success in the military. I want to talk a little bit about what successes you've had in the healthcare space. I wish we had more. But I will say that I've had some success in some training. We personally at Simba chain, we've worked on a few initiatives, but we don't have anything publicly available from a healthcare sense standpoint, but I will say that if you go to the blockchain training alliance, which is one of the leaders in providing blockchain certifications, they have a three day course on blockchain healthcare and I authored that course. So I identified various different areas within healthcare, things like owning your own medical data, things like tracking and tracing the actual health, health equipment, which is under what's called CFR part 11. I look at HIPAA and GDPR regulations and how we can conform to those regulations and still have the right to be forgotten and still maintain some of that data on a blockchain. So we look at a lot of standards within healthcare. There is a plethora of pain points. I'm of the opinion that at some point in your life, there will be a piece of data that will be more important than any other data that you have. And that's your healthcare data. And the fact that you don't have full visibility into all of that information and have a full portfolio of that data and readily available for you to manage. I think that's a travesty. And I hope that we can fix that problem. And I really feel like that there's a lot of opportunities there. So if you have some ideas, we are certainly open to have those discussions with you. And we'd love to talk to you about it. Perfect. And then James has a great question here for you. He's talking about different data cadences and they all need to fit in the same ledger. And James, if you want to come off mute and ask your question, that'd be great. So basically, I think he's looking at James. Yeah. So, um, when I did work with the state of Colorado underneath for the blockchain work, we realized the telecom infrastructure. So the white quote, quote, global wifi is not as strong as it needs to be. And actually I've even seen this in oil and gas. So we know that there's variable data cadences and they still have to either fit retroactively or sequentially into the chain. How do you rectify that problem? That's probably a little bit outside the scope of my, of my capabilities. Honestly, I'm not a, I'm not a wifi guy. Um, but it sounds like basically what it sounds like is just having bit creep basically in, in, in your inputs. Um, is that accurate? I don't know. I'm one of the sales people. Uh, I come from a technical and sales standpoint. But when you're, when you're looking at it, I mean, you look at what IBM and what they've done, when they've taken, it's almost, they almost did an RFID when they moved a yogurt throughout Turkey, like Turkey to Egypt or something like that. So I mean, you're going to, you're going to be in places where you're not getting connection. You're going to have plenty of dead spots. But even, and you may record it, but then you have to do it retroactively because when you're looking at the hyper ledger, the sequential, the sequential nature and the date and the time post, when it comes down to the data mark is incredibly important. Yeah. So it's not going to be a good example of one that we kind of work with, with this. Um, there's a, there's a thing called beef chain. It's in Wyoming. Um, and so basically. Yeah. Yeah. Yeah. So, you know, Tyler. Yeah. So anyway, they're no longer, they're no longer really around, are they? They're kind of struggling. Uh, I talked to Tyler about it last, what we were there, what a month ago with Riley, uh, in Wyoming. Yeah. Yeah. It seems like, I mean, they're, uh, they're, they're doing different things and they're making, they're, I think they're probably making more of an ADA, uh, or Cardano approach with it. But yeah. Um, but anyway, the point is is that they're doing the same similar concept. They're, they were collecting through the IRD device that was in the cow, right? They would collect the identity and then that identity would interface with the feed trough and, and then feed the cow basically, uh, whatever that identity should have, right? So they're, they're portions for that day. Um, and so what they've been able to do is, is if they have certain data points, like for instance, um, the collection of how many steps that, that cow has taken. Well, that can't be collected in that IRD device, right? That IRD device can only collect like the location that it is in, within that field. So it depends on the IOT and all. Yeah. I mean, if they have. Create a local bridge basically is what we have. Right. Right. So we just, we were basically doing a local collection bridge, which is going to be your proxy collection. And a lot of times we'll do that either in, like in this case, we'll do it in the, in, in, in the, in the barn or in the, you know, in the feature off area, it'll have that wifi, uh, collection point that's then collecting all that data from those individual IRD readers from each one of the cattle that are in the, in the field. Um, but, but then, uh, we don't manage the, um, you know, the individual devices, uh, in the field. We just manage them locally from that collection device, that proxy. And then from that proxy, you can use things like Laura Wan, right? So with Laura Wan, um, you can just report state, right? So if, if you don't have to report the entire dataset and you only have to report the hash, then you can just send the digest up as through Laura Wan. And it's a very small data packet. And so even though you're sending it through satellite and it doesn't necessarily have to be 5g, it can even be low, low bandwidth. There's a lot, there's a lot of 2g out there. Yeah. Yeah. I know the food industry. So. Yep. I, you're close. You're close. What you're saying? Yeah, I was trying. Yeah. You probably know better than I do. So I was trying to explain your own industry. Yeah. Because just like for an example, they're going to, there's other IoT devices that actually measure a cow's temperature. So like for an example, people don't buy, some people don't buy beef in the summertime, especially if you're looking at the rate planes, because of the temperature variances. And the reason I'm bringing up tear temperature variances. Cows will get sick like that and you'll have death loss. And when you're looking at there's beef chain, which is trying to do certified cows versus general feed, feed yards where there's more money in it. When you're looking at those temperature variances, you want to get ahead of them quickly. And if there's even that lag, that could mean a difference between. Yeah. Yeah. Yeah. Incredible probability and losing everything too. Yeah. So yeah, I mean, that's kind of where it needs to be because you have to, sometimes I have to have that granular level quickly and be able to create a data mark throughout. And I think, you know, honestly, like a lot of that stuff could be, like I said, it could be optimistic, right? So we could pray, we could create those rules. And as long as that's just part of your, part of your governance, then you could just, you know, you could put that into like an AWS quick start or something. You know, that quick start could be what you would launch and buy the devices and then, you know, you have a smart farm or whatever. Okay. So what I want to tell you is we're coming up at the top of the hour here. Tommy, if you're okay taking a few more questions, I'd like to go ahead and extend beyond. But one question I want to ask. Yeah, I can probably take one more question, but I do have another appointment that starts in like, it starts at five after. So I got about a five minute break. Okay. I'm just going to jump right into. Chen has a question here that I think is highly relevant to everyone on the call. So he teaches a blockchain class at Purdue Northwest. Is it okay for him to have each student sign up for a free account and work through the tutorials as class assignments? That's his question. I'm going to punt to my co co worker who can probably address that better than I. So I appreciate your time today guys and have a great afternoon. Thank you so much, Tommy. Take care. Yeah, this is awesome. Yeah. Yeah. So to answer your question, Chen, you can definitely use the free version of our tool. However, it will limit the students on how many transactions they'll be able to make and how many applications they'll be able to make as well. So a lot of universities have been leaning towards our pro version. And usually for the education sector, we do have different discounts based on the needs of the university itself. And then also how many students are going to be using the tool. That's a great question though. Okay, everyone. Well, I really appreciate your time this morning and. Riley, did you post your email in the chat in case anyone has any follow up questions? Yes, I am going to right now. That would be perfect. After she up there. Rather already got it done. Okay. Thanks everyone for joining today. And I hope you have a wonderful rest of your day. And we look forward to having you join the next webinar that we host. Thanks. Thank you guys so much. Thank you, John. Yep. Have a great day. You as well. Bye.