A new generation of Tokenized DeFi Strategies on Makina

EthCC[8] · 3 Jul 2025 · 38:51

Alessandro Buser demonstrates deploying on-chain strategies with Makina. The presentation discusses the execution engine’s risk-management design, composability and cross-chain execution.

Speakers

Topics

From EthCC[8], hosted by Ethereum France.

Transcript

So I'll introduce a new protocol that we partnered with uh that will allow us to take our strategies on chain. Um and I'll do a little deep dive into the mechanisms around that. Um whoops. So first of all about dialectic uh we are um a defi native asset manager. Um we run three different funds. So these funds uh produce yield on stable coins ETH and bitcoin. Um, importantly, these are fully onchain strategies. So, the subscriptions into the funds, the redemptions from the funds and all the positions in the fund are fully on chain in DeFi. Um, you can think about this as like sophisticated yield farming. And um, we've been doing this since Defi

summer. Uh, so we've been around for close to 5 years now. Uh, we deployed in curve before there was a token and have been around um, ever since. So the way that the strategies operate um is really like broad exposure defy yield. Um how do we find yield? Well, it's really much about um getting all the data, understanding where the opportunities are. Uh so we developed an in-house tool called codeex and what we can do with this is to keep track of everything that's happening on chain. Um so we scout across all the different EVM chains. We keep track of different positions the different wallet has and we can independently measure the returns. uh we can also independently measure the risk and thereby we have

like a full overview of all the set of investable opportunities in DeFi and from there we can really like narrow it down to the opportunities that fit our risk profile um and then from there we can optimize for best risk adjusted return. Um at any point in time our portfolio has around 50 to 70 positions um in each of the fund. This year alone we deployed over 300 positions um in D5. So as you can see these are quite like fast turnaround strategies. Um the way that we um optimize for risk adjusted return um on the one side you have the return side. I just talked about that just like keeping track of everything that's going on all the fees all the incentives everything like that. Um on the other side it's really about

minimizing the risk. Um so there's different layers to um risk management. We have this multi- um layered approach where at the first step it's really about due diligence. Um so that means really deeply understanding the protocols that we interact with, understanding all the security assumptions, the trust assumptions. So this goes from like the smart contract risk to the governance risk to the economic mechanism risk. So for example, lending markets have different risk profiles than the centralized exchanges and like lending markets you have liquidation risk, you have bet debt risk. Um so we spend a lot of time just doing due diligence on everything that happens in in DeFi. Um so once we kind of like understand what the risk profile of all the different opportunities is we

can size them according to our diversification policy um which really means that like the high-risisk position have very small allocations the lowrisk positions have much bigger allocations and so we design and we create a portfolio that's optimal um in that sense as well. Um then once the positions are deployed um we have real-time monitoring on everything that we do. Uh so we work with different security partners. Uh Hypernet for example is one of them and we have full realtime monitoring on all of the positions. Um and we developed um some tooling that allow us to do automated uh withdrawals. So if ever there is like some risk event on chain like a token is pegging a like lending market is

starting to acrue that or a smart contract exploit is going on uh we can trigger an automated unwind um and reduce the risk on the position basically in the next block. Um so this allows us to to be very fast and react very quickly to changes in in risk profile of different opportunities. Um on top of that uh we have uh full portfolio coverage uh with Nexus Mutual. So Nexus Mutual many of you may know um they're an insurance provider for DeFi. Um and we are the first uh fund that they felt comfortable with to give a full portfolio uh level cover um with insurance. So this insurance covers uh smart contract exploits, bridge exploits, token DPEGs and things like this. Um so what we're really trying to

do here is to give our investors access to all the high yields that DeFi offers and then at the same time really try to drastically reduce the risk uh through this multi-layered uh risk management approach. So what um is happening in DeFi right now? I think all of you have been at DCC last week. So we've seen a lot of the traditional finance, the fintech starting to come into the space. Our general thesis on DeFi in general is that a lot of the capital will move will move from being privately managed to professionally managed. So this means that we'll have less and less individuals and small prop shops deploying their assets directly in DeFi and more and more will be directed

