Speedrunning chain abstraction EIPs by Ankit Chiplunkar | Devcon SEA

[music] 75. Hello. Hello. Hello. Am I audible?

Um, this is this is supposed to be like a 90minute thing, but uh the idea is to speedrun it. Um the core uh objective of of doing this workshop is basically just explaining the the grand vision of what we mean when we say chain abstraction. Um and then digging deeper into more technicalities about what are the different EIPs or ERC's across the stack uh that would help um you accelerate or or or give the chain abstraction vision to your to your end users. uh one way how I describe chain abstraction is if you are an app developer then uh removing the word chain bridge and gas from the user journey altogether is is the final end state of how how uh I see chain abstraction and so um if you're an app developer and the user does not see those three words anymore they just go to your app click a button and get the execution they want is the eventual end state uh that we imagine as as As uh the MC already told uh I want this workshop to be more interactive. Uh feel free to just stop me, raise your hand.

Uh we can have we can have questions, we can have like a Q&A session. Um uh there there are a bunch of ERC's that have their own like historical context and more technical depth. I won't I won't go into like a lot of historical context and technical depth, but the core idea is just to explain like what it tries to achieve. Um and um we won't get we won't get too much into the nuances but like how it takes you closer to to the desired end state is is is uh the objective of the workshop. Um okay so a few few things this is like the outline.

The first thing is I just want to talk about the blockchain cake or how we think like what are the different actors or different layers in the blockchain ecosystem. uh then like what are the ERC's that interact on the permission layer what are the interact ERC's that basically are required between the DAP and the permission layer so permission layer is more like the wallet and so the DAP and the wallet layer what are the ERC's that that you need to basically communicate between these two entities uh and then what are the ERC's that are needed to communicate between the permission layer and the solver layer so like the meool layer and then what are the ERC's that you need to communicate between like the solver layer and the settlement layer we'll get deeper into like what each of these these terms mean but this is just like the broader context. Um and so like the first first uh section is just about explaining like what are what is the grand vision of what we are trying to do. Uh this is something that I call the United block spaces of Ethereum. Uh if you think about the last bull cycle uh everything was amazing like you had the D5 summer you just went to an app you clicked the button you had the thing that you wanted you you went to Yam Finance you clicked the button you were able to deposit into this D5 ecosystems and everything was super smooth.

The only thing was you were paying $100 for for a transaction. And so after that this rollup ccentric road map L2centric road map sort of emerged and um it was a solution to this like block space is becoming costly problem but it has created a fragmentation problem and so um the L2centric road map has brought us many block spaces some block spaces are red in color some block spaces are blue blue but um they all commit data to the Ethereum L1 but they don't feel like they don't feel like United just too much fragmentation. Uh if you just look at like the UX that you are giving to the user right now you have um you have three different types of Ethereum. If you if you open like your Coinbase wallet, you have three different types of Ethereum. It just causes a lot of friction to the user.

Whenever you try to change your network, it just pops up and says, "Hey, do you want to switch your network?" And then the user like has to go and and then click another button. And even if you want to transfer funds from one chain to another, it's like you go to an aggregator and then you send those funds to some other uh other location. Uh you you like have these different options where the user can choose between time and cost. And and it's it's a very like buggy uh and uh frictiony experience for the end state.

And this is this is why it does not feel like uh united block space like if you if you're imagine if you're living in the United States and every state had its own version of US dollar and you had to convert when you're moving to one state to to another in its own version of US dollar then it won't be as as smooth a UX or when you were moving from one uh state to another and you had to basically get a visa stamp whenever you move move from one state to another it was it would not have been uh as united and so this like if you solve these problems then the Ethereum ecosystem, the whole EVM ecosystem will feel united again. Um and so that is I think the final vision of of um um [snorts] what chain abstraction is all about. A little bit detour to just uh explain what we mean by the uh blockchain cake. Um and so there are we imagine like blockchain has different layers. Uh and there are different parties who are operating at different parts of the stack but they own all these parties fall in like four broad categories and they have their own sort of trade-offs that they are trying to optimize for.

Um the first is like the application layer or the DAP layer. These are things like unis swap or a user goes there. This is like a UX interface in front of the UX in front of the user and then the user goes there clicks a button gets the thing that they want. Um the main thing that application layer does is basically generate call data uh for the user. So um the user goes to the website, clicks a button, it generates the call data that needs to be or generates some sort of instruction that needs to be executed um signed by the permission layer and then get then uh executed on the blockchain.

Um so the thing that application layer really tries to optimize for is finding the application that user want and then reducing as much friction as possible. Um then there is a permission layer which is which which are things like wallets. Um and so there are multiple parties who are doing different things in the permission layer, but at the end of the day, what they're trying to do is convert this instruction that is coming from the application layer into some sort of signed instruction that the blockchain understands uh and is able to execute and change state. And so the application layer is constructing some instruction format and then the pmission layer is basically converting that into a language that blockchain understands. So it can be a transaction, it can be an intent and then it gets executed uh on chain.

