Connecting Blockchain Networks in Practice

Join us as we speak with Temujin Louie, CEO of Wanchain, about how blockchain interoperability supports the movement of assets and data across networks. This episode explores how cross-chain bridges operate, from lock-and-mint and burn-and-unlock mechanisms to the emergence of messaging-based interoperability. The conversation also covers bridge security, validator configurations, and common failure points, as well as how interoperability is evolving alongside enterprise adoption and increasingly complex multi-chain ecosystems.

Disclaimer: These podcasts are produced by the Cardano Foundation. The views expressed in these podcasts are solely those of the participants and do not represent the opinions of the Cardano Foundation. These podcasts are for informational purposes only, and are not intended to provide legal, tax, financial, or investment advice. Listeners should consult their own advisors before making these types of decisions. The Cardano Foundation does not guarantee or make any warranties as to the accuracy, timeliness, or suitability of the information in these podcasts. The Cardano Foundation has no responsibility or liability for: any claim attributable to errors, omissions, or other inaccuracies in these podcasts; or for any decision, other acts or omissions made in connection with your use of the information presented in these podcasts. Unless stated otherwise, reference to any specific product or entity does not constitute an endorsement or recommendation by the Cardano Foundation or by the participants in these podcasts.

This page may contain links to third-party sites that are not under the control of the Cardano Foundation. Access to such information does not imply association with, endorsement of, approval of, or recommendation by the Cardano Foundation of the site or its operators, and the Cardano Foundation is not responsible for the products, services, or other content hosted therein.

Transcript

SPEAKER_02 0:39

Hello. Good afternoon, Temujin. Thank you for making this happen. We had a couple of uh tries and errors, and now we finally made it. Welcome to the Let's Talk Cardano podcast.

SPEAKER_00 0:52

Thanks very much for having me. You know, as they say, third time is always the charm. So I was very confident that it would all work out this time.

SPEAKER_02 1:00

Cool. So maybe let's start a little bit with you and OneChain. Can you tell us a little bit about you and OneChain?

SPEAKER_00 1:09

Yeah, yeah, absolutely. So my name is Tamujin Louie. Most people call me Tam. I'm the CEO of OneChain. I've been involved part-time with blockchain since around 2012-2013, but didn't really kind of go all in as a career until 2017. OneChain itself, some of you listening might have heard of us. We're a pretty old project, and we have been focused on blockchain interoperability since the earliest days of interoperability. WANCHAIN itself originally launched all the way back in 2017. And of course, Interop and the project itself has gone through many transformations over the years as blockchain itself has matured. But always it has been about interoperability, connecting chains, making sure that the chains can speak to one another, that data can pass from one to the other. And that has always been kind of the guiding light for Wanchi.

SPEAKER_02 2:01

And what gave you the idea of doing uh an interoperability solution? And how did it look the first? I guess was there a white paper in 2017? What was the first idea?

SPEAKER_00 2:14

As all projects from that era, definitely there was a white paper. And we were very proud of it.

SPEAKER_02 2:19

Not always. It could be yellow, pink, gray. So there's a different shade.

SPEAKER_00 2:24

I think yellow was always for you know the business side, and then the white paper was for the technical side. But yeah, so we had we had all of that, of course, and we're very happy to have been one of the few projects, not the only one, but one of the few projects from that era that has totally delivered on their white paper and and more so one of the perks of surviving this long, I suppose. But really, it all just came down to even back then, it was pretty obvious to us that the whole world wouldn't be able to run on a single chain. In fact, already at that time there was already multiple chains. There was Bitcoin, of course, there was Ethereum, there was things like XRP Ledger, I think, even then. Well, it's definitely, definitely XRP ledger. But from our perspective, specifically Bitcoin and Ethereum already being what they were, and we believed in the vision of both of them, that okay, we're already in a situation where it's more than one chain. And so you're gonna you're gonna need something to connect these two. So that was kind of the really earliest stages of that idea. Me personally, I was drawn to it because I was really, really brought into this industry by the dream, you know, the the romantic promise that the whole world would be able to run on on blockchain, on decentralized tech, and and soberly, I could see that you know it'd be very difficult, if not impossible, for the whole world to run on a single chain. The scale of the things that are happening in the real world are are just well beyond even today what a single chain can handle. So very, very pragmatically, one was not enough.

SPEAKER_02 4:00

Okay, cool. And um, could you speak about what was the first product or the first problem you wanted to address? Was it the interoperability Bitcoin Ethereum, or what else?

SPEAKER_00 4:12

Yeah, so our to be honest, our vision of interoperability back then or or a thesis proved to be somewhat incorrect. So at that time, back to the white paper, the idea was that you could bring all these assets from the various chains to a kind of centralized location, another intermediary blockchain, and then you can have the assets kind of interoperate in this place. Now, over the years, I think it's much more popular now, and I agree with the way that the industry has gone in this direction, is that these kind of direct connections are more powerful. So if you want to interoperate between Cardano and Ethereum, those two chains should just be passing data back and forth. You shouldn't go to some third mysterious chain and interoperate there. So that's something that have that we've evolved with as well over the years. But in the earliest days, we had the thesis that you could have um, you know, a public circle, a public square where everyone kind of joins and interoperates there. So that's what the kind of white paper was about. That's why there's one chain L1 originally, the original vision for the WANCHAN L1 blockchain, it itself began as a code fork of Ethereum, so it's EVM compatible. And so the first bridges that we ended up deploying were first, you know, Ethereum to one chain. So this is an EVM to EVM type of setup. And the second was a you know Bitcoin to WANCHAING, so this is Bitcoin to EVM. And then over the years, you know, we've expanded to a lot more chains. Today we support 50, 50 plus chains. The mechanisms also have changed a few times over the years. Those earliest, earliest bridges actually use HTLC, um, so like hashed time lock uh contracts. And so whilst quite secure, um, not necessarily the most user-friendly thing, it required multiple transactions from the user to move assets both on the source and the destination chains. Um, and you know, so we've made improvements on that side today. Today, it's much it's much easier to use.

SPEAKER_02 6:09

There's uh you mentioned those early efforts. I remember working on a sidechain of Ethereum using the parity bridge. If if we is it did this kind of thing that you're mentioning, or is it something else?

SPEAKER_00 6:24

Well, for our solutions, it didn't use parity itself, um, but those were cousins of ours, I suppose. I think parity was what around like early 2018 or something like that. So around that time, the the earliest concepts, you know, probably 2016 projects really starting to design kind of early frameworks for interop, probably around 2017, establishing concepts that today are very obvious, the so-called low-hanging fruit. But you know, back then the stuff didn't necessarily exist. So even Wanchin played like, you know, it's always hard to tell, you know, who is the first person to have done something, but you know, amongst the first people to establish even something as simple as like what is a wrapped asset? You know, what is a you know lock and mint mechanism today? It's like, oh yeah, so that's that's baby stuff, but you know, someone had to build it when none when that asset didn't exist. So that was really happening around 2017, but I think parity was probably more like 2018.

SPEAKER_02 7:20

Yeah, I uh I was doing the parity bridge 2018. And uh and then the the push for these kind of bridges came more for a scalability problem rather than uh moving asset chain to chain. Uh I mean that that's the parity bridge uh itself, right? Was more similarly to um polygon, right? The as a as the emergence of layer twos and later on optimistic roll-ups, and then chain specifically designed with this kind of sharding embedded in their system like Polkadot and Cosmos IBC.

SPEAKER_01 7:59

Yeah, yeah.

SPEAKER_02 8:00

