Tokenizing Short-Term Debt: Building On-Chain Infrastructure for Invoice Factoring

Transcript

So thanks for being here today and the stage is yours, Philillip. Give them a round of applause. Thank you very much. All right. So this talk is about a project we as 20 squares have done for a client that asked us to um implement a design a market design are a pipeline from tokenizing um offchain depth into the blockchain implement markets primary markets secondary markets and then also think about the settling mechanism back and how it touches again into the fiat world. Um the starting point for this project was actually a narrow use case and I should also say this is work in

progress. It was initially started by inverter that brought us onto the project. The context was a factoring use case in a specific scenario. Um the stuff I'm talking about will be you know written out up in a white paper and also open sourced in a couple of weeks. Um the factoring use case was embedded into an institutional structure where the government already has a digital invoicing system in place and the task was principle to build on top of that. uh while working on the factoring we realized relatively early that um the components we need to define which are obviously driven by lots of constraints that I will talk about also in a minute are in some sense more flexible and at that point we started out saying okay let's try to think about this in terms

of a stack of modules that can be reused in different contexts um the talk will focus on two things I will talk a bit about the design principles that we want to apply and also um on the discussion of the stack and also the components. Now I have 20 minutes or 18 minutes something now. It will be short and high level. Before going into our design, let's talk about very briefly about the context. Um this is a slide and you know the topic itself is obviously quite common. Many people talk about this. Many people think about these issues. So why would you be interested in tokenizing depth?

Um there are many reasons. One of them is obviously that if you have a depth contract between party A and party B which is typically a private contract it's highly illquid very often opaque which is very hard from pricing perspective and obviously also high friction because there are lots of legal and regulatory constraints and the legal and regulatory constraints are specifically relevant if you want to go be beyond um a bilateral pair between A and B let's say seller and vendor in terms of an if factoring case but um Basically holds the receivable and once wants to sell it off or wants to liqufi it at that moment party C enters in and that typically creates a lot of legal frictions and regulatory frictions as well. Also for C if C again wants to kind of sell on or restructure the debt.

Now thinking about the blockchain system or tokens in general is pretty evident and quite obvious. Many people have thought about this application or other applications as well. So what we are talking about obviously has many other teams and projects working on from different angles. Now three obvious thing you can standardize the depth instrument you make it audible you can also track information over time information is key specifically if you want to price things that again keeping track of information is relevant if you want to go between or beyond the relationship between A and B but let's say C and then maybe also DE etc and lastly you might have composable claims which is very nice because you can very effectively and efficiently form portfolios

okay what's the outcome very simple We are creating a market that's hopefully more efficient so it serves both sides. Those who are seeking for capital get it at cheaper price and those who want to invest basically have new opportunities and new yield. All right. What are the core principles? Uh key thing not surprising in the blockchain world is modularity. Um we want the pipeline that I'm that I basically will introduce has several components several stages. They should be reusable or repluggable as well that if you need to make a change, you're not affecting the whole stack and you can do easy upgrades. Very straightforward.

Another key thing is risk. That's the bread and butter of adapt relation. Um party B which basically is under risk that A can't pay back always needs to be in a position to understand what is this risk and possibly also how to price it. And that obviously is not only true in a bilateral relationship. Again, if you think about a supply chain situation where a supplier and um the buyer basically are in a long-term relationship, clearly understanding the risk is relatively easy at some level. But again, if you're breaking that and want want to go beyond the bilaterally existing relationship, then things are more complicated.

Information tightly linked to risk clearly. Um again in the supply chain scenario and factoring scenario if I'm the supplier I have a lot of information about the party with I'm interacting but again if I'm selling on along the chain and want to sell the the dep basically further along the line then clearly information might get lost. Um that is obviously true if you're outside in the offchain world and onchain there is a question of how can we keep information around so that everyone basically has the information to as best as possible price the instruments tying it also to risk clearly information is tightly linked to that uh and also the question in the system of the design from a principal perspective the question is

who's actually carrying the risk which you have to think about a default and if you're selling on who is actually from a financial and economic perspective affected and what are the incentives behind it? Now clearly um this is a whole that thing itself how to keep information around how to keep track of it. You can have a a very long discussion and uh basically its own dedicated session on this. The thing is obviously what we're trying to do at the moment is to compromise um where you have some onchain proofs you have an off-chain component that basically stores information let's say information about balances etc that are not yet uh in an effective way be able to put on chain at the same time the reality is

you also need to think about privacy it's important but also it's legal and regulatory requirement and then lastly um if you want to build a marketplace incentives are key this only works if capital as well Does those who are seeking capital have an interest actually using this market and obviously also for other parts parties involved involved in the system we have to think very hard what are the incentives and also how does it link to information risk yeah I mean this is pretty standard there's no no surprise there um we need to align the the all the players in that platform to basically provide liquidity and also use it effectively without uh wrecking the design what are we doing we have at the moment

