TE Unplugged – Tokenized Value: From Utility Frameworks to Financial Frontiers

Transcript

Mark, if you like to introduce yourself briefly and then we kick it off and of course we are open to questions. Um Mark, feel free to prompt whenever you think we should provide some room for questions. Stage is yours. Welcome. Thank you. Uh yes. Uh hello everyone. Thank you for uh joining us for this panel. Uh my name is Mark Richardson. I'm the uh project lead at at Bangqua. Um I've been working there since um the beginning of 2021 on an official contractor basis and since 2021 as a anonymous volunteer for the project. Um and I've been uh the project lead there since October of 2022. Um Vicil and I have known each other um since way back

in those days during um sort of the early stages of TE Academy. Um and I think this is uh Phil and our first opportunity to to speak um together. Um I wanted to premise um this panel what I what I see my purpose is here because this is I think a little different from the kind of panels that you usually see at conferences maybe not so much at ECC but certainly at things like um token 2049 or something where often the pan the the panelists are here to um to essentially pitch you on the the strength the investability of an idea or something like that and it's the moderator's job to sort of make those

ideas as compelling as possible or give the panelists room to present those ideas. That's not the case today. Um when Angela asked me to to do this, she used the word peer review, which for me means uh to scrutinize and criticize, right? it is um the you know the the the strengths of the ideas that we've seen our our two speakers present will have to you know stand up to that scrutiny and criticism. Now that's not to say that it's mean-spirited but it might not feel as um you know pampering you know I think as as some panels often do. Now my other purpose is to um bring some structure right to the conversation,

some continuity um some shared symphony between the intellectual ideas that we've seen both of our speakers present. Um and from the outset it seems that uh these are two very disperate topics. I'm going to try and convince you otherwise. I actually selected these two speakers as a part of the the process leading up to today. So this is no no accident. um you you were both handpicked right from a very long list of of potential speakers and I want you to know that I'm very pleased um that you guys accepted this invitation and it's my honor to be doing this process with you now. Um, so I think the structure that I that I decided on and that I shared with you guys leading up um to ETCC is that we're

essentially going to take the the macro view that Basil's expertise leans into and then slowly sort of move down the funnel towards the um you know the minutia of the engineering decisions um that Phil is is explicitly dealing with. Now uh Vasili um, from, uh, you know, value verse has sprung forth, I would say, um, from work that you've been doing since long before Valverse would have been completely conceptualized. Um, you presented, I think, uh, just briefly the, um, a familiar image to me, the sort of periodic table of of tokens.

Um, I think a really good place to start this conversation would be if you could actually just tell the audience how that came about. um maybe um you know in the the beginning stages of of token engineering discussions and like how long it took to even develop that and whether or not it's changed over time. Yep. You mean the uh the periodic table itself or the you know just basic approach to distinguish or survey mechanism and implementations as you wish. But I think that the the thing I want to drive at is that this this periodic table is something that you're you're trying to discern intrinsic properties right of the value of a token. This isn't you're not speculating on the price of a token

necessarily. It's more exact than that. Yeah. Yeah. So I think all my work started uh at the point when I understood that discount token is not separate class of tokens but it is a conditional action the amount of product that you bought or used with the discount and the amount of cash flow that you essentially saved from using some token as a discount token. So this was the I think the first step when I start to think about all of this because I understood this is not like discount token is not like a monolytic type of thing. can be subdivided and then uh start to consensus like work tokens like and and the predict table was much um much later because uh so I created this or of value and mechanisms and I shared it with

Angela and so I showed it a lot but there was no table and Angela said me silly if you want to present it on know some place maybe it was ah it was a TV read you you because I shared a lot about the table that I will create it but I never create it and she said me if you will not create it I cannot put you invited this newsletter oh my god I I need to do it super fast and uh I created it over four hours because I I understood that I have enough mechan that I identified to uh you know combine them into some structure that has some rows and stuff and I can make some logic there not just you know put there to to have some picture but have a logic why this mechanism in this you know square.

