**A** (0:05):
So hi everyone. So we are at the cross chain product panel for our long hash multi chain infrastructure summit. And basically today we'll be discussing native cross chain applications because for this panel we are introducing our thesis that we believe that like native cross chain products will represent the future Web3 applications and because native web cross chain applications will be more successful than the traditional applications which will operate on the single chains. So yeah, I think we can kick it off with a self intro on all of our panelists. Yeah, so I think, yeah, maybe Richard, you can go first.
**B** (0:46):
Cool. Yeah, let me start. I'm Richard, I am the technical founder of the SAFE project. We are working on a smart contract based wallet or particular also account abstraction that is like we believe that account abstraction is required to unlock real ownership on blockchain and also bridge the gap that's still in the UX and certain security aspects still exist. And obviously when thinking about account abstraction, multi chain is a big part, right? Like how does account abstract, how do smart contract wallets behave between different chains? And it's a lot more special than it comes into an eoa. So when we, since we believe in that account abstraction is the way towards the future to get method option for blockchains then this is one of the very essential parts to figure out how does it work together to bring this really to the methods.
**A** (1:36):
Yeah, thank you very much Philip. I think you can go next. Yeah, sure.
**C** (1:42):
Hi, I'm Philip, I'm the co founder and CEO of DeFi. We are the most advanced bridge aggregation protocol on the market. We try to aggregate as many different solutions as possible and we believe that abstraction as well as account exception, that's the abstraction of liquidity flow will play a major role in building multi chain applications in the future. Dapps, like multi chain dapps will function like on chain or single chain dapps so the user won't recognize which changes. And simply we believe that depth is going to pick blockchains like the developers pick databases today. So based on the technical needs and that's only working on 40 people by now.
**A** (2:28):
Okay, thank you very much. Sunny.
**D** (2:33):
Hey, my name is Sunny. I've been, I work on the Cosmos ecosystem for the past five or six years. It's a ecosystem that you know, multi chain interchain, native first. The entire, entire premise is that like you know, there doesn't need to be one blockchain for everything and generalized blockchains are a little bit of a misdesign and really what we want is a world of application specific blockchains that can all still communicate and interact with each other. And so past two, past year and a half I've been working on a project called Osmosis, which is a Dex built as its own blockchain using the Cosmos stack. And so yeah, really focused on building a interchain native Dex.
**E** (3:23):
I think my background is like scaling based like for the last three years I've been working on like the scaling problem in general was the initial part of the initial team at Polygon, built one of the first ZK roll up systems, built the fastest optimistic roll up at the Ethereum foundation and right now I work as the co founder and the basis of job for us is to solve for scaling because we believe in order to solve scaling we need to like roll up centric feature and we need to work on asynchronous communication protocols that enable developers to create these like unified applications that enhance user experience for users that they don't have to use AAVE on Polygon, they can use just Avalon.
**A** (4:21):
So yeah, thank you very much for your introduction. So going straight into the first question after I given the brief intro on cross chain itself, so what are the main pain points in Web3 that we think that cross chain products can solve for right now? Yeah, so yeah, yeah, okay, start like.
**D** (4:44):
So one of the main things that I see that like why this whole app chain model, you know, is something we really believe in and there's, there's actually a number of reasons, right? So one is the just this, I, you know, one of the most easy, simple reasons is just for scalability purposes, right? When you have a blockchain that like is a generalized blockchain, what always happens is you end up competing for throughput with other applications that are on the same chain. And you know, you might be trying to provide a certain, certain level of like service to your users, but then suddenly, I don't know, an NFT drop happens on the same blockchain that you're on and suddenly the gas prices spike and you sort of have no control over that. When you have an application specific blockchain, you're sort of the only application on your blockchain. You don't have to worry about another application coming in and suddenly just over like you know, eating up all of the throughput of your chain. So that's like one of the most obvious reasons. And so, but beyond that there's also like a lot of cool stuff you can do as a developer when you're building on something like Ethereum or any generalized blockchain, you're really at the, like, mercy of the L1 developers on what you're able to do. And especially if you're trying to really push the limits on like what you can do with blockchains today. Like, you know, for us, we really believe that the next frontier is like doing interesting stu with privacy. You can do like, interesting, you know, mev mitigation and capture strategies. But a lot of this stuff needs to be done with like innovations at the blockchain layer. And so what building these app chains, what you do is get this like level of vertical integration that you won't get otherwise. Like, you know, other applications that are built on existing L1s might be able to, you know, they control their smart contracts. But with something like osmosis, we control the application and, and the blockchain itself. And we also actually build the primary wallet for the cosmos ecosystem. But so by having this like sort of full stack control, we can do stuff like, you know, experiment with novel cryptography, do things like build in batching systems like natively into the blockchain itself. All sorts of cool things that you wouldn't be able to do otherwise. But then we're still able to interact with the rest of the cosmos. But even the larger blockchain ecosystem using bridges like Axelar and still bring in these assets and allow them to be tradable very seamlessly on the osmosis decks.
**A** (7:19):
Yeah, definitely. I see the appeal of osmosis having its own dex and having a sovereignty so that it's free. It's free to experiment with new features as well. Yeah. So yeah, maybe we can move on to like Live Fire Socket, which are like the middleware hoping to ease some of the problems for the users.
**C** (7:41):
Yeah, I think ultimately these crosschain products, right now they are facing a particular challenge, which is an information gap.
**A** (7:48):
Right.
**C** (7:48):
The user's multi chain has information assets and an identity on multiple chains. And this information gap has to be bridged in multiple ways. And so we have a variety of bridges that solve for different cases. We have liquidity networks to move assets. We have arbitrary data messaging bridges mostly underneath these liquidity networks that can send all sorts of data. Essentially all these bridges kind of have the same fundamental, but then again they focus on different features. And then we have a new breed of bridges that simply allow to share state proofs and do that in a very specific way, like state proofs across multiple chains at the same time, for example. So again, another type of bridge is focusing on different features as an aggregator like refi or socket. We aggregate These bridges and we make sure that the developer doesn't have to make a choice here because for the developer it's so much research overhead. Just shortening that go to market is a huge value add for him. Right. So we make sure that they don't have to choose which bridge to use specifically. These bridges support different source and destination chains for whatever they are offering and all of that adds so much overhead. As a developer you want to focus on your own business. That's what cross chain products have to solve for and we are an integral part in the process.
**E** (9:15):
Yeah, I think definitely agree to what Philip just mentioned that I think we at Socket also believe that for asset building particularly aggregation provides like a very nice middleware that's not only just like good UX but almost potential and that's just because how bridges work. Right. So if you talk about AAVE, if someone deposits like 10 million USDC on AAVE that 10 million USDC is available for everyone to use. Right. But if a bridge has 10 million TVL that's distributed across 10 chains, that's 1 million per chain. Right. So that kind of creates bridge liquidity for a very small amount of assets. But users want a larger asset support. I think aggregation is the right kind of middleware for any developer. And on top of that Socket also has a messaging layer that adds composability to these asset transfers so that users can bridge their assets via the most efficient route and then use the messaging solution to perform actions on the destination chain and stuff like that. So I think it just enhances the overall UX for the developer and for the user and I think this is like quite needed in the space right now.
**A** (10:31):
Yeah, definitely. Like I feel the appeal of for. For both the users and the developers like of simplifying the cross chain experience. So yeah. What about Richard? Like I know that like NilsiSafe is also deployed on multiple chains and would like to hear on views on like what you guys are working on with the account of abstraction as well.
**B** (10:53):
Yeah, I mean first I would also like really what Sunny said right. Like with the advantage of multichains is right like that you have different purpose but also different trust models. Right. Like I mean for some cases like gaming you might not need hundreds of thousand validators validating your gaming set. Like you can use other trust models and use L1 as a rule back I think what we see that to really facilitates these advantages also for the user they don't need to be, they should not be visible to the user and this is where then for the safe it becomes a little bit tricky because if you have account abstraction it's like there are very quite a vast amount of challenges when it comes to like because users have certain assumptions right now that you about addresses, how to use addresses and I mean that's very interesting how Sunny described it. Right. Like if you have full control over the whole stack, you can abstract away some of these things more easily. But then also you are kind of setting a certain framework and I think this is for us with account abstraction. The question okay, how can we make use of this to introduce a standard where you can also have this cross chain and line cross chain on certain rules so that you can transport it to some extent? Yeah and I think also long term the question is like all how can be tools like arbitrary message which is used to really use it for the account standard across. Right. Right. Now we, I mean the examples are hey, we have exchanges, we have lending protocols where we use aggregation across chains. But we are not like I think the next step would be okay, how can we use like arbitrary message which is to have one account on one chain and control multiple accounts on different chains. Right. Like and this is not trivial because currently users always think it's on an address base but obviously that's a difference. So there's a high potential and I mean they have been outlined by all of the different people here. Right. Like with multi chain. But yes, it's still quite tricky and users should not have to think about it. Which chain are they on? What is the purpose of this chain? Right, like this is, I mean as Philip said, we don't even want the developers to think about it, even less the user. Right. Like so this is I think one of the parts where we still have to do quite some research.
**A** (13:02):
Yeah, definitely. Thank you very much for your answers. So yeah, before moving into the second question, basically like we've been working on like a model to sort of like frame the different types of cross chain products that will be out there. So I've been working on nuts model with my team at Long Edge Ventures and basically we have three archetypes that we have identified. So the first archetype is the distributed model. So basically the liquidity and the assets are distributed on multiple blockchains. However there will be like a single coordinating chain or coordinating like off chain protocol which will like use message passing or like any other smart contract interaction to coordinate the different liquidity functions of each of the liquidity on the different chains. So something like LIFI and socket, they are utilizing the existing liquidity on the Dexes and bridges. So they are using their own infrastructure to enable more seamless swaps of that. And of course we are also seeing like something that Delphi Digital recently wrote about the the slam model where the liquidity is fragmented across all the different chains and then this, this coordinating chain will basically view them as like virtual liquidity. So the virtual AMM can basically swap assets of with very low slippage between the different chains as well. And of course like we're seeing like Niosis Safe, which is a distributed model in our opinion because we think that like it's basically the copy pasting the smart contracts on Ethereum onto the different chains for their governance, they can still decide to see if it'll be centralized on Ethereum or if that will be distributed as well. The other archetype that we've identified is of course the aggregator model. So that's where something like osmosis comes in. We think that in Cosmos osmosis is the main chain that aggregates all the existing liquidity from all the different assets in osmos and also all the native bridged assets as well. So basically they are aggregating all the liquidity onto into a single chain to enable more capital efficiency and maybe in the future different protocols can take advantage of that as well. And of course we've also seen dedicated NFT chains like Enjin and IMX which are starting to come out to basically dedicate all the throughput to just processing nft. So this is the aggregation model that we see. And yeah, another like this is the final archetype of your that we've identified. It's a very new product idea. Like we haven't seen a lot of products building on it yet. It's basically like the unbundled product. So basically each of the DAPP will have different aspects on each chain. So Sommelier on Cosmos is building something like this. So basically all the yield calculations and yield strategies are handled by the US on the Cosmos chain. However, when implementing the strategies themselves, the assets are all around Ethereum. So basically they're utilizing the softw different chains of Cosmos to enable all this aggregation and calculations, but using the liquidity of Ethereum to execute the yield calculations. And of course we've also talked to several NFT projects which are building their own gamified auctions on a faster chain like Polygon. However, the NFTs that they're bidding on are actually on Ethereum. So they're actually using bridge versions of the NFTs on Polygon. And if the bid is successfully captured on Polygon, they will allow the user to claim back the original NFT on Ethereum. So basically like they're utilizing multi chain in order to split the load of the calculations onto a cheaper chain. So yeah, going into our question, basically I just want to understand like what you guys think are going to be useful to have like distributed or like aggregated and like what you think can be like done on like modular basis. The different things that we can think about are of course like the main thing is the liquidity which can be distributed of course the different chains and we're also seeing like governance which hasn't really been distributed yet, it's more like aggregated. Right now all the major protocols, they have the governance on a single chain. And of course, like what do you think, like the coordination of different assets. Do you think that will also be vital in this new crossing model?
**E** (17:44):
I think a pretty, pretty solid question and just to kind of, you know, kick thing, kick things off here. I think my personal mental model when thinking about cross chain stuff is basically think about APIs that are like a million times slower and cost a million times more. Right. And that's basically the current cross chaining infrastructure.
**B** (18:05):
Right.
**E** (18:06):
And on top of that you add all of the security problems that you know, come along that kind of increase the complexity to another like 100x level. Right. But that's, that's probably the mental model around which I kind of, you know, think about these things. And it's kind of interesting to know that if like messaging or bridging kind of evolves to a level where, you know, things take like a cross chain transfer takes as long as it takes to make an API call today the topology of applications will kind of change accordingly if we kind of get to this world. Everyone will want to be at all areas at all times. Pretty much how things happen in the distributed world right now. So if you like, applications start localized and once they have a good amount of scale, they kind of want to be everywhere and they use things like Amazon Edge and you know, software like that. So I think there is no one, one, you know, one correct answer to this. It's very application specific and the trade off here is like synchronicity versus like capital efficiency, for example. Right. And I think each application will kind of decide where they want to lie and will be quite, quite fun to kind of see applications decide, you know, different areas in the whole spectrum and see how that thing kind of plays out. I think osmosis particularly here has taken like A non like a completely asynchronous approach but very capital efficient, very liquidity aggregated. So it'll be fun to kind of see how these designs kind of, you know, kind of evolve from here.
**A** (19:47):
Yeah, Philip.
**C** (19:49):
Yeah, I think, yeah, I agree with what Vaibhav said. And just to make an example also here like application specific needs that come into play here. Right. A multi chain lending protocol will want to have liquidity on multiple chains to borrow against and then at the same time it's facing that capital efficiency problem. So it needs the ability to share data and state and move assets around to rebalance the pool. So this is just very complex question with no straightaway answer. There's nothing that should be or shouldn't be. And then also we can see each different use case in a specific context. Right. So maybe there is a voting solution just for a particular set of companies. Also thinking about company ecosystem chains that we were going to see. Let's say Visa is launching a chain for all their merchants, right. So we're going to have these cases that are there and then, and then maybe there's just one particular other chain they have to interoperate with and it's going to be a totally different dynamic and solution for that.
**A** (21:03):
Ah, definitely a lot of interesting use cases that still have been figured. Have yet to be figured out yet. Yeah, for sure.
**B** (21:12):
And I also would have to mirror this quite. I mean I said right, like the safe is more on the user side to some extent. I mean also the developers are important and you mentioned that it's more the distributed model right now where we copy paste code. But we can already see that why for some cases that it's nice and has advantages but it has at least as many challenges that it brings up. Right. Like and it depends very much on the use case. And for many users a model where they have something like a beacon chain from which output they can control the other chains. Right. Like would be way more natural because they don't have to think about really every chain specifically. But it's hard to say is there one beacon chain? Like which one should these be? Like, I mean how Philip said, right, like if there's suddenly a business that spins up their own chain, do they want to commit to that? Their beacon chain is a serum mainnet. Not sure if Visa would want to do this. They would want to create interoperability and this is really where this for us like this which one is the right model depends very much on the use case and we take extracting this away Will be a very big challenge. And I mean it starts with we first need to abstract away the protocols. If you can abstract it away on the like for the different protocols and it becomes also for the user a little bit easier how to abstract this away and think about this. And yeah, and I mean I liked how Philip mentioned in the for the first question, like under the hood there's a lot of common like we use arbitrary method projects in different forms and I think evolving this will be very key to really enable these different use cases. And then I'm not sure if there's one right solution.
**A** (22:50):
Yeah, definitely. I'm also been thinking like other. Have you guys been thinking about like more out of the use cases for Nielsen where like you can have like your main multisig wallet on Ethereum but then actually have that wallet sign another deployment on another chain through gmp. So do you think something like this would be possible in this new distributed model where the coordinating chain would be on Ethereum. However, the deployments across the other chains are handled by gmp. Like message passing using the bridges.
**B** (23:24):
Yeah. So there has been a prototype actually by the Zodiac team which was for the dao focused tooling, right. Like where they really said hey, we want to do the voting on a chain where it's like really feasible to do on chain voting, which I mean main net on chain voting right now with a big dao is kind of not feasible. But then you want to somehow transfer this vote over right. Like I mean this is the current like there's a safe snap, right, which integrates with snapshot. But there you use an oracle, which means you have to trust this oracle. And if you say hey there's if you trusting a bridge is potentially or hopefully in the long run way more trustless than trusting one specific oracle. And I think the other way, if you want to think it also the other way around is like theoretically it would be nice that you can use a mainnet or like layer one save to have it as a recoverer for all the other chains. It's nice you have some keys, you lose them on some layer 2 or sidechain but that doesn't lose your funds because in the worst case you go back to layer one, you have a little bit more critical keys there and can recover the stuff because sidechains. The challenge here is if user always thinks about same addresses everywhere you you have to like like this is very tricky right now. If you use a factory, getting same addresses actually provides you more a text surface than it provides you any Benefits. But the users are still like, this is the only way how to really go forward. We need to have the same address everywhere. Which makes it hard. I mean, yeah, the past. I was a fan for this too, even with ENS having the same address. But actually it's not feasible, especially if you want to have more heterogeneous. Heterogeneous, like with different implementations. Not good with pronunciation of those words. So you don't want to have 100% homogeneous blockchain space. Right. Like this. Like it's okay, but it's not the future. I mean, we see it even with CPUs moving away from having all the same CPUs, we have different kind of.
**A** (25:16):
Yeah, yeah.
**D** (25:16):
One of the like things that we do, like we're doing a couple things to solve this one in Cosmo. So one is like we use this Beck32 prefixing. It was like by, you know, it was started by the bitcoiner. Bitcoiners actually. But you know, so every chain has a unique prefix at the beginning and then there's also a nice checksum that it does as well. But at least then I can like see an address and I can like see, hey, this is clearly like an address for Osmosis versus Juno versus stargaze. And so, you know, you don't act, you know, there's obviously that situation that happened on the Optimism case or like, you know, you just see an address and you don't know whether it was like, oh, was this an Ethereum address or an Optimism address? Yeah, so that's a problem. And then we are actually building this thing called ICNS right now. Interchange Name Service. It's kind of like an. It's kind of like, it's kind of like ens but it uses like what we call the Outpost model, which is, I can actually get into the Outpost model in a little bit because I actually think that's where the direction of most cross chain apps is going. But how ICNS works is that like, you know, the ownership of a namespace, a name. Let's say I own the name Sunny. It exists on one chain, but then I can set the resolution of different suffixes. So I can do Sunny Osmo points to a specific Osmosis address, but I could do Sunny Juno points to a Juno address. Well, Sunny Stars points to a Stargaze address. And you set all the command center of this exists on the ICNS chain. But then it like when you set a Sunny Juno address, what it does is it sends that data over IBC and sets the resolution for the Juno on the Juno chain, it's important to have the resolution of addresses happening locally to their domains. So that way contracts on that chain can actually make use of that as well as it could be used as like a routing system. Because if a contract on osmosis, you know, it needs to send tokens to Sunny Juno, it's like, I don't know know who Sunny Dot Juno is, but I'm just going to IBC this to the Juno chain because I know this is a Juno address. And then I'm going to let the Juno chain figure out how to act, who to actually resolve and send this to. So that's kind of like, so this outpost. So this is like an example of this outpost model that we see, which is this idea of like command centers existing on an app chain, but then they have these outposts on other chains. So another example of like team in Cosmos that's building like along this outpost model is the Mars protocol, where they're like this lending protocol. But what they do is they have their own blockchain, the Mars chain, where people deposit assets. But what they've realized is for lending protocol to be useful, they need to be co. You need the borrowing capacity to be CO located with Dexs. Because what people want to do primarily is do these leverage loops, right? And you don't want this to. You want this to happen synchronously and atomically as fast as possible. And so what Mars does is they deploy outposts. So sort of like on Osmosis or DYDX or Injective, all these many different dexes in the Cosmos ecosystem. And then the Mars protocol like looks at, hey, where is the demand for borrowing coming from? And they shift their liquidity to, to the outpost, wherever the demand is coming from. So that way you can borrow synchronously a certain amount of assets. And then if you want to borrow more than that, that will happen asynchronously because it will go pull it from other outposts or from, from the hub, from the Mars hub itself. So this outpost model is actually how I see, you know, I've seen like, you know, I helped the Mars team sort of design this model, and we've actually seen that a lot more projects in Cosmos are sort of following this outpost model now as well.
**A** (29:20):
Yeah, definitely. Like, we've also seen some projects that are building on Layer zero and Akila right now, which are trying to create like different borrowing and lending in separate chains, but ultimately have one chain to do the coordination. So basically for the User it's basically like all the liquidity will be shared across all the platforms so the user can collateralize their the USDC on like BNB and then borrow some like a Matic from Polygon just using the MP and the state of which the different outposts are synced using a single coordinating chain. Yeah, definitely one of the main use cases that we see how like cross chain products will be built in the future and yeah, and like just wanted.
**E** (30:10):
To add like what do you guys.
**A** (30:10):
Think about the like the unbundled project? So basically we've also been brainstorming different ways that these applications can use different blockchains to each of the abilities. So basically in the Cosmos ecosystem we were thinking that maybe on the stock chain which is like an NFT dedicated chain, if people want to buy NFTs using USDC but they don't have a DEX infrastructure, they could use the Dex liquidity of osmosis to do the purchases. So basically for a user it will only seem like they're buying NFT on starts. However, like all the liquidity is actually routed through osmosis.
**D** (30:50):
Yeah, this is something that actually we are hopefully will have live by the end of the year. This ability for you to have assets on any Cosmos chain, at least Cosmos enabled chain for now and be able to do a in a single transaction. What it will do is it'll IBC it to osmosis, do the swap, IBC it back and then finish executing whatever the rest of your transaction was. Because you know, the goal is that we want to make this, you know, right now each of those steps requires a new transaction, a new click, new ledger sign from the user. And that kind of, you know, is not the UX that we really want. And so we're trying to, you know, we've basically added, you know, there's a couple of new things that came into the new protocols. So how IBC works is it's just like very bare bones like transport protocol that transports data and what you do is on top of that you build application layer protocols. So you know you have the token transfer protocol or the one. There's a new one that came out, you know, that went out for a couple months now, but kind of now starting to see production is like interchain accounts where it allows an account on one chain to make a transaction on a different chain because it sends the transaction data itself over ipc. And so this is sort of by using this interchain account system we're going to be able to achieve that kind of Thing.
**A** (32:20):
Yeah, definitely. Like very, very interesting use cases and excited to always try out all these projects myself personally as well. So yeah, in terms of like, as like a middleware provider like socket or leafy, what do you think you guys can fit in into this distributed model or coordinating model where the liquidity is on different chains and like applications want to utilize the different parts of each blockchain or the liquidity.
**C** (32:49):
Yeah, I think this is, this is specifically due to the fact that liquidity is like. Liquidity is documented across so many bridges. We see around 70 bridging projects out there. It's incredible and we see more and more coming up. So I think Lara will agree, like, sorry, there are so many bridges in the pipeline that haven't even announced yet and some have been announced and will be released yet. So there's more to come and there's someone's venture capital behind that that they're going to see traction to a certain extent who will then in the end win if it's the one, winner takes it all. It's a different question, but they're all going to pick their niche. We also see more and more bridges specializing for certain use cases and in certain environment. That's interesting. So the space is apparently big enough to pick your niche. Even as a bridge and as an aggregator, we simply are able to not let you think about this. Neither you as a user nor as a developer. And in the best case a chain or project will be completely chain agnostic. I mean if you use the Internet, you don't care who's issuing the SSL certificate, right? You don't care about which tier network you're on right now. In the same manner you don't want to think about which bridge is being used underneath. And also as an aggregator, we are simply able to provide fail safety if a bridge gets hacked, if a bridge is drained out of liquidity, if anything happens, our smart routing and our monitoring solutions in the back end are just smart enough to take that very early on and we simply fall back to alternative solutions. And this is something you, the developer by your own. You wouldn't be able to do that. It's just too much implementation overhead. And a huge issue these caution products are facing and will face is these fast iteration cycles we are facing in the interoperability space. We are seeing these bridges reinventing themselves over and over again. We saw that the SYNAPSE results, but by economy we saw that with Connect specifically. I think last year in April, the Connect was still on the state channel approach. In July they released nxdp which was on chain and stateless, and now Amarok is coming, which is a really nice solution. But it's the third iteration within a year, right? So at least for the team that they stay completely flexible and don't fall in love with their own ideas and just like, okay, refactor, refactor, refactor. But these fast iteration cycles are making it hard for you to just rely on a specific solution. So having a dedicated team, third party team that takes care of these things makes decisions regarding that because you then have to evaluate is the change too early or when is the right point to make that change. Migration and switching posts are just high. And then again, super interesting to see projects like Herodotus and BlackRock, multichain state proof solutions and all of that coming up. So this again will change. And then you as a developer have to make a decision, what's the right solution? Is the solution enough for now? What if I need another solution by tomorrow? And as the aggregator, we are solving all these issues for you. You get everything out of one API, similar to what Skype has done with all the payment processing back then, right? We do the very same thing for interoperability.
**A** (36:17):
Okay, yeah, definitely. So you're basically focusing on like, it's just too much for the developers and the users, like all the new interoperability solutions that are coming out. So your goal is to like aggregate and like incorporate as many of them as possible. So what about for socket? Like, is it the same direction you guys are going? Or like, is there more like more specific use case that you guys are trying to accomplish with the aggregation?
**E** (36:44):
Yeah, absolutely. Also to comment on like the previous question about like the unbundled model, I think it's a, it's, it's quite an interesting model, honestly, and kind of aligns with my personal thinking about how the scaling space is going to evolve. Like right now we're in the model where, you know, everything lies on the same chain and everyone wants atomic transactions, right? But all of us have collectively realized that's not the future, that's not how we are going to scale. And we're building these things called L2s, right? And the other end of this spectrum is everyone builds their own app chain and everyone's asynchronously connected. But I think honestly, practically speaking, we're going to lie somewhere in the middle. I like to call this concept as state bubbles. We'll have different state bubbles and in these bubbles, like all applications that need synchronous access to each Other will lie, everything else will move out, right? So if there are applications like Sunny mentioned that the and the Dex they should stay together because people like to do those atomic leverage actions, right? So these kind of functionalities which will kind of lie together in the same layer or like same stage bubble and things like marketplaces, NFT projects or like NFT heavy functionality, let's say will lie on another layer and an application will together, you know, kind of reside on top of both of these, right? Where all the NFT bubbles, all Dex lending act is routed to this, you know, let's say defi state bubble, right? Or like synchronous defi state bubble. And there is this like large coordination layer that's you know, kind of making all of this happen underneath the hood. And I think that's where Socket's trying to operate, right? Socket's trying to become this like orchestration layer or just like market where people just kind of deploy applications and all of this like orchestration happen happens underneath the hood, right? People don't have to worry about scaling. And I think one interesting and like a funny observation this is Solana also scales for example Solana or Sui and things like that, they all scale by parallelization, right? And with L2s we get parallelization, right? And we can like just as a thought experiment, if we try and think about what happens every contract on Ethereum L1 to not a contract but an L2 in itself, right? We get to this model where all transactions are asynchronous and we can have a coordination layer that kind of processes linked transactions together and unlinked transactions separately, that big leap in scalability. So I think like the whole unbundling thing is really exciting and Socket kind of wants to operate on this coordination orchestration.
**A** (39:42):
Yeah, definitely. Very interesting use case as we're seeing different quote. Like just instead of relying on a single chain for the orchestration, you guys can act as that orchestration layer. Yeah, definitely.
**D** (39:56):
Just going to show cosmwasm here where Cosmos is this smart contracting system that we have in Cosmos. It's actually designed to do this design for this. It uses a actor based message passing system. And so all smart contract calls are asynchronous by default. And so the kind of the beauty of this is what it actually lets you do is the act of calling a contract on the same chain is basically the same as calling a contract on a different chain. So you know, being able to do this sort of like, you know there was this idea in Ethereum called like yanking which was like, oh, you can move contracts between shards and stuff. And so this is something that's actually very easy to do in the Cosmos framework today.
**A** (40:51):
Yeah, definitely. Thank you for sharing. Of course like with all of our Cosmos designed to interoperable, the link programming language is also designed.
**E** (41:00):
Yeah, it's like a lot of the.
**D** (41:01):
Things, I think a lot of these interoperability solutions are being tacked on in a lot of the EVM design world. While in Cosmos a lot of this stuff has been being designed from the get go. Like you know we designed Cosmos to be asynchronous from the get go because we knew our goal was we wanted cross chain contracting and stuff.
**E** (41:21):
So you know, I think the ability.
**D** (41:24):
To write cross chain applications in the Cosmos stack is just going to be like, you know, allow us to move a lot faster than you know, I think other frameworks.
**B** (41:34):
Okay.
**A** (41:34):
Yeah, definitely. Thank you very much for sharing your view.
**D** (41:38):
Yeah.
**A** (41:38):
So in the interest of time like I think let's move on to the final question. So basically for now like we can see that like for the cross chain products there's a lot of pain points for the user in particular. So basically like for me personally as a cross chain user as well, like even to when using like a Dex aggregator like I have to sign multiple transactions and then like so for, even for EVM to evm, if it's like EVM to like Solana or like Cosmos, I'll have to like find the transaction like switch my wallet to a different address because the address is non evm. So there's a lot of pain points there. And of course like we've even seen like some projects like a Stepn which have released their NFT collections on two chains. So both Solana and bsc and we're seeing that like because of the different liquidity in each of the different ecosystems like the play to earn model and the prices of the NFTs are completely different across both chains. So there's a lot of challenges even for different dapps right now when trying to implement cross chain. So the question is what do you think in the future? What will it take for cross chain product to be the standard and then what would it look like for the user in order for cross chain products when they're ready to take off? Yeah, I think. Richard, do you have anything?
**B** (43:05):
Yeah, I can start. I mean I'm going to go. It's also like top down since I come again from the user side. Right. I mean we have visited the tech side a couple of times and I Mean I think a lot of things that need to change have been mentioned before in our session today. I mean they were like right now bridges are still something where it's expensive, it's not fast, right? Like this needs to improve because only then also from the user side you can abstract it really away as long as the user really as you brought the examples, right? Like you have to think about different addresses and you know what these different addresses mean. So you have to think about so many things that don't make sense. I mean Sunny described it quite nicely, right? Like with this, with the interchange naming system where you don't want to think about it should be under the hood routing in a way that I mean ENS also working on this where they say hey, you have this cross chain resolution model, right? Like these need to be there and you need because these are the tools to abstract it away from the user so that the user only on a very superficial level has to think about not how they do it right now where they think oh do I have to use a different wallet? Do I have to use a different signing key? Like that's not the level where they need to think about it. And only once we are able to abstract this away then we can really achieve user adoption. But I mean where with what I would hand it up to the other people before we can even achieve user adoption. I would go back to what Philip mentioned before. We need to get developed opportunity to abstract it also way for the developers to some extent and this is I think also quite a big challenge.
**A** (44:38):
Yeah, definitely. Thank you very much for your views. Yeah, what about Philip of Do you have any opinions on like what's still needed for the user experience?
**C** (44:55):
I think we have mentioned most of the stuff, right? It's simply more security battleheadness. So we need to increase trust in these solutions. This is a major thing right now. It will take for sure one, two more years until we have achieved that. I think it simply takes time to get rid of so many bugs and small entrances. It's like financial systems. They took years to stabilize and be safe and then performance usability is the key. So some bridges claim they are fast, but they're only fast as long as they are Centralized. For example, layer 0 right now is still a very centralized solution. They are decentralizable but they are as of fact right now centralized and that makes them fast for now. Will it scale performance wise once they start decentralizing? I'm going to see this is definitely something that has to change.
**A** (45:57):
Yeah, definitely a lot of the main hacks and bridges as well. So I can see the users reluctance in using these solutions. But yeah, security is definitely one of the main things that we definitely need to still work on. Maybe Sunny, you can go first. What are your thoughts on the whole user experience?
**D** (46:18):
Yeah, I think there needs to be a little bit better cross chain coordination systems almost insta dap for cross chain where users don't. What users should be able to do is it should be more declarative rather than imperative, right? In the programming imperative is you write out the steps of what you want to do. While declarative is more you say, hey, this is the result that I want. And you want the, you know, some sort of system that will go and like figure out what steps to do and execute and coordinate them. Right. And I, so, so I think like, hey, if someone wants to open a 2x leverage position on, you know, so you know, instead of the user having to, you know, choose which bridge to use with, where to get the lending protocol, lend like, you know, where to bridge it, where to trade, do all the stuff, right, that should all be like coordinated away from the user and like that. I think that's like sort of one of the next big, you know, next big cross chain products that needs to be built. Otherwise I think, you know, another thing that I think is very important is just on the security side of things. Like I think one of the big issues is a lot of people are just like, you know, rightfully so with the number of bridge hacks that have happened in the last couple in the last one year, but just on the security of use of using bridged assets. And in my opinion, like, you know, I think one of the biggest things that we could be doing to help like with bridge safety is like, or just the way to help with like any safety in like anything in blockchains is rate limits. So you know, one thing that Axelar has added recently is this idea of rate limiting where they say they can say like, hey, only a maximum of 25% of our bridges TBL can like be like removed within every like 6 hour period or something like that. And so this is really nice because that way even if so if there is some sort of hack or something that gives time for, you know, it caps the losses and gives time for human intervention. And this is how like systems work in traditional, like traditional systems work as well, right? You always need circuit breakers in the system to deal with like, you know, extraneous black swan events. And so I think like, you know, we're working on adding similar sort of rate limiting systems into ibc. But I think like getting more bridges to add these sort of like security mechanisms will help ease people's like confidence in using these cross chain protocols.
**A** (49:01):
Yeah, definitely. Even in the traditional finance world, as you mentioned, the circuit breakers or some of the unforeseen stock events and even some banks, they won't allow you to withdraw all your funds in a single day. What you can do on defi. So definitely these things are still necessary as well. Faibhav, are you back?
**E** (49:22):
Yeah, absolutely. I think, kind of answering the same question. I think one, one big problem that I still kind of, I'm trying to find answers to is how to make. So right now every user or every developer in the whole ecosystem is kind of used to synchronicity, right? So bridging is inherently a very anxiety driving process, right. You send your funds to this random smart contract on one chain and you pray to the Lord that you get those funds on the other chain. This is like a very small example for asynchronous communication, right. It induces so much anxiety that it's actually taking like a big, big toll on the user. Right. So I think kind of applications that try to handle or like try to process like let's say cross chain payment transfers as quickly as possible, even by taking on a little bit of LP risk, I think those are like a big win for the ecosystem and they can settle amongst themselves slowly later on. I think things like hop and connect and even across are kind of building such kind of systems for cross chain transfers and I think these are like a big UX win for the end user. So I think generally all kind of cross chain applications we will kind of try to hit interesting trade offs there that users like and kind of take security to another layer, build a more UX friendly application for the users, take on security for the and you know, allow LPs take a hit, things like that. I think those kind of applications are going to be really interesting and really kind of looking forward to, you know, kind of this whole ecosystem evolve in that sense.
**A** (51:10):
Yeah, definitely. As you mentioned, the asynchronous file like having to wait for the other chain to confirm your transactions. Definitely a Harry Potter in the cross chain experience for now. So yeah, thank you very much everyone for this panel and it's very great to hear everyone's thoughts on the cross chain experience. I personally have been doing a lot of research into the space as well and yeah, a lot of new ideas that you guys have given me to think about as well. And so yeah, just to close off the panel, we think that in the future cross chain experiences will be totally abstracted away from the user. Like users won't have to worry about like what chain they're operating on and there'll be like a single like managed wallet or like even a single address for domain for all the chains which can be seamlessly used by the user. And yeah, we also think that like DAPPS can will have their own like sovereign chains. We're even seeing like a thoughts of like Uniswap becoming their own chain through the unichain and then like there'll be like seamless interoperability within all these chains as far far mentioned with the synchronous computing. And yeah, definitely the cross chain is definitely the way that we think Web3 is going. So yeah. Thank you very much for this talk everyone.
**E** (52:28):
Thank you so much guys.
**B** (52:40):
It.