Les Amis d’Ethereum France #11 — Les AMMs avec Swaap.finance et Mangrove

[Music] Okay, good evening everyone, delighted to welcome you to this 11th edition of Friends of Ethereum in France. The idea is to bring together the best of the French Ethereum ecosystem, but also the wider Francophonie. Today we are delighted to have a theme on AMMMs and to be hosted by Mangrove, and also Swap Finance. So, just a quick word about Ethereum in France for those who don't know us: we are a non-profit association (under the 1901 law) and have existed since 2015. For your information, we were called La 7 before, we organized workshops and events.

We merged with the Ethereum France website and now, broadly speaking, we organize events and meetups like this one, the big Ethereum conference you may know called LET. Here in July, we write content, we translate technical content as well on our website and France.com. You can follow us on our social networks, on Twitter, we have a Meetup page. For those who asked where we publish our events, we have a Discord is the usual platform, and this event, like the others, is being filmed, so that's why I have a microphone and you can't hear anything.

It's really for the video, and all our videos are on our YouTube channel. A quick word about our events this year: we're trying to maintain a rhythm of about one event per month. We had a meetup on Launching Gaming with teams from Latis who presented Mud. It was really interesting, and that video is also online on our YouTube channel, which I encourage you to watch. Last week, we had a meetup on the regulation of Diffa and DAO in Europe, which was very interesting.

If you're interested in that topic, check it out. Today, we're having a meetup on AMMs. Next month, we're going to try to do a meetup on finance and CFOs with Mazar, so it's still in the planning stages, but it's likely to be very interesting too. We're going to do a Defy meetup with Paris Blockchain Society in May, our event that you mentioned here in July, and Haiti, if so... So, quite a lot!

A week of events around SCI in July, with around 150 events, so it was quite something, it was full of energy, it was really cool. A quick word about what we're doing: we launched this two days ago. To be here, there's a label auction currently running live until March 31st, so the day after tomorrow. This is the only chance to buy tickets with crypto. We launched this because usually the tickets here sell out in about 30 seconds, so this allows you to place a bid for several days.

It's the same price as regular tickets, so you're entering a raffle. If you want to be sure of getting a ticket, you bid a little more and you have a chance to win a Sissi ticket. So, I'm mentioning it because it ends the day after tomorrow, and again, it's the only chance to buy your tickets with crypto. Otherwise, it's the usual ethical approach. So, there you go.

And we did this with... we replicated... The Defq model, we did that with the TrueFA and Comets teams, so that's pretty much it. But without further ado, let's move on to today's agenda with a presentation by Vincent Danos from Mangrove and Sterile on swaps and 3.0 market making.

Then it will be followed by a short cocktail session. So, thank you, and I'll hand it over to Vincent. Today I'm going to present the topic of liquidity provision, which is surely crucial, across three segments. I 'll first talk in general about the characteristics of Mangrove and what it offers compared to the DAX. Then I'll focus on two use cases: one that we've already discussed a lot, which relates to how Mangrove or the offerings on Mangov can manage the various liquidity sources available on-chain; and a second one related to the implementation of procyclical strategies, which are dear to directional traders, entirely on- chain.

And that's really Mangrove's unique value proposition: the ability to automate behaviors on-chain. And strategies that until now have operated off-chain, so the DAX is good, which is why, well, current events may have led to a lack of protest, but we'll still say it's good because it's centralized, it's good because it requires little or no infrastructure, so everyone can participate, and that's a powerful force in all markets. It's also good because it executes with zero latency on-chain, and the chain is a very rich universe. Being zero latency means we have a view that might be a little limited computationally because we ca n't calculate everything, but it's very, very rich and perfectly captures the variables we want to measure. So you'll see that this is particularly interesting for liquidity sourcing.

This doesn't preclude, like swaps, combining the automated market-making aspect with the traditional management aspect. How do we have control from outside their chain? So, mangroves... What's special about these offers is that they don't have the usual structure, so I'll show you one here. Part of the data is standard: you specify how much you want to sell for and the price you're giving.

Then there's a particularly large part: a callback address, which is the address of an on-chain contract. This contract will be responsible, among other things, for executing the trade when it's triggered by the match engine. Mangrove is an order book, but we can talk about that later. I won't dwell too much on this distinction, which seems to belong to the Web 2.0 universe.

We're clearly in Web 3.0 here, so it's not important. What is the underlying market structure? What is important, however, is that when the market mechanic creates a match, it calls a contract that is directly referenced in the offer. To accompany this call, there are two additional important data points: the offer must display the maximum amount of gas required for execution, thus preventing premature executions.

On the one hand, it must provision a certain amount of the native currency, the Matic, since we're launching on Polygone. There are two components: the amount of gas it needs to execute at most, then we use that with the official gas price according to the platform, and then we multiply that again by a coefficient. This coefficient will incentivize third-party players to clear the order book. Okay, so there are four. Once we've made this choice, there are four main principles that lead directly to my first principle, which is very important and will impact everything that follows: the offer can reference any contract.

Therefore, the code is arbitrary; you write it, and there are no limits on the code except for the amount of gas required. We cannot go beyond the maximum gas, for example, the high chain of 30 million units of gas on Polygone at the moment. Principle number 1, principle number 2: the code starts with... His pocket is filled with the ticker's money, so he's capable; he has a budget that increased in a flash lane effect within the transaction, and this opens up new possibilities for him. We'll talk about that later.

Obviously, if the code fails to complete the execution of the offer, or if it refuses to execute the offer, it must cede the supply to the ticker as compensation. And that's where the small coefficient comes into play. In short, we're doing more than just reimbursing the ticker for the amount he paid to launch the gold. Finally, the fourth fundamental principle is that the market engine will recall the same contract to give it the opportunity to redistribute its offers, replenish the liquidity that has just been consumed, and do anything else under principle P1. So, the consequences are that since the code is arbitrary and we don't know what we're actually running, as a mangrove, we expect emergent effects.

