# Fixed-Point Approximations of Financial Models | Mark Richardson | ETHWarsaw [4] - Speakers: Mark Richardson - Channel: [ETH Warsaw](https://streameth.org/eth-warsaw) - Date: 2025-11-09 - Duration: 37:18 - Watch: https://streameth.org/watch/yt-EAqJasNTjyA - YouTube: https://www.youtube.com/watch?v=EAqJasNTjyA ## Description Mark Richardson from Bancor walked through how fixed-point arithmetic can break DeFi assumptions, and how to structure calculations to keep them sound, even under rounding constraints. 🎥 Recorded at ETHWarsaw 2025 Follow ETHWarsaw on social media for the latest updates! X (Twitter): https://x.com/ETHWarsaw LinkedIn: https://www.linkedin.com/company/ethwarsaw Telegram chat: https://t.me/joinethwarsaw ## Transcript Hello. Uh my name is Mark Richardson. I'm the uh project leader uh at Bangor since October of uh 2022. Obviously the project is much older than that. Goes back to like 2016 sort of 2017 era. I think was the second application on Ethereum after Nosis. So like really really old project at this stage. Um, one of the things that I did when um, I took over leadership of the project was I wanted to sort of move away from the AMM model a little bit and into something a little bit more uh, expressive. And I've been discussing these models um, for exchange primitives for the last few years, but rarely have I had an opportunity to talk about actual implementation challenges. And that's really what I wanted to discuss uh, today. Um, and I think that this probably goes for a lot of projects, not just um, not just decentralized exchanges, but I think that there's kind of a sort of four tier process when it comes to developing an app for a blockchain. And the first one is that obviously you want to sort of figure out exactly what your product is going to be. And then you sort of define the model in abstraction. And what I mean by that is by essentially ignoring all of the the constraints that the the blockchain itself might impose on you and instead sort of wonder what it might look like as like a web two application or something like that. And then after that is the really difficult stuff where you need to take that abstract model and then decide how it is actually going to exist on the chain. And I refer to this as an approximation, right? that in a in a sense the the model that you have in abstraction is the real version of what you wanted. Um and then some approximation of it exists on whatever chain you're deploying it on. Um and those you know limitations can be different depending on the environment that you are um that you're going to uh persist the the application on. And I think that for most talks, especially the talks that I give, usually we're hanging around in this part of the process because it's kind of the the easiest I guess and the most exciting. Um, and then like these implementation details are usually the stuff that kind of either get swept under the rug or never talked about at all. Um, and so if these kinds of things bother you, this is what I have designed this presentation for. So before we get there, obviously I need to give you some context. maybe discuss um some of the um you know the the product aspects and what the challenges are in implementing them. Um so this animation is a um AMM style exchange just doing what it does. And so you can see there's a a price curve here and it's swapping the bidding and the asking liquidity as AMMs do. Um and then on the bottom we see the canonical sort of um hyperbolic representation of that bonding curve. And then in the top right, I'm tracking the the performance of this thing, right? The actual returns on this position versus just holding the assets outside of an AMM. And if you've been around uh Ethereum for the last few years, um especially back in sort of 2020, 2021, a lot of people were very critical of this specific option value because you have to weather like very very large downsides on an AMM. Um and your upside is very very small. um which means um you know the analogy to uh picking up pennies in front of a steamroller, right? Is usually the the the idiom that had been applied to this specific financial product. And uh concentrated uh AMMs aren't um much better. In fact, they're they can often be a lot worse. Um so here we're seeing that the the draw down is actually um much more exaggerated. And this is because you've already depleted all of your liquidity as it moves outside of the band that you have dedicated it to. Um, and then of course as the price comes back through, we see the normal sort of AMM mechanics start to pick up again. Um, but again your upside is very very small. Right? You can see that this band up here is the the 0% the break even. And when we came back through, we actually did come just briefly into sort of a profitable region, but we have to weather a sort of 25% draw down um in order to get something like a 0.1% profit. So it's it's not really a very attractive um financial vehicle. And maybe that's not surprising because AMMs were never really designed to be sort of investable things um financial instruments that normal users buy. They were designed as a way to keep uh community currencies liquid. And so the idea that I had was to make these kinds of systems um more aligned with user intentions or user expectations that you can separate the bidding and asking sides of the AMM into their own discrete bonding curves and then basically allow people to um to nominate the band that they want to buy an asset at but then simultaneously the band that they wish to sell it at. And this is very very common you see in day trading activities that they will draw sort of the the buy levels and sell and sell levels. And so this basically automates that um and also uses the same kind of AMM mechanic to distribute liquidity across a range. So rather than having to place many uh discrete limit orders, you can instead create uh a continuity of limit orders. Um you can see the um the financial profile is a lot more attractive if you're using this kind of mechanic. So this is the product side, right? This is the the what it is we want to do in terms of um defining the the precise abstract model that defines it. This is the the very familiar um you know concentrated liquidity bonding curve that I'm I'm sure you've seen um all over the place and you need the you know ability to uh to change its shape uh change its size and that sort of thing. And I have dedicated an enormous amount of time to um explaining exactly how to describe these things. And this is really the the talks that I've given sort of in in previous lectures. Um there are a huge number of ways that you can uh parameterize these models, but these models are all effectively the same thing. Um so this is the one from uh 2020 with bankor v2. Um these are the parameters for unis swap v3 and then these are the parameter choices that we have for for carbon d5 for the um the product I was demonstrating in the in the first slides. So I'm just going to refer you to you know this archive paper if you want to understand um how those models are parameterized and in fact there's an infinite parameter space there that you can choose from. Um, and I've previously discussed um, how to choose a specific parameterization based on the product that you actually want to build rather than just sort of forking someone else's product and assuming that you can shoehorn um, new functionality into it. Um, I also discussed um, that at ETH Warsaw last year and my presentation still up there on YouTube if you would like to explore that. But I'm basically just going to, you know, ignore all of that component and just say that, okay, we have a specific model in mind. I've previously justified why that model is chosen. Um, and now we're going to talk about the actual fixed point approximations of that model. And there are four things that I think uh every developer in Ethereum needs to be cognizant of permanently. and that's that everything is always an integer which is really problematic if you come from you know pure applied mathematics where you always have access to like the real numbers and then on Ethereum not only can things not really be rational numbers but they everything has to be an integer um which is a really uh you know dramatic uh hurdle to overcome when you've got a very precise model in mind that you're trying to implement after that memory is expensive um probably uh of no surprise to anyone especially people who were paying gas fees back in 2019. Um routing is rounding is unavoidable. So no matter how good you are at you know uh defining your model eventually whatever is going to be implemented is going to be imprecise or inaccurate compared to that sort of gold standard. And the challenge is how to get it as precise or as accurate as possible. And because of the decisions that you're making in order to address these things, the scope is going to be limited as well. So with respect to the uh how your decision-m with respect to fixed point implementations are going to affect the product, there's really at least in our system um two key areas that you need to be paying attention to. One is that the person who's coming in to create a liquidity position has got you know some uh some strategy in mind, right? they they want to achieve a certain goal and they're going to be providing um the parameters that describe their intention, but then you still need to process it into um the form that's going to be accepted by the smart contract. And so this is really the the first point um to pay attention to where there might be uh a loss of integrity of that information, right? This is where the the first set of rounding errors and so on start to pick up. And then after that is done when someone is going to be interacting with the um the smart contract representation of their whatever it is that they communicated that's also going to be subject to rounding error. So errors will compound over time and so you need to be um very very uh mindful of how these things propagate. Okay. So let's have a look at an example. This is just a screenshot from the app. So this is the ETHUSDC chart. Um you can see that we have these bands and people can interact with these and this changes the the inputs. So um from this screenshot I've created sort of a mockup of um what the the JSON file or dictionary in this case might look like that's being pulled from the the front end. And then um you know what I'm trying to to show here is that the information at least from um the way I've presented the product up till this point kind of makes sense, right? We've got uh some price data here that um expresses the users's intention with respect to the band that they're hoping to contribute liquidity to. And note that I've included units with these prices, which is USDC per ETH. Um, which again is intuitive, but it doesn't necessarily have to be that way. One of the things that you need to appreciate is that with something like ETHUSDC, um, the exchange numer people usually price ETH in dollars or something like that. Um, but if you speak to someone who is trading ETH versus Bitcoin, they will disagree on which one is the correct numer, right? Either you're valuing Bitcoin in ETH or you're valuing ETH in Bitcoin. And the same is true here, right? It's just I've chosen this pair to make it more pronounced. So, what I'm going to do, and you'll see I've got a little icon up here in the top right. Um, if you flip this chart over, it looks very different. This is in fact exactly the same price chart. And I've modified the user input so that they're actually expressing exactly the same intent. It's just that now they are buying USDC at a low price and selling USDC at a high price compared to Ethereum, which is kind of backwards compared to what we would usually expect. So, I'm going to flip this over a couple more times just so that you can um get an idea for this. you see that the this double peak pattern on the um Ethereum price chart becomes a double trough pattern on the USDC price chart. And so when the user submits inputs in the opposite order, we now see a very low evaluation because the price is effectively the inverse of what we were expecting. Now the important thing here is that we don't want to waste time on semantic descriptions of what is effectively the same programmatic object right a user coming in and choosing ETH to USDC or USDC to ETH if they provide the same parameters then whatever exists on the blockchain should have identical attributes and this is important because you might uh be you know if you were in this situation tempted to say Well, we're going to record the user's bias, right, as a part of the smart contract object that they nominate, for example, the bidding or asking asset and so on. And that's a mistake because not only is your contract going to become now double in size because you need to account for this kind of thing, it also makes integration much worse. And usually integration hell is is already bad enough. you don't want to kind of exacerbate it by having all of these flags and things that that make the um you know that give unnecessary context to your data. So the lesson I have for you here is that conventions are important and whenever you're developing a protocol you should absolutely make one and don't treat your technical docs like a white paper. It should really just describe like very academically um how things should be interpreted and what they do and not necessarily sort of lean into the marketing product aspect of of of why you've made these decisions. So for our example, we state clearly what token 0 and token one are. And these will obviously have addresses with them. I'll give you an example of an encoded order. And then um these indices correspond to the rate information and token balances underneath them. So it's very very quick to look up. Now the convention that we developed is that each one of these orders will always quote the price with its own token balance being the kind of implicit numer. And so that kind of makes sense as to why we chose the variable name y instead of x or anything else because it means that the rate information is implicitly sort of in the dydx formulation which makes these things kinds of uh I think more intuitive more intuitive to read. And so when we are encoding this this is actually what it looks like. I just took this um from uh from an event and kind of spanned my own information into there. You can see what the organization is like. We have token zero and token one with the addresses and then these um these blocks of of information to um to give context um to what this position is actually doing. Now importantly um because order zero is associated with token zero and this is obviously the Ethereum token it means that the price data here will be interpreted as ETH per USDC which is usually the opposite of what you're expecting. um whereas the USDC token um which you can read off from um from line three is going to be expressed in USDC Pere. So the contracts in a way take both perspectives. They allow both orders to quote the numer that they have. And so it means that when people are um coming into the front end with different biases, they can produce exactly the same information and it's unambiguous to someone reading the contracts what that information means. Um, memory is finite, right? Really important lesson. Um, and when you're developing a system like this one, it can be very easy to just say we'll just keep adding memory slots to, um, to overcome some of the engineering challenges that we want. But, um, we had a mandate from the beginning that no, we're going to limit the entire system to exactly three slots in memory. Um, and that can mean that, you know, if you're not working with very um talented developers that this can be completely um insurmountable, but luckily the my colleagues are are very talented and we managed to overcome it and I'm going to show you how it was overcome. Okay. So, um we're going to take that same example input now and I'm just going to zoom up on the the far right so you can see these numbers. Um, and I'm going to show you how to um how to process this information from the front end and take it all the way to a smart contract variable. So the first thing to note here is that because the U chart that the user is interacting with is using USDC as the numer that's only going to be appropriate for their quoting prices, they're asking prices are going to need to be inverted, which is why I have this, you know, one over. Um so um the other thing to note is that these prices that the user is quoting is almost always um in terms of token per token which of course to a smart contract doesn't mean anything because one Ethereum has 10 to the 18 tokens associated with it and USDC has 10 to the 6 tokens associated with it right per token. So we need to actually get it into way context before we store that data. Um, and so this means that you actually end up with a much much higher number than you might have anticipated. And this is going to um this is going to affect some other decisions that we have to make with respect to the scope, the size of the numbers that we're going to allow the smart contract um to accept. And then on the bottom side, you're going to see for the same reason, but this time in the opposite direction, the um the buying price is much much smaller than you would expect because USDC is only a six decimal token. Um at $4,222 on a per way basis, you're still only exchanging um 4* 109 USDC tokens per ETH token. Um and that's especially problematic because it's not an integer. um and we're going to come back to that in just a second. Not just not an integer, but an integer less than one. Okay. So, in terms of um organizing the information, we always have uh p high and p low corresponding to the actual magnitudes of the the data that we're storing, which I think is pretty self-explanatory. And then just a quick reminder, if you haven't seen my other lectures, these correspond to the first derivatives at the x and y intercept of their respective curves. Now these A and B terms here are super important and we're going to spend some time discussing it over the next uh dozen or so slides. Um but A and B are naturally expressed using the square roots of those derivative terms. So this isn't something that we kind of shoehorned into the math. It just fell out of the math on its own, which is helpful because when you take the square root of a large number, it becomes much smaller, which is nice because you can fit it into memory more easily. And for very small numbers like less than one when you take the square root they get a lot larger which is also helpful. So by taking this square root um you actually kind of compress all of the parameter space closer around one which is uh which is advantageous. Now don't worry about these other equations just yet. We'll come back to them when they're important. But just note that now that we've got these specific variables we can take their um we can take their square roots. Um, and now we've have units of square root rate, which is a little bit interesting. Um, but it did do exactly what I said. So instead of having to take um and store a number around 216 million, we now only need to store a number that's like 14 a half thousand, something like that. And then similarly, these numbers that were times 109 um collapse right up to around 105. So become a little bit larger again, making them slightly easier to handle. Okay. Um, so, uh, this is kind of where we, um, where we've arrived. And then, you know, subject to my foreshadowing before, um, I've already pointed out that these numbers are less than one. And Ethereum doesn't understand that there's numbers between 0 and one. So, if you try to store this number, right, it's just going to get rounded to zero, right? If you ask Ethereum, what is 1 / 3? It will always tell you the answer is zero. So, we need to deal with that. The problem with small numbers can be overcome by just making them larger. Okay, which I know sounds like obvious, but it has follow on effects that we need to discuss as well. So if we're going to zoom up around a number, we just choose a very large number to multiply everything by. And this means that numbers between 0 and one um will become, you know, scaled up by that amount. So what we do is we um define a new convention here that when we use the capitalized um the capitalized letters that this means that they've been multiplied by 2 to the 48 which is something like 281 trillion. And this means that now a lot of these numbers get a lot larger. Um which now looks like something that we're um going to be much more comfortable storing in memory. But notice that on the other side we now have numbers that are becoming impressively large. And these might be more difficult. Now, just because we've managed to think of a solution for representing small numbers as larger numbers doesn't mean that we can't we can't forego our responsibility to amend the model as well. So this means that all of that beautiful mathematics needs to now be retrofit to account for the fact that we are using a scaling factor implicitly. Um and so here I've already done that work and um so we don't need to go into too many details about that. We will be returning to these equations a couple more times before the end of the talk. So now we have this I've computed this with like a 100 decimal places of precision just for the sake of demonstration. Um and you can see that some of these numbers really are truly anonymous and we need to think about how the smart contract is going to be storing them. So remember I said that you need to respect the um the memory limits of the uh of the EVM. And in this particular case due to the um necessity of um of keeping the um the token amounts uncompressed and um and perfectly um auditable we really only have something like 54 bits per one of these variables. And 54 bits is a stressfully small amount of memory to be storing such large integers. Okay. So, what do we mean by 54 bits? So, these numbers are all in decimal. Um, if we convert them to their binary representations, we're literally just counting the digits that it's going to require to store them. And so, the 54 bits is what this um highlighted section in blue looks like and the red is the part that overflows. And so, you can see that even with something like USDC ETH, which is a very, very common trading pair, you run into issues already because of that decimality difference. And that's not even the worst offender. She enu is one of the most stressful tokens to accommodate in any DEX infrastructure because it's an 18 decimal token and relatively worthless. So you're always operating at the boundary of what you can even calculate. I'm going to show you just how bad it is. So this for example is the WBTC ship chart which is something that again users may reasonably expect to be able to trade. Um, but these prices here are already in the billions of Shebaenu per Bitcoin. But Bitcoin is an eight decimal token and Shibbaino is an 18 decimal token. So actually these prices are 10 orders of magnitude worse than that. And if you do the um the accounting like I showed you in some of these earlier steps to see how enormous some of these numbers are already. So this is a two septillion um sheibba enu per wrap bitcoin on weightaway basis and if we convert that to um the binary representations you can see that um it's it's got no chance of fitting inside that 54-bit limit and it actually exceeds it by 28 bits already. So this brings up um sort of the one of the most important design decisions that we made which is that you need to be able to compress this data even though Ethereum itself doesn't support it e754 floats and this is exactly how we did it. So this is that ShibaInu binary number that I mentioned before. And what we do is we take the first 48 bits of this and then just zero out the rest of um the rest of the digits. And what that allows us to do is to express that number in scientific notation. Um this 10 by the way is actually a two because we're counting in binary. And so if we flip everything back to decimal, you can see that that sheibbaenu rate can now be expressed using this decimal number times 2 34. And this means that we can take that exponent pack it at the front of the mantissa and then store that very cleanly as a 54-bit integer in the smart contracts. Now this is where the scope like the limits of what your smart contract can support are going to be defined. And so this means that we can support prices up to 2 to the 96 and as low as the inverse of 2 to the 96. So if there's ever a token more worthless than Shebaenu, and there are, um, basically we can't trade it here, but that's okay. There's currently no smart contract that can trade some of those. Okay, so um, what we've really been discussing is this part of the process. The user has given us their expectation and now we've basically processed all of their data to represent it on the smart contract in such a way that it can be unambiguously interpreted by anyone who's integrated with it. Let's think about some of those decisions that we made though. So what I've done here is to add a a dotted line that represents effectively the B parameter, right? Or at least after you you know decompress it and square it and so on. What we're going to be looking at is what happens when you round that number down. Okay. So, the user has expressed a very precise uh price that they're looking to to trade at. And what we've done is round their results. So, what does that what does that do? Well, because of the way that we invert things by rounding down, the quote prices will move further down and the bidding prices will move and the asking prices will move further up just a little. Right? I've massively exaggerated it for the sake of of demonstration. It's usually sort of in the parts per million or parts per billion, but the point is is that it's moving in the right direction. And then the A term really measures the width, right, of of these bands. And so what happens when we round A down? Well, it all moves in the the same direction as well. So by rounding B and rounding A, what we do is basically uh collapse the the ribbon just a little bit and move it a little bit farther away from the the market price, which means that the user who is setting it up is actually going to get a better exchange rate, right? We're giving them a um a more um a greedier uh strategy than the one that they were prescribing. And so in this case when I actually left the decimal place in with all of these digits as we uh ignore those digits we are already rounding down. And so this is already a very good defensive programming strategy to adopt and the same is true when we do our compression algorithm. So when we uh took those first 48 bits and then zeroed out everything else because there is some information out of like up here that is getting left out down here then this result will always be a smaller number than what it originally was which means that we're always rounding in the direction that the person using the protocol would want us to be um to be rounding in. So one of the sort of takeaways I have from this part is that you have an unlimited amount of computer power when you're offchain. And so that's where you want to be putting all of the complexity. Um it also means that uh if you do this part well then everything that happens once the contract is you know fed with data is going to be uh perfectly anticipatable overflow because we no longer have to square this thing in the numerator. Um and so having two different forms of an equation where you know one is very precise but if needed you can fall back on a less precise one to avoid overflow is actually a very um a very common and very helpful uh programming strategy especially in Ethereum. So this is how that equation breaks down and you know don't be frightened uh this is really just u sort of you know functional syntax but the the point here is is that each one of these steps is making sure that at no time um will the EVM produce an an overflowing result or that we can at least control where that overflow may occur and revert early. Um, and more importantly, we get to control whether or not we're doing a ceiling or a floor division, which means that for this specific calculation, we can force the case that someone trying to exploit the contracts will only ever get, you know, less tokens back than what the the gold model um would have suggested that they did. And so, if we put all of that together, you eventually get to this. And you can see that it does have both of those cases. So if um you know this uh denominator is less than 256 bits then we're happily going to process it that way. Um but if the denominator exceeds 256 bits then we've got another way to calculate it with a slightly poorer precision but that's okay. Um and you know if you don't need to if you don't want to refer back to the previous slide um this is basically um the the full elaboration of that swap equation. Okay, so that's the trade by source, but then we also have trade by target. Um, you can see that you know they exhibit similarities um but they're fundamentally different equations and so we need to implement um that function specifically. Now with trade by target it's slightly different because the user our you know Lazarus group member here he is choosing the amount of tokens that he's taking from the contract and the contract has to calculate how many tokens he needs to send in to achieve that exchange. So this is the opposite case. We want to round this value up not down otherwise he's effectively going to be um being given a a discount. Now, same thing. Um, there is a formalism for decomposing these kinds of things like this. And you see that, you know, I've put the notes up here on whether or not something can be uh 256 bits or not. Um, in particular, you'll notice every time we do one of these ceiling divisions, I've actually said that the intermediate multiplication may exceed 256 bits. So that means that this numerator part is allowed to be bigger than 256 because the way that we handle it at runtime um is that it's going to be divided by this amount first. So as long as the whole thing uh comes to less than 256 bits, we're actually okay. We're not going to get an overflow and the transaction isn't going to revert. But in other these other cases, we actually need to constrain the result to 256 bits or the transaction will revert. Um, and so again, after we've composed everything down, it's nice to get such a nice neat little summary of, you know, what was a page of equations. Um, and you know, if you don't want to refer to that functional language, that's fine. Um, this is exactly the same formula here. And you can see that it actually is rounding up the entire division. That's what this ceiling division symbol means. We round up the numerator, we round down the the denominator in order to achieve uh the rounding in the direction that we want. if and you know I I apologize. I know that this is a a very fast talk for a huge amount of of detail. Um, but I have written all of this down and a lot of the um, a lot of the material uh, that I presented to you today um, is actually from this blog article. And so if you would like to, you know, uh, comb over this at your own pace, I I think that this is a really great place to start and be reminded that, you know, the theory that it is describing, I've also presented last year at ETH Warsaw and um, for the token engineering academy as well. Um, if you would like to talk to me about this or about anything else, um, this is my Telegram. That's probably the best way to reach me. I don't really use any of the other three, so just reach me on Telegram. Um, thank you so much for your attention. I realize I went a little over time, but if there are any questions, I think we're at the end of the day, right? So, we >> Hackton is opening, but it's entirely up to you guys if you want to take the questions or go to the Hackton opening. The room is yours for the rest of the day. if you want to continue >> and you know how to reach me. Anyway, so >> just I got a question for a nor more of a normie person like me. How does that make my experience better? Like I some of the math went over my head but I understood like the whole >> So yeah, that's a really terrific question. Um I uh okay without naming anything right just in the last couple of days um a very prominent protocol built on unis swap v4 um was exploited for $8 million because of precision problems right it was actually you know because they didn't do the formal verification correctly and you know like they're not they're not dumb um it's a very clever setup that they have um but there were some assumptions there that that weren't checked Um, and that meant that because the, you know, because their their fix point implementation had that rounding error in it and it was in the wrong direction. Um, that basically, you know, even if you only lose a fraction of an ETH on each thing, um, that's fine because I'll just fill up a whole block, right, looping that transaction until I've drained the entire pool. And that's exactly what happened. Um and you know again another protocol two years ago um one of the very first um concentrated liquidity amm um I think because of a precision issue lost $85 million um which was essentially you know the entire protocols worth of funds because that wasn't just a specific you know instance on specific pairs but actually the the flaw was at the protocol level and so every token was susceptible to loss. So from the users perspective, you know, and this is one of the things I said last year is that you even if you feel like you're incapable of understanding this, I promise you it's not like it's frightening. Sure, but with a little bit of work, maybe chat GPT or YouTube helping you, these are very digestible ideas. And when we say trust, you know, when we say verify, don't trust. This is what I'm talking about. You should be able to actually look at the smart contract and confirm for yourself that these things have been handled correctly. Um I think I I don't know if you find that a satisfactory answer. >> Yes, please. >> Yeah. >> Wait. Uh I guess my question was were you saying that like you do some of these like approximations on the front end or somewhere before you send to the for a contract? >> Yeah. So for things like calculating a square root, right? It makes no sense to take the user's inputs um as they describe them and then submit it to a smart contract for packing down. Instead, what you want is like an SDK um some sort of, you know, app at the front end that does the the processing of the user's transaction before it ends up on the blockchain. Um so, for example, we could have potentially um a smart contract that does this kind of stuff so that we don't have to do it, you know, at the front end. The problem with that is that you know if you're scaling up one of these numbers by 2 to the 48 and then need to truncate bits that transaction will just revert right you need to sort of sanitize the data before it ends up on the smart contract then the question arises there is like well doesn't that fly in the face of you know decentralization and so on like what if the front end gets poison and so on that's all true um and so I think the the best approach here is to have the the SDK publicly available and in as many programming languages as possible. So I think we do okay on that front. We have um the the the SDK both in Typescript and in Python. And Python's like, you know, super saturating programming language. Even people that hate it at least know how to speak it. Um so there's really no excuse to not understand how this stuff is done. Um and then using just that SDK, um it's very very convenient. Um, and I've tried this myself. Um, to actually just not use the web app at all and submit transactions directly to the chain. Um, and so I I think that that's kind of the, you know, we offer the the front end as a convenience because a lot of users expect that kind of thing. But in an ideal world, you would just write how to interact with the contract and then make the user responsible for sanitizing their own data right before it ends up on the smart contract. Obviously, we're not quite there yet. Um but you know maybe one day 50 years from now everyone is you know avoiding using browsers altogether and interacting directly with the the chain without the need for a front end. Bam. Anyone have any other more questions? Nope. Well, thank you very much. It's always a pleasure listening to you, Mark. And let's have one more round of applause. Thank you.