So this how it happened. Now the um when you first started speaking to me about that I think around 2020 um you know there I think one of the pieces of feedback that I had for you then um is that um you're it's almost like you're imposing a a superficially well-defined structure right over something that is continuous right like it wasn't clear to me then and maybe it's still not clear to that um you can necessarily discretize the the types of value capture in such a a clean way um and that you know by doing so you may um you know be

obiscating some of the nuance there in the sort of continuum and how these things bleed over. Uh one of the things you said to me then was like yes but these things compose together things don't necessarily fit into a single category but they might belong to to several different categories at the same time. I think I have a similar piece of um you know um criticism to to give to you today which is that with the AI models in particular one of the things that they are demonstra demonstrabably bad at is understanding nuance right and I I wonder um if you could comment for me on how much faith you actually have in the AI's ability to do the work that you have been doing right since 2020 in

the sense that um you know the AI may not be able to detect the the kind of hubris right that people inject into their white papers in order to describe their token that you might decide to remove from the analysis whereas the AI is going to take it at face value things like that. Yeah. So uh for AI I think the most important step the first one is to identify all origins of value distinct ones in the token and second is to combine them into the mechanisms and u of course the more verified cases that are like 100% correct we have the better is AI from one point of view from other point of view so we have a special like a database watch is what is for example the value transfer right in different

projects that we are uh 100% sure that it's correct and I see okay transfer chain link is this when they transfer in ethereum is this when they transfer in unity so in we don't have any transfer in bitcoin is this for example so um I think that uh like a lot of tokens on the market are similar even we have a lot of them but they have different changes in design for example what is grow economics right very popular uh like family of mechanisms right we have curve we have for example veeradrome if you will see there are different structures but the the overall princ disable lock token for a long time aligning you know incentives of the community and pre preventing some governance attacks so you cannot you

know borrow token vote for something bad and return it to the uh lower price efficiently shortening it right so I have uh faith in AI to analyze tokens and created like database records but about the future investment analysis I think it's much more complicated because it has much more factors than intrinsic value so this is the like bigger pain point for me than just create a database. I think the creating a database is easier than creating results on top of the database. Now, some of that nuance um that you know I'm not saying that I'm not confident that the I'm not saying that the AI can't do it.

I'm just saying my confidence is low that um I think AI is capable of understanding that level of nuance. Um and it relates um to something that Phil had in his presentation as well. Um and so Phil, I'd like to to ask you to comment on this um very briefly. Um, but you you pointed out that there is um I mean we're going to talk a little bit more about some of the things that you mentioned. Um, but specifically that the there are design um there are design aspects to um you know the the debt market that you're hoping to create. Um things like um you know you said that um there might be scores attached right to these NFT tokens or maybe there won't be an NFT token. you you'd mentioned that

you might have a liquidity pool for secondary markets which implies at least an ERC20 standard or at the very least an ERC 1155 standard um and that it's possible at least in you know I know I have a strong opinion about it that I think that those specific design choices will actually impact you know the the way that um one of these tokens would be viewed under whether it's you know Vicil's uh rubric or or any other rubric um and so I wanted to get your um you First, whether or not you even agree with me, like does do these specific design choices fundamentally impact the nature of the vehicle that you have at the end or um is it you know is it more well you agree with me so go ahead. No.

Yes. I mean that's the whole point um the whole point of I mean if it would not affect it then we could just design one pipeline for everything and it would go through and then you know whatever happens. Um there are again there are dimensions to it. One is I mentioned at the very end legal. Um let's put that aside for now because I think that's not relevant for what we're discussing now. The other one is also getting the liquidity into the market. So the question is what are you actually selling and who could be actually interested in in in buying it and depending on the structure. Um again if you think about the example on the construction yard it's a very specific thing very narrowly defined. Um how many actors in the market right now are able to actually think about the pricing for

this thing? There are these exist but they are specialized. So there's no point in trying to make it over complicated trying to you know cater to a mass market in a sense or trying to cater to non-sophisticated um actors that do not have their own pricing in place. If you think about factoring on the other hand um I mean there are factoring companies in this world out there and what they do is they basically provide a service for the companies involved good or bad you know let's put that aside and then they are basically tapping into financial markets in different ways. they're refunding it through specific vehicles. They may be securitiz securitizing things. There might be also OTC sales to explicit actors in the market. Um on that regard, I think improving that pipeline, maybe creating more efficiency is clearly

