 Now we are live on LinkedIn and YouTube as well. Hello, good morning, good afternoon, or good evening, everybody joining us today, depending on where in the world you're joining us in from. And welcome to this hyperledger in-depth webinar with SpyDRA on low-code asset tokenization platform for enterprises. We're just gonna give everybody two or three more minutes to join and while we wait, I would encourage everybody to use the chat button and tell us where you're zooming in from. Hello, Adrian, and happy to have you here as well. Everyone, good morning, good afternoon, or good evening, depending on where in the world you are joining us in from. Hello to Atlanta, hello to India, to Brazil. Hello and welcome to this hyperledger in-depth webinar with SpyDRA Technologies about low-code asset tokenization platform for enterprises. We are delighted to share with you this hyperledger in-depth webinar. My name is Tomasz and I'm an ecosystem manager at the Hyperledger Foundation. Today, I will have the pleasure of taking you through some housekeeping and also introducing to our panelists. Now, if you join any of our other hyperledger in-depth webinars, you know that we have some housekeeping rules. So first of all, I would like to emphasize that all are welcome in our hyperledger community and we are striving to make a safe and welcoming environment for everybody. So please, to get more information, please visit our Viki on our website as well. So all of the hyperledger in-depth webinars are held under the Linux Foundation Antitrust Policy. And you can find our Antitrust Policy on our Viki and on our website as well. This session is being recorded and it will be available in the webinar library along with the slides and you will also be able to find it on our Hyperledger YouTube channel. Now, we encourage people to get to be active in these sessions and we would like to get these sessions as active as possible. So please use your raise the hand button to and I will unmute you and you can speak up and ask the question to our panelists. You can also use the Q&A box and this is also an option as well as the chat button. So for those of us joining us on YouTube and LinkedIn Live, you're also welcome to use the comments to ask any questions and we will relay them to our panelists at the end of the session. Now, without further ado, it's my pleasure to introduce Ashvat who is a co-founder of Spider Technologies and it will be presenting at today's webinar. Again, welcome everybody and glad to have you here. Ashvat, over to you. Thank you, Thomas and thank you everyone for joining the session today and taking some time out of your busy schedule. So quick introduction about myself. I'm Ashvat Bobindan. I'm one of the co-founders of Spider Technologies as Thomas mentioned. Before joining Spider, basically I have focused all of my career on in the security and identity area and eventually in blockchain and a lot of majority of that part, I was with Microsoft for almost 16 years working on cloud-scale technologies in security and identity initially and basically enabling a lot of customers or the group embrace some of those kind of technologies. And eventually I've been working on blockchain a lot more on the enterprise side of things, not the public blockchain, crypto or NFT side of things but basically enabling enterprises to use the blockchain technology to do various things. So let me quickly share my screen. I hope you can see the screen. Yes, looks good. Yeah, so a quick introduction about Spider as well. So at Spider what we do primarily is to basically our mission really is to make the adoption of enterprise blockchain technologies into different use cases in traditional industries like supply chain, banking, healthcare, insurance, so on and so forth. So as a technology where there are multiple organizations involved in a business process and there's data being exchanged between them, we all know that enterprise blockchain has a lot of use cases there which can be fulfilled. And that's where our focus is fundamentally to basically make that adoption easy and as part of that, we have developed a asset tokenization platform fundamentally too so that organizations can easily tokenize their existing assets on a blockchain platform. And as part of this, we have tried to develop a platform which is not very specific for only a particular use case, like we are not a supply chain solution per se or we are not a fintech solution per se which is using blockchain, but we have developed a platform which can be used by other organizations and integrated into their existing ecosystems. And our solution blockchain platform is fully currently based on a hyper ledger fabric as we are more focused on the enterprise or the private blockchain space. So as part of our journey, we are developing this platform, we have come across various use cases and tried to solve that in a generic manner that can be applied to all these different industries. So in this session, I'll cover some of these, how we went about building this platform and some of the learnings that we got from that and basically also show you how our platform works and how it can be used across various industries. So basically a quick, to start with a quick overview of asset tokenization, I think most of you would already know about asset tokenization, right? It's the whole process of representing physical or digital asset on a blockchain platform, right? The assets can be as can be digital, like a token, right? Which presents something of value or a loyalty point or it could actually be something like a real estate actually physical asset, like a real estate or equities or certificates and things like that or anything in a supply chain which is being tracked across its own life cycle, right? So, or it could be an intangible assets also, like copyrights, trademarks, intellectual property, so on and so forth. And the reason to tokenize assets on a blockchain could also be very different, right? Like if it's a physical asset, like a real estate, right? The reason that you might want to tokenize it is because you can then fractionalize it and then basically sell a fraction of that to different participants or different users thereby increasing liquidity. Or if it's a supply chain asset, right? Something which is moving across a supply chain, it could be to basically have a single source of truth for that data that is transparently shared across the participants, which can result in operational efficiencies and things like that, right? Or sometimes it could also be because you want to increase the reach of a particular asset specifically something that you're trading, right? Once it's on a trustless system and it can be traded across the globe without having to different participants having to rely on each other, right? That could be also another use cases. So there are different reasons why you might want to tokenize an asset. But at the end of the day, it's all about, you know, having a digital representation of that asset on the blockchain, right? Which then enables a lot of use cases. So if you look at specifically the enterprise space, right? And where you want to tokenize an asset or even have a digital representation or a digital twin of an asset on the chain and do something with it, right? There are at a very broad level, I would say there are three things that need to be done by any organization looking to do that, right? One is because we're talking about a close network, somebody will have to deploy and manage the entire blockchain network, right? So there's an infrastructure thing that has to be done, right? And specifically with blockchain, it becomes a bit complicated because there are different participants which are typically organizations in an enterprise scenario, right? So you have to bring all of these different organizations and their nodes which are running in different places onto one common, you know, network and it should have connectivity between them and everything should operate in a cohesive way, right? So there's an infrastructure part of it that has to be deployed. And then of course, once you have a blockchain network, let's say based on hyperledger fabric, you'll have to start writing smart contracts or code within the chain code within the blockchain network, right? Which does certain things. It could be as simple as, you know, creating assets and querying for assets from the blockchain network or it could be very complex as complex as enforcing a lot of business rules, right? Within the blockchain platform itself, as we all know, smart contracts are meant to basically enforce the business rules on chain so that they cannot be unilaterally changed by any of the participants in the network and everything is, there is a guarantee of execution of those rules within the blockchain itself, right? So you'll have to start writing code for that, right? And then the third thing is, of course, if you have a blockchain network and something which that network does, it cannot exist in isolation, right? And it cannot function on its own. So it has to be integrated with existing applications, like applications, like for example, if I'm talking about a supply chain, lot of the data already exists in an ERP system, right? That is where, you know, manufacturing data, shipping data, invoices, purchase order, everything that site today, right? Now, if that data is there and you want to put some of that data into the blockchain network, then you'll have to probably integrate your blockchain network with that ERP system or a custom application, it could be your, you know, things that customers are already using, right? So integration of applications is the next thing that somebody has to do, right? And SpyDri is trying to make all of these three processes very easy for a customer who want to use a enterprise blockchain network, right? So at a very high level, that is what we do, right? But then if I drill down a little bit deeper into it, right, what does it actually mean? So at a very basic level, what we provide is a managed blockchain network, which as I mentioned is fully based on Hyperlegia Fabric at this point of time. So the Fabric Network, as a customer, right? You can deploy the Fabric Network on SpyDRA Cloud. SpyDRA Cloud meaning, you know, there's a choice of deploying between AWS, our cloud, which is hosted on AWS, our cloud, which is on Azure at this point. And we also plan to support GCP going forward. And, you know, we also have, give you a choice of where to deploy the network, right? Or when I say the network, the nodes, which belong to the blockchain network, right? The order of nodes, the peer nodes, and so on and so forth, right? So they, as an organization, you can choose where it needs to be deployed when you're using our cloud or, you know, you have a choice of deploying the cloud, the network in the cloud of your choice or account that you bring, right? We call it bring your own cloud, but basically it means that you can bring your own AWS account, you can bring your own Azure subscription and the corresponding nodes that belong to your organization is deployed on that. And, you know, different organizations in one network can be on different clouds, different regions, and they are all from part of the same network. Customers can also deploy the nodes in an on-premises Kubernetes environment. That is also something that we support, right? But basically, you know, what we have seen is that when there are multiple organizations in a network, they are usually in different locations, in different, using different technologies, clouds. So, you know, a true distributed network, decentralized network would be really using different kinds of infrastructure. So that is something that we support and make it easy for customers to enable. And that's where we have done a lot of engineering to make that work best, because we think that that is how real networks actually function. And then, of course, on top of that, we have a, you know, a web application and management console, which can then be used to basically administer all of the blockchain network itself, like the nodes, the channels that are part of it, you know, deploy chain codes, so on and so forth, right? And basically, also invite other organizations to be part of the network and all of that. Some of these things I'll go into a little bit more detail going forward, but this is just, you know, all the different things that we provide as part of a platform. And the reason that we have provided some of these features is that, because, you know, we feel that these are some of the things which are really required for a lot of enterprises to actually get onto blockchain at a much faster pace, right? So we also provide, you know, key management functionalities where, you know, the block, there are a lot of keys and certificates which are involved, right? So we provide a vault on from our side, a hash account vault, or customers can bring their own vault where the correspond the keys for the network can reside and so on and so forth. It's a managed network, so it's monitored, you'll get alerts if something is going wrong. We have taken care of high availability and disaster recovery. So, you know, there's a concept of the nodes being in different availability zones. You can do disaster recovery across regions and so on and so forth. Apart from the Hyperledge Fabric Network, we also provide a private IPFS network which can be used to store the documents, right? Typically, that's how you would do, you would store documents in IPFS and then put the hash or the content identifier that you get from IPFS into the blockchain if you want to provide immutability to a document as such, right? But it's the private IPFS network, so it's not going to the public IPFS network and the documents are fully private and secured in general. So apart from the infrastructure things, right? What we also do is we also provide is a set of application level functionalities, right? Like we have an asset tokenization application which I will go into a little bit more detail of how we have designed that. But the asset tokenization application is basically meant to provide a lot of features which you would need in general for any asset tokenization use cases, right? Out of the box without writing any chain code or any code at all. So our solution is basically no code asset tokenization platform, right? Which means that we want enterprises to adopt blockchain technologies without really having to write too much blockchain-specific code, right? We also have a concept of on-chain workflows where, so the asset tokenization solution, right? Fundamentally what it provides is a way to easily create query, update assets and things like that, right? Basically manage the assets from the chain. But then apart from managing the assets, right? If you want to enforce any business rules, right? Typically you would end up writing chain code or smart contracts, right? So on-chain workflow is a concept where we have a UI-driven workflow designer using which you can actually model a lot of processes and business rules. And then those get purified into the blockchain and then it'll execute as per the workflow that design. So I'll show you how that works. But basically the whole idea is to, for customers not to have to write chain code to actually define the business rules on the blockchain or to actually even code smart contracts on the blockchain. We also have a concept of event listener that you all probably know that there are a lot of events which can be generated by the blockchain when transactions happen. There are transaction-level, block-level events, there's events that are generated from custom applications and so on and so forth, which any way you can subscribe to directly by hooking on to the block, on to Hyperjust Fabric. But we also provide a more easier way of subscribing to webhooks, websockets, webhooks and even queuing systems like Kafka, for example. We also provide field-level encryption. So this is something that we have engineered on top of Hyperjust Fabric where when you create an asset, you can basically say that either the entire asset or some fields within the asset need to be encrypted during storage so that even, as we all know, the ledger and the world state are synchronized across all the participants in a blockchain network, which means that anybody who has access to the underlying ledger or the world state can basically read anything in the blockchain. So if you want to really prevent that and also want to say that only certain participants should have access to certain information and also to satisfy general regulatory requirements around encryption at rest, right? We also provide a way to actually encrypt the asset or fields within an asset on the blockchain so that it's actually encrypted on storage and only folks who have been given access can actually decrypt and query it back. And of course there's reporting and analytics which come on top of all of this. So that's everything in the blockchain or the ledger, right? But then as I was saying, the third thing that anyone would have to do is basically integrate the blockchain into existing systems. So that's where we have a rest API interface. Of course, you can use the Fabric SDK and connect directly to the blockchain, peer nodes, order nodes also and do whatever you need to do. But we provide a more easier rest API interface to either access the asset management functionalities on the blockchain or query, do any transactions in your custom code also that you have deployed. There's a GraphQL API interface which is, so as you would probably know that querying something from the blockchain is not as simple as querying a database, you'll normally query based on a key on the key that is in the blockchain, right? Either the full key or partial key, right? But then we have basically have a GraphQL API layer using which you can query based on any block, any field of an asset in the blockchain. Plus we have some inbuilt integrations to popular ERP systems like SAP, Microsoft Dynamics and we also have connectors to Zapier. Zapier as if you know is a workflow automation platform that connects to various other systems, right? It connects to almost 4,000 to 5,000 different systems. So we have the Spydera platform APIs also are surfaced as a connector in Zapier, which means that then you can basically using Zapier, you can connect to lot of other systems like databases and various other applications and even things like flat files like CSV and Excel files and then basically either sync data from these systems to the Spydera blockchain or vice versa when something happens from in the Spydera blockchain, the information can go back to these systems also. We also have some developer tools specifically, we have a plugin for Visual Studio Code which is an open source plugin which you can use to develop chain code from Visual Studio Code and debug while it's developing. So I'll talk about that also a bit going forward. So that's how we have created a generic platform, which can be used to solve, to implement, use cases for different industries, right? Okay, so delving into some of the specifics for these, the first thing is the management console itself, right? So I've been talking about it a bit but in more detail, right? You can easily deploy the network on board different organizations into the network easily, right? So you can create different organizations or basically invite others as well to join the network. We provide all the management functionalities to manage channels, nodes, chain codes, all of that. We also deploy an inbuilt certificate authority within Hyperlegia Fabric, right? Every entity requires a certificate which is their identity, right? So we have a, we deploy a certificate authority by default and you can basically use that to create certificates for all the participants. For some of the nodes and stuff which requires certificates out of the box, any way gets certificates when their provision automatically so you don't have to worry about it. But for anything else, if you want for your own users or for your own applications, you can use a certificate authority to get a certificate and then do transactions. Private IPFS network I already talked about. You can deploy things multi-region, multi-cloud, or on-premises. Everything that we deploy, of course depends on the tier that you're going towards. So if you, you know, so we have a concept of a small, medium or large tier. So medium and large tier, right? Has more than one nodes running by default, right? Of course you can adjust the nodes anytime but by default, if there are more than one nodes running, they are deployed in different availability zones so that, you know, there's high availability. If one of the zone goes down, there's still a peer that is still serving the request. Similarly, all of us, if there are multiple, they go into different availability zones and things like that. And we can do disaster recovery across multiple regions in case an entire region goes away. We have focused a lot because blockchain itself is a, you know, technology which is inherently based on cryptography, right? And one of the reasons for using that is, you know, to make data immutable and there's a lot of security concepts inbuilt into it. So security is something that we have focused from day one right from how the various components are isolated, how the data is isolated to all the way to different features that you can use to build an additional security into the system, right? Like for example, right? Ours is a SAS multi-tenant system, right? Which means that different customers can come and create different networks on the platform, right? Which means that, you know, there is a need for isolation for different tenants or the different networks that come on our side, right? So every tenant basically gets their own set of nodes which is completely logically isolated into their own Kubernetes cluster, for example. And we have a concept of a shared and a dedicated mode in a dedicated mode, right? You get a completely different Kubernetes cluster. You get a completely different virtual network, VPC, AWS or a virtual network in Azure. So everything is isolated right from the layer of network, networking to the layer of infrastructure and the data storage, right? In a shared model, some of the networking and infrastructure might be shared but still there is logical isolation. But everybody gets their own logical space within the platform. And everybody gets their own off-chain debut also. So there are certain settings and, you know, what not that are required for the web application or the management consultant function. They're all again, I swear into a completely off-chain DB that we maintain per network. And more importantly, everyone, every organization, not even a network, but every organization gets their own vault. And we have multiple options for that. Even if you don't do anything, by default, you get a completely different hash or vault for every organization. But then you can also say that, okay, I don't want to use a vault provided by Spydera because the keys will live there then and it's the keys to the kingdom, literally, right? So you can say that, okay, as an organization, I want to bring my own vault, right? Which can be a hashicot vault that you own in your own infrastructure or it could be Azure QALT, AWS Secrets Manager, KMS, combination of that. And then, you know, all the key material basically lives there, right? So there's isolation at that level. You can bring your own CA certificate. So, you know, when I was talking about the certificate authority, right? Certificate authority has a root CA, right? So by default, if you don't do anything, we create a self-signed root certificate for every organization and the CA associated with that by default. But then you can say that you don't want to use a self-signed certificate created by Spydera. You can bring your own certificate from your own certificate authority, which will become sort of an intermediate certificate authority for that particular CA. And then all certificates issued by that CA will roll up to your root certificate, right? That you own or you bring from. So those kinds of options are also there. We also support enterprise single sign-on, which means that, you know, by default, when you come to our platform, you'll have to create an account on Spydera. But then you can also say that as an organization, you already have your own single sign-on system, like Octa, Azure AD, or whatever it is, right? And we can basically do single sign-on and you can log in with your existing credentials, enterprise credentials onto our platform. We are also ASA 27,001 certified, and we are currently undergoing the SOC2 type 2 audit, which takes a little bit of time, but we hope to get it done in the next few months and complete it. Okay, so that was mostly around the infrastructure part, right? Now, if you come to the... So the question is, right, okay, so infrastructure is there, but then, you know, there are a lot of other, you know, organizations also, which provide you an infrastructure and you can also, you know, deploy it yourself as well, right? But then after that, what after that, right? So that's where we have an inbuilt asset organization application, right? So the, if at a very fundamental level, the intent of the asset organization application is to sort of make the usage of a blockchain as simple as how you would use a traditional database. Let's say you have, you create a MySQL DB, right? Then what you'll get is definitely the infrastructure, but then you also get a query language with it, right? Using which you can then start immediately creating tables, you know, defining relationship, you know, configuring things there and then start putting data into the tables, right? Inserting data and then querying for data, all of that. You get literally out of the box, right? In blockchain, any blockchain and, you know, hyperlegious fabric also, that's not how it works, right? Even if you want to create an asset, get an asset from the chain, you have to write code. You have to write smart contract, right? So that is, fundamentally, that is what it does. It tries to avoid. Plus, of course, there's a lot of other functionalities on top of it, which I'll come to, but think of it this way, right? Let's say you have a blockchain deployed, but then now you want to start creating assets, right? So the asset organization application, first of all, allows you to define different assets that you want to manage on the chain, like in this particular case, right? It's an automated supply chain where I want to track the car which is being manufactured and the different parts that a car is made up of through the entire supply chain, let's say, right? And there is a quality inspection that is done. I want to track the output of that, things like that. So in the asset organization application, you can create these different types of assets, first of all. And then you can say that, okay, the car is dependent on engine because, you know, car is made up of an engine, it is made up of a chassis and it is made up of some number of tires, right? So you can define these kinds of relationships, right? And then what you can also do is you can define start defining permissions so that you can say that, okay, who can create a car asset on the chain? Who can read it? Who can update it and so on and so forth, right? And then you get a lot of credit operations on top of it. When you query, right? We have done a lot of engineering wherein when you query a car asset, you can basically get the car asset and the referenced asset data also with it. You can also, you know, there's a lot of in-built methods that are available around ownership transfers, approvals, you know, transferring assets between different organizations or participants, approvals for doing that and things like that, right? All of this without writing any chain code, right? And then of course you support all the, so that was a general asset, right? But when we say asset, it's just any JSON data here. But we also support specific asset types, right? Like ER620, 721, 1155 token standards to support. So basically, you know, you can deploy, you can directly start creating tokens, different kinds of tokens. And then we support main transfer, burn the typical functions. We also support some additional functions like, you know, swapping between tokens, converting between tokens, even between tokens than NFTs, tokenizing NFTs into tokenizing NFTs means meaning, for example, there's a real estate NFT, right? And you want to mint certain amount of tokens out of it to fractionalize it. And then, you know, basically sell it to different participants, right? So fractionalizing an NFT we support out of the box. And then a lot of granular access control, like similar to the asset access control I was talking about, but this is more granular, like who can burn transfer, who can do what kind of functions there, right? So we support assets which are, you know, confirmed to these standards also, or generally assets which don't confirm to the standards also, any JSON that you can bring into the chain, right? I touched upon the concept of workflows a bit briefly, but let me, you know, delving into that a bit more. Basically, it's, you know, giving you the ability to write, to have a smart contract deployed on the blockchain, which does certain actions, but without having to write code, right? Essentially. So we are, you know, there's a concept of different triggers that you can define. Like you can say that when, when like in this particular example, right? Let's say it's a example of a parametric insurance, right? Where insurance is given by an insurance provider, which is linked to the amount of rainfall that happens in a particular area. So if the rainfall exceeds more than a specific, specific millimeter, then the insurance has to be paid out, right? So basically all of this can be configured. This rule, right? Which says that if the rainfall exceeds for more than this in a particular location, then the corresponding insurance need to be paid out. This rule can actually be deployed on our spiral platform without writing a single line of code, right? And the workflow will look something like that, right? When a weather data is updated on the chain. So that's the trigger, right? What you can do is say get all the insurance assets on the chain, which are linked to this weather data. So I was talking about the reference part, right? So that's where the reference becomes meaningful. You can say get me all the assets which are linked to this insure, to this weather data, all the insurance. And then for each of the insurance, if the rainfall, current rainfall is more than what is in the insurance, then create a payment request and raise an event, right? So I'll get going to a little bit more in an actual demo to show you how this works. But basically it's a visual workflow interface using which you can actually, you know, define a lot of business rules and processes that need to be followed, which can change the state of various assets on the blockchain, right? So that was the part where, you know, we have done some engineering to make it easy for you to store assets on the chain, query for it, and then, you know, configure rules on how they can be transformed or how they interact with each other, right? Now coming to the integration part, as I said, we have a rest API, but that's simply the starting point, right? Any developer would probably understand how to invoke rest API. You can do synchronously or synchronously and all that. We take care of load balancing across multiple peers and all of that, so you're not really connecting to a particular peer, unlike how you would do, you know, if you're directly connecting to a peer, but you can take care of all that complexity. You can basically enroll different certificates and, you know, invoke the rest APIs under the context of different organizations or different entities for which you have basically enrolled the certificates. You can also create, you know, event listeners, which I was saying, as I was saying, to listen to the events over different other protocols, like, you know, web sockets or an event stream in general, right? I also touched upon GraphQL briefly. So GraphQL is basically a query language, I mean, it's sort of a query language over HTTP, right? That is widely used in other places. So we have created a GraphQL-based interface using which you can actually query for data, chain code data in Hyperledge Fabric. And we don't actually give you the query results from an off-chain DB, which is what a lot of, you know, other implementations do. What we do is that we have a middleware, which basically takes the GraphQL language, converts it into Couch TV queries. So, and then we actually query the world state in Couch TV and then return you the query directly from the world state, right? So there's no separate off-chain that is involved and we support a lot of different combinations, they're complex queries, sorting aggregation group by page nation and a lot of things. And the last thing that I was talking about in terms of integration is specific integration, right? In ZPR, for example, right? In this particular UI interface, you can see that, you know, when a new row is updated in a Google Sheet, for example, right? Then the action. So this is also a workflow interface that has a similar concept of a trigger and action, but this is in ZPR, right? The workflow that I was talking about in Spyrise executes on the chain, but this is mostly for integration outside with external systems, right? So in this case, when a row is inserted into Excel Sheet, corresponding asset is created in Spyra, right? And again, all of this just by saying which Google Sheet, which are columns to pick and then which column maps to which attribute on the asset that your asset, which is on the blockchain, right? Or the HyperJFabric ledger. So just by doing that configuration, whenever something is inserted there, it will start appearing in the ledger. Now, this is a very powerful feature where you can actually integrate with a lot of things, right? Like dynamics of ERP systems, databases like MySQL, you can say that when something is inserted into a table, a row is inserted in a table in MySQL, then automatically create that asset in the blockchain or vice versa, right? When something is updated or changed on the blockchain, then change the corresponding thing on MySQL table, for example, right? And then I was talking about the HyperJFabric debugger, right? Which is basically a debug plugin for Visual Studio Code so that when you write chain code from within Visual Studio Code, right? What you can simply do is, you know, just like you would normally debug any code, right? When you launch the HyperJFabric debugger, basically it'll create a fabric network, first of all, for you. So normally if you might be aware to, in order to write and test chain code, you need to have a fabric network first of all, right? Which is deployed, and then you have to deploy the chain code onto it, do the chain code lifecycle commands, and then only you'll be able to execute it. And then also, you know, if you have to inspect the, you know, how the code is performing or, you know, what actually was executing, you'll have to spit out log entries and then look at that and all that, right? So with the HyperJFabric debugger, when you debug code, first of all, you don't need a separate fabric network already deployed. The plugin does that for you. And then it deploys the chain code onto the, that particular network that the plugin has created. And then, you know, you can actually, then the code executes within Visual Studio, the chain code actually executes within Visual Studio and you can actually create breakpoints and then the breakpoints will be hit. You can look at the variables, the stack trace, everything, right, that are normal, using a normal debugger, whatever you can do, you can do with that, right? So that is to, is the, is the development of the chain code. And this plugin has actually been widely used. We almost have 12 plus, 12 K plus developers using this across 120 countries at this time, right? So it's seeing some good traction. Okay, so now I'll actually show you the platform that I was talking about, right? And I'll take a simple demo here, right? So let's talk about an automotive supply chain, right? So there will be multiple participants in the automotive supply chain, right? Like there'll be tier one, tier two suppliers, for example, there'll be a factory where the manufacturing process happens and then there'll be downstream distributors, dealers and then service centers to service the, service the vehicle after that and all that, right? But let's say, you know, out of that, we are just picking suppliers, which are supplying some raw materials or, you know, some parts which will be used to manufacture the final vehicle, right? And then there's a logistics partner which will do all the shipment. And then there is a factory, OEM, which is where the car is actually being manufactured. So now if you want to trace the life cycle of the car, right, from where the products, the parts are sourced from to the point where it is assembled into the final car and then, you know, shipped to a dealer via a logistics provider, right? Then some of the assets, right? Again, to simplify, some of the assets that you would want to maintain on the chain could be, you know, the raw material, the actual metal, the steel, aluminum or whatever was used to manufacture some of the things like chases of the car, the engine tire, right? The parts that come into the car. And then, you know, you'll probably have to basically drag the actual vehicle as an asset in the, on the blockchain and then also maybe some quality control parameters, right? Now, these different participants might be using different systems automatically, right? Like some of this information might be offline in Excel files, the supplier, some of the suppliers may already have ERP systems. The OEM factory also has an ERP system by some of this data already resides. So that is the thing that you have to get onto the blockchain, first of all. And then there might be some certain rules that you want to enforce, right? Just to take an example here, right? When a quality control vehicle inspection happens, let's say the tire is found to be defective, right? Then I want to know that, okay, the tire came in a lot of tires. The 100 tires came together, right? So which all vehicles tire from this lot has been fitted into. And then we'll mark all of those vehicles as defective and also the entire tire lot is defective. And then we'll either have to investigate or send it back to the supplier where it came from, right? So that's a rule that I want to enforce onto the blockchain, right? So that is there, you know, traditionally you will end up writing a smart contract, but that's fair. Our workflow engine basically can be helpful to actually develop some of that. So let me go quickly to the platform. So this is our Spydera platform. So this is a Dev environment, but basically you can go to Spydera.app and get started from there, which will take you to the production platform that we have, right? So everything revolves around creating a network, right? So as you can see, I already have a network here, which is based on Hyperledge Fabric and we use the latest version 2.5, which is the LTS. And some of the features that I was talking about, right? Inviting other members to be part of the organizations, managing infrastructure in terms of channels, nodes, deploying, you know, applications. You can deploy custom chain code and the asset organization pre-configured chain code that I was talking about, right? It is something that we have and that can also be deployed, right? So if I go to the deployed applications here, right? There are a couple of deployed applications here for different scenarios. So the vehicle automotive supply chain, right? This is the application specifically handling that scenario. So if I go into the settings of this, right? You can basically see that there are various asset types that have been defined, which is what I was talking about earlier also. And, you know, basically you can define the different asset types, the references between them, like in this particular case, right? A car has a field called body.tire.it body and inside the tire and ID, which actually maps to a tire. For example, right? I'll show you the JSON data for, as you're saying, right? It can be, you can input any JSON, an asset is just any JSON object that you can bring yourself, right? This is how my car asset looks like, right? It has a car ID, some information about the model color. And then there is a body section, which has a tire as an object, which is an array that has different tires, right? So within the body, tire and ID is where the tire maps, which tire is being used by this car is mentioned, right? So that's the reference that I've made in here, right? And then there's a concept of permissions, right? Where different permissions, who can do what like supplier in this case, supplies the engine raw material, tire, et cetera. That's why they can manage that. The factory can manage the car, who can create, create, update, all of that you can do at a granular level. And then these are the REST APIs and GraphQL APIs that I was talking about, right? Which can be used to manage the assets, the approvals, ownership transfer, et cetera, that I was talking about. Even things like, you know, getting a history of the entire asset, so on and so forth. And then there is the GraphQL and workflow part. So let me just show you some of these quickly. For example, right? Creating a car is basically submitting a port request to the asset endpoint with the asset type is car and the data, which has the actual data about the car, right? Which is a JSON object. If I get a car object, right? Like if I get this from the chain. You can see that, you know, when the car data is returned, the chassis ID was so and so. But we actually also expand the entire chassis object itself and give you back. This is, you know, this is another feature where, you know, you don't have to query multiple times on the blockchain to get referenced objects, right? So this can go to multiple levels, right? So chassis is made up of raw material, whose ID is M1. So if I look at the car object, right? All that it has is chassis ID was so and so. That's all it has, right? But when I get the car back, you also know that, okay, how did the chassis actually look like? What material was used within it? And so on and so forth, right? So everything is sort of expanded. We also provide inbuilt APIs to get the entire history, right? In this case, I'm getting the history of car one. So you will basically get a list of things that happened on that car, right? Like car was updated, something was done. If I scroll all the way to the bottom, this is when the car was created, so on and so forth, right? So there are five records here because something happened five times on this car, right? So we had inbuilt APIs for all of this. There are inbuilt GraphQL APIs, like for example, right? If I want to find out, let's say a tire from IDT1 was defective, right? So I want to find out all the cars where this tire was used, right? So as we saw, the tire ID is mentioned inside body, inside tire, in an array. So we are saying within the array, any object where this element is matched, you get me that. So this is, as you can see, it's a very extensive query, right? That you can write. And then if you do this, it will tell you that, okay, there are three cars. And in GraphQL, you can also say that which fields need to be returned. Don't return me the entire object, but just return me these fields. So you only get these car IDs here. These are the three car IDs where the defective tire lot was fitted, right? So now, let's say, you know, my requirement is that now we know, right, tires that came from P1 lot were fitted in these three tires, right? But then I want to enforce this on the chain, saying that, you know, whenever a tire is marked as defective, find all the cars and then mark them as defective also, right? So that's a workflow or a rule that you want to code as a smart contract on the blockchain, let's say, right? So that's where we have a concept of workflows, right? That I was talking about. So if in this particular network, I have a workflow called defective cars. If I go into that, right? What it does is that there's a trigger which says that on create asset, when vehicle inspection is done and the vehicle inspection asset is created on the chain, the vehicle inspection asset, the way it looks like is something like this, right? It's a vehicle inspection asset. It was done for a particular, it has its own ID, but it has done for a particular car and it'll say that, okay, engine status is okay, chassis status is okay. For the tire, it is not telling me whether the status is okay or not. What it is telling me is whether the, what is the measured load rating, right? So load rating is something which is a property of a tire. If I look at the tire, right? Tire object has a load rating. In this case, for T1, it is 91, right? But when the vehicle inspection happened, what was measured was 89, which is lesser than 91. So my rule says that if the measured load rating is less than the load rating of the tire, actual tire, that the supplier said it should be, then it is defective, right? So my workflow, if I look at this here, right? The way it works is when a vehicle inspection report is created, asset is created, get the tire. So vehicle inspection has a tire ID, right? So get the tire, so this is a variable coming from the vehicle inspection asset itself because the actual ID of the tire is in this particular location. So based on that, get the tire. Check if the tire is defective and how do you check that by comparing the measured load rating to the load rating of the actual tire, right? Oops, sorry, refreshed. Okay, and then, you know, what we are doing is we are reading all, we are getting cars, all the cars where this particular tire was used. So if you see, this is the same GraphQL query that I was showing you, right? So GraphQL query is also supported in the workflow so that you can actually get a list of defective cars here. Then what we are doing is for each car that is an output of this, we are seeing update the car with the property of status with the value of defective, right? Literally that's what the workflow says. So let's just quickly see this in action, right? As we already know, the cars that are defective are C1, C3 and C5, right? So let me use GraphQL itself first of all to get these three cars, right? And I'll get the car ID status and ledger metadata. So ledger metadata is, you know, something that we have as an inbuilt attribute. So there are certain metadata that we associate with every asset that is created on the chain, right? You know, who created it, when it was created, when it was last updated. And specifically, if a workflow updates it, there is a updated by workflow section which will tell you that. So yeah, that's what we are getting here, right? So if I get this now, right? It'll say that this car ID C1 status is assembled, right? Let me just put C4 also, which is actually not defective but just to see what we get, right? So right now all four cars, the status is assembled, right? Now let me just submit a vehicle inspection report where we are in, which is for car, the report for is for car C1 and the load rating is so-and-so, so-and-so, right? So when I submit it, the transaction is done, right? But let me go and see the car status of the cars now, right? If I see something has changed, C1 has been marked as defective automatically and it tells me that it has been marked defective by this particular workflow and the activity, this particular activity within that. So C1, C3 was marked as defective. C1 was not marked as defective because it doesn't have tire from T1 lot but C5 was also marked as defective. So basically, you know, that's the concept of workflows literally, right? Where without writing code, you want to do these kinds of things, right? Define a process, some rules end-to-end, right? So yeah, that's pretty much what the whole platform is all about. So currently we are working with almost, you know, around 50, 50 plus customers, customers and partners, right? In different stages. So we have quite a few applications which are in production, some which are in POC, some which we are partnering with other product companies where they are developing a full stack solution, for example, in automotive supply chain, but using our blockchain solution to back in for that, right? So just quickly talk about a couple of case studies where we have implemented the solution in a big scale, right? So Raymond is one of those customers. Raymond is basically a fabric retailer in India, right? It's actually the biggest fabric retailer in India with 1400 stores across India, right? But they had a huge problem of, you know, two things, two problems, right? Counterfeit, detection of, counterfeit goods through the entire supply chain and then detecting them. And then also they didn't have much visibility of how the product is traveling across the entire supply chain today, right? So for that, we actually use Pyra blockchain to tokenize all of their fabric material, looms basically, on the blockchain platform right from the manufacturing all the way to the retailer and to the end customer where end customers can actually scan the QR code and see what was the journey of the product, right? So at Raymond, we have actually almost tokenized 30 billion plus assets on the chain and the potential savings, right? So the loss that it was of suffering from counterfeit was around $200 million in that range, right? And of course, not everything can be prevented just by blockchain, but they're seeing good success in terms of, you know, detecting the counterfeit goods which is estimated to save potentially 121 million USD per year. We also are working with the production application. We have worked with a large hospital chain. It's the second largest hospital chain in India based on the number of bed count. So this is mostly around, you know, streamlining the claim processing, insurance claim processing process, right? Which we all know sometimes can be very cumbersome. So in this particular solution, right? The hospital third party administrator TPA and one of the insurers is currently on the chain, right? And most of the claim related information including actual information and also documents are tokenized on the sidera blockchain and that has reduced the claim settlement time from almost 12 hours to one hour, right? Because of the transparent flow of information. One thing that we have done interesting in this particular implementation is the field level encryption part, right? So right now, as I mentioned only one of the insurer is onboard, that has been onboard by the TPA. But the TPA wants to bring in other insurers also onto the chain. But then there's a problem, right? If you are putting insurance and patient related information on the chain, then other insurers can also read that, right? Who is part of the chain? That's where we have actually done field level encryption so that only authorized insurance providers who have been given access on a particular asset can only read the actual information within that, right? So that's something that we have done. The third interesting case study is for a B2B, you know, auto parts company which is basically providing auto parts to garages, right? And there's a concern by the end user whether, you know, because these are not OEM service centers, right? They are third-party garages. So there's a concern whether the parts that are being used in the vehicle are genuine or not, right? So for that, again, the entire auto parts, right? From sourcing from the actual supplier to the customer is dragged on the blockchain and then the customers can scan if you are code and then get a certificate of authenticity, basically. So that's another place where we have, you know, implemented a good solution at a larger scale. So that's all really that I wanted to talk about today. Thanks everyone for joining. And as I mentioned, right? You can actually go to spider.app and try out our platform. We have, we provide $400 free credit for you to get started and explore the platform. And if you have any feedback, you can reach out to us on the links that are mentioned here. Yeah, thank you very much, Ashfaat. And I see that there are some questions that weren't answered, but please see this slide that Ashfaat was just sharing and feel free to reach out to spider team. I think Rokit wanted to answer some of the questions and Alfonso was also asking if you would be able to present this in Spanish. But unfortunately we are out of time. So feel free to reach out to the spider team or reach out to us at the hyperledger as well. As I mentioned, this webinar recording will be available on our webinar library. So you can also return there and you will get this data and you can just reach out to them then. But Ashfaat, thank you so much for this great presentation. I saw in the chat that people were really enjoying it and you managed to cover a lot in these 60 minutes. Now, just to wrap it up, I would like to also invite everybody present here to join our hyperledger Discord where we have a lot of real time interaction as well. And we do have a lot of upcoming webinars coming up very soon. So we have an exciting webinar with Infosys on driving process transformation in public services with blockchain along with the speakers from Rhode Island and AWS. And please visit our events page to register there. Again, thank you everybody for joining. Thank you to our panelists, Ashfaat, great presentation and we hope to see you again soon. Thank you. Thank you, everyone.