we We have six components that are basically you can think about it as a pipeline. You start on one end which is the the digitalization step. Then basically at the end there is the settlement default handling. In principle there's a seven step basically linking things together. Um but that's pretty straightforward at some level. Okay. I will go through these components. Um what is important to understand is that they are the outcome of thinking about specific on several use cases for parts or specific applications. You might not need all of these elements in the stack. For instance, I have one which is called risk assessment. This is basically providing the possibility for external services to inject risk assessments.

This is not something that is necessarily need needed in all cases. same you might have cases maybe because of uh regal legal reasons that you can't have a secondary market easily. So that might also be a component that is not available or not relevant. And lastly what is important to understand if you think about this as the pipeline going from you know offchain into uh handling and then back. Um, if you make design choices along the line, for instance, if you decide on the primary sale, let's say you have an auction, clearly there are dependencies between the components that come later.

Okay, what's the first step? The first step basically is pretty straightforward. Um, it's the idea that you have some kind of relationship in the offchain world between party A and party B. uh you need to make sure that whatever is the underlying thing that you want to uh tokenize actually is unique and real can be tempered with can be manipulated with. How you do this? There are various options for this. Um in the case of the factoring application that we have been looking into as I alluded to before that problem is basically solved by a government uh structure that is enforcing invoices to be sent into a system for the reason of um tracking taxes. So in this case we can basically leaning on that specific infra infrastructure but obviously you

know if you don't like that and you're looking into another market where these kind of interventions are not happening by governments um there are also private many many private ways of doing this. The tokenized step then basically is the first step once you are in the digital realm you can you know there's a putting it on on the chain step. Um what we are doing at the moment is and again think about this as abstraction barriers. Um once you have once you're looking in a specific scenario let's say factoring but you can also think about funding projects. Let's say you have a construction yard someone needs or has a very lucrative contract but needs short-term liquidity in order to fund or buy uh equipment or material for it. At that moment um you might be looking into um a very specific unique element. In

the case of factoring, if I'm looking on the universe of companies and I get a lot of invoices from these specific companies, they might be relatively similar. Now, XUN to make that system flexible enough, we don't know what exactly will be the right or the best assumption. So the the thing that we do with this module is essentially introducing a step so that uh as an abstraction barrier we assume very conservative stance namely each title that gets tokenized is basically unique. Yeah, which again if you think about factoring A and B let's say two invoices consecutively happening over the years over the years it's quite likely that these the two different invoices and receivables in the back will have the same risk.

So again as a starting point we assume each title that we are tokenizing is different is idiosyncratic and now you can think about what are the natural next steps is how can we make these things at least partially more functional that's basically the rest and also these different modules serve exactly that purpose of providing different setups and cases for when this system or when the when the different titles are actually easily tradable or when they are not when they are really different. Okay, one scenario is the following. Um, we talked about before you need some risk assessment. This could happen on the individual party that is actually buying things uh in the market. But in the case of factoring, this might be not very effective in the sense that there

might be a large universe of companies that you need to basically monitor. So how do you do this? One option that we um introduce is basically an extra module. It's a risk assessment module. The idea is you have an onchain registry of accredited raers. What do they do? they can basically attach scores to the NFT before and the idea is that this score might then be used as a classification schema for the primary market that comes next. So you might have four categories and you're looking at a universe of receivables in the factoring case that are very much the same and then you basically have different ways of um allocating them or selling them to the outside world compared to if I'm really looking at

let's say individual project based tokens that are uh very very very idiosyncratic. Um maybe as a side note a bit um the idea of rating agencies or basically partners entities that do this is has a a mixedback history. In the past let's say 20 years we had um specific problems with some of these companies in the past let's say it like that. So here's an additional thing where if you are tracking this information in a much more public and transparent way, clearly there's also room for down the road introducing a reward and penalties in principle for the behavior and for the accuracy of these ratings. There are problems to be figured out etc. But at least as a possibility um this is a

novel route that is not available outside. Okay. Um primary market kits. So what are we talking about? Um Starting again from the under from the assumption that we have unique NFTs representing specific titles. Um, by the way, these titles are relatively simple. We're talking about short-term depth, which means there's a maturity, there's an amount, um, the parties involved, and then possibly also offchain data that is um, relevant. Now, depending on the kind of tokens and the underlyings you're looking at, you need flexibility in how you allocate them. So, let me give one example. Um if you have uh let's say the project based construction yard example

maybe€1 million euro in total um to allocate this and a similar um project tokens it might actually sense to really just sell them individually. You could use an auction for selling them on an individual basis and that would be it. A next step towards making things a bit more funible would be that if we have um NFTTS that have similar risk structures and have been asserted like this then we can basically do batch auctions on them. So you bundle the risk by TR basically and then you do this step by step and basically build sell the whole bundle at once. And lastly, um going a bit more in another direction. If you want to go more into a DeFi scenario or setup or market design, um there's something very simple you can do. Well, you basically