And then the solver layer is basically all your mempools. So in in in v 0ero you had mempools and then uh as the me problem evolved you had like more sophistication that was that that developed on on the solver layer. But at the end of the day it's all about the step between signing and uh finality. Everything that happens to your transaction between signing and finality is what uh is what the solver layer cares about. It cares about liquidity.

It cares about sequencing. It cares about all the different types of auctions you have. There are maybe 100 different companies or just operating on the solver layer. But this is like the core trade-off um that the solver um layer tries to optimize. And then the finally the settlement layer.

These are your blockchains and oracles where things get finalized. Um and then that becomes your root of root of trust. Um maybe just like a just as a warm-up as a show of hands. Uh can you can people just raise your hands? Who is working on the application layer in the audience?

Wow. Quite uh quite a few quite a few people. I did not expect so many. There's this joke running. There's a running joke in in crypto Twitter which is no one is working on the apps.

Everyone is working on the infra. Um um and then uh there's the permission layer like who's working on the permission layer like the wallets and and uh policies and intents. Um a nice good set of audience over there as well. Who's working on the solvers? Um quite a quite a few people.

And then settlement layer like chains, nice a little bit less settlement layer people. Uh maybe they don't like chain abstraction that much but it's fine. Uh uh okay. Okay, so let's let's look at the core trade-offs that each of these layers are trying to optimize for and basically where they what decisions these players in these layers of the cake make. Um you get like different properties of your application.

And so the the core trade-off that the permission layer is trying to decide on is between UX and user agency. And and so like you have one set of users who just use like hardware wallets who verify the transaction hash that if the transaction hash that they're actually signing on the hardware wallet matches the thing that they see on Metam Mask or or some other wallet. And at the other end of the spectrum, you have people who just use Telegram bots and they just send their private keys to a backend server. And so but Telegram bots still generate like 20 30% of the volume. And so there is this trade-off between what great UX you want to give to the end end user versus how much agency the actual the user wants for them.

And um this is like a trade-off that that app developers or dab developers or wallet developers actually have to care about and they lie some somewhere or the other on the spectrum. Another interesting thing that I that has sort of emerged um is like if you guys have used these uh apps or dabs which use Google SSO um all the Google SSO verification or authentication that happens cannot happen onchain. it happens in some off-chain compute system. And so what what the app that is doing Google SSO is doing is is it checks if the oath token that Google has given you actually corresponds to the private key that they store in some secure enclave or secure environment and then sign it. And so u even apps that are providing you Google SSO are making this UX versus agency trade-off where users who actually ask for Google SSO are um are letting go their agency, letting go of their um censorship resistant properties for a much better UX.

And so uh it was very interesting for me to see like the rise of these apps which like let go some parts of the decentralization or censorship resistance aspect for this for this improved UX and it it's coming from like a user demand. Um the second thing uh that you uh the second layer basically the solver layer optimizes u or trade trades off between finding the optimal route versus giving you like an execution guarantee. And so if you can imagine if you imagine a world where where there are multiple chains, a user is holding balances in three different chains uh and says I want like a user is holding $100 on three different chains and says I want $100 at the end of the day on chain four uh find me the best route, pull the funds, give me the liquidity. um there there is this trade-off on the solver layer between like what is the best price that you can give to the user versus can you actually execute the transaction or not and so that's that's that's the trade-off that the solver layer sort of struggles with and uh finally on the settlement layer uh there is uh this trade-off between fees and execution speed. So um like if you are trying to move messages across two different chains there are different ways in which you can pass messages like you can either rely on the L1 L2 bridge which has like 7-day delay but that is like the most secure way of transferring funds or you can trust like some other bridge provider which has a multise and it'll give you just just things instantaneously and so there is this trade-off over there.

There are some properties that obviously we don't like but there's a breadth of options available and that's what the settlement layer sort of struggles uh between basically giving you a better execution speed versus like the cost of time or cost of of doing that execution. Uh any questions till now? This was a little bit heavy or not heavy. Any questions till now? No.

either I'm very good at it or or no one is listening but um okay so uh this is what this is what I imagine the expected end state to be from a perspective of a DAP so if like you're a DAP developer this is what the end state of chain abstraction I think looks like which is a user comes to your front end a user comes to your DAP they don't see these three words anymore they don't see the words gas chain and bridge anymore it's just abstracted away from their experience The DAB basically is deployed on some chain. It's deployed on some settlement environment L1, L2, L3, whatever is there prefers. Be it ZK, be be it EVM, be it maybe even the new versions of VMs that are popping up. The DAP is deployed over there. The DAP requests either the wallet or the solver layer.

What is the effective balance of the user on this particular domain on this particular environment? And then knowing that particular that effective balance of the user on that environment can generate the call data that that needs to be executed on the environment. And so all the process of basically pulling the funds from multiple domains into the target domain into the target chain is responsibility of everything downstream. So like the wall the permission layer, the solver layer, the settlement layer, the DAP, the only thing that the DAP cares about is what is the effective balance of my user over here and then what call data I should generate um or what intent or whatever is the format I should generate to basically execute this. Uh and so like users can hold funds like if if you if you if you if you get back to this United block spaces of Ethereum vision then users can hold funds on these multiple domains at the same time.

