Unlocking AMM Powers With Balancer V3 Hooks - Fabio Mendes, John Grant

Transcript

Okay, thank you everyone for joining us. Uh, today we're going to talk about Balancer V3 hooks and how you can build on them and why you should build on them. Um, just a quick intro to the agenda. We'll do a very quick V3 introduction, talk about why it's good for you guys to build on Balancer and some of the benefits that you maybe don't know about. uh a quick overview of the V3 architecture and how that relates to hooks. Uh we'll go through the staple search hook which is a hook that is deployed live at the moment that I'll showcase some of the hook um code and then I'll switch to Fabio who will walk through another one of our hooks which

is the ME capture walkthrough and then we'll close out and you can ask any questions. So, Balancer V3 is a platform for AMMs. Uh, using our past experience from V1 and V2, it was really focused on making it easy to build and customize AMMs. Uh, it's been fully and very deeply audited, been audited by three of the best firms, which should give you confidence that you can use it as a Lego block to build on top of. Um some of the other interesting innovations that we added is support for 100% boosted pools which basically makes the pools super capital efficient by depositing idle liquidity

into any of the lending protocols such as a for especially we introduced support for hooks at various life cycle points and these are basically modular plugins that allow you to extend any existing pool behavior. Uh since launch at the end of last year, both partners and ourselves have been busy building things on Balancer V3. Uh we've got a range of pools that have been built on top of it, such as Wade pools, stable pools, gyroscope pools, which were built by the gyroscope team, quantm pools, um reclam pools, which is our latest pool that Fabu introduced yesterday, and LBPs.

We also have three hooks in the wild as well. the stable search hook and the me capture hook which we'll go over today and an acron hook which was built by a separate team without even really getting in touch with us which kind of showcases how easy it is to do also uh so the question was did cow amms also build on top so they're actually built on v1 because they were developed while we were still developing v3 and they will be report it to V3 at some point soon.

They're doing that as we speak. V3 that's possibly part of the development that we're like migrating over now, but yeah, it should be coming soon on V3 as well. Uh yeah, so why should you guys build on Balancer V3? The main idea, the main reason is actually because you can take your idea to a product super fast. Uh, and a shorter development cycle means faster time to market for you and you can just focus on implementing your actual idea.

You can build on top of all the balancer audited code relating to like token balances, accounting and you can just take care of your own stuff. We also have comprehensive documentation. We have a range of example hooks and reference implementations in the monor repo. Uh we've got a bunch of helpful periphery contracts that you can leverage for testing and development. Uh we have very active dev support in discord and telegram and we also have grants available if you have new ideas. So basically if you have anything or if you need help you can reach out to us at any point and we'll be there to help.

And it's not just the development part. We also have a lot of support after launch or before the launch through our ecosystem. We have the balancer front end which is modular and easy to update to include customer branding. Um we can also implement like extra features. So both gyroscope and quantm are separate products but we've managed to like add them to our balancer UI which allows them to launch straight away with an interface that LPS can come and add and remove liquidity and it also showcases like their own kind of design their own kind of like graphs and things. Uh aggregators is super important. You can't just launch a pool and expect the

aggregators to pick it up. We have like good relationships with like all the core aggregators and solvers and we also make contributions directly to their code base. So that's something that we can do so that you can launch and soon after be picked up which drives volume to your pool which gives your LPS more swap fees. Um balancer also has the incentive flywheel and we have a very capable and like supportive operations and marketing teams. uh they can help you from things like governance proposals, launching your first pools, anything like that, there's somebody there to kind of help you.

So just to cover the architecture before we get into the code. It's a very high level view, but there's like four main components to look at. The router, the vault, the pools, and the hooks. The router is the user's entry point to balancer. Uh this is where like somebody would go if they want to register a pool, add liquidity, remove liquidity or swap. The vault is a singleton contract that handles all the token scaling fee accounting limits things like that and it's been optimized for gas. Um both these contracts or range of contracts are fully audited deployed and it's not something you really need to worry about. you just need to focus on the

right hand side which is your custom pools or your custom hook logic and it's probably worth explaining at this point the difference between the pools and the hooks. So pools are where you can define your core maths. It's where you can build different math based liquidity curves. So you can think of your weighted pools, your stable pools, gyro pools, things like that. Basically giving you custom pricing model. So it's like a new AMM Whereas hooks extend these pools. So a hook can be used with any pool type. It can be used with multiple pools and it basically allows you to build extra behavior on top of that existing pool.

