Resource-First, Chain-Second: Designing Tomorrow's Cross-Chain Apps

Transcript

[Music] Hello. Good morning, everybody. Uh, I know it's early and we're halfway through the week, so I'm going to take it a little bit less technical than some of the the presentations beforehand, but still dive into some of the interesting things that we're working on uh over at One Balance. So, I'm here to talk to you today about designing tomorrow's crosschain applications and doing so in a chain first, resource first and chain second manner. Where's the clicker?

How do I go to the next slide? Cool. Thank you. Hold it a bit closer. Okay. So, who am I? I'm Daniel and I'm the co-founder and COO here at One Balance. But before I was at One Balance, I've spent a lot of time building in the crypto space. My first project that I co-founded was a consumerf facing application called Local Coin Swap, which is the largest non-custodial peer-to-p peer exchange. From there, I first found all of the user frustrations that exist when trying to build on chain. Things like users having to manage gas, users having to manage assets distributed across different chains, and all of the pain and suffering that goes with this, trying to

onboard new users to this onchain environment. From there, I started diving more into the infrastructure space. So I spent some time doing MEV trading, arbitrage and liquidations across a range of EVM chains. And then I spent some time at Flashbots leading the operations side of the organization, but more interestingly helping with the launch and adoption of MEV boost uh leading up to the merge. Uh for those of you that aren't familiar, MEV Boost is one of the core pieces of infrastructure that powers Ethereum today with over 90% of Ethereum blocks processed through Flashbots's designed uh infrastructure.

So let's take a step back and think about the world that exists today with with onchain and off-chain within crypto. So we're seeing more and more that onchain is fast outgrowing offchain. And the reason for this is there's just a huge amount of opportunities that exist in the onchain space that simply cannot exist offchain. We look at the world of tokens that exist. So, if we look at centralized exchanges, custodians such as Coinbase, Binance, and all of the custody providers for the other centralized platforms, they support less than 1,000 tokens. Whereas, if you look onchain, there's over 14 million tokens that exist. Uh, and the reason for this is that it's easier than ever to spin up and deploy a new token. With platforms

such as pumpf fun and unis swap, you can instantly get your token in front of millions of people. So we're seeing more and more that institutions, platforms, fintexs, web 2 and sort of finance platforms that have users are wanting to give their their users access to this onchain environment to give them access to these opportunities, access to stable coins, access to yield opportunities that don't ex that don't exist elsewhere as well. So there's a problem though and that problem is that we have an infrastructure issue and this is causing onchain UX to be fundamentally broken.

So let's think about a regular crosschain transaction today. So you're a user. You have a funds funds on one chain and you want a different asset on a different chain. So what do you have to do? First you have your asset. You need to find a bridge. You need to think about the trust assumptions that exist in that bridge. Then you need to initiate a transaction to the bridging contract. Now you need to pay some gas fee probably in a different asset than the one you're actually sending. Then you need to wait some period of time. Maybe this is a few minutes, maybe it's a few hours depending on the bridge that you need to use. After this, you your transaction lands on the destination chain, but this probably isn't the asset that you want. You've probably bridged Ethereum or USDC or some stable coin,

but maybe you want to buy a memecoin on the platform. So then you need to find another DEX. You need to figure out which decks you want to use, make sure it has liquidity, make sure it has good pricing, and then you initiate a transaction, and you're sort of at the whim of the MEV traders and the sandwich traders that exist. Hopefully, you get good price execution and finally you have the asset that you want. And all of this is a sort of function and a relic of the fact that we've been designing for chains instead of designing for resources. And given the history of blockchain when we had a few chains and applications launched on a single chain, it made sense, but it no longer makes sense anymore. So, we need to start designing for resources or start designing around the assets that the