How you you're much more experienced than me. How do you see the timeline of interop you know going from the early 2016 until 2026 with layer zero just announced their own uh layer one, I guess, right? Which is a bit ironic. Uh can you can you guide us through this uh you know five minutes fast forward from 2016 and until 2026? That's 10 years.

SPEAKER_00 8:28

Yeah, it's hard to believe it's already 10 years. You know, I think the earliest earliest stuff, even before you know myself or Wan Chin were were around or aware of it, you know, there's definitely some early writings, kind of academic papers, um establishing how to perform like atomic swaps. So in a sense, that could be you know very early types of interoperability, more focused on the asset side of things. Then I think I think you're right.

SPEAKER_02 8:54

You know, what do you recall the first atomic swap mainnet kind of what was it?

SPEAKER_00 9:04

For bridging at that time, it might have actually been WANCHAN because we were using HTLC back then, but you know, the ideas of it, there was no practical place to actually do atomic swap. So people were writing about it and kind of showing how it could be done without anyone having you know built it in the in the earliest, earliest days.

SPEAKER_02 9:23

And we and which asset would you atomic swap? Was it BTC ETH or yeah?

SPEAKER_00 9:28

So so us for our for our scenarios it was BTC and ETH to start, yeah.

SPEAKER_01 9:34

Okay.

SPEAKER_00 9:34

You know, you could do it with anything you want, really. But yeah, I think those atomic swaps, you could argue that that that kind of was perhaps the start of the conversation around interop, which which, like I mentioned, is more on the kind of the asset side. Then I think you're right. You know, then I think there was a lot of conversation about scaling a lot of it or a lot of it around Ethereum, a bit around Bitcoin, to kind of scale these networks via side chains, in a way, side chains themselves, you know, are are the product of bridges. Um, if you want to be not not necessarily use 2026 uh understanding of bridging, but kind of more just like the technical piece of of what bridges and interop are. So yeah, definitely side chains came up. I think this, like you said, is more about scalability. But the a few projects like Wanchain, I think there was like IOTA back then, Komodo, maybe these words are, are tickling people's memory from from those early days who were looking a lot also at use cases. And those were those are the assets. So these two things were kind of happening in parallel. You had really kind of academically rich pushes on scalability, and then you had you know different projects who are really trying to put these things into practice so that users can actually do stuff with interoperability, and at that time, that that just means asset related, moving an asset from one chain to the other. So these things are kind of happening in parallel, probably sidechains a little bit earlier. That's like your 2015 to 2017-ish window. I think 2018, Polkadot probably launched. So you're talking parity bridge. That was an interesting development because you know, polka dot was really, really had interoperability in mind from the kind of earliest conceptions of the project. So, you know, up to that point, we're dealing with a static situation where, okay, you have chains that are not interoperable. How do you make them interoperate? Polka dot or Gavin Wood was basically, well, you know, we thought about it from the start. So you can have the idea of a relay chain and parachains that are all kind of sharing the security of the relay chain without having to worry too much about the baggage of like the previous era. Yeah, you have some ideas of you probably want to connect it to Ethereum and maybe Bitcoin, but those are kind of side things to the design. The core thing is like you have the relay chain and the parachains, and look at this beautiful interoperable system. That was around 2018. Then I think, you know, that 19, 20, even going into 21 era, I think things are just getting mature. I don't really think you're necessarily getting like too much major innovation, but things are just becoming a little bit more usable, kind of culminating into that 21, 22 era where things really exploded. A lot of bridges popped up, really targeting retail people are moving assets all over chains. You know, EVMs are popping up left and right, and people are chasing you know, DeFi yields, and that's really kind of going crazy, and probably in what, 20, 2021, 2022-ish. And then right after that, the kind of conversation shifts a little bit. And after this big rush of token interoperability, even though the ideas were quite old, you know, even I'm sure you were dealing with it in 2018 and about scalability and stuff, but from the retail perspective, they started being sold the idea of like cross-chain messaging rather than token bridges. And that's really where kind of today's big players like Layer Zero and Axelar are really kind of emerged because you know they were they were starting to show how you could deliver on the promise that a lot of other projects were talking about, where you could get smart contracts on different chains to directly interoperate. So you could have like a smart contract on chain A, call a function call on a smart contract on chain B. So you can start to design true cross-chain applications rather than just move assets. That was kind of the promise of these messaging platforms. And so that really brought a lot of excitement into interoperability. And you know, we haven't really changed much since 2023 in that sense. It's just some minor improvements, certainly at the each protocol level, but we haven't not moved on to kind of like the next meta-narrative for interops since that shift, as I as far as I can tell, anyways. Hopefully that was okay for us somebody.

SPEAKER_02 13:40

No, that that was great. That was great. We can speculate uh the end in closing of the podcast, what's the future, right? Uh maybe before we do that, can we could you help me explain mechanistically uh how those bridges work? And and maybe we can start with the most rudimentary, you know, lock mint and burn unlock, you know, the first token bridges, maybe give a couple of examples of projects, and then we build up from the basic concept to to, as you mentioned, uh messaging protocols today, how how these evolved and how they they are operated, right? They have their own validator sets to to have a resemblance of trustless trustlessness. But yeah, let's start from the mechanics. How does it work? A bridge.

SPEAKER_00 14:34

Sure, yeah. So kind of bridges 101, we can say. Yes. Happy to. So we're should I start? I think the thing to keep in mind before we go into the specific mechanisms is that all bridges today, anyways, can basically we're gonna oversimplify a lot in this conversation, so please understand the listeners. So this is definitely a 101, so don't come at me on uh on Twitter about you know maybe slight inaccuracies. And so we're gonna we're gonna smooth over some of the rough edges. But basically, you know, all bridges can be broken down into three sections. So you have the the source chain, this is where you're starting, the source chain infrastructure, you have the destination chain infrastructure, this is where you want to go, and then you have an off-chain infrastructure, and this is the kind of piece that you know moves the data or the asset from one chain to the other. So all bridges, you know, when you're trying to evaluate the mechanisms and how they work, um, these are kind of the three things you're gonna have to look at. But just keep that in the back of your mind because you know, we're not gonna have to talk about it in the first lock and mint, like you said, but probably as we go a little bit more complex. But just keep that in the back of your mind. So now back to square one. The simplest bridges is about moving an asset to from one chain to another chain. So you have basically a pretty straightforward tool set to do so. You have a lock, you have a function, you have a mint function, or you can have a burn function, or you can have an unlock function. These four kind of functions are basically all you need for a kind of token bridge. Um, so lock is pretty simple. You know, it's just the user will then send their asset to a smart contract that they do not own, that quote unquote locks that asset. That's kind of step one. Once that asset is locked in that smart contract, depending on what bridge you're using, the off-chain relayer, however, they set up a group of validators or a centralized single person in some cases, you know, however that bridge has been built, they'll be observing that smart contract on the source chain that has locked the assets. Once they see, okay, there's assets locked in this in this contract, then they'll know, okay, to trigger a mint function on the destination chain, on a smart contract on the destination chain. So that's lock and mint, right? So user locks asset on source chain smart contract, off-chain relayer looks at that chain, sees that this event has happened, and then on the destination chain, they trigger a transaction to mint an asset, wrapped asset, a representation of it, and then send it to the user's address on that second chain.

SPEAKER_02 17:05

That's kind of your lock and maybe a quick quick question on the lock and mint. How does it work on Bitcoin or chains without smart contracts?

SPEAKER_00 17:13