towards professional asset managers like us and like the morph for curators and and many of these um types of players who are just like specialized in doing this who have the experience who have the risk management practices and we believe that over time um we'll see more and more of these uh professionally managed strategies on chain. So the same way that in traditional finance we have mutual funds and index funds and hedge funds and all these different fund structures uh that just like do this professionally on behalf of their investors. In DeFi we also see a similar trend uh where we have a lot of onchain vaults. Now we also have tokenized trades. So for example Athena resolve it's just tokenizing a single basis trade um and just making that accessible

to everyone. And then um we also Morpho and Oiler and these different protocols using the curator model um where it's also like the individual investors, the individual users providing liquidity to the vaults and then having professional risk curators um managing these positions on behalf of the users. So we really think this is where the space is going. Um we believe that this is what DeFi will become. Um we'll have a lot of these aggregation layers uh to just take away a lot of the complexity from the end users. Um so how are we reacting to this changing uh market structure? So we are partnering with Machina uh which is an onchain asset management protocol. Um it's a layer of infrastructure that

lives on top of DeFi. Uh so this is a smart contract based system. Um this is a vault infrastructure uh for asset managers like us. um we were design partners with them helping them to um build a protocol that fits the requirements that we have and I'll go a bit more in depth now on like how this works um to kind of give a better understanding of what's possible and what we will be doing with this technology. Um so some of the features first of all of the the mark infrastructure is that it's fully non-custodial. Um so we have seen a lot of vaults in the space um that is basically just a 4626 wrapper around the nosis safe. Um, so there's there's a lot of limitations that come with that. There's increased trust

assumptions. So from the get-go, Machina was designed to limit those trust assumptions and to make a system that's much more resilient. Um, it allows for onchain risk controls. As you saw, uh, we really care about risk. We take risk very seriously. Um, so it was very important for us that the infrastructure that we run our strategies on can meet our standards when it comes to risk management. Um, also in regards to the automation systems that I mentioned with real-time monitoring and emergency withdrawals, um, the underlying technology stack needs to be able to do atomic execution. So whenever there is a risk event, we want to be out of the positions as quickly as possible. Um, so this is where like having atomic execution and being able to fully unwind a position in a single transaction is

really really important. Um, with atomic execution, we also get um, flesh loan support for free. Um if you're able to like fully execute an action in one transaction, you can just take a flash loan before executing it and then repay the flash loan at the end. This is really important um because it enables strategies uh like loop positions, arbitrage between decentralized exchanges and things like this. Um the infrastructure um also needs to be fully crosschain. I mean we've been seeing a great expansion of layer 2. There's so many new chains coming up. All of these different chains need to bootstrap their liquidity. they usually do that by providing very high incentives for people to bring their liquidity. Um so for us as uh liquidity providers, it's

often crucial uh to be very early on these ecosystems and to be able to deploy our capital as soon as possible. Um so we needed an infrastructure that allows us to like deploy our capital on different chains very very quickly. Um the other thing kind of on a similar line is the speed of integration. Um it's very difficult um to interact with DeFi. Every protocol has different standards. Um every protocol has different ways to interact with it. The traditional model is to write custom smart contract adapters uh for each protocol. That is a lot of overhead and it delays the time to deployment like from when our scouting system finds the opportunities to when we can deploy the opportunities. We need to be really

quick in that. Um, so what Machina allows us to do and this is where I will spend a lot more time on the presentation is really like explaining how the interoperability with external D5 protocols work because I think that's just a crucial point um of being able to be agile and being able to like really get the alpha while it's there before the opportunities get diluted. Um so dialectic will be operating its strategies on market on day one. Um there will be potentially other operators together with us. Um but I think this is um will really be the guinea pigs for this new technology.