That is to say, we can analyze Husky and propose them, but we're going to have Surprises await; people will do things we didn't expect. So, we're really opening up the right way to think about Mangrove. We're opening a new design space, planting little flags in it, saying, "Well, we can do this, and that, and that," and we'll plant some of them together. But essentially, the most important flags are perhaps the ones we haven't planted yet. So, we have a strategy of more of an ecosystem and joint discovery of the possibilities we've opened up, but which we don't exhaust in our own investigation.

A consequence of the second principle—and this is simpler—is that there's a flashlock effect. So, indeed, if we open a Market and land, for example, without doing anything, we've created a flashlane market on polygons for land or for any other type of land that interests you. Is it more technological? Is it really a market that will interest people? I don't know, but in any case, it's there.

You just have to press a button. The third consequence is that there must be this coefficient. The incentive to clean the Carnavour structure, which is an important component, is a small trap. So here we enter the complexity of the design space: if we set it too small, this incentive coefficient incentivizes less, and if we set it too high, it incentivizes attacks to thwart specific offers and reap the associated anti-breeding. Therefore, it's a coefficient that seems harmless, but it must be handled carefully.

A fourth consequence is that since the code can republish or re-establish malicious intentions on the market where it was affected or on others, we have immediate access to offer persistence. So we can automate many things. Let's try transforming this into Huska Isis. They are not mutually exclusive; we can do everything at once, or any subset [Music]. For obvious reasons, another Huskace, or rather, a class of Huskace, allows us to manage offers on multiple markets simultaneously, since we have arbitrary code.

It overcomes the fundamental limitation of multi-token strategies, which are embodied in balancer-based AMMMs, for example, which require fragmenting liquidity. Liquidity is built for a strategy, and if all the strategies we experience are based on binary markets, we can create index strategies, for example, on a binary market framework. So there aren't millions of markets to open; there are only standard binary markets. Similarly, for daughters, there's no need to multiply the sons; we can offer the same liquidity on several markets, so we can share it. I'll talk about this again later.

We can source liquidity; this is the most obvious application everywhere. I'll come back to this; I have an entire slide that describes all the possibilities. And then we can manage all these quantities of liquidity, at least the personal ones, in order to optimize them each time there's a cycle in the code's lifecycle when the strategy is recalled. So these optimizations also lead to... Fun optimizations, for example, we can simply arbitrate between borrowing at different interest rates or lending at the same rate dynamically each time we start.

So, as we said, we can do all that, it's wonderful. We can also do many other things not on this list that we don't know about, and that's a little scary, but we don't open a new design space without breaking the mold, so let's dig a little deeper. We'll give names to these combinable Husky backups. If we can get this clear, it will feed into price defense strategies. So, typically, we'll cross-reference the price we're at with prices in the surrounding challenge by measuring them.

We can go very far, in fact, we can do things on-chain that people don't usually do, and so we can create zero-latency recruitment systems and make a decision based on what we see from the neighborhood prices. It's very powerful. For example, if we're selling, typically example number 1, if I sell at a price P and I realize that the MM next door they're going for a higher price, I'd be stupid to sell, I pass, I give up the burnout, and if I want I can even go sell at the same one since they're buying and they're going for the same price since it's finally in the same classics anyway, so here's a possibility, I can't help each other, I can deflect, I can recover the signal, refuse the trade, pay the guarantee and it really becomes a guarantee that I'm paying a premium to the one who took me to thank them, in quotes, for giving me the information that I'm going to use now to go on a trek which is completely different, so here's a possibility in the other group, the group that manages offers on several markets, there is automatically, if we have cyclical structures in our markets, auto-arbitrage, if we move the liquidity somewhere we will perhaps create arbitrageable cycles, we can check them in situ with zero latency on the chain and execute them, that means that we put the object back into equilibrium and in addition are Of course, it's arbitrage, so we have a risk-free profit, the same liquidity shared across multiple offers, even multiple markets. So, we're entering hyperspace, my friend. It's about liquidity amplification effects, or liquidity amplification.

There are people who play this kind of game, filming it, and it's always a tightrope walk. Here, it's managed by code, so we could go back to the questions, but it's a form of temporal washing, rather than the classic margin trading booklet, and it's completely new in form, at least on the blockchain. Again, it's not me saying you have to do this, I'm saying here's what we can do, and so this is the beginning of a list, but clearly it's possible; we've programmed it, by the way. Then, another good one, the most obvious application is the application that manages liquidity sources, since the mangrove mechanism completely combines the publication of trading intentions with liquidity management. So, the liquidity—they can be working, you just have to be able to recruit them when you need them.

So that It's a whole topic, a dirty one, and in fact, in the simplest example, it's traditional market making where a market maker never actually owns the asset they sell; they borrow it from the market. And that's actually how we built my Grove. We were familiar with these strategies; we were reading similar papers back then, with the year, date, etc. And then we talked with people in the markets. We knew that liquidity is never in the market maker's pocket; it's a different profession, and there are additional ingredients.

So we'll talk about it again over a drink. But we're not obligated to do classic AMMs that offer returns to liquidity providers. We can also implement on-chain option replication strategies, for example. It's very doable; we haven't implemented it yet, but we have it in our files. So, yet another degree of freedom in the design space.

Okay, so now we're going into the second segment. Just one slide, we'll be quick. So, this is just to give you a brief overview of all the manipulations of Liquidity that we can create, and then I'll move on to the husk that I'll have developed a bit in the last 10 minutes with you, which is very new. So, you tell me what you think. Here, the problem is sourcing liquidity.

We assume the code has started, it's triggered, it's running, and now it has decided—we've gone through the first steps of the code's logic—it decides to attempt to release or deliver. And now the question is how to deliver. So, we'll distinguish two main classes of sources: there are the sources that belong to us, which aren't necessarily accessible. For example, if I have collateral at AV that someone has completely wiped out, well, I have one that I can't funnel as an underlying asset. This happens often.