Um and a hook is registered with a pool when the pool is created. And once it's registered, you can't unhook it. Basically, it's immutable. So that's something worth noting. And the hooks themselves can be hooked into like a different range of life cycle points. So we have basically registration, initialization, after and before add liquidity, the same with remove liquidity. And we've also got the dynamic swap fe hooks. Um, and you can use one or more of these within your hook.

So the hook we're going to talk about first is the stable search hook. This was an innovative directional fee mechanism that was actually proposed by one of our maxes. H and it's basically a dynamic swap fee hook that as the pool becomes imbalanced the price of the swap fee goes up which should uh protect stable coin pegs during periods of market volatility. Um and the things that you that we use in the code here is a stable pool and also the custom surge logic which exists in the hook itself.

To start with, we'll talk about two of the periphery contracts that exist in balancer v3 already that you can leverage. Uh so the first one is the vault guard. Uh it's a base contract that your hook can um inherit. It stores a reference to the balancer vault and basically ensures that when you use the only vault modifier, it restricts access to only the vault. And it's important to use that because only the vault should trigger hook logic. And this prevents external or unauthorized contracts from calling any sensitive logic. I can just flick over quickly.

Just looking at the stable search sheet itself. So you can see that it's added here on register and it's easy to just import this and you just inherit it as a vault guard and these hooks are all available in the monor repo and serve as like super useful references if you're going to start hacking yourself. The next one is the base hook. Uh it's another one it can be inherited and basically implement a minimal default hook that your hook should follow. Um you can basically override any of the

functions that you want to implement and then be sure that anything that you have not implemented will be covered correctly uh by that's basically done by each hook returning false which means that no logic will be applied for that hook. Uh, and you should use that for a number of reasons. It basically saves you time because you only need to override what you want to do. Uh, and it does ensure that your hook is going to be compatible with the interface. Uh, and it basically improves your safety. Just quickly show that one.

So it's a base hooks here and you can see that every hook here is just defined and returns false which basically shows the vault that that hook is not going to be used. And then in stable surge wherever we want to use any logic we've just overwritten it here and implemented our own logic in the contract itself. So the first thing that you have to override if you use the base hooks is the get hook flags function. Uh this is called by the vault whenever a pool is registered and it basically tells the vault what the config of that hook is and what hooks it's going to use. Uh

once the pool's registered with that hook, that config is saved in the vault and the vault will use those configs to make sure that the hooks uh that you've configured are going to be used. Uh and we can see in the stable search hook that we use three separate hooks. We've got the dynamic swap fee, the after add liquidity and the after remove liquidity. Uh every hook must implement this and um if it doesn't, yeah, you your test won't pass. Basically, uh on hook registration, we also have the onregister function and this can be used for a bunch of different things. Um one of the common use cases is

restricting usage. So basically if this function returns false the actional throw and the pool can't be created with that hook. So you can use it for whitelisting. Uh you can restrict it to like certain pool types or certain pool factories. Uh and it can also be used to like initialize with like default configuration. Um for your pool to successfully register with a hook that function must turn true. And we can see in the stable search hook there's no kind of whitelisting going on but it's been used here to set the max surge fee to the default and set of surge threshold to the default. It also emits an event which is super useful for the offchain infrastructure and then it just

returns true which allows the registration to continue. The other hooks that uh this particular stable search hook removes uh uses is the add and remove hooks. So these are the trig uh tri triggered after an LP adds or removes liquidity. And it's important to note that this function gets called with the updated balances from the vault for that pool. So it can be used to validate the pool state. Um you can emit custom logs or analytics. Um it can also be used like at that point in time to interact with external contracts. Um and in this particular case it's used to detect if the pool is

stable is surging at that point after the liquidity has been like added or removed and if it does if it is surging then it'll throw false and the action will be blocked and this ensures that the liquidity isn't added during unstable conditions. It's pretty hard one to see. If we just look at a bit of the code here, we can see the first thing it does is it's checking what kind of ad action it is. Any proportional ad is fine because it's always going to be adding it proportionally which won't unbalance the pool. So, it immediately returns true which allows the vault just to

continue with the action. If it's not a proportional ad, then we're doing some maths to basically detect if the pool's going to surge after the action. And if it is surging, then it returns false, which will block the action. And if it's not, it'll just return true. So, it's a nice way to make sure that your LPS aren't going to get like shafted basically. Um and then the last one which is where the meat of this like innovation is happening is the dynamic swap fee which is the onmp compute dynamic swap fee percentage hook. Um this is called every time that a swap is happening and the hook responds to the vault with the current swap fee which is then used in