Like they can hold $10 on mainet, $50 on optimism, $30 or $40 on arbitrum and then the the wallet or the solver figures out how to pull everything over from all these three domains and executes the call data on base. Maybe the maybe the user wants to buy some some memecoin on base. User just clicks a button, gets the execution and and uh that's what the DAP and the user cares about. Um uh any questions on the vision? Any challenges?

Things people don't like? I'm getting good at sales apparently. So um okay. So let's let's let's take a step back. uh let's only look at so in my opinion you need ERC's at these different interface points between different layers and those are the things that we should sort of standardize there are some like ERC's that I think are interesting on the permission layer which give which give uh interesting permissioning or interesting properties to the apps uh and so we'll take a little bit detour we'll just look at the permission layer ERC's and then um then go then go deeper Um okay so first ERC is uh 4337 so when Ethereum launched uh many years ago I don't remember uh maybe draw knows but when Ethereum launched um everyone had EO wallets so like uh um and your wallet basically is is responsible for doing three things it is responsible for uh giving you some sort of an on-chain identity.

So like your private key when it is uh converted into some sort of a hash gives you an onchain identity. Your wallet is responsible for signing which is basically uh verifying if the thing that you have you are saying you want to do is actually coming from you. So it does o and then your your EOA wallet is also responsible for basically constructing this this instruction set to the to the blockchain. Um over time people sort of figured out that this is very like restrictive and this does not have the proper properties you want for a very good UX. Uh the thing that was limiting there are a bunch of things that were limiting with something like this.

Like one thing is you cannot have modifiable authentication and so like if you want to do something like a multisig then you would need to deploy a new smart contract on chain which has its own its own sort of authentication mechanisms. People also call them policies. So you can have more fine grain policies like this app can only withdraw these many funds or I can only with I can only execute uh $1,000 worth of transactions in in the next 24 hours. Stuff like that. So all all that is doable on chain.

Um all those like checks and balances are doable on chain. And then uh another property that that uh basically dab developers wanted was uh like uh batching of transactions together. Um basically like the flashbots API just does this like it ensures batching of transactions and so like you have a you have a big entity just formed to to enable that property to the transaction layer and then uh also because you can do batching you can do like gas sponsorship so that you can you can give the user $100 in ETH let them do the transaction and then withdraw uh withdraw $100 of any other token in uh in your solver. And so like these two properties is what people wanted from a modern uh account which is granular authentication and ability to basically execute transaction on behalf of the user. So like gas abstraction is also what people call it and so 4337 gives you that property.

I won't get into like all the all the details of what are the different types of instructions you can pass or enable but yeah these are the two properties one thing one um one thing that uh I think is pretty nice 4337 is gaining momentum and gaining adoption and so it will be like the default way how people deploy smart contract accounts on chain um but for for a crosschain setting how 4337 is also important is if you are on some target chain and you want to execute the a transaction on behalf of the user but the user does not have any funds on the target chain this message sender message sender property is very important for for every DAP. So basically the way DAP authenticates if a request is actually coming from the user it is by verifying if message.sender is the user or not. Um but be if the user does not have any funds on the target chain like the user cannot execute the transaction and so uh how 4337 helps is if your user has a 437 account or if your user has this batching property which will be possible with 7702 whenever the 7702 hard fork comes as well. The solver can just fund the user with the money that they want on the target chain and execute the transaction on their behalf.

The user does not have to basically ex the user does not need to be responsible for the ex for executing the transaction itself. And so um it has many other interesting properties as well such as DOSS resistance. So like you always have a mempool which is decentralized where transactions you can just leave transactions and they will eventually be executed on chain. Uh but I think in from a point of view of the chain abstraction vision this message sender property is is a is a pretty interesting one. Um the second one which is like we are still in the permission layer.

We are still in how uh like what are the properties that you give to your account. Basically uh over time people sort of figured out that we cannot create new accounts with new properties every time we want to do something new. We wanted some way of basically installing programs into your account uh into your account. So similar to how if you have like a phone or if you have your laptop, you install applications into these hardware devices, you can basically install modules into your account and get properties. Um like the another clean thing about uh this modular smart contract design is someone can just basically create one module make it public get it audited and everyone in the ecosystem can basically just install it and and uh and get those properties.

Um any questions till now? No. Um so like there are three main modules that are available. One is the validator module where you can basically install uh you can install these validator modules and the only thing that the validator module does is basically checks things before an execution happens. The second thing is the execution module which actually uh changes state on chain and then there are pre and post hooks where you can you can do some conditioning before and after uh an execution module.

There are two different versions of it like one is gaining more momentum compared to other but both try to solve the same problem which is how do you create this communication layer between an account and installable installable um functions. Um the second type of ERC's are on permissioning. So imagine imagine you have your Google account and you are able to permission applications. So whenever you connect your Google account via SSO let's talk only about web two world like whenever you connect your Google account via SSO to another application you are basically giving them permissions to do something with your Google account. permissioning standards or permissioning ERC's are similar like that where you can basically give permissions of your account to some other application and so there are quite a few applications already that are live which sort of uh give session keys to the application.

