Shortcuts Kitchen: Cooking Complex DeFi Recipes in Minutes

Well, hello, everybody. Thank you for joining. I know it is rather late, and it is an hour-long workshop, but I think we can even make it shorter because really the work that we are doing at ENSO is about making it faster to get whatever ideas you got to production to get them on chain. So my name is Nenad. I am DevRel at ENSO.

This is the Twitter handle of our project, so you can also follow the updates on Twitter. And before we get started with the workshop, I will tell you a little bit about what we are actually building and why all of that matters. After we finish that part, we will dive into the workshop, and it is something that will be very much hands-on. So there will be a couple of challenges that you will solve with ENSO, starting from something very light and going to something a bit more complex. So let's say this is you, a developer, and you have an idea.

You want to get something on chain. But to get there, if you want to integrate some protocols, you would have to do some of those integrations manually in the regular approach that we have. So that requires a bit of solidity, well, sometimes maybe even a lot of solidity. It requires audits, and of course, it requires weeks or months of development and auditing work. And all along, you just wanted that thing to get on chain.

And we are trying to cut this path a little shorter, and we do shortcuts. So for devs, what we do, we are a cross-chain intent provider, meaning that you can call ENSO's APIs and say, my user has this token on this chain. They want it to end up on this chain in that vault or whatever, and this is all you really need to do in order to get a transaction that does a bunch of swaps, bridges it, and deposits it into the vault on your target chain. For users, this is blockchain shortcuts, because users don't need to know anything about, at that point, and they don't need to do anything around bridging, swapping, and depositing. For them, it's just, one of my tokens will end up on the chain, will end up in a position, and that's the quickest way for them to get there.

So this solves developer experience and cuts development costs, and also for users, it solves the user experience problem, like you don't need to use five different tools to get there. Now we're going into the technical part of it, and we're making this possible via four APIs, four groups of APIs. One of them is about routing, and that's what you will experiment with today. The other groups of APIs are tokens or positions. So if you want to move liquidity, well, there are positions you're moving from and positions you're moving to.

And when you have routing, so finding the path, and tokens, the things you're moving, you also need a way to express how do you intend to move those things, and this is where integrations come from. So this is all the DEXs that are in there, all the bolts that are present, and this is how you specify exactly what you want to get. And there's a little bit of API that gives you information about wallets and TDL. So for us today, the most interesting part is the routing part, because that's where shortcuts come from. So it's practically translating this idea that you might have.

You take a token, you deposit it, you borrow, you swap, and you deposit again. So this is what, for example? Looping. So this whole process of doing something with the token in a couple of steps, we can actually translate it into a single, runnable transaction, and it's actually executing cross-chain. With the route API, so this is like the smart routing that optimizes stuff.

We're doing swaps, but there can also be deposits and redeems. So these three operations mixed in a particular way will actually get your tokens from one position to another. And Enso actually collects these and arranges them in such a way and chooses the DEXs and liquidity positions that yield the best routing results. So it's practically the best output for the user. And essentially, this is like a little visualization.

The only couple of things you need to specify are the input token or your origin chain, the output token or your destination chain, and these blue dots represent those little operations along the way. So it is constructed for you, and you don't need to think about who to pick, where to swap, when to deposit, what to withdraw, what's the primary, what's the underlying, and so on and so on. So in that sense, this is, well, solving a lot of developer experience issues that we're facing today. And this is routing. This is, as I said, it does something smart for you by optimizing the path.

But you might want to get in the position where you want to control exactly what's happening along that path, and you want to add more stuff. Yeah, I'm going to come back to this slide. So there's also the bundle API, which is pretty much route API without that optimization. And here, you can also have different actions besides redeem and swap and so on. There's also harvesting.

You can add fees to those routes. You can borrow from protocols, repay debt. You can, of course, swap, because that's like the first operations many of us did. And when you're creating a bundle that consists of these operations, you can also include a route. So you have a pretty, let's say, static chain of operations.

And then you can say, okay, and so but for these tokens, do your optimization magic, get me the best path to a desired token. We good here? Any questions so far? Yes. So when you're bundling these actions, for example, swap will give you the amount of tokens it swapped into.

And then you can do a reference. I need to show you the code for that, and we'll get to that in a second. So you can actually reference, hey, I want the output of the third action in my list and to use it as the input of my current action. Thank you. Yeah, this jiggles.