this the swap calculations. And this allows your hook to dynamically change the swap fee based on the pool state. the direction or like external data. So there's a lot of room for innovation within this. Um the dynamic swap fee itself, the maths is here. It's pretty detailed. Um if you do want to look at, you can check out the whole like monor repo implementation. But the basic kind of principle is if the pool drifts from the balance, the fee starts surging.

um it increases the fee as the imbalance becomes further and if it's not surging at all it'll just return the default swap fee. So you can see this. So here's the one compute dynamic swap V. It has to return true again. If it turns false at any point then the action will be blocked. And then it's getting the get search fee percentage. So the first thing it's doing is updating the balances with the amounts and then it goes into the get search fee percentage.

Um this is where the maths is happening and then it's basically checking if it is surging. It returns this calculated swap fee which is based on the maths and if it's not it just uses the static swap fee that was um the pool was configured with at the time. And the reason we wanted to kind of highlight stable surge is like this is a hook that was implemented in probably about a month including audit time and it's a hook that's in the wild already.

Um it's deployed in mainet and L2s and it's powering a lot of our like partners stable pools. It's already got over 30 million TVL and 100 million swap volume. Um, there's also like a couple of links to the full contract code and also a blog post that kind of shows the whole deep dive into the concept and how we went from like design to the full product. Um, yeah, and that's us. Pass you over to Fabio. Any questions so far? We have the microphone there. Uh, yeah. A question one. One. Okay. Uh yeah. Uh so thank you

for the explanations. The question is um the hooks are there uh just smart contract functions so to say or is there anything uh any tech stack on top of that such as I don't know oracles maybe some crosschain stuff or maybe some monitoring uh nodes monitoring something that trigger some of the hooks. No, they are just standalone smart contracts that the vault is aware of. So the vault calls those smart contracts at those specific points of time in the pool life cycle. So like if you think like the LP is going to add liquidity when that action is triggered in the vault. The vault knows that that pool

has an associated hook and calls out to that contract, does the logic and then returns back into the vault which will then continue. But you could like from your hook you could reach out to like other contracts as well. So it's like an opportunity for you to do that. And when you say uh the vault triggers the action uh does it happen when a user does something or does it happen at some time intervals or or or maybe uh uh the the protocol itself triggers the vault? Uh probably best to show you. So it's these specific points here which are all related to like a pool life cycle point. So we have like the registration point. So when a

pool is first registered with the vault, you can do like an action before and after that. H when a pool's first initialized, which is like when somebody first adds liquidity to it. The same again you can do before and after. And then also before and after add liquidity. And then the dynamic swap fee percentage is whenever there's a swap. So it's those kind of core actions that you can like inject your logic into I guess. Understood. Thank you. Cool. Cool. Okay. I will continue.

We have a second hook to present today which is the MV capture hook. Uh this one is a quite simple one but powerful at the same time. So the objective of this one is to internalize the value liquid uh from the pool to the liquidity providers and then redistribute that uh value loss uh in between the the liquidity providers who have been providing liquidity uh for a long time. in the pool methodology is actually based on a paper from paradigm called priority is all you need if you have read it and we use priority fees to identify which uh transactions are from

me bots. So with that information that's the that's the signal we use we apply a dynamic fee mechanism which aims to internalize the most value possible from the arasure. So this is more or less how it works. So here on the mys left side uh we have how it works today. uh and I did not mention actually but this only works on optack chains where you have priority fee a centralized sequencer uh which source the transactions by by this priority fee. Um and in the first image you have the arbitrurer and and on the on the right side you have the validator. How it

works today is the validator receives this fee and sorts the the transactions by the by the priority uh and if the arbitrageers manages to perform this this arbitrage it receives the the profits from the from the liquid providers from the validator. Uh on the other hand what we are trying to do is adjust the subview of the pool based on this signal based on the priority fee. So you can try to keep the most value possible within the pool and not send that over to the to the validator to the base sequencer for instance or on any OP OP stack chain uh sequencer and that value will be redistributed

automatically uh for the liquidity providers because this can be applied to any any funible position or any balancer pool actually. So you might be wondering how you get the priority fee um from the block or for the transaction metadata. That's actually not directly available but you can calculate it. Uh so we have this objective object uh transaction and this other object block and in each one of those and the transaction you have the gas fee in the block you have the base fee and actually that's combined that that's the fee that's been paid by the user. But if if you subtract one from the other then you