Yeah, so the most important thing to consider then is really the off-chain relayer. So you can't rely on smart contract logic exclusively since they don't exist on those chains. So really you just use a quote unquote lock account. So in a sense, you're just giving, you're just sending your asset in BTC to address that is owned by the bridge. It's not a smart contract in this case, it's just whoever has the keys to that address happens to be the bridge. How they're securing that key, you know, that's what you care about for your risk profile of the bridge. Like I said, it could be centralized and you just decide to trust a single person, or it could be quite decentralized if they've split split up the key either in a multi-sig or a multi or MPC or something like that to control this lock account. And then the rest of the logic is the same. So rather than a smart contract locking it on in the kind of smart contract logic, it's just you send it to this address that is owned by someone else, quote unquote, that someone else's off-chain component looks at that address, sees that you have sent BTC to that address, and they're like, okay, I can see and confirm that this has happened, and now I'm minting it probably in a smart contract. Uh well, definitely in a smart contract on the destination chain to issue you a wrapped version of that of that BTC in this example, or you know, whatever assets on the chain that has no smart contracts. So that's kind of really lock mint, pretty straightforward, I think.

SPEAKER_02 18:37

Okay. What's the what's the next the next step? Is it uh general messaging or is there well that's way too big?

SPEAKER_00 18:45

That's way too big a leap.

SPEAKER_02 18:46

We got we got Okay, what's that what what are what are the baby steps? What are the baby steps?

SPEAKER_00 18:51

Yeah, so okay, well in in this scenario, the other you have to consider the other side, right? So okay, so you've locked your real BTC or native BTC on the lock account, or let's just say your your USDT, Ethereum, and you've minted a wrap version of it on another chain. At some point, you're gonna want to get the real thing back. You're gonna want to get the native version back. So here you use a slightly different mechanism. So now you have to, rather than lock and mint, you have to burn and unlock. So it works very similarly, but with the you know, the the steps themselves are a little bit different. So rather than sending your asset to a contract to lock it, you burn it. And then once that off-chain relayer detects that you have properly burned this asset, then they will trigger the unlock function back on the original chain and send you the native asset back to your wallet. So it's the reverse direction. So to kind of in this kind of wrapped assets scenario, to wrap an asset, you have to lock and mint it. And then to get the real one, the underlying asset back, you have to burn the wrapped asset and then unlock the native asset. So that's kind of the whole flow. So you have these four things, right? Lock, mint, burn, and lock. Then you can play around with it a little bit. You know, some assets like USDT is the big the biggest one, obviously, um, where you might not want a version of that asset that's minted by some random bridge, you know, because the real thing exists on both chains. So you just want to go from one version of the real thing to another version of the real thing. Or it might be like the ETH and all the L2s. You know, you might want to have the you know, not some random wrapped ETH on Arbitrum. You want the one that is considered native on Arbitrum. So in this case, your third-party bridges can't mint that. You know, the the the minting permission belongs to the owner of the assets. It'll be you know the the official L2 bridge in the ETH in the ETH example, or it'll be tether in the UST example. So in this case, mint and burn is not a good idea. You know, if you you can't mint it, and if you burn it, you're never getting it back. So in this case, you have to just use lock and unlock.

SPEAKER_02 20:58

Um so like I said, these are the kind of your four, the four- I mean, uh as a as as a as a thought experiment, uh, I think Charles Hoskinson made this. He said that you know you can mint Bitcoin on Bitcoin and then you could migrate it to another chain, right? So you could burn it. I don't know how smart of an idea this is.

SPEAKER_00 21:22

Yeah, I mean, my migrate, bridge, you know, a lot of it you get lost in words in a sense, but you know, I think for BTC ultimately, at the end of the day, the the value will be the original version of the the BTC. Yeah, yeah, you could you could uh burn some of that and make it unrecoverable and try to prove that this version of it on this other chain is the canonical version, but you know, in practice it's not gonna it's not gonna fly.

SPEAKER_01 21:50

Yeah.

SPEAKER_00 21:51

So if you're dealing with native to native in that sense, you know, you have the lock and the unlock in that case. So you won't be able to burn, you won't be able to mint it. So you lock it on the source chain. Same idea, the relay or the off chain component. Component is looking at the source chain, sees you've locked it, and now is unlocking it on the destination chain. Which raises an interesting question, which is kind of the step two or step three, wherever we are, where these are kind of very the the the the actual functions are quite similar, but what's happening is quite different. You know, in the one where you are locking and minting, really you have infinite liquidity in a sense, because as long as the user is willing to lock the native asset on the source chain, the bridge can mint the same number of a representative asset, a wrapped asset on the destination chain. So it doesn't matter if you're doing a thousand USDT or a million USDT or 10 million USDT, for the bridge, it's all the same. You know, you're just calling a smart contract on the destination chain. Okay, one wrapped USDT, 10, 100, whatever numbers I said, a million and 10 million. But if you're dealing in a native to native situation, then you have liquidity constraints that you have that the bridge has to consider and you become a so-called vault-based bridge or liquidity bridge, depending on what kind of terminology you want to use, where the bridge in a native to native scenario needs to have access to pre-existing liquidity on both chains to allow the user to the bridge. So because we're using a lock-unlock mechanism in this case, the lock side's easy. The user has the asset, they lock it in the smart contract. But to unlock something, it already has to be there, locked, waiting for you to unlock it. You can't mint it out of thin air the way a lock and mint bridge might might do. So you have these kind of operational considerations to do uh in this you know vault-based versus not vault-based kind of bridges. So that would be kind of the next, the next big thing. And there, you know, there's there's advantages to both. You know, I think there we've we spent a lot of time talking to Cardano community as well. And there's definitely, in a way, rightfully so, you know, a bias towards the native version of an asset. You know, native is better, Cardano, native app tokens or native, native, native. It's safest. Yeah. And you know, one chain holds the same opinion. If there's a native version of the asset on the chain, you know, that's the one we want to use in our bridge, and we'll deal with the operational difficulties of trying to secure liquidity to make the bridge work. But there's real strong advantages to having a kind of a lock and mint mechanism as well, because that allows you to bring the value of an asset to a chain where that asset doesn't exist. And that itself is also a very powerful thing. So you know, both really have have a place. But those are two kind of two different types of bridges that you have to think about. Then if you want to kind of zoom out a little bit more and jump in if I'm talking too much, but we're now at the stage where it's No, no, it's it's clear.

SPEAKER_02 24:32

Maybe one question on the Vault-based, because it's interesting. In the case of stable coins, for example, do they count the locked version of the stablecoin as a as an active, you know, as a part of the market cap, or you know, does it need to be backed by fiat? Or is it is it actual is it an actual stablecoin or is it is it not? You know, is the sh the the shredding of stable coin or what's in a vault-based scenario where it's native on both sides?

SPEAKER_00 25:04

Yes. Yeah. In that case, you know, from a market cap perspective, it doesn't really matter where the asset is because the asset exists and it's backed and it's redeemable by the issuer, you know, so circle or tether in most cases. So whether it's locked in a bridge smart contract or in a user's address or in a DeFi protocol, a DEX or lending platform, it really doesn't matter from the issuer's perspective. These are just different use cases for the asset. So it definitely all contributes to their market cap because if you go and retrieve that asset, you can then redeem it for the underlying value, whether it's fiat or you know, some it's usually not cash.

SPEAKER_02 25:43

I'm just asking, because there's this the symmetry, like you have uh a pool of X where half of it is always locked on one or the other chain.

SPEAKER_00 25:55