So as I was saying uh we kind of need to like understand the architecture. Um so I have here like the two models. The legacy model is this kind of like the users they provide liquidity or they deploy their capital into one vault. Um and then the vault has a lot of different adapters to the external protocol. Each one of these adapters is its own solidity smart contract. um and they all need to be audited and it takes like a couple of weeks of turnaround to get these up and often times it's like the opportunities are not that long living. Um so the way that markina works is that we have a concept called the caliber. Um the caliber is a single smart contract that's deployed once. Um and then this caliber takes offchain

execution instructions uh to interact with the external protocol. So there's no more need for writing custom adapters to each protocol. there's a single smart contract which implements an on-chain virtual machine and then we can send offchain instructions to this virtual machine to be executed. So the give this gives us uh like a lot more agility. Um it also limits the the attack surface because there's no stateful smart contracts. Everything is executed atomically. Um and also like there's less of an auditing need for these. So um the way that uh the crosschain mechanism works is through a hub and spoke model. So the users will always interact with a contract that we call the machine. Uh the machine lives on the hub chain. Um you can think as mainet

being the hub chain for most cases. And then we deploy these execution engines on all the different chains and the assets can be bridged from the uh from the smart contract on the machine on the hub chain onto these other smart contracts that live on the spoke chains and then from there um the liquidity can be deployed into the D5 positions. um this makes the system um like very closed in scope. So the assets can only bridge between the smart contracts of the protocol. They can't be bridged to to external addresses. So it's it's uh similar to the uh to the child safes. So NOS safe now has this concept of deploying a safe on one chain and then

deploying these subsaves on another chain. It's it's a similar architecture to that. Um I think like very importantly um the way that um we treat deployments in DeFi is that we have an abstraction layer that goes um on top of the actual transactions. So we have this concept of a position. Uh so a position is a position of liquidity deployed in a D5 protocol. Um the way that positions are opened um is through what we call instructions and instructions are atomic bundles of transactions and I'll go a bit more into that. Um but what this allows us to do um is that we can like define very concrete um ways in which the operator interacts with external D5

protocols. Everything is a position. Every every position needs to have an instruction to be opened, an instruction to be closed, an instruction to be accounted. Um so we use the same mechanism to open positions, close positions and account for positions. Um so how does an instruction look? So an instruction is basically a transaction that is sent from the operator to the onchain vault. Uh the instruction is executed atomically. Um every instruction has a position ID which uniquely identifies the position that's being managed. It has an action type. Um so this could be a management instruction or an accounting instruction. Um and then it has a way roll script. Um I will go a bit more

into way roll and how that works. Um but that is basically where the logic of the executable sits. Um we also pass in a Merkel proof. Um because every instruction needs to be a pre-approved it needs to be included in a Merkel tree. So then when the operator executes the instruction um a Merkel proof is passed the smart contract can verify um the Merkel proof make sure that the instruction that's being executed was preapproved. Um and if that is good, it can be executed. We also pass in a list of affected tokens. Um this is crucial because we need to do slippage checks. Um so every uh smart contract, every caliber um can do generalized slippage checks by checking what the balances of the tokens were

before um the instruction is executed, what the balance is or after the instruction is executed, and then it can verify what the delta is um and make sure that no funds were lost in that operation. So this really adds a lot of safety. Um this allows operators to act um in a much more automated way because even if there is some bug in the system or if it's a fat finger from a manual um execution, the smart contract still verifies that no funds are lost um when executing these instructions. So how are these instructions constructed? Um so we designed a DSL so domain specific language um it's more of

a YAML file actually um but this is a human readable um piece of code in some sense that can then be translated into um an instruction that's executed by the virtual machine. Um so there's kind of three components. Uh so in this example we want to approve a token and supply it as collateral to a. So this is two transactions that need to be executed. We need to approve a token and then we need to call the a contract uh with the supply function um to actually deposit the token into the smart contract. So there's kind of three sets of keywords.