have only the priority fee price paid by the user and that's what we are going to use as a signal uh for the dynamic fee calculation. We have a few hook pars uh that's how we're modeling the problem and that's how we we're going to apply the dynamic fee. So first of all, you have a threshold or we decided to have a threshold. Uh and that's the the threshold that determines when you start triging when you start charging priority fees. We don't want to charge priority fees from solvers, aggregators and retail users. So we have this threshold in order to distinguish between retail flow and arbitrage flow. Um we have the

multiplier which means uh how aggressively we're increasing uh the fee um based on the priority gas. We have a max sub fee percentage that's a global maximum dynamic sub fee. Uh that's mostly for for safety reasons. I guess you can just go go over and over. Um and then you have the exempted senders. Again, speaking of the the same idea as for the for the threshold, you we have contracts that we trust that the only flow that's coming from from there is retail flow. So we could for instance trust the cow swap settlement contract uh and just apply the static fee for them because we acknowledge that the

flow coming from the order flow coming from their contracts it's just retail flow. It's good flow for the pool actually and it's what makes the the LP providers making money. This is what the hook setup looks like. So we have uh on register uh on before add and remove liquidity and you have uncomputee uh dynamic sub fee as John showed us. We have the get hook flags which defines exactly what is said. So saying true for this three for for these three uh for the three hooks default should call and then upon registration this is the simplest one we just have

this default uh multiplier uh and the default threshold uh for all the pools but that's actually also configurable upon registration the the pool owner the swap fe manager can actually change that you might be wondering why we the before add and remove hook and that's actually needed because that transaction or that operation can behave like a like a swap uh because at balance here at balance v3 you can do unbalanced operation so I can single side join a pool and single side exit that same pool that's pretty much a swap and we have to protect uh against

that against that case so that's the reason we we have this before add and remove. If the if the kind of the operation is proportional, that's completely fine. That's just someone joining the pool. But otherwise, we'll check if the priority gas price is below the threshold. If it's above the threshold, that transaction will just revert. will not allow the the the liquidity provider likely being in this case an MV bot trying to to arbitrage that PL that that pool will not allow that and then the most interesting logic is really the the dynamic fee. Um, one thing that I already mentioned and the

first thing that happens on on this transaction on on this function is we check the sender uh to see if it's exempt of the of the me tax uh or not. And in order to do that, we have to use this uh trusted router uh function because anyone can can call the vault and anyone can tell the vault uh or can can tell the vault that someone is is is performing the swap even though it might not be that that person. So we need that sort of uh routers that we trust that are going to pass us the the original

sender the really the the user the retailer user behind that transaction. So that's why we use this concept of of trusted router. That's the second thing we we check on this function. If it's a trusted router, we get the sender and then we check if the sender is one of the exempted um ME tax addresses. If that's the case, we just apply the Go ahead. Can you pick up the microphone? So I understood that maybe something like these aggregators would be exempt.

you're using the white list to for that. Do you set this at the pool creation or like do you how do you leave it open enough to adapt or I don't know. Yeah, that's that's controlled by the by the DAO. So we have this contract called balancer registry and then we can whitelist addresses there. Uh so far we have only whitelisted the cow settlement contract because that's the one that is for sure retail flow. There are some aggregators that anyone can call uh you don't have this enforcement the the batch batch auction that happens at cow

swap. So we did not allow listed uh any other any other aggregators but we did it for for cow and that's on on the dow's uh permissions. balancer the balancer dow did it yeah but actually the max is on behalf of the dowo which is a service provider can the pool deployer like configure their pool in a way to be the controller of this allow list or is this I don't think so the way it is set up right now I don't think so that's that's for d so how much freedom do the pool deployers have to govern in the like the mutability of their pool after the fact

and how much of it is on balancer side. It really depends. It's it's case by case. Uh I would say the pool owner here do have the ability to set multiplier, set threshold and then some of the params but they do not have ability to to set it all. That's the pool type developed by balancer. That's what we thought was the best when we were designing. Uh, but it it could be even changed. Sounds good. I'm not complaining. No, no, no, no worries.

Cool. Yeah, that's it. That's the the beginning of the dynamic fee calculation. Uh, and then we go to the function itself. Uh, the function that's called by by the hook. That's the calculate fee percentage function. The first thing it does is get the priority fee. gas price as I showed you guys. Uh if it's below the threshold, we just return the static swap fee. There's nothing to be done. But if it's above the threshold, then we take the the difference from the priority fee guest price paid by the user minus the threshold and we multiply that by the

