A Case Study in Building a Secure Omnichain Yield Vault

Transcript

Big applause. Thank you. Hi. All right. Uh, hi everyone. Yeah, my name is Yan. Thanks Tobias for the introduction. I think this is an interesting followup to actually Tobias's talk about different chains uh and their usage because um you know there are still multiple chains out there. I think last year there was something like 130 rollups circuit one of them. Uh but there is clearly a few that have a lot of the TVL. It's sort of a disproportionate. The first five or 10 in terms of TVL have most of the TVL and then the rest of it doesn't. Um but that doesn't mean we should build apps only on those one chain or two chains or five chains. I think um still there's going

to be a world where a multi-chain um ecosystem works. And to uh bring this reality into focus, we need to have everything that we have on one chain work on every chain. And so I'm going to talk to you about um something that we're doing now at Zirit uh which is a new product Zircuit Finance. But I'm going to talk a little bit more about the technical. So I apologize if you wanted a product pitch. There'll be a little bit at the end. Uh or if you didn't expect too many technical things I will have some function names, but I promise you I won't show share any actual like code. Uh but we're going to talk about getting DeFi to become crosschain. So what's the problem? Uh the problem is there are a bunch of chains. Some have some liquidity, others have other liquidity. And if you are a

user, you know, you don't really want to be thinking about where your assets are and where the app that you want to use is. Um, as Tobias pointed out in the last talk, you know, there's there's certainly some places for some apps, Poly Market, you know, you probably need assets on Polygon. That's great. But you don't want to have these actual, you know, mental processes going on inside of you when you think about paying something. Unless it's a really large transaction like a house or a boat or something. I don't know what rich people buy. Uh I bet you're not really concerned about how you're paying or where your account money is hitting.

You're just tapping your credit card or, you know, paying in cash and it's some shared pool that you have. And we want this experience to migrate over to Ethereum and its ecosystem as well. You don't want to worry about where your funds are. you just want to use the funds. And so if you build an app that can work anywhere all the time, this helps to solve that problem because now you just, you know, have your wallet, it connects to wherever and everything is good. So what we want is something that accepts and returns funds from any chain within the ecosystem. Users can do this wherever we build an app. There's a bit of a engineering lift for anyone building this app because you do need to support multiple chains. That's a bit of a pain. There are some small subtle differences in some of them, but if you

can get over all of those or if they're all mostly EVM, it's pretty easy. And then we want it to just work as if it was on one chain. We want accounting to be properly accounted for. You know, you don't want race conditions. You don't want anything that will be complicated just because you happen to use multiple chains. And in doing this, you also get the advantage of potentially putting your users funds uh into strategies on any of the supported chains where they can make the most money, right? So you can tell users that they put into strategies on any chain regardless of where they deposit, which is I think an ideal situation because you really want to abstract all the bridging away from the user, right? I think bridging is is a concept that's been around for, you

know, obviously as long as L2s and side chains have existed in other blockchains, but it's not something that I think most retail users get. They don't understand what bridging is. We really want to get rid of this. So, we just talk about apps. And to do that, we have to overcome a couple of challenges. Um, first the bridges, right? Blockchains don't know about each other. So, we have to overcome this natively within our app. That we can solve using some existing technologies I'll tell you about. Uh then we need to adapt some other specific primitives and we can reinvent the wheel. We're always free to reinvent the wheel whenever we want but uh that usually introduces a bunch of risk. So we can take existing primitives. Vaults are really popular these days. ERC 4626 is one of the more popular designs.

Let's use that. It's not quite multi-chain um out of the box, but we can put it into a multi-chain system, make it work, no problem. And then we just have to overcome latency, fees, and some failures. We don't want to do anything risky. We do want to have safety everywhere. And then it's just about accounting and making sure everyone gets the money where they need it to be. And actually, you can do this fairly straightforwardly, right? There's no reason to over complicate the system, especially when we have existing bridging infrastructure that abstracts most of the sway. And in particular, we're going to use layer zero for this.

