Liquid Apps for a Connected Onchain Economy

Transcript

Hello. Yeah. Hi everyone. Uh the toughest time uh to attend a conference talk just after lunch. So, I think all of us are blessed to kind of look at a very boring presentation while our body is refusing to, right? So, I will try to keep it as interesting as possible. I will try to stick to my points and hopefully at the end of the presentation there will be some takeaway which uh would not lead you to sleep. So, I'm Prabal. I'm from Avail. And today I'm going to claim that if you have ever, you know, built a blockchain application, you are losing your users by the second.

Um every application that you've ever built on blockchain rails uh have been artificially limited in the amount of scale and in the amount of attributable market that you can reach out to. And we are going to introduce the concept of liquid apps where we think that on-chain economy should be fully connected with one another and users don't have to worry about which chain this app is on and so on. I will try to uh go through that, but uh firstly, I'm Prabal. I'm one of the co-founders of Avail. At Avail we are trying to, you know, bring the next level of scale and interrupt to blockchain ecosystem by building the essential tools to make it

happen. Before I make those big claims, I think I would like to start with a simple story. A story which probably all of us could be relating to. And hopefully you guys would, you know, go through the story with me. Let's assume that you have an application, any DeFi application. Just I have made up this name Nextlend, right? Like you go to this application, you want to try that out. The first thing you realize is that you don't have sufficient funds on that Now, that might be any app on any chain, but it doesn't necessarily mean that you have funds on that exact specific token that they would want you to deposit. And so, the first primary blocker becomes

that I don't have enough funds on that chain. And that is okay. We are kind of used to that by now. What do we do? We don't worry. We go to a bridge. A separate application where I go, I pick up a token, I pick up the source, I pick up the destination, I pick up the amount, and then I approve. I wait for the bridge to take place. And then finally, when I have that asset on the destination chain, I realize that I don't have enough gas. I don't have enough gas to pay for the transaction fees on that chain. I have enough funds.

So, I'm not, you know, poor enough to not have to pay a few cents of transaction fees. I it happens to be that I am not in the right token and the chain that I want to be in. And so, you go on the wrong asset, you go back, you do some other things, you go to gas.zip or any other uh website, you finally get your gas. And then you come back and you realize that oh, you thought it is, let's say USDC or USDT, but it happens to be a some variant of that. Let's say it's USDTO because that chain allows special wrappers of stablecoins on that chain. Now, you have to go through the cycle again. You have to go to a DEX,

swap the token, and come back to that application. And this is what applications developer are also facing, not only the users. Think of the application developer who has put their mind and soul into building this app. This is the user experience that they're having to give by no, you know, role of their own. And I don't need to convince you, right? That this is messed up. Uh user retention is a metric which uh every blockchain application is facing to be getting lower and lower every day because, you know, we are we are kind of violating we are violating the first rule of SEO and analytics of websites.

That is, if someone lands on your website, don't let them leave. But if you think about it, the first thing that we ask them is to leave this application, go to some other application, get the stuff done, and then come back to this application. So, this is the this is the uh you know, flow today. And this has to fundamentally change. This cannot go on. We are living in a times where there are, you know, hundreds of chains that are out there, thousands of protocols across it. And if this is the state of affairs in this ecosystem, then uh this is going to be extremely fragmented.

And so, for an application developer, when they start their journey, the first question that they need to ask themselves is that which chain to build on. Now, suppose I'm building a DeFi application. I want the biggest TVL to be able to attract to my app, right? And I wouldn't want to go to some other chain which doesn't have enough liquidity just because they have better developer tooling or because they have incentives. But those are also real problems. Like I if I am a very small indie dev, and I go on to some of the biggest chains, maybe they will not support me. So, now I'm making having to make a critical choice, a choice between developer support tooling and ecosystem benefits versus the ability to attract

volumes, to ability to attract liquidity, and so on. And this is what is bothering us. This is what is, you know, creating a problem across the ecosystem. Let's assume that the developer chooses Arbitrum, and it could could have been any other chain, but let's choose Arbitrum. This is the total TVL of Arbitrum as of few days back, I guess. And then this is the rest of the Web3. And this is the choice that they have to make, a 100X difference almost of what could have been your TAM versus what is your TAM.