So if you if anyone has used hyperlquid then the thing that they do is uh you go over there they attach they attach some session key uh maybe I think in the browser context or in their back end and so you don't actually you just sign once when you log in and after that you don't sign anything you just click a button and the session key behind that who is responsible for executing or generating call data and making sure everything is valid um um executes or generates the call data and signs stuff for you. So there's no there's no there's no like there's no metamask pop-up like the only only time there's a metamask pop-up is when you when you log in and uh after that there's a session key that gets attached to the dab and then u then everything happens either on the browser on the back end. I'm not I'm not exactly sure. So there are these two ERC's that handle that. Um I don't know which one will give gain uh momentum over time but yeah there's this um these are in flux.

The good thing that the these also touch upon this UX versus agency trade-off that I talked about earlier on the on the permissioning layer. So like if you don't want the user to be troubled by like a new pop-up every time you want them to do something, you can add a session key to their account and then it will be just like a click of a button and you can you can generate uh multiple signatures or multiple transactions just because they have clicked something uh once. There is another one which I I sort of like which is Merkelized signatures. It is not a standard yet but so imagine a world where again let's take the example where you have funds on three different chains and you want to get the funds on some target chain. The thing that you will have to do is basically sign four transactions withdrawing funds from those three different chains and executing the call data on the fourth chain.

If you have something like Merkelized transactions, then uh you just sign once like your Metamas just pops up once and all those power transactions are uh in some in some sort of a hashed format and you just sign once and it's like a one-click signature experience. That signature is valid across all the four domains, but it will only be executed at the particular chain ID that that that it has instruction on. So you can really give the user this one oneclick experience uh without popping making four different pop-ups every time um for every every different domain. Um okay so that was all about permission layer ERC's. Let's let's look at like the interface between between the DAP and the permission layer.

Um any questions till now? Yes. Yeah, it's not I think it's on by economy docs. It's not uh Yeah. Yeah.

It's not uh there's no ERC for it, but it's just something that I like. So that because like you can using that you can basically do one click sign four different transactions. All those four different transactions are just valid on their particular domains. And so you carry that information on chain but the execution only happens for that particular that particular chain ID. Um so in the in the permission layer like just to recap on the permission layer context we looked at four different types of ERC's that are in flux that will smoothen the that will smoothen this UX versus agency trade-off.

One is on 437 it gives you this message. So that the user does not need to have funds. the user does not need to execute the transaction on the target chain. The solver or some other third party or even the DAP can do it for them. Uh the second is um how do you modularize how you add more properties to your account and once you unlock that you can add like session keys you can add these uh merly signature type things and you can you don't even need to write any of these anymore like people have uh written these smart contracts and got them audited and you just need to install them in your uh in your account if it follows uh the standard.

Um okay let's let's look at how the DAP should communicate with the permission layer. So this is another thing which is in flux. There's no ERC for it yet. But one end state if you want to have like the united block spaces of Ethereum is you need like the transfer should as the bridge should be as easy as a transfer. So right now it's like a very very buggy experience.

I just showed you how like when a user is trying to move funds from one domain to another, they have 50 different options and they need to choose between uh speed and cost. But um one thing that you can do and it's still uh I don't know the exact specifics where it will land but at the end of the day this is what an address will look like. Uh so it will have your normal address hash and then some information of the chain and then every chain would have to register some sort of an ENS domain. That domain will have all the metadata that you need that the wallet would need to basically uh unfurl where I should send the funds and that is how you would um you would be basically like pasting pasting the desired address of the user. Um the other thing that that app needs to do is even just figure out what is the user address.

In in cases where you have smart contract accounts or different types of authentication mechanism, it is not very easy to figure out what is the what is the address of the user. And so this is one way in which uh the DAP can communicate to the wallet saying hey just give me the smart contract address. Sometimes even on the user might have different addresses on different chain ids. And this is one way to basically request um what uh what is like what are the what are the available addresses for for the user on all different chain ids and then construct the call data according to that. Um another interesting thing that is happening on this between this DAP and permission layer is there are these session scoped um EIPs or ERC's that are being formed which is the DAP can maintain a session with the wallet and only request certain scoped properties.

So it can maybe only request I can read your balances. It can only request I can execute some transaction. it can only request. I can change some some properties on certain chain ids. And so similar to how you have uh whenever you basically authenticate whenever you loging in via Google SSO or or Facebook SSO, you define some scope properties that these apps can can unlock.

Um there are these four there are these four CAPs is what people call like chain agnostic IPs that uh give these session properties. So you can either create a session, revoke a session, change a session or or even like if there is a session that is active, just get a session very similar to how um like a DAP in the web two world will will interact with your your Google or Facebook uh backend servers. Um another interesting ERC or EIP uh is this one called batched calls or batched transactions. So it creates so suppose in a multi-chain world or a multi yeah multi-chain world what you would want is to execute something on the target chain you might want four different things to happen one after the other the four different user operations four different transactions um and this is the way how DAP can tell to the wallet that hey I want these four or five different transactions can you execute them in batch uh and instead of just sending one particular transaction waiting for execution and then sending the another one. You can just send a batch of transactions to your wallet.

