Okay let's get started. So my name is Aaron Morton. I've been involved in the Cassandra project since the middle of 2010 and I've spent my professional career since the beginning of 2011 just focusing on Cassandra. We're at data stacks now and what I want to talk today is about how we made a JSON retrieval API. So there are other, let's get this out of the, let's get this clear. There are other document based databases out there that have set some standards and some of that is around usability and we would like to see how we can be a bit more usable for people in the Node.js community. So today we're going to talk about the requirements of what we were trying to do and try to understand how the JSON data model works so we can map that over to these two features that are the future of Cassandra. Secondary indexes and transactions for it sounds pretty weird. I've been doing this since 2010. Cassandra isn't big on secondary indexes and transactions but if you're just in this room listening to Scott from Apple talk about the future of transactions and secondary indexes then we'll go and look at how we can do this now with our data model of storing it and how we have to deal with the updates. So our goal here was to make something that a Node.js developer would expect when they're storing data. Back in 2005 when they lived in London, Honda had this advertising campaign for launching their diesel cars called hate something change something. So in the spirit of hate something change something we're going to go learn about the JSON data model and how we can make Cassandra deal with it and on that pathway here's what's important functionality is more important than performance we will get to performance performance will be good enough and we will make it better. If there's something hard to do and it makes Cassandra and CQL better then we should really put in the effort if it's hard and we had to work out what that Node.js developer was looking for we don't have a clue we don't have any Node.js developers in Cassandra using Cassandra. So we partnered with this project called Mongoose.js it's an object document mapper on NPM and to say it's popular is an understatement gets about 1.8 to 2 million downloads a week GitHub claims there's 3.8 million dependent repos out there using it and Valeri Kapov the author and maintainer is a great guy and we worked with him to understand what is the back end someone writing Node.js is looking for. All right into the data model learning about JSON data model well it looks pretty simple I've got a map I've got names I've got values they have a type number and strings but there's only one type of number so one and 48.8 are the same data type that's kind of weird there's a null but the null is not typed it's an untyped null kind of like a Python null so maybe I could just put this into a table because we're coming from Cassandra there's tables and things this looks all easy now I'm going to add on an array so I've got an array of things that look like numbers maybe they could be anything not just numbers in there so if I talk about this in a table perspective I could have a cql list or something like that to hold an array but I don't know what's in the array my example here are just numbers okay to add a bit more complexity we could put a sub-object into our JSON document here so address points to an object that object has other things in it okay bit harder if I was doing this in a table mapping maybe I could have another table for the sub-object or I could use a cql map to store the sub-object it's getting harder and then when we try to go across documents it just gets crazy so in the document on the left the age is a number 48.8 and in the document on the right the age is a string so which is it is age a number of a string well it's it's there's no rules you've got this situation of of some things but what did we learn so a document or a JSON object has a number of fields in it those fields are identified by a name that name has one or more parts to it address dot suburb those fields have data types they could either be a scalar type with some basic types and null is a type or they could be compound data types and you've got objects and arrays and you've got an unnamed implicit object at the root like the document and across documents this is kind of polymorphic ish I know across two documents they've both got a field called address one of them is a string and one of them is an object all I know is that there's there are type value next up how do people think about being able to pull this data out and again there are other examples in the industry of how people think about this one of it is uh jason path I don't think jason path is very easy to understand this is a typical sort of query uh it looks pretty easy go and find one document where the filter where the name equals I guess aren't easy I could add to this so now my filter clause is two operations I'm going to guess they're joined with an and and for age I've got uh not just equals I've got some type of operation I've defined add a little bit more complexity now I've got four operations running against in this filter uh they each have a path that they're talking about that field name and there's a couple of comparison operations one looks like an existence operation so does the is human field exist in the document and another is an array operation find me documents where fab numbers is an array of size three so the complexity there is growing and now I get to the next annoying part all right so on the left go and find documents where age is equal to the number 48 and on the right go and find documents where age is equal to the string 48 which one do you want do you want me to treat it as a number or a string do some learning again our filtering has a number of expressions those expressions can either be logical or comparison expressions they are basic logical expressions such as and and or our comparison expressions would point to a path and we say what's the operation could be a comparison equal to greater than biological operation you can do element operations such as does the element exist find me all the documents that have the is human field I don't care what value it is and there can be operations on arrays which are matching the contents of the array finding arrays that have array finding documents where the array contains one thing or finding things where the arrays of a specific size operations like that and then this polymorphism ish type thing that json does we're going to use the expression to tell us what type we should be locking in on so if you say equals 48 the number I'm going to go find documents where it equals 48 if you say the string I'm going to look for the string four and eight we're going to just kind of trust that the clients sending us requests are adults and they know what they're looking for and if they're getting confused between numbers and strings there's nothing we can do about that another part of this is that most of the time right there is a strong thing like mongoose that's making the schema so people are defining classes they're just using something like o dm and we're going to get regular normally we're going to get all the data will be the same all right last part of this learning step what do we have to write well here's an operation there are basic inserts that do overwrite and everybody in Cassandra land knows how inserts work that's easy but things get a little more complex this is where functionality trumps performance so what this says is go and find me the document where id equals one and that update clause says add the field is old and remove the field is human from the document so I've got a couple of operations happening there in that update this is getting a little bit harder because we don't do this this says find the document where id equals one add the field is old go to the field age treat it if it's a number I want you to set it to be the maximum of its current value or 50 that's a read modify write operation we don't you can't even do that in a cql update you can't do cql field equals field plus two unless it's a counter all right now we're getting a bit more complex this says find the document go to fav numbers it's an array add 22 and 33 to it if they don't exist so that's what dollar add set add to set says so again we've got a level of complexity in the update operations and we've got a bunch of read modify write things that are going on and these are things we don't like to do in Cassandra this is all of the things that I could possibly want to do and this find one an update so find the document update the is locked field to be the max of its current value or one give me a projection so return back to me the resource and is locked fields from that document and return it back the state it was before you did the update these are all the capabilities you can do and find one an update so this is how you could implement the distributed lock it's basically doing that and again that's like the level of complexity there from cql we are used to the idea of just being able to do a no look right and just overwrite everything all right so what do we learn we've got documents that have updates those updates can be on fields and arrays our updates require the document in memory because we have to be able to make read modify write and decisions about what the document state should be based on this current state inserts by definition we already have the document in memory so from a Cassandra point of view we can just keep rewriting and things again and again because we always have it we'll see that in a minute okay the c-star features that are actually useful for this the talk before here Scott was saying SAI is great and it is and it's the future and it is because all the vector stuff runs on SAI and it's good after all these years to have good secondary indexes and lightweight transactions Paxos and Accord are the future as well which is really weird briefly touching on SAI a third time a try third time trying for secondary indexes in Cassandra available in OSS 5 very efficient and being able to deal with multiple indexes on the same table we'll see a chart about that in a minute and very high performance they've got and and or support so whether that or support is in the version that's in Cassandra 5 I've not kept up with everything but it's coming up JD's shaking his head it's coming and we're going to see the list of things that make SAI better that we've we've uncovered in this so yeah in the real world this is maturing and technology this is from CEP 7 SAI was one of the first things to go in in that process you can see the blue line at the bottom as you add more SAI indexes you are not using a linear amount of additional disk space it is very efficient of being able to index multiple columns on a table and that's really important when we go and see the the monstrosity I'm going to show you shortly also on that CEP 7 there's some of the performance numbers here this is reading four billion rows I don't know all the details of what it was it's on CEP 7 it's fast and other people are making it faster that's always a good situation quickly if you haven't seen them make a table create a custom index you can put it on the text a number of date I've included some of the options there for text indexes coming soon as well we'll be leucine tokenizing of your text fields as well now the really exciting part I can use those like a regular like database I can say where name equals Aaron and that's powered by the SAI index but in those last two examples I can put two terms into my where clause and SAI will go and read both of those and do the join for me and do it smartly so it's not a sequential get one and get the other it's parallel work and it can do the same with or so when we found all this and this was great stuff we also looked at collections so I can put them on maps and sets and lists I just haven't included lists here because we don't use them you can have three different types of indexes on the map you can index the key or the keys or the values or the entries which is the really useful one so you can see if I've got a map here of metadata I can index and say get me all the doc get me all the rows where metadata topic equals monkeys I can put that together in multiple clauses it's starting to look pretty cool and I can do a set test as well to see if the set contains a value okay and now on to lightweight transactions so being around since Cassandra 2 they are used in a lot of places and relied on at scale that probably you'd be surprised about given their reputation uh Cassandra in Cassandra 2 they came in in Cassandra 4.1 there's a new version which is supposedly 50 faster and in accord it's going to be more better performance so it's basically the same performance as a single right as a normal insert in most cases so we now get to have better consistency which is handy because some of those use cases for Node.js users expect to have primary key constraints and we just went through all the need for read modify write in order to have all the functionality so quick example here I can do an insert and if not exists if there are no users with the username the beard of Zeus and I can also do an update and only change the value if the value is the same as what it was previously all right we've got the building blocks now we've got a pretty good understanding about the JSON data model how how we store it how we need to read it back and we know that there are these features that are in Cassandra now and getting better there is SAI is getting better our transaction support is getting better so we can put these two things together and have something that will get better in the future so we came up with this idea called super shredding which goes through three steps we're going to walk through the JSON document take note of the nodes in it work out that path name so it's user.name or something like that understand the data type that it is and we're going to look at all the types of operations you could want to do against that and try to work out how we what data structure we need to store for that and do we need any extra metadata so we're going to say for for the exist clause put that in the set because we want to go and look at all the fields we can test we'll look at that an example we want to put it into one row of CQL so that that see that SAI query planner can go into his business it's actually pretty good at working out how to run those queries so we always want it to be in one row so if we have this document here and we have the is human tag the is human field we see for dollar exists we just know to store a way to a set of that has is human in it and then we can go and query to find that back all right so the next slide has this data model we've improved that this is the easiest way to explain it and and I do have people send me emails and things at work about some of these things all right yeah so let's break this down there's really two things we need to do store the blob and maintain some way to be able to pull the data back the primary key is a tuple here because the the idea of your document could be any jason scalar value so we have to encode that string 48 is different to number 48 the tx id we use in the transactions we'll see shortly doc jason is where your blob goes all the others are data structures maps and sets that together allow us to implement all of the functionality of the api by being able to go and pull those up we'll go through some examples in a minute this is even the worst part so then I go and put all these SAI indexes on there um SAI is going to be slower is going to take more effort on the rights that's how databases work and we will work to improve this but we now have a good understanding of what it's like when someone puts too many SAI indexes on the table bit of a work example we've got a document and we want to be able to serve the exists filter which basically says find me all the documents where is human is defined I don't care on the value it could be null could be a bullying could be a string so given the document at the top there we do an insert and I've just pulled out the exist keys it's a set we're walking the document we've got all the paths and we are an insert those into the super shredding table and then when you come back to do a read where is human existence true we we go to that set and say where set exist keys contains is human now SAI in the current installation cannot do not contain so that's coming as well as one of the things we've added so we'll see that at the end but that allows me to do a really simple one so what about a more complex query I've got is human I've got the age so we have a map of all of the numeric values query double values we put the age and I put the id in there as well so if I get a query that says find me documents where is human is defined and the age is greater than 48 we can construct this cql query where we put both those terms into the where clause push it down to the database and say go and solve this problem and that's a really easy thing for me to do it's a harder thing for the database people to go and sort that out but again SAI is going to get better because a lot of the types of queries that you see coming from vector space are kind of filtering filter using this metadata then do a vector similarity score and then maybe I need to do some de-duping and some ordering after that similarity because I've cut off the top 10 and I want to order those by some other thing complete queries like this where you need to use ad hoc metadata the filter are going to be more important over the next few years here's an example here with the sub documents just to show that pathway you can see where we've got address in the sub document city we do address dot city we put that into the map of all of the text values and if I get a query that says find me age greater than 48 address dot city again I'm just constructing a SQL where clause and using the address dot city as the path putting it into the query text values okay so the super shredding breaks it all down based on knowing the types of queries we want to serve then it puts a whole lot of pressure on the SAI to go and be able to serve these queries updating what did we learn we've got basic inserts and overwrites and then all of our updates are read modified write that's probably not true I think you could look at an incoming request and say does this require a read modified write operation and then make a decision but unfortunately in Cassandra if you want to go down the strong consistency linearizable consistency path you can't do it ad hoc I can't say changes to this document read modified write so I'll do one thing and this one isn't so I'll do something different doesn't work that way so we're always going to have the document memory we're going to override all the time that tends to lead to better outcomes from compaction and from being able to compaction has more work to do but it's easier to drop stuff off because we don't have like one column written six months ago that has to sit way over in and all this table and other things living at the front so when we have an insert we're just going to do the inserts we saw those before and then put if not exists on and that runs a lightweight transaction currently in Cassandra four that's four round trips it's faster in four point one and then Cassandra five that will be the same as a regular insert in the happy path all right now there's a really complex one find one an update this is all the things that can ask you to do right it can ask us to say find something but if you don't find the document create the document make the change project it before and after basically we have to pull the stuff into memory and make the change they can't really get around it so given the query that looks like this we're going to update and again add the field and set the max we're going to do a select and we know that this query is by ID so we're just going to get by ID here we're going to deserialize that Jason update it and then redo the super shredding and we fortunately have the maintainer and author of the Jackson library on our team so when we want to make that go faster we can so that's kind of fun and then we're going to rewrite everything with an update and see that transaction ID if it hasn't changed from when we read it we go back this stinks this is not great it works there's probably more elegant ways to do it once we have a better understanding maybe if we move more things down to the database or something from a like from a Cassandra point of view when 2015-16 we would talk about these things as something you shouldn't do a lot and by this time and next year when we have a court everywhere we're going to look at things like this and say oh this is just easy like there's no reason not to do this you can do this now okay so what did we what improvements did we come up with here we've got a bunch of improvements coming to SAI for not contains on the set not equals on map entries you can see them all there all support is coming there's a cp out there for not i'm still a big believer and still push on global order by in cql would be great and limit an offset to be able to support those queries earlier we've found some things we can improve in Paxos v1 without having to go to the next level so what did we get out of all this we can do successful just one line config changes and the no j s app can come and work against data data stacks astra or stargate sitting in front of Cassandra doesn't mean everyone's going to change this thing what we wanted to do was make something that was appealing to no j s developers from a performance perspective it's a difficult thing to get a handle on because we're doing things that Cassandra really hasn't liked to do in the past but from a basic trying to compare apples to apples just reading by id adds about 0.3 0.5 milliseconds to go through HTTP and the jason stack and things and there's still a lot more performance improvements we can put in there going to SAI we've got a table with three million rows and we go into a read on one of those SAI indexes on the map and you know 1.4 milliseconds read at the coordinator level to get through the rest of the stack another one and a half milliseconds so SAI can deliver some performance we also have an example of reading with two fields future we've got more HTTP tuning to do because that's a new skill going up against native binary transport which has years and years of becoming very good at being able to do high concurrency high throughput maybe relax some of those consistency rules we started this and in the before vector was such a big thing with vector being such a big thing you tend to have data that loads in as a bulk job or something like that right the embeddings are calculated you want to push it in working out some way to deal better with that all these SAI indexes we're going to go and now work out how to deal with them all and make them more efficient we've got a use case so that's great and just sort of more operations to support vectoring if you want to get hands on with this go to astra and in they get one of the vector-enabled dbs there's a github repo for this stargate slash rest api so you can stand this up against Cassandra sorry jason api typo says jason api sorry and then also Jeff's doing a talk do I get a t-shirt for a cocking up Jeff's doing a talk about using this api now for things and if you see this blog post about was building a Taylor Swift enabled chatbot so this happened in the last couple of days uh there was a whole bunch of work put in to get this going quickly you can see an example on that blog post that came out this morning an example of just being able to go oh look I've got I'm writing uh type script no j s I'm able to go and use Cassandra slash data sacks astra with all that power and do something really simple in in no j s rather than have to get a driver and do stuff in cql so this example here is just searching on embeddings so I have a couple of minutes for questions if there was any I guess t-shirts I don't need this thing um what's the most uh what's the most complex app that you've tested against this so far uh we've had some production apps test on it like things that were originally coded to use another leading data a document database from another leading vendor that were originally coded for that and so production things that other people have run where we launched private preview in september some of those SAI enhancements where it'd been able to do basic things like less than and greater than that are now available turns out there's a whole bunch of apps that don't use those so the complexity will be I think in the vector space right so imagine at some point in the future if someone wants to do this I want to do a query of all of the restaurant reviews that Aaron's written that mentioned the word hamburger in the mini where I then want you to take that set of things and do a vector sort on it and then I want you to sort them by the distance of what street corner I'm standing on those multi-stage queries will be the complex parts all right thanks everyone