Yeah, so like from um so these bridges that are operating with like vault-based protocol or vault-based solutions, the the bridge is not the issuer of the stable coin, right? So we're just locking and unlocking. It's issued by someone else. So market cap has nothing to do with it because from the you know, tether doesn't necessarily care what is being done with the USDT after they've issued it. They've issued it, it becomes part of the market cap, it's properly backed by the fiat or the or the papers. And then what it's doing on chain, whether it's locked in a bridge, it doesn't matter because you're not locking and minting it in this case. You're you're just it just happens to be sitting in the bridge, and then on the other chain, there's also USDT in this example sitting there. But Tether has already issued those USDTs themselves on both of those chains. So you're not changing the supply, you're not doing anything. It just happens to be locked on a smart contract and then happens to not be unlocked. So nothing to do with the market cap or anything like that. It's a little bit trickier with the minted assets, because then you are creating kind of like a new asset in a sense. From Tether's perspective, they just you know would not recognize the wrap version, right? So for their market cap calculations, all that, they're only going to be looking at the ones that they issued themselves, and that'll be the ones in a lock-mint scenario that's locking the bridge, and then whatever the bridge mints has nothing to do with tether. You can't take the wrap version and redeem it with tether. All you can do is burn it and get the underlying real USDT back in the example, and then that's the one you know that that you can redeem and is calculated in the market cap and and all of that. I don't know if that was clear.

SPEAKER_02 27:34

No, that was that was clear. It's always the accounting, uh, I guess also it's also different project to project. What's next?

SPEAKER_00 27:43

Yeah. So then the other kind of you zoom out a little bit more. I guess we've been teasing it a little bit, message passing or asset transfers. So that's kind of the the more recent, at least in retail uh space, the more recent split. So assets is what we've been talking about. You have an asset on chain, it doesn't matter if it's a native coin or an ERC20 token or a CNT. These are just kind of specific data structures. And then with an asset bridge, what you're doing is you're quote unquote moving that asset from one chain to a different chain using some combination, right, of the lock, mint, burn, and unlock functions. Message passing, it's a little more arbitrary. What you're moving is not the specific data structures that form an asset. You're just moving, you're providing the ability to move kind of just oversimplifying, say any type of data, arbitrary data. It could be anything you want. And then the the kind of components of both these types of bridges are the same. That's what I laid out at the start. You have the source chain infrastructure, you have the off-chain component, and then you have the destination chain infrastructure. So in the asset bridge scenario, the user's locking the asset, the off-chain component is looking at that smart contract, sees that that asset is locked, and then mints or unlocks. In messaging protocol, rather than locking an asset, there's some sort of data that's being written on chain on the source chain. The off-chain relayer is then looking at that data, sees that it's been recorded, and then is basically copy pasting it over simplify to the destination chain. So now that same data, whatever it is, arbitrary as can be, is then now copy-pasted onto the destination chain and basically sent to a target smart contract. Now, what smart contracts can do, you know, is in a sense only limited, only limited by what the developers can think up. And so with the assets, it's clear. You lock an asset, you give an asset, you're done. With messaging, it's like, okay, you've written some sort of arbitrary data, you send it to a smart contract on the destination chain. And then what that smart contract decides to do with that data, with that input, is kind of really whatever the developer has decided to do with that with that target smart contract. So theoretically, you can do anything you want. That's why you have this really kind of romantic idea of you know large, truly cross-chain applications where you have a smart contract in one chain setting, sending arbitrary data to a smart contract on the second chain, and then that logic flow will just keep continuing on that second chain. In practice, it didn't turn out to be necessarily as romantic because people haven't really thought up what you can do with that besides build token bridges or cross-chain swaps. So, what you have today is you have projects who went out and built token bridges from scratch, or and you have projects that use message passing protocols to build token bridges.

SPEAKER_02 30:36

Yeah, I was gonna ask what are the the use cases like the most adopted for message passing, but it seems there's they have not taken off yet.

SPEAKER_00 30:46

Yeah, I think it's it's we might be kind of approaching a more depressing conversation, but but you're absolutely uh right about that. You know, they're the message passing protocols are more flexible in terms of what you could theoretically do, but people haven't really found anything broad strokes to do besides token bridges and cross-chain swaps. That would be kind of the one value add. Um the cross-chain swaps themselves have become a little bit more commonplace since message patching has arrived. But that might just be a deeper, a bigger question of like what is blockchain for besides assets? Where we had dreams in the early days, but when we look at what people are actually doing on chain these days, it's all asset focused. And so I guess it's no big surprise that on the interop layer, we've also had trouble thinking beyond assets.

SPEAKER_02 31:34

And on the the message uh passing protocols for the token swaps, do they use message message passing or do they use a more traditional lock mean burn unlock?

SPEAKER_00 31:48

For the cross-chain swaps you're talking about, right?

SPEAKER_02 31:50

So Yeah, yeah, exactly. Like I don't know, layer zero or CCIP or whatever, uh one-chain. Those who have developed message passing for the plain vanilla, you know, moving ADA to Ethereum. Uh what do they use?

SPEAKER_00 32:07

What do the Yeah, it's really definitely you're using message passing for the cross-chain swaps because there's some quote unquote arbitrary data or other data that's not purely the asset that you need to know when you're doing a cross-chain swap. You know, with an asset, it's simple, right? You lock it and you mint the same number. So you don't really need to pass a lot of additional logic from the first chain to the second chain. It's pretty straightforward. But there's more nuance with the cross-chain swap, which you need to know. Like, for example, you need to know even something as simple as you've all you've all used DEXs, like the user's nut doesn't have an infinite appetite for slippage. So you're gonna have some sort of limit on it. What the will what kind of rate the user is willing to accept in that swap. You need to know the the asset that the user wants to swap to. You know, the user's only sending let's say they want to go USDT to to ETH to BTC. Maybe not the best example. Let's say USDT to ETH, okay? The user sending their USDT to the smart contract, but those smart contracts need to know on the destination chain that what the user wants to do is take the user's USDT, swap it to ETH, which is a different asset, know various things like the destination address, the slippage tolerance, all these kinds of operational things.

SPEAKER_02 33:27

Uh USDT on which chain, not on Ethereum or Right.

SPEAKER_00 33:31

Yeah, you could do like USDT on Avalanche to ETH on Ethereum, for example.

SPEAKER_02 33:38

So ETH on Solana.

SPEAKER_00 33:42

Yeah, or you can let well this is Cardano focus. So let's say you want to do USDT on Ethereum Ada. Okay. You have all this other additional information that you need to pass through the whole bridge logic because let's say the swap is happening on Cardano. So it needs to know that, okay, the user has locked or given up custody, locked their USDT on Ethereum. And then you need to send a variety of instructions in a cross-chain swap. You're not just going to mint the same number of USDT and then game, and then you're done. No, the flow continues. So you need to know what is the receiving address. In this case, it's good because actually the address format itself is different. So you can't just copy the same address on Ethereum. You need to know slippage tolerance, you need to know that the user started with USDT, you need to know that the user wants to get to ADA. You need to probably specify which decks on Cardano that the user is willing to, this not the user necessarily, but the protocol is willing to swap with on Cardano. Um, so you have all this additional information. So this is all being sent via message passing protocol. Then in certain cases, depending on what, well, in almost all cases really, you also need to use the the asset bridge. So if you're using like a one-chain wrapped USDT on Cardano, just for example, the user, as part of this flow, locks their USDT in the cross-chain swap contract, then the cross-chain swap contract needs to leverage the LAN chain bridge to mint the equivalent number of wrapped USDT on Cardano. And then that contract needs to receive on the contract on Cardano needs to receive both the wrapped USDT as well as the supplementary instructions and information from the message passing protocol in order to execute a swap on like min swap, and then swap from USDT to ADA, make it legal in the sense that it's all within the restrictions that the user specified in terms of slippage and all of this type of stuff, and then send it to their receiving address on Cardano. If you're dealing with an it's not gonna be a great example of Cardano, but let's just say theoretically you have native USDT on Cardano, and so the one-chain bridge or the cross-chain swap doesn't have the ability to mint the wrapped version, then it's the same idea. You still need a bridge and the message passing protocol, but you're going to be locking it on the source, the locking the USDT on the source chain and unlocking it on Cardano. So the same kind of differences with the bridge part, but in most cases with cross-chain swaps, you need both bridges because you're dealing with assets, or asset bridges, sorry, because you're dealing with assets, plus message bridges bridges, because you need to transfer supplementary instructions.

