Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Ava Labs x CBER Ep 3: Just-In-Time Liquidity At Decentralized Exchanges
6 Plays11 months ago
This episode discusses a phenomenon known as Just-In-Time Liquidity at Decentralized Exchanges. Agostino Capponi (Columbia University) explains that, while this phenomenon is generally viewed as positive for liquidity demanders, it can actually undermine liquidity provision. More specifically, JIT liquidity providers can pick-and-choose the best trades, which reduces the incentive for passive liquidity providers to offer liquidity. The consequent reduction in passive liquidity can lead to lower overall liquidity.
Recommended
Transcript
00:00:06
Speaker
Hello
Introduction to the Podcast Series
00:00:07
Speaker
and welcome to Crafting the Crypto Economy. I am Silvia Sanchez, Project Manager at OWL Explains by Avallabs, and today we bring you a transformative podcast series in partnership with the Crypto and Blockchain Economic Research Forum. This series features leading faculty from renowned global universities exploring various elements in the blockchain ecosystem. These episodes are a bit longer than our usual hootenannies, since we will be getting very deep.
00:00:33
Speaker
And also, each episode will have its accompanying paper posted on our website for further reading.
Moderators and Guests
00:00:38
Speaker
And with that, I will hand it over to our moderators Fahad Saleh and Andreas Park. Hi, everybody, and welcome to a new edition of the Seaburg Crafting the Crypto Economy podcast, where Fahad Saleh and I, Andreas Park, meet with researchers in the field of cryptoeconomics and trying to understand their work better and trying to explain this to you, our audience.
00:01:03
Speaker
I'm very happy today to have Agostino Caponi with us. And as we normally do, Agostino, why don't you introduce yourself very briefly?
Understanding Crypto Economics
00:01:13
Speaker
Absolutely. I am Agostino Caponi. I'm an associate professor in the industry engineering and operations research department at Columbia. And I'm broadly interested in topics related to market microstructure, crypto economics and financial networks.
00:01:32
Speaker
Yeah, I'm really happy to have here. I think in many ways you embody the ideal person working on crypto and blockchain because you are an engineer by training, as I understand it. You also work on economic problems, so you understand both sides really, really well. Now, what we want to talk today about is some concept which is referred to as just-in-time liquidity.
Decentralized Exchanges Explained
00:01:55
Speaker
decentralized exchanges. Now, we've had already one of our podcasts on decentralized exchanges, but just in case, to make sure that our audience understands what is going on and what actually decentralized exchanges, maybe in just two or three sentences, can you explain a DEX to us? Yeah, absolutely. The decentralized exchange is a type of financial innovation that
00:02:22
Speaker
aims at providing liquidity in a decentralized fashion. So what decentralized fashion means is that the market makers in this space, who are also called liquidity providers, will deposit liquidity, typically in the form of tokens, into a pool. And this pool is shared among all these liquidity providers, and then it will be accessible to all
00:02:43
Speaker
traders want to execute trades, typically in the form of swapping one token for the other. And the underlying technology which makes this work is typically blockchain technology where you can submit orders of the bustling liquidity, so somewhat the equivalent of a limit order in a limit order book, or market orders which are essentially orders to extract liquidity in the pool submitted by traders. So, you know, one of the things that
00:03:08
Speaker
That strikes me about decentralized exchanges and actually people looking into this is, and you probably have the same feeling as I did Agostino is like, so we are all working on in a field called market microstructure. Micro microstructure is a field which tries to study how trading institutions, so that's like regulations and trading rules, fees, and generally how the market plumbing works and how that affects outcomes such as allocative efficiency, which means that people who value something the most get it.
00:03:39
Speaker
information efficiency, that you know that the price is right, and just generally trading costs, how they affect how people interact with one another. And the one thing that strikes me about decentralized exchanges is that literally anybody who looks at it first goes, this is nuts. I mean, you have a computer which runs a simple piece of code and tries to simulate a market. And at the same time, then anybody who looks at this more carefully thinks, wow, this is actually really clever. People come up with some really clever ideas here.
00:04:09
Speaker
Now, what we also see is that this market and the technology behind it and the concepts actually are evolving. So it started, I'm just going to brush over this very briefly, but I think in about 2020 in the summer is when Uniswap went public with a relatively simple mechanism. A year later, we had Uniswap V3, the third version, the first one in case nobody knows, it actually just means you could only trade the UNI token against Ether, as I understand it.
00:04:40
Speaker
And then Uniswap v3 had a completely different, not completely different, but had a very refined model. And now we see more and more iterations of this with more and more new ideas.
Just-in-Time Liquidity in DeFi
00:04:50
Speaker
And so sometimes it's a little hard for us to keep track of this. But I hope this podcast will be useful here. So we want to discuss a topic that is now introduced in decentralized exchanges, which is called just-in-time liquidity. Now,
00:05:06
Speaker
Can you maybe just outline for our audience what that really means? How would this work?
00:05:13
Speaker
Absolutely. So let me first start with the traditional way of providing liquidity in this decentralized exchange, which is essentially, as I mentioned before, you deposit tokens into a pool, and then you have an algorithm, as you mentioned, Andreas, which is also referred to as the smart contract, which will take care of determining the prices, like at what price you trade one token for the other.
00:05:41
Speaker
Typically, these market makers, the positive liquidity in the pool, and then they observe other investors trading. So in a way, the traditional form of market making is rather passive, like the price has changed only after a trade, and liquidity providers are typically leaving the tokens in the pool for some time. Now, a new- Let me interject for a second, because I think this is actually one of the really cool features, especially about the simple ones, is that
00:06:10
Speaker
People like you and I can become liquidity providers, right? So you deposit your assets and provided it's done in the right way, this should be something how you can actually earn extra income. So it's very different how we think of normal markets where there is like a sophisticated market makers and certainly differently than equity markets where there is, you know, these high frequency trading bots from Virtua and Citadel ready to trade most of the time, right?
00:06:33
Speaker
So sorry to interrupt you there, but I thought I'm just going to interject this because I think the audience need to appreciate that, too. Yeah. And it's a great point, I think, exactly. As you said, liquidity providers can be an artibillion, sophisticated entity, so just profit from the fees that they make when investors trade. Because investors who trade assets deposited in the pool have to pay fee, and this fee accrues to the liquidity providers. So even better, it's share among all those who have provided liquidity in the pool.
00:07:01
Speaker
Now, I mean, just in time, liquidity is somewhat a new form of market making, which somehow changed the bargain from passive liquidity provision to more active liquidity provision.
00:07:15
Speaker
Now, before I discuss what it means in the context of decentralized exchange, I think I would like to give some historical description of just-in-time. I learned this concept when I was actually a student at University of Rome. A long time ago, I was taking a class on operations research there. And my professor mentioned, okay, there are different methods of production or managing inventory. One is the traditional method where you order
00:07:44
Speaker
the quantities you need in order to produce cars or to manufacture any goods. The other method is called just-in-time, which is essentially an inventory management method where goods are received from suppliers only when they are needed.
00:08:01
Speaker
So it might sound like very difficult to implement such a method, right? Because it means that you really only want to have, say, wheels and tires to assemble into a car, precisely at the right time of the sequence. You don't want to have too many wheels, too many tires in the inventory, but you just want
00:08:19
Speaker
to have them when you need to manufacture the car. So it requires a lot of coordination among suppliers and producers, like you need to supply the goods exactly at the right time, if something happens, if there is disruption, of course, this method would miserably fail. But on the other end, I think, as you can imagine, and as we also see in finance, this method is basically designed to reduce the inventory holding costs, because you really have very, very limited inventory.
00:08:47
Speaker
And you also have like, you increase the inventory turnover. So it's a practice that was started in Japan. I think the Japanese came up with the business philosophy for the first time. And the idea was to improve operations, like from the assembly line workers to the CEO. So they wanted to make everything extremely smooth and efficient.
00:09:10
Speaker
Now, I think the concept of just-in-time liquidity... Can I just ask for one second? Just out of curiosity, since you bring it up, right? The main challenge here is that, is it merely an organizational conception of one, or is there also an economic question here such as increased transportation costs, for instance? Because imagine, I don't know.
00:09:30
Speaker
And maybe this is a stupid example. Let me just say it, right. So, you know, I can either buy, you know, shop at Costco and buy huge quantities, which I store at home, or I can go every day and go to the store and pick up the stuff that I need. And the concept of the differences and, you know, I buy stuff at Costco in bulk and I keep it, but then it's hanging around in my, my, you know, my, my, my pantry for a while. Whereas if I have to go to the store every day, this is taxing on my time. Is that, is that actually the main trade-off or is this really just something that you,
00:10:00
Speaker
Is that the question that we're after here? I think, Andreas, this is definitely, I mean, there is this concern, this trade-off that you incur between, of course, transportation costs because you need to support the good more times instead of piling it up on your inventory. I think in the case of production,
00:10:22
Speaker
The system is definitely a concern. In the case of financial markets, somewhat this becomes also a concern, but somewhat, at least based on the analysis that I've done, it seems to be a more limited concern compared to physical goods.
00:10:38
Speaker
Yeah, let me move to like, how do we apply this concept in finance, right? Or what does it mean in terms of in terms of finance and exchange? So the idea basically is we think about decentralized exchange.
00:10:53
Speaker
So far we are used to liquidity providers who are these unsophisticated investors who decide to deposit assets in the pools, again in the form of tokens. Now, with just-in-time liquidity, this liquidity is not provided
00:11:10
Speaker
at the very beginning at inception and then stay in the pool, but rather it's provided on the fly. Can I just briefly interject? You went from talking about the physical goods context and I thought you were going to talk a little bit in the
00:11:25
Speaker
maybe the pure finance context, almost traditional finance, but you sort of, you've already kind of jumped on the decentralized finance. And so here I had kind of a question though, because as you were explaining the physical asset case, I was thinking, well, so in that case, if I understood correctly, the producer has already identified the supplier, right? So it's like, I like this, you know, this input.
00:11:48
Speaker
as soon as possible or something like that. But in the DeFi context, I want to trade. I'm not specifically asking any particular person to provide me the liquidity, right? Right. I think in the traditional physical context, I agree, you have to establish a relation with your suppliers. In fact, you tend to rely on the same set of suppliers, those who are delivering on time. Because if they don't deliver on time,
00:12:18
Speaker
you might have delays and the foreign production can even fail. Now, when we think about finance or financial contexts, the fact that you are providing liquidity to a specific unit or a specific entity becomes somewhat less clear. So you just provide liquidity into a pool for whoever wants to trade. You are not really
00:12:42
Speaker
serving a specific customer. You are serving the entire pool, which basically means whoever is there and he wants to trade. So it's not really a one-to-one map, like in the traditional physical good where companies, like Japanese companies, for example, they have established a relation with suppliers and each company has a different relation with their own suppliers. Yeah, like we think about the suppliers to be like a pool of, like,
00:13:08
Speaker
service providers, and then we think of the traders as being those who consume this liquidity. And it's not really a one-to-one relation. Right. No, so I was just trying to think about whether there is a distinction between doing it with a physical asset versus a financial asset, and then a further distinction between having a centralized finance context and a decentralized finance context. So for example, if I was thinking about your physical asset context in just like
00:13:35
Speaker
traditional finance context, the closest thing I could think of is something like, I call my broker and I say I want to trade this thing. Then there's a specific person I'm asking. They actually, even if they don't really have it on hand, they do the trade and then they basically have to go figure it out, which I guess is already a little bit different in the production context. Then the DeFi context is just an order of magnitude more complicated, I think, from the economics precisely because
00:14:00
Speaker
I'm not calling up a particular person and saying I would like this trade. I guess you'll get into that, but yes. Yeah, it's not really an over the market counter setting where you call the broker and you.
00:14:15
Speaker
decide on the term of the trade. So you have this cost to incur. Here it's more like similar to somewhat an exchange, like you directly deposit the liquidity for whether it's there and available to
Economic Implications of JIT Liquidity
00:14:26
Speaker
trade. Another point I think is that typically in the physical world, I think as Andreas mentioned, you have this transportation cost that you have to incur. So every time you deliver the good, you have to
00:14:35
Speaker
to pay for the costs. Now, I think in the cost of finance, you don't have the same as the transportation cost, but I think an equivalent there, and I will get to that maybe when we discuss in more details the nuances of this formal liquidity provision, is that you need to pay fees in order to deliver, in order to get your liquidity accepted by the pool. But another thing, actually, I think is really interesting here is that
00:15:03
Speaker
I mean, normally when we think of liquidity provision is that you give other people an option to do something. And you can structure a liquidity provision in various different ways. So in limit order books, you can post different orders in an AMM. So in an automated market maker that we're talking about, you can, I mean, the pricing function takes care of some of that, right? So in a very standard one, because somebody wants to trade a lot, actually has to pay a higher price.
00:15:29
Speaker
And in the versions like Uniswap, the third iteration, you can also post differently, so you can provide different amounts of liquidity at different times. Now, if I can put this back to really basic economics. In basic economics, the very first time we thought about uncertainty and markets, we think of what's called a complete contingent plan. So you try to figure out all of the different states of the world, things that
00:15:57
Speaker
future and you make a plan for this and you basically prefix your decision that you would make under those circumstances. So just for the bigger audience, this has been a topic which people have discussed in 60s and 70s in economics. And we know that these markets can work rather well. So in the way where you can make all these plans, whether you take them at the time or in the future makes no difference. You would do the same thing because you know everything.
00:16:24
Speaker
But reality is different. Reality, we don't actually know everything. We don't know all unknowns, unknowns. And so people like to have the option to actually not do something or maybe do something at a later stage, something that they haven't anticipated. And that creates the just-in-time liquidity decisions that we're now talking about. Because otherwise, we could just program everything that we want to do.
00:16:49
Speaker
We don't really want to do that here, right? So there's sort of like contingencies that you have to think about. And this brings me back to my cost of my friction, because here I would imagine as somebody who wants to act this way, you have to monitor the market. So that's kind of a cost that you have.
00:17:05
Speaker
as an equity provider. Completely agree with what you have said Andreas. I mean if I can add like this timing or delay is really key in just in time liquidity. The idea is that you basically want to observe first what is the order flow.
00:17:24
Speaker
Typically, this order flow consists of trades that have been submitted for execution and they are pending in the so-called memory pool of validators. And then you want to actually add or provide liquidity for these orders. And after these orders have been executed, you want to take out liquidity. You want to retract all. And you would like to do that all in a single block.
00:17:47
Speaker
That's basically the basic idea. The timing is important because in a way, you can think of this just in time with the providers to have the so-called the last mover advantage. Now, we always think about the first mover advantage in finance or economics, but in this case, I think it's the other way around. You can observe what is available and then you can decide whether or not you want to provide liquidity or not. Can I interrupt you there? Because I think there's a very interesting insight here because
00:18:17
Speaker
That actually goes at the heart of how liquidity provision works in a decentralized market relative to, say, a limit order book. Because you just mentioned the last mover advantage. Now, I think for our audience, it's important to understand if you post, for instance, at the same price in the limit order book, you would still be last to trade because of time priority. Whereas in the AMM, there is no time priority as such.
00:18:44
Speaker
If you provide liquidity, the way this would work is that all liquidity gets provided, and then all the goods essentially will be shared. Everything will be prorated. I think this is a very crucial difference here, right? Yeah, that's the key difference. Absolutely. I think another point to make is that in a way, if you think about traditional exchange, the operating continuous time and the latency is the key problem. It's a first-come, first-served principle.
00:19:13
Speaker
But here instead, on such an earth settled discreetly, like a discreet point in times, you decide which social including the blocks. And that's exactly the reason why liquidity providers can take advantage of the order flow and decide what to do, because it's like if they can glimpse.
00:19:30
Speaker
depending orders and they can decide on the liberty provision, which is something inconceivable in traditional exchanges. Because as you said, you can only observe limit orders who are somewhat resting in the book, those that are waiting to be matched against market orders, but you will never be able to observe market orders. You only see everything
00:19:52
Speaker
after execution has happened. So if I could ask, just to make things concrete, could we just walk through an example of how exactly this works, right? So let's say I want to do a trade, I want to do a large trade, right? And I think one important distinction, again, coming from sort of the maybe where the analogy with the physical assets breaks down, if I want to do a trade, I'm not specifically
00:20:11
Speaker
going out and talking to a particular liquidity provider, I'm just going to send a transaction into the network with that trade size, etc. Alluding to this point that the liquidity providers, the active liquidity providers are going to be able to see that. Could you clarify where exactly? Are they validating nodes? How do they exactly see what this is?
00:20:36
Speaker
And I guess there's a question also about competition dynamics, which touches on this thing you're talking about, preferring to be the last instead of the first, because I'm not, as the person who's trading, I'm not specifically calling somebody up. And that means that multiple people can in effect answer the phone, so to speak. So could you clarify from the point at which I send the transaction in? I'm just trying to trade, let's say.
00:20:56
Speaker
how do these active liquidity providers observe the transaction, the trade that I want to do, and how does the mechanics of how they then react? And who is they in some sense is also part of this question. Yeah, that's a great question.
00:21:11
Speaker
So the idea is that you, I mean, liquidity providers, we should think of them as the equivalents of the frequency trading traders in the traditional market. These are entities with very sophisticated technology who are scanning continuously the main pool, right? The main pool is this large memory of
00:21:35
Speaker
That's the, yeah, you can only observe the public mempool. If a trade, if a swap, suppose that we have a swap order, you want to swap, let's say, an Ethereum token for some USDC tokens, like for a stablecoin. Now, if these trades were to be submitted to a private pool, then there is no way for a just time liquidity provider to observe it. So there is no way to provide just in time liquidity.
00:21:59
Speaker
If instead this order is submitted through a public pool where there is full visibility about the order flows, then I observe this flow and I say, okay, hard ones to trade, no fun, because it's anonymous, but there is an order of swapping this Ethereum token for USDC tokens. Then the first question that I would ask myself is, okay, is this going to be an informed order or an informed order? Is this large swap?
00:22:25
Speaker
going to be, I mean, has been submitted by some trader who has information about prices and therefore he wants to trade because he knows that the price will go up and therefore he wants to take advantage of the current misalignment, the current lack of information revelation and the for trade at a lower price or not. So I need to first detect whether or not this trade disorder is informed or not.
00:22:51
Speaker
If I'm a very sophisticated market maker or equity provider, like somebody who has like this technology that like freelancers have and can scan like multiple venues to understand whether or not
00:23:03
Speaker
is information or not in the order, then I will say, okay, if it's uninformed, let me provide a lot of liquidity so that the swap order will be executed. And what is my benefit? My benefit is that I will gain from the fees because there is a large swap order that wants to be executed. As a result, I will gain large amount of fees from this execution.
00:23:28
Speaker
Just to clarify, the benefit of providing a large amount of liquidity, is that so that I will be a larger pro-rata share of the liquidity and so that I get a higher share of the fees?
00:23:40
Speaker
Yes, that's exactly right. So if you provide a large volume of liquidity, then of course the shares, the broader shares that you get is proportional to the amount of liquidity that you have provided compared to those who are already there, compared to the vast city with providers. So if you provide 99% of the liquidity in the bull, you will basically get 99% of the fee revenues that the bull is making. And that's exactly your incentive to provide liquidity.
00:24:08
Speaker
But then this raises the question of the competition that you've been alluding to. So I was sending in the trade, and so maybe Andrea sees my trade and goes like, all right, I'm going to put in a ton of liquidity, so I'll pick up all the fees. But then you see the same trade that I'm doing, and you also put in a ton of liquidity. Then neither of you would be close to 100%, let's say, of the liquidity provision. So what actually happens given that multiple people could, in theory, provide liquidity?
00:24:36
Speaker
Right, of course, competition among liquidity, there is a different form of competition. I think one form of competition is what you alluded to, competition among liquidity providers. Of course, like this is like reducing the revenues for two reasons. First is that they are not getting like this 99% or a close 100% production.
00:24:54
Speaker
shares of the fee. And second is that the more liquidity is added to the pool, the smaller is the price impact of the trade. As you all know, based on the work that you have done, you see that if you have a deeper pool, price impact gets lower. And as a result, the liquidity provider is running less from the price impact. So in a way, if they cannot coordinate on the provisional liquidity, they will be suffering from competition because they will get less revenue from fees and also
00:25:22
Speaker
less revenues from the pricing part because as we know, the liquidity providers are running from the pricing part of the trades. But just to clarify then, so then ex ante, how do liquidity providers deal with this, right? So if Andreas doesn't know how many other people are going to also basically do the same thing, how does it affect whether he even does try to provide this liquidity?
00:25:45
Speaker
Yeah, me. I think the way would be, I mean, there are different ways to deal with this situation. I mean, one possibility would be to, of course, be like me. If there is like a lot of competition, then I think you also want to fight for block space. So if you are able to get access to the block and kick out somebody else who also wants to provide just in time with it, then there will be one way to do that. The other way, which is I think how things work,
00:26:13
Speaker
as I understand worse at the moment, is to be somewhat collaborating or partnering with a builder, right? Because this, I think I want to make the point that in the new, I mean, this just in order with the product is operating on your soft ports, which are deployed on the digital blockchain.
00:26:31
Speaker
And as we know, the data on blockchain has gone through a transformation where there are the so-called searchers who are searching for MEV opportunities. There are the builders who are putting the transactions into the blocks, and there are validators who are proving the blocks. And I think these just-in-time liquidity providers play the role of searchers. So they try to build bundles, including the liquidity that they want to provide, the swap transactions that they want,
00:27:00
Speaker
to
00:27:02
Speaker
to match in terms of liquidity, and also the order of the tracking liquidity. So they submit these bundles to the builders. And if they have good relation with the builders, as we know, the builders have a lot of private order flow, then they will be able to convince the builder to execute their own transaction, right? Instead of transactions of other just-in-time liquidity providers. So the relation with the builders plays a key role in terms of determining which liquidity provider will be successful and which not.
00:27:33
Speaker
So let me just do a quick recap here. So just so we were all on the same page and the audience understand also the subtle differences here. So there's a few things to distinguish.
Settlement Layer and Market Structure
00:27:45
Speaker
So there's the smart contract application, let's say Uniswap.
00:27:50
Speaker
where a trade gets generated and that trade then gets submitted for processing to the blockchain network. So think about it, I think about it as there's an application level and then it goes to the execution level.
00:28:04
Speaker
You could imagine that just in time liquidity, as you described, it could be a feature of the smart contract and of the application. But at the moment, this is not what we're talking about. And so again, this is maybe important for an audience that is not entirely familiar with all the details of the blockchain, the way blockchain works is the transaction gets created by an application. It then gets put into the, if you want, settlement network. And in the settlement network or in the settlement process, things can still happen.
00:28:34
Speaker
So, one problem that we know, we've not discussed on the podcast, is the so-called MEV extraction. So, you could see something called a sandwich trade that occurs after a transaction has been submitted. Now, this is not what we're after here. But what, as I understand the problem that you described, is that it is possible that a trade gets observed and then somebody observes that this trade could be something valuable.
00:28:59
Speaker
Then they make an addition to the liquidity pool, which is an additional transaction, which would be processed before the trade, so that then there would be a different pool composition. So the application would actually look different by the time the trade gets submitted.
00:29:16
Speaker
If I may add one more thing, so this is also important maybe for an audience is because there's a difference to traditional markets. When you have a traditional market and say Fahad and I, Fahad and I put in a limit order, I take a market order and I trade against Fahad's order, this is the message and this is what is being processed by say a stock exchange and then sent to settlement.
00:29:38
Speaker
In blockchain land, it is the processing of what actually it happens as a trade happens always at the time when the trade occurs in the pool. And that is not the time when you submit an order. So between the time that you think you're making a trade and that it actually gets included in the blockchain and processed, things can still happen to this mempool. So not mempool, to the application.
00:30:03
Speaker
So I'm sorry for my lengthy explanation, but I think this is quite important because it's rather subtle because it affects, though, who knows what at which time and who acts at which time, right? Because in your model, the problem you described really is something that happens after people have already made all other decisions as a single entity, if you want, that can possibly inject themselves and do stuff. This is very different from our traditional world.
00:30:31
Speaker
So if I can pick up on that and maybe also ask a question following it. So I think, Andreas, the point I guess you're making is that things don't actually count until they're on the blockchain. And there's a distinction between me generating a transaction, essentially creating an order to trade, and it actually ending up on the blockchain.
00:30:55
Speaker
And so part of I think what Agostino was describing at one point was this idea of searchers and builders. And so the builders are the ones who create the blocks and the searchers are sending them chunks of transactions or sets of transactions. But then that sort of, I think, brings forth this question about
00:31:12
Speaker
Yeah, so it's not that I have an order to trade and it's going to end up on the blockchain at the time that I send it in or even on some kind of like Let's call it exogenous schedule. Like it's not like 10 seconds later or 12 seconds later. It's going to end up on there It's going to have to do with this sort of
00:31:30
Speaker
interaction of these economic agents, shall I say, searchers and builders. And so I don't want to go too far afield from, you know, sort of the scope of the work that we're discussing of yours. But nonetheless, if you could provide some context on sort of the relationship between searchers and builders, and how it might affect outcomes that could you just or Andreas, you wanted to say something?
00:31:56
Speaker
I definitely want to interject something because that's actually very important because it's an ongoing discussion that we see in the world beyond the blockchain world, particularly in the regulatory space. And this is the following. There's a certain theme where people say, same role, same obligation. So say, for instance, a decentralized exchange should be treated like an exchange-less brokerage because it does exactly the same. And this is really critical that that's actually really subtle, but a very important difference is here.
00:32:25
Speaker
And treating them the same way is just not right, right? So you're missing actually, you know, trying to, you're trying to squeeze a round peg into a square hole here. Because as you say, and I think this is one of the things that your work brings out that there is really the difference matters. And there's different economic mechanisms that arise because of this. Yeah, I was just so if you could flesh out any bit of the how the actual
00:32:50
Speaker
economic interaction evolves in practice between the searchers and the builders? Yes, I think this is... I will answer this question and then I want to go back also to the relation with the MEV and the centuries attack that Andreas mentioned. So in terms of the interaction with the searcher and builders, I think as I understand at the moment,
00:33:14
Speaker
the just-in-time liquidity providers basically play the role of searcher. So what they are doing is constantly scanning the public mempool, identifying large swap transactions, and then gitting liquidity. So like somewhat adding an order of raw liquidity for this specific swap. So they typically try to really put an order
00:33:39
Speaker
limit order or you can order for a liquidity at a price range which is very close to the current swap price. So at least at one tick around the existing swap. And then, of course, they immediately sandwich this swap by providing an opposite order of detracting this liquidity.
Risks and Challenges in DeFi
00:34:00
Speaker
Then the idea is that they compete with other searchers for adding this swap into their own bundles. Because, of course, other searchers will also want to take the swap transactions, perhaps want to front-run this transaction, right? Or they want to maybe do a send each attack, or they might want to even like put in their own, they might even want to
00:34:26
Speaker
match it in terms of liquidity. I mean, just in terms of the providers themselves. So the idea is that they compete and they want to outbid other searchers who also want to use the swap in their bundle. Outbid. So when you say outbid, you're talking about... Outbid, I'm talking about the bids that they are
00:34:51
Speaker
In order to get their transactions into the block, they have to pay the builders, right? And they have to pay a fee to the builders. So when they say outbid, I mean competing with other searchers in terms of bidding the fees and making sure that their fees sufficiently large so that the builders will take their own bundles and dot it into the block.
00:35:14
Speaker
And of course, like in a world of personal information, let's say that we are on a public pool. And with Russian players, I mean, we expect this flop and only if a G transaction is more profitable than all the other possible MEV bundles that are using the same flop. If you are really profiting a lot from
00:35:35
Speaker
gitting a swap and you're profiting more than other searchers who are also trying to construct bundles using this swap transaction, then you will be the one who
00:35:49
Speaker
who will succeed. Otherwise, you will fail because, for example, if there is another MEV searcher who wants to execute a sandwich attack and his sandwich transaction is more profitable, then the fees that you would earn from your just-in-time liquidity transaction, then you will not be willing to outbid him. And as a result, you will not be successfully being jitting this transaction. Jitting, I mean, just-in-time liquidity providing.
00:36:18
Speaker
How efficient is this bidding process in the sense that do the gains either from the jitting or if it happens to be a sandwich attack, do the gains tend to go then to the builders? There is the usual process of transferring fees to the builder. In the end, the profits of transactions are partly shared with the builders because in order that you are willing to bid
00:36:46
Speaker
So i need more from like an empirical perspective like in this house is how can i hear you can you can write it in the yeah i am i agree i mean in bernica leon we haven't checked how much of the i mean i don't compute how much of the fees that are being paid by the searcher to the bidders. What portion of these fees accruing to them and how does it compare with the budget but i presume that.
00:37:10
Speaker
it's probably a large main. They are definitely profiting, but they are sharing a substantial part of their profits with the builders. But I don't have the exact number. This is a great point. I think we should definitely check. I mean, if I make an analogy with the MEV, where most of the profits are accruing to the builders, right, then I presume that the same should all true for just in the MEV. I don't see any difference in terms of
00:37:38
Speaker
the economic mechanism which is leading to a transfer or well transfer of fees from searchers to builders, like similar to MBB. Like when you search for MBB transactions, then you're willing to bid up to the value of the transactions as a result. The fee that you pay is a very significant portion of the gains that you would have made from this sandwich transaction. But we just didn't check that yet.
00:37:59
Speaker
I have a bit of, I guess, an odd question, which is, are there cases where we see sandwich attacks in concert with jitting? Because it occurs to me that you get fees from the guy doing the sandwich attack, too. It's a great question, Fad. I can answer this question more conceptually and theoretically. We haven't seen yet empirically, but I think the trade-off that is being faced
00:38:25
Speaker
is the following. If you identify a large swap, then you want to decide. Should they cheat this swap? Should they provide liquidity for execution of this swap? Or should they do a backrunning or frontrunning transaction or a sandwich attack?
00:38:44
Speaker
And then I think the typical trade-off that you face is the following, that if you execute the G transactions, then you have to basically pay the fee to provide liquidity and the fee to take out the liquidity. So it's two orders. Now, you first submit an order of providing this liquidity, then the shop executes, and then you have to submit another order to that drive liquidity. Those fees, you're talking about gas fees there?
00:39:11
Speaker
Yeah, I'm referring to gas fees, fees for adding your order, sorry, fee for adding your order to the member. But so that's not really going to scale with the size of the trade though, right? Yeah, you're right. This doesn't scale with the size of the trade. Then, of course, if you top up the pool liquidity, then your price impact will become lower, right? Because if you add more liquidity to the pool, then the price impact coming from the execution of soft transaction is not large. So ultimately, most of the revenue comes from the fees that the supporter is providing.
00:39:40
Speaker
If you do a sandwich attack instead, or you backrun this transaction, then suppose that you backrun it. Then you would somewhat pay the fee only once, at the time where you decide to backrun it. But as you said, the fee is a fixed cost.
00:39:57
Speaker
But of course, you wouldn't be earning the profit from the fees because you are executing the swap yourself. You're just trying to gain from the pricing, but in this case. I had something that would be a little more complicated in mind in the sense of you would require some coordination, which is like if I wanted to jit this thing, but I see that somebody else, I see Andreas is going to do a sandwich attack,
00:40:20
Speaker
Could I provide the liquidity, put in his sandwich attack, and then remove the liquidity? So I get fees from his sandwich attack, and I get fees from the... That probably is like...
00:40:32
Speaker
That requires a certain amount of coordination because I have to be able to see his sandwich attack attempt. I could see that being beneficial for the liquidity provider because there's actually more trading then. I guess the sandwich attack is still coming off. In some sense, it's easier to do a sandwich attack when there's more liquidity in the pool because if you have some slippage tolerance, it's going to be harder to actually approach the slippage tolerance.
00:40:54
Speaker
Right, right. I agree. In principle, if you can identify a sandwich attack, then you could create a bundle where you put your order of running with the sandwich attack, and then your order to the directly with it. As you said, there is always a chance that the sandwich attack would fail because it exceeds the maximum sleepage tolerance. But the Git is actually helping there, right?
00:41:14
Speaker
Yeah, the JIT, yeah, I agree. The JIT is basically reducing the pricing, but so there is a smaller chance. It's like you're going to actually just let this sell. No, it's a great point. Well, really, what you do is when you do that, right? So what you're taking, you're taking actually away the profit from the sandwich attack, right? If you add liquidity, all that happens is that the sandwich attack, the profit for the sandwich is actually going to decline in the amount of liquidity that's provided.
00:41:41
Speaker
So I think if anything, you're actually taking away the power of the sandwich. Because the price impact is smaller. Correct. So the sandwich attack that you would see, if there was a sandwich attack and you can see it, all that you do is because that's a fixed size. Now you can make the case, if there is just a time liquidity, you can make a much larger sandwich attack. And so that creates more trading fees, which is good for you.
00:42:07
Speaker
All that you do here is you kind of screw in the sandwich attack a little bit. That's all the more reason for me to do it if you're doing the sandwich attack. If I can figure it out then...
00:42:16
Speaker
Yeah. Right. Now, you're getting very, very subtle here, if I may say so, right? I think it's more important, actually, to probably think, if I can bring it back to the economics here for one moment, right? So, I mean, a sandwich attack is, so just so the audience understands, is essentially it's some form of front-running attack, right? A sandwich attack means you move the price before somebody else trades, and then you sell, I mean, implicitly, it's not quite the case, but implicitly, you sell to the person that you're front-running,
00:42:45
Speaker
at a higher price and you pocket the difference, this is essentially a profit. Here, however, this is not the case, because here you supply liquidity. If this was a real market, let's say, sorry, not a real market, this was a standard market. If you supply extra liquidity, you actually have an extra risk.
00:43:05
Speaker
Whereas a sandwich attack is a risk-free profit. Here you actually would have extra risk. Now in an AMM, and so you make the fee, we understand that, but you also have the extra risk. Now in an AMM, we refer to this as you're facing potentially an impermanent loss. That's the term or positional loss that people have. Because as you provide liquidity, if you withdraw it right away with your fees, which if you want to realize that profit, if you have the additional cost of possibly having the
00:43:33
Speaker
the positional loss, right? So I just thought it's important to point that out so that we don't, we're tossing a lot of words here around. So it's very important to differentiate the two effects here a little bit.
00:43:45
Speaker
So, but just going back to the original discussion, so one of the things that we're observing here, and I think this is what you're pointing out, I was seeing this again, that at the settlement layer, so at the processing layer of blocks, a lot of funky stuff happens that we're now slowly becoming aware of, and that the app developers themselves actually do not know themselves either, right?
00:44:06
Speaker
So the cool or the interesting thing for us economists is things that happen on the settlement layer now all of a sudden have an impact on the running of the application itself, which is nuts. Because you normally think, well, the blockchain is just a thing. It's just a tool. But actually, it has its own economic ecosystem.
00:44:26
Speaker
It's really important to understand this. Now, if you come back to Agostino's problem, right? So now you are a regular liquidity provider here in this context, right? So what can you just point out again? So what exactly is the issue that you should have with just-in-time liquidity? Yeah, the issue is that on the surface, it seems that everybody should benefit from all liquidity, at least if you
00:44:53
Speaker
If you don't think, at least when I thought about this problem for the first time, I was thinking, okay, having more liquidity should be beneficial for the ecosystem. You should be beneficial for traders, you should be beneficial for the passive liquidity providers, those who are not really sophisticated, but they're just depositing assets in the pool and waiting.
00:45:11
Speaker
And it should be beneficial for those who are topping up the liquid in the pool. But then I think if you think a bit more carefully on the problem, you could see that there are some costs that need to be taken into account in this mechanism. And they would like to slow down a little bit and
00:45:31
Speaker
discuss those costs in some detail. So if we think about passive liquidity provision, passive liquidity providers, they basically deposit the assets in the pool and they face the risk of being picked off in both direction of the price movement, right? Because if there is an informed order coming, then it's true that they will learn the fees coming from the trades, but
00:45:57
Speaker
they might be picked off because, for example, the price is moving, as you mentioned before, in the wrong direction for them. And there is nothing they can do. I think we have one other paper that shows exactly this point, that even if they would like to take the liquidity out of the pool, they will not be able to do that because they will never be able to compete with those arbitrageurs who are trying to exploit this price misalignment.
00:46:25
Speaker
So this is basically a problem faced by the passive liquidity provider. They are at the mercy of the market and they face potential losses from informed traders.
00:46:37
Speaker
Now, on the other hand, the just-in-time liquidity providers, they have the so-called last-mover advantage. They really cannot opt out of unfavorable trades. If they see that the trade is informed, they might decide not to provide liquidity against this trade. And this, of course, reduces the risk, or in other words, it pulls the risk of being adverse to zero because they can avoid it, assuming that they are
00:47:02
Speaker
of course, enough sophisticated to detect whether or not an order is informed. But if they have this degree of sophistication, they will definitely be able to avoid any other selection. Now, the issue is that if just in terms of providing, let's say, 98% of the liquidity in the pool compared to the passive liquidity providers, then they can potentially earn mostly the transaction fees
00:47:28
Speaker
from uninformed traders that positive liquidity providers were depending on. So all of a sudden, the just-in-time liquidity providers will basically crowd out the positive liquidity providers because the pro-rata fees earned by the positive liquidity providers are now being taken by the just-in-time liquidity providers, right? And this is actually, I mean, assuming, of course,
00:47:51
Speaker
The final effect is that the vast delivery providers are still subject to the same adverse selection cost. Assuming that this adverse selection cost from informed trading remains the same. But they are earning less fees because their product share is going down. Exactly because most of the liquidity is being provided by the active delivery provider.
00:48:12
Speaker
And this is really the key point that we have to keep right off that we are gliding the paper that it really means everything depends really on what is the elasticity of the order flow with respect to the depth of liquidity pool.
00:48:29
Speaker
So if more liquidity deposit in the pool leads to more uninformed orders being submitted, then it means that the volume is going up. The trading volume is going up. And as a result, even if the product share of fees earned by the positive liquidity providers is going down, still the volume is large enough that in the aggregate, they are better off, right? They are getting maybe 1% but of a bigger pie.
00:48:57
Speaker
compared to 1% of the same Pi, which would be the case, for example, if the elasticity of the order flow with respect to the liquidity pool is more. So if like you top liquidity in the pool, you add more liquidity to the pool, but the set of trades, the order flow remains the same.
00:49:15
Speaker
then it means that the trading volume stays the same. And if you are only earning, let's say, 1% of the fees generated from this trading volume, that will not be enough for you to stay in the market. And that's exactly the situation where the active liquidity providers would be crowding out the passive liquidity providers.
00:49:34
Speaker
Right. So if we abstract from the competition at all and just think of like a single active liquidity provider, what is the constraint to not providing more than, you know, essentially infinite amounts of liquidity? Because what I'm getting at is like you were talking about, you know, 1% of the fees for a passive liquidity provider is higher when there's more trading potentially than, you know, a higher percentage for less trading.
00:49:59
Speaker
But in some sense, that seems to assume that the active liquidity provider is not just going to blow up liquidity provision to the point that it's essentially 0% for the passive liquidity providers. So what is the dimension that gets the, let's call it the active liquidity provider to a finite amount of liquidity provision?
00:50:20
Speaker
I mean, I think in our model, it would be the budget constraint that they have. They have a limited amount of resources available, so they cannot provide an infinite amount of liquidity. In practice, you also have that there is always some probability that you have not detected that this order flow is informed. So if, for example, the order flow happens to be informed and you provide an infinite amount of liquidity,
00:50:40
Speaker
your adverse selection cost will be infinite, right? So then it depends really on the quality of your monitoring technology. But if you are sure that this order is uninformed, then of course, you want to crowd out the main, actually, you want to crowd out the liquidity provider, but you need to be careful to one thing here.
00:50:58
Speaker
which I think is basically the problem even if you would have an infinite budget. If you crowd out the passive liquidity providers, so that means that there is no liquidity to start within the pool, then you cannot really top up the liquidity because no investor will come and trade if there is very limited liquidity in the pool or if there is zero liquidity in the pool, you have no idea about the prices and you get me. Suppose that you have a tiny amount of liquidity, then you are still
00:51:23
Speaker
like shooting food in the dark, right? You don't know at what price you will execute because the grid is too shallow.
00:51:31
Speaker
I want to set that last point aside for a moment because I want to ask a clarifying question on the point about in practice, is it that liquidity providers, these active liquidity providers who are jitting, is it that they're using their own wealth to come up with the capital that they use or are they able to borrow and do things like that? They are allowed to borrow. They could get a flash loan, for example, and just use it to buy tokens and provide this liquidity.
00:51:57
Speaker
And then at the time where they tried this liquidity, they could return the flesh alone. This happens within the same block. So you can definitely do that. In the same way you do a sandwich attack, you typically use a flesh alone.
00:52:11
Speaker
to get the tokens that you need for execution and then you return them within the same block. So this can be done exactly in the same way for just in the liquidity providers. The only reason why you don't want to do that is precisely because just in the liquidity provider only exists if there are passability providers. So if there is no liquidity in the pool, there is no way to add additional liquidity. So you cannot go from zero
00:52:31
Speaker
to infinity, right? You have to have some basic amount of liquidity, then you don't want positive providers to disappear, which would be the case, of course, if you get 99.99% of the shares. But that doesn't mean there isn't a unilateral deviation, right? Like, so for example, given that passive liquidity providers are providing a certain amount of liquidity, I think about my incentive problem. But anyway, I think Andreas wanted to jump in here.
00:52:58
Speaker
Yeah, so first I actually want to make a point here, which again, to bring this back to traditional markets, because I think there's a very important and subtle difference here, right? So if we think of a high frequency trader who provides liquidity on existing market, what they try to do is they try to be at the top of the book whenever it works for them and then disappear whenever it's bad for them.
00:53:20
Speaker
Now, there's a similar mechanism of creating a negative externality with your behavior towards, say, not passive, but less sophisticated liquidity providers, which is that HFTs will pose and they will get hit with their pose. And then when they realize they're going at stuff, then orders that are behind them will get picked off, right? Now here, however, the mechanism is actually much worse, because here you actually have the option to provide liquidity
00:53:49
Speaker
after the fact, after you see that it is beneficial. And so this is essentially in the traditional market, if say there is no passive liquidity provision, okay, it's still high-frequency traders that could lead to dislocations of prices and so on, and to minimize liquidity or to reduce liquidity, but here it could literally unravel, right? So here it's literally the case that if the high-frequency traders are able to pick up all the good orders and they don't leave enough
00:54:16
Speaker
for the bad orders, if the degree of positional losses, asymmetric information, or the risk really of price movements is too large, you have a complete unraveling of a market. This is what you kind of pointed out there, and I think it's really important to understand that difference.
Mitigating Liquidity Provision Issues
00:54:31
Speaker
So this is, now, happily, the blockchain world is working on fixing of this, right? Because, I mean, the Flashbots protocol is one example, right? And hopefully, at some point, we're going to get totally hidden transactions where this
00:54:44
Speaker
as Farhad calls it jitting. So just in time, liquidity provision is simply not an option anymore. And in some sense, if you think of the total risk of a market, in particular, that would apply to the kinds of, maybe that doesn't apply to trading either against a stable coin, where there's sufficient amount of information, but for anything that is smaller, where there's possibly higher adverse election risk, there you could see definitely the unraveling of the market.
00:55:12
Speaker
Is there a way to sort of allow for jitting but yet not have some of these downsides that we're describing? So for example, if the essentially the right to jit would be auctioned off by like, you know, so basically something where you
00:55:34
Speaker
give the first transaction in the block, can you auction off the right to be the first transaction? Or something where you auction off the position in the block or something like that. And then you distribute the gains to the passive liquidity providers.
00:55:53
Speaker
That's a great point. And in fact, this is actually one of the fixes we are proposing in a study. We're saying, OK, if you want to somewhat incentivize a facility rather to stay because you don't want this unraveling of the market that Andreas was mentioning, you want still sufficient amount of liquidity there.
00:56:11
Speaker
Then one possibility would be to create, let's say, a two-tier fee system, where parts of the fees that are being earned by the active liquidity providers who are dominating the market because of their bigger share are transferred to the basket liquidity providers in a way that they want to stay in the market. So redistribution of fees one way, which I think in principle is also implementable because you can observe which transactions are being jitted and which transactions that are
00:56:39
Speaker
being generating fees that are accruing to the vast city with the providers and as a result you can redistribute these profits. I mean that's one way that I see how to fix the problem.
00:56:48
Speaker
You have to be very careful though with, I mean, not you personally, but one has to be very careful with the design of these markets and its applications. Because once you start to have, when you try to do something very intricate, it is possible that you get it wrong. And if you get it wrong, in terms of how you're designing it, then you can have the unraveling of the market again.
00:57:13
Speaker
Number one, number two, keep in mind that so one of the things that I think is really appealing about the DeFi market and the traditional or the simple versions of it is that allows people to access and use the market in a simplified manner. And so one of the lessons I think that we see from our modern markets is that
00:57:32
Speaker
You know when when it comes to when the question to a high level of sophistication then you kind of have catering to a particular clientele and that clientele you know maybe also proposes a mechanism that just works for them like we see this in exchanges where a particular client proposes a particular order type that allows them to make a profit at the expense of everybody else. If we see the same mechanism and defy then we kind of do me the market right for taking away all the advantages of it.
00:57:58
Speaker
Yeah, I was thinking with this fear feed system is something similar to rebates. Now, TBLU have a market making rebate in traditional finance, which ensures that those who are providing services, market service are being compensated. But of course, one is to be careful that it doesn't become too exclusive, right? That you only may end up benefiting a specific clientele. Yeah, I mean, one of the things
00:58:24
Speaker
I think we tend to forget this also is the importance of risk sharing. Because ultimately, liquidity provision being there in the market over a stretch of time is risky. And if this risk gets unequally distributed, so we may see the unraveling. So everybody in the market is always after what is the best thing for me and what is the best that I can get.
00:58:53
Speaker
In a market with fictions that couldn't create problems right in in a in a perfect market Obviously everybody acts into according to their own self-interest we get an equilibrium it works out We have allocated for efficiency and everything but not in a market with friction with market with friction as it becomes a much harder problem right and so they have the ability for people to share risk and share rewards can lead to an improved social outcome and
00:59:21
Speaker
Now, it sounds like I'm talking as a socialist, but this is just basic economics, right? Markets with, let's put it differently, markets with externalities. The competition of markets with externalities is a very hard problem, right? And the answers and the outcomes are not always obvious. This is a message for those of you who think of themselves as capitalist and believers in markets.
00:59:43
Speaker
your markets may be more complicated than you think. So that's certainly the case, but is it fair to say that the design space
00:59:52
Speaker
in the blockchain is different than the sort of, I'm not even sure if there is in some sense a design space on limit order books, but like for example, the ability to auction off the monopoly right to jit on a given block, let's say, right? Because it seems to me that there is sort of a first order benefit
Blockchain's Economic Design Space
01:00:09
Speaker
of jitting. The problem is that it's not the only effect it has. It has sort of like economic implications downstream, right?
01:00:14
Speaker
The idea that somebody is going to provide a wall of liquidity for me to trade into is really great if you can just have that effect and nothing else after that.
01:00:31
Speaker
Of course, it's very important to be careful as we try things. I think that's part of the point you're making. It might sound like it makes sense and then you didn't realize a variety of things that could happen, particularly in this space where you can have
01:00:47
Speaker
very subtle things like re-entrancy attacks and stuff like that, that even computer scientists won't think of at first. I think it's important to be careful, but it does nonetheless seem to me like
01:01:03
Speaker
There is the opportunity to do things in this space that you wouldn't be able to do in a traditional centralized market precisely because you can literally code these things into smart contracts. But again, that doesn't mean that you're going to not overlook code pads or various other issues that could cause problems. Right. So, Fad, if I hear you, you're saying this would be a great mechanism if we can shut down all the equilibrium effects.
01:01:31
Speaker
In some sense, yes, but you can design a different mechanism that has the idea of auctioning off the value. You'll still have economic effects, but hopefully, in that case, you don't have the negative effects that we're describing because you're not disincentivizing the passive liquidity priorities because you're specifically sharing the benefits
01:01:50
Speaker
you're passing the benefits on to them. Now, that doesn't mean that there aren't other economic effects that I haven't thought of coming up with something in a few seconds here. This is the reason why I think actually rigorous academic work is important because you can convince yourself of all sorts of things if you only spend a few minutes thinking about them and you don't actually formalize anything. But I do think one of the interesting things about this space is that
01:02:15
Speaker
There is a design space, so to speak. It's just once you specify things, you got to be really careful about thinking about the economic effects that arise from that.
01:02:27
Speaker
Yeah, so if I may also just interject there, right? So there's a lot of things that require some understanding often. I mean, we know, for instance, in traditional markets, that different assets trade differently, right? So treasuries trade often differently from stocks for a variety of reasons. Some of them, historic others, are also functional.
01:02:47
Speaker
So, for instance, we had a discussion early on before the podcast started about this. So, as I understand it, in treasuries, for instance, there's mechanisms by which when a trade occurs, or when there's an indication of a trade occurring, there's a short period in which there is essentially an auction, which leads to what's referred to as size discovery. So, for different sides of a trade can actually both contribute
01:03:10
Speaker
to an order, to an existing trade, so that potentially the total amount traded is much larger than what the original trade was for. Now, again, this requires a lot of sophistication of different market participants, which is warranted in treasuries, because this is such a big market with very sophisticated players. Probably not so much for the market for any normal asset like stock or whatever, which is mostly traded by retail investors.
01:03:39
Speaker
Going back to your point about the design space, there is room for also trying to come up with trading mechanisms that cater to the underlying security that is being traded in the market, which has a demand for that. As it is, I don't think we have any result in theoretical economics who says XYZ is the ideal market structure.
01:04:04
Speaker
We know that some will work better than others. Larry Glaussen has written this insightful paper of the inevitability of the electronic linked order book, but obviously predicated on a particular set of features of a security. We don't see limited order books for FX as much, or at least not to the same degree. We see a lot of OTC trading in certain types of assets for obvious reasons often.
01:04:32
Speaker
So then thinking about it again, like the extent to which, I mean, we've been talking sort of about just-in-time liquidity and I would say it's somewhat focusing maybe on some of the negatives of just-in-time liquidity, but I'm wondering empirically, do we have any sense of what the effects on passive liquidity provision has been of just-in-time liquidity? And whether it's differential across different types of pools, because then I think to Andreas's point about like,
01:05:01
Speaker
the market structure that's ideal may differ depending on what exactly we're looking at. Yeah, so I mean, I will share some empirical findings that I read about and also I want to answer, sorry, I tried to answer this question theoretically first and then I will discuss a little bit empirics. So you're saying, okay, when does it, when is it bad? No, when is Justin Dimitry provision bad? I think
01:05:30
Speaker
What we really argue in the paper, and this is something that we should actually verify empirically, that's a great point, is that for all togens pairs, where you don't see a lot of elasticity, in the sense that if you have more liquidity, the flow doesn't increase much. Light increases may be sublinearly, or it stays constant. For all those pairs, then just in time liquidity, the provision is bad.
01:06:00
Speaker
Because again, the volume is not going up, but the pro-rata share of the fees accruing to the activity with riders is larger. And as a result, the positive with riders are losing. And this I presume, I mean, I think this is probably the case for many altcoins, no? Coins, I mean, tokens, pairs, which are very volatile.
01:06:24
Speaker
Whereas, if you think about pairs, which are more stable, in my view, these are also the type of pools, let's say USDC versus USDT or USDC maybe versus ETH. These are also the pools where more liquidity actually causes substantial increase in order to flow. And this is exactly when just in terms of the distribution is actually benefiting the positive liquidity providers.
01:06:47
Speaker
This, I think, is something that I'm not, we have not yet verified in period, but if I have to guess, that's what I would say. I would say that for pools or with managing very unstable coins, just even if the provision is bad, but for pools managing more stable coins or coins with very low volatility, I presume that there is a benefit in cheating.
01:07:11
Speaker
Now, back to the empirics, I'd like to mention that if you think about Uniswemit, this just in general weather really started after Uniswemit V3 was deployed. And if we look at, from the deployment of Uniswemit V3, which I think happened sometime in May, 2021, till July, 2022, I was reading that there have been basically
01:07:37
Speaker
over 95% of liquidity provision, gitting liquidity provision was just provided by a single account. And in total, there are less than 20 addresses which have tried to supply liquidity.
01:07:53
Speaker
And I think in terms of, just to give you a sense of the magnitude, I think if we think about the volume of UNICEF V3, the trading volume of UNICEF V3 over this period of time, like May 2021 to July 2022, there was about 600 billion trading volume.
01:08:11
Speaker
And the provision of liquidity by JIT providers was about $2 billion. So basically zero, roughly, I mean, 2 billion out of 600 billion is basically about 0.3%. So 0.3% of liquidity that has been provided for UNICEF V3 was coming from just in time liquidity providers. So that means that most of it was not coming from them.
01:08:40
Speaker
I mean, this is, I mean, these of course are data which refers to the video 2021 to July, 2022. I mean, I think one would have to look at what happened after that, whether or not it went up or down. And I'm thinking whether like, this could be related to the question that maybe the market design at the moment is not great. And as a result, somewhat, there is somewhat, there is some resilience to provide just in time liquidity.
01:09:07
Speaker
And also, I think it looks like that the only successful transactions are most of the, like, half of the successful transactions, which means the ones which ended up
01:09:23
Speaker
being included in the block and executed were coming from just in time with the providers who were topping liquidity just a few ticks around the current price. So many transactions just in time with the transaction which are providing a little bit deeper like in the book like for example picking a
01:09:41
Speaker
a segment of the Uniswap v3 curve, which was far away from the current swap price, ended up failing because they were not able to extract any liquidity. So based on that, you're saying it's not a problem yet, or...
01:09:57
Speaker
Is there, is there anything we can, so I'm not sure how much you, you looked at the data, but is there any, any cross-sectional or time series features that you can identify there? So I'm asking because maybe from that we can learn the circumstances under which, you know, generally would say there could be a problem.
01:10:18
Speaker
So it's number one, and obviously, number two, it's always a little difficult to say what could be if this becomes widespread, right? Especially once jump trading and figures out how to do that, then there could be a game changer, right? Yeah, I think we haven't looked yet at the cross section or time series of the data, but definitely it's something that we... At least I want to test this, obviously, that I'm mentioning about more stable versus less stable pairs. How do they interact just in time liquidity provision?
01:10:47
Speaker
I mean, it is surprising from a theoretical economic perspective to have Chitting be so small in the liquidity provision, right? Because just in terms of unilateral profitable deviations, right? I mean, yes, there's an equilibrium effect that could dry up passive liquidity, but there is passive liquidity right now. But then again, I think you said the data you were alluding to goes to July 22. Yeah, July 22, I think we would have to look at the data after July 22.
01:11:16
Speaker
Another point I wanted to add is that it's very concentrated because around half of it is provided the Uniswap USDC Ethereum pool with five basis points fee. That's the second, the pool with the largest trading volume.
01:11:40
Speaker
And if you look at the top 10 pools of UNICEF, they account for 95% of just-in-time liquidity. So they really mean it concentrates where there is a large trading volume, which also makes sense.
01:11:52
Speaker
It's interesting because in some sense, a half hour or so, I mentioned something to the extent of when you actually provide just-in-time liquidity, you do face a potential risk afterwards. What you just described seems to be you really do this only at the pools where the risk is low.
01:12:11
Speaker
The advantage of that being also that the externality, the possible information externality that you provide is not that large on others potentially, right? Because that's really kind of the concern that we have with these markets, right? So that there's the high volatility cases, the case of asymmetric information, this is where you jump in, right?
01:12:32
Speaker
Well, that's kind of interesting, actually, right? Yeah, it's true. Because for this deeper pool, there is also, to some extent, less systematic information. It's like they are closer, let's say, to the dredger rather than to the agri markets. If we think about USDC or US Ethereum,
01:12:47
Speaker
Another reason, I think, is because if you want to hedge this risk, then definitely, let's say, if you want to hedge some of the risk in centralized exchange, then there is definitely more liquidity in centralized exchange managing, let's say, USDC versus ETH rather than centralized exchange managing, I don't know,
01:13:12
Speaker
The term doesn't exist anymore, but let's say AVE versus compound, for instance. So that's the reason why if you want to edge risk, then you want to go to a pool which is deeper liquid. So I have a bit of a naive question here.
01:13:32
Speaker
The advent of, say, gitting in the context of decentralized exchanges and so on, there's nothing on the smart contract level that specifically enables it. It's not like there was an upgrade or something like that and then people started doing this. First of all, is that correct?
01:13:55
Speaker
I guess, how aware are market participants of the ability to do this? Because I hadn't heard about this very much, I guess, a year ago even.
Managing JIT Liquidity Effects
01:14:05
Speaker
And usually when that happens, it's because there's actually some kind of difference in the functionality that facilitates something from happening. But I don't think that's the case here.
01:14:15
Speaker
Yeah, no, as I understand, I mean, it's not really a functionality in coding in the smart contract. Let's say, I mean, they, they, they, they top liquidity algorithmically. It's more like a problem. It started with the, with the, with the, with the new sub V3. So after the deployment of new sub V3, somehow, like, there has been like more sophistication added to the market. So this, uh, I feel like the market makers starting coming and, uh,
01:14:44
Speaker
deciding to implement this just-in-time liquidity provision. But I don't know if it's due to the new structure. I mean, partly it could be due to the fact that they can now decide where they want to provide liquidity because they can submit limit orders. They can pick exactly the second curve where to provide liquidity, whereas before it was harder because you had to provide liquidity for the entire.
01:15:08
Speaker
segment of the curve. I don't know if that's the triggering cause, but as far as I know, I don't think there is any algorithmic encoding of Justin Timberlake in the smart contracts. Is it related at all to the
01:15:25
Speaker
the ecosystem of searchers and builders further developing, because it does seem to me like there's this coordination aspect. In principle, the moment Uniswap V3 was live and you have a particular liquidity pool that's launched, let's say the five bases went USDC, I can deploy an insane amount of, I can do an ad operation and deploy an insane amount of liquidity and pull it back to remove operation. But I guess it's not really, I take on more risk if I'm really just doing it in that way versus the way that we were describing with searchers,
01:15:54
Speaker
putting together the exact sequence they want and giving them to builders, which I guess requires a certain amount of coordination. In some sense, I guess that might say that, so if that's true, and of course, I'm just theorizing in the area, so I'm not saying it is true, but if it is the case, then I guess it's possible we'll see more jitting as these relationships that say among search and builders and so on develop.
01:16:21
Speaker
Yeah, I think you're raising a great point because the numbers I quoted refers to the period before there was this division being billed as a very searcher and validator. So it's possible that after the merge, where there is more integration between searchers and builders, searchers are just in time with the providers too, then we should, I mean, I expect to see more just in time with the provision.
Strategies for Economic Mitigation
01:16:49
Speaker
I think that's something that we should, we would need to check in the data. And so you alluded to, I think you briefly touched on potential ways to mitigate the, let's say negative effects of, negative economic effects of just-in-time liquidity.
01:17:05
Speaker
Can you say more about that in terms of, one, what you would suggest as a researcher and two, if you're aware of anything that, for example, Uniswap or some other of these decentralized exchanges are actually thinking of doing? Yeah, so I mean, I think what I know, I mean, what we are trying to argue in the paper is like designing a mechanism similar to this fee, I mean, to the office structure where you
01:17:34
Speaker
try to redistribute some of the profits to the possibility providers, again, exploiting ideas similar to what happens in market making when there are rebates. In terms of what the Uniswap and other pools are doing to prevent this effect from happening,
01:17:56
Speaker
I mean, I'm not aware of any existing mechanism that they're exploiting. So I think it's still... I mean, they are gliding that... I mean, I don't think they... Also, I glided the problem that we are starting in this favor. I think their focus has been more in terms of...
01:18:17
Speaker
like when you should do a G transaction versus when you should do an MEV transaction and when it's one more profitable than the other. I'm just going to say this. If I would be taking a more plain vanilla approach, because these effects happen on different parts of the tech stack, if you want,
01:18:38
Speaker
In my mind, if just-in-time liquidity would be something desirable for a smart contract for DEX, then they should be designing it and not leave it to the settlement structure. Likewise, the settlement structure shouldn't have a life of its own. Personally, I find this is actually a genuine threat to the whole blockchain ecosystem.
01:19:04
Speaker
If you think about the MEV extraction from arbitrage transaction, arbitrage is so critical for the workings of our markets. This should happen at the application level and not at the settlement level because you kind of create an unequal playing field there. If anything has to happen in this blockchain world, you have to have a proper separation of the two. Because you basically create all of these unforeseen contingencies that could happen for an application that they have to look after.
01:19:34
Speaker
Just bringing it back to a much higher level, if you look at the recent DeFi regulation proposal for Miesco, one of the things that are in there is that they want to hold DeFi platforms accountable for MEV extraction or mitigating effects of it. That's literally in the proposal.
01:19:52
Speaker
where you, of course, go like, how would I know even how to do this, right? How can I do this under all circumstances? Because your companies can't, right? So this is really a problem at the protocol level that needs to be solved. So in other words, Andreas, you are envisioning a smart contract which also implements the Just Intended Liquidate provision. That's correct, yeah. So I envision two things. I envision if it is beneficial, if it's viewed as beneficial, then it should be something included in the smart contract, correct?
01:20:20
Speaker
And I also envisioned that we move into a setting where transactions actually have to be processed essentially without the transaction process and knowing anything about the transaction. I think people are working on this, but I think this has to happen sooner rather than later. So if you take another step back, we'll never see a wide set adoption of genuine finance applications in this space.
01:20:45
Speaker
when you don't have a full understanding of what could happen to your lifecycle of a trade, because stuff can happen at the settlement layer. I mean, there's the insanity of this. If you think about a, imagine you submitted a trade to a stock exchange, right? And the stock exchange processes said they have their time priority, but then the DTCC could decide they could actually, you know, change something in the back office and change the price or the cost of your transaction. This is just nuts, right? This is nuts.
01:21:14
Speaker
Nobody would accept that. Exactly. You want more predictability on trade execution. That's right. You need absolute certainty, actually, of what happens in that layer. That's right. Which is, I think, the problem here. There is a lot of uncertainty. I mean, imagine you're a risk manager for an institution that wants to use this. The risk that you say is, I have no idea what's happening. How's that going to fly?
01:21:40
Speaker
Yeah, I presume the risk is the risk you are gliding is both on the side of the past delivery provider, but also on the side of the investor who is trading a large swap, right? Because you have no idea what will be the pricing part of your trade. Correct. Yeah. Well, I mean, you can for the investor side, if it works in your favor, that's a good thing, right?
01:21:58
Speaker
Yeah. And to some degree, as the trader, the aggressive trader, the one who submits the market order, you can protect yourself by limiting the price impact and the like, which is already what DeFi protocols have. So that side, I mean, in this particular case, this side has some level of certainty and some level of control. It's not clear that if we come up with something completely new, that that could not change, right?
01:22:23
Speaker
But yeah, so your point is well taken there, right? But you just need to know what's going on. I mean, so just to be fair, even on the stock exchange, if you submit a market order, you actually may still get a different price than the one that you see in the order book because there's dark orders and all kinds of stuff happening, right? Fair enough. It could be that any limit order is added after you submit your market order, right? And before you get a better execution.
01:22:45
Speaker
That's right. Essentially, it has to be trustless. You don't need to have to trust any infrastructure to work. You need to build it in such a way that it's trustless. Yeah, that's a very good point.
01:23:00
Speaker
All right, Agostino, this was very interesting. I really appreciate the insights that you provided into your work, and I hope that the audience appreciates just as much. At some point, we should probably have a provision too so that you can actually send questions in so that we can answer them maybe in a separate AMA session or the night. But for now, thanks so much, Agostino, for being here and for enlightening us.
01:23:26
Speaker
We hope you enjoyed this podcast. Thank you for listening. As a reminder, you can find additional materials on owlexplains.com and can stay updated by following us on social media. That's all for today.