something. But for that to work, you can't expect final people who buy this at all levels. Except if you're really just again tapping into the same market as before, you can't expect them to do the pricing only on their own. So you need to provide information and have actors as basically intermediaries and as service providers in such a market in order to reach the end of that pipeline. Yeah. Okay. I it's you and I have consensus I think on on this specific point. Um I want to go I want to push you a little bit farther though which is that um one of the one of the things that you sort of um were a little bit ambiguous about during your your presentation was that with respect to the the the risk property right of the

debt itself. This is either something that you build into the pro like at the protocol level or you sort of allow market participants to shoulder the responsibility for that themselves and I think that at a at a fundamental level that's like night and day right that it changes the asset fundamentally I was hoping yes discuss yes okay so I agree with you and in fact the design we have is exact is in someense is trying to accommodate this um in the following way when I said before that you know we have this digitalization process which has its own risks by the way which I brushed a bit of a side that we just say it's solvable and in a specific factor in case it is we have a

you know we can have a high degree of confidence of being solved um the question is basically what is the instrument then doing and let's say give you an example to what we do let's say we would be directly saying this goes onto a pool um and then basically something in the pool happens the problem with this is depending on what you do how does the pricing actually work how you know algorithmically and is it actually accurate would it basically work in the market environment so the idea is to have basically one step in between which is the second module this NFT step where we basically take a very conservative and totally nonopinionated stance that we say each title is in itself idiosyncratic which is not realistic but it's basically basically a safety barrier if you want from that moment on you can apply it and you can

say look I'm looking at this project again construction yard example it's really iosyncratic there's no point in bunching it together. In other cases like the factor in invoice factoring for specific segment of the market which might be relatively risk-f free at some level um it doesn't make sense to think everything is separate but the idea of having this barrier in between is exactly for allowing different use cases and applying it and basically specializing it to the specific use case at hand. Okay. um facility the um okay with respect one of the things that you mentioned in your presentation um and I I wholeheartedly agree with you right there they're there one of the the massive problems that we have is that

there are so many tokens and there is so much information and not even all of that information is good right there's probably equal parts information and disinformation or maybe even more disinformation than actual information um and that's usually Like when people hear that the it's very natural to assume that okay that's a one token per project problem like you know the fact that there's too many tokens might suggest that there's too many projects or something but actually we're we're the day has long come and gone where you can necessarily say that for each project there is one token right even within the curve universe for example there were things like you know the um you know the the curve governance token

and and various rappers on that through things like um convex finance and and other things. And so you end up with this entire you know plethora of of related tokens. Um, and this is going to come back to something that that Phil is doing, but I was wondering if I could get your comment just quickly on whether or not within that collection of related tokens that you can have like dramatically different sort of characteristics attached to each one of them in terms of the rubric that you're applying at value. Sorry, I I don't understand the question is why we sure that it's all correct in our database or not? Just just um high level is it a reasonable expectation that all of the tokens associated with a

single project will have a very similar sort of value characteristic according to the value verse rubric or can you get arbitrarily different kinds of tokens? Of course we can get different because for example curve has a v economics and for example conx they don't have v e economics you have just a v lock you don't have different duration there so it looks similar but it works differently and for example stake d as I remember is also v economics I think that tokens can have totally different properties and it is regulated only by the necessity of something so you can even maybe create you know the stable coin on top of curve that uses curve as collateral theoretically but of course maybe it's not good choice because curve is volatile and doesn't have a lot of liquidity for liquidations. We all

understand that. But I mean the theoretical you can even build a some separate third party stable coin on top of curve token. This curve token will be connected with the uh sorry the stable coin will be connected with curve because if curve value grows you can mint more stable coin against it you know use it more far more get more fees. Yeah. Okay. And um we we haven't seen it I think with curve or maybe we have but I might not be familiar enough with it but certainly projects like compound and ave um have very recently sort of overhauled you know their their tokconomics process and sort of decided that they want to discard right some of these auxiliary tokens that were created in the wake of the success that Curve