If you do not if you care about user retention, then this is the problem, the dilemma that you are facing every day while building an application. And so, if you attended many of the talks that are, you know, very very big DeFi applications giving talks all across uh this venue today and through the next of the rest of the uh event, you will see that they're all having to struggle through this conundrum. Like whether I deploy to more chains. I was attending the last talk by Alex of Aerodrome and and they have been deploying to multiple of these chains.

They have been trying to deploy to 12 plus chains. And that is an effort that not every developer can take. Developing concurrently on multiple smart contracts across different chains and synchronizing them together in order to not create an arbitrary leak of assets or value or an audit scope is not something every developer can partake. And the other option is, do I integrate bridging products? Do I just have a widget? Then there are like many many, you know, bridging products that are out there. You integrate one of those widgets, you allow users to use their applications within your app. And then, you know, you you get the funds in so that in an in an attempt to not let the

user leave. And this is what we want to solve. We want to allow users and allow developers to create liquid apps. Apps which we call liquid are the ones which do not ask their users which chain they are on. They do not ask their users whether they have the funds in the correct denomination. They don't ask their users whether they have this, you know, crazy wrapped stablecoin that is, you know, that you need on your application. They just ask the users, do you have enough funds?

Right now, we are, you know, we are talking about Avail Nexus where we don't not only allow, you know, users to deposit on-chain assets, we're very soon going to expand that and talk about, you know, traditional rails and how users can be coming from traditional rails to on-chain rails as well. Because that's what we want. We want a connected on-chain economy. This ecosystem that we are building, the entire community conference that we are hosting, will be very limited if we cannot build the next set of financial tools on blockchain rails.

And so, what is Avail Nexus? It's very simple. On its on its outset, it does few things, and it tries to do these few things very well. It supports many many chains. We have 15 plus chains today, but every week it's expanding. We have N to one liquidity provision. So, irrespective this is not a one-to-one mapping. So, you don't need to think about whether I transfer from base to Arbitrum or from BSC to Arbitrum and so on. That is not the point. The point is, can you, you know, take aggregate assets across all the chains and bring them here together?

That's what we want to build. And then, where does this does this sit? This sits within an SDK inside your application. You don't need a separate, you know, uh bridging portal. You don't need a separate UX. This can be completely inclu- included even inside the balance that you show of the user. We want to show a unified balance, a balance across all assets, across all chains inside the ecosystem. I think we have talked enough. And one of the things that we do a lot on this conference is is to talk uh to talk about promises that we will deliver in due course of time.

And I want to skip that and show what is possible today. And we have already launched something that we call as Avail Deposits. I would just like you to go through the flow of how a deposit looks like. So, let's say I create a deposit widget on any contract. We have taken Ave. And I want to, you know, deposit multiple different assets. It just goes through the flow. It takes assets from multiple different chains and multiple different denominations. It takes the intent. It collects from different sources. And then it deposits directly into the contract call on that application. So, this entire thing we collect on at least two different sources across two

different assets is what we show here. And we do a deposit transaction. And the total fees is, you know, what fees do we accrue across the transaction fees, the protocol fees. And uh the the different solver fees that are involved in to enabling this. And so, all of this is baked in within the same deposit widget. You don't need to go out. You don't need to worry about which chain and which asset. This all gets converted directly. And get deposited. As well as executing any arbitrary functions of the contract.

I think I discussed a lot on, you know, what. And I don't think I will be doing justice if I don't talk about how. So, I'm going to, you know, quickly gloss over how do we enable it? Because I think it's important to understand like what are the what are the technical, you know, nuances that go into building uh a plugin like this, an SDK like this. So, what we have is we have support for all these chains and more. And let's assume that we take these chains and and the user has funds across five of them.

I cannot show this. This is a wipe code and architecture diagram. So, don't, you know, blame me if there are, you know, problems here and there. But, there's this wallet. And in the wallet, I have different amounts at across different asset classes, as you can see. And I want to go and use an application. Let's say that this application is on Ethereum and needs Ave token. You can talk about any ERC-20 that is out there. I chose Ave. Um and then the normal flow is like you go and try to deposit on this app, but you face the issues. The issues are that you don't That That app is on Ethereum and your assets are not on there.