Okay. Good morning. Good afternoon. Good evening to everyone. Thank you for joining us for the March Hyperledger Financial Markets Mortgage Subgroup. I think we have a great agenda today. And just to let everyone know, we are recording this call. And also, at the beginning of these things, I'd like to express our appreciation to the Financial Markets Special Industry Group and Hyperledger for their ongoing support and making this group possible. Our speaker today is Daniel Zegu. He's a DLT architect, and he's going to be discussing tokenization. So let's go ahead and get started. Okay. Okay. Before we get started, Daniel, there are a couple things that we want to go through in terms of the agenda. We always like to review the antitrust policy. Please note that this meeting is being recorded, and it's under the umbrella of the Hyperledger Foundation. So we ask that everyone abide by the antitrust policy and the Code of Conduct. The antitrust policy states that we avoid discussion of companies' specific pricing products and projects. We don't make negative remarks about other companies or products. And the Code of Conduct means that we treat each other with respect, never discriminate, communicate constructively. We fully support Hyperledger's policy of openness, equity, and inclusion. And for new participants, we welcome you. And if you'd like, please introduce yourself in the chat and let us know if there's any specific areas of interest or just say hi. Okay. The next slide, here's our agenda for today. We've just gone over the general introduction of welcome, antitrust Code of Conduct. We'll have a couple of minutes on Hyperledger Community Information. James is going to provide the update for the blockchain and the mortgage industry, and then Daniel will cover the tokenization of financial services, and we'll have Q&A at the end. If you do have questions during the course of this presentation, by all means raise your question or type it in the chat. Okay. We always cover the slide in each of our meetings, and this is to reinforce that we're all on the same blockchain journey, but we may be at different points along that path. This group is meant to help everyone on that journey and to demonstrate the feasibility of blockchain technology through mortgage industry use cases or financial services use cases, and define the potential path for the mortgage industry. What does a mortgage company need to implement blockchain, how difficult is it, and how we can all help each other along that path. Okay. So our community information, we always cover the next three slides really briefly, and this is primarily for people that are new to the group. This slide provides link to different Hyperledger resources. The second from the bottom one provides the link to the mortgage industry subgroup wiki. So I invite you to take a look at that. These are great resources and we'll reference several of them during the course of our presentation. Okay. How do you access these resources? You need an LFID. This slide will walk you through that. I'm not going to go through it, but this is how you access those resources. And then the last one, Hyperledger offers free blockchain training. This is how I got up to speed on blockchain and Hyperledger. Highly encourage it. It's free. So please avail yourself of it. And with that, that brings us to James's update for the mortgage industry. James, take it away. Marvin, perfect. Thank you very much. Moving on to the first slide. So, you know, and sticking with the theme with Daniel being here, I wanted to talk a little bit about some of the things that we're seeing going on relevant to tokenization. So, you know, as we're looking at the real estate industry, so real estate tokenization can convert real estate into a token stored on the blockchain. These divisible tokens represents a fractional share of ownership in the real estate. And they provide several advantages from lower barrier to entry, allowing lower minimums and smaller investment amounts compared to your traditional real estate investments, ability to create liquidity. So real estate tokens are easily and securely transferable by way of the blockchain, allowing investors to diversify their portfolios and help minimize their risk. There's lower transaction costs and post management and security. You know, traditionally when a real estate asset is sold, there's a heavy process of transferring documentation that must occur. And through blockchain, as we all know, that can heavily eliminate it. You know, great article from Blockworks. It was actually posted via LinkedIn. I'll talk about the Wiki when we get a couple slides in and you'll be able to access all of these articles from the Wiki. Over in the JP Morgan world, so JP Morgan's recently proposed a new concept called a deposit token. Deposit tokens are transferable tokens issued by licensed institution on a blockchain as evidence of a deposit claim against the insurer. So given that deposit tokens are commercial bank money embodied in a new technical form, they sit comfortably as part of the banking ecosystem subject to regulation and supervision applicable to commercial banks. This includes existing bank minimum capacity and liquidity requirements and other technology risk management regulations and supervisory expectations. The bank argues that deposit tokens are much safer than stable coins as they don't pose systemic risk to the financial system. And JP Morgan has claimed that deposit tokens may enable advance programmability features, the ability to exchange funds with other digital assets, and the transfer of commercial bank money on ledgers that enjoy transparency and immutability that you have within a blockchain. Taking a look over in Europe, there's a German bank, Deca Bank, that's collaborating with Medeco, which is a digital asset management company. It plans to launch a new blockchain platform in 2024. The partnership will launch Harmonize, the core blockchain-based platform providing institutional digital assets. According to Andrea Sack, who's the digital asset custody executive at Deca Bank, the new infrastructure is focusing on the tokenization of bonds, stocks, and other funds that'll open up a new token economy. Additionally, Deca Bank has decided not to trade crypto assets in collaboration with Medeco. The bank's interested only in regulated products under the German Electronic Securities Act regulation. So we're starting to see a theme here, particularly from these last two articles, that banks around the world are seeing the benefits of blockchain, but they're looking for alternative solutions to crypto that'll work within the existing financial ecosystems that are currently available. Marvin, let's go ahead and move on to the next slide. So yeah, I wanted to bring up, CB Insights has issued their annual state of blockchain report for 2022. As you'll recall throughout last year, we would pull highlights out of their quarterly reports. And we do have the 2021 CB Insights report available on the wiki as well. So you can do a comparison, but to glean over a few of the highlights from this report. So 26.8 billion in global blockchain funding last year. Most of those deals hit during the first quarter, very strong first quarter. But then as the crypto market had its impacts, we went into what they called the crypto winner, causing three straight quarters of declines as investors repeatedly scale back due to macroeconomic pressures, stablecoin collapse, multiple crypto bankruptcies, and ultimately the fall of FTX that we talked about last month. 50% of that funding is in US-based companies. US has been leading the blockchain funding year over year, though the fourth quarter of last year, both Europe and Asia, matched the US and blockchain funding. That's definitely appearing to be a trend. And it's kind of anticipated in 2024, both Europe and Asia may overtake the US in the funding that's available. Taking a look at some of the downsides for last year, a 48% drop in funding to crypto exchanges and wallets. Venture funding, as we mentioned, dropped dramatically during the last three quarters. Also a 23% drop in funding in institutional crypto and custody, though it's noted that influential players like BlackRock and B&Y Mellon, they remain bullish on institutional interest in crypto. However, the tokenization of securities, not crypto, is an emerging area to keep an eye on. We've also seen an 81% growth last year in funding in both infrastructure and development within the blockchain world. So it's a great report they produce every year. It's roughly about 160 pages, full of graphs and information. They break down the report by global trends. They spotlight Web3, NFTs, DeFi, the metaverse, as well as giving a geographical breakdown by US, Europe and Asia. Marvin, the next slide. So just a reminder, here is our Wiki site. We'll drop into the chat. A link convenient for everybody to click on and get access to. Over on the left-hand side, if you're looking for any of our past presentations over the last year and a half, you'll actually see those listed on the left-hand side. You can see both the recordings as well as the presentations that we did. All of the articles that we discussed today, you'll see those over on the right-hand side. If you're looking for that CB Insights report, scroll down on the far right-hand side and under the global mortgage industry research. We have another research section that the CB Insights report is on, but do take a look. Marvin shared the information on how to set up your LFID. It's also in the upper right-hand corner, right under Resources, the directions for that. But if you do go ahead and sign up at the Wiki, whenever we're posting articles there making updates or of course posting copies of these monthly presentations, you will receive automatic notification of those. Marvin, next slide. I think we're up to Daniel now. Fantastic. I'll pass it back over to you guys. Thanks, James. Great information there. That's a real interesting CB Insights report. So thank you. Next, I'd like to introduce Daniel Zego. He's a DLT architect. Daniel has been working in different distributed ledger technologies for five-plus years, including but not limited to hyperledger fabric in the Ethereum and Polygon. He's made multiple presentations on blockchain topics, including atomic cross-chain swap between hyperledger fabric in Ethereum, hyperledger fabric and consortium blockchain challenges, cross-border CBDC tokenization and DLT, and a deep dive into key certificates and access control of hyperledger fabric. So Daniel, it's an honor to have you here today and take it away. I'll turn it over to you. Awesome. So thanks a lot for the invitation.  You cannot... Okay, just a second. Awesome. So theoretically, you should see my screen. I just turn my camera off. It's going to be better. So hi, everybody. Good morning. Good afternoon. Good evening, everybody. This is Daniel and today's brief presentation is going to be on tokenization, and especially as having used cases as tokenized financial securities, I would say. It's going to be just an introduction, so we can't go very much deep into the details, but perhaps in a subsequent presentation. First of all, I would like just to apologize. My network is a little bit buggy sometimes, so it might happen that I will just have like a 20-second unintended break. So if you see that, that's practically time for a coffee.  So let me just start with the presentation. So again, that's going to be like an introduction to tokenized financial services. And let me just start from blockchain. So I'm more like a technical actually guy. I have some financial background as well, but I have more experience with technology. So I will just start from blockchain. And if you just take a look on blockchain evolution, I mean, everything started with Bitcoin. The next step is something which is public smart or public or consortium smart contract system started with Ethereum. But practically, what's more important is that this kind of an innovation splits from public smart contract systems. And we have like two directions, two way of innovation. One is the so-called infrastructure innovation, which is like layer one scaling, layer two scaling or cross chain swaps or cross chain cooperation. This kind of infrastructure stuff is kind of very, very technical. It just makes blockchain faster, better, more private and so on and so on. But what's an interesting direction is the other direction. And I would say that's kind of an application level innovation and it starts with tokens. So basically application level innovation goes a little bit into the direction that this kind of application or abstract tokens or abstract things can be actually interpreted independently from the underlying infrastructure. If you take a look, for instance, even Visa started something with tokenization, which is not a blockchain at all. So considering this application level innovation, I mean, the major direction that we saw practically in the last two years, one is like NFT, that was a big hype. Another one is DeFi. It was again a little bit hype and yeah, I would say the bubble is a little bit exploded at the moment. And perhaps the third direction, which is coming is kind of classical financial securities that are tokenized on different blockchains or I would say on different infrastructure. So this is like a blockchain evolution. So let me just continue what is a token basically. So a token is, I would say it's like a poker chip that there's no exact definition of what's a token as far as I know. So I would just give like an intuition definition, intuitive definition that's like a poker chip, which moves on the blockchain basically. So you get a poker and abstract or virtual poker chip. You can imagine there can be like many different chips, poker chips, they can be different based on size, color, amount, perhaps even the shape can be different. And what's important, this abstract entity is interpreted only on the blockchain for the first round. And what blockchain does, it gives you practically a kind of an abstract ownership or a quasi ownership. I would say it's quasi because that's not a physical ownership, that's a so-called cryptographic ownership. So practically it means if you get the private case and you can make a signature with this case, then do you own this token? But it's important to note this is not a legal ownership for the first round. This is a kind of cryptographic ownership. And then if you own this token in a cryptographic sense, then you can transfer these tokens. If you get like multi-token systems, so let's just imagine we get the yellow chip, the yellow poker chip, and the green one. And you can just transfer them, but we can exchange them somehow. And all of these functionalities, all of these exchanges or transferring stuff are defined on the blockchain practically, as the whole token is defined on the blockchain as well. The implementation itself is usually something to do with smart contracts. There are native tokens as well, but I'd say this is a bit like it's getting technically deep, so I just don't follow this direction. This is just one slide. You probably know actually these basic token types. So these are the basic token types. You get like FungiBull tokens. FungiBull tokens, one token is absolutely identical or practically the same as another one. So if you just imagine the idea, if you want to tokenize like money, then one dollar is the same as another dollar, practically. You can use it in the same way. So practically, they are the same. If you just like to tokenize like natural resources, one gallon or one liter of water should be actually the same as another one. So they are practically the same examples are currency or cryptocurrency or stuff like that. These are the FungiBull tokens. And exactly the opposite is the so-called NFTs. These are the non-FungiBull tokens. In non-FungiBull tokens, one token is totally different from another one. So I mean, just take an example. You want to tokenize like fine art, like you want to tokenize Mona Lisa and Picasso. And then if you just imagine that Mona Lisa is represented by a token, then Picasso is represented by another token, then these tokens are different. So Mona Lisa is absolutely different from Picasso. And the tokens representing these arts are different as well. So these are the NFT tokens. Perhaps it's important to point out that these are the token categories that may seem and we know. So there are many other, they are less known. So like hybrid tokens, kind of something which is in between FungiBull and non-FungiBull tokens. So if you want to do like fractional ownership for Picasso, for instance, it is possible that's going to be like kind of a hybrid token. And then it's important to point out, I mean, this field is under innovation as well. So the fact that we have these token types doesn't mean that it's not going to be developed further or innovated further. Perhaps in five years, we're going to have like, I don't know, 5, 10, 100 new token types as well. But again, so these are the basic types, so like FungiBull and non-FungiBull tokens. So if we speak of tokenization, I usually find it practical to point out that, I mean, the whole context of tokenization. And then, so we can imagine let me just speak of that. I own, for instance, a mobile phone or something. And then in terms of ownership, we can define like three categories. And I think it's important to understand these three representations of an asset, because then we can understand and better rep most of the discussion that's happening in the world in terms of legal. Hey, Daniel, I think we just lost your audio. I'm going to send him a quick chat. So I had my break now, but that was like a coffee break, because this is a hard topic anyway. So I think it's important to understand or see these three different kind of asset representation. And one is basically physical. So if I have like a mobile phone, I have it in my hands. So basically, I physically have this mobile phone. I can give it to somebody. So it's like kind of a physical transfer of that asset, of that object. We can speak of something which is kind of a legal or institutional ownership. So for instance, there's a legal system which defines, for instance, that I'm the owner of a real estate, for instance, or of a car, for instance, independently, if I physically have it or not. And basically, in this world, the legal system defines something which is ownership and the legal system defines something which is a transfer of that ownership. And then basically, it's important to note, I mean, this physical ownership and legal or institutional ownership, they are not the same, but it has like, you know, having the connection between these two worlds is like having like 2000 years history. So what happens if I live in my real estate, but it's not mine from a legal point of view and it is transferred legally, but it's not physically. So for kind of a dispute, basically, I mean, there's a system which makes some resolutions between these two worlds. But the point is that we get something new here. And I would say that's the third category at the moment. And that's tokenization. So if we speak of basically blockchain and token, we get, again, a poker chip on the blockchain, which is defined as an ownership from a cryptographic point of view. If I have the keys and if I can sign signatures basically with that, I own that token from a cryptographic point of view. So most of the discussion and most of the problems with blockchain, I think is somehow combining these three words. And it is especially true if we speak of like financial instruments. If you speak of financial instruments, I would say these are like mostly kind of legal or institutional constructs. So physical institutes or physical instruments are not necessarily physical, although there can be some physical characteristics as well. But tokenizing in the financial world basically usually means kind of somehow combining this classical legal and the institutional thinking with the blockchain tokenized thinking. And then there are many variations and many solutions how this can be done. Usually, I would say there are two big directions. And the one big direction is starting from the blockchain world, from the cryptographic ownership. And the point is there are a lot of crypto assets, like Bitcoin, like Ethereum, like Ether, which are basically native crypto assets. So they didn't exist previously. And then the question is how this kind of native token, this born on blockchain tokens can be somehow put into the classical or institutional world, how they can be handled, for instance, in a fully legal world. So for instance, is Bitcoin a security or it's not a security? What happens if Ether, in Ethereum, is it a security? Is it a financial security or is it not a security? What happens if I go to DeFi, for instance, and I just combine two assets. So I put like an on-chain fund having both Ether and Bitcoin, and then just retokenize it. Is it something which is legally a financial instrument? Or is it something different? So these are the hard questions. And this is one way, basically. This is like the crypto and token regulation. And there are many initiatives. Actually, there are initiatives for security tokens. There's the Mika regulation in the EU. That's the coming Mika regulation that's marking the crisis regulation in the EU. Then there's like separate regulation in Luxembourg. And then I'm sure there are like regulation attempts over all the world. But what we are talking about in this presentation is rather the other direction. And let me just have kind of classical financial instruments, which are which are well known, which are really well established, you know, I mean legal frameworks, like for instance, classical money, for instance, let we have like the Euro, for instance, as a classical money, which already exists even in physical form, or let we have like corporate bonds or stocks. And let me just try to put them to the blockchain in a tokenized form. So if we speak of like tokenized securities, then this is the this is the way, this is the direction that we are that we are considering. And I would say it is sometimes easier from a from a legal point of view, it has some other challenges, I would say. So there are some hints, basically, how you can bind, for instance, the token with kind of a legal something. So I'm not a lawyer, so I can't say much on the legal side, but technically what you usually can do, you can have, for instance, a classical contract under your or you can bind, for instance, a classical written contract with your token. There are like, it's a classical digitized written contract, which is not a smart contract for a certain legislation, and you can just upload it to a decentralized storage, and you just bind it with your token, for instance, with hash or something similar. There are even systems that that are capable of doing it out of box, it's like the R-free quarter is, for instance, such a system. So this is one, you know, technical way of combining these two words. Certainly, there are other challenges as well. So like, for instance, classical blockchains or especially public blockchains, use something which is a pseudonymization. It's not a very, it's not the best idea in a classical legal system, you know, I mean, it's difficult. I mean, the whole legal or institutional system or financial system based on identity. So it's combining something with a pseudonymization is sometimes hard. Then usually there are like technical challenges, it's like, so if you sign basically with your private key, then you can transfer your token on the blockchain, but this signature is not necessarily legally binding digital signature, but it's again, it's just kind of a technical problem or challenges. And let me just, let us just see a couple of big areas where this tokenized security word is heavily involving or heavily improving. One, I would consider money as tokenized security. It's just, you know, a little bit broader sense perhaps, but one big direction is CBDC, that's like central bank digital currency. And it's, I mean, it's, I mean, so the core idea is very simple, let me put classical money like the Euro in the UN and let me just have it in a tokenized form. And there's seven discussion on how this tokenized form would work, but basically, I mean, from a categorization point of view, there can be like two big areas where we can consider such as CBDC. It's again, kind of tokenized money or tokenized payment. And if I say money or payment, this is like money of a central bank outside, like money or officially issued money of a central bank or officially liability of a central bank, like the European central bank. So that's what I mean by CBDC. It's not a stable coin, especially not a cryptocurrency, but from a technological point of view, are pretty similar. So we got a couple of CBDC use cases. I mean, and it's still heavily discussed where exactly CBDC can be used. The idea is using like retail in retail CBDC. So practically in every shopping, if I just buy a piece of bread, for instance, in the supermarket, then I can pay by CBDC. That's the retail CBDC direction. And the direction is the whole CBDC, that's like interbanking money. What's probably even more interesting is kind of cross-border CBDC or cross-border CBDC use cases. And even in cross-border, we can just differentiate two areas. One area is kind of cross-border retail. And the other one is like cross-border horses CBDC. These are like, I mean, I mean, practically international, interbanking money from and it's especially to hard field, but I think it's especially challenging because so let me put it that way. They have the need for optimization and making it cheaper and faster and stuff like that. But these are the classical use cases. We got some innovative use cases as well. They are still very, very early phase and pretty much in brainstorming. So there's like the question if we can use CBDC in web-free or if we can use CBDC in defy or especially if, I mean, the question is supposing that there's going to be meta-wares and I'm sure there's going to be meta-wares like in 10 years, perhaps not in two years, as everybody promised, but I'm sure there's going to be meta-wares. So meta-wares is not just like, for instance, a virtual reality, but it has very strongly meant to have a very strong tokenization behind meta-wares. And of course, the question is what's going to be the payment in meta-wares? I mean, one idea is CBDC, which might provide kind of a more regulated aspect to the whole field. Of course, the other direction is just having like stable coins or crypto currency, but basically, I mean, nobody likes that idea in the regulated world. And there are even initiatives, if I'm not mistaken, in Singapore, for instance, to have something which is more like a synthetic CBDC. A synthetic CBDC is kind of a stable coin, which is practically issued indirectly by a central bank. So it would practically use, I mean, these use cases supposed to have their own infrastructure, so something which is either a consortium blockchain or perhaps even without blockchain, like with a classical message-based system. Synthetic CBDC is something which is meant to use public blockchain platforms and work in a similar way as stable cryptocurrency said the moment. The only thing is that they can be somehow issued perhaps not directly by central banks, but indirectly by central banks. So that's like synthetic CBDC. And from the technological point of view, it's part- Daniel, if I could interrupt you, I might just put a question in the chat. Is Swift moving to blockchain or is there a private blockchain alternative? I don't think Swift is moving to the blockchain direction. So that's like, let me just have the other part of my slide and I will just try to answer the question as far as I can. So from a technological point of view, it's not a must that CBDC is implemented on blockchain. It's not true at all. So for instance, the latest directions from the European Central Bank is going rather to a message-based system probably and not to blockchain. I mean, blockchain having like many issues at the moment, especially scalability and so on. It's just, you know, I deal mostly with blockchain. So I just follow actually more like the initiatives that are on blockchain. But there are many considerations of having CBDC on classical message-based systems. That's like Swift. That's like Visa. That's like ISO, 20,000, 20 direction. These are the classical message-based systems. And then as far as I know, Swift is not moving to blockchain. They might have some blockchain initiatives if they have something, I would say it's like kind of an interoperability initiative. So like having something with Swift core platform and somehow exchanging data or token or asset with a blockchain platform. I think that Swift is classical message-based platform. So the core platform is surely not a blockchain platform. Again, I mean, they might have some blockchain initiatives. But hey guys, I think this is our coffee break. Change everything to blockchain in a shorter time. So this is like the technology. And then, I mean, if it's not a message-based, we got some ideas how CBDC can be done. It's usually, of course, I mean, one direction is like on general distributed ledger platforms. One direction is having consortium blockchains. And then there are even initiatives doing something on public blockchains. So usually, I mean, the idea is having something on consortium ledgers because it's like CBDC, it's like banking money. So they don't like tokens putting to the wild internet. The only problem is that consortium blockchains are sometimes not so easy. It's just not so easy to set up a platform. And then sometimes public blockchain technology evolves faster from a technological point of view. And I must say, I mean, there are even initiatives to start something on public blockchains. So as far as I know, for instance, there are at least two cross-border initiatives between, that was the French Central Bank, Bonn de France, and the Swiss National Bank, I think it's Schweitzer National Bank. So they have some initiatives for cross-border. And I think partly they involve like public ethereum networks. Again, it's not so typical, but there are ideas. And especially if I just go back, for synthetic CBDC, I mean, the idea is, for instance, using something similar as a stablecoin on a public blockchain, it is just issued by not by anybody from the wild, but by regulated institutes or even directly from Central Banks. So this is the use case, and this is the technological roadmap for CBDC. But I mean, there are many other directions and other interesting ideas as well. So as James mentioned as well, I got this one on my slide, as well. It's kind of a logical step, because I mean, I would say Central Banks sometimes move pretty slow, which is certainly not a bad thing from a stability point of view, but especially in terms of innovation, perhaps not the best. But I mean, practically banks issue their private money in a normal sense, which is connected somehow to Central Bank money with a bar. So I mean, it's a logical idea that commercial banks can create their own tokenized money as well. And there's even a framework for that and the good white paper from GP Morgan. So the idea is practically kind of a tokenized deposit accounts, which are the deposit tokens, basically. So it's a very, very interesting and novel way of doing something. I'm not quite sure about the technological basis. I think they promote like kind of a consortium network, if I'm not mistaken, but I don't exactly know the details. And of course, I mean, there are ideas to like having classical financial securities and putting them to the blockchain. So one example is like tokenized bond issuance. And it's like two weeks articulizing. So for instance, Siemens, which is, I mean, I mean, isn't necessary to consider the most innovative company on the world, issued digital bond. I'm not quite sure on which blockchain, but it was surely a tokenized bond. And it was an initiative. They said, I mean, they issued practically the token so you can hold the token, which represents a bond. Of course, I mean, the legal constraints, there's a company guarantee for sure from Siemens. So if you have the bond, then the, if you have the token, then the company practically guarantees for you that that's a bond. And as far as I know, it was a hybrid solution or a hybrid digitized bond issuance. Because there's no payment. So there's still no digital, you know. So for this reason, payment was done practically in the classical banking system with free up money, but the bond itself is represented on the blockchain. And I think they said as a result that even if that's a hybrid system, and we don't get payment practically on chain, just on classical banking infrastructure, I mean, having just bonds on blockchain has like a much faster, much better, much flexible system than they used to be. Then there are some other examples that I just listed here. There's something which is green bond. I would say it's like a different category. It's like BMP, Paribas, if I can pronounce it correctly, they issued green bonds tokenized on the Ethereum blockchain. I would say, I mean, green bond is especially an interesting topic because it is very innovative. And if it's a green bond, it is usually connected somehow with like, you know, like carbon emission or some environment friendliness or sustainability. And what you can do if you tokenize green bonds on the blockchain, you can somehow or you can technically prove that this is really a green bond. So it's not just like green washing, but you know, I mean, there are initiatives, even a type of ledger like putting carbon emission to the blockchain. So if you just, if you have like carbon emission or meta emission information on chain, and if you provide tokens, which are, which represent green bond as well on chain, then you can practically combine the two. So you can make kind of, you know, I mean, less trust lead and more flexible system where practically everybody has a better view that if that bond is said to be green, it is really green in some sense. So like you can just cover the emission data behind it, for instance, which is on chain as well. And last but not least, there are initiatives for tokenized issuance. So it's classical tokenized stock. I mean, I just have like two examples here. So like Signum Bank, I think it's Switzerland, they do like classical IPOs, but they had like parallel listing practically stocks or company shares in the Singapore digital exchange as well. And then one example, it's like, I think it's at least six months old, it's like World Wide Bioscience, which tokenized like company shares, for instance, on blockchain as well. If it's about stock, I would say there's one more interesting property that can be combined. And it looks that way. So I would say, so if this token kind of a company share, then then for a company share, you get like two sinks, which is, I would consider more like physical properties. One is voting. I mean, you can vote for a company if you have a share. And the other one, getting paid practically at the end of the year, if there's like profit. And I would say, I mean, both of the features can be somehow technically combined with your token. So if you have a token, and if you have like a digital voting system, then practically you can digitize this voting for a company stock, a company share, which is the token itself. And if at the end of the year there's revenue, then even the payment can be actually done somehow on a more transparent way on the blockchain. So that was basically the introduction. I think it wasn't so short, you know, but so this is a big field, I would say. And I would just go back to my first slide. So we are speaking about this direction here, which is kind of a tokenized financial securities, which is an evolving field. And I would say, so it can be really big like in the next five years. So that was my presentation. Let me just check the questions if I can answer them at all. So there's no really questions, just Swift. But again, so I don't think Swift is moving to a private blockchain alternative. I saw some initiatives from Swift, but I think it's kind of an interoperability between the Swift core system and with kind of a blockchain. But who knows, yeah. And Daniel, if I could interject, Mike, as further answering your question, we've included in the chat an article that talked about Swift. They're doing a proof of concept on blockchain. So we put that article in the chat if you want to take a look at it. So I think to what Daniel is saying, they haven't made any great steps toward it, but they're taking a look at it. So it'd be interesting to see. Now, Daniel, you talked about quite a few things. Thank you. That was a great presentation. One question that pops into my mind, especially as we take a look at the mortgage industry. And there is some tokenization that's taking place already. But a lot of these efforts are on different blockchain platforms. So if tokenization is taking place within Bitcoin, within Ethereum, within I think Redwood Trust was using Stellar, what are the implications around interoperability? If I'm on one blockchain platform, how do I get a token from another blockchain platform? Can you kind of tell us how that works? Sure. So technically blockchain interoperability is solvable. So you can do it if you want. It's like a pretty much evolving field. So I would say it probably needs five-year research and development, but already you can do cross-chain swaps. Cross-chain swap is a way that one transaction on one blockchain can be done if and only if another transaction can be done on another blockchain. So it's like exchanging for Bitcoin to Ethereum. You can get the Ether on Ethereum if I get the Bitcoin, for instance, and then there's a guarantee that the two transactions are done in the same time. The other one that is mentioned here is like cross-chain bridges and cross-chain bridge. What you do basically, you look, you practically map one token to another chain. So what you do basically, you lock your token on one chain and you issue kind of a wrap token on another one. And then if you just burn that wrap token, then you release your original token on the first blockchain and there's usually kind of a bridge which guarantees this consistency. So I would say, so that's the two things. There's a free survey as well. It's always a question if you do like cross-chain interoperability, if you need to avoid like cross-chain double spending. In these two examples like cross-chain bridges, cross-chain swaps and stuff, you need to avoid basically cross-chain double spending. But usually that's not the case or sometimes it's not the case.  Then you don't need to worry about like cross-chain double spending. Then you can do basically with an oracle. That's the third direction. And there's like ongoing research. If you want to do like cross-chain interoperability in a way that you want somehow to execute a business logic in the middle of your swap or of your chain in a trustless way. It's pretty much, I would say in research and development, but the modern zero-knowledge systems are gonna solve or might provide solutions for for such problems as well. And someone mentioned in the chat, I think it was Mike as well about the security concerns around that, which I've heard about as well. But then the other concern that I've heard about and I share is the energy consumption for that type of step. Already with the proof of work consensus mechanisms within blockchain, Ethereum has now gone to proof of stake. If you try to have that type of interoperability, it's just for energy consumption that's going to be pretty significant or at least increase. And then transaction processing speed. Yeah. So energy consumption comes from the consensus algorithm. And then if you've got like two blockchains and one working with proof of work, then energy consumption is an issue. Daniel, this is a great presentation. We appreciate you coming today. I wanted to reflect back. But usually it's not the case. Yeah. So let me just somehow try to do it one by one. So I don't think that the, I mean, cross-chain interoperability will have like bigger energy consumption than the individual chains. And then the point is, or then the question is, yeah, so what's gonna happen with Bitcoin, which consumes a lot of energy, of course, and then they don't plan to, I mean, upgrade to like a proof of stake. So then that's the question that practically remains, I would say. Yeah. So there's a question actually like the privacy concerns around retail CBDC.  And I would say, so this point is like a little bit more complicated. It's more complicated because there's like two, at least two aspects. One is a technological aspect. And the second one is more like, you know, I mean, political and society aspect of this question. So from a technological point of view, you can do on a blockchain practically tokens with the same privacy guarantee as cash. That's like Zcash, that's like Dash. These are privacy coins. They have practically the same privacy guarantee as cash. Especially with like the zero knowledge movement at the moment, perhaps in a couple of years, even on Ethereum, you can do like private transactions as well. They're gonna have like almost the same privacy guarantee as cash, for instance. So this is the technological point of view. From the political and society point of view, especially, I mean, the question if, you know, if a central bank wants to issue like fully private money. And it's like a more complicated question. And I just wouldn't go very much deep into this question, because this is like a really big discussion. So usually, like, you know, I mean, most central banks don't plan to issue so private money then they're short Zcash, for instance. There must be a certain level of privacy, but somehow like, you know, I mean, the key YC and a lot of regulations, which are not exactly privacy friendly, should be somehow kept. So this is one, I mean, side of the coin. The other side of the coin, which is the privacy level, which is accepted by the society.  Certainly, it's not necessary kind of a CBDC design, which is accepted by the society. So if that happens, practically, nobody will use that system. So again, from the, so I can answer more the technological point of view again, and all the other aspects are just more controversial. But from the technological point of view, you can do it practically as private as you want.  Hey, thank you, Daniel. Are there any other questions for Daniel on tokenization? As Daniel has been saying, and I think as we're all learning, this is a very broad topic with a lot of complexity. And we're just starting at the very beginning here. And I think, Daniel, you've done a great job of giving us a tokenization primer. And we'll continue in future meetings to dive deeper and deeper into this. And we definitely appreciate you getting started. And we'll probably want to have you back for future discussions as well. So let me just open it up to the team, to everyone else. Any additional questions? Daniel, I did have a quick question for you. So on slide seven in your presentation, you mentioned the challenges with consortium blockchains. Could you expand a little bit on that? We've been talking with this group over the last year, bringing various articles to the table on different banking institutions that are forming these consortiums. And I'm interested from your perspective as to the challenges for that. So the way I see, but that's my opinion. So if you want to do something with consortium blockchains, there are two challenges. One, you need to have your full infrastructure up and running. So it's not the same as if you're a developer, you can implement and develop and put something on the public chain in two days. If you want to deliver practically infrastructure for five banks, that's gonna be a big project. I mean, just imagine if you just want to deliver any kind of software for five banks, you get a lot of regulation. The infrastructure size is not the easiest. If you speak of blockchain, it's not just five independent nodes, for instance, or components that you deliver for five banks. But these are five components that must basically communicate with each other. So it might even be even bigger challenge, for instance. I mean, just giving one example, just imagine you get five banks, each having different ideas for and processes for making a change, modifying something in a system. But you can't implement five different change in your consortium blockchain. You've got one consortium blockchain, there should be one process, one way of making changes on the system. But as your five banks having five totally different something, you're gonna have a lot of discussion and you need a lot of energy making to a compromise. That's my experience, basically. So that's one of the big challenge. The second big challenge that I see, so sometimes crypto is evolving faster, and especially the infrastructure below crypto evolving faster as well. So for instance, like again, the newest wave of infrastructure innovation gonna be like the zero-knowledge rollups. You can find them on practically every second public blockchain. You don't even find them on like, I mean, as far as I know, there's no initiatives, for instance, for like Hyperledger Fabric or for R3 Core. It's just, I mean, they are just behind a little bit. So this is the second challenge that I see in terms of consortium blockchain. But again, so I would say the biggest challenge is, again, if you have a public blockchain, you can have an app, practically or a token, up and running in a couple of days. That's not a problem. If you need to install infrastructure to five banks, that might be like a half year, one year process. Excellent. Thank you. And Daniel, we have time for one last question. Ramesh put into the chat. Is there any spec for CBDC implementation? So it's a good question. What do you mean by spec? There's the open CBDC platform, which is open source. That's only one CBDC implementation. It's not just a spec, but it's an implementation as well with white paper and stuff like that. It's partly for MIT, I think, and initiated by some banks in Boston, if I'm not mistaken. So you can even find systems, which is meant to be like an SSCBDC system. If you need documentation, so the last one I saw, basically, it's a good summary on requirements, on technical and non-technical requirements for a CBDC that's from the Bank of England, for instance. But basically, there are many reports you can find almost on a monthly basis, one good report for having one CBDC direction. And it's a little different as well. So for which purpose do you want to use your CBDC? Because again, I mean, retail CBDC has totally different requirements than an OSL or a cross-border OSL. I mean, in a retail CBDC, you need like, I don't know, couple of 10, 200, 2 million transactions per second, which is sometimes not even solvable with blockchain. In an OSL case, you might need like a couple of 100 transactions per seconds, or even less, which is totally solvable, perhaps even by public blockchains as well. Thank you, Daniel. And thanks, James. Ramesh, James put into the chat a link to the open CBDC white paper from MIT. And everyone, that brings us to the top of the hour. Daniel, again, thank you for joining us. And you clearly have a depth of knowledge in this, and we appreciate you sharing your knowledge with us and answering these questions. It's been a great discussion and we definitely like to bring you back for a future discussion because this is just the beginning of the tokenization discussion. With that, thank you to everyone. We will post the recording to this call because usually we have several hundred people asking or accessing the recordings to these calls at a later point. And thank you, everyone. Have a good day and we'll see you at our next Hyperledger meeting. Have a great one, everybody. Thank you, Daniel. Thanks for the invitation. Bye. Bye.