And if it is a smart contract wallet, the wallet can execute it in in in the same transaction, it will it will execute those user ops. Or even if it is um uh like uh you can even send instructions to execute multiple user ops or multiple transactions on different chains. And so this is how you do like batched transactions in um between u DAP and wallet. Uh another interesting uh property it has is this get capabilities feature. So a a lot of the stuff that is driving these sort of some some of these ERC's between the DAP and the permission layer is the idea that you should have smart wallets but dumber dumb dumb apps.

So the app should only care about uh what call data I need to execute. What is like the slick UX that the user wants but um but the wallet should care about all the other intricacies of how how I need to bring the amount or how do I need to bring the assets to the to the final destination. Um this one is this one is a combination of the scope and the and the and the call that you want to execute. Uh another interesting one is so right now there DAPs need to basically get a list have a sense of what assets the user has and then query them with their with their u note provider. So like okay does the user have USDC does the user have this does the user have that and then just query them.

Um this basically gives the responsibility to the wallet and so uh a DAP can just basically query uh okay for this address what are the assets can you just give me all the assets or can you give me these the these assets and these the these balances and so all that job that the DAP was doing to basically fetch balances is not is is is offloaded to the wallet and only the wallet is doing that job. Um I think this is like because a lot of this work is repeated across both DAPs and wallets. I think this is a pretty powerful um ERC it. Yeah. Uh I'm not sure.

I think only RC20 for now. I I can get back to you, but I think only RC20 for now. Um any any other questions? Yes. Yes.

Can you use the mention that we already have a execute batch function right in the ERC 437 is it using uh EIP 5792 behind it? So um in 4337 you can execute user ops one after the other in the same transaction. 4337 so it gives the your account that property that it can execute these things in the same transaction. 5792 is only about between the DAP and wallet saying I want these things to be h to happen and then the wallet wallet needs to figure out if it is a 437 account then it can do it in the same transaction or if it is an EOA account then it needs to do it one after the other and so and and what about like crosschains like if I have let's say for example gas fee uh I don't have a fund on a particular chain yes but I want to do some transaction then how do do we have to separately communicate between different chains for this. Uh even that is like the wallet's responsibility.

The DAP just says these are the things you need to execute please execute them. There is also like a flag where you can specify if these things can happen in parallel or they need to happen sequentially and so that is how you can do some of the some of the crosschain. Thank you. Um the next set of ERC's are between the permission layer and the solver layer. So how does how does your wallet communicate to the mempool layer or the solver layer that please do this.

Um so the wallet has converted the instruction that is coming from the DAP into some sort of um signed message that the blockchain should understand. It can be like a intent or it can be a user op. It can be a transaction uh like an EOA transaction. But yeah like by this point at the end of the permission layer the wallet has signed something for you. One way I think the distinction between applications and and wallets is applications generate the call data or instruction and then wallets are responsible to sign them and convert them into a language that the blockchain can understand.

Um um yeah. So one one thing which is uh sort of popping up uh is this intent framework. Um let me just take a sip of water. Any any questions in between. Cool.

So when you are trying to communicate between two chains, you can either communicate, you can either send tokens, transfer balances or you can basically send information or send messages across. And uh if you look at the things that an account has, it either has balances, so things that are funible assets or things that are funible. And then it has some sort of like authentication scopes that are attached to it like a multiseg address or a session key or some some other property or a policy. And so when you are in a crosschain world when you are in a world where there are different domains you need to sort of sync up that the sync up the authentication scope all the time but maybe send the balances at at execution time. Do do you have a question?

No. Okay. Um, so this one is about moving assets across chain. One interesting property when you're trying to move assets across chain is because assets are fungeible, you can basically pay a solver or pay a sophisticated third party to uh just move their those assets instantaneously. And so this is why you have these solver or intent type of frameworks that have that have emerged where you have a sophisticated third party who takes some money and gives you this speedy this speedy execution.

Um but when you're trying to move messages around you cannot you cannot have loss. It cannot it cannot be lossy. When you're trying to move messages around and you're trying to basically maybe vote yes in a governance vote, you cannot vote a maybe. It it has to be it has to be a yes. And so when you're trying to move assets, there can be some loss associated with it uh if the users are happy with it.

But when you're trying to move messages, it has to be it has to use the most secure pathway to to move it around. And so this is uh this is just a standard to move assets around. Uh and this is you can think of it as like a crosschain limit order saying I want to give these these these assets on the input side. Can you just give me this asset on the output side? And then it's the responsibility of the solver network to figure out uh which solver to use, what fees to charge, all all the all the minute details.

But this is how the wallet can communicate with the solver layer about this is the this is can you move these assets for me and and get me these assets at the at the um target chain. Um there's another thing that we have sort we have been working on which are resource locks. Um and so if you think about a cross-chain transaction, there are three things that happen in a cross-chain transaction. One is you need to send a message on the origin chain. Then the second step is someone on the origin chain or someone on the target chain is waiting for finality.