And that's the bundle API. So again, a lot of stuff happening here. And as I said, because all of this is cross-chain, there's a bridge action. So in the middle of that bundle, you can say now bridge to another chain. And after the bridging is complete, follow up with these actions.

So you can continue moving your liquidity on the other chain as well. And we need to talk about actions. So there's a bit more than 20-something, and this is a credit roll. I'm not going to read them. They're in the docs, so you will find them.

But that was it when it comes to the overview. Now, for all of us who like to do stuff hands-on, you can scan this QR code. This is the intro to the workshop. So it will give you the necessary links and instructions how to, well, get started to do the next challenges. How many people would like to do the hands-on stuff?

Two? OK. You don't have a lot. OK. All right.

So let me join the party, then. All right. So this is the workshop intro. The challenges, the individual challenges, will be released as part of the workshop. So please join us as we go along.

And, yeah, you see my screen? That's the wrong screen, I think. Let me just expand the display. OK. Can I get a little help here?

Actually, I'm good. I found it. All right. So you see what I see now. Good.

So before we get into challenges, first couple of challenges you can actually do from the workshop, perhaps even on your phone, because there's no code involved in those. It can be code-based as well. Because in this workshop, we'll use three different things. One of them is Happy Path. So this is a little widget that we built that actually allows you to move those things very, very easily.

And this is something that you can embed into app UIs for the end users. So when you check out this intro page, you will see the Happy Path. Then there's the SDK option, or using the API directly. And a little helper tool that you can use. This little helper tool, let me just show it.

So this actually shows you exactly which chains Enso supports. And this is the current list. And all of this is really live. So this is coming from our APIs. And you can search for projects that are supported with their respective versions of their protocols and the chains they're supported on.

So this is sort of useful if you want to dive into the supported tokens. For example, if you want to find what's the primary contract, what are the underlying tokens, and also query based on these values. So for example, let me pull out all the tokens, all the positions that have USDC as their underlying. So I would just say underlying tokens. Paste this address.

I remove Uniswap. And there we go. We got all of those. So it's a little query thing that can be helpful when you want to interact with particular specific protocols. But we'll come back.

We'll actually go back into the workshop. And to get started, first you need to get the Enso API key. So to do that, there's this dashboard button at the top. And when you click it, after logging in, you will get an API key. And I will need to get a new key after this workshop, apparently.

And then you can use it somewhere. People who are following along, all good? Yeah, okay. So I'll copy the API key here. And I'll just start a terminal session.

And zoom this in. And maybe I just... Yeah, much better. Okay, so I'll just say... I'll just export this key in my bash environment.

And after doing that, I'll copy the first command. Let me get all of this into one view. There we go. So I'll copy the first example. And this first example will actually give us all the things that we can do with Aave version 3.

So I'll just copy this curl. And boom, you remember that credits role that we saw with the list of actions? Well, here are the actions that are supported for Aave v3. So you have borrow, and then you have the exact inputs, which is pretty much like a type system description, how to interact with this protocol via Enso. And at this point, I would like to just say one important thing.

So borrow looks the same with Aave and with all other borrowing protocols. So same parameters, even though implementations are different. So you can think of this interface as a facade to many different borrowing protocols, standardizing the way you interact with them. Any questions so far? This thing on?

Oh, wow. So these endpoints that we're hitting, do they generally return signable data, or do they expect you to provide a signer key? Or is there a standard format for the response you get from these things? Yeah, okay. So this is just describing actions that you can take, right?

So there's nothing to sign here. But I'm guessing that you're asking about something like this. So let's check out how the routes work. So you would call the API, this is the SDK, and what you get is a route with a transaction object. So in there, there's the recipient of the transaction, there's the call data, and all of that stuff.

And you need to send that transaction, of course, from your wallet. So you need to sign it. So this is translating the intent, this token to that token with possible bridging, into call data that encapsulates all of that. And what about the case for like e-sign-typed data or something? Would it give you some signable message, as opposed to just transaction data?

So it just gives you the call data, and that's pretty much it. All right, any more questions? Okay, so now that we've seen this, and I hope everybody got their API keys, you can choose either to work with Perl, Perl-Perl, or the SDK. I prefer the SDK, so let me set that up. Yeah, let me...

Let me just set up a folder. Let me zoom in a bit. There we go. Oh, yeah, PMPM doesn't have that. And now, let's say, let's open VS Code here.