people want to transact with rather than the chains that people are transacting on. So let's step back and think about a general user goal. So you're a user, you have USDC. Let's say this USDC is on Ethereum and you want to buy another token. Uh let's say you want to buy Penu token which is on Salana. So the general pain points that you're going to go through is like first finding a DEX, then figuring out all of the gas um the gas, then you might have to pay gas on two different chains. You might have to wait a bunch of time for your funds to be bridged from one chain to another. Uh you're probably going to have to use multiple wallets because all of these wallets have different deposit addresses. Um and this is just overly complex. You know, for a user that has a

simple goal, there's a huge amount of pain points uh that exist when trying to perform just a simple action. So I believe that all of these problems are born from chain first thinking and they can all be boiled down to these five points. So firstly we have bridge latency. If you imagine the time it takes to bridge from one chain to another often this is you know minutes. Yeah we've made it a little bit faster but it's still not instant. It's still not a web two like experience for users. Uh following this we have transaction reliability. And this is a big issue especially for companies like fintex that are used to providing one-click instant execution for their users. I

don't know how many people here have initiated a transaction and had to had it revert. You've even had to pay gas fees when that traction transaction has reverted. And it's like increasingly frustrating to pay for a transaction that doesn't execute to then have to go and pay for another transaction in order to actually get the asset that you want. And by that time, the price has probably moved. So, we have cost unpredictability both through transaction reversions as well as through the hostile ME actors that exist on chain. I don't know if anyone has ever had uh Jared from Subway eat their lunch um and had, you know, received half of the token, the output token that you were looking to get when trading on a pool such as unis swap. But this is a real problem for many users on chain that are that are trading today.

And then in addition to this, we have the issues uh like like asset fragmentation. If you have USDC, you might have that USDC distributed across five different chains. Um, and then you have to figure out how to aggregate all of those different USDCs into one USDC so that you can then buy the asset that you want that might be on a sixth chain. And when you go through this whole process, you also probably have to manage different gas tokens on each chain. You need to somehow get gas to all of those chains and then get the assets to the chain that you actually want. So all of these problems are due to the fact that we have initially and continue to design around chains rather than designing about around the assets and resources themselves.

So let's think about these first three problems. And I'm here to tell you that I believe we can solve for all of these using this new primitive uh called resource locks. So what are resource locks? About a year ago, we've been we were doing a lot of research around the transaction supply chain and really thinking about like what is the best solution to solve this instant interrupt problem to give users the web two like instant experience that they want to do so in a non-custodial way and to do so in a way that is VM agnostic. So not just on Ethereum but you can launch this on other VMs Salana Bitcoin and things like that too. Um and we wrote a white paper we we published it on ETH research

talking a lot about resource locks and really setting the stage for the next wave of applications that are being developed. So the best way to think about what resource locks enable is this. Resource locks enable crosschain transactions to execute at the speed of the destination chain regardless of source chain finality times. Um so this is kind of complex. So let's kind of think about this in the context of a intentbased or solver executed crosschain transaction. So the anatomy of one of these transactions today is you have a user that wants to get an asset on a on a different chain. They initiate a transaction to some escro contract or perhaps directly to the solver depending

on what kind of of protocol they're using. Then once that track trans transaction is confirmed has a sufficient amount of of confirmations or has finality depending on on which protocol we're using the solver will then go and execute the transaction for the user and give them the assets that they want on the destination chain. So there's this sequence of transactions. You first have the origin chain transaction then once you have confirmation then you have the destination chain transaction. So what resource locks allows us to do is it allows us to paralyze these two transactions. So instead of first waiting for inclusion, the solver can go and execute the transaction on the destination chain instantly without even waiting for inclusion on the on the origin chain. And the reason for this is that resource locks unlock two things

for the solver. They give finality protection. So protection against a reorg on the origin chain. Uh they also give equivocation protection. So this is protection against the user going and like withdrawing their funds from from the account or from the escrow and like sending it somewhere else after they receive the funds on the the destination chain. And the reason we can do this is because resource locks allow us to apply a lock over the state of a user's account while the destination trained transaction is being executed by the solver and it gives these two two forms of protection to the solver so that they know they can be p repaid.