I don't work for layer zero. It's a nice product, though. And we decided that actually we're going to use it everywhere. And I'll talk a little bit more about um some specific concerns that we might have or you may be worried about. But essentially if you use layer zero and you build an OAP, you are essentially inheriting an an inter interface on all of your smart contracts sort of everywhere on all the layer zero supported chains. And that may or may not actually be VM uh compatible, but if we keep it to that, it's simpler. And uh that means you can deploy to multiple chains very quickly and build out infrastructure very quickly. And so I think this is particularly interesting especially here at ETH Prague. Um a to see what we're building and b in case you're you know looking for ideas at the

hackathon. Oaps I think are something that are underutilized for anything other than just you know message passing. I think actually building um crosschain apps as a first class uh entity is is something that's very very interesting. And so the solution we'll have is just take that ERC 4626 vault. We'll put it on a single chain. Doesn't matter which one. We're going to pick let's say base because it's fast and EVM equivalent and we're going to use it to store all the accounts and then we're going to have a bunch of spoke chains and we're just always going to pass information either to the hub chain or through the hub chain in order to get everything to work and we'll call these you know other chains spoke chains and they'll issue the relevant deposit and withdrawal tokens or manage specific

strategies on these chains as appropriate. And if we do this then we can zoom in a little bit on the hub chain. You can also call this a accounting chain because it holds the main vault. It will handle all the shares. Everyone's funds will essentially be somehow recorded via a layer zero message into um this hub chain uh and the vault that it has. And then we can use it to do all the cool thing the vault normally does. Namely, it can define the share price. Um it can orchestrate crosschain redeems. It can do all the cool stuff that we needed to do. And then if we look at a spoke chain, all we actually need to do is make sure that it is issuing shares via this hub chain and a layer zero app as appropriate um on the local chain and

we'll take all these OFT representations on the smoke chains and say those are your assets in the hub chain vault. So this makes it fairly straightforward and um then we can also take the uh spoke chains and have those OAP endpoints deposit directly into strategies for users if that's something they want to do which is really cool. So that's actually not that hard but I realize layer zero is actually a tech that people don't talk about out in the open too much. So I'm going to give a little bit of a background because you might find it interesting to hack on or just to understand what I'm talking about. So what is layer zero? Well, they sell themselves as the universal crosschain router and they're usually pretty good at this. And essentially, you have a bunch of contracts deployed on all the

chains and on each one there's an endpoint and you can send messages to and via that um endpoint smart contract. So, if you send it a message that says mint elsewhere, it will receive the message on the chain, process the stuff, burn some tokens if it has to send a message to something called a dist distributed verifier network. they will pass the messages to the other chain. That corresponding endpoint will mint it and everything will be really happy. And conversely, it can also execute things when it receives. So when you actually get a message from another chain via layer zero, it can do the things you want like either uh let people withdraw or put stuff into a local strategy.

And then on each spoke chain, you can have an which is a omni chain fungeible token. This is a token standard uh that's defined by layer zero to allow all of this to work seamlessly. Um you can use this to wrap traditional tokens in other ways but uh essentially it's got its own interface and then on each version of your spoke chains you have this native thing that you can mint and burn via this layers uh endpoint. pretty straightforwardly and name and and and the easiest way to do this is actually just let the the endpoint do this as it communicates back and forth with the hub chain.

Then uh all you need to do is wrap that into an adapter to deposit in the right strategies whenever you want. Um it could also be used to accept things like USDC or USDT. It can do all the fancy stuff that you need to compose with other things in DeFi which makes it sort of interesting. Before I get into a little bit more, uh, I do want to talk about the decentralized verifier networks, the DVNs. You may have heard a lot about these over the last couple of weeks. Unfortunately, they made some news as some protocols used only one of them, but essentially the decentral centralized verifier network is the network that passes me passes messages between endpoints for layer zero. And so each message will be attested to by some number of them. Uh, and then that

message will be passed onto another chain and people will verify it. And if everything looks good, it'll do the corresponding action. Now, the key here is that your app can configure this. Uh it can actually choose who does this and and how many of them do it. So, as long as you take the right precautions to uh build out the right number of DVNs or to use the right DVNs, actually this is not that problematic, right? Using only one is maybe not so ideal, but if you have three or five or 10 or 15, it definitely reduces the trust assumption. Now this is a bridging application where there is a trust assumption. So I won't say it's 100% say trustless because these DVNs do play a role. But if you use enough of them it can certainly reduce the trust of something is very very manageable.

