New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

DeFi Exchange Protocols 101 Precision and Accuracy in Fixed-Point Arithmetic - Mark Richardson

NapulETH MeetupThu, Oct 9, 2025, 12:00 AM

Speaker

Mark Richardson

NapulETH 2024 Open Village

Transcript

leaving the ethereum side completely blank and so this is what it would look like over that chart and as you play that simulation out you'll see that over about 6 months it makes about a 30% Ro Roi so we don't measure things in apy because I think this is a bit of a like a defi um like deliberate Veil you know as to how to calculate things so we just measure everything based in the cash asset that the user has nominated and so in this particular case you know starting with 1 2 3.45 compound um you would actually have improved the value of that position by 0. 81 eth over this simulated time period um and then referring to real world results again on the app you can explore how different people are currently trading these assets um here's one from the cell blockchain uh where someone with only $7 in liquidity um has already achieved a 62.1 15% Roi in a fairly short time period trading uh usdc versus cello and this position has traded hundreds of times so um each one of these pages is 10 results long so we actually uh allow the user to go and interrogate the blockchain to see every single trade that they've participated in um and there's 22 pages of this data for this users specific strategy um and so what I'm trying to to point out here is that we've really created a system that's much more aligned with user agency rather than the protocol prescribing a very specific trading strategy that we call liquidity provision so how does this work obviously the mathematics that describe asymmetric liquidity are slightly different or required a slight transformation compared to the the traditional the canonical concentrated liquidity equations and again I refer you back to the stuff that I've already published in archive to see how these things are derived the only thing you really have to know here is that a and b are rate parameters and y and z are token quantities in non sense and so if we are going to allow users to choose any set of rates and Supply any amount of tokens then what is a reasonable range to support because eventually um ethereum is going to run out of memory this is a really interesting question to tackle so for example if you imagine a user is wanting to trade the shenu token versus wrapped Bitcoin which is a totally reasonable thing to do right these are both highly liquid um you know very culturally significant tokens in the in the crypto currency economy um the problem is is that Shino is relatively worthless and I don't mean that that is you know that the Shino is a bad token I just mean that its per token value compared to R Bitcoin is relatively low so those that subscript nine refers to the nine leading zeros here and the problem is is that if someone said I want to trade one Shea Eno for some amount of wrapped Bitcoin that's like asking how many Ferraris can I buy with a penny right the you can't subdivide the Ferrari and so at this point we're already exhausting the decimal limit that Bitcoin tolerates it only has six decimal places of precision but it's actually worse than that because shba Eno and rat Bitcoin um both have their own decim alties the shibo token has 18 decimal places of precision whereas rat Bitcoin only has eight and so what this means is that on a token per token basis sure it's got nine leading zeros but on on a token way basis it's 19 leading zeros which is a very very small number and appreciate that the user can denominate this trade in any direction either they're trying to buy R Bitcoin with shba Eno or they're trying to buy Sheba enu with rra Bitcoin and so you need to support the inverse operation for every single trade so on a token po token basis um you end up with something like two trillion um Sheba eners per one way of wrapped Bitcoin these are enormous numbers right on a token per token basis sorry that's on a token per token basis it's 2.7 billion and on a way per way basis it's 27 quintillion way units of Sheba Uno per wrapped Bitcoin UNO let's put that in perspective these numbers are difficult to Fathom the BGE Khalifa is the tallest tower in the world I think it's still the tallest tower in the world and it stands at about 128 meters tall a carbon atom is one angstrom tall so 10us 10 m and so this means um that we can um if you were to stack carbon atoms on top of each other you would end up with about uh you would end up with a tower of carbon atoms about 8.

2 trillion carbon atoms tall before you reach the top of the Burge Khalifa so let's put that to the side now let's consider the height of Bitcoin in Sheba ener like which Tower is taller and by how much it is roughly 3.3 million times higher meaning the the Sheba enu unit used to measure Bitcoin is 3.3 million times smaller compared to a carbon atom versus the B Khalifa these are ridiculous numbers and we somehow need to process these things on a smart contract using a blockchain that can be roughly approximated to be a fancy like graphing calculator so the question is like what is a reasonable range to support it's like choose a number like there there are instances like this one where we already have extremely large and extremely small numbers to support So how do you create a protocol that can allow users that level of agency that we don't put limitations on the tokens that they're trying to trade with and the way to do it is to use a scaling Factor I'm going to try and skip over this because I've only got two minutes left in the present presentation but essentially um we use price parameters that are scaled up by a factor of 2 to 48 um and this means that we end up with a slightly different invariant function and if we were to take some of the price data that we've just seen on the last two slides these are the kind of numbers that we would end up with now the numbers that we actually store in the smart contract are the square roots of those numbers so there's already a certain level of compression there but after we've compressed it via the square root which is fine because that's the way that the um the swap equations expect the the price to be uh quoted anyway we undergo a second level of compression where basically we only select the first 48 significant bits and then anything after that just becomes an exponent value and so by compressing it this way into a mantisa exponent um pair we can actually support an extremely wide range of uh of different price values albeit meaning that the um the difference between prices might follow something like a step function which is okay okay um so this on this slide all I'm doing is showing how this compression process works comparing it to let's say the the Maker's imagined infinite Precision um you know value compared to what we would actually end up with um on the blockchain what this means is that we can actually fit all of this data into only three slots which is why carbon defi is now the most gas efficient dexs anywhere right it it it has very very few things that it needs to read and write from and so all of this complication of where the bidding prices and where are the asking prices is actually represented in an extremely concise manner there are parts of this that do introduce error and so it's really important that we very closely analyze how the makers or the the users uh intentions are eroded um when it gets transformed to the to the blockchain and then how that error is compounded by someone trading against it but I'm happy to report even in these cases of extreme stress right when we're trading things like rap Bitcoin versus shba Eno right remember 19 leading zeros this is more accuracy than your iPhone can handle we're still getting about 60 parts per million um relative error um in One Direction and in the other direction we're getting something like 2.48 parts per quadrillion um relative to the the Maker's imagined um infinite Precision situation um and if we compare it to what the contract actually has it's about 26 parts per octillion if you'd like to see all of these proofs I have written about it at length and you can find it on the um on the website blog and this uh QR code will take you there um but that's our that's our product and we we've worked really hard to make sure that it's both secure and represents the user's intentions really well if you would like to reach me you can do so at any of these sources um and I am very grateful to have had your your attention and I'm happy to accept maybe one or two questions I apologize for going over time we were very lucky to get this presentation thank you unfortunately we do not have time for questions but we can meet

Automatic transcript — names and jargon may be misspelled.