The assets that you want to send are the wrong token. There's not enough, you know, uh transaction fees. There's, you know, insufficient balance on this application. So, this is the conundrum with the normal flow. And how do we do it with Ave Nexus is that we have deployed vault contracts on each one of these chains. On all the chains, there's a lock contract which allows people to deposit assets of their choice into the vault contract. But, of course, we cannot be taking up arbitrary assets because the solver might not support arbitrary assets.

Not only that, those arbitrary assets might not be supported in the destination chain. There are so many assets today which are only available on a few of these chains. And it is on the responsibility of the application developer or the user, worse for the user. Uh but, it's on them to go and swap it and transfer it and then go and deposit it. So, what we do is we take those assets. We swap them. We swap them into generally a stable coin or a native token which has deep enough liquidity on the destination chain. In this example, we take USDC. So, we swap all the incoming assets on those corresponding sources into something like USDC.

This locking is what is, you know, looked at by the solver. The solver comes in and gives those funds through the destination deposit vault contract. And from that, of course, I cannot deposit USDC. That was one of the main problems on the destination app. We go ahead and swap it. We swap it and then we go ahead and deposit it to that application. And this is how, roughly speaking, we enable. Of course, there's a settlement phase. The solver needs their money back. Once the vault has confirmed that the correct denomination and the correct amount was deposited on the application, that is verified by the Ave Nexus vault.

And then the funds are transferred to the solver which they are due off. And this is, roughly speaking, I have, of course, not talked about many, many different deltas of how this is enabled. Things like ephemeral wallet support, 77024337, and the host thereof. There are many of them already baked inside the protocol. But, all of this goes inside the back end. The application developer don't need to worry. And um all of this happens in a matter of a few seconds. So, this is, roughly, the architecture. I I've been said that, you know, I'm already out towards out of my time. And we are not, you know, only talking about this. There are already integrated apps already using us. There are ones which

are many, many more are coming inside the pipeline. If you are a developer, you know, let's talk. Let's talk about how we can elevate the UX because UX is one of the biggest barriers on of on-chain adoption, we believe. And if you're a user, we can also have some tools and portals that we can point you to where you can get you know, seamless UX when entering newer ecosystems and newer chains. And if you're a developer, there's a Nexus SDK. This is a headless SDK. So, you know, all of your existing, you know, um thematics and such can be quickly integrated. It will not impact your branding or anything else. The You have UI elements. If you want us to

handhold you, there are, you know, UI elements that are out there which are React-based. And I am guessing many of us have are using React-based infrastructure. So, go ahead and just plug and play the code and you will have a deposit widget working. The API is coming soon. We are, you know, supporting back-end apps to also be able to use Nexus. And I'm not foolish enough to believe that we are still writing code by hands. And we don't assume people to do it also. So, of course, there are, you know, SDK skills and elements skills pack that we have. Just add those skills. Ask the Ask the coding agent to do it on your behalf. And without much problem or guidance, you will be able to

do it on yourself. If you face issues, definitely reach out to us. And yeah, let's talk more. If you are building a DeFi application, remember you are being artificially restricted towards, you know, expanding to multiple ecosystems. It should not be a roadmap item. It can be integrated today across multiple different ecosystems and asset classes. Thank you. I guess we have 2 minutes to take questions.

Uh so, does the the system asynchronous when you have to unlock the funds to the solver? Or is it synchronous and you have to wait uh the the end of the transaction on the app? So, the waiting is for the solver. And so, the solver waits. The solver has to wait tens of minutes. Because there are, you know, uh problems that you take when you do the fast path. The fast path is for the users. So, the users are giving the money as soon as possible. But, for the solver, we have to work for the reorg limits. We have to work through the transaction confirmations.

We have to work through confirmations from across different chains and so on. And that takes a bit of time. Uh I would say roughly 5 to 10 minutes is what it takes for the solver to receive back the funds. For the users, it's a matter of a few seconds, as you saw. Okay. Okay, thank you. Thank you. Thank you, everyone. Well well