SPEAKER_02 36:19

Uh okay. That was great explanation. Before we go in how this does this all work operationally and the security assumption, any other concept in the evolution of interop?

SPEAKER_00 36:34

Yeah, I mean in practice, that's kind of where realistically we are. We have some few a few theoretical developments, which I might not even necessarily be super well positioned to talk in kind of an expert level, but definitely things like ZK Tech, you know, is going to play a lot of bridges are focused in that direction. Uh basically, you know, if we go back to that original very simplified model that I put up the front, all bridges are some sort of source chain infrastructure, some sort of destination chain infrastructure, and some sort of off-chain infrastructure. You know, we we wanna we want to shrink the surface layer of that off-chain infrastructure. That's kind of when you get into conversations about you know trustlessness or trust minimized designs. It's really about making that off-chain piece less and less important. And so things like ZK Tech, there's work being done on that, but nothing's really ready for prime time. You know, you're not out there really using real ZK bridges yet or anything like that in most cases.

SPEAKER_02 37:31

Uh intents, you see them more as layer on top, like UX, or do you think they're also a building block of interop?

SPEAKER_00 37:41

Somewhat controversially, I do not think that intent-based solutions are a great innovation of interop. I think it is something that is good at the application layer to smooth out the user experience, but is not a very good direction for core interop infrastructure. Intent-based, if people are listening, it's really at a very, very high level, just the idea that you know the user doesn't care how things are done behind the scene. They just want to just declare outcomes, and then how those outcomes are solved, the user doesn't care. So you can have all sorts of different designs to see, okay, how do we solve this? Usually it's like a network of unique actors who are kind of bidding against each other and offering the services cheaply or as quickly as possible by design. In practice, it ends up being just one person who does it because you know it's a race to the bottom and no one makes money. But I think they're they're they're good for smoothing out the experience, but we'll be in very, very bad shape as an industry if that becomes part of like the core, the core interop stack, in my opinion.

SPEAKER_02 38:42

Yeah, I I agree with you. And and maybe you know it's a bit like the DEX aggregator, this intent is more of interop aggregator, right? I like a router for your trades or your asset bridging.

SPEAKER_00 38:56

Even that I think is like a little optimistic in terms of how it's gone. Like it'd be one thing if it was just an aggregator of other solid solutions, but really it almost always boils down to ending up just being like literally one person running an agent who's like solving these. You know, we're still stuck in tokens, right? So if you're trying to try someone trying to bridge or do a crushing swap quickly, you know, shockingly often it's through literally one person running an agent on AWS, detecting this, and then you know swapping those assets on a centralized exchange somewhere and sending it to the user. Yeah.

SPEAKER_02 39:31

Really, is it is it so bad? Is it is it so bad that I I didn't know was it that bad?

SPEAKER_00 39:37

Uh oftentimes, you know, so if you definitely there's some that do that don't use the centralized exchange, that was a little bit taking a shot, but you know, it'll be people using their own liquidity, you know, it always boils down to that. So it's just kind of like whoever the solver is is what we call them, you know, they need access to so put it for the listeners in slightly more tangible forms. Let's say I want to bridge USDT from Ethereum to Tron, whatever. That's a popular route. If you go through a third-party bridge, you know, that could take quite a while, it could take 15 minutes, let's say. With an intent solution in this use case, you'll literally just have a agent, some actor who has USDT on Tron available, not doing anything. And then the user wants to bridge it. So the the agent will just take the user's USDT on Ethereum and give them USDT on Tron. And so obviously that's a much quicker thing than trying to go through a whole kind of decentralized multiple layers of smart contract logic, waiting for finality in different chains. So the intent solver, you know, will charge a little fee because they're taking on a risk, certainly, and providing a service. But you know, it's really more uh for me, I call it application level innovation, not really something I want to see more core uh what are the main intent intents?

SPEAKER_02 40:52

How can I say platform or is it I I was looking near last time I checked, they are kind of took this niche and they're pushing on it. Or you're muted, uh Temujin.

SPEAKER_00 41:03

Sorry, it's like I I don't even know if I know any that have really done amazing uh work on it. You know, stuff like the bridge is I think from a token perspective, it really they've they've done it well in the sense that they've done it well in the sense that the user experience is very, very nice. You know, it's quick and it's smooth, and they're they're they're a token bridge that leverages you know in an intent-based network. I think a cross protocol also does stuff with intent-based bridging. But you know, a lot of this is I'm not saying there's no improvements there, but it's it's really all about the user experience. I wouldn't necessarily want to build kind of like the world's well, I wouldn't want to run the world with you know very important pieces relying on intent-based solutions is really more what I'm what I mean when I say that it's application layer versus core infrastructure.

SPEAKER_02 41:48

All right. Let's talk about the security assumptions. How does that work? What should we look at when we do a cross-chain bridge or we do a swap? What are the characteristics of a bridge or a protocol that we should be critical of? Is it just the number of validators, the type of multi-sig, or how does it work?

SPEAKER_00 42:15

Yeah, yeah, again, I think this boils back down to those three pieces that I mentioned source chain infra, which is almost always just smart contracts, unless you're on a non-smart contract chain, but just simplicity for this conversation. Your smart contracts and the source chain, your off-chain relayer, that's your your off-chain component, that's how how are you looking at the source chain to confirm that something has actually happened on the source chain. Really, you're trying to solve that question. And then the destination chain infrastructure, let's just call it a bunch of smart contracts. In 2026, unless we're dealing with oh, I won't, I won't go that far, but let's say in 2026, you know, the source chain infrastructure and the destination chain infrastructure are pretty well established, well-tested. You know, most bridges, you know, running these functions in a smart contract, that's not really where you're going to expect really huge risk. You can always have cases of fraud or some secret back doors or anything like that.

SPEAKER_02 43:08

But if I trust Ethereum and Cardano smart contracts, what what's what's left is the off-chain. Exactly.

SPEAKER_00 43:16

