Jan Gorzny - A Case Study in Building a Secure Omnichain Yield Vault
ETHCluj Meetup·Tue, Jun 9, 2026, 12:00 AM
Speaker
We distill lessons learned about building robust omnichain DeFi products using existing battle-tested standards (e.g., LayerZero). This talk provides actionable patterns for designing robust cross-chain products.
Transcript
My name is John. I'm a technical lead and co-founder at Zirket. Uh Zirket's a lot of things. We built a zero knowledge rollup and then we decided what else could we do? And uh one thing we could do is bring institutional finance onchain through a product that we call Zirket Finance and that's our focus now.
And I'm going to talk to you a little bit about the technical parts of that um because it's a little bit interesting. I think it's something that might be obvious, but you also might not know how um some of these protocols or uh DeFi apps sort of are built in the modern era, right? You might still be thinking about single chain applications or unis swap clones or something like this. And so I'm just going to dive into the architecture just a little bit. It's not super technical.
So you're not going to see like a bunch of function interfaces or solidity smart code but just the idea of what we're building and uh then a little bit about what the product is and then we'll be done. So without uh further ado, what are we trying to build? Well, we want to try to build crosschain defi. If you did see the panel earlier today um with the L2 participants um that I was on, uh I I like to reference the stat that last year in October there was about 131 L2s or roll-ups listed on L2B. That's a lot.
that means a lot of fragmentation on liquidity. Um that is not great. But we don't want those chains to necessarily have to do all of their own sort of network effect building or you know build out their own solutions. Having multiple copies of a single DAP like Uniswap is not an ideal way. Um and there are ways to solve this that you know big players in the space are trying to solve.
For example, the use of based roll-ups might remove some of that altogether. But actually at the application layer which is a little bit more attainable for smaller teams to build out um we can actually also build apps in with this in mind. Um so what do we actually want? Well we'd ideally like to simplify our lives have a single vault somewhere uh because we don't want to be managing rebalancing liquidity or you know updating multiple things but we don't want it to be necessarily um only accessible from a single chain. In fact you should be able to deposit and withdraw from it from any set of supported chains that you like.
So if you like to have money on base, put some money in some DAP. That's great. But if you're an optimism user, you should also be able to access this app. There's no reason not to, right? This is a modern day and age.
We can architect this. Um the challenges that come with that though is race conditions. If we start to bridge things, uh so what happens if your shares or your accounting goes out of whack? You know, on one chain there might be some price action for something, on another chain there might not be. That gives arbitrage opportunities and it complicates your life as the developer and confuses you as a user.
if you see weird yields coming to and from things. And if we can do all of that, if we can solve all the technical problems, which I will argue we can, uh you want to be able to use this app in uh ways that are beneficial for the users, namely take your assets and put it wherever it gets the best funds for the users. You're no longer constrained to the best yield on your chain. You're constrained to the best yield on any of the chains you support. And that's a really nice thing you can do.
So why is this hard? Uh this is hard because obviously most rollups don't talk to each other. Um by default they have a single bridge to Ethereum. There are bridging solutions out there. You got to pick one.
You got to build on it. Doesn't mean it's impossible, but it does add a a point of pain. So you know using chain link or using layer zero uh you're using something else. There are things you need to build. And then if you look at the standards to do this because you don't want to reinvent the wheel.
A because the wheel is very nice and B because in this world you have to audit your wheel every time you change something. Uh you want to look at standards and your common vault standard these days is ERC 4626 which is you know very popular. It's got a good interface but it really doesn't have multi-chain support um out of the box. Actually it's just you know designed for one chain. And so this on its own doesn't do everything.
So we can be a little bit clever about how to solve that and we'll show that soon. Um then you just got to worry about bridging itself. Is there latency? Do you need high performance? Do you need low latency?
You do need fees and you do need to know what happens if one of your chain doesn't do something correctly like a transaction gets dropped or reorged or something. Uh but if you can overcome all of that, this is pretty straightforward. And then it's just anatic problem. And I will argue that's not so hard if you keep everything on one chain. And how can we do this?
Well, how did we do it at Zircuit Finance? is actually pretty straightforward. We just build out a hub and spoke model. So, we can take that singular um ERC 420 or 4626 vault and you can put that on particular chain. It doesn't matter which one.
Um you probably want it to be cheap and fast and reliable so that you're not charging users a lot and they have a pretty good UX. And then what you can do is you can issue um shares of this to token vault um in uh OFTs or other bridging solutions. We're going to use layer zero. We just happen to do it. um you might be scared of of that because of some recent incidents, but if there's no supply chain hacks and everything's configured right, Larzo is still a very strong good technology.
So there's no reason to be sort of scared of that on its own. And what we can do is have those shares issued as as OFTs, which are on chain fungeible tokens. I'll say a little bit more about that near the uh middle of the talk. And those are tokens that are inherently sort of tied to the layer zero protocol. And now you can move them to and from different chains.
So anywhere that there's a layer zero endpoint, you can take uh withdrawals, sorry, you can take deposits or give users withdrawals no matter where they actually put the money in the first place. So that's pretty straightforward and it just means we have to build out two parts. The first part is a hub. So this is the vault itself. Just got to put it on a on a chain somewhere.
You're going to be issuing shares in the same manner that you want um on any other vault except this time it's going to be an OFT as I mentioned. Uh, and this will just always be your source of truth. So no matter what happens, you're going to get tokens to and from this vault through the layers that we're bridging out. And whatever this vault says is final, you're just going to treat as final and everything will reconcile later. And then you can do things like compose if you want.
Um, this has a nice interface. It looks like other vaults. You can, you know, get some good strategies going, that type of thing. And then every time you want to move assets, use OFGs. And correspondingly on every chain that you want to have users talk to your app on, you build out just sort of a spoke.
And this is essentially just an interface that wraps the O of key into or out of whatever digital assets you care about. So if you want to deposit, you deposit your OFT mint some share. Your share eventually gets transmitted back to the hub chain. Um all of this works wherever you want it on whichever chain and that's it. Now you don't need to worry about where the assets um actually are coming from because you're sort of sending it to the main vault anyways.
And then you can actually um move things between different endpoints anyways, different spokes. Usually you want to do that through the vault itself because the vault is the single source of truth that we're trying to build out. So you have to maybe swap between um A and B through this hub chain. But it's not too bad if the um if the delays between transactions are not too high. So let's go into layer zero just a little bit because it is an integral part of this design and it's one that you know people may have questions about especially due to recent incidents.
Uh so what is it? Uh lay layer zero is just a bunch of endpoints where you can deploy on multiple chains and they will define some interfaces where you can um establish uh digital token in this OFT standard and the standard will basically let you move things between each other through things called executives and um they will have systems called DVNs which I'll talk about soon where you pass messages from one chain to the next. So it's actually pretty straightforward and if the DVMs are configured correctly and if you have sufficiently many of them um it's a totally safe and good system. The of is what you're actually going to end up using as a user. We're going to abract all that away from you in the case of circuit finance.
And most apps probably you don't actually need to tell the user what token standard you're um building on. But I wanted to make this a little bit more technical and say this is one of the standards that are out there. In fact, um I think one of the reasons this is worth pointing out is that if you look at different bridging protocols, they will all have different um token standards. They all look and feel like ERC 721 or um ERC20 depending on the use case to some extent, but they're not interchangeable out of the box. If you start to commit to a bridging protocol, actually what you're typically doing is also committing to their their standard.
And they're not really different, but ofts are not necessarily going to work exactly with chain links CCIT for example. Are they significantly different? No. But you know, you do need to change your tests. You do need to change your code.
And so actually picking one of your standards um is somewhat important if you are looking to build out a product. If you're just a user, it doesn't matter and it's all going to be good. But essentially once you have one of these tokens on the spokes, you're going to have you know these these OFTs living around and they will be issued to and from messages um with the actual uh hub chain through something called an adapter. And this is also one of those pieces that changes if you use a different um bridging infrastructure. messages on layer zero are passed between uh different chains using something called a DVN.
You may have seen some some stuff about not only using one of them. So, you should have multiple DVMs and they should be configured in in good ways. But this is um one nice perk of layer 0 is actually that you have a lot of control when you're building out a multi-chain app using layer zero. One of the reasons we like using layer 0 is that you get to change who your DVNs are and um the thresholds you want for that. So if you make it sufficiently robust and sufficiently diverse, you get a really nice system.
If you want something that's quick and trust centered, you know, you can reduce that, but you do that at your own risk. Again, changes depending on the bridge protocol. Um, but it's still something that's useful. Okay, so let's jump very quickly into the smart contract architecture. Um, I've already sort of said the highle stuff and I'm not going to go too much deeper.
On the hub chain, what do we want? Well, we want this vault um that looks and feels like anything else in DeFi. And for that we're going to use ERC 4626. It's pretty straightforward. We're going to take assets.
We're going to issue you shares. Then you can do whatever you want with the shares. And you know the assets can be traded back for shares or vice versa at any point. And we can use this as a single source of truth. Right?
Critically what is nice here in this design is if you actually build this vault using layer zero, you don't need to have the vault be aware of the other chains. It just issue shares that happen to conform to the OFT standard and then those can move around as you want. But your actual vault implementation is fairly straightforward and fairly simple. You can just sort of fork it. Most of the tests will work.
You know, you don't need to do anything inherently multi-chain on this design. On the other hand, the tokens, these OFTs, they obviously need to be very multi-chain. Uh they're going to be moving around different chains. You're going to be trading them in different places. You're going to be accepting funds in different places.
So, you need to have an OFT that represents these shares. Um and that's totally fine. But what is really important um if you go down this route is that you maintain the vault being the single source of truth. So anytime you mint assets or you burn assets um that are often on one of these spoke chains, you do want to make sure you've sent messages to and from the hub and the hub is sort of confirmed or acknowledged that this is happening. So you really want this hub to be the single source of truth.
It will simplify your life. It'll mean failure modes go away in a lot of cases and others are easier to handle. This is pretty straightforward. And then you have to do a little bit of work to get some of the UX work uh to be very very smooth. Especially if you want users to be able to withdraw on one chain and deposit on another or vice versa.
Um essentially you can do this if you always go through your central hub though. That's pretty straightforward. Takes a little bit longer. Um but it's it's totally fine. You can skip that if you know there's certain cases in particular if you're on the hub chain as a user.
So if you choose a good hub chain that's fine. Um but then once you do that too, you can also use the O of endpoints um in ways that compose to other assets. So you can actually have strategy managers on each one of your spokes or on the hub chain itself to actually put money to where we want it to go. Um so this means as a DAP developer, you can provide yield to your users on any one of the chains that you support. That's really nice.
That's really convenient because it means if you have a good opportunity on base that doesn't exist in optimism, you can still get some of the money from bass uh put into optimism or vice versa or any of the other of supported networks that you build on. So this is actually a critical part and this sounds fairly straightforward and fairly obvious but I think this is some sort of design that actually you know wasn't possible until we saw interrupt come alive in the last couple of um let's say years right it's it's it's been a bridging revolution to some extent. All right. So, I won't bore with uh some of the other stuff I talked about. Uh the capital allocation.
I think I already spoke a little bit about um you know, you can do stuff when your vaults look and feel like the ones that are out there. Anyways, um 4626 is used by Morpho. So, when you start to think about integrations and putting capital into some of these um positions, if you know how to code with your hub vault, you can do this um pretty straightforward. All the interfaces are there, but you can also do other things. Of course, you can always do other things.
Um, so you can do uh things like that and I will skip some of that, but essentially anytime you want to deploy capital, you put on the right chain, you put the stuff in the shares, you make sure the hub is always keeping track of it, and then to reverse it or to withdraw, you reverse. And so why why am I telling you all of that? Um, not just because I think it's an interesting design that someone should go out and build. I give the stock sometimes at a hackathon where, you know, I do want to see if people understand um, you know, if it's difficult or if there there's some nuance, but also because we built it out into a product. Um, and I don't I didn't want to spend 20 minutes up here showing a product.
Um, but I I do want to say that actually we built this design to get you yield um on multiple chains. Zirket um you know was was very involved in in a bunch of chains. And so we wanted to um make a crosschain solution so that we didn't have to necessarily get people into a single chain to do it. And we built out Zirket Finance. And so Zirket Finance is a place where you can deposit funds and you can earn yield on stable coins USDC and USDT.
I'll give you a quick rundown of the stats. Um we're targeting 8 to 11% which we think is very competitive. This is going to be better I think than most pools on a or Morpho because they're not um overcolateralized loans. We generate yields by giving um funds to asset managers. So asset managers that we work with um actually will generate yield in however ways that they want.
Generally they're institutional partners. There's a logo wall coming up. If you don't know who I'm talking about, I will say some soon. Uh but essentially we work with these partners and they do yield and good things. Um there's a small performance fee but you don't have to deposit anything um big right so actually what we want to do is provide institutional capital without a minimum lockup period or a minimum deposit size.
Uh in this case there is a bit of a withdrawal time in some cases if the asset manager has put your funds into a system that you know it needs some time to recover funds from. But that's why we can also talk to apps like morv or off um to have um quick liquidity and we can build on any layer zero chain we want. Currently rely on base and ethereum just because we have to start somewhere and as the system grows and gains adoption we will adop um we'll add more chains. So what do what do we actually do? Um well the funds um are deposited and then they're exchanged for shares of basically um funds managed and operated by people like Monarch Thorius.
Um, we just announced wisdom tree two days ago. I think it was two days ago. Um, so essentially we get yield for you and your USDC and USDT from sources that don't normally exist on chain. So we're actually bringing institutional capital on chain for you. We're not necessarily going into define native primitives which means this is a lot more safe in a lot of ways because you don't have weird looping.
You don't have a lot of technical lift uh where you can introduce technical um risk. Of course they're smart contracts. they have been audited all of that but it's a fairly straightforward system. So um in short though the whole idea of the talk was you can put two things together namely here 4626 which is I think something that um we don't talk about enough even though a lot of people in DeFi which is still the biggest use case in um Ethereum and and uh the ecosystem is running on. Uh I haven't seen a talk about 4626 in a while.
Maybe I missed one today. If I did I apologize. Um, but I think people should know what it is because just like ERC20, it's everywhere. And trying to figure out why this is useful, how it's used is nice. But then also of Zero, um, I don't work for layer zero, so I didn't want to necessarily just shill it.
But it is a really good technology. And despite, you know, again, maybe some some issues, um, that some people have had with it, uh, it is still a solid bridging technology, and there are still ways you can make it do really cool stuff, even if these designs don't seem very technical. In fact, I would argue that simpler solutions are better in a lot of ways because it makes makes it easier for you to check everything and then we can actually build it into a product. We did um you get 8 to 11% like I said on stables. Um check it out.
You can it's live now. You can put money in now. If you have any questions, feel free to reach me at one of these um Jay Wars Telegram or Twitter. And I guess I'm a little under time so I have time for questions. Thank you.
Automatic transcript — names and jargon may be misspelled.