 Hello, everyone. Can you hear it? It's a little noisy here. Can anybody hear me? Can hear you, Vipin. You're breaking up a little, but we can hear you. Yeah, sorry about that. I'm in the middle of this conference. We'll start the meeting. Let me just say. To follow the entire, so that we are engaging in any anti-competitive and also consulting for PDRM by C. And I look to themselves, but then also we have to follow the code of conduct, which essentially says that we should not be, we should be kind to each other. So go and introduce yourself. I've gone on each of the participants. Peter. Yeah, hi, Peter Ray. And I am a consultant in blockchain. Beautiful. I keep the introductions possible because we have the many events. This is Isaac Kanpo with Chain Yard. We're also a blockchain consulting company out of North Carolina. Hi, I'm Jagdish. I'm from Swapster, pink. This is Morali. I'm from Hyperlegia Public Manager. Hey, this is Paul de Marseille. I'm the director of community with the Enterprise Ethereum Alliance. This is Manny for Life from Swapster. Hi, this is Bill Alder, membership director with Enterprise Ethereum Alliance. Hi, this is Officer Avinari from the New York security token exchange. Amanda Wilkie. Yes, Amanda Wilkie. I would say Manny, you should go ahead and start your presentation. It will be recorded if you do not mind. I will share it with you before I put it on. Yeah, no worries. Let me try to get my screen shared. Sorry, I have to set my Mac preferences to let Zoom share. Now I have to restart. One more time. Hang on one second, folks. Why? Yeah, I'm back. Sorry, the new security features that Apple has put in. They're good. But sometimes you have to remember that you haven't done it for every sharing app that you can remember. All right, so let me get started. Morali Gray with Microsoft has been also the chair of the Token Taxonomy Initiative. I also sit on the board with the EA and wanted to provide an overview of the token taxonomy. Framework itself. And a good bit of back end and background is helpful to understand what we're trying to talk about. First off, the Token Taxonomy framework is the major output from an organization called the Token Taxonomy Initiative, which just so happens to share the same management staffing and infrastructure for the most part with the EA, but it is a separate organization. It is not an Ethereum aligned or specifically aligned standards body, but rather it is neutral. And you'll see as we go through the Token Taxonomy framework why that is the case. It has been broadly welcoming really to everyone, including all platform providers because of its neutrality, including all the main ledgers and hyperledger, the Ethereum variants and things like R3, Quota, digital asset, Hedera Hashgraph, a whole bunch of others as well. But probably more importantly, it is probably most directly applicable towards non-technical business audiences that are focused on creating solutions and tools being, excuse me, tokens being one of the tools that they are one of the new tools that look to potentially solve some of their existing business problems and create new opportunities. So with that, let's quickly jump into what the taxonomy is and probably just as important what is not. This number one goal is to essentially create common ground for educating and establishing common terms and definitions across the ecosystem so that we are speaking with one voice as an ecosystem in blockchain category. It doesn't mean you have to be a blockchain to use this, but it allows us to speak to business people and technology folks and even probably it's importantly regulators around the world and speak and not confuse them with terms that are either specifically out of financial services or specifically out of blockchain and create a framework where we can, you know, everyone can articulate what it is that they're trying to do with a token and talk about the business problems it's trying to solve. So from that it establishes those common terms and definitions and then underneath the covers it is a composition framework. So it is built up of a whole bunch of different, what we call them artifacts and they're just essentially business descriptions with metadata for individual components and I'll go through this in just a moment that allow you to compose a token without knowing how to program anything but rather understanding what the concepts are and modeling out what you would want your token to be able to do and just as importantly not do. And then it lets you create this token definition which as it turns out is a really solid set of technical requirements and business requirements that can be used to implement that token for a specific platform. It does not tell you how to implement it, it rather tells you if you're going to implement it this is exactly what it should do. And then the notion behind that is when you have that and you've written it to that specification we can then eventually certify that that token implementation meets the exact specifications that are in the token taxonomy definition and we call that the specification. Now, we have not defined the certification process to date we have a star on that. But obviously there's a, if you've ever been in this business for a while you have to first agree with what you're going to standardize on and then how it's actually certified on each platform, the vendors and the actual platforms themselves will have to be able to lean in and help. Not only that but you also have to have a way to actually certify and test it. So those tools are going to be in development for a while but that is the long sort of arc of what that is. So what is not is it's not blockchain specific. It is not illegal framework or regulatory framework but it's great common ground. By design, not complete. It is intended to be a collaborative very much community driven open source sort of ecosystem where the framework and ties is folks to contribute to increase the number of possibilities that people have. So I've done this presentation about 1000 times so I'm going to time now that we have some visuals to show I'm going to actually show you what what the end of the road might look like. This isn't what it looks like at the moment, but we're racing towards this and what you can expect an experience would be from a non developer business person that has gone through some basic training and maybe learned about the token and can begin to work with this framework to design a token. So here's a designer look and feel that you would look at looks very similar to in most of these. Well this at times now seems sort of old school but if you've been around for a while and you remember how we used to have whizzy wig UI designers where you would drag controls and pop the on a page and and sort of create what your interface user interface would look like the same sort of scenario where you would start out and pick from you have these different palettes of token bases these are essentially the starting points that you start with. And then you can grab from the various property sets and we'll talk about what those are in a moment behaviors and these things called behavior groups, don't worry about what the terms are at the moment, rather let's focus on what the intent is. So if we go through this, you know user could come in and grab the single token or singleton token and drop it on to the design surface and then, along with that automatically. Some of these are preconfigured to have behaviors already attached to them so you this singleton behavior is actually already attached just don't see it until you drag it on there. And then from there you start dragging, in this case we're dragging property sets like the file property set and the bill of lading property set or, you know, whatever these property sets are and they snap in to build properties out this way. Of what those would be and then the behaviors we grab over here from the palette of behaviors and will drag and drop behaviors to say, you know, it is transferable, it is a testable, it's logable. And then, you know, we get to say save and call it bill of lading. So this is our bill of lading document token so this is a since we're going to be scanning it a bill of lading and creating a token out of it. And then describing, you know, that we could transfer it it's a testable it's logable, but we're not finished with that you know we can go out and then add different behaviors so here's another example where you would start with a fractional fungible fractional fungal means that it is subdividable. So if it's subdividable, when I drag function fractional fungible it automatically brings out subdividable by definition going to be there. Then I would say how many decimal places do I want this fungible token to be subdividable by and I would have a, I could simply click on subdividable, excuse me, click on it, pick the number of decimals and then it would give an example what it looks like. Same thing for your property sets if I have a skew property, and you know I want to set a max length on the skew. How would I do that I could type in a number and then regular expression would come into play I wouldn't have to type throughout expression, but I could put in things like max length or put any other constraints that I wanted to, and have that decided I know you'll notice over here you can also do the same thing without having a pop up window on the right hand pain I could change these properties. So it gives us a very sort of intuitive way. I'm going to point out a couple of other things as I continue along with this. You can also use it for education so you can simply hover over something and if I hover over the skew it tells me what the definition of the skew property set is, but also over here I can see. In my token base as a fractional fungible here's the definition, and all of this text is coming from the framework. So the individual artifacts have all of this metadata in them within these their graphical visualizations of them are these artifacts that are in the token tax on the framework. And it gives me a description gives me some examples. So I can use this user interface to surface the contextual information about tokens as a user is designing that token or learning about that token. So you could pull up an existing token example like fab token or an ERC 20 variant fungible that's called that's given a business definition like a loyalty point. And I could, you know, hover over these and learn about that. What does this actually do? What does it mean as an education tool. So this again is various things are being in development. I'll point out some things here you'll see this thing called a token formula. I'm going to go into all these things in detail and just the next starting in the next slide of breaking this thing down. But I wanted to give you a feel for, you know, how we envision this being used in the non blockchain community. But also, you know, it really should unlock sort of the concepts and the power across the broader ecosystem without sort of starting with, you know, chain code or solidity or, you know, whatever. Rather, let's go back and model out what we're actually trying to do and put some real world language in there so that end users can understand these concepts. So, let's start breaking this thing down. First, we have to define some predefined terms. We try to keep it at a minimum and if you've been in programming for some time these will look very, you know, I kind of understand what these are and it kind of makes sense. But I'll start at the top. We have this thing called a template or a token template, which is actually a composite in itself and it has two main parts it has a formula. And as a definition, so I'll go into the details of those but those two things combined create a template itself. When you write an implementation based off of a template, and someone deploys that that becomes a deploy that to a network. It becomes a class of that template type. So it's a deployed class and then individual tokens, depending on if it's fungible or if it's, you know, a non fungible that instance is what we call an instance. So it's an instance of that class. So that doesn't translate exactly to every platform but it's more of a concept and establishing these terms. And I'm saying the instance I'm usually referring to what an end user would think of as the token in their wallet is a balance that they hold those are instances of that token class. And from that token class is based off of the template specification of that so it gives us sort of a set of high level terms. And within those terms we say okay, let's talk about this user analogy with baking. So a token class is like a cake, a finished cake, you know, it's baked from a recipe like a template. A slice of the cake is a token instance. You can have bigger smaller slices. The cake is made of ingredients like milk, flour, sugar and like that's the formula. The formula itself is just a list of ingredients. And then the definition are the specific instructions for how to mix the ingredients, how much of each ingredient is needed, how much milk, how much flour, how much sugar, when do you mix them together, all those things and then how long to bake it. So the template itself is essentially a recipe. It doesn't know how you implement it. The analogy starts to break down when you start to get into the physics, but that's actually what we're talking about here. So and the TTF ingredients are artifacts. Those are the individual milk, flour, sugar, things that are like standalone. They have the potential to have quantity, for example, but they don't specify what that is until they're placed in context with an other ingredients in a recipe like a template. And then once you bake the template, that's an implementation class. And then the instance is a quantity of that class. Okay. So that's all sort of high level stuff. Let's now break into what a template formula. So this is where you'll usually start a typical user would usually start an end user would start with a template formula. That means you're going to try to compose or get all the ingredients that you would need. Like we did in the graphical designer starting with a base token and grabbing all the behaviors and property sets that met our needs to create a template formula. And as you drag those things across and plop them on the design surface under the covers is building this formula. And it has the base type and the formula for more sort of classification purposes, which we'll talk about in a minute. They have symbols and it looks like a mathematical formula, but it's very simple. It's just a way for logically grouping these things together and differentiate what's a behavior versus what's a property set versus a base of token base itself. So you can see how the formula breaks out. And again, we're just talking about the formula here, not the definition the formula itself. So those are visual symbols underneath the covers, each one of these are artifacts, and they each have a unique identifier, which is just a GUID or a UID in the framework, and it has a type so you'll see that in a moment. And then from once you have a formula, then you can say I want to create a definition from that formula. And what that does is it essentially goes out and because each one of these a formula is just a reference to individuals. So this is a reference to milk, flour, sugar, but doesn't say how much each one. It says you're going to need these things. These are just pointers or references. When you say I want to create a definition, it creates a new artifact called a definition, and it grabs essentially a copy of each one of these is called a reference. But it's essentially it grabs each of these things and puts them into a structure that you can then go in and specify my subdividable amount is a decimal places of two. This is where you indicate what the settings are for that individual artifact in that context of the formula. And that will be very, very specific for the template that you're defining. So if you're defining a, you know, stable coin, it's, you know, in the US or most countries would have a decimal place of two, right, so divided by two. This is an example of that level of detail. So again, this is our definition that we're pointing to so formula definition itself. Down here we have classes. So there, you'll see that the token class, we use the same color to say hey it should have basically the same interface just implemented differently underneath for different blockchain so it also represents a common abstraction, which we'll get to in a moment. So, that's the framework, basically the how you sort of compose those things, and then you compose them of artifacts that are placed in the categories. And these categories are the base tokens. Those are sort of your starting places, property sets, which I'll talk about each one of these in detail here, and subsequent slides. So property sets, you can think of just simple properties that have getters and setters and no heavy logic behind them, like a SKU, for example, or a PO number or something simple. But behaviors are really where we see most of the action and that's where you're going to either define, you know, a capability or restriction and really put in some business language, and perhaps regulatory or compliant information in there. And the behavior groups are just a way to group, create a template of behaviors that typically go together and have them preconfigured for specific use case. So let's go through these real quick. All artifacts have this thing called an artifact and all this stuff is essentially under the covers it's at runtime, if you will, it's just using protocol buffers. So you'll use when you're working with artifacts in a programming environment, you'll use it just like native objects or whatever programming language you're using. We serialize it all to JSON and the GitHub repo. So the TTF is hosted in a GitHub repo. And, and just so happens, get is a really great place to do collaboration at this level where you can have multiple people contributing. And we track all those changes because we're serializing to text, we can see what deltas are and manage the expansion of the framework over time. Anyway, these artifacts are just GitHub based. They're pretty simple structure, the folder structures based essentially on these groupings and folders are named and have the latest version and then subsequent versions can be uniquely identified. So you have multiple versions of the same artifact, and then reference different versions as you compose those things together. So it's a pretty straightforward if you've done any tax of your framework based work it'll look and feel like any other framework. So let's go through some of these first like the base token types we have. You'll see the fungible tokens you have a this is going to get a little bit in the clear classification I'm going to cover that much more in detail the next slide. But here we have a common fungible, which is the towel F, and then the unique fungible which is essentially a balance or account based fungible for common unique is UTXO. So we think that same concept will apply to non fungible in certain platforms so we just said okay let's just let that flow over to non fungible tokens whether or not for individual platform it makes sense. We didn't want to restrict it yet we may or time say this doesn't make any sense that's this confusing where people in this work but we defaulted to to not doing that initially. And we have this notion of a hybrid and a hybrid is the way you would model out from a business perspective things like a security. So a mortgage backed security would be fungible parent with a bunch of child non fungible. Well, logically mortgages. Each one each mortgages its own unique fund non fungible, and then I can just issue thousands of fungible tokens to allow me to sell fractions of that pool of mortgages. You turn it on its head and you can then model out something with a non fungible parent like a metallic is coming to a city and they're going to do a three three day show. You would have a non fungible token for each day of the show, and then you would have tranches of or excuse me classes of tokens one for general admission those are fungible and then you could have reserve seating, which now that they've gotten old I guess you kind of want to do that for a concert, you could buy reserve seating and get like premier seats with, you know, your ear plugs, so you don't go deaf and your old age. Any reflecting a little bit too much of my last experience at a mentality concert. So hybrids let you sort of model these things out how they're implemented, you know, it really varies by platform. We want to restrict people's concept of building tokens based on what underlying platforms can and can't do. We didn't want to buy design we did this very early on as to say listen we can't. We don't want to bring any restrictions or capabilities and explicitly restrict the framework itself to not being able to have a concept just because it doesn't make sense for that platform. That's not the intention here and we don't want to do that. So let's talk about classification this is super important for once you start to understand this better this is this becomes sort of really really important it helps you sort of guide customers and regulators as to sort of what the big picture is so the first is the token type is either fungible or non fungible. Those are the fundamental differences I'm not going to spend time covering what those are right here right now. But from there then you said okay what's my token unit is it fractionable whole or is it a singleton. A lot of people get hung up on the whole singleton and so witness singleton and non fungible and what we've seen scenarios where non fungible tokens can actually be subdivided. So I might have a non fungible art token but I can have I could then subdivide that and say you own a quarter of the Mona Lisa without me having this weird multi sig type thing. But the the whole token itself is a non fungible whole. Anywho it is not an implementation in detail it is what is the unit from a business perspective there should be one of these only one and it cannot be subdividable so that's a singleton whole is essentially saying you're dealing with whole numbers fractionable we are to talk about subdivision. The next one is value type whether it's intrinsic or reference so intrinsic value is a cryptocurrency it's not backed by any asset no real world asset behind it. So that's what we call an intrinsic references where we're seeing a lot of the action now is it's actually referencing a commodity or a piece of property of some sort or backed by a pool of like Libra backed by a pool of currencies. Anyway that's a reference type. The second is or the fourth sorry is representation type comedy unique we talked about this in the last slide whether it's common fungible sorry. UTXO versus balance if you say that to a business person you're never going to get past the discussion but if you go and say hey it's common and unique what does that really mean and talk about properties and give them business scenarios for like if you have a whole bunch of tokens and they they should all share a skew number and you have to change the skew a year after it's been out there. That becomes a problem changing that skew for all the tokens that are out in the wild if they're all unique. That's a business problem right it's not really a there's ways to solve that but you have to think about it upfront. You know how would I address this you know as you go forward and the fifth one is the template type. Now this is a template typing because when you're defining a token you sort of define it as an individual thing that you can put it in parent and child relationships after it's been defined. Now you can then combine them and say it's a single token meaning there are no child tokens or if it's a hybrid it can be a parent with one or more children and a child token can actually have be a hybrid itself which can create very complex model very complex business scenarios. So these are the definitions I just walked through all of these so that you guys are going to get these slides so you'll be able to see the details here and read these. These are all in the markdown as well that's publicly available in the documentation for the framework but this is a good slide if you're trying to communicate it to a larger audience. So let's go into the individual artifacts these are again the individual sort of recipe ingredients themselves so properties themselves. Let's back up a little bit and talk about properties properties are either behavioral or non behavioral. If you've been programming for some time this makes a heck of a lot of sense. We have sort of a behavior excuse me a regular property set is just like a regular property or a something that has a just a getter and a set or many you're going to set the value without a ton of logic. And you can get the value and you're expecting that property to be queryable for an object of that class and a programming language for example. That's what we would call a property status kind of doesn't require a lot of logic to set the value. We'll talk about behaviors in a minute you have behavioral properties that are not exposed or they're dependent on a behavior to set its value. That's what we call behavioral property it should not be defined as a property set. So it's a sort of a for people that haven't been programming for a long time this is sort of a you have to kind of figure that out. But for the most part we're saying it's something like a skew who the issuing organization is something like that. The denomination of the the fiat currency backing the stable coin or whatever would be a property that we would look at. So these things have a symbol of you'll see the fee skew which is essentially in the formula how you're there and you go in there. The most important thing there is when you're putting this in a token definition you can set things like property restrictions. It could be seven characters long the first two characters are numeric followed by dash and less rest or so you would put expression validation things in there to put business rules. For those individual properties. Behaviors themselves again this is where a vast majority of the of will see what I say that we think what this is where most people will like pivot to and think about behaviors. They're either a capability restriction so something can be transferable or can be non transferable. Now that's essentially the same behavior but one's just just the opposite you'll see how we use the utility symbol for that indicate the indicate the opposite. And then a behavioral property these are properties have buried within the behavior definition so if you have a property that is can only be set by a particular behavior that should be defined in the behavior itself. So we'll talk about like subdividable has a decimals property. Now how you implement it again this is just for the definition to make it readable. Now the interesting bit about this is behaviors are also where we think behaviors to property sets or where you'll see will certify these things at least surface level because they are essentially describing the interface of the token. Meaning you know what properties are exposed publicly and then what behaviors are accessible. Out there as well. So when we describe a behavior and property set both of those we have these things called control messages. And they're simple, you know, you would say have a behavior this is how I invoke it. We describe it as messages transfer request has a transfer response. The transfer request has requires these fields and a response will include this as a receipt and it is not a programming. But it does let people describe you know when I'm. If I've described a behavior, sorry, a property set like insurable or a behavior called insurable, where I want to have proof of insurance on a bill of letting for example. Then the insurance company can define these are the values or the consortium would define these are the values that we're going to approve insurable. When we like ensure a bill of letting we call the insurable behavior we're going to set these property values. So I'm going to pass in some cryptographic proof, you know, identify certain things and that'll be the insurable behavior. And they can define that and they'll define those control messages and then you can just apply insurable, you know, to any type of token to say you know it should be insurable so it's going to expose this interface and have you know set these properties not how it's done. But essentially this is where these control messages are describing. You have the option in the taxonomy you describe them as very simple. A nesting of you know I have a request in response and you just name the message and give it some optional parameters and what you expect them to be not what the values are but your description, you know the receipt should include a transaction hash and a block ID or whatever you want to put in there. You have the option of also modeling now out and protocol buffer messages as well not required. Some people have done it automatically just to make it easy. We anticipate control messages as we're the majority of the focus on certification will happen. We come with a palette of, you know, a handful of more maybe two handfuls of common behaviors and they're just, you know, pretty standard standalone things that transferables T non transferals till DT says the opposite. Subdividable and whole is the same so you'll see we're we're not we're trying to reserve the symbols singleton is essentially saying that it's non subdividable and it has a quantity of one. Mentable role support burnable will go through some of these as we go through so you'll have a sort of a rich palette of these available. Now behavior groups are ways to grab a bunch of different behaviors and is pretty configure them so we we have one example in the framework called supply control, which has meant burn and role support. And what it does is says, I'm going to model out the ability to create new supply and also remove supplies that's meant and burn but I want to enforce it with roles only certain people or people in a role or accounts in a role can meant new tokens. So I'm going to grab roles in there and I'm going to say there's going to be a group called mentors or role mentors. However, it's implemented call it mentors. And that should have add member remove member, you know, and have a pre check of is enroll and check that membership anytime someone calls meant. So if somebody calls mentor, it should check, you know, is the caller enroll to do that. And that sounds kind of trivial but this allows us to pre define that and have it be behavior group that's read instead of having to grab each one of these and reconfigure that again for that specific function we just compile them together into this thing called supply control. Now, that's sort of the shortcut underneath the covers and the definition you'll see all those behaviors and but they already have these settings set, you don't have to do that work. Again, we talked about referencing a lot. One of the main things we try to do in the taxonomy is not duplicate data. That's what you try your your remove as much duplication as you possibly can. When somebody gets to a definition it's sort of and you're pulling over the artifact itself essentially copying that the basic values or things that had values and then you can change them in the definition and some sense you'll have some duplication there. But if you don't change a value in the definition that has no values set. Or it sets to the default it will just stay with whatever the default is in the base artifact itself. But is anyway references just that reference. Here it's not just a pointer to the artifact but it actually lets you set the values that reference the actual artifact itself. So here's our template formula we talked about this is sort of walking through that same concept where your template formula again is just a list of ingredients. But then from a template formula you create the definition and this is where you're getting the individual references to the individual artifacts and putting in the values for each one of those that apply to the artifacts in context for that formula. The token specification is a document that's generated. You don't create a token specification you create ultimately you're the token specification is created from the template definition. So the template definition has a unique ID just like every artifact has a unique ID and you can say hey print the tokens or create a token specification from this definition ID and it will generate an open XML document. That you can then open in Word or Google Docs and print it out. You can save it a PDF whatever you want to do with it. But it is generated again if you see something you print this thing out and you see typos in it because words really good at catching grammatical errors and stuff like that. Can't don't change the specification go change the definition because it came from your definition. You might have to say oh it's not actually the definition it's actually in the artifact so you would need to like crawl back to the artifact itself and said there's a typo in your business description of this behavior. And I can make that modification in my in my tool and what it's doing is it's modifying your local get branch and then when you issue a pull request we'll see that essentially. Oh yes I fixed this typo or made the sentence read better. And that's just going to improve the overall quality framework but essentially that's what a specification is it's a printed human readable format and that the tool all the tools that I'll be talking about machine and common the framework itself and or self contained. Here's some just rules on grammar I'm not going to dwell on a lot of these. You can read a lot of these things in the documentation I'd rather get to Q&A as quickly as possible he was much time there. But you can see this these are rules for how we create the the grammar itself I've had lots of Microsoft research is like enamored with this grammar and they're they're running wild with this because you can do all sorts of things with. Code generation formal verification. But it you know it's actually quite useful. We primarily use the formula grammar just for classification. And for visualization and how you sort of visually create these things I show what these things look like in a moment is just some more grammatical rules like you can state a behavior is incompatible with others some are just obvious like you can't be transferable and non transferable. It's just you're either one of the other. But you might have some that behaviors can influence other behaviors like they don't make sense standalone and that is like one called delegable is an example so delegable means that I can delegate. Another behavior that I apply delegable to to another party to do on my behalf. So this is typically I'm going to give my broker they can transfer on my behalf up to a certain number of tokens without going through some business process. That's what we call delegable. Delegable makes no sense by itself it has to be applied or influence another behavior. So you'll see that. Here's the classifications we start things we build these natural hierarchies where you have this sort of generic based token is abstract. Nobody creates just a base token and you have branches fungible non fungible and hybrids and from underneath each of those it will branch out so you get to actual definitions themselves and you can visually see you know how a fiat currency relates to a stock. You know what are their common parents and things like that. None of this is like actually that the hierarchy is dynamic you can pivot it and create new trees visually from the metadata. So we're seeing all sorts of interesting ideas and I'll show you some examples of that in a minute. The hierarchy itself we just use the we start with branches that start with a fungible non fungible. We initially started with just fungible non fungible but we said you know you have to declare what is a subdividable capabilities or but front. So let's just cut to the chase and not confuse everybody with all these different bases. And so we said we'll create five bases and you have your fractal fungible and whole fungibles. You have non fractal fun. So sorry whole fun no fungibles and fractal fungibles and then singletons. And then you have this hybrid which could be any combination of those in parent-child relationship. The branches from there sort of visually go out and say what is your your base token. And if it's hybrid it was that the parent base and what type of it is that. So then this is just goes and again how the hierarchies built this is more for people that want to create new visual hierarchies and pivot on perhaps unique versus common you could you pivot the tree like that as well. The token templates, you know map to individual definitions themselves as a part of the template and you'll see like end users will see physical names underneath the covers that will have a reference to its parent formula. Here's a artifacts are structured hierarchically this is the visualization of the folder structure and GitHub. So it has an artifacts folder and then it just has sub folders for the different classes and you'll see each, each folder itself will have the latest, which is the latest version they have individual version folders itself. The tooling and metadata has some interesting stuff built in there as well. Each artifact has what we call a set of maps and those maps are essentially pointers to either source code for a particular implementation could be finished solution could be like a so like a behavior can point to source code snippet like on opens up line or somewhere like that or it can point to a finished source code that completely implements that or to a solution you know maybe it's something you know on AWS or Google that you've already set up and it's ready to go or it's your solution that you've that you've got ready somebody can discover your implementation just by using the tools and get the framework itself. And then the other type of reference is something called an artifact resource reference which could point to regulatory guidance for example. So if there's regulatory guidance for a stable coin, we would have individual mappings to the regulatory guidance maybe by jurisdiction sec mass, whatever, we would have, we would map that and so maps you can have those rich and that's really extensible you can sort of do whatever you want to with an anticipate that might. That becomes in handy for things like co gen as well. So if you're going to start building tools off of this, you could create metadata and submit it and you know have it be in the framework itself. The model when you get it. So we get sort of to the when you you can actually grab the entire object model and then navigate it like this. So I can say give me the whole taxonomy one go and it will turn back a is on your platform like that's in Java or C sharp or go you'll get an object. So that has nested clad list of these objects or collections, and you just navigate through this and and look at these objects themselves. You don't need to worry about reading JSON or serializing it just use the programming interface and protocol buffers and as a g RPC interface on the front, pretty straightforward, really easy to use. So things that I'd like to talk to people that have been doing this for a while is to sort of say, you know when you you start declaring things like financeable doesn't mean that your token is going to implement finance logic, but rather it's indicating that your token will support being encumbered or attached or related to a contract, either on the same blockchain or something, some other completely different system. So I have the hooks in there to support the essentially cryptographic linking of a token to some other legal contract or something else somewhere else, so that you can quickly correlate those and trigger those and encumber things so I could, you know, have the financial behavior on a property title for a loan contract that's on completely different network that you can't get to but I will not be able to trade or burn that property title because it's encumbered in a different network of behavior. So the loan contract would have to go in and, you know, remove that encumberment by whatever the business processes and that loan contract. So it's really a way to define these contract interfaces not they're not purely contract interfaces that's one of a concept we're trying to get people to really, really, really hammer home that tokens are not contracts and contracts are not tokens. They might be implemented using the same technology and you might say, hello, this is like on Ethereum as a token contract. Well, it's not. Okay, tokens are contracts, technically, but it's confusing to the rest of the world. We don't want to do that. We want to say tokens are this, this concept contracts, typically will dictate the rules of how we transfer utilized contracts or tokens as a mediums of exchange or value between ourselves. So let's not commingle those things together. I'm about to wrap up here. Here's an example of the classification hierarchy. This is a dynamic view you could sort and pivot this however you wanted to. There's the old design you saw the new design. This is actually sort of this is what it looks like we have some different tools in the works. We have a workshop process where we want partners and members industry organizations to use the TTF as a place to record the outcomes of a workshop. We don't describe how you do a workshop that, you know, could be a pre sales engagement it can be a exercise and a meet up for a vertical industry group, but you would go through and you can define individual artifacts and then record those in the taxonomy tools so that you can contribute them and have those be reasonable so that becomes like an insurance industry you want to you want to define the insurable behavior and these properties that are valid for insurance so that supply chain groups will just reuse those artifacts so that you'll get the goodness across vertical groups. This is the last slide before we go to Q&A the TTF ends where implementation begins essentially TTF essentially stops at the specification definition. And then it has links to where you can point to implementations whether it's source code the implementation or reference material. So, with that I'll stop I do have some you'll see the next slides but I wanted to leave time for questions. Hi, this is Jim Mason. I unfortunately arrived late to the presentation, but this thing is fantastic as an architecture. So if you look at it, what's brilliant about it is you model beautifully in the formulas, the taxonomy has modeled very well what I call the exterior side of life for different token use cases and what that does is because then the metadata in a sense exists as a definition. It provides the opportunity brilliantly to automate a lot of the from the model, you know, onto the actual implementation which is excellent so thank you very much. Oh, thank you. It wasn't a community effort. So, I anticipate the folks on the call we want you to help us do this and this is this is like call to action for everybody is like lean in help us out here. Okay. This is Manny from SoftSub. What kind of a tooling is available or at least an early stage for modeling these things? Very good question. So, we have in the, when you clone the GitHub repo, when you first clone it, there are tools in there. The first is, you'll see the raw artifacts folder and don't go there. I mean, unless you just really love editing JSON directly, rather there's a, we have an object model to find in a separate folder. You can navigate this just all clearly documented, but there are tools in there and one is called the taxonomy service. The taxonomy service is essentially a crud create, read, update and delete GRPC service that you can stand up and it will essentially load the taxonomy. So, when you clone it, it will load from your local artifacts folder and create the object model that we call the Tom. And the Tom is essentially that structure we showed and then you can just make a single call to that service and say, hey, give me the whole Tom. When it's local, it's not a big deal. You can get the whole thing and have it in memory. And when it's in memory, we show you the client. We have a sample client that goes through and creates new artifacts. You can modify artifacts. You can create a definition from a template and you can print specifications to the print the ability to print them to have the basic object model, the, the service that serves up the object model and supports reading updates and deletes to that so that but it does it to your local copy. So if you accidentally a bunch of artifacts until you issue a pull request, no one else is going to see it so you can cheat yourself from the foot, delete it and start all over again. So that's, that's a good thing. And then so it has that with a sample client. That's one of the lowest level where we'll soon have, I was hoping to have it. This week it looks like it might be next week, but there'll be a browser interface very simple taxonomy browser. That's essentially read only so someone can go and look at each artifact and read them without having to clone the repo or browse the GitHub repo and look at each artifact and JSON, which is not a really pleasant experience. And that's one and then the other tools that are in development are the visual modeler that you saw Microsoft. We're building one here at Microsoft for Visual Studio Code. That's actually we want it to be reusable and we're donating that into So you could host it and your own website. You don't have to use Visual Studio Code. It's just a set of react pages. So we're sort of contributing that and then we have other partners. So the we're trying to create an ecosystem of people using this as tooling because once you have the GRPC service up and running, you can grab the taxonomy object model on any platform, whether it's web, Java, go.net, you name it, and then do whatever you want to with it programmatically because it's very easy to work with at that point and create your own tools. So we've had some people think of the printer as a tool that's just using the open XML object model to create Word documents or open XML documents themselves. So those are the tools. We sort of put a call action to the tool manufacturers or tool makers. We have three projects in flight right now. I want to in the TTF itself for the web application. We have one and the Visual Studio Code team. And then we have one. That is actually has some tools around the workshopping that a company called Invision Blockchain has been building around sort of the process itself, but also you're looking at building tools to facilitate workshopping itself. It's been a great presentation. Thank you for coming. I have a couple of questions. One is, you know, you did mention that parts of the roles definition which would have identity implication. I would ask you to present on the identity working group on those topics. The other thing is you mentioned that, you know, there was a reference token and another kind of reference token implies some kind of a real world interaction. So would you say that you need some kind of custodian or something like that to implement that reference token? No, the reference versus values, the value is reference versus intrinsic. So it just simply means the value of the token is referenced elsewhere. The token itself by itself. Yeah, I understand. That's it. And we're not taking it any farther. We want people to define sort of custodial behaviors or behavior groups. And that's, you know, we're encouraging people to look at that. And we have lots of people rushing to custodial implementations without really defining what does it mean for custodial services. And I think that's an awesome exercise that somebody could use the token tax only to model the business process after. Hint, hint. I agree with you. That's a totally, that's a huge area. Yeah, to follow up on that is that, you know, we are part of these, I'm not sure if you have noted the common domain model for the capital markets. So where we go to all these details of contracts, how these contracts are defined in the real capital market world. And definitely I see at some point where there's an actual transfer of value comes in the token taxonomy and the artifact is very, very useful. I had actually asked that these members participate. So I think at some point we would like to reach out and see how this could be incorporated into a CDM modeling itself. Yeah, I think the same way. And we purposely sort of really when we scope this out was this is not about contracts right just tokens and that is the work that they've done is actually we would want to have this be integrated with. They complement each other. At some point, I probably would like you to come in and just give a quick intro to our working group so that we can start the effort of integrating the contract work with the token token. You guys have done a great job. Great. And the last question is, how do you see the Hyperledger, the Hyperledger community interacting with this particular effort. Very good question because we don't deal with implementation. There are a couple of things that we would look to do is we are very interested in creating frameworks implementation frameworks for how you would. So a lot of the certifications for creating, like if you created a token spec, how do you certify it for hyperledger fabric. I think it should be a project within the hyperledger fabric community. Say, hey, we've got we've got this, and then perhaps provide rappers and starters and SDKs for creating TTF compliant tokens on Hyperledger 2.0 or Fabric 2.0 or we've actually we made, we have a product called Azure Blockchain tokens that we just announced and it's all about this as well as finding tokens, but how do we create a snap in model where anyone can write a token for any platform, whether it's hyperledger fabric or Parthicorda or but but have a common interface and that's one that we've said we're ready. We want to do this and we'll do that in the hyperledger fabric ecosystem because it's an implementation that we want to have brought everyone sort of come into so we haven't formally proposed that but that's like we're really close. And because we think that's super important. And you're right. I'm sorry. I think we have to close the meeting now because I think some of the next meeting already here. Sorry Peter, I saw your hand up at the last month minute. We will interact with Marley on the mailing list or somehow in a asynchronous manner. I'm going to stop the recording and I'm going to ask I'm going to thank Marley again for appearing and giving such a lucid nation on the very complex topic. Thank you, Marley. Thank you.