Okay, nice. Get this out of the way. So I'm just now installing the EMSA Finance SDK. That's the second instruction you got in there. Since we're using PMPM, it should be faster.

And there we go. We got that. All right, and I'll just create a new file here. Index.js.

And we can get this going. So I'll just put up... an immediately called async function because that's wrapped everything. And from here, we can keep adding the code. Tell me if I can move on.

Yeah, okay. So if that was the intro, here's challenge one. You can scan it. And I'll switch to challenge one right over there. Just in case somebody needs a scan.

Here it is. Assuming everybody scanned it, let's warm up with a little bit of cross-chain swapping. So here, you get to choose your own adventure. You can pick your favorite chain and your favorite token. And when we say pick a favorite chain, it has to be one of the chain answer supports, of course.

So we couldn't go with just about any chain. Let me make this a little smaller. So I'll copy this code request. And there we go. We got a bunch of chains over here.

Again, the same chain that you would find in the navigator. And then you would pick your favorite token. And again, this is the API that allows you to get those tokens. Or you can do it via SDK as well. So I'll just run this one over here.

And let's say I want to go on base. Because that's the only chain ID I know by heart. Something happened here. All right. So this doesn't really look pretty.

To make things easier, I'll come back here. And I'll just say, OK, we'll go to chain ID base. And let's take USDC. So I'll copy this address. I will need it for later.

And I'll just paste it over here back in my code editor as a string. So that's USDC. Now, you might have picked a different coin. That doesn't matter. And let's move this.

Let's swap it into Bera. So let's move the USDC that we have to Bera chain. So for that, let me just go over here and do another search. Bera chain, here we go. And I'll just skip the address because I'll copy it here.

So there's the Bera token. And of course, it's the native token, so it's got the E address. And let me paste that over here. So now what we want to do is actually create a new instance of the ENSO client. So it's just new ENSO client.

And we need to pass two things. Well, the base URL is not really necessary, but we need to pass the API key that we got previously from the dashboard. So I'll go back there. And let me just copy it from here. And yes, I know this is like a big no-no, but I'll paste it because this is a workshop and I'll reset it later.

All right, now that we have that, what would we need to do? Like this is a call for discussion. What would we need to do to achieve this regularly? What would be the steps? Come again?

Validation of? Yeah. But without ENSO, what would you need to do to achieve this? Yeah, as a user. So think of yourself as a DeFi user.

You would need to bridge. So to bridge, how would your process look like? Go to the bridge, connect the wallet, but which bridge? Sorry? Yeah.

So there is a little bit of thinking that people need to do there. And I jumped straight into code. We'll come back to the UI later. But let's see how to do that with code. So this would be get route data.

And in here, I need to pass an object. And this is pretty much what we need to pass. So there's amount in and let's make it this much. The chain in. So we said base.

So that's B-A-S-E. Destination chain ID. We want it to be on Bera. Now I need to copy this one because I don't know it by heart. There we go.

And the from address. Well, we need some sort of address. I'll copy one later. What we also need is token in. And that's our USDC.

Token out. And there's a couple more parameters that we need to specify. There are sensible defaults. So I'm not going to specify all of them. For example, yeah, we'll come back to that one.

I want to make this as fast as possible. So let's just to find a quick address to copy to. I will actually go to the examples here and just copy this one. This is Vitalik's address. So we can pretend we're him.

And that's pretty much it. So I'll just say route is whatever we get from this response. And to see what's going on, let's do... I'll stringify it and make it humanly readable. If I'm not mistaken, this is enough for us to test it out.

So I'm going to do node index.js. And this should run it. All right. So we get an API error because I forgot that when you do cross-chain, then you need the receiver.

So here I'm going to say, well, receiver. And let's do the same address on bearer chain. That doesn't really matter. And it must be an Ethereum address. So now when we run it, it does some stuff.

There's a lot of hex over here. That's the bytecode that makes all of this possible. But here's the interesting part. So this will show you the route that is happening in there. So it does bridging via Stargate.

And it's taking in... Well, this is the original USBC and the native token. And the token out is USBC, right? And then when the bridging is complete, we also need to do a transformation of whatever we got on the output to the bearer token. So this is the thing that we didn't express in the intent.

So here we just said take token and transform it into bearer on bearer chain. But there's also swapping that's happening after the asset gets bridged. We cool with that? We're not cool with that. Could you pass the mic, please?