Yeah. So the by far the more important piece is what's happening off-chain. You know, on-chain, even you can usually, if you're a relatively or very advanced user and you can access a lot of these smart contracts as code and you can review it, all this type of stuff, or rely on someone who has that ability. Okay, all this stuff can sort of be put aside because that's not really your risk. Like you rightfully said, it's what's happening off-chain. And this is lots of different versions, and complicating things matter for matters further, is that you know, this doesn't have the same stringent open source requirements or or culture that that the on chain pieces have. A lot of proprietary tech happening on the off chain piece. And part of that could be to on one side of the spectrum, to uh, you know, it's because there's a strong concern. Effort to make the off-chain piece as secure as possible. So they're not necessarily looking to open it to the public. And on the other side of the spectrum, maybe it's just really low quality construction, and you don't want to reveal that to the users. And so that's why it's quite difficult. But they you there's usually a manageable number of different ways that people these days, bridges these days, are doing this off chain piece. The simplest, totally centralized, just someone running a bot, basically, a one-of-one and processing transactions. That's kind of like a one extreme. But we don't have to talk about that type too long. In the more decentralized way, there's there's also just kind of a handful of things that people do. You know, we have multi-sigs. A lot of the listeners will be familiar with what that is. So you could do that off-chain piece with a multi-sig. Uh basically, you have multiple different actors, whether they all know each other or not, you know, will impact the risk profile of the bridge, how many there are, all these types of considerations. But basically, you have a bunch of different people who are will be observing the source chain events, and then they see it, and then they sign a transaction saying, uh, yeah, we we agree to it. You pass some threshold, and then that smart contract will trigger this the destination chain event, whether it's a mint or an unlock. So you have multi-sigs, you have NPCs, that's what actually OneChain uses for our off-chain relayer, um, which is not so dissimilar from a multi-sig, but you know, in the technicals, it's very different, but it's still the same idea. You have multiple different parties who, rather than each you know, having their own private key and signing, you're generating a key kind of together based, and then you pass a certain threshold. You can basically conceptually think about it the same as an MP as the multi-sig where enough people see what happens on the source chain, and then they sign a transaction together to trigger it on the destination chain. With these two, you know, you really need to just think about how many, how many participants are there, how the participants are selected. Those are really the the the two most important things. Of course, you for MPC and stuff, you need to have confidence that the you know the maths uh behind it and how the keys are generated are done properly. These are always tricky to talk about because you know, we as an industry know how to do this. So it's not an unsolvable technical challenge. It's just from a user's perspective, it's almost impossible to independently confirm has this been implemented properly or did they make you know human errors. But uh that that's a kind of different thing. Some bridges can use like clients, which is basically you don't you don't have the full chain data from Genesis, from history. You're dealing with you know kind of approved checkpoints or states, making decisions based on that. And then with a lot of the L2s, you're using like optimistic watches where you're just kind of assuming everything's all good, and then you have some set of actors who rather than are looking at the chain and confirming events are happening and are correct, they do the opposite. They assume everything's good. And then if they see any problems and they're like, hey, we got to double check this one. There's probably others I'm forgetting, but you know, obviously ZK also we mentioned, but those aren't really kind of in production in uh any meaningful way uh yet. But those are really the kind of different ways that you can design your off-chain uh relayer. It's not very helpful actually for retail users who are using bridges, you know, just to move their own personal friends from from one chain to another, because a lot of this stuff is obfuscated. You know, you can't you can't really even even if you had the know-how to understand all of this stuff, you don't have access to the data in most cases. So very, very difficult. And usually what I tell people is okay, you're not gonna have like 100% understanding, you're not gonna be able to have 100% confidence, but you can kind of do simple kind of stress tests to give you a basic idea. Like one thing that I always suggest is okay, if you're thinking about using a bridge, okay, source chain, destination chain stuff, smart contracts, yes, that off-chain relayer, is it permissionless or is it permissioned? What's the easiest way to figure that out? Google or go through your docs and try to see how do you deploy a node. In most cases, you might be shocked to discover that you can't. And if you can't, if you yourself can't deploy a node, it's a permission system. So if you're dealing with an MPC or multi-sig, then you already know, okay, these are pre-selected participants. And that informs your risk profile for the bridge as well. You can look at how many participants are there. This they usually publish. Projects usually publish. They'll say, like, okay, we're our threshold is 17 of 19, or it's not usually not that tight, but like 17 of 25 or 11 of 19 or whatever it happens to be, three of five, you know, they'll usually publish that type of information. So you can also use that to kind of build your own mental model of like how risky is this? It's okay, so if it's three of five multisig and it's permissioned, meaning you can't join that multi-sig, okay, now you have a pretty clear idea of what that bridge is. It's five people who probably know who definitely know each other, or at least are connected by some selecting entity who's giving these rights. And you only need three of them to agree to steal all the funds in the bridge, basically. Because if that relayer fails, they can basically do whatever they want because they're the ones who are determining from the bridge perspective that something actually happened on the source chain and are triggering events based on that information on the destination chain.

SPEAKER_02 49:06

So for the listener, MPC is uh multi-party computation.

SPEAKER_00 49:10

So it's uh Yeah, yeah, that's right.

SPEAKER_02 49:13

Let's not get into it. So maybe can we can we make names? Meaning you you meant one chain is MPC. Can anybody participate in the computation? Is it permissionless?

SPEAKER_00 49:26

Yeah, so one chain is permissionless. So you can go and deploy a node and join the set uh right now. It's like a stake-based mechanism. So you stake assets and then there's an election cycle on a basically a monthly basis. Each epoch is a month, so that's how that one is handled. So this one is a permissionless MPC set.

SPEAKER_02 49:47

Do you know of the other, let's say the top three, top five other protocols? How what are their security, uh MPC, multi-sig, uh, or is it just one guy, one single key? For example, let's start with layer zero. Do you do you know how they do it? So layer zero is quite cool.

SPEAKER_00 50:07

We're talking V2. So layer zero, they're kind of one of their differentiators is they basically allow you to configure the off-chain piece based on your own deployment. So I think they call them like DVNs. I'm trying to remember what that stands for, but that's basically your verifying network. You can kind of sort of configure that. So if you want it to be a single person, you can deploy your. You know, we talked, we joked about how people are just using message passing protocols like Layer Zero to deploy token bridges. So if you're building a bridge with like the message passing protocol and you want it to be a one-of-one, you can use layer zero to do that. Theoretically, that means you can also make it as decentralized and permissionless as you want, so long as you file you that might mean though that you have to build decentralized permissions and off-chain relayer from scratch and and and plug it into layer zero. So very, very high engineering threshold for that. Layer zero, I think, is is the the tech is very cool, though not a concern. Because I, you know, I also don't want to like paint this in the wrong light because you know we joke also about the one of one, but one of one does not mean not secure. You know, one of one could be maximally secure if you trust that one person. And in a lot of cases, especially at the enterprise level, maybe one of one is a little extreme, but you know, they they uh when you maximize security, one way to do that is to sacrifice decentralization. So it's not necessarily that you know you have to be decentralized and permissionless to be secure. Definitely I don't want that to kind of be the takeaway. So you could do a layer zero to make it as decentralized or decentralized as you want. In practice, I think something like 99% of the transactions that go through layer zero either rely on their default in-house relayer or are run by the client themselves. And these are all centralized, basically. Centralized, not decentralized. So in practice, most of the layer zero transactions will be closer to a permissioned centralized set, either using the default layer zero relayers or like tether uh uses layer zero for like USDT zero. Another situation where a one-of-one, again, slight exaggeration, but a small set of centralized entities is put in to maximize the security. So it's layer zero trusts no one more. I mean, tether trusts no one more than themselves. Same thing with Circle. So they put themselves in that position and then they're very comfortable. So that's kind of layer zero. But tech, very, very cool. I'm actually quite a quite a fan.

SPEAKER_02 52:38

How about CCIP from Chainlink?

SPEAKER_00 52:42

Yeah, CCIP is a kind of a funny one too.

SPEAKER_02 52:45

They're all funny.

SPEAKER_00 52:46

Yeah, they're everyone's every everyone is funny. So they they obviously have a pretty expansive Oracle network, so they leverage that Oracle network to do this off-chain relayer because Oracles are very similar to bridges. If you want to be very loose with your definition of what a bridge is, you can just say like an Oracle is a bridge. But regardless, we don't need to get into that conversation right now. But so they leverage the existing Oracle network, but they have a permission set of nodes that act as a fail-safe. So if you're really kind of boiling it down to the pure security profile of it, then it's best to treat it as a small permissioned set of nodes because they have that fail-safe in place that can you know freeze deployments and things like that. I think they I'm kind of going outside of my own area of expertise here, but I think in the original kind of white papers and stuff like that, the CCIP ultimate vision is to be a little bit closer to layer zero, where a lot of these components become configurable to the specific client. But as I understand it today, they're you still basically default to this permission set of nodes below the larger Oracle network.