Um so we have the constants. Um in this case it's the a pool. So a constant is something that never changes. The address of the a contract will always be the same. So this is something that can be hardcoded in the instruction and it will be the same for all a pools for all tokens and everything like that. Um we also have variables. Now variables are specific to the strategy. Um so depending on whether you want to supply wrap e or you want to supply USDC um these addresses change um so these are things that are specific to the strategy that's being run. Um and then we have inputs. Um and inputs are really the things that change on a function call by function call basis. So once we define

we want to interact with this a contract, we want to approve this token. Um then every time the instruction is executed, we just need to define what the amount is that needs to be supplied to a um and so all constants all variables um are always included in the Merkel route. So once the Merkel tree is approved um the operator cannot change um the a contract the operator cannot change the token that they're approving. Um in the case of a there's also a parameter which is on behalf of um which is where the supply is credited to. So this also not something that the operator should have discretion to change like if the operator is deploying the liquidity from a vault um the

collateral should be credited to this vault. So these are all functions um function parameters that are included in the Merkel tree. So these cannot be changed anymore once the Merkel tree is approved. So the only thing in this case that the operator has discretion over is how much um is deployed. So the only input in this case is the amount. Um so this means that once this is approved in the MLE tree the only thing that the operator can do is to interact with this contract with exactly this parameter and they can only change the amount. Um so this really like limits the set um of executable things that really like limits the degrees of freedom that the operator has um and really like allows

uh the system to really reduce the trust assumptions um because it's like very granular um ability to to fix things. Um this uh kind of domain specific language these blueprints implement standard solidity types. Um so they're very easy to to implement. Um and as you can see here, um there's kind of the two function calls. Um so there's like the the first call which is the approve. Um it has a target um where the um where the function call is directed to. In this case, it's the address of the token. Um and then the function signature, which is a proof. It takes an address and a number. Um the address is the a pool. Um we always only want to be

able to approve the a pool. we shouldn't be able to approve random contracts. Um and then the amount is the one input that um the operator has discretion over and then once the approval is done um the virtual machine can go and execute the second call which is the supply. So here the target is the a pool um and then the parameters or the two variables. So like the token that needs to be supplied um the input amount um as well as the on behalf of um which is where the supply is credited. Um so then what happens is that once this is defined um this is also human readable so it's very easy to like check what's going on in here. Um this gets transpiled into an

instruction. So in this case we instantiated the instruction with the rep address. So what we are now so we had this blueprint which is generalized to all interactions with a now we have an instance of this blueprint um which is specific to rap the as the asset that's being that's being deposited. Um so as you can see we have some of these same variables. So we have the position ID we have a dead flag that basically just says is this position a not um if it's a dead it needs to be accounted for as a negative position. Um we have the list of affected token rep. So we can check what is our rep balance. Then we supply some wrapped eth to a then we can check what's our rep balance after. And we can make sure that the amount we

supplied um is not too different from the amount that we had before. And then we have these way roll commands which are basically the machine executable um instructions that we send to the virtual machine. And we can see the two function calls here that I had before. So first there's an approve and then there is a supply. So this is the command to execute the approve. This is the command to execute the supply. Um and then here we have the parameters that we had. And as you can see all of these are hard-coded addresses. Um so when this instruction is sent to the smart contract these will be included in the hash um that we verify against the Merkel tree to make sure that these can be changed and then this kind of random string of numbers this can be overwritten um and then this will pass

um the verification step. Um if you're not familiar with way roll you can read up on that. Um it's super cool um technology. It's a onchain scripting language that kind of makes all of this possible. Um it's fully open source. Um it's maybe not super well documented um but that you can look at the repo and and probably figure it out. Um so basically what happens is that um once we have all of these instruction together so now we had like one instruction to provide liquidity to a on the supply side we can just have a giant registry of all the protocol interactions that we want. We put them all in a Merkel tree. So we re pre preapprove all the different um things