So you send a message or send a transaction on the origin chain either to a bridge contract either to a solver network and someone on the other side on the on the on the target chain is just waiting for finality or waiting for inclusion on this first message and once they are happy that they will get the money they can execute they can execute the transaction. And so this is like this three-step process very synchronous 1 2 and three that happens which causes this like long delay in in in moving things around. And this is also how like like centralized exchanges work. Basically you send money to their escrow. They wait for certain number of blocks and then they debit you the money.

This is what you need to do to basically uh guarantee equivocation protection between uh between two databases. Um we are working on this thing called resource locks where you can convert the synchronous process into asynchronous process. And so if you are able to commel to the solver layer by whatever means you can attach this lock on an account level you can attach this lock on a token level. If you are able to communicate to the solver layer that you will eventually get paid don't worry about it just pay the user right now. you can convert this three-step process into like a very quick like instantaneous process for the user and that's how you are able to move um assets uh instantaneously uh across chains.

It has like an initial bump of actually users depositing funds into a lock but once this lock is enabled you can uh get instantaneous execution. Uh I can show you a demo of how this works. So the so the idea is that you should be able to move funds crosschain faster than you can move the funds on the same chain even and so that is the hopefully this demo works. uh whenever I really want to make it work, it does not work. But uh um so so uh just to give you like a recap this is like the wrapper contract where users so similar to how you have wrap you can have a wrapper version of the contract where users just deposit funds and similar to how when you deposit into w you can use it on all the different uh DAPs like unis swap or a u something similar when you deposit into this wrapper contract you can instantaneously move these funds across across any domain.

So this is a rapper contract uh and this is my address on arbitum. Let's just let's just move. So I have already wrapped some some funds. Let's just move a small amount of money. Uh and what will happen is uh it will pop up like a simple permit to signature message that I just need to sign and uh as soon as I have signed I have bas I have basically sending to the solver the transaction.

So I will I moved money from mainet to arbitum and it took uh like 2.9 seconds and if I just um if if you look the transaction on the mainet is still pending but the transaction on arbitum has already happened. I already got the money and this is happening because you can do this like asynchronous communication between two chains and you basically get this you if you unlock something like this you basically get the speeds of Solana across the whole EVM block space. Um this is live anyone can use it. Uh just test it out.

Uh but you can yeah there's no ERC yet. There's no ERC yet. just so how did you do uh we did not we are writing an ERC but uh it's just like a quick demo the contracts are public uh it's like a wrapper contract which just so the so the main question is can the user revoke this transaction or not if the user can revoke this transaction then the user has double spent and the solver has not received the money that they paid instantaneously. Um the way this works is you when the user deposits into this account or into this token, they are voluntarily opting into a time locked withdrawal. So they can withdraw these funds permissionlessly only after some time lock period.

But uh but it's still pending. So it's not I think it is final. It should be finalized by now. Yeah, it's finalized now. So the the solver has received the money.

But like when you say two second that's even less than the the source chain confirmation time. Yes. And who are the party like can anyone do it permissionlessly or are you do you have some So right now it's it's being it's in a permission setting like Peter from relay is sitting over there who's doing it. Uh he was he was waiting for the money. He was waiting for the money but he paid it up front.

Uh but eventually like you can also you can also encode it uh permissionlessly. But you can you you just said you can cancel right like because you cannot cancel you cannot cancel you cannot cancel even though it's pending. Yes. Because you have uh you have locked the the funds with that account or with that token contract and the only way you can cancel it is if you unwrap those funds and relay account. Sorry.

Who put the money? The user. The user voluntarily put the money into before this happened. Yes. So before before user put some amount of ease then they put the rich instruction.

Uh so let me let me take a step back. So over here if you think about what is happening at transaction time user is paying this this cost of finality or inclusion. But with the resource lock the user because by the act of depositing has already paid that cost initially. When did when did you deposit? So whenever the user deposits we wait for certain number of times to save ourselves for reals and then uh we can say that there's no risk to the solver if the user will like you will eventually get the fund.

But what happened to the brand new user who just want to bridge something from A to one? It sounds like you have to do some setup job to pre-allocate the one. Yes. So that when people do next time it's faster but if it's a first time experience it is not okay. Okay.

Yeah. Yeah. So yeah you need to top it up initially and only then you get the the speed otherwise you don't get the speed bump. There's there's another question at the back. Oh I was going to say can you talk a little bit about capital efficiency okay and like the reality is you've got to lock up the assets first.

Are you planning to put it um you know the methods that you need into say wrapped eth or something else so that you don't have to hold you know one balance e or you know sty that kind of thing. Yeah that's a good question. So there are like there are different places where you can put the lock you can have a lock in this like in a in a module. So we we looked at some of the valid like ERC's where you can put a lock uh where you can put where you can code different things in the module itself. So you can either put the lock on your account level and so whenever you receive the funds the funds are logged itself after some time or you can uh put it on a token and so whenever so whenever you wrap it you basically log them.

Um but yeah there is this initial friction and so if if the user has not logged it will it will go through it will go through this path. If the user has logged it, it will go through this part. Yes, there. Thank you. Uh, so this sort of lock is similar to how NOS's pay works in a way so that if I as a user want to move money out, I have to know wait a certain time before.

So it's a two times transaction. I I say I want to do that and then I can move money out. Yeah. Yeah. Yeah.