SPEAKER_02 53:54

Who else is out there? Wormhole. Do you know?

SPEAKER_00 53:58

Yeah, yeah, wormhole uses MPC as well. Theirs is a permissioned MPC network. So you can't go and deploy your own node. I think they also have a sizable set. I think I think they have like 19, unless something has changed in the last little while. But I think they have 19 permissioned actors who are doing the validation for Wormhole. I don't know if you're gonna ask this one next. It's CCTP, I think, is one that's worth mentioning as well. Uh that's circles.

SPEAKER_02 54:23

Yes, we just we just launched USDCX on Cardano, right? So yeah, I think by by volume is the actually the the biggest messaging protocol. If you go on DeFi Lama, I was looking before the recording. Yeah. They are number one by 24 hour volume by a large margin.

SPEAKER_00 54:43

Yeah, and they're they're very cool in the sense. And again, it kind of goes back to what we were, or the amendment that I added as we started this, where it's like centralized isn't necessarily bad if you're talking about security. So this is a perfect case for that. You know, CCTP is Circle's in-house messaging protocol and it services exclusively, at least today, their native assets that they themselves issue, USDC. And so in this way, Circle can own every single part of that simplified bridge infrastructure I talk about. They own the source chain infrastructure, they own the bridge, the messaging layer, they own the destination chain. And so they're very comfortable with that. And CCTP is is interesting in that they, you know, they allow other bridges or anyone really to use CCTP, and then you just basically ping them to oversimplify that something has happened on the source chain and that you're trying to do this bridging with USDC. And then their off-chain relayer will confirm that that has happened. They will issue a so-called attestation saying that yes, this has been confirmed to have occurred, and then you use that attestation to trigger the destination chain smart contract, which allows bridges even like OneChain, who have integrated CCTP for USDC. Then you know, from the user's perspective, the you can go to the WanChain bridge and other bridges as well. But you can go to the OneChain bridge and burn and mint native USDC via that interface. Um, so back to those four kind of building pieces. Before we're all with third-party bridges, we're always talking about it's either lock and mint, burn and lock, or lock and lock. Because sort of because this is all circle from top to bottom, you can do a more interesting, you know, burn mint. So you're actually removing it entirely different from circulation on chain A, USDC from circulation on chain A, and minting new, redeemable, indistinguishable from native USDC because it is native USDC on the destination chain. So also quite cool.

SPEAKER_02 56:45

All right. We we have spoken about the mechanics, the security assumptions. What went wrong in the past? There's a lot of stories of hacks and failures. And uh, do you have uh on top of your mind a hack or an incident that we can kind of see what went wrong and what we've learned since?

SPEAKER_00 57:06

Well, I don't know about that second question, but I think everyone who has been everyone who has been in crypto long enough can think of various bridge hacks that have occurred, you know, big ones relevant to Cardano. There was the Nomad hack several years ago. There's been the wormhole hack, also a huge one. There was multi-chain, which some people might have forgotten that they existed, but at one time they were by far the the biggest, most popular bridge out there. And overnight they ceased to exist and just vanished into thin air. So maybe we can talk about that one. But that one's quite simple in that basically they had a backdoor in their smart their smart contracts when just took everything.

SPEAKER_02 57:46

I mean, I I I wouldn't call this a hack, right? This is uh cheap hack.

SPEAKER_00 57:51

This is more like uh low budget hack.

unknown 57:55

Yeah, yeah.

SPEAKER_00 57:56

But there, but there, but there's tons like that. You know, you but I think you it's it usually boils down to it's not like how do I say this without offending the entirety of the listenership. You know, when you have bridge hacks, it's basically not something that is the the root cause of that hack is essentially never been something fundamental to cross-chain technology itself. You know, it's not the crit the core cryptography that has failed, it's not properly implemented MPC or the maths underlying, you know, the the key generation, if properly implemented, that's failed. It's not the underlying L1s in most cases, at least the major ones, you know, that it's not like Cardano consensus has failed. It's always just either something with how that off-chain piece is verifying what's happening on the source chain has not been configured properly, or that there's some key management issues, a multi- you know, uh a private key leaks, and then someone can take over the multi-sig, or you know, social engineering and this type of stuff too. Or like we just mentioned with multi-sig, you know, there's just like a backdoor. So it doesn't make anyone feel any better because if you lose money, you lose money. And that's in my head, I think that's probably why I also loop in multi-chain into that as well, because even though that's quite a bit different from like a key leak via social engineering or a verification bug, like I think would happen with like wormhole and and and nomad. You know, from the users, they don't really care. You know, like they at the end of the day, they they they lost their money. So I could put them all all in the same basket.

SPEAKER_02 59:34

Researching for this episode, I looked up the the biggest hack was the Ronin Bridge in March 2022. 624 million. And the exploit was social engineering, and they got five private key out of nine, which is which is insane.

SPEAKER_00 59:51

Yeah, I always joke too, you know, that with these specific types of leaks, you know. I uh or how should I phrase this? I would say, you know, that that's why when you're evaluating you know different bridges, multi-sig, you know, they'll usually be pretty straightforward, you know, pretty open because you can knowledgeable people will be able to tell on chain if you're using a multi-sig or an NPC or something like that. So like they'll usually be pretty forthcoming with what their thresholds are in terms of how many participants there are in the multi-sig, for example. So like with the Ronan Bridge Hack, it wasn't a secret that there was well, I think you said nine, right? That you only needed five to five out of nine to exploit the bridge. So, you know, this is stuff that was publicly available. And as you're evaluating bridges, you know, these are the types of things that regular users can take into and kind of developed a reasonable, a reasonably accurate kind of risk profile. It's like, okay, if you're if you if your multi-sig has a hundred uh participants and they're permissionless, yeah, you could and and the threshold that's just make something up, you know, is 60 out of 100. Yeah, they could you could say, oh yeah, maybe 60 people will be socially engineered and lose and leak their private keys, but obviously that's very unlikely. But if it's three out of five, five out of nine, suddenly you're very much in the realm of possibility. Um, especially if it's a permission system and they're not being and the project's not being very forthright about who the who the signers are, you know, then all of a sudden it might be nine signers that work for the same company that are all on the same server or some some number of it. So suddenly it becomes way less far more believable that you know social engineering could you know crack this type of system, even if there's you know$600 million in it. You might you might be tempted to assume that proper security measures have been in place, but more often than not, especially in in blockchain, that's not how it is. Yeah.

SPEAKER_02 1:01:56

All right. Looking maybe is is not a question necessarily about interop and bridges, but I think it makes sense to touch it with you. I would like to know what you think. It seems to me that uh block space now has become readily available, you know, with so many blockchains, you know, Solana, Ethereum, Cardano, Definitely near, all the layer twos of Ethereum. So it seems that the you know, the the kind of block space there's more available than the demand is. And now we have seen, for example, in the Ethereum Ward, the going back to the one-chain maximalism where they're trying to consolidate everything back to to one-chain only instead of having this sharding and fragmentation. Uh, do you see this trend continuing and does this have an impact on how you see your company going forward? Because if if we really see this consolidation to just uh a few layer ones, maybe Bitcoin, Ethereum, Solana, Cardano, of course, uh, there will be less need of interop. Or how do you see this?

SPEAKER_00 1:03:09