was having with its you know ecosystem and instead sort of bring everything back to you know having a single a single token. Um I I I wonder when you see those kinds of consolidation processes that you just kind of sum all of the characteristics or you know are there these you know are these economies somehow less than the sum of their parts or more than the sum of their parts like let's talk about this consolidation. It's it's always different. So for example as I what I know about Tava they introduced a proposal to to add some protocol fees in the token as I remember. So and it significantly updates the future value state of the token because we'll have a new source of income which is evidently boost the

token like at least some fundamental value that you can you know assume for it. So and for compound uh as I remember the you know it was just a governance token where you have conditional action and you know and governance so you can just vote you even don't need to stake because it's just like you need to have a tokens before the date of the proposal or you know the block of the proposal and Gab copied this approach long time ago I don't know anything that is going with with compound token but with I hopefully will automatically assume what is going on there but I think that uh it's not kind of consolidation probably it's they just build a new token on top of existing one understanding all previous mistakes and you know problems that were there for example in our you remember this safety

model right that was paying first from emission then as for fees and now they want to make fees for all token holders under some conditions so because now it became evident that in uh defy if you have a good you know fee stream why not to share it with token holders if you can find a way to do that the reason I wanted to talk about this is that um during Phil's presentation um you mentioned specifically um you know and in in not much detail and I understand in 20 minutes it's hard to to get that kind of detail in you that you mentioned a um a sort of tranched marketplace right where you would expect um you know certain risk levels I think to be distributed or this is at least

what I expected that you that you were referring to um and for each one of those tranches right this could either be represented by a unique EC C20 contract for example and this would resemble I I I imagine that you're inspired by things like insurance link securities markets and and how those are structured um and you know one of the questions I have got a lot of questions about that and it's possible that some of them can't be answered um but like first of all like is my impression the correct one right are you thinking rather than than have NFTs representing specific debt that rather someone puts together a prospectus or something and that there's like a basket of these debts that are

now under a specific UIC20 contract. It it's getting boring. Yes, you're you're right. Yeah, good. Um maybe let me comment on the trunching. So the um the the the again this module two basically where we make a conservative stance on each title being basically idiosyncratic is just in some sense to keep the flexibility down the road. If we are entering a market where this the the fungibility or the comparability the similarity between different underlying titles is not is not automatically given. The whole point about having this standard second phase basically and tying it together with the risk assessment is to kind of get to a point where we can bundle things together in different ways. Now there is of course a constraint. I give you an

example. Um if you have if the market basically supports I make it I make it up 10 invoices per month. They are all wildly different. they have wildly different risks because we're talking about you know a corporate doing doing the invoice and basically a startup doing the invoice um the risk will be wildly different. So one of the things that is very hard to predict and needs to be assessed on the spot for the specific market through quantitative reasoning and also for market design is how thick can the market be in principle that depends on supply as well as demand. I think demand per yield is less of a problem and you know as in particular if you can provide information and pricing actually can be supported and can become transparent over time. The question is the supply um and there is no recipe against it in

some sense just that you need to prepare and in some cases it might not even sense to pipe set up the pipeline right if there if the volume is too little then no point doing it and then there's a secondary question one is that if you think about it traditionally there might be actually reasons why these market are small is because they're regionally clustered even though if you compare regions actually they're relatively similar again you can make a case for Germany or your other European countries as well Um so that one way of getting a thick enough market is actually by doing this kind of digitalization blockchain thing because you're increasing the reach. This is a typical thing happening in again countries like Germany wherememes go to their local bank.

Clearly that specific thing will not be well priced for them because they have a local you know partial monopoly. Now if you tap into a larger market then it might actually be a teachable that you have these structures and they are thick enough that uh it actually makes sense to have them right. Let's say we do an auction. Does it make sense to have an auction? And keep in mind we're talking about things that are shortlived 30 60 90 days. So you were thinking about duration of of a year. How many cycles actually can we auction off and synchronize which is not so that there are also details there which are need to be taken into account. And then there is the pool where for instance the synchronization of maturity is much simpler there because you don't basically can ignore it from the capital provision side. Um