So uh there are other things that also like if you look at this there's not something new. This has been tried before by different people. They just don't there's just not named it. But there was Gossis pay who was doing it. So when you are so you need to do something like this when you need to put a card on your onchain balance because uh Visa Mastercard wants like instantaneous uh guarantee but onchain it might take some time or it might also be reordered and so you need to put some locks in your account level.

So Gnosis has put some locks on the account level to enable their uh their card feature. I'm sure any other wallet who has their own card needs to put something like this because uh because Visa and Mastercard won't wait for 12 seconds or or some finality guarantees. There are there's also this thing by Coinbase called Magic Spend where you have funds in your where you have funds in your like Coinbase uh centralized exchange and you want to execute them or use them on chain at transaction time. Uh they have a lock as well. The lock is on the centralized database.

So wherever is the source chain, wherever is the source chain, you need to have some to get like the snappy uh 3second and it took 3 seconds because it's a demo like the our indexers are slow but it ideally it should take you should just sign the message and it should take the time of the target chain the target chain block time is is the only thing that that should determine. Um any questions? Yes. Yeah. Um do you provide the source code on GitHub so we can dig a little more in the one one if example?

It's not uh I will make it public but the code is the code is there in the the code is open source so you can just um so the smart contract but um I assume on the UI there is a bit of wrapping and offchain oh yeah packing so I would like to read into it as well got it there is I maybe you have plans to publish it on your GitHub there are some docs uh I'll at the end of the slides. I I'll share the link to the docs, but you can go to docs.un1balance.io, I think, and you should find all the docs. Which docs?

Uh doc uh okay, thanks a lot. Doc one.io. Got it. Thank you.

Yes. So these these are the documents. You can just How do you handle reorgs on the source or destation chain? So because um the funds are logged even if there's a reorg you can just replay the transaction and the solver will get the funds. Can it cause a double spend in any way?

Uh I don't think so because like uh whoever is providing there is there is some like entity that is at the end of the day what you're what you're trying to do is solve for double spending because you want the user to get the money first and then give the money to the bridge or the solver. Um and so effectively whatever this thing is doing is solving for double spending. And the way this solves for double spending is make sure okay this transaction goes first then this transaction goes first then this transa another way to look at it is it's like a account level sequencer or a token level sequencer which is just trying to sequence transactions one after the other so that there's no double spend. Yes but you execute transaction on one chain and then on another reorg might invalidate one of them. So the reorg might invalidate.

So suppose a user signs a message like a 712 message send this much money to this address. Um first time transaction happens then there's a reorg whoever is the pay master can execute that transaction again and give the solver the money again because the funds are logged uh because the resources are logged the user cannot remove those funds. And so in the in the locking contract you need to be sure that there is enough time uh that even if there's a reorg you can the pay master can replay the transaction but uh yeah so the that is the only thing that you need to make sure otherwise uh the solver will always get paid and how much time is this locked uh I think in this demo it's 24 hours but ideally it should be as long as you are sure that you can get the transaction included even if there is some some sort of censorship or rig. Thank you. Yeah, more or less the same uh question.

Sorry, I have to reiterate. So the input transaction um uh the user is supposed to to submit the input transaction on the origin chain, right? But at the same time uh you send it to the solver assigned raw transaction for the case that the input transaction on the origin chain gets reorged. So the solver can resubmit it any time um herself. But uh how do you deal with nonsis?

For example, you could invalidate the the nons with another transaction and then it doesn't help that the funds are locked. You cannot use that sign transaction anymore. That's a that's a good question. So at least on the token level uh since it's just using permit to um the nons are not uh sequential and even on the account abstraction level in 437 you can have parallel nonses. So got it.

So so you actually do not share the signed row transaction you share a signature um and and the signature you can use in any transaction submitted by anyone actually. Yeah a user op or permit two are just signed signatures anyone can bring them on chain. Yeah, makes sense. Y and ideally it's in the best interest for the solver to bring the source chain transaction on chain because they've already paid on the target chain and even if there's a gas pike they they want they'll try to get as much money as they can. So even if there's a gas pike, they'll keep on like bumping up the gas and uh make sure that that they get the money that uh that they paid for.

Um any other questions? Yes. Our solvers are permissionless. So anyone can become or solvers are permissionless. Anyone can become a solver or they've listed somehow.

Uh in the demo uh not yet but ideally yeah you can you can have a permissionless solver. Okay. Um okay. So this was how you commi how like the wallet communicates with the solver layer to get some properties uh either how you transfer value or how you get this instantaneous crosschain UX. Um now once uh now once the solver has done their stuff how do you validate or how do you actually validate if something has happened on the target chain.

So suppose in the case of 7683 the user has just signed a message saying I want this much money. The solver pays the money but how do you make sure that the solver actually gets paid or if the solver does not pay the user on the target chain how do you make sure that the user gets back their funds. Uh this is what this is what u you sort of try to do in the in between these two layers of the cake. There are two standards. One is just like a message passing.