that the oper operator can do to run the strategies. Um then all these instructions are sent to the onchain v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v virtual machine. So this is the machinerm um which lives inside of the caliber. So if you remember the caliber is like the local execution environment that is deployed on all of the chains. Um and basically what happens is that this instruction is verified for its integrity. So all the parameters are checked against the Merkel tree. the smart contract makes sure that only things get executed that were pre-approved. Um then it executes the instruction. So that's where like the tokens move out of the vault into the

protocol or the other way around in case we are decreasing our position. And then afterwards uh we can do a slippage check to make sure that not too much value was lost um during that interaction. Um and the thing that we can also do is to take a flash loan uh basically before the execute step. Um so we can just like have an instruction that calls a morpho contract takes a flash loan execute say bloop position for example. Um so you take the um the assets in the flash loan from morpho you would buy a PT token on Pendle put it up as collateral on Morpho um and then borrow against that position to repay the flash loan and in one transaction you opened up a leverage

leverage position. Um so I will quickly show a video of a demo um to kind of like make this a bit more tangible. Um so this is a command line tool that we built. This is like version 0.1. Um but it will kind of show how from an operator point of view um this all of this will will be done. Um so basically we like need to select the strategy. So in this case we have like a machine this is machina test eith um we are selecting to execute things on base.

So this machine has like um the ability to uh open positions on mainet and base. In this case we operating on base. Um so then the command line gives us all of these different options. So the first thing that we do is to check what positions we have open. So in this case the um the caliber has three positions. Uh there is uh base ETH supplied on Morpho. There is some EUSD borrowed on Morpho. As you can see, this is a negative position because it's that um and then this EUSD has been deposited into tokamac. Um and as you can see like these numbers are very similar. Um because it's just like taking the debt against Moro, deploying it somewhere else. As long as the token mark position

um has a higher APR than the borrow cost on Morpho, there is a positive spread um on this position. So um we can kind of like look at this on debank. Um so this is actually like deployed on mainet right now. Um and kind of a private test instance. So we have all the data on on mainet. Uh you can see that um we have these three tokens. So base is an index of these three tokens um that are supplied. Um and then we have the borrow position and then down here we have the borrow position um supplied on the token mac.

Um so then I think what we will do now is to manage a position. Um so what we will do is to interact with morpho. Here we have a list of three different actions that can be executed on the morpho smart contract. Uh we have like add collateral, borrow asset, repay asset and withdraw collateral. So these are the four actions that an operator needs to interact with Morpho. Um what we will do is that we will borrow some more USD. So in this case we are borrowing 20 more USD. Um the command line simulates the instruction. So this is um kind of like the raw call data that was generated in in the CLI. Um it simulates the interaction with the

caliber to kind of like display what assets are being moved. In this case, there is an inflow of 20 EUSD into the caliber, which is what we expect. Uh so we can approve this. Um now it's being sent to base. Um once this transaction is confirmed, we will be able to see it show up on the bank. Um also after a transaction is confirmed, we just print all the balances again. Um so in this case, you see that now we have 20 EUSD in the wallet um or in the caliber in this case. Um this will also show up on debank uh once it's refreshed. Um so all of this happens in real time. Um and as you like instead of traditionally you would go more you would click all the

buttons sign like multiple transaction here it's one command it's executed in a single transaction. Um and we we borrowed um the USD. So what we need to do now is to swap um some of this EUSD to USDC. Uh so we can also execute swaps out of the caliber. Um this is done through different um dex aggregators. So again this like all the command line tooling to swap one token to the other. We can set the slippage. Um it then requests a quote uh from Odos in this case. Um and then if we like the quote uh it gets simulated. So you can see that we have some outflows. So 10 USD are going out pretty much. Um 10 USDC are coming in. um basically minus

the transaction fee. This looks good. Um so we can execute and this will now execute the swap and as you can see now the EUD balance went down and the USDC balance went up because we executed the swap. Um there's also slippage checks on all of these swaps. Um so even if like the DEX aggregator is compromised or like the call data that's being executed is malicious, there is still an external slippage check inside of the caliber um just for like an extra layer of safety. Um so now we can see this updating on debank as well. It will just like show the the new position.