sorry I started off and I wandered off. Did I actually answer your question? I think you've done uh yeah, you you got close enough um to where I needed it. Um the the the the reason why this is significant first of all is because we haven't um it it's not true that tranched systems haven't already existed in D5 before, right? Um you might recall uh like Barnbridge um for example I think was the the the first to implement something that was um like the the splitting image of of something that you might see in traditional finance and they also had um ERC20 contracts specific to to each tranch um and so um Vasil back back over to to you if we were to apply the rubric right

from from value vers um let's say that you you know that um that you were hired as like consultants, right, to to advise on a project like this. Obviously, there there are all kinds of decisions that need to be made here. There some of them are um about practicability and you know, engineering implementation challenges and smart contract security and some of those things aren't necessarily always aligned with, you know, um the value capture properties of of the token and the system itself and things like that. And so I I I wanted to ask you know in a in a general sort of sense what is your sort of what would be your objective advice right for for

structuring these kinds of things? Do you always prioritize right or is there um is it true that you can even prioritize the um you know the the categorization of the token of of tokens underneath the the rubric that you've developed or is it more pragmatic than that? Do you sometimes need to say well you know it might not look like it has the best value capture now but at least you know it's implementable that sort of thing. Yeah Mark as I understand the question is how to design an utility token for this project on top of all these you know depths that will be created. So so depth itself is a representation so the token NFT token representing the depth is representation of real depth which is you know existing

right this depth it has some recurring payments it has some interest rate if interest rate is you know positive not negative it means that you have a some future cash flow if I own a depth assuming the depth will be fully paid with all the interest rate I will get a cash flow right so I see this as a as a representation and the future cash flow and all the technical instruments that I used oracles smart context as well they're all built around uh making this representation working well I think because you need to know the price you need to calculate the default score like chance it is that it will be defaulted.

So, so this is basically representation and using all the articles you try to notify owner of this token about the real you know properties of the depth what is really going on. So, and on on on top of uh this you know depth universe right you you have a thousands or hundreds of thousands of depths if this system will be scaled up enough right it will work well for example so it means that uh and you also want to make this trenches because you can combine it the pools if you have a lot of depth in your properties you can combine into the pools. So what we have here we have a lot of cash flow so you can distribute some cash flow to token holders but of course it's evident do we have some governance possibility I don't know but I think that probably you can

also get an access of uh people who can create depth and maybe underrite depth in this system and make some money on that because it's something you know that is not uh you know you cannot allow everyone to issue debt right you can allow everyone to underwrite debt for example so I think you get a cash flow in some form I mean if you for example do a buy back and burn or you do some direct dividends or you do something else it's anyway cash flow even if you do a discount it's also a cash flow but paid in natural form so I always understand that this is a cash flow so you have a cash flow in some variation you have governance you have an access so this is three type of you know origins that I see you know from

from the first side uh maybe there is chance to do some kind of Water scroll because I I mean why wat water scroll is so popular because I mean owners want to people to lock tokens right because they want to avoid selling but this is for speculators but we at the same time we understand that this token lockups for a long time protecting system from governance attacks and this you know because if you lock a token for a long time you don't have any motivation to vote in a way that will crash your system I mean this is the assumption general of course there are some bribes and we show how and we saw how in cur for example bribes changed you know the understanding of what people want to walk uh to vote for and how. So I think if you will ask me how

to do the talk and we go for a course for one hour and I will sit and just think from scratch you know just some you know friendly advice no responsibility for that right for example I will do what economics will get some fees from it uh to to make tokolders also know getting some profits for example uh also will provide some discounts if you have a big world scroll position you have some discount on something because I think there are some services and governance Because for example on the register of people who can issue that who can under that and you also need to have some sty tokens that can be alienated for doing this actions because if you do it these actions incorrectly for example you do on purpose not correct and writing of debt or something you can be slashed. So something like this