Oh, you've got one. I just... With the first bridge, you started with an ERC20. And if you're going to wind up with an ERC20 on the next chain, you're not going to have the gas to do the final swap when you land on the next chain. So what would you do?

Or what happens in that case? Let me ask you. What do you think? Well, I would think you have to swap first to native token and then bridge native token. Then you have it.

So I would expect to see swap first followed by bridge. Okay, let's check out what these tokens are exactly. So the A33, that's our USDC. And this is the native token that also goes to Stargate. And the token out is 549.

Let's see what this is. So it is on Vera. And the address is exactly what I copied here. So it's a USDCE that we got after the bridging, which got swapped into Vera. Yeah.

I'm slightly puzzled as well. So the Vera you're getting is the native token? Sorry? So the Vera that you're getting is the native token? Yes.

Yeah, and this is executing on Vera. Who is executing the swap on Vera? Who is executing the swap on Vera? So this is not explicit. Over here, so it's not naming a protocol, it's one of the DEXs that are registered with ENSO within the aggregators that we rely on.

So we could find that out if we took this and actually simulated the transaction, so we would definitely see what's going on in there. That's the best I can give you now. Any other questions? Okay. So now that we saw that, let's see what's happening in the UI, because where's my first challenge?

Here it is. So you remember from not there. Yeah, here. We also mentioned there's happy path. So let's do the same thing visually.

So here we're going to pick base, and we set USDC, right? So there it is. And we're going to take it to bearer chain, and we want bearer token, right? So now when I enter, let's say, 10 USDC, what we have started is bridging it to USDCE and then swapping into bearer. So it's pretty much the same thing.

This is giving you a visual indication. So even if you want to quickly check out how something would go, you can actually use this UI to achieve it. And, of course, you can specify different slippage tolerance and stuff like that. So this would be the way easier part. That doesn't require any coding, but it's not repeatable.

It's a manual process. So if you want to do something repeatable or to create a UI like that, the route API that we just saw over here is pretty much all you need. Any questions? So this UI part, it was pre-created, right? This UI part is public.

We created that, and it's also an open source thing. So some projects actually built it in, in their UIs. So it's a solution that you can just paste and include it in your interface. Yeah. So it's like frontend blocks this part that you just showed?

Yes, absolutely. So this frontend is calling all of those APIs that we saw in VS Code. There was a question? Yes. So the question was if TensorFlow has something to get user balances.

So I'll just delete this one and get balances. The only thing that you need to pass is, well, EOA address and, yeah, I deleted it. Let me come back and pick it up again. So in the examples over here. Yeah, let's take this again, and let me come back here.

So the EOA address would be this, and use EOA, I'll set it to true. And chain ID, let's say one. So now when I run it. Oh, but it didn't catch it. And let's just console log it.

So JSON stringify balances null two to make it a pretty print. So the only thing we need to do is give it the address, say that we want to use the EOA and the chain we want the balances off from. And after a little while, there you have it. So you have like the complete information, what's the token, what's the amount, what are the decimals, what's the current price of the token. Yeah, what's the name of the token, the symbol, and you also get like the logo URL.

This is live, so these things happen. Any other questions? Okay. Where were we? So we saw that.

Now what we – I think we have time for one more example and then some questions. So the second challenge would be to do a cross-chain ZAP. So we just saw a swap, but what if I just want to enter a particular pool on a different chain? So if I have Wally on mainnet, how can I enter curves to a three-crypto pool? And here's three-crypto.

I'm going to copy the address, and, of course, these are the underlying for that one. And for this, I'm going to start with the UI first. So here I'm going to say I'm on Ethereum, and I'll paste this address over here. And for some reason it doesn't pick it up. Let me select the protocol.

Hmm. Yeah, I am – sorry, I got confused. We start with ETH. We want to get into the curve pool. So we're here, and the target token will be on base, will be curve, and will be three-crypto.

And this is why it didn't pop up, because it's a different address. So now when I do that and say one ETH – okay, let's try 10. And there we go. So it would bridge it, deposit in Serap Native, and then deposit into the curve decks. And, again, we can do this by hand practically with the route API, or we can do something a little bit different with the bundle API.

So I don't plan to repeat writing the get route code again. I would like to do an example that actually uses those actions that I mentioned, because we paid a lot of attention to them. Let's see why. Let's switch over to something more challenging. Again, three-crypto pool, but this time we have three tokens.