So in a crosschain setting we generally have uh an an input state and an output state. So going back to the example that we gave before the input state would be the USDC that the user has on the on the origin chain say Ethereum and their desired output state is Pangu the token that they want to buy on Salana. Now we can bundle these two things together. We combine the resource locks giving the finality and equivocation protection to the solver with the intent. And we have what we like to call a resource lock intent which is a resource lock plus an intent plus an oracle which allows us to bring which allows the solver to bring proof of execution on the destination chain back to the origin chain to retrieve the funds from the resource

lock and be repaid for their their execution of that transaction. So, I think it's interesting to take a step back and look at the history of bridges and the history of sort of crosschain interop and and how we got to where we are today. But before we do that, I know everyone's a bit tired from last night. So, I want to have a quick show of hands of who has interacted with more than one blockchain in the last month. Okay, it's about threequarters of the people here. Okay, now who has been frustrated with their experience dealing with more than one chain?

Okay, I'd say about 90% of people who who originally had their hand up are still feeling the frustrations of this. And let's sort of look at the history of like where we started, where we're at today, and like how we can go a little bit further into solving this problem. So when we first started building L2s around Ethereum, we designed a canonical bridge or a native bridge. And what is this? This is a deposit contract that allows you to deposit your funds in on Ethereum. Then after we have finality on the origin chain, the funds are then minted on the destination chain. So finality on Ethereum takes around 13 minutes. So you deposit your funds and at the shortest time you'll have your funds on the destination chain in 13 minutes. So this is still a pretty crappy user experience.

Then we said, okay, we want to move a little bit faster. We want to we want a faster way to sort of interrupt funds between these chains. So we designed message passing bridges. So things like layer zero. And with layer zero, instead of needing to wait for finality on the origin chain in order to have your assets on the destination chain, we now only need to wait for optimistic finality. So, you know, this could be 1 to 2 minutes if you're transacting from Ethereum to another chain, which is great. It's better than 13 minutes, but it's still not the sort of single click instant experience that people are expecting if we're trying to bring normal users on chain, uh, not just sophisticated web 3 users like ourselves.

So, then we said, how can we get a little bit faster? How can we create a better experience for our users? And that's when we started designing intent bridges. So things like across and the great thing about intent bridges is we no longer have to wait for finality nor do we have to wait for optimistic finality. Now we only need to wait for inclusion. So generally like a single block inclusion on the uh origin chain and then a solver is willing to go and execute that transaction on the destination chain and take the real risk themselves. So generally this will be sort of one to two blocks and you have your transaction on the destination chain. But again if you're transacting from Ethereum this might be 13 26 seconds before you get your funds. Much better than the canonical or the message

passing bridges but still not as good as the one-click experience that we really want to build to bring the next billion users onto web 3 today. So how can we get even faster again? Well, this is where resource lock bridges unlock, no pun intended, this sort of web two uh one-click experience for the user. And the reason for this is that we only need to wait for the signature rather than waiting for inclusion, rather than waiting for optimistic finality or rather than waiting for finality on the origin chain. So a single signature from the user on the origin chain, the solver can then go and give the user the funds on the destination chain that they desire. And the resource lock provides this equivocation protection um as well as this finality protection to ensure that they're going to be repaid after

they provide execution proof. So in essence, resource locks are optimizing for three things. They're optimizing for speed, cost, and reliability of crosschain transactions of sort of solverbased intentbased crosschain transactions. So solver it users generally have like a simple action they want to they want to um experience. So they have a assets on an origin chain. They want some kind of asset on a destination chain. They want to do this in a single click with no reverts and have a sort of cost effective and reliable transaction.

Under the hood there's a lot more going on. So we have this this chart here where we look at the sort of resource lock then we look at the intent and then we look at the execution and bringing proof of that execution back. But the core thing is that this happens all under the hood and the user doesn't have to understand or like what's going on that all they need to understand is that they're receiving the funds instantly on the chain that they want. So if you want to learn more about sort of resource locks and what happens under the hood, uh I encourage you to come check out our documentation, come chat to us afterwards. Um it's exciting what we're building and and definitely a lot more to to dive into here outside the scope of of this talk.