Um then we can deploy a new position. So this is a position that wasn't on the caliber before. This is deploying into curve. Uh so this is the CRVUSD USD pool on curve. So what we will do here is a single-sided deposit. uh where we just deposit the 10 USD that we have left and um in this case what we will do is actually deploy the curve position um and then receive the LP token from curve approve it and stake it into the curve goes um so you'll see now here in the simulation um we have the outflows we have the USD going into the pool um we are minting the LP token of the pool um then there's like inside of the

instruction this is like a very big instruction ction. There's like many steps in this. So then the LP token needs to be approved. Um and then we have the outflow of the LP token going into the go and then the go mints us um the LP token. So this all looks good. Uh we can just approve this. Um this is now being sent and then when we go over to the bank you'll be able to see um the position on curve being staked in the go. So also if you do this manually this is like many this is at least like five or six transactions um that you would have to execute and sign and everything which if you do this stuff from a metam mascot wallet is not so bad. Um if you operate a professional fund like us there's multisig and every transaction

needs to be approved and checked by multiple people. Um so deploying these like multi-step position takes quite some time if you do it manually. Here it's just like an execution in the command line. Um so now that we opened the position on curve um we still have 10 USDC left so these will just be deployed into tok um so this just now executing um the second uh deposit in the case of token mac it's also the USDC is deployed into the token mark vault we get back the token mark USD uh you can see here this is the inflow um that is being minted and then this LP token is staked in the token mark contract so there's also a approving the USD DC deploying the USDC and token mark

receiving the LP token back approving the LP token staking the LP token into the staking contract and all of this is executed in a single action fully atomically. Uh so this also looks good. Um so we can just like approve this transaction is being sent um and then we quickly go back to the bank um and look at that position there. So as you can see um oh yeah so there's also just like displaying the position again. Um so now as you can see there's an extra position here which is the one that we just deployed.

Cool. Um so this was a little demo. I hope now everything is a bit more clear and tangible. So why did we at dialectic decide to use this technology stack over other technology stacks? I mean as you saw like it's very usable, super user friendly from a user perspective. Um we have full EVM compatibility to any chain. Um we have the full atomic execution. It's fully non-custodial. Um which is also very important from like trust assumption basis. Um we have the infinite composibility. Um and there's some really cool tooling like the CLI is the first uh kind of like operator facing tooling that um Machina will provide. Um but it looks like we'll also

get an API uh we'll get an SDK uh to run automated strategies um and and these sorts of things. So what will we be doing with this? Uh so we will launch uh basically three products. Uh so these are all onchain yield indexes. Uh an example here would be the dialectic USD yield index. So this will be just like broad exposure, stable coin deployments across many different chains, across many different protocols, many different underlying assets. So we can really have good um diversification, good risk management.

Um and also all these strategies will of course be tokenized. Uh so there will be a yield bearing token um that anyone can buy on the centralized exchanges. It's fully composable. You can put this on lending market. You can loop it um um and all these types of things. Um but we will also have our other three strategies. So there will won't just be USD yield index. There will also be an ETH yield index and a Bitcoin yield index. Um and it's all very similar strategies. So these will all be available on Ethereum mainet. Um as well as Inc. So Inc. is the Croken 2. Um it's one of our great partners. Um they've been very supportive. Um and it's all like running on on wormhole which is our

um auto launch partner. So these tokens will all be tradable on the centralized exchanges. Um anyone can just go on cow swap or wherever um and and buy these tokens and these will just be yield bearing tokens that go up and acrew the yield and then they can be redeemed um against the underlying um with no KYC required um on the decentralized exchanges. So what are the features um of the strategy? So we'll have the same real-time monitoring uh that we have for emergency withdrawals. So any position that's deployed will be monitored in real time uh with hypernative um to get real-time alerting on risk events. Um through the atomic unwind, we will be able to close all of these positions very very quickly. Um we can also just