thanks um maybe let me tie into something which I think is very much related um on evaluation and also about the tooling um we we heard about um One of the advantages of doing something what we do in principle not immediately but down the road is obviously also the traceability and the transparency of information that gets basically assembled over time. And one of the questions that we have um right from the start and which is you can't answer it basically purely theoretically but you have to also explore it and you have to try it out at some level is um what information is actually needed for which parties and for what specific scenario.

Providing this information though is obviously important in a way that you can actually inform the pricing along the chain. So again if you're moving things by chain I mean the final supply chain in some sense. So party A party B has doubt adapt then sending it to C maybe to D and as you mentioned there might be secret secularization steps there might be other forms of refunding happening which turn which change the nature of the instrument and which might also you know we have seen this 2007 2008 that information basically is lost and that causes a lot of trouble in the pricing and one of the goals clearly is not to do that but instead to have a way identify information that is actually relevant. that's also linking up to you.

I mean if you have pricing models basically that require certain information that information is not there and it might be not obvious totally obvious that the information should be provided at the beginning over time it should actually be provided. So there is a it's not that thing is not we you know we're designing it and you know let's go to the holiday and goodbye. We will not it is meant to evolve and there are many questions in the in that in the specific um information but also in the in the structuring that we will evolve over time. Well, I'm I'm glad you brought that up because it was one of the things that I I wrote down um very early in your in your talk when um you said that, you know, so you had listed a few of the attributes of of tokens as

being like standard and composable and this kind of thing. Um and that the the codebase that you're developing or the framework that you're developing is, you know, intended to be modular, reusable, upgradeable, this kind of thing. Um and it's you know it's again one of these cases where um you know particularly in the at the speed at which blockchain development moves versioning becomes a huge problem right um and it it seems like you're you're saying two different things right because on the on the one hand when you when you're trying to produce a monolithic standard that's supposed to you know exist in perpetuity like you know um Simon dear Rubia's

standard, right? Which was perfect when it was created and will be perfect for the rest of, you know, human existence. Um, and then what you're saying is, okay, we like this idea because we can reuse this thing and, you know, that's this is why we're attracted to this paradigm, but then say that well, but we expect to evolve over time, these kinds of things like resolve this conflict for me. I mean I think I don't see a conflict honestly because I think I first of all I said before it's work in progress. It's not like the thing is deployed and we we shipped it and that's it. The thing that we are designing at the moment it's really in a development phase. So the classical distinction between development testing deployment that's similar what I see here. But the

question is if we are now designing let's say a fully fleshed out pipeline that is basically monolithic from end to end. Then we test it and we feel oh this works. But then the lawyer comes along and says guys uh you know uh what are you doing? So in some sense this mod the mod the fact that it's modular and modifiable is exactly for in the first phase of setting it and adapting it to a specific market. It has to evolve up to a point where we can test it and where we can verify yes it's working in an effective way. It actually creates a thick market. It's actually legally sound also we got basically cleared it's regulatory sound. That's why we want to have a building block that we can adapt it to a specific scenario can evolve it eventually of course in that specific

market. It should major and then it should not be about hey we're changing you know to version five in in one go. uh it should be stable but at the moment I think there's a lot of uncertainty about many of these components and that's why we are we emphasize this and maybe also on the market design there is there's a there's a contingency depending on what you structure in the beginning let's say the primary market has a lot of effects legally regulatory but also technically what you can do just from a market design perspective for the secondary market and we have to be careful if we now basically make a choice this is it that's the component we are not changing it what do we do then right if that's if there is no secondary market maybe there is no demand for it, then we would be stuck. I

I feel like you may have started making some of those decisions already, right? For example, um you know, you you mentioned that u in your in your modules um you had I think number one was the Oracle, right? That this is an irreversible design choice once it's once it's built into it in general. Um and um yeah, you also had you know I I remember you struck off a couple of things but then the secondary market I think was point number fiveish or something on the list and then um on the next slide is where we sort of went into the the ambiguity between NFTs or whether or not we're going to have liquidity pools and that sort of thing.