So as I mentioned we have these sort of three barriers first three barriers to onchain adoption uh that are solved by resource locks but we have these other two we still have this issues of asset fragmentation and gas management in a case where you have this instant interrupt provided by resource locks. So how can we solve for these as well? Well, at One Balance, we've put together the One Balance toolkit, which is a toolkit powered by resource locks that also gives all of the functionality of of chain abstractions such as asset fragmentation, uh, solving for asset fragmentation, solving for gas management, and abstracting all of this away from the user in one simple to integrate toolkit.

So, think about apps today. Again, most apps are built on a single network. So, a single chain. you you launch an app, you have a smart contract, you connect it to some RPC to allow users to bridge funds in uh to deposit funds in and then you want to launch on another chain because we see the next the next big hype wave. So now you need to implement another RPC. You need to redeploy your contracts on another chain and oh no, now you need to give your users a way to bridge funds from one chain to the other. So you go and find a bridge, you implement the bridge, then you realize your users don't have gas on the on the destination chain and then you got to figure out a way to give them gas. So maybe you abstract that away from them.

you set up a pay master to start paying for gas for your users, but you've already implemented now like four different tech stacks in order to give this kind of chain specific experience to your users. So what if what if there was another way? What if you could just integrate a single toolkit that abstracts all of this complexity away from you under the hood? So you can build on one balance. You can have all of the benefits of one-click experiences across any action chain or token. Um and this is both EVM and nonem compatible. Right now the toolkit is built for super apps, fintexs and AI agents and we're sort of increasing the capabilities to serve more of the crypto space uh shortly.

So a lot of these features we talked about already. We talked about resource locks providing speed, cost, and reliability. We work with many wallet as a service providers. So you don't have to reinvent your stack if you're already using privy or turnkey. You can use all of the great features such as authentication, social login, uh and not have to migrate away from a different stack. And with the one balance toolkit module, you can receive unified balances for your users. You can show those five USDCs across different chains in a single USDC balance. Allow them to spend it in one click. Allow them to spend it in a way that's completely gas abstracted. And more excitingly, you can also charge fees in an abstracted ways for your user. So you can charge the fees in any token you want. You can charge all of their gas fees in USDC,

for example, and then you can take a clip of that fee in in whatever mechanism you want as well. And all of this with sort of full token support and front running protection as well. So we've built this in a modular way to support any chain action or token. Currently we're live on Ethereum and a bunch of EVM chains. We're launching with Salana in the next 2 weeks. And we've also built a proof of concept on Bitcoin, which is really exciting because I believe this is the first iteration allowing people to hold native Bitcoin, not some wrapped version of Bitcoin, and instantly execute transactions on other chains using resource locks over the native Bitcoin that's in their account. So, this is a huge opportunity to unlock the biggest liquidity source that exists in all of crypto and bring it into DeFi, which is something that a lot of people are

trying to do with layer 2s, but it's a little bit more uh sort of one step away from the user experience that people want to really hold native Bitcoin and spend it on another chain. So, as I mentioned, it easily integrates with your stack. No need to migrate away from your favorite wallet as a service provider and simply upgrade your stack with the one balance toolkit uh and provide your users with this chain abstracted experience. In addition, we've recently launched a MCP server to allow you to more quickly build and focus on building the user experience rather than building all of the infrastructure and all of the chain specific stuff that goes on under the hood. So you can plug this in with Claude or Cursor or your favorite IDE and start coding focusing on the user experience and outsourcing the the onchain execution uh elsewhere.

So, if you want to build one-click user experiences across any chain, action or token, uh check out the one balance toolkit. Uh check out our documentation. Come come reach us after this presentation and let's chat. Thank you. We have time for one quick question. Questions? Okay, it seems that there is no question. Thank you very much. Thank you. [Music]