Okay. So let's take a closer look at what this might look like if we actually wanted to build one of these out. Again I'm telling you there's not going to be a lot of code so don't worry too much. Uh the first thing that hub chain. The hub chain is basically just going to use the 4626 primitive. It's a wellestablished vault. People use it all the time. Uh, and all you need to do is have something that converts uh the incoming messages to shares and vice versa. Essentially, what you want to do is have this hub share um record shares which you can then pass to other layers or endpoints in your DAP. In which case, you know, they can trade, sell, deposit, whatever. Uh, using the shares. This gives you a nice single source of truth despite being live on multiple chains.

You can have arbitrarily many spokes and as long as you have sufficiently small latency and good um connectivity to your hub chain through the layers error network, you can actually get a single source of truth and now all of your accounting only needs to happen on this one chain. So your maintenance actually doesn't need to go through the roof for multiple chains. It can just be reduced to making sure this hub chain does the right thing. Critically, the vault doesn't need to know about what's going on other chains. It should know that it's an OAP and that it will receive and send messages, but it doesn't really need to care that there's only three spoke chains or seven spoke chains. They don't need to be hardcoded. They can be.

There's some benefits of that, but they don't have to be. On the spoke chain, uh, all you need to do then is build a vault token. You need to have a share of this thing that lives on another chain. Um, you do this using an straightforward here. Um, mint the shares on the hub chain. it will send a message to the spoke chain and say hey produce a share for the user. The user can then take that and do something with it or you can invest it as appropriate. And critically here all you need to do is make sure that you're always in um sync with the hub chain. And this is fairly straightforward to do as long as you respect a key invariant that uh every time you're sending messages to or from the um hub chain that the corresponding action on the spoke chain

happens first. So really if you're going to mint a share, lock the assets on the spoke first and vice versa. Pretty straightforward. Then uh occasionally you may want to move some stuff around because some people might be saying well this is weird. What if I want to deposit on base and withdrawal and optimism to those people I say thank you for paying attention and actually it's still not that hard though. You just need an extra layer of hop and you may need to compose some redeems when we do this right. So if you actually do want to do this, you can utilize all of the layers of your infrastructure and this sort of clean architecture to do that. You can deposit on one chain and withdraw on another as long as the invariants that say the hub chain is the key source of truth are

respected. And so you may need multiple hops. This will add a little bit of delay but still makes it pretty manageable for your users, I think. And finally, what this means is on each spoke chain, you can do whatever you want with those things. fairly straightforward because everything looks and feels just like a local app, right? It looks like an OFT, which just looks sort of like an ERC20 with some additional rules. You can deploy funds, you can add funds, you can mint funds, you can put into D5 protocols, you can do whatever you want with these things. And so what I've tried to do here is highlight a highle architecture of how you can take ERC 42 uh 4626 and glue it in with OFTs to do more than just, you know, what one of these things can do on

its own. And um then you just have to consider a little bit of corner cases. I already talked about this is the two hop compose essentially if you want to withdraw on base but you deposit an optimism you first you know send your message to the hub chain and then the hub chain will send a message to the other spoke chain and you can shortcut this in some very specific situations but I think I've already said this and I don't want to bore people so I will move on and I did already mention that if you can get all of this to work in a nice way uh which is not that challenging to do you can then actually allocate funds on any of your chains really conveniently. Um, a lot of the stuff that you're going to be talking to already looks like your hub chain

anyway. So, for example, if you're putting stuff into a more for vault on a spork uh spoke chain or the hub chain itself, um, you know, it's going to use 4626 anyways. So, a lot of your infrastructure is already going to be built out in this manner. So, you're not reinventing the wheel and you're getting um some experience for integrations along the way. Or you can do whatever you want. you can give it to say an off-chain yield partner and they can generate yield and you can bring stuff back on, you know, manually or as appropriate. When you deal with funds, it's just that simple. Um, all you need to do is make sure that on each one of these spoke chains, you do have a strategy manager which has, you know, one asset manage being managed by each strategy per pool.