I think I definitely observe the same things you're observing, of course. And we're probably today, the the specifically like the Ethereum L2 and sidechain expansion was probably too aggressive. And so I do agree we probably will see some some call consolidation. I don't think that the original vision for why interoperability needs to exist is under any threat. You know, I don't think we're going down to one chain, but I do think we can prune around the edges in terms of how many chains are currently needed, particularly in the Ethereum L2 space. Kind of conflicting with that point of view is enterprises have started to arrive. They've always been there in the background, but they've really stepped up over the last couple of years. For better and for worse. Yeah.

SPEAKER_02 1:03:57

Yeah. One of the things that emerged with the conversation with enterprises that many of them build their products with Corda, Hyperledger, Ethereum Besu, or you know, the Canton, the first iteration of the network that was kind of private. And they realized that doing something uh permission private chains defeats the purpose of the blockchain, right? You might as well use a central database. So now they are coming to the layer ones, and there's a lot of demand for either they either they start from scratch and they build on Cardano, Ethereum, Solana, or they're building interop bridges from those enterprise blockchain, like you know, Hyperledger is maybe the most famous, then Corda, then things are happening in this direction.

SPEAKER_00 1:04:52

Yeah, yeah, absolutely. And and I I I know you're very well aware of this this history, but I think you know, in the earliest, the earliest days of enterprise, you know, you definitely had this sense where the various enterprises were very keen to run their own blockchain. And they were like, oh, we can just get all of our clients to come on on our chain. And then in practice, they realized that you know this didn't happen because in the same way that they weren't willing to go on someone else's blockchain and put all their kind of proprietary data on that chain, similarly, their partners and were not willing to do the same. And so that kind of, as you mentioned, you know, turned their eyes back towards to the public space. Maybe there is, maybe this is how the the public chains start to fit into the puzzle. Where I think, and maybe I'm concerned, I don't know, but where I think things are kind of going is you're kind of getting a new class of blockchains emerging. So while I expect to see like the the fully public L2, Ethereum L2 system start to consolidate, we'll start to see the emergence of new chains that are. Run and operated that are like sort of semi-public. They present themselves as public, but their primary client is meant to be enterprises, meaning you'll have a lot of the features of a public chain, but a lot of the fail-safes that you would expect to see in a closed system. You can see this with like chains that are maybe owned, you know, like by entities like Coinbase or potentially even Layer Zero, as that kind of comes into further view. So I'm I'm kind of looking into seeing what happens there. So rather than purely being here are kind of some totally permissioned enterprise chains and some totally public retail chains, and how do you interoperate between the two of them? You might have this third kind of hybrid class where you is can is Canton an example or Canton's very cool. I think probably it'll be hard to replicate Canton. So they're almost in a category of their own. But I think they're probably their unique design probably comes from the same place where they're uh a third party that is building a blockchain specifically to be compatible with permissioned use cases, which I think is really where a lot of the enterprises' enterprises live. So we have to kind of see how that how that plays out. But as long as you have different types of chains popping up, you'll have more than one chain, you'll have a need for interoperability. So interoperability, I think we said at the at the top, you know, has changed a lot over the years. And I don't expect that to change. I don't think we have reached the so-called end game of interop yet.

SPEAKER_02 1:07:32

What do you think? Uh maybe last question, what do you think is the end game? What's the biggest unsolved problem, or what do you think the future of interop in five years will look like?

SPEAKER_00 1:07:44

We're not going to get there in five years, but very long term, I think, for the well-being of the industry, um, we need to get to the point where interop is the interop providers are they themselves interoperable. And one of my concerns right now is we're going in the opposite direction right now. The interoperability solutions are increasingly positioned as kind of product level implementation. So if you build something with one message passing or you know, one bridge or one message passing protocol, you know, the the output of those things are not compatible with other providers. So you get it, you're you're you're really kind of at risk for vendor lock-in that is going to be very, very expensive to unwind. And that's because the pieces between the blockchains, the interop stack, has never fully been embraced by the industry as part of kind of core blockchain technology. It's always been something else. And my long-term vision is really, you know, we've got to get to the point where there's enough kind of industry-wide standards in place where the interop providers themselves, you know, are interoperable with one another. Not super optimistic because we're not going in that direction. You're getting specific players who are getting very, very big with proprietary solutions. And more concerningly, you know, I know that a lot of the the big guys, they don't, they don't want industry-wide standards. They don't see the need because they're in such a powerful position. Um, so all that to say, five years, I'm not uh super optimistic. But within within that five years, I think there's still going to be some very exciting and interesting things happening. Right now, at the kind of retail level, I think chain abstraction has a lot of potential. We've really, as an industry, not been very good over the years for a lot of reasons at creating seamless user experiences. Uh, the idea of a wallet and needing to sign transactions and all that is maybe incompatible up till now with seamless user experience. But stuff like chain abstraction, I think, will will help smoothen a lot of that out. And I that's the type of stuff that I expect to see in the short term, uh, where users really they don't need to care. Um, and they don't most of them don't don't care really what chain their assets are on or what chain they're really using. Yes, you have like tribalism, things like that, but that's what I'm talking about, like people who actually want to use applications.

SPEAKER_02 1:10:11

I do I fully agree with you, but I find as I do think Cardano is one of the most decentralized layer one, right? And so it it it pains a little bit to me that if people don't care about which chains they're on, we might end up with uh more centralized chain or or like decentralized it. The whole purpose of a blockchain is uh you know self-sovereignty, and we might get into, you know, yeah, I don't care which chain I use, and then you use a very centralized chain where you have no self-sovereignty, right? That's that's the dark side of it.

SPEAKER_00 1:10:47

I'm worried we're gonna end on a very somber note because I I do agree with a lot of what you said. You know, at the top, I think I I mentioned originally I was drawn into blockchain as a whole by this romantic promiseness of the whole world running on decentralized tech on blockchain and all the advantages that that brings. I think as the industry has moved forward, and as you can see, I don't I don't think you would say that on a whole blockchain since the launch of Cardano and the blockchains that have followed have become, on the whole, more decentralized. As you said, Cardano even today is still amongst the the most decentralized, certainly. Rather, we're seeing kind of the opposite. We're seeing a willingness to sacrifice decentralization for higher speeds, greater output, and I think, and worry that that is only going to that that trend is only going to continue, especially now that enterprises are coming into play, and they've shown rightfully or wrongly that security is more important than decentralization to them, and they're not after you know some decentralization for decentralization's sake. You know, they they are more than happy to have fail-safes in place and to be able to click stop and all these types of things that that that that you might have to give up in 2026 or 2027 to really have super high throughput and with high security. So yeah, I don't want to end too somber. That's why I'm also hoping you know these same issues are reflected in interop. The the the the market leaders you know are not promising maximum decentralization. That's not the pitch. You know, the pitch is you, issuer, are in control, and that is somewhat incompatible with decentralization.

SPEAKER_02 1:12:36

All right, Temo June. That was awesome. Thank you very much. Uh, it was super insightful, and we should do this again in five years to see how accurate we were with our prediction. Thank you so much.

SPEAKER_00 1:12:50

Absolutely. And and let me just say, I hope we were not accurate, that the industry takes a sharp left turn. Decentralization becomes the goal once again, and we can move forward in that direction.

SPEAKER_02 1:13:01

Thank you, T.

SPEAKER_03 1:13:03

Thank you for joining us on Let's Talk Cardano. For more insights and deep dives into the world of blockchain, don't forget to subscribe and reach us at CardanoFoundation.org, where you'll find extra resources and content on all things blockchain. Leave us a review wherever you enjoy podcasts. Follow us on social media, and stay tuned for more coming soon.