build some kind of monetary market fund equivalent that buys NFTs at a specific price um that you can algorithmically set. You can also govern it if you want it. And then in that case, the NFTs go into the pool. basically when they're mature they their rewards go into the market is go into the pool and they are basically buying up again the next trunch of NFTs now if you do this then you can have a participation from an investor side in the pool you're basically holding an equity share equivalent in that pool and um ideally if the thing is well designed and works well and the economic conditions are right that thing will create value over time there are also other considerations in this case clearly that is are

important to allude um in the pool case you are sharing risk across um different parties. So you also have to think about moral hazard essentially is there actually one who's monitoring it and then which is also relevant there's the question of what happens in default all of that will have different consequences in the case of the pool you principle can um enable a structure where the pool itself has ways of going after defaulting entities and basically try to get the proceeds in Okay. And then lastly, um, liquidity and settlement. So in some cases, you might actually be interested in a secondary market. So that after you have done the

initial selloff, which typically involves the scenario again of A owning to B, B trying to sell it off, getting liquidity, and then what happens if C buys it. Maybe this stays with C, but there are good reasons why if a market has a secondary market that C can basically sell it off again that this might overall increase liquidity and also make the market more efficient. Now I mentioned before the pipeline we are building is contingent. So if you're making choices on the primary market clearly that will have an effect on what you can do and what is in reach on the secondary market. So again if you're thinking about an auction then clearly you have to think about some kind of OTC design afterwards which might be complicated which also not be liquid enough and have other also regulatory

hurdles on top in the pool path. Just to uh contrast it there you are basically looking at a participation token and that token might be tradable uh on your preferred exchange. So again and not to kind of to oversell it but in the not kind of to make the OTC case too bad. Clearly also in the pool there are many many legal questions. I'll come to that in a minute. And then lastly the settlement obviously happens. So you have to have a pipeline for um getting the feared stable swap basically done at the beginning and also at the end. The assumption is that partners seeking liquidity will not be active on chain themselves. So you need

to have a lot of integration which boils down to many mundane things like EIP integration and other parts that have you have to have in place in order for this to work. Now in this case in the factoring case that I alluded to before um a large chunk of this is already done because invoicing etc is already digitalized and is enforced by a government platform. Yes. And then lastly you have also this question um if someone is defaulting or payments are late clearly this is behavior um and information also that you can feed back into the platform. Now it's not totally evident how you want to do this. You might want to say that the platform is basically agnostic. It's the task of those who price risk to include this. You make this information maybe

public but that's it. But clearly um you might actually also more actively design the reputation system and the consequences of that. Okay. So very briefly again summary we have an oracle phase then we have the NFT basically as a base base assumption on what is the risk involved with behind a specific title. We have a phase where possible external risk assessment happens. We have the markets primary and possibly optionally secondary and then also the settlement part. So again reminder what is the idea? The idea really is to have a modular components in place for the different scenarios. So um the factoring case is one but um

theme liquidity is a big concern uh in many countries Europe in particular where you have profitable business that don't have access enough to short-term liquidity even if profitable. And in some sense the idea of building such a pipeline or is you know at least making a partial contribution towards improving that scenario the situation. All right let me end on the following. Um all I said before about um what what we designed and what we kind of did in a collaboration is actually straightforward and pretty simple. Uh it's not complicated in the end if you do it. There are options there are trade-offs but you have to go through the trade-offs. The actual kicker is obviously the legal part. Um this is the actual challenge.

Depending on where you are, depending on with whom you trade, whether it's going across countries, um a lot of complications arise. You might have wondered at the beginning, why do we have the six stages? Um it's not because we feel like six stages make a lot of sense purely from a market design perspective. But we need sometimes barriers in order to be clear and steer clear of what are the consequences of moving from one level to the next so that it can be legally figured out. can put into a frame and you might also make a a decision on what is the market structure purely on legal and regulatory uh information just to give you a flavor and again many of you will know about this if you think about depth contract which is a private contract between party A and party B you can't just sell it off to party C you

need consent that consent actually extends into the question of can you actually what can you digitalize how can C then again sell to D so you need also secondary consents on all levels um What is the legal status of the pool that I mentioned before? Don't ask me, ask a lawyer. Uh it very much depends on where you are. And then again, that's the key message basically so far. The legal friction remains the key thing that disturbs all of this wonderful nice abstract thing of compositionality along the pipeline.

Okay, I don't want to end on this in this bad way. So, we have been working on this. Let me very very briefly say something on this. We have been banging our head against it. uh and we think we have a possible path forward that we are working on now and you know stay tuned to hear something about this hopefully also in the near future. Um very quickly there is a very oldfashioned instruments based on negotiable instruments that could be used some countries updating them on a new legal level and that might be actually at least at least it's our belief in the belief of lawyers we work with a possible entry point in achieving some form of composibility that you're not needing consent on all levels and you make things hopefully that's the goal tradable aggregated you can disagregate if you want uh and hopefully

less and maybe even no structural legal regulatory changes when traded Again, think about party C having several receivables. At that moment, they are refunding it. They're typically doing some synchronization. They might be running a bank. They might have other financial instruments behind it. All very complicated and obviously a transition from the original relationship. Thank you very much. Thank you. We stop here and continue