It's pretty straightforward. And you can also use this to balance across different chains, right? because you're always going through the hub chain. If you need to send funds from one chain to another, the hub chain uh and this hub and spoke architecture lets you do that fairly straightforward. And frank is also just as easy. So, I'm not going to get into the details of this because I do realize we're a little over time. Not that I'm running out of time, but uh I do want to say um that this actually works. So, this is not just an architecture that uh sort of an academic I would say, oh, this is obvious and you should build. No, it's actually one that we use. Uh so Zirket was a zero knowledge rollup. We still are a lot of things. Uh but our newest product is Zirket Finance. And Zirket Finance is a

way that users can get access to institutional grade uh investment opportunities. And we weren't really happy about doing it in one particular chain. Um and we wanted to make sure that we could get liquidity from everywhere. And so we had to solve this problem. And so we're sharing it with you a because I think it is interesting, but also because it is useful, right? It's not just something that is uh an interesting hackathon experience. We built it. We built built it to power circuit finance and with circuit finance you can actually get access to regulated uh managers with proven track records. So I'll take a couple minutes here just to talk a little bit about that. It is our new product. Um it is uh targeting 8 to 11% APR on stable coins. So that's I think pretty good. This is done largely through um asset managers where they

target off-chain delta neutral funds. We don't take a management fee. There is a bit of a performance fee, but there's no minimum or lockup period. There is a 14-day listed here because some of the chains we are on are optimistic, in which case if you want to do withdraw, there is a 7-day delay in some cases. Um, but yeah, that's it. And it is multi-chain. So, we have base and Ethereum, but because we built it in the way I just described, we can bring it onto other chains whenever we want. So, if you are looking for yield on um your stable coins, please check out Circuit Finance. uh and we the way we get a lot of this yield is to actually um work with asset managers. So the asset managers will actually um generate the yield not necessarily defi native we do integrate with a and morpho but uh also

there are asset managers like monarch ordius who do things um that might not be accessible to you otherwise so I think it's a good way to to get access to this capital without um necessarily being exposed to all the risk in DeFi. So in short, got a little bit of time left. It's okay. Uh all I wanted to say was I think it's really cool that you can take these onchain primitives that are meant for onechain, namely the ERC 4626, which is really popular anyways, and there's no reason to keep it um constrained to one chain. In particular, cross-chain apps like OA apps and layer 0 do exist. You can glue them together.

They work. If you're clever about things and you cover all your corner cases, it makes for a really nice um product architecture. And this is demonstrated in the real world with Zirket Finance. Check it out. That's my talk. >> Thank you very much, Yan. Any questions? Yep. I'll come to you. One second. >> Hi there. Um what are the trust assumption on the crosschain rebalancing? Is there a governance rule over it? Who decides on the rebalancing?

What are the executions? >> In in the general case, yeah, you can make that whatever you want. Um for the circuit finance case, we'll put the money where the asset manager sort of says that's where they're going to generate the yield and we won't balance unless there's an explicit need or to do some quick withdrawals. One thing that is kind of nice about this architectures that you can balance so that if there is a lockup period because an asset manager has like a fixedterm loan um you can bring assets from a different chain that might have been in Morpho for example which are easily liquid and give them back to the user without waiting for that lock up period. But I think it's up to whatever the app wants to build in general.

>> So would the app create its own DNV hand layer? >> It would need it would need to create its own balancing strategy. If you don't want to balance it that's totally fine, right? You can say only deposits from from optimism and only withdrawals from base. That's that's something you can do. It's up to whatever you >> makes sense. Thank you. >> Any other questions? >> Um hello. Sorry. Um how did you decide between uh chain link CCIP and layer zero of in general from a business perspective? I know that they're a bit architecturally different.

>> That's a good question. Uh I don't I didn't make the decision so I don't know. Uh, I I think you can do this with most of them. Uh, we like layer zero. I don't know. I think we like them all, but we don't want them. I'm sorry. I don't have an answer. >> Okay. >> Thank you. >> Questions. One more. Good. Thank you very much, Yan. Big applause.