How can we deposit them into that one? What would we need to do regularly to achieve this? So I have 10 DAI, 10 USB-C, 10 USB-T on mainnet, and I want to deposit into that three-crypto pool on base. Yes. This is a discussion point, so everybody can – Just approve three times and deposit three times?

Or you could approve just one and deposit, and I think it will buy some of the missing tokens from the pool. That's a part of the solution, correct? But these tokens are on mainnet, and we want to put them in a base pool. Right, they have to be bridged. Three-time bridging, and then after that, three deposits, if you want to deposit all three of these.

Or you want to do some swaps in between or something like that. So if you have three tokens like this, the heavy path widget actually doesn't work because it accepts only one token. So we would have to do something like using the bundling. So you might remember that I said you can pick a lot of different actions and put them as a sequence, as a bunch of Legos. And if you came to the stand today, you saw that there were Legos over there, so there's something happening in there.

And this, what pretty much does – okay, this is a stupid example. It's got only one action. But you can put a lot of these actions, and it transforms them into a single transaction that gets executed. So I've got 20 minutes to create a bundle. Let's see how that works.

Get bundle data. Let me just rename this one and move this away. So what we need to start with – just a second. What's the first argument? I need my intellisense here.

So the first argument are bundle parameters. So this is like the basic stuff. Chain ID we're starting from. That's base, did we say? The second thing is from address.

I deleted it again. The third thing is routing strategy. Now, in this case, we didn't talk about this one. The routing strategy is actually super important, because in some cases when you use this router option, that means that you're signing with an EOA. So some things are not possible.

If you're using delegate, that means you're signing with a smart wallet, so 7702. And that's what makes it possible to put borrow inside of this one, for example. So for some actions, you absolutely must use bundle and must use delegate as the routing strategy. So I'll just put that in there. And, yeah, there's also some other stuff that happens here.

Receiver, I'm going to put it there just as a placeholder. And now the second argument is actually an array of actions. So our first action would be to bridge, right? And what we need to do is pick a protocol. So this is target, because currently ENSO does bridging only via target.

The next step would be arguments for the bridging, and that's an object. And here we have the token in, receiver, primary address, destination chain, and so on and so on. Let me just think for a second if we need to start with bridging. Yes, we absolutely must. And given we have 15 minutes, I'm fairly confident I will not be able to hit all those parameters.

So I will actually ask you guys, how would you like to use the following 15 minutes? Because I'm pretty sure you don't want to see me trying to nail Jason. Yeah. Go ahead. Do we get to start the questions from now?

Yeah, we can do the questions, and we can solve them via code or docs or verbally. All right. It's fairly different from those examples. I'm wondering if ENSO can be used for, like, maybe less defiant use cases, like maybe on-chain voting. Set up a context around it.

So how do you see it? So basically having the same benefits as, you know, using all these Lego blocks to build a voting application. So personally, I work at Claro, so we have a voting protocol. But I could think of other voting protocols that could benefit from using ENSO, for example. So you could have an application that submits proposals or creates questions.

Possibly in a cross-chain manner, actually. I think that would be quite useful. Okay. And how would that voting work? Like, I guess there would be a sequence that you want to automate as a single action for voting.

What would that consist of? Okay. That's quite Claro-specific, so I don't know if it's going to interest everyone here. In the case of Claro, I could imagine a useful building block could be to create a question dispute. That requires some fees that are going to be used to reward the participants in that question, who will vote on the question.

So there's a payment attached to the question. The question contains some metadata. And typically in the V1, it's on Ethereum, on this chain. But you could imagine an attraction layer that allows other applications on any chain, maybe on base, to send a dispute to be created on Arbitron or on this chain. That would be very good to do this with ENSO, for example.

Yeah, and how do you represent disputes? There's a JSON metadata that needs to be uploaded to IPFS. And then the IPFS CID is part of the parameters of the function. So theoretically, I see that possible, as long as you have actions that are abstracting those mechanics that are happening in the voting. So it really depends how you represent disputes, how you represent votes, and if any of these actions can work with that.

And these are highly DFA-specific, so I doubt that they're applicable. But the cool thing that's happening is that we're planning to open source the repository with these standardizations. Standards? So people can actually register their own custom actions. And then you can actually use them as little Legos to make those chains of actions and automate those voting systems.