multiplier. So that's that's how how we do and that's how we get the fee increment. So this multiplication will give us the fee increment that we have to sum with the static fee and that's the fee that will be ultimately charged um by the by the pool for the arbitrerure. Uh we do have a have a cap as I mentioned before. So we have this max uh swap few percentage that's why the return of this function it's actually the minimum either the max or the new soft fee percentage calculated by summing the static soft fee and this fing

just wrapping up uh we have deployed this pool I guess one or two months ago uh it was the the first of its kind m internization uh product uh on base uh and it also expands balancer MV protection to kit uh we had cowm's build and balancer v1 and live on mainet and noses but now we also have this other product uh live on base and could be live on other opt chains as I said but we're focusing on bass right now um so pools available on balance tree you can find them on the UI there's a future there you can find them with

capture and you have the contract code. The solidity implementation is on GitHub under the balancer v3 monor repo. That's it. Speaking of the of the mv capture hook, you got a question for the Yeah, if it's question time, I can wait. Nope, no, no, go ahead. Okay. So, uh maybe this is a long-winded question, but we're seeing a lot of uh like launchpads, I don't know, pumpf fun and all this stuff. out there now and a lot of them tend to use uni v2 pools because it's super easy and we see people maybe launching I don't know uh uni v3 pools and it's obvious at least to me that

balancer would be the way to go when deploying liquidity because you have some additional configurability or something but I guess my question was is what what configurability does balancer v3 offer like I mean we see the hooks Um, on top of like all of these alternatives that that like give incentive to say the the pool deployer to to use it instead of something super trivial like unif.

But you you mean the pool deployer as a developer, a builder or someone who wants to launch a token? Yeah, somebody's like got a launchpad to launch a token and like at some point once this ICO phase is over, the liquidity that's been added to to the launchpad gets added, it gets deployed to a pool that's like say technically owned by the the launching whatever address is associated with the ownership of this company, this entity and it's maybe say locked for years, but like maybe the DAO wants to have uh additional like the the actual token holders of the like the like

pool that's been created maybe want to have uh some control over like changing these parameters over time. Okay. Yeah. I guess um we are right now working on LBPs. So I guess I'll start from from that. So we are taking LBP is the liquidity bootstrapping pool from V2 and porting to V3. That's a pool designed for launchpads actually launching tokens. Uh and what we're trying to do better this time I would say is um having post hooks uh for LBPs such that you have some guarantees that after the

LBP runs and the the sale of the token happens. Uh migration can easily happen for a new balancer pool. uh you have some insurance that maybe liquidity will be deposit locket tokens burn like you have on on pumpf fun uh for instance so we are really really into this uh post hook lbps uh research uh balancer retreat does offer a lot of flexibility for for projects to do whatever they want uh I would say uh we we do have our own pool types which like you have defined pairs like you have a weighted

pool which has weights and a swap fee. You have a stable swap pool which has tokens and factor. Um that can be configured by the pool owner by the way if he chooses to do but he can al afterwards after deployment the the pool owner can do that uh for sure if he's if he chooses to be the pool owner kind of because that's that's one of the the parms of the construction of the pool. You can delegate that uh that power to the balance dow for instance or even to any contract uh really uh or you can keep it for yourself or you can even burn it maybe like set to a random address like the that address uh and that's it. Nobody will be able to to

change it anymore. It will be immutable. um balancer. It's probably worth saying as well that we also have like quite a comprehensive like operations site as well that makes it easy for people to manage the pools, create like payloads and things like that and the maxi is always like support people through that as well. Yeah, just a quick one on on your question. Uh, one other thing that happens is balancers has always been, I want to say shy on shutting out like our benefits comparing to other competitors.

Um, and that we can see every time that we talk to a partner and then we show them how good our pools work and how easy it is to create a new pool. Um, and how they can tweak uh the parameters when they starting it and how different pools we have for each type of strategy. Uh so one of the things that I would uh mention here is that besides only uh being easier to use uh we're focusing also on on shouting out a little bit more on on theseap capabilities uh and I think when we launch LBPs uh that will be kind of like a no-brainer or easy cell to show how good and how easy you