So if if you guys remember I told you like there are two types of messages or two types of things that you need to move across chain. One is tokens or fungeible assets and if you're moving tokens the user can basically take a price card take some loss uh and get this faster speed or you are trying to pass messages across and so this is this is one standard to move messages across like bytes uh and then there is another one to actually burn and mint uh tokens across chains. So there are two different standards. One is by Optimism Superchain. I think the 7802 is by Optimism Superchain and then 7281 is by a bunch of different like bridge providers.

It was called XCRC20 before. But the the core concept is that a token can assign a bridge to become uh a burn and mint bridge basically. So we when we look at the solver type of a transfer between chains there can be some loss but in a burn and mint bridge um there is sort of no loss you can you can just it's it's as good as a transfer it's effectively yeah it's it's if even if you look at the code it looks like it's very it looks very much like how the ERC20 transfer um gets is executed and the token basically trusts a burn and mint bridge saying that okay uh verify I or validate that the burn has happened just mint me the equivalent amount of tokens on the target chain. So very uh uh costless way of moving assets. That's all I have for you guys.

This is some some shameless publication publicity for what we do. But uh we have two different products. One is like the chain abstraction toolkit. So if you're a DAP and you want to uh just get all these properties of just you just need to care about what is the effective balance on the target chain and this is the call data I want to execute just make sure it happens then that this is your this is the product that you would want and then on the second side we have another product that will that we're working on which is the resource locks as a service. So if you want this uh one token is just one representation of it but then there'll be more modules that we build on top of it and so yeah that's the uh that's the other product.

Thanks a lot. Any questions? [applause] There's one question there. There's one question over there at the back or no more? None.

But there is one just asking if you could upload the slides because it was a lot. I got almost everything but not all of them. Where should I send it? Sorry. Twitter.

I Yeah, I'll post it on Twitter. Uh if uh I am Anka Chaplunk on Twitter and Telegram. Feel free to DM me if you need anything. Thank you. There's another question somewhere there, right?

Or or no, maybe not. Um, also I can see that a few people did submit questions through Mircat. The the one that got an up vote was how to support SOL and BTC. Um, I think effectively it's the same thing. You just don't have like ERC's there.

uh at least the good thing about uh EVM ecosystem is you can have the same sort of language but a lot of the stuff that we talked about will have to be changed a little bit for these ecosystems. Um but you can at least from a like a resource lock perspective you can put a lock over there as well and you can instantaneously move you can even instantaneously move Bitcoin from just at at a click of a button to another chain. But there's like a lot of um other stuff that you need all the different ERC's that we talked about that need to be talked with these different ecosystems as well and I don't know who is doing doing it. We are not doing it. I don't know if anyone else is doing it.

Another one is um is EIP 3370 already a standard for chain specific addresses like base 0x ABC blah blah what safeex is using uh yes it is uh but there's a different one um there the the main I think the main thing is like any any chain can call itself base and so how do you know what is the chain ID of the any chain can have the same chain ID as well. And so with with this chain specific address like if you use ENS then you there is like a way to actually hold that metadata on yourself. And the other thing with that proposed ERC is it will be permissionless. So a wallet can basically just run a light client and be able to get the metadata from that from that ENS ID. Then we got a question.

How can a user ignore the chain? Aren't different chains uh with different security and performance properties? Um there's a trade-off like some users won't ignore chains. Some users will be like it happens right now as well like uh some users are like I'll only hold Bitcoin. Some users are like I'll only hold ETH.

Some users want to trade meme coins. And this is just like a UX makeup on top of different properties that chains might have. Some users will care about it, some users won't care about it. And so if you are a DAP that wants to target the type of users that don't care about it, then then use this. If you are a DAP that um is very specific about know like the user uh should have all the context uh when they're trying to ex execute something like this.

then then um the normal path is also available. And the final question we have here is how would wallets be deployed into different chains for initial setup? Um there are different ways. So um at least on deployment I think one thing one more interesting property that you get with 4337 is you get this deterministic address and you don't need to deploy uh you don't need to deploy your account uh even when you're receiving funds on any chain. So you can just let the user receive the funds and only when the user is trying to transact something that you can that you can deploy the code of the account and then um do the so it it has these nice like civil resistant properties as well.

Uh that is one way there's another thing that if the user changes their multisig on one uh chain how do you sync up? It's like it's a different rabbit hole in itself. There's key store roll up, there are L1s load, there's a bunch of other things. We have not even touched about that over here. But yeah, that's a different rabbit hole altogether.

All right, that's all the questions we've got through Mircat. Are there any final questions from the audience just spontaneously? Yes. Can can you wait for the mic so that everyone can hear you? Um, from the UX perspective, how long do you think it's going to take for us to be at a point where users and normies don't have to think about gas bridging and chains?

Like are we two years away, a year away, five years? Uh, you can use these two apps. They are already in prod uh that there is like there are a bunch of apps that are already in production. users don't need to care about gas chains um bridging anything. Okay.

So yeah, at the end of the slides there are two apps that I link where it just abstracted away. And if you're a dab developer today who wants to get this like snappy UX who wants to uh tap into all the different um users who are on all the different domains then then then you can use these things. Guess the answer is the future is now. Yeah. Future.

Yeah, was yesterday. Cool. Thank you. Lovely.