# Solving Multichain UX: Lessons from Cosmos for the Rollup Ecosystem by Nicolas Lara | Devcon SEA

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-09
- Duration: 24:31
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-2J2XDbN8Q6M
- YouTube: https://www.youtube.com/watch?v=2J2XDbN8Q6M

## Description

This talk addresses how we tackled challenges in the Cosmos ecosystem like liquidity fragmentation, multi-chain accounts, and cross-chain contract standards, and how these solutions can be used to improve cross-chain UX in the rollup ecosystem. 

If time allows, we'll also dig into designing flexible and scalable abstractions for rapid deployment of integrations (bridges, dexs, wallets) across not just many chains, but many diverse tech stacks.

Speaker(s): Nicolas Lara
Skill level: Intermediate
Track: Developer Experience
Keywords: Fragmentation, UI/UX, Account Abstraction, defi, cross-chain, aggregation

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] um hello everyone so um Sonia was supposed to present his talk he couldn't be here today so I'm going to be presenting on his behalf uh my name is Nicholas Lara and I work at osmosis which is the leading Dex and liquidity venue of the cosmos ecosystem and since this is an ethereum conference uh I'm going to first do a quick introduction of the cosmos ecosystem in case some of you are not familiar with it the cosmos ecosystem is a network of independent blockchains that are generally but not always built with the cosmos SDK and the main thing that they interact with each other using this protocol called the inter blockchain communication protocol now this is how the network looks right now it's a bunch of chains they're following pretty much every crypto use case that you want to build there's a chain for it and uh the central idea that we've been building around is that each of these chains can make all their engineering decisions based specifically on this use case that they're trying to build around so you have chains that are a de a privacy chain liquidity um chains you could have da layers and all of those could customize sometimes small things like block times or block sizes but it could be bigger things it could be different execution VMS could be different mles consensus algorithms or it could be using the MPC capabilities of the validator head so [Music] um Okay so we've been building in this heterogeneous environment for a long time which means we have to think about all these different types of chains and like all the differences that appear in them have these protocols that are higher levels so if you're building applications that interact with all of them then you uh cannot really rely in all of them being the same and this is what this talks about like the problems they have Arisen when dealing with this in Cosmos the solutions that we build to address them and the open issues that we're still trying to solve so uh there we go what does this matter for the ethereum ecosystem so the idea of l2s is not really new it's been around since forever but the amount of l2s and like the difference between them and how much they're interrup interrupting with each other and like the different ways in which they communicate has been growing a lot lately and I don't think anybody really believes in this idea that one chain will actually win outright and that you will have everything happen in one place we're instead building these apps at a higher level that have to interact with multiple chains to be able to do what you want to provide to users so the first thing you need to build when doing uh something like this is a message passing protocol and that's what IB is uh I'm not going to go into all the details of how IBC Works internally but basically IBC uses light client verification of the counterparty chain State and offchain uh Rel layers that update the light clients and notifi chains of posted messages there are other designs of General message passing there's like notably layer zero Accel GMP and hyperlane and they all serve as this B base layer I think IBC is one of the most secure and general architectures for this and a new version of this is actually being developed it's code named Eureka right now and um that's actually going to make it easier to bring IVC to EVMS because it's uh simplifies the protocol a lot now one of the first things that you implement once you have a token trans um a general message passing protocol is token transfer right the general way you implement token transfers you lock it in one place you pass the message to the other chain you let him know that that has happened the other chain can mint the token now one thing that I've seen even for like the more advanced intent-based token transfers that are still being proposed is nobody thinks about implementing multiple token transfers that's a lesson that we've painfully learned they spend countless hours in people like trying to work around the fact that you can only transfer one token at a time that was done wrong in the initial implementation for this and IBC it's been like rectified on the newer one but once you start transferring value then one thing you have to think about is like what do your accounts look like right in this heterogeneous environment your accounts don't necessarily look the same everywhere you cannot assume that just uh this type of address is going to represent you everywhere and so one thing we do in Cosmos simple we add we encode this as spec 32 we add the chain name at the beginning and that there are trade-offs that makes it harder to recognize the address directly you look at it you don't you're not really sure if that's your address or not cuz there is checks on bites at the end and uh there's actually a really good solution for this on uh on evm that is this ERC just stick the name of the chain in front of it but um the problem with this is that you actually don't really know who owns this account who actually controls it cuz this might be true but even for EO uh for eoas you could have a chain that has implemented account derivation differently so even if you control that account in one chain you're not sure that you can't control any on the other and that gets even more complex when you consider something like smart contract account or uh even just something as simple as a multi-stake you would end up with something like the a winter mute hack where somebody sent tokens to an account that they supposedly controlled but was not initialized on the receiving chain so a hacker was able to snap uh to snipe so uh what we can do instead to avoid these issues is to lean heavily on Registries we've tried a couple of registry designs in Cosmos none of them has actually stock so I'm guessing this means that the design of this protocol is not as good as it could be uh but you actually do have a de facto standard in ens domains and I think this is the best bet that we have to have a general registry system that you can use across all of um all all chains but of course I think it should evolve a little bit you need to have there are three important parts that you need to have that is like the top level owner of an account you need to have sub accounts and you need to know which chain you're interacting with so having something like that it generally would help you identify the account but it will lead to one very obvious problem that is like you're linking all of your accounts and yes you could use statistical methods to deter which accounts are linked to each other but that uh becomes a lot easier when you're just giving that information away so I think is that you could use this concept of asymmetric names asymmetric names is when you have these names that are interactively verified so you could it generate uh accounts on the fight that are used only as a receiver and you have a way uh those are all derived from your private keys and they're all controlled by you so it becomes kind of like a utxo model but something that's even better is that you can then take a that to those tokens that you have received there and they could be just streamed through a privacy layer to the account where they're actually supposed to live at rest and in something like Cosmos this would go through a set of different chains before it lands where you need to have it now when you once you introduce uh abstract accounts or smart contact accounts you end up in the situation where you have created a set of complex permissions that you have on one chain and you want those permissions like this is how you interact with your uh accounts you don't want to have to have that in every chain so once you have have set this up you don't really want to have to transfer that to every chain and once you want to change your permissions then you would have to actually adapt it on every chain that you've interacted with instead one solution from Cosmos is this idea of interchain accounts interchain accounts use this controller host architecture that um allows you to create an account from one chain to the other so like your account on one chain can have an account on the second chain and you can control that only by sending messages from the controller on the controller chain now uh there we go there's one big problem with this and is latency right if you have a one account that is your main account that is controlling everything else once you want to do an interaction with any other chain you would actually have to initiate it on your controller account and even if that is a very fast chain you would end up having a latency of like at best at 1 second and that's probably not good enough for what we want to build so even when you do that there are like even if you're okay with your one second and controlling everything from one account you have two other problems one is that you need to initialize your accounts in every chain you cannot just start using a chain that you haven't used before without creating an account there and the even more important problem is composability you normally want to interact with three different accounts uh sorry three different chains and in all of those chains you want to execute different actions if you wanted to do that by controlling your chains from one um Central account chain then you would end up having to sign all these messages and you have to do this offchain coordination of which order things are going to happen what happens with failures and instead what we want to do is we want to have this General model of cross chain execution you want to start your interactions in any chain and as you do that the interaction should automatically move through all the steps that are needed to complete so if you want to send tokens to a chain swap them there then send those two tokens to another chain and LP there you should just be able to sign one message and ex and express that you want to execute that and all the other execution should just happen automatically and that is something that we've built for Cosmos and we built it in this way of having nested messages where you specify what is going to be um happening on each on each step each one of these messages is either a token transfer or a contract execution and it's followed by another of these um operations and if you zoom out to what this is this is actually just Monet right like this is just one big operation that gets processed and as the operations is processed it returns you two of the same operations one for success and one for failure if you succeeded you execute success if you failed you execute failure and um as you have that that is just the general model of computation that you can use to do basically any sort of execution across all chains now there are challenges for this right once you're dealing with these two chains um who's doing the execution you initiated the action in one chain what account is doing the execution on the second one and the way we've solved this is we've created uh the as you transfer tokens One account gets created for you automatically on the receiving chain that is only existing there for this particular execution now that account has received the tokens and can act on them as that account sends the token somewhere else or executes new actions new accounts get created for that so those can only be controlled for this particular execution now this has a nice side effect that you actually have to send your tokens along with your transfers so you can you don't have to rely on like having tokens be there in those accounts beforehand now who's paying for it in Cosmos unfortunately right now this is altruistic Rel layers um in ethland you actually could just use a pay Master for this which is really good and we're working on like a fee uh system for getting around this in Cosmos right now now you're posting the execution data on chain like as you start your execution you're saying this is what I want to do and you're getting that on chain that can be pretty costly in some chains so what you want to do is you want to try to avoid that and if you think this is costly you could just instead of posting the whole execution you can just post a commitment to it just post a hash and when you relay your messages you can include the execution uh information now you have to deal with Dynamic information that is really difficult I think the best solution we have for this is having some sort of query language that you can actually use to act on the previous executions results but this not something we've implemented it's like too complex and like the advantages are not good enough um I mentioned before cross chain latency and the cross chain latency here is not the same that I was talking about before before you had this issue of when you start your execution you have to wait for the execution to start until the second chain receives it whether here the latency is just the amount of time this execution needs to take anyway if your actions requires three token transfers and three actions on each chain that's the minimum amount of time that they should take um and of course if you are um is saying what you want to execute on the first step and then things are going to happen say a minute later on a different chain you'll have this me issue right but first I think this is not something that you need to solve at this execution layer you need to solve it more of a privacy layer and the simplest way to get around this is just what I said before for execu execution data being onchain you don't post all of it you just post your commitment your hash and then as you execute um you actually reveal what needs to happen um there are some standards that I think would be really useful in E land to implement all of these but like the hard part even after we have this is what is the top level protocol that we're going to implement that is going to allow us to communicate both with uh evm chains but also with Cosmos and also with Solana that's like an way of um specifying your cross-chain interactions that you can use across all these chains now even when you've taken care of all that and you can do this execution across chains one big issue that we have in terms of ux is this idea of asset fragmentation what users actually care about is which underlying assets you're interacting with uh what risk you're incurring on and being able to just use those assets on applications right so if you have an application that works across multiple chains you end up having many different variants of one asset that are spread out in different chains and they may or may not have the same name and they also may not have the same liquidity they may not be able to be used in every application so um centralized exchanges do the opposite right they show you just one version of the asset and they just don't expose the risk at all you just don't know what's under underlined there you assume it's variance of the same asset and hopefully it is but you don't really know it and at asmosis we've developed this concept of alloyed assets alloyed assets is just basically a pool of all these variants they can be swapped one to one so uh then the lp token of this pool actually becomes the canonical version of the asset in this case you would have like a Bitcoin that is the representation of Bitcoin on asmosis is just the union of all these variants of Bitcoin that have been bridged now this is of course socializing the risk but users can also choose to use the variance directly if that's what they want and and certain applications that don't want to use this alloy ass can also choose to just use one variant now one cool thing is that the original issuer of this token if you have onchain governance or even with offchain governance you could be the one that decides which variants are allowed in this alloy right like you could have for example the ethereum foundation start these polls in different places and say these are the tokens that are allowed here other people will provide liquidity but these are the tokens that are allowed as canonical eth and the same way could be like for chains that have onchain governance onchain governance can decide which assets will be part of this now a cool thing with this thing is that it doesn't really need to be something that only exist on one chain you would be tempted to just take this asset and like send it everywhere but then you're basically just creating one more variant of the asset right so what you can do instead is just have these bols exist on every chain and that is what is considered across all chains the canonical version of one asset so everywhere when you're referencing Bitcoin you would be referencing this thing that is a version of Bitcoin that has been bridged through these 10 bridges that we through social consensus consider to be valid bridges for Bitcoin um and yeah and and those could also be just rebalanced across themselves uh and I think a lot of this that I've been going through is B basically that we need better cross-chain standards something that doesn't work just within one ecosystem and that works with chains that are very different to one another and yeah this probably leads to standard proliferation but I feel like do some standards do win out it's not necessarily true that the more standards you you add the more standards you have eventually people will move towards the better ones and um I think with in general with want to move more towards this user Centric view of blockchains you users want to have accounts that are easy to identify they want to see all their assets across all chains they want to have better execution across all chains that they can easily specify you want have protocols for asset identity so you know which assets you're interacting with but without having to you yourself go into all the details about the risks and they want to be able to share their account permissions between chains we're trying to apply all these lessons to our new product that is called Polaris and Polaris is a token portal to trade all assets on all chains through one app and we're hoping to be able to build better cross chain standards along the way we're going to be interacting with pretty much every chain out there so when there are no good standards uh out there we want to help build it so uh yeah if you have good or bad experiences either building or using cross-chain applications just please come talk to me because I love to hear what you think and try to work together in like making better standards and unifying them and improving them thank you for your time okay thank you Nicholas let's see the questions so we have three questions for now um first one is how do you see the lack of middle ver functionality in many bridges compared to ibc's ability to execute commands through middleware and IBC memo impacting Mass adoption and ux in Cross chain echos yeah yeah uh we need better Bridges we we need callbacks on Bridges um IBC is I I obviously I believe in IBC everywhere but yeah if we don't have IBC everywhere if we use other Bridges let's use the ones that have callbacks and I think as we start implementing functionality that use this type of like middlewares and callbacks then th that's the ones that people are going to use because they just provide a better like possibil better possibilities for building applications okay uh next question is is there a cosmos version of the ERC 7683 standard uh since I'm not an eth person you somebody if somebody can tell me the name of 7683 then I can probably answer that is there anybody who I I don't know so yeah um who has question is is it a question intent or is okay uh you can answer this later discuss yeah okay uh next question is what is the biggest benefit of having a standardized interoperability standard across the ecosystem versus various bridges in ethereum MH so I think there are two different things like the interoperability standard it would be for being able to like regardless of whether you have one Bridge or multiple Bridges you could have one inter ability standard built on top of that so um and I think the advantage is applications can build using basically this language and then if a new bridge that is better comes along you could your application will still work there now um versus having various Bridges I think it's good to have various Bridges they have different properties and yeah if some are better they'll hopefully win okay next question is why not use the EA Crush chain interrupt spec that was recently released um I is it 7702 uh no I'll probably have to look at it like I think we we worked on this if it's recently released I guess the answer is we built this before so oh wonderful yeah i' yeah I'd love to look into that okay uh next question is is you mentioned the Privacy layer before a transfer from uh up chain to another one isn't it possible to end uh to ends up sorry yeah we lost the question uh is it to ends up being targeted by the governments like tornado cash uh sure yeah I mean I feel like everything can get targeted uh even just like blockchains in general but that's why I so I like the idea of having this as an optional layer that you can have like in the case of these female accounts I was thinking like so your um your name registry actually provide this different set of accounts that you can interact with right like things get pushed to them and then you have again basically an utxo model right like you have all these things that you control and you can move through there and that gives you some sort of privacy now if you actually want this to be streamed through a privacy layer then what would happens you would have something that is slowly moving moving this thing to another chain that does privacy and then moving out of it uh yeah if that chain gets shut down then you probably would have to do privacy somewhere else and um yeah I think other privacy Solutions uh would come out uh okay next question is um how will Polaris handle the reorgs of layer twos um how polars will handle reorgs of l2s um I don't know that's a good question uh we are so Polaris is working at a higher abstraction level so I believe like whatever our provider apis are doing there is what we'll do like for evm chains um but yeah I again good question uh give me your opinion out there okay um we have 20 seconds but it's not enough to answer the next question so you can take it uh there and thank you a lot yeah