Um so okay fine maybe there is no conflict with respect to versioning and I concede the point. Uh I do think that there's a conflict between Oracle pricing and liquidity pool based pricing in certain circumstances. Obviously not um across the board. Um but I I I want clarity from you on that specific point because if you if you are using something like an oracle price feed first of all what do you mean right? Is the Oracle just providing offchain data in terms of that the risk has been evaluated as a certain number or does this you know what what is the oracle doing there? Um and then you know how do you see that participating in a liquidity pool based secondary market?

Okay. Uh I mean in principle there are two I mean I didn't say it explicitly but the risk module itself might be an oracle. You can conceive it like that. The the first oracle basically has a much more primitive thing. Um I'm a construction company. Um how can how can you make sure that the contract actually exists between me and the other company? It's a very mundane thing. Is the invoice set in the factoring case? I want to uh basically factor is it actually real or not. That's that's basically it. It's just it's basically about proving that there is some kind of let's call it asset or underlying that I'm basically want to base my my claim on my token claim that it actually exist. Now um to be fair and I agree with you this is this is not harmless at all in the specific factoring use case

we basically bypass the whole problem because as I mentioned initially in that specific use case there is a government enforced system that if you're uploading your invoice and you're tempering with it you are in deep trouble. So we can basically it does not mean that you get money back and there could be other reasons and we have to think about this but in some sense the whole problem is is orders of magnitude simpler at some level specifically also if you don't start you know if you whitelist companies um basically active in that system um on the on the pricing itself on the risk assessment yes so this is actually one of the things we are we have question marks um it is clear to us that for let's say for the factoring case we actually need some form of assessment from third parties. Um and

obviously what we do let's say we are building a pool and what do we do actually if the assessment is just bad or wrong. Um now the I mean first of all we have to think about ways of how to ensure the quality. This is basically offchain. This is just good business operations doing it. Um moving forward and thinking more long term you can also think about gathering information about this. um in principle it's not it's not easy but in principle it's doable and it actually ties also into an evaluation um are these risk assessments actually correct because I mean think about the instrument we have right you get a payment at the beginning and then you have to do a payment at the end basically a coupon right so it's it's structurally very simple this is let's say 90 days and you either make it

it's incomplete or you basically default so the typical thing is a relatively simple risk in the sense of mathematically risking it you need basically risk score of how how high is the probability of default or only partial payment. Uh in principle now if you're collecting enough information over time you should be able to say that you know service provider XY Z was actually doing a miserable job because they qualified things as A and it turned out to be actually D right I'm making it simpler that it is there are lots of practical problems and operational problems on the quantitative side to actually make this true but at least it's an opening up a design space that you can do and use over time. Now what this is not solving is the problem of how do you how do you

deal with it short term right so you need to have some mechanisms in place that um if the defaulting goes overhand which would be an indicator that something is not priced accordingly um that you have to intervene and that's one of the this is one of the things we are struggling with um yeah I think I'll stop you can ask questions totally reasonable um I I want to throw a discussion back to Vil for a moment um And I think uh I just want to ask a plain plain question which is like what is the what is the purpose of value reverse right like do do you pro um present it as like a consulting company right for for crypto projects to use or

is this more like an information provider that you know people are supposed to approach the way they would something like Wikipedia. I think that the volume is a data company. I think our main asset is comprehensive understanding of you know hundreds or thousands of tokens which are really needed by someone. I think this is the core and anything that you can build on top I mean valuation models any kind of you know AI like predictions for price or something is just a product on top our main uh goal is to very correctly assess what we have in the talk and I think this is the most important piece of the because if this foundation is not correct we can build anything on top so it's not not a

consultancy. I'm trying to focus not on consultants anymore. I try to focus on building this. I want in six months that you can just come and build. This is m much more interesting I think than just a consultancy. So but uh one of the questions is why uh the information in our database is correct because we can even you know if you have a it can already know some audited contracts audited website information can be incorrect. This is is a very good question and to be perfect it should be have it should have you know like kind of a dreily created knowledge graph or something. This is I think the next big step that I will need to do in the future to be because now I just showed