So it might be possible in the near future to maybe create a PR in that repository and to add community-contributed actions? Yeah, that's the vision behind it, to make it open for community to extend. As of deadlines, follow our Twitter. Okay, thank you for the question. Could you just grab the mic, please?

Can the API key be in front-end code, or is it meant to be kept secret in the back-end? Ideally in the back-end. The thing with the API key, I mean, you are rate-limited. There's no signing happening with that. And it only serves to identify your front-end that's doing something.

In case you have several front-ends that represent your app, then you would need, well, to put it on the back-end to tell apart which front-end actually interacted with Enso, if that's important for you. Okay, go ahead. But again, there's no mutation that you do to the data within Enso. So from that perspective, you might even keep it in the front-end. But this is not the official advice.

So the bridge you were using in the example, is it a third-party bridge or your own? Yes, so this is a target bridge. And you might remember that when I was enthusiastic about doing it, I started with the target protocol, the bridge action. And let's just take a quick look of how that looks. So you would set the destination chain token in a mountain.

Somebody asked the question, can I have dynamic values in these bundles? Yes, you can. So you can say, use the output of call at one, and this is the call one. So you can actually pipe results of actions into subsequent actions. And so the actual question I was going to ask, that was a pre-question.

So I see a receiver there. Is it the receiver of the funds on the destination chain? Yes. And whose address is that? You can define it.

Sorry, could you get the mic, please? Because this is live stream. You can define it. So let's say, for example, you have your own wallet. You build an application.

And then that user wants to send the money to another user, for example. So you can actually set this. You can set it to smart account. You can set it to an EOA, whatever you define. And, like, if I want to bundle actions and do some additional action after the bridging, it probably wouldn't be my EOA address, would it?

Yes, it is. So, well, it lands inside of the ENSO account, like the ENSO smart contract. Generally, you don't need to set that. You'll see, like, there's an option, like you don't need to set it. If you don't set it, it'll go into the ENSO smart contract.

And then from there, you can decide what you want to do with it thereafter. But if you're signing with an EOA? Yeah, yeah. That's a good point. Yeah, yeah.

So, like, ENSO's got contract supplies in all these different chains. The funds will land inside of there. Whatever actions you have after will be, like, all done atomically as well. We don't control that account. It's just like an intermediary contract to be able to bundle all these calls together.

So, I could potentially take a look at this smart contract to make sure that only the stuff that I specified can happen to those funds, right? Yeah, exactly. I mean, once you make any request to ENSO – by the way, sorry for hijacking. If you want to cut me off, you can. No worries.

Everything gets simulated twice. So, once you make a request, we generate all the call data that you've requested to do all these actions. We run it on forks. So, we run it on, like, replicas of those chains to make sure that it all passes itself. So, nothing should be executed without making sure that it will pass.

So, you can check that and run your own simulation if you wish. So, you could use – we built an open-source simulator called Temper. It was used by Gnosis Wallet, Gnosis Pay, Gelato, Yearn, and Caswap. All for free, all open-source. You can run that on your site if you want.

Thank you. Okay, thanks for the questions. Any other questions? All right. There is a question.

Yeah, by the way, really good job on the workshop. I like your pace and the overall presentation. I got a question which is not maybe very much directly specific to the workshop, but generally since ENSO looks to be primarily focused on developers and you are a developer at ENSO, I was wondering what were and are the best practices for you in attracting the mind share of developers because we know there is a bunch of infra right now and the attention is very much gathered. Everybody is fighting for developers. So, what has been the most rewarding practices you guys are doing to attract the adoption and the usage of ENSO?

It is a never-ending experimentation. I do not have the best answer for anything. Maybe there was something that you did that was like, okay, this worked. Can I answer a bit? Yeah.

We shipped two products ourselves. So, we shipped a social trading product. We built a DeFi super app that builds some recognition in space. Then we realized all the problems that we have, everyone else does. And people reached out to us.

My language said, how the fuck did you integrate 50 DeFi protocols in day one? You all have the same issue. Here, use our API. The other thing that we found, we are like the first mover advantage. Two people are now copying us to do the exact same thing, which is really good for us.

They think it is not, but it is really good because they reach out to get people to use their API. And it was like, oh, but ENSO does this. ENSO has been around for so long. So, if you can somehow get people to become competitors, it actually benefits you indirectly. The other thing that we have done, sorry for hijacking again, is many applications.