can just switch to a pool and then even like After that, let's say you go with a reclam that he presented yesterday. Um, if you're not happy with the parameters, you don't need to migrate on your pool. You can just change the parameters. So, those are like few tweaks and and things that we can show that. Yeah. So, I was under the impression that these bootstrapping pools already existed even in V2. Is that not a thing? That that's that's yeah, it's live on V2. We're taking and porting to V3.

Yeah. Okay. And we're launching and bringing to the balance here UI actually because before we had this external UI running LBPs and we were bringing LBPs home. Okay. So I mean people who are doing Launchpads shouldn't be rolling their own contracts anymore like at all. Yep. Yeah. Exactly. They won't even need to do a UI because the UI on balancer will support as well. Yeah. Wow. Balancer is great. Um, it's also a great opportunity for launchpads because we're providing the infrastructure. Uh, you'll have access to what's happening on our UI, but we will not be promoting um the the token launch UI as

pump fund does, pump fund does. So, we're actually just going to promote our infrastructure that you can use. uh people can use the contract and by themselves by their own product but if someone wants to create a UI and create a launchpad and use our protocol that is fine as well and they can use all the structure uh that balancer offers on their own UI they could potentially make money off that as well I think that's something we forgot to to mention maybe but in balance v3 we do have a pool creator fee so upon registration you can set a pool creator and take your cut uh of the swap fees generated by by

that pool. So there's an easy module for builders and developers to yeah just make money building balancer. Thank you for the questions. Uh yeah, moving forward. Um last slide I guess we have a few grants uh up for for grabs. Uh this is our hooks. Yes, this is our hooks. So we have been revamping actually the the grants program. I'm leading uh it right now with Mike B.

He's not here but he's my partner. Um and we had three ideas that we would like to see build and balance tree. First one is size based fees. So charge different fees based on the volume uh that trade is producing. that potentially involves some integration with oracles or something like that because you do have to have a notion of price. Uh in that case um we have permission poll um some kind of projects have already reached out to us asking for a solution to have permission swappers or liquidity providers. Uh there are many ways to to build this

actually. You can use at the stations. You can just hardcode a bunch of addresses on your contract. But yeah, you have to came up with with a good and and scalable solution for this problem. We're just throwing uh a few ideas out. Uh and then the last one is directional fees. So that's the idea of liquidity providers being able to adjust their spread uh based on the price of the token and the volatility of the market. Uh so that's the the third venue for for exploration. This all can be done uh via hooks specifically uh dynamic fees two of them. The permission pool would be on

before uh swap on before uh add remove liquidity as you have to check the sender. You probably have to use the trusted router as I was showing you guys. Um and yeah, those are our two ideas. That's my telegram. Feel free to to reach out to to us. Uh it's the first time I guess we we're talking about these ideas, but we'll probably do a push on on Twitter. You might see see that there as well. But yeah, feel free to get the alpha and reach out to me if you're a builder and want to do that.

So, what's the process to participate in these grants? Do we put up proposals in a forum first or do we just start forking V3 contracts? No, talk talk to me first. Uh reach out to me. Uh we we need a proposal uh for sure. That proposal does not have to go to the forum. We have a grants committee uh and you can submit a uh uh a proposal to us. uh we don't have a clear format. Uh I would say it's more about like getting to know your background, what your proposal in terms of deadlines and ask uh in terms of budget uh looks like and then we'll set up a group and and chat

and figure out. Let's do it. Uh yes. So in in terms of uh this grant program, are we supposed to build uh purely on your stack? Cuz uh the ideas I'm getting is applying our info tech stack to your hooks to possibly uh enhance the functionality. I did not get it. Yeah. So the question is are we supposed to build purely on your text stack or can we add something else on top of that? You can for sure.

Uh like like as I said the size based fees can be probably built on top of chain link oracles. Uh for the directional fees you you might need some sort of pricing data as well. Uh for the permission pool it could be be on top of uh the stations. You might have heard of it but yeah it's it's built by the AIS uh team. But for sure if your tech contributes to any of those uh those problems right like those are problems we have we want to find solutions uh to them. If you can help us figure out, I guess that's great. Uh, is it the full list of the problems? Uh, are there some open? We these are the three we're putting out there. Uh, I actually managed to just have this short list of

six yesterday, but I prioritized those three. It's just a smaller one, easier to scope. We don't want to create like huge projects at the same time. Uh, so we are starting slowly and then potentially potentially growing. and yeah getting the community to get these ideas done and and do some outsourcing. Yeah, thank you. Is that the last one? Yep. Any other questions?