like optimize all the harvesting. Uh similarly we can just like look at all the all the different um incentive tokens that are being paid out and just comb those in an efficient way. Um, Machina will also offer a security umbrella. Um, so this is very similar to what AI has uh where you have a ability uh to underwrite the risk of the strategy. So some users who have a higher risk tolerance um can stake their LP tokens in the umbrella contract and then in case of losses um those positions will be slashed. Um but what will what that will do is that anyone who is not in the umbrella uh will have cap cap downside um because there's this like native insurance mechanism. So this

is really kind of reproducing the Nexus mutual insurance that we have on the funds. Um and then lastly uh we can enforce risk policies. I mean all the positions will be onchain and auditable anyways. Um but the smart contracts also allow to set exposure caps. So we can say um as an operator that we commit to not allocate more than whatever percentage of the portfolio on any single protocol or on any single chain or on any single asset and then this is an onchain enforced risk policy that can um provide diversification um to the user and make it very transparent.

Um I don't have a thank you slide um but thank you everyone for listening. Um and I think we have two more minutes for questions. [Applause] You can raise your hands if somebody has questions. I can give you the mic. What will be the fees on the strategies? Um, TBD. Um, so like the strategies can take management fee um and performance fees. Um, it kind of depends on the yield and how much liquidity we have. um it's going to be like 110 220 somewhere in that range. Then those fit those fees are split between the operator and the

protocol. So machinizer protocol takes a fee for the infrastructure. Um so all fees that are generated will go in large part to the operator and then a smaller part to the protocol. Hey, thank you for the great presentation. Uh, quick question on the CLI. Uh, so I guess it is going to be public, right? Like we're also going to be able to use it as DeFi users. Um, if you run your own strategy, yes. Um, like the CLI is specific to a strategy. Um, in this case, we had like this Machina

test strategy deployed. The CLI is connected to that specific vault. Um, and that specific strategy. If you run want to like as a personal user just deploy your own private strategy where it's only you uh you'll have the CLI and you can just rebalance your portfolio using that. Understood. Then maybe yeah maybe question makes no sense but I saw that there was no like uh strategy health uh breakdown in the CL CLI directly like you know you were borrowing and we couldn't see the the the health of the strategy. So I was wondering like is that something that's going to happen and appear at some point or Yes, I mean uh all feature requests welcome. I mean I said this is like a very early version. This is just like

trying to get uh stuff up and running on mainet. Um but um we'll work closely with the Machina team over the next couple of months um to bring our own feature requests. I think the Machina team will work with other operators to get their feature requests. Um so we can just add all of these things and make sure that um that it like works for us and everyone else. All right. Thank you very much. We'll take the last question. Yeah. Yeah. I had a question for the vault strategies. Uh deposits are they taken in a single asset, multi-asset and for withdrawals the same thing? Yes. Um so every machine defines an accounting asset. um that's the asset in which the share price is denominated in and that's

the asset in which all positions are denominated in and that's also the asset that users um deposit and redeem um from the vault. Then there's also um a thing called base tokens. Uh so the base tokens are the assets in the strategy that are priceable through oracles. Uh so like if the accounting token is USDC, the user deposits USDC but then the operator maybe wants to deploy a position denominated in USDT. Uh so in that case USDT needs to be enabled as a base asset which requires there to be a price feed from an oracle that prices USDT against USDC um so that all the accounting can run on chain.

Sorry since you mentioned oracles. Um so sometimes you know you might have to price based on something else that requires multiple oracles. So composing oracles uh how are you guys going to solve that? Are you looking at stuff like uler Oracle systems or anything like that? Yes. Um, so the Oracle system is I think based on morphos registry uh where you can do multi-step pricing. Uh, so if you like need to jump like do two jumps to get to to the asset that's possible. Okay. Thanks again for the presentation.

Thank you so much.