So, Vercel, we copied Vercel, pretty much. The reason why Vercel took off so well was they built many products themselves and just open sourced it. Now, people can go to that and be like, Jesus, this ENSO team, Nenad built it. Dimitri and our team built it kind of in a couple of days. But this is a whole product that people raised millions of dollars for, and they just open sourced it.

So, this kind of, one, gives more ideas, and two, it gives more awareness of what you can build. And, yes, one is, honestly, hiring a BD as well. Before, I was doing it myself, and then we hired a BD, and that is kind of your part of every single conversation. But I think the biggest part was building products ourselves and showing how it can be used. Instead of a lot of these info products are talking about what it can do, but nobody shows you what you can actually build with it.

It's all theoretical, no words. So, this is the gallery of those products that we built, dogfooding our APIs and figuring out how to improve both the interface developers have to deal with and the way they work and how optimal they are. And I think that there was a couple of interactions with dev teams where they were like, it's already done. Like, in 30 minutes, they would actually be able to integrate and go along. For some of these, the actual heavy lifting, the DeFi stuff, was not that super hard.

The super hard part was the UI. So, that also speaks a lot. So, my point of view is do a good developer experience and show devs the power of it. That's pretty much what it boils down to from the DevRel perspective. The other thing we noticed is we just build stuff.

Like, some of our competitors, they just talk, blah, blah, blah, blah, blah. We just integrate the protocol. We send the protocol and be like, this is a really interesting thing. You know Privy got acquired, right? Yeah.

The founder is really smart. If you get in a call with Privy, what he'll do is he will show you how to integrate Privy in your application on the call. We do the same. So, we add your DeFi protocol before we even have a conversation. We get in a call and we show you how it works.

And that's like, you know, compared to other people that just say, hey, you could do this. We show you within the first five minutes and you're sold in 50 minutes straight away. Again, I'll leave it to you. Thank you. This is a panel which is also exciting.

All right. All right. We've got two minutes. Time for one more question. Oh, there's a couple of questions.

Technical one. I'm just saying they get balances, but I'm not actually getting any balances and stuff. Carter will help. All right. Yeah, go for it.

Could you please name one or two examples of the bundles which are most popular amongst your clients and what types of entities these are? Is it like Dexters? Is it B2C users? Yeah. So, the most popular ones, I didn't do the research, but looping is one that's mentioned fairly often.

Also, rebalancing as well. So, when you go to the docs here in the build section, there's a short test library. So, there's this smart routing examples, and there's also the examples of stuff people use Bundle 4. So, you get staking pipelines. You get leveraged positions, which is looping essentially, stuff like that.

So, you can explore what's in there. I don't know which one is the most popular, but you can get the sense of the most common ones and how to get started there. Okay. Thank you for your question. It feels like, yeah, go for it.

I'm not familiar at all with the cryptoeconomic side of how the network executes everything that you've seen in code. I just saw that there are validators. So, maybe from a defensive point of view, how do I know that someone is going to execute, according to my specifications, those actions? How would I know if someone actually doesn't, and what happens to them? Yeah.

All right. Connor? He's been in the conversation. So, what you did with the validators is like the decentralized network. Only today, we started phase one of the decentralization, so people can add to the network.

How do you know what we respond is going to give you what you ask for? One, we simulate it. Two, we give you all the call data. Three, we give you each step-by-step. And we open-source our simulator, so you can run that yourself to double-check, or you can plug into Tendril API, for example.

The other method that we're doing, whenever other validators come into play, because we're the only people right now, why we do that. One, just faster to market this idea, blah, blah, blah. They will have modules inside. It's like a shared library of, hey, I want to inspect this call data for any delicate calls happening, any approvals happening, any transfers to accounts that weren't asked inside of the request itself. It's kind of like a checklist itself.

I would say, to be honest, the safest way of doing this is simulate it on your side. You can trust us, because we've not lost any money so far. But again, the back-end being hijacked is a risk. We simulate, you can run those simulations yourself. We don't ever execute, by the way.

I just realized that. Yeah. You give me the call data, then I need to make sure before I execute messages. Yeah, yeah. A lot of people, we give you all the response data.

They use that to present to the users. There's a bit of trust element inside there, but proof is inside the pudding. We're not going to take the funds, right? You can check this step-by-step yourself. Thank you.

All right. We're a bit overdue.