And finally, there are... So, this is really a whole dimension of on-chain trading, which, by the way, isn't specific to members. There are many people who are concerned about this problem. Anyway, this is an example of capital that is in the hands of the code, so we'll call it 6. It belongs to us, so let's...

Here's a short list: it could be in my pocket, so it could be on my RC 20, my address; it could be with an Ender as collateral if I'm completely passive (I don't borrow, I only lend); it could be with Ender as a borrowing capacity, so it becomes semi-active, you can feel you need to start paying attention. There are liquidation conditions, and the line of credit evolves over time, so it's more delicate to manipulate. There are completely generic Volts, so passive or not, if they are active—that is, if they change their composition without our intervention—you also have to be careful. It could be LP tokens on a uni V3 pool, for example, in which case the price will also affect the composition of our holdings, and so someone malicious, or just price action, could mean that we wanted to withdraw ether, for example, and there's none left because we sold it all because the price action exceeded the upper part of our range, for example. So, for example, when It's active, it's more complicated.

So, in fact, these sources that we legally possess, they are either active or passive, and if they are active or semi-active, we have to monitor them; it's part of strategy management. Furthermore, I haven't mentioned this yet—it's a long discussion—but it presents very different attack vectors. So, for example, curiously enough, it costs practically nothing to dehydrate a chicken on a V with a flashome, whereas manipulating the price of a universe 3, for example, which has a lot of liquidity, to force us out of the range and put us in check, that's much more costly. I'll come back to that. And then the other source of liquidity—well, here we're talking about the fourth dimension—there's no reason to limit ourselves to the liquidity we possess, so to speak.

We can also convert the liquidity we possess into the liquidity we don't possess. So, we can swap during the execution of the transaction. I call this using "trans"—you have to transfer. So, essentially These are liquid forading behaviors, liquidity, forading speaking, we can do optimal splitting On the chain, we can, and in fact, if we think about it, we abstract ourselves from the problem. We're solving a generalized optimal routing problem.

We're not going to solve it optimally, but it's an optimal routing problem, generally a convex problem, and we're solving it with zero latency. So, we might not solve it as well, but on more precise data, and under budgetary constraints, namely the liquidity we have, and also under constraints that reflect the user's risk and return objectives. Okay, so now we're getting into the lottery that will conclude this presentation. So, we're in a very traditional framework: we're directional traders, we have a large machine that processes the signal, and at some point, it beeps on the console and displays " black version, you have to be long, Eth." So, very good.

So, do we buy and hold a certain amount of TH? And then, typically, what we'll do is try to preserve our capital by placing a stop loss 2% below the entry price, and then maybe... An exit strategy with a take profit 2% above the entry price to pares the trade, and then perhaps a time to leave as well, so we don't stay between the two prices forever. So the Stop Loss is the component that interests me here. It's a cyclical contract strategy element, pro-cyclical, sorry.

It follows the price; when the price goes down, you have to sell, so it's pro-cyclical: when the price goes up, I buy; when the price goes down, I sell. It's the opposite of a market-making strategy, and by definition, that's something you can't record in a DAX because if you try to buy or sell at a low price, you 'll be caught immediately. Unless the current price is roughly the price at which you're trying to sell, but at that point, you can directly execute the order. So here's the challenge: I'm going to abstract myself a bit from knowing how to set the Stop Loss. The Stop Loss has the following syntax: when the price of the set I just held...

so I'm going to be long It falls below a certain price threshold, so it's a down crossing. I'm going to sell at a lower price, or maybe the same price, but more likely a lower price that will set my sleeper order. So, a minimum price P1 lower than the P0 at which I'm triggered. I'm going to sell this asset that's burning a hole in my pocket. What I want is a stop loss, and how I'm going to sell it—we won't talk about that here.

I'll assume, for example, that I sell it in the form of a limit order for this example, but it's not at all necessary. I'll assume that I recast it as a limit order on the bookmaker where I'm going to implement this strategy, but we can do whatever we want, it's not important. So, I've already said it, but I'll repeat it: what's important is the take profit part. It doesn't pose any problem; we can write it in the golden notebook. So, it's the market structure because it proposes selling at a price that's above the current price, so nobody is interested.

On the other hand, the stop loss part—we have to invent something else; it's secret. We can't To show it, you have to entrust it to a third party, who might be a banana, and who promises to execute it when they themselves detect the downcross. So, a small point: all these structures are iterable, so the Stop Loss can itself be placed, and its trigger placed by another Stop Loss. You can nest these techniques with these Take Profit/ Stop pairs. These are things I have to do with traders quite often; there are no constraints on that side, we can implement them just the same.

Okay, so the idea is, we can't place our sell order right away, so what we're going to do is place a buy order, which is a bit counterintuitive on the other side of the book. So, I can't sell at a very low price right now, but I can very well try to buy a ridiculous pre-order. Nothing will happen there, so I do that, I place a flop order. It's small in volume and it's small in price, so it's not taken, and it's well below the current price, and it's small in volume because what interests me is not... Buying volume is what interests me; it's capturing the signal that there's a downcrossing of my price threshold.

And then what do I do? Well, I inject code into the execution part of the code that will start selling when it detects the signal. We've coded pro-cyclical behavior within a market-making structure that is fundamentally counter-cyclical. So let's look a little closer. There's a small catch.

So how will it execute? We're going to check something— I won't say what it is first—and then two things will happen. Either we decide to go ahead, great, we believe a price signal we just received, the check indicates it's OK, and at that point, it will sell not only what we wanted to sell from the beginning (the large V) but also the small V we just bought— the APA, if you will—and we'll sell at the agreed price (P1). And if the check predicate says no, then the signal If we don't believe it at that moment, what do we do? Well, we make the trade anyway because if we don't believe it, it means the price is higher than the trigger price P0.

That means we're getting a good deal, we 're buying cheaply, so we'll buy. Then we'll go to the source where we identified the high price, trigger the arbitrage, and recover the proceeds of the arbitrage risk-free. No rational player will take that unless it's an attacker—I'll talk about that in a second. And then we reset the price sensor. So we set it up at the moment—remember principle 4—we can repost our offers, and so the price sensor makes money.

Well, if there are naive players, that is. But otherwise, it stays put until it triggers for good and triggers the Stop Loss. So the problem with verification is that if we trigger the stop, then we're... Essentially, we're selling a volume delta at a price delta, and we have to be careful. If the price delta is small, it's fine; if the price delta is large, we're being arbitraged by a malicious player.

So this is where on-chain execution capabilities come into play. What we're going to do is... how will we attack? We'll proceed. First, he'll have to pay to bypass the predicate check.

So that's a cost. For example, if it's price manipulation on a friend because we're going to read the price of an imam, it will cost him the price of manipulating the price, so a round trip. A price that will be proportional to the market's flow and its liquidity; it can be very expensive. Then he'll buy the A7 that I'm offering, less than buying what doesn't have it. Then he'll sell it to me; that's step 3.

So he'll get the [Music] cache that I'm going to pay for, so VP0, and if here is... He took the opportunity, bypassing my predicate, and so a sell order at a price P0 has just appeared on the other side of the order book. This is advantageous, so he'll take it, he'll spend again, he'll resell at the current price, and if he's taken the opportunity well, he wins. So what does that mean? He wins.

It means that the price is positive. So the conclusion of all this is that it's wonderful; we can encode covariant, cocyclic, recyclic, or directional strategies on the chain. From the moment we have a primitive like the stop-loss order—this is its dual, which you can call, I don't know, " profit" or something like that— who buys when the price goes up. From the moment we have these two primitive components, we can implement any directional strategy, but there's a price to pay. We have to carefully calculate the attacks we might suffer, which are literal attacks, especially if the price censor repositions itself in the same place.

These are attacks that the attacker can carry out by manipulating prices earlier. And we He was talking about attacks where sources are drained. This is another type of attack; it's an attack where price signals are distorted. So how does the attacker do it? All the contracts are on-chain, so they disassemble the code even if we have n't provided the source code.

After a while, if they really want to, they'll decompile what we're doing. They'll understand what we're doing, and then it's up to them to find where they can attack. There are many additional defensive measures. One that's magical is that we can detect, in terms of robustness, the fact of being called a second time in the same transaction. In this attack, it's important for the attacker to " sandwich" us.

Right after eating the slice, they must have triggered the mechanism that tries to consume, and they must type a second time in the same contract because it's the same callback address that will handle both offers, and the callback address can handle the fact that it's being called again. I'll explain how we do that later. But it's very fun, so there are several layers of defense, but in any case, the message is that you have to be careful, and it's typical— I didn't just give you this example tonight—it's typical of the mangrove design space. There are new possibilities and new opportunities for attackers too, so you have to be careful about what you do. So we forget about huskies.

What is the in-game mangrove? At the end of the story, there's no cost other than code to refer or reference liquidity, at least what is actionable on a given chain on the mangrove markets. And besides, we can reference it multiple times, as we said, we can publish it more than what exists, so an amplification. So in the end, it's not really the VAT that counts anymore, it's rather the total, or what is referenced on the bookmongroises, we can no longer count it, so it creates aggregation problems, problems of knowing how much liquidity there really is on a chain. But if we If you want to make the effort, we can know everything is transparent, so I'll conclude by saying okay, well, we have Smart Money that's chained to liquidity.

It's no longer really something we push and control from the outside; it speaks through pricers and similar structures. It senses price movements; it doesn't need infrastructure. It doesn't hurt to have additional infrastructure to give it extra information. For example, typically, if there are price dislocations, it's good to know, and it's not necessarily readable on the chain. Then, it constantly optimizes its personal source every time it launches, whether it's running or not.

So remember the code that runs—well, I'll get into the technical details here—but there's a part of the code that we launch at execution time that will survive a run, what we call the post hook. And finally, and I think this is very promising, it has a personal execution layer that runs with zero latency. Thank you for your attention. [Applause] I'm just going back to the attacks, so basically it would be a flashboat attack, or the data that will trigger your contract. The guy can grab it, run a simulation beforehand, see that you're going to make a purchase, so he just buys to raise the price and finds the threshold because of the simulation, and then he resells at the end, right?

Yeah, so if you do it in flashback, you'll be the first. If you win the flashboat contest, it's a bit more complicated than that, but indeed, yes, it's a kind of sandwich running. You'll simply have to pay the cost of making the verification predicate false, and that's a cost. So typically, the verification predicate is "Validate the tiwap of a V3 story if we were running in parallel," and what looks like the price at which you're currently executing... Ah yes, okay, there's the price in the request, so he can't really modify it either.

So the offer knows at what price it's executing, it's P0. Now, if the one who tries... To trigger me, it triggers me in an environment where it's easy for me to realize that the current price is twice P0. I'm going to run that part of the code, which is the part where I win. However, if he has significant resources and can manipulate all my information sources, he has the right to do so.

In any case, it might cost him too much to be economically viable, but he can make me fail. It's a bit like in Mission Impossible, managing to build a universe around me, an execution context where all my checks are actually valid because he's manipulated all the oracles, roughly the same ones I manipulate. This situation isn't new in challenges; there are many hacks, but this is the norm. So, when defending yourself with public on-chain prices, you have to be careful. It's an economic equation; you have to write it and manage it dynamically.

Because the costs and conditions of the equation depend on the price... So basically, we're going to be in price ranges. If we deviate too much, for example, the price censor from the current price, we take risks, so that's what we need to manage. There's another variable in this equation, which is the level of reward we can expect by failing an offer. But here, there's a straightforward attack that's just about manipulating prices, it's like a running sandwich, except in a running sandwich, we're lurking in the shadows, waiting for the victim transaction, the victim swap.

Here, it's even better because we can trigger it. In fact, we can still sandwich something that we trigger ourselves. So we have to make it robust. The request that will arrive, the contract is n't necessarily the request that will wake up your contract to potentially attack it and make it fail. It's not necessarily signed by someone, so it can be anyone who calls it, really without the date.

Yes, and if manipulating the verification environment or whatever, it's really just OK, OK, great, thank you very much. This pure attack, we can... To thwart this, I used the trick I described, which is actually a generic trick that's quite funny. I don't know if it can be used to protect other things, but it's a small piece of robustness that allows, through introspection on the variables that link them, how much it costs to read in gas. It costs less when you read for the second time in the same transaction, so you know you're being called back.

You can even count how many times you're called back; that's when it gets a bit expensive. But if you're called back a second time in the same transaction, and there's no good reason for it to happen, it's probably because you're being attacked. And then you can just close the liquidity. So that's still very difficult for an attacker to circumvent. Afterwards, they can try to attack us in the next block, but the bounty might escape them.

They don't know anymore. Okay, well, thank you very much. So what's the difference between a direct AMM version and the original version we could have? It's still two The execution models are very different because, as we know, in continuous market making, you need threads to pay the trader due to the principle of permanence. So here, the payment principle is the same, at least for the same ones we've built.

They work; they are what we also call path-independent or not, so it's the guarantee that when the price loops back to the entry price, we haven't lost, and in fact, in practice, we've won. But the source that plays the role of FISE— it's funny to say it this way because normally it's the world upside down— we create threads because the structures of the same market are continuous, whereas in this type of discretized structure hosted on the order book, the revenues are based on what we call spreads, so the differences between the price at which we buy and the price at which we sell, essentially. And so the two sources of profit are difficult to compare. After that, there are ways to discretize finely enough so that the P&L of the discretized strategy starts to resemble At NLP, continue, okay, thank you. Another question, a bit ambitious, yeah, because it's very gas-intensive, so here we're going into polygons.

Actually, it's more of an object, yeah, well, yes, so these strategies aren't sensitive to MIVV, but the techers will be. And to be attacked within the constraint that limits the creativity of this code on the chain, it's first the size of the gas and the cost of the gas. So it's true that on the terrarium, it seems difficult to deploy all these source optimization strategies, for example, it's going to be so expensive that it will be necessary to raise the prices at which transactions take place. That's why we went to polygons. And then I have the impression that the trend is that the new L2s that come out are more efficient and even cheaper in gas, so we're going to stay in high chains that allow this type of creativity.

On MIVV in particular, we don't have a particular answer, we behave like any other market. So there, in fact, when we've searched The first time we raised funds, everyone was saying, " Your idea is wonderful, but it can't exist in a world where gas is expensive." The second time we raised funds, nobody said that anymore, but now they were talking about MiVI. I think the third time, nobody will be talking about MiVI because the ecosystem had really solved its problems with the same encrypted "chicken" (a specific type of token). The proofs are all there.

If you want to do something innovative, you have to approach the future from a different angle. You can't wait until it's possible to do it; you have to do it before it's possible. I've worked with people, I hope. Sorry, yes, well, there, revising the chain and consensus mechanics that allow you to bypass the same-chicken problems is really the part of the high-level infrastructure. It's the companies.

I was, for example, Flashbot, etc. These are companies. Not that I consider it a good solution, but it's an interesting temporary solution. It must have mobilized people. There are a lot of resources, so yes, of course we can.

There are already plenty of channels that offer to have internal wiring within comic book structures, for example, which are part of a consensus (I don't remember the names) and which allow us to completely bypass the fundamental training problems on Dax, but still in general terms. But we ca n't build it there; we're in a different role. We're building on top of an existing object that will benefit all forms of Dax. Otherwise, there's the solution... Cyril recommended that we discuss a project called Redstone, which offers oracles that improve upon the GMX model.

They're similar to Darkool, meaning we commit to executing transactions at a price we do n't yet know, but which is fixed at the beginning of the next block and therefore protected against this type of attack. So, these are... well, that's pretty good. It's a hybrid solution that doesn't affect the infrastructure but still requires a certain degree of flexibility from users. So, we'll get there, but it won't be us, we'll just take advantage of it.

Yeah. [Applause] Okay, great. Well, hello everyone, glad to be here tonight. So, I'm Cyril Pastour, the co-founder of Swap, and what we do at Swap is market making 3.0.

Our vision is that default should become the new infrastructure of the financial system because we consider it... It's more accurate to say that it's more efficient thanks to interoperability, transparency, and security. Our contribution in all of this is to allow any type of investor—individual, institutional, or protocol—to benefit from passive and profitable market-making strategies. So why did we choose this topic for the Market Meeting? Because we believe that market-making is still an issue that is n't completely resolved in crypto.

On the one hand, we have tragedies, which we can discuss later, and on the other hand, there are custody risks. These players take possession of your funds when you're with them, and well, you know, you all know, I imagine, the adage, note, surprise, nature, coin. In fact, this presents risks for those who hand over their funds to these players. So why is this a problem? We've seen that when everything is going well overall, it's not necessarily an issue, but when it starts to feel routine, or when there are actions, well, of the...

Marketers who may not be very well- intentioned, or who have ethical considerations that may not be very good, lead to tragedies both in the traditional world of finance and in the world of finance. I think there's someone you all know, especially right now because there's a documentary about him on Netflix: Bernard Madoff. He was involved with traditional crypto assets, and it all seems to point to leverage. So, obviously, when it works— when we're in a bull market—these strategies work very well, but as soon as the market turns, they're not resilient, and it leads to collapses. And then, of course, the example everyone knows is Fiex.

So there too, we have a problem with transparency regarding the strategies used by MEDA, with issues as well as accessing users' accounts. There are also problems, as I'm saying, with Calamina, for example, that there are many protocol projects that had MEDA... Market makers, who consequently had part of their token supply deposited with Meda, well, with the bankruptcy of FTX and Meda, these protocols are now stuck because these tokens are seized by the American liquidator, and it will take years before they can recover this part of their supply. So, again, we see that the problem of custody is a real issue. So, that's the first issue.

That's why there are problems associated with traditional market makers, both in traditional finance and in centralized finance, in crypto. The other problem is that of market maker roles. Market maker automation has many advantages; it allows us to solve the problems I mentioned, and it also adds other very interesting things, such as composability. Within the IFI ecosystem, it also allows us to make tokens liquid that wouldn't be liquid in centralized finance, which allows us to create initiatives. Economically, for small communities, well, today there are actually many small projects that need a liquid token for their project needs, and they can do this thanks to their friends.

They couldn't be listed on centralized exchanges for legal reasons, listing fees, etc. So, this is what happened, which allowed me to do this. The problem that arises for these same people is that these products are very inefficient in terms of liquidity. I imagine that if you are LPs (Licensing Partners) on AMMs (Average Marketable Securities), you have all experienced what is called hypermanent closure. In fact, there are several studies, and we have also done this work ourselves, which shows that when you think about it, AMMs are not really investment products from an LP perspective; they are more like casino products.

So why casino products? Because when you look at the structure of returns for a LP on a friend in the absence of an incentive from the same person is exactly the same as those of the roller, meaning that overall we have a negative expected return, which is not excessively negative but is negative with very high volatility. So, in other words, you have a fairly high chance of winning a lot of money, but you have an even higher chance of losing it. So you are in the casino, and the casino is arbitrage. So what we are trying to do at home is create a market maker, a friend who combines the virtues of traditional markets: composability, transparency, our custodiol, democratization.

So it has really registered in the doses of default, but with the performance of an investment product. So for that, we launched a first product, X, or V1, nine months ago, which we could describe as a risk-return strategy. So it's a product that was launched nine months ago on Polygone. This is a product that has already shown that it is possible to do automated unchain market making with positive performance. So, in concrete terms, we have approximately 2 million TVL, a little over 2000 backend providers, and about 0.

1% of a permanent stake on a pool. We only have one pool for now, which is a BTC and USDC pool on Polygon with a net return. So when I say net, I really mean what you put in your pocket. It's not the "why" points you see on the protocols, which are quite biased metrics and don't take into account all the costs that the providers face on these products. So, an ethyl that is around 1.

75%. And with volatility—in fact, volatility, which is the best measure of risk, is ten times lower than that of traditional money markets— so how do we do that? One of the main problems with traditional money markets is that they violate some very important laws of finance when you want to make returns on the financial markets. I don't know if you like movies, like Wall Street, but I really like them. So, I've included a short quote from a film called "Mardin Call," which is quite cynical, where a hedge fund dumps some pretty bad products on the market very quickly and tries to get out of a difficult situation.

There's a rather interesting line spoken by the manager of this hedge fund, who says there are three ways to make returns on the financial markets: either be the first, be the smartest, or cheat. And so, being the first, in difficulty, is what we call MeV (Mean Value), which is knowing how to position yourself first in the block to be able to take advantage of the... Other market participants are the smartest. In fact, the problem that AMMs face today, from our point of view, is that they don't use the math best suited to market making. AMMs use a formula called the product formula xylk, which is very elegant and allows them to list assets for which there is no price information, but it's not at all suited to liquid assets for which there is a market price.

So, what we do is, what we believe is that the default changes a lot of things from the perspective of the infrastructure of the values of the interbank by power, but what it doesn't change are the maths behind the financial products. So, our bias, the one we've chosen, is to use the most used and advanced models in traditional finance or in crypto finance and adapt them to the context of the So, what we use are histochemical models, which are the most widely used in marketing. Then, the last thing is cheating. I think cheating should be understood as having as much information as possible. In traditional finance, here, in the words of this cynical manager, Edgefred, it means having insider trading, having private information.

The problem is that there are several levels of training. There's level 0, which means having no information. There's level 1, which is exploiting all possible public information. And there's the illegal level, which is having private information and using it. That's illegal.

The problem is that AMMs (Agent Market Makers) are at level zero, meaning they're completely blind to the outside world and what's happening with other companies, for example. As a result, they don't know the market price. And what that means concretely is... There are, well, there are traders, or rather, actors who are the arbitrageurs, who will provide this price information to the participants in the pool. But these actors are actually handsomely paid by the backroom providers because they only act if the transaction is profitable for them, and this results in very significant losses for the LPs (Licensed Partners).

So what we do is try to have real-time price information to be sure we can avoid this leakage of value to the benefit of arbitrageurs. So, to explain in more detail how our strategy works in V1, this is going to be a bit more technical, but it's based on three main mechanisms. The first idea is to assume there's no Ribal Insignia. In other words, the benchmark is Roddle, so that means if you start LPing with one Ether and 1000 USDC in an Ether/USDC pool at Swaps, the idea The thing is, regardless of the price of Ether, our goal is to give you 1000 USD worth of Ether plus some threads. Whereas a traditional investor will take a position on the market, meaning that depending on the price of Ether, they will adjust their portfolio accordingly.

So, they won't be neutral with respect to the asset; they will take a more fundamental position. Let's give a concrete example: imagine the price of Ether rises to 2000 USD. In this scenario, you have a foothold in the market. With a traditional investor, you're essentially holding 1000 USD worth of Ether and 1400 USD worth of land. So, with the new price, you'll have approximately 2800 USD in your portfolio.

The idea is that you have roughly 3000 USD. In this scenario, the price of land has risen to 2000 USD. Okay, then... There are the girls to add, etc., but overall, that's how we approach the subject, on the one hand, Manuclos.

So, this introduction of the absence of Ribal hunting is going to pose a problem. In fact, a traditional friend is dictated by the relationship between the quantity of assets and the price, a constant relationship between the quantity of assets in the pool and the price of the assets. So, we need to define a new way to calculate the price and a new way to rebalance the quantities. So, the first thing we're going to do is, for the price, we're going to use oracles that are in the meat, so Chanel, and this will allow us to avoid paying for arbitrage. To have real-time price information on liquid assets, the oracles have introduced other problems, notably fronting problems.

So, Vincent, let's talk about that a little before. So, to avoid this fronting, we're going to introduce our famous stored models. In fact, this allows us to... Frontroning is when a VM attacker looks in the same pool, which is where transactions arrive before being validated on the blockchain. They position themselves between two oracle updates to exploit the oracle's information, the " eye of the oracle."

The greater the variation between two updates, the greater the potential exploit. So, what we do is try to anticipate significant price fluctuations in the oracle using SOCACIS models that allow us to price volatility risks. We increase our fees when there's a high probability of volatility. Another problem that arises is a quantity imbalance. In concrete terms, if you want to hold one Ether and put the SDC (Single Coin Offering) into the system, if someone trades, they will inevitably disrupt this balance because, for example, they might want 0.

1 and 100, so they would buy 100, essentially giving the equivalent of 100 USD. So, for 01, in the pool we'll only have 0.9 and land and 1100 USD. This is, for example, in the absence of sons. So what we're going to do to guarantee balance is introduce a concept of " sleeping," which means that anyone who unbalances the pool from its target balance will pay an additional sleeping fee.

This sleeping fee will then be given to those who want to rebalance the pool. In other words, if the pool is balanced and you unbalance it, you'll pay more; if it's unbalanced and you rebalance it, you'll pay less. So that's what keeps the pool balanced. We're not stopping there because V1 was more of a "professor of concept" that showed it was possible to have complex, chained logic, that it was possible to profitably make market-making decisions on access to liquidity. And so, here we are...

We're currently working on V2, so we'll give you a bit of Alpha here in this presentation, which we've finally released. We think it will be a product that will be 10 times better. First, we've worked a lot on the models we use, and in particular, we're doing something quite unique: we have a collaboration with researchers from the Louis Bachelier Institute, a research institute in finance and mathematics. Together, we created what we call the MM Simulator. It's a kind of simulator that allows us to test different strategies in thousands of market conditions.

The problem when we want to test a strategy is that even if we thesis it in real-world conditions, in reality, very few scenarios actually occur. What I mean by that is that an extreme event has a very low chance of happening, and so, strategies can perform very well in many different situations. But in extreme events, it can be completely unbalanced, so it's important to supplement real-world data. There's also backtesting, which involves testing strategies on past events. We have a more simulation-based approach that allows us to study strategies across many different scenarios.

This AMM simulator has allowed us to determine an optimal model that we can use in our V2 to also address [Music] . And finally, the other innovations we'll be bringing to V2 are changes to our architecture. I won't go into more detail today, but it will allow us to increase our... well, one of the critical points for us is what we call data lethency. It's how quickly we can get price information from other exchanges.

Our new architecture will allow us to greatly improve the speed at which we obtain this information, and it will also allow us to... to mark the profession much more with tokens because we are limited by the speed of Axel information, so we are super excited about being able to release V2 soon, and in this context, we are offering you access to our whitelist. We are going to change this; we will launch it in a few months, and we are launching a whitelist program that will allow you to LP before others, at launch, and to have access to exclusive benefits. I don't know if you have any questions, so we'll see if this also applies to tokens that are very illiquid, or rather, token validity. We remain focused on tokens that are more liquid, and in fact, for a market maker, this represents a real marketing challenge for illiquid tokens.

So, our focus today is to bring deals to the backroom providers, and so we will stick to tokens that are still quite liquid, even if we will be able to go a little further than what we're doing today, thank you. I was sorry, I have some questions regarding your simulations on the consolation slide. Yes, so the first questions I have are about the parameters, the types of parameters. So you'll be working only with synthetic data. And also, the second question I have is, according to what criteria do you do your simulations?

I'd like to have more details. So if you want more details, really go into the depths, we had a research paper in December that summarizes all of this, and so you really have... well, there you go, you'll be able to really go into detail. But if I can be a little more specific, basically, we take a pair that is the equivalent of an Ether/USDC pair in terms of volatility, and we simulate many price behaviors. And then we make assumptions, both about the price behavior and also what we call the evolution of demand.

What we call demand is how much traders want to trade and... How do you think this trading demand evolves based on the price of its assets and the margin the market maker takes on the asset price? I don't know if I'm being clear. So, we're going to run a simulation. We've simulated on, I think, about 1000 different market conditions.

Each of the strategies, well, several strategies, so we've simulated, for example, Nice B2 strategies, curve strategies, on really liquid assets, but volatile ones, sorry, not on the Persevelcoins. Our efficient model that we built, and also our V1, and the idea is that for each market condition, you'll end up with a return at the end. The idea is to position each strategy on a matrix between the return and the variability of that return, with the obvious idea that the more you have, the more variable the return, the worse it is. That's because it means you increase your risk, and the higher the priority, the better. I do n't know if that's okay, very clear, thank you.

[Music] I understand very well the protection of LP providers, but doesn't that come at the expense of, or for example, are there times when some "hens" (a type of trade) become unusable? Imagine there's a trade in Quimper, everyone buys it, which means the " hen" becomes unusable, and therefore nobody wants to use it anymore because there are too many " girls," but even normal users, even those who aren't into arbitrage, because that's not a problem for them, or is it [Music] for us? So that's also why we want to increase our threads while there's a lot of volatility; it protects me from that too, I think. What's interesting, the question is also the aspect of favoring LPIs (Limited Pricing Information), well, I don't know if that's what you had in mind, and so isn't that to the detriment of traders? Well, the first thing is that we don't consider ourselves an exchange, well, we are an exchange by nature, but Actually, we see ourselves more as a market maker, and the goal of a market maker is to protect the interests of the LPs.

So, to put it bluntly, if we make a trade per year and it gives us a 50% net return, we'd be very happy. There's no problem with that. Our goal isn't to become the place where traders trade. I think that's more the domain of protocols like Mangrove, which can provide that kind of value creation. Our goal is simply to be a player on different marketplaces where there are a lot of trades, and to be able to offer services to the backroom providers of the deal or liquidity on their storage.

So, why is it that as a Prolycosie provider we still manage to be competitive for traders? It's not a two-person equation, but a three-person one: there are the LPs, the traders, and the people who actually want to trade—those who pay for the liquidity service and are willing to do a swap. This is for USDC versus USDC. For example, and then there are arbitrage opportunities. The problem is that arbitrage opportunities are what extract the most value.

So, if you consider it as a zero-sum equation overall, all the value is captured by the arbitrageurs, and this is detrimental to both Delpi and even the trailers in a way. So, if you remove all the value extracted by the arbitrageurs, you can distribute quite a bit to both, ultimately to the trader. I'm not sure if I'm correct. And then, generally speaking, it's a competitive market, so you want to be able to address both... you want to be competitive in order to generate returns for Alpine.

So, the algorithms are also calculated to be optimal in this regard and to be effective when needed. But I think it's important to understand that not all traits are worth taking. Today, the problem with AMMs is that they make a lot of trades, and based on this rule, many of them are actually easy-mindful and shouldn't be done at those prices. So we leave the bad trades to the AMMs and then we take the ones that are... yes, the strategy consists of withdrawing liquidity from a market when it's too volatile.

It's a standard market-making strategy, and you can't kill it, so it's a conservative approach to the market maker's value. Otherwise, I had another question about this slide: in the bottom right corner, you announce the effective model, but we don't believe there's a parameterization that will work in all market conditions. So you manage its command? It's a model with a control that's capable of recognizing market patterns and adjusting its behavior. Yes, indeed, that's right.

There's all that calibration work involved, actually. There are several purposes. The parameters on the left are the inputs of this model, and so, for example, we recently recruited a... A trap in physics is that you can work precisely on calibrating these models and adjust their behavior according to market conditions. It's something we'll do as we go, something we'll learn as we go.

Otherwise, there's a point in your presentation where you talk about quickly injecting a reliable price signal, which makes me think of two things: first, I want to steal your signal if it's on the channel; second, if it's very reliable, that's great, I'll take it. The one from a V3 story is worth 20k in gas, the marginal price, the execution price. You have to pay a little more, but you can examine it for small volumes. The TiWAP is 24, same thing, how much gas will it cost? Okay, so the fact is you'll have your price on the shop, so if it's very good, you'll be a free oracle.

By the way, I do n't know how you solve the problem in training, how, for example, when I interact with the chanling contract, how do you have a Link se I figure out how to know I'm not in a structure that I can't call it in, that I can River to prevent payment. I'm sure they've found solutions, so maybe you can copy their solutions if you want to protect your price signal. And the other thing that makes me think of is that it would be interesting... We actually did it a little bit indirectly when we looked at the literature that covered this. Ultimately, it will be one of the determining factors in the effectiveness of your strategy: the rare events where there's a price dislocation.

Because you've worked a lot on your Oracle, making it very robust with very low latency, you have a better price indication than the rest of the surrounding challenge. Therefore, TLP doesn't lose, whereas other LPs, as you explained, lose a lot because they're up against arbitrageurs who get price signals very quickly and, above all, arrive at the front of blocks. There's compelling evidence that today, at least on certain channels, the square of the lead price of centralized stocks is done very, very effectively on the DAX because there are people who know how to be first on the blocks, read price signals very quickly, etc. So my question is, you [Music] go back a little bit, so if this signal is very effective, it's going to be somewhere, and that's why I'm telling you I'll fly, it's going to be somewhere, we're moving forward on the rest of the challenge on the channel where you work, and it will be interesting to know where you can already, by the way, how often is this mini price dislocation between the good signal and the delayed signal that everyone has, if we're on the channel of interest, how often does this happen? Well, maybe, well, today we chose not to communicate on how we're going to do the infrastructure because, well, there you go, we have, well, there you go, so what I propose is that we talk about it directly, and then you started your intro by talking about the opacity of market- making strategies, and you're not saying everything there, but well, we're currently working on the beginning, but we're going to edit it, it won't be about rare events, well, what we have, well, what also showed V1 is that we were extremely resilient in extremely difficult market conditions, so, well, to give you an example, we launched, so I think that That was the week of the Strahouse Capital crash, which also failed again and completely fell apart.

So that was our first week of launch. Then we had FTX. During FTX, we saw a net gain of over 50% for three days while everything was finally going wrong in terms of performance. And then recently, two weeks ago, during the Adepèges SDC, we saw a net gain of over 15%. So it's a strategy that's very resilient in times of major market turmoil.

For now, it's exceptional, but how did you manage it? How do you explain it? Yes, but what I was expecting was for you to tell us that you hadn't lost any money when everyone else had. Well, actually, you have a lot of volume during these periods, with many people buying at higher prices. So that allows us to increase our revenue during these periods.

And then we have protection mechanisms... In fact, we don't experience the downside of the closed impermanence that other AMMs do, or in these moments of volatility, well, volume helps them, but they still lose quite a bit with a side effect because prices fall, and so we, well, this proves that our protection mechanisms work well in stressful situations and therefore allow us to capture all the obside related to volatility and the fact that traders are either very active, no, that's not good, great, thank you very much. [Applause] [Music]