uh the general principle how we can decompose token and how can we scale it. It was not you know kind of you know shilling the project itself. It was more showing that you know the approach that I established that it really works at this moment but this is only piece of course I understand that now we have a centralized oracle centralized Oracle coin gek API right we rely on it we trust that coin gecka provides us true links to the you know website of the project right to the documentation with trust to the projectivity that documentation is correct and the contracts are correct maybe there are some new contracts that are not listed at all right maybe we can so this is all the assumptions and we understand it now we fully understand it now we just every database record is our vision of the

token and uh like our vision of what we found as information about it. Maybe it's different. Okay. So, let's say that we, you know, we went with a a type of um, you know, specific custom utility token, right? Um, that somehow captures the let's say the profitability, right, of the the debt market. Um and the the things that we we list off are essentially um you know that it's Oracle you know it's external Oracle dependent um and you know there are there are risk assessors and I forgot to get clarity on this um but it sounded like um that there is a a

field um where the the risk rating becomes like a you know stuck you know to the thing which implies that there are administrative permissions on on the token contract. Um and you know combined with that we assume that there are um um you know we heard from from Phil himself massive like legal um and you know regulatory barriers to you know to to getting this done like altogether I would say whatever this token would be or tokens would be um it's looking um you know extremely complex right do you think that the the analytical framework that you have today, right, would be

able to handle something of that level of complexity. Like to to what extent do those design implementation decisions impact the the score or whatever you would give to this thing? I think that it depends on the quality of documentation basically but actually a perfect answer but but let's think about so I proposed I mean like a friendly advice and joke with no responsibility I propose some token design but we all understand that uh the value of this token will be tied to amount of defaults because the more defaults is there the less cash flow this token will get right and less will be like the value of underwriting all these deps less will be the value of fishing new depths if you know you have a platform where a lot of deps getting to default so it means that lenders getting nothing that the trust is going

down nobody want to go because your initial assessments is not correct. So yeah I just want to add some on top that all this you know value capturing you know origins of value mechanisms it's up there based on the percentage of defaults if there is too big percentage of defiles it all goes to zero I mean the fundamental value of it um yeah maybe one thing on this so when we started this project this originally originated long kind of quite a long quite a long time ago as a research project mostly and initially we were kind of really thinking about can we do something radically new on the token design maybe you know think about what could be the token here I mean you saw what we do now which is relatively standard and one of the reasons

obviously is that if we you know if you come up with something fancy fancy then who understands what it actually is what are the risks involved and I mean as you said basically that's part of the documentation if you use standards that are well understood at some level um that's not enough but of course it makes it easier for people and also for systems to understand what are the consequences of this and also goes through sim simulations basically right um the thing that I would maybe also kind prompt from my side is that I mentioned and I alluded to that the legal risks are hard. This is in specifically if you go cross country um where you know underlying is a depth relationship between you know country A and country B or parties in country A and parties in country B um the practice of going to

court and basically you know enforcing some invoice um can vary dramatically depending on where you are right and it this is one of the things where it's very hard and this is something also professionals on the pricing side struggle with a lot what is the price and I think AI actually could have a a big advantage on this because if you have enough if if you have enough data and collect it on all levels there could actually be a way where you can price something better which is very much highly unstructured right I mean a zero coupon bond can be is structured and relatively straightforward I just want to add a few seconds so your depth is representation everything you build is a insurance quality of the representation uh your interest rate is a future cash flow and your pooling is a meta representation that collects all the

chances of default so so basically from the you know value capturing uh view it's very Simple the question is about the implementation how it really works and this is much more complicated but if I build this what I will think about I will I will think about to do uh this project inside one jurisdiction like European Union right you can make invoice between you know Netherlands and Germany like countries that are quite close and they understand legislation inside the United States you have a lot of you know states and people inside you can do inside the United States so the crossboard you know invoices I think maybe it's the step two only. Thank you gentlemen. We're going to have to uh leave the conversation here. Uh audience, please join me in thanking our our panelists. I think this was a terrific conversation. Thank you so

much.