EP.44 [EN] - Dmitriy Berenzon: On the Crosschain Solutions and their Trade-offs / 关于各种跨链解决方案与取舍
56:46 Share

Hello and welcome everyone. I'm Mabel Jiang, the host of 51%, a podcast series presented by Multicoin Capital. This show is the exploration of blockchain's rapid development across Asia with a particular focus on the perspectives, communities, and operators based in China. My goal is to bring Eastern perspective to West and Western perspective to East so you can better understand the crypto's unique market structure and how these distinct communities think and operate.

This podcast will feature a mix of English and Chinese discussions. The language you're hearing now will be the language I use for the rest of the podcast. Stay up to date with my latest episode by subscribing to this podcast. Thank you for listening.

Mabel Jang is a principal at Multiquin Capital. All opinions expressed by Mabel or other podcast guests are solely their opinion and do not represent the opinions of Multiquin Capital in any way. This podcast is for informational purposes only and should not be construed as an inducement to make an investment or led upon as investment advice. Multiquin Capital may at times hold positions in some of the tokens or companies discussed on this show.

Hello, everyone. Welcome back to 51%. I'm your host, Mabel Jang. Today, I'm extremely excited to have Dimitri, the research partner at 1KX Capital, to join us. Welcome, Dimitri. Thanks for having me, Mabel.

No problem. Before we get started, can you give our audience a self-introduction about what you were doing before crypto and then overall, when your time in crypto, what you've been doing and also right now your job at 1KX?

Yeah, for sure. What I was doing pre-crypto was more in traditional finance. Spent six years working for a bank, the first four of which were spent across a variety of strategy roles, often building out internal fintech products, things around real-time payments, big data analytics. Came across Bitcoin in 2013 because I was doing research for the bank's head of payments.

And at the time I was living in New York and we had offices on Wall Street and there is this place called the Bitcoin Center that was ironically right near the New York Stock Exchange.

So I would go there and see people trading Bitcoin peer-to-peer and selling custom ASICs and saw Vitalik there in 2014 when he was doing the Ethereum presale, but didn't really think too much about the tech, just wasn't excited about magic internet money, but did recognize that software was eating finance and I

I think around 2015 at the time, wanted to help the bank compete. So I spent my last two years there building out their innovation labs. And that was more on frontier tech, particularly machine learning. But we did an early blockchain proof of concept in early 2016, at which point I said, okay, some other use cases outside of payments, but still a lot you need to do around blockchain

developer tooling and regulatory clarity. So really still not bought in and actually wanted to do more of a career transition and decided to go to grad school to Berkeley and came across this group there called Blockchain Berkeley that had this really great course on Bitcoin from more of like a

computer science game theoretic perspective. And that was finally my aha moment where I realized that the last 10, 20 years of fintech innovation was mostly around channels, but they were still building on antiquated infrastructure from the 70s. And so I really dove into that rabbit hole. Since then, I spent a year working with a crypto fund called Coin Fund, mostly doing research and due diligence.

Then joined a crypto family office called Bollinger Investment Group for two years, leading research and investments there. And then I've been with 1KX since early this year. My role is effectively three hats. One is research, which usually means going down into different rabbit holes for a few months and coming out with some content that I think is going to be helpful for the ecosystem. And obviously the bridges was the last piece, but I've written on everything.

automated market makers, the intersection between NFTs and DeFi, gaming governance kind of across the spectrum. The second is working with portfolio companies, helping them with token design and distribution, go-to-market strategies, hiring, things like that. And the last is investment due diligence, trying to see what's around the corner.

Cool. That's awesome. You really had a pretty colorful background. I didn't know you were in for so long. I mean, it's funny that you mentioned you were in the Berkeley Blockchain Club. I forgot the name of it. What is it called? Blockchain Berkley.

Oh, okay. Blockchain at Berkeley. Yeah, because I knew I think a few other fund managers I knew were also part of that. It sounds like it's a really large, very influential student group there.

For sure, for sure. And the school in general. I don't know if you've read the Cypherpunk Manifesto. It was an early piece of culture that influenced really the Bitcoin movement. I was surprised to learn that actually a UC Berkeley student wrote that. So I think there's something about that institution as really trying to create ways to empower individuals and kind of push back against

I guess, institutions and I guess antiquated power structures. So yeah, I think like there's a ton of people in crypto from Berkeley as a whole in addition to the student group. - Yeah, absolutely. Actually quite a few of the portfolio that we were backing and the deals that I led, they had the founders from Berkeley. So that was super cool. - Amazing. - Yeah.

So you mentioned your work at 1KX as a research partner there. And then we were just talking about you were referred to people as the bridge guy recently because of the article that you wrote. So I'd really love to expand on that topic a little bit more on this podcast. So I'll start with the seemingly obvious question. Why is cross-chain important?

Yeah, let's start with that. For sure. I think it's important for a number of reasons. I think the most basic idea is to give users freedom and I think to enable innovation. I think the place in general has a lot of maximalism and I think

There is so much of a design choice between creating these state machines that I personally do not believe that you could have one that does it all. And that cuts across different areas. You have...

trade-offs between, for example, decentralization and performance. You have certain performance attributes or certain applications that you could optimize your entire structure for. So that is huge. And I think you need to get to a place where you allow these state machines to really go in the direction that they feel is best. And

That's one component. Another component is also geographic. A lot of these chains have this strange correlation between a user base in a specific region.

So I think just that, you know, I almost look at it as languages and the network effects that languages have. And you tend to have these emergent countries. And I think you need a way to give both users and developers a way to really travel between different countries.

So that's kind of really high level how I look at that. So like very practically, that could mean being able to port assets and giving users the choice to define which assets they want to hold on which chains gives them access to different applications on each chain because you need those assets

For developers, I think it unlocks a lot of interesting use cases that you could be doing once you have access to these different applications. So I think it's broadly great for the space. And I think Cosmos and Polkadot had this vision a long time ago, but I think they also got the order of operations a bit better.

backwards where I think you needed some use case. And I think after like sound money, you know, DeFi was really that use case. And I think, you know, Ethereum was like one of the first

uh, state machines that had some, uh, critical mass there. And so the other, uh, uh, you know, a bunch of other base layers that said, you know, we need access to that capital and to that user base. Um, and, and, uh, that kind of led to bridges being a necessity, but I think it also opened the minds of, of developers and users to say, Hey, we could actually have, um, application specific chains, application specific L2s, um,

maybe even at one point, like function specific chains. So I think the kind of, you know, Pandora's box is open now. And I think we're going to continue down this trend over the next few years.

You gave so much information that I actually wanted to ask you a few different questions. So I'll probably track down each of them. First of all, I was a bit surprised that you said the geographical component, because I would actually assume that was more of a 2017-18 kind of narrative about like, oh, this is the Chinese version of Ethereum, this is the Indian version of Ethereum, whatever. Yeah.

And I understand, you know, in terms of marketing perspective, there are certain chains are more popular in some, you know, some countries or region or whatever. But like coding languages, they're all the same. So technically for developers, the decentralized application developers, it should be the same for them to develop on. Like why would, I mean, I guess like the users of the chains made the

quite a bit because of the marketing on, you know, you set the language barrier, whatever. But wouldn't be, you know, the developer marketing be the same for any Chang? Totally. I don't think it's black and white. And I think it's also a sensitive topic from one perspective. And I think it's definitely...

changed over the years. And I think it tends to be just these soft networks, these off-chain relationships that tend to happen between the founding teams or the core developers of a certain chain and then their relationships of the initial core devs that start to build applications on that chain and then the friends and the networks of those developers.

So it's a very weird, like emergent phenomenon that I think happened. I think now because the broader user base and retail awareness of crypto has been much larger today that you'll start to get, for example, developers that

just evaluate a certain L1, L2 by their performance properties. And I think that's where we want to get the industry at, where you have a clear understanding of what are the pros and cons of each chain that you're building on. So I think we're getting there, but I think it just so happened that, you know, like,

founders of these chains had their own networks and they just organically kind of spread from there.

That's kind of true. I think another component, you know, a lot of us right now today at crypto who are web free maximalists or whatever, like may not agree to. But I think inevitably we might face a future where there are some mixed chain, which means that some part of it is actually gated or permissioned.

So then you actually need some sort of cross-chain solution for that as well. And I do think that's going to be more regional focused or country focused per se. Sure, sure. Right. And then the other thing that I wanted to discuss is you just mentioned Polkadot and Cosmos. I mean, usually people call them...

categorize them as layer one as well, but technically they're also cross-chain. So I wanted to ask you about Polkadot more specifically because they've been using this parachain structure, talking about this for a long time. And then it's more kind of you can categorize that as a sharding design. So when it comes to Decentralized Finance, when you need to update all of these different applications with the

the data instantly, won't you be worried that there's always friction if you're using sharding design? Or how are you thinking about the UTAs? Maybe your answer is that the cross-pair chain communication doesn't have to be anything related to finance. It could just be something else like the actual applications. I'm just curious what your take on this one.

Yeah, I mean, a part of me wants to see what happens. You know, we have a lot of these really robust theories, I guess, of what ifs. I would love to see...

and to see what happens if something goes wrong. And I don't think we've gotten to that place yet. And maybe I'm just not aware. But I think the interesting answers are the ones that we are going to get in practice over the next few years, because it has taken a while for these chains to really develop

have the functionality that they promised back in the white paper days. IBC is now live on Cosmos side. Kusama is doing a lot of interesting things. And then Polkadot is starting to, as a network, get off the ground. I would just love to see how much of this actually is an issue in practice.

There's concerns about charting. There's concerns about security in optimistic for zero knowledge systems. And I've just been growing to be more practical and just say like,

let's see what breaks. And that'll probably give us the answer. Where we haven't really seen, I think, any truly cross-shard DeFi. I think the obvious answer is most DeFi, you could argue that most of it is going to sit on one shard or a small number of shards. Right.

That's also possible. Yeah. Yeah. I think like, like that's probably what's going to happen, especially if you need atomicity and if you need to enable things like flash lens. And you could argue that's going to be a similar case for like the L2 landscape on Ethereum. But yeah, I, a part of me just wants to sit back with the popcorn and see what happens when these things are like,

No, that totally makes sense. I mean, reality is that also not all the DeFi protocols have to be

that high frequency, you don't really interact with them all the time. That's another argument. So I think we'll see. I think that's probably the panacea answer for this kind of questions. And then you mentioned a few kind of use cases for cross-string. But then what, so today, like people obviously like usually talk about like using cross-string solutions.

to port asset from one smart contract platform to the other. Are there any other things that are being less discussed? Yeah, I think there's combinations of things you could do. So generally, yes, you could port assets. So you could send like USDC to Terra, for example, to buy some asset on Mirror.

This could also, you know, it doesn't have to be a fungible token. You know, I could ideally take my NFT, my top shot from Flow and port that onto Ethereum, for example, to use as collateral on, for example, NFTFi.

So I think even just that is going to be a ton of unlock with these novel use cases. I think it also, from a protocol perspective, increases the design space of what they could do. For example, I can imagine a urine ball

that has farming strategies that cuts across both Solana and Avalanche. I could also imagine having like an index on index co-op that has a variety of proof of stake protocols, which you can't do today. So I think it gives you a lot more capabilities for the protocol.

And then I think it'll give developers, traders some interesting things that they could do. You could do some interesting cross-chain arb, assuming that there is some non-stable asset across multiple base layers or L2s or whatever.

some sushi or whatever, like you could do, you could arb that across DEXs on multiple L2s. So I think there's a really wide design space there. And I think you need to unlock that innovation and have like those tools available. And I think devs will find really creative ways to use them.

Right, absolutely. That definitely sounds exciting. I actually didn't know, I didn't place close attention to NFT5. But now that you mentioned it, I realized that you can actually port a flow asset onto Ethereum. That's actually super cool.

Yeah, so in the article, you actually broke down the bridges into a few categories from different angles. I actually really like the way you do it. It's like horizontally and vertically and whatnot. And I think crypto is always about the design of different infrastructures, always about trade-offs. So...

What are some of the angles that you categorize these bridges? And then maybe you can walk us through the trade-offs among these categories. Yeah, totally. So you have a couple of ways to look at it. I think overall, there's also a caveat that

says there are things that do not fit perfectly into these and it's really some form of a mental framework to help uh uh bucket them but there's a lot of uh exceptions here and i've had teams you know yell at me after i publish this no like this is wrong wrong bucket because uh x y and z and and and so i i

you know, can't avoid getting people upset, but I try to find some, some middle ground. Um,

But in general, one angle is actually like what kind of bridge is this? Like what's the type of bridge? And the most basic is like an asset specific bridge. I think wrapped Bitcoin is the most obvious one. You also have like wrapped Arweave, for example, that's being built.

and ported on Ethereum. So you could have bridges that just focus on creating some synthetic representation of an asset on some destination chain.

You could also have a chain specific bridge, one that just focuses between two different chains, point A to point B. Obviously, like the Avalanche bridge is between Ethereum and Avalanche. The Terra shuttle is between Terra and Ethereum. The Ronin chain or the Ronin bridge is between the Ronin side chain and

and Ethel One. Wormhole is between Solana and Ethereum, but I think they've expanded to support more now. So that's another flavor.

A third is application specific, where the bridge is the application in a way. So when you think about the compound chain, I guess they're calling it a gateway. You're enabling users to use other L1 assets as collateral and them using

the application is by nature using the bridge. So it just like it does one thing and that's the use case. And you could argue like ThorChain is something similar but for asset exchange. So like it just does one thing that it's meant to do. And then the last is something more generalized.

This, for example, could cut across multiple base layers and it could do some mix of

Asset transfer, potentially like minting assets or carrying general estate. So potentially like a catch-all term. So things like Connext, that's really good at asset transfer, particularly across today, like multiple EVM chains or IBC chains.

that is used primarily within Cosmos today, but there's ways to support IBC from other base layers.

So I think that's one lens. There's another lens that looks at what is the validation mechanism of these bridges? Basically, how is this thing actually bridged?

And like the three flavors there, one I call is, you know, some external validator set. And this is usually like some group of nodes that are staring at some like,

inbox on some source chain. And then each of these nodes, they agree on whether some action happened or some asset was sent by some address into that inbox. And based on that, they are going to take some action on a destination chain.

So you're, you're relying on this like external party to really verify what's going on between two chains so by nature, your security is defined by that validator set. And the big trade off there is it's usually going to be less secure than the source and destination chain that you're bridging.

it also gives you a lot of flexibility in the kinds of things effectively like these validators could do. So that's one bucket that's probably the most popular one that we're seeing today. Also probably because it's like the easiest to implement.

The second is like a light client system, and that is effectively a system where each you have contracts that natively verify block headers of the two chains that they're bridging.

So for example, if you're trying to bridge Polkadot and Cosmos, for example, you would have a Polkadot-like client running on Cosmos and a Cosmos-like client running on Polkadot. And they would each natively verify the block headers. And the benefit there is you are

You're relying on the security of the underlying chains. So there's not really any trust assumptions here. It's a really safe way to do bridging. But it's also really expensive to do that verification. And these things are super hard to build.

So it tends to take a long time to support other consensus mechanisms and other signature schemes.

And then the third bucket I call a liquidity network. This is really just like an off-chain system that has parties that hold liquidity or hold some inventory of assets between the chains.

that they're trying to bridge. And then you effectively have like some way to do like an off-chain exchange of these assets, but with guarantees

of layer one equivalent security due to dispute mechanisms and things like that. So it's generally also like a very safe way of bridging, but it's sort of limited in the things you could do because it's basically good at just exchanging assets and it's more difficult for it to do more robust things. Like it can't mint some synthetic asset on some destination chain.

So those are like the three main buckets there. And I think a last way I cut it is by the trust model itself.

And this is probably more contentious here. And I think there are teams that will argue otherwise. But everything's on a spectrum. There's trusted on one side, trustless on the other. I define trustless by generally the security is equivalent to the base layers that you're bridging. Trusted is that you're relying on people

validators to behave correctly. And there are arguments that say, you know, like they have their reputation at stake, you know, like, like, they would never do something bad, because their, their, their names are known in public.

And then from that trusted system, there's ways to do better, I guess. You could have these usually validators or some actor bond some token, either some native token or another asset. And that bond, if they misbehave or they just make a mistake, they get slashed.

And from there, there's another layer, I guess, where what happens to those funds that get slashed? And I consider it to be an insured model if the slashed funds potentially go to the users as well. So that's like another layer of safety.

So I know that was a lot of categorizations and there's a ton of new ones there, but yeah, that's broadly how I view it. Great. Well, I was going to say for people who didn't want to take notes, you can actually go visit Dimitri's work. I think they're actually very well summarized in the article. Yeah, I would also assume that the ones that get most kind of

what do you call it? The contended contention is probably the, the ones like how he did this categorize the trusted versus insured versus bonded versus trustless. I think that was the four, right? I, I don't have it in front of me. Yeah. So I think, you know, this is kind of interesting. It's like when it comes to the, the, I think Thor Chang, you categorize that as,

insured model. Yeah. Right. And then I think most of these insured ones, they actually had quite a bit of challenges in the past, you know, things like the hacks and stuff. So I actually wanted to dive slightly deeper into, you know, this specific area and kind of ask you, like, maybe you can chat a little more about, you know, those hacks that these

specific types of crashing bridges had in the past and what were some of the major reasons for these because you did mention that they are really extremely hard to build

Totally. I mean, in general, I think that users are probably going to lose more money in cross-chain bridges over the next few years than DeFi, like by any order of magnitude. Because these are things that deal with distributed systems and cryptography, and there's a much bigger attack vector or like attack surface there.

So that's in general. And what I want to push projects to do is to think more deeply around what happens in the unhappy case and to make sure that users are as safe as possible. And I think trusted models are okay as some go to market, but I think you should probably...

figure out how to shift that along the spectrum to something that's safer for end users. Because if you think about facilitating billions or trillions of transaction volumes across these chains, you really want to make sure you have some mechanism there to protect against unhappy cases.

I think one of the biggest ones was the Poly Network. That was the biggest one. It was around like 600 million that was hacked, which, by the way, is more than the Mt. Gox hack in 2014, which is like 450 million. It's probably the largest in the history. Yeah, totally. But the interesting part there is...

Kind of going back to my categorization of trustless, there's an assumption within every project in that bucket that their actual code is safe.

And that's the difference. That's a very critical difference between research and engineering, because you have something that looks good on paper, but the way you implement it might have issues. So with the poly network hack, it wasn't really like a fundamental design issue.

issue and it wasn't like some malicious validator. It was really like an external hacker that exploited one of their contracts and they basically didn't have the required permissions in that contract.

And the hacker was effectively able to just like grind out a certain string of numbers that allowed them to do something that they shouldn't have done. It wasn't as drastic as like fully recreating a private key. Like it took some work for them to do.

to figure out like, I don't know, a password effectively. Go ahead. No, I thought they bypass all the multi-syncs.

My understanding is that there was a function there that you effectively needed to call a certain target contract. You didn't prevent users from calling that contract.

So the user had to find specifically the right data that was able to trigger a function that changed the public keys on one of the contracts. And that's how they're able to divert the funds.

So they were able to grind out some input that produced some output that would allow you to do a thing on a contract that wasn't intended. So there was no need for like a private key compromise. You just had to like grind out the data.

So, so that was more so like a oversight on their, on their contract design. Like you basically need to make sure that if you have like a cross chain relay contract, you have to very clearly define what that contract can and cannot call.

And I think like in the implementation, you need like a better like separation of concerns and to not create like these special privileges. And so that was actually my understanding of that.

what happened, which again, it was like totally different than, than all these like trust assumptions that I talk about. It was actually like the, the, the implementation had an issue there. And, and by the way, like you could have these issues across like every part of the

Like if you're doing like some threshold signature scheme or if you're doing like some header verification, like all of that code could have issues. And I think that's why it's so scary because this is like really complex stuff.

Yeah, totally. I think when, especially when it comes to, you know, things that require TSS and requires a bunch of different really complicated designs, I think the more part you, you have, I think that the more exposed you are to different potential implementation problems. So kind of, I think, you know, this is like a, I'd say, you know, the, the,

designed for some of these in short model versus the trustless model, it's always a lot of trade-off. I think the trustless one is probably also very hard to build, especially the ones that I don't think you included them in the article, but there were some of those are leveraging VK roll-offs

Those are just extremely hard, but I think the most secure among all. So I think, you know, from your perspective, one of the key areas to hear, if you disregard the time horizon, what would be your favorite model of all time, including the ones that are unshipped?

Yeah, I think that like the easy answer or like the cop-out answer is it depends. I think there is a lot of different trade-offs between these. I think it's probably easier to say what's my least favorite model. And again, I can't wait for like the angry emails, but I think like validator-based models is probably...

my least favorite because I believe that in a robust cross-chain system, you should have as close security as the source and destination chains that you're bridging if you're trying to maximize system-wide security, I guess, across every chain.

And I think there's also nuances that we haven't really seen play out, but we're going to around these synthetic assets, where if you have, say, five different validator-based bridge, and say you're trying to bridge, I don't know, like ETH to Solana, each of those separate validators

has a bucket of ETH that they're holding onto. And they're the ones that issue like the SETH or whatever, like on Solana.

And you have two issues there. One is like the fungibility between those, where should each of those assets be equal one-to-one? And I would argue no, because the security assumptions of those different validators are completely different. And two is the very scary like domino effect,

that happens if one of those assets is compromised. If like a validator set that issues a synthetic asset gets hacked or if they just like run away with the funds and that asset was used in one or multiple say like DeFi protocols. Like how do you do that accounting when it's effectively unbacked and it should be like zero?

And I think that's really scary. And I don't think the ecosystem is pricing that risk. And ironically, with the housing crisis or the subprime mortgage crisis in the US, it was mispriced risk because of a lack of transparency in what was happening in those areas.

securities. And now we might risk, if there's enough of these synthetic assets, a similar thing where we're mispricing risk again, but it's due to a different thing. So I think that has a lot of negative externalities. So that's probably the one I like the least.

Um, and then between those, I think, um, like clients really cool, um, uh, very safe. It's effectively validity proofs, which I personally believe like, um, uh, zero knowledge tech is like the strong technology, um, uh, that is going to dictate a lot of where crypto is going to go, um, over the next decade. Um, so I think like that, um, uh, those kinds of security guarantees are, are really great. Um,

But, you know, it's like these things take a really long time. Exactly. They're really expensive to verify. And if you're trying to do like no hops between chains, then or like one hop, one to one communication effectively, like that's going to take a super long time.

to build out. And then I think liquidity networks like Connects are just really good at doing one thing and doing it well, which is like, I just want to trade one asset for another and that's it.

Yeah, that also makes sense. I also like Connect a lot. I actually really appreciate you bringing it up because if you don't, I would also ask you about it too. Yeah, so like there's, it's like a red ocean right now for all of these cross-training solutions. I think I very much agree with you. I think it's pretty pivotal for these

different solutions trying to find the way they kind of stand out. For Connects, your point, they're just trying to do one thing and do it well. And then for some of the other ones, I think for the ones that you mentioned, the ZK ones, even just running a server would take a long time. So sometimes I really think these teams would have to have a lot of perseverance and believe in what they're doing because it not only costs them time, but also costs a lot of money.

for all of these to be able to see it, see the future fruits of it. So from your perspective, how can one differentiate itself among its peers if they're in the same categories? Or for the peers that are doing different things, say like liquidity network like Connects or maybe solution like ThorChain where they actually have a DEX itself.

or, you know, maybe the, um, quote unquote Oracle service network, like, um, layer zero, how do you see, um, their go-to-market strategy would be differentiating? A couple of ways. I mean, overall, uh, with the design choice, I mean, like effectively, you know, you could do, um, uh, like what Solana did, like relative to, um, uh,

Ethereum, I guess. What you ideally want is some radical design trade-off that is as different as possible because usually you tend to pop out a use case that is uniquely suited to that design and that architecture. So I think the teams are just trying to do fast follower forks or whatever. I don't think that's going to be

successful long term. And I think the ones that just really embrace those trade-offs, I think are the ones that are going to find unique use cases. Outside of that, like go-to-market wise, I think the lowest hanging fruit for a lot of these bridges is to support all EVM chains first.

Because that is where we've seen a pretty interesting network effect around Solidity and EVM.

So it's pretty easy for developers to just copy and paste most of their code. And so there's usually a ton of demand to go across BSC and Polygon, for example. I think the next step is to support untapped corridors, where that's the obvious one because it's easy. But what can you do that's really hard to build? Can you do...

like ZK Sync to Solana. Like that would be really interesting. Or like Terra to Moonbeam, right? Like things that enable new corridors that don't exist. I think it's going to be really interesting. I think the last part is you support new kinds of assets. Like I actually haven't seen any

robust NFT bridges. And I think that's going to be really important. Like, Rare Bowl has launched on Ethereum, Tezos, and Flow.

So how can they leverage some NFT bridge that allows a user from one front end to be able to access inventory across multiple base layers? So I think that part is going to be really cool. It's also difficult. But I think those three are probably good ways to differentiate.

interesting that you said, you know, EVM first, because I felt like everybody was going to do will do that first. And that doesn't really provide any differentiation. But I guess like your point is about like capturing the largest volume from all of these chains, because probably that, you know, all of these EVM combined, they do have the majority of the activities.

Yes. And you could do like within that, again, like specific design trade-offs, like things that you're good at, like only like being really good at bridging or like minting synthetic assets across or being able to support really high value transactions in a safe way. I think a lot of that,

like I don't want to call it like table stakes like like you could have a really successful um bridge I think as long as you um connect high demand corridors like if you assume that there's a lot um which so I've been seeing like a lot of organic traction on other L1s like um uh Slana Avalanche um and uh I guess like Phantom I think is now one so if you're able to like bridge those three um

I think that would be really cool. And maybe it's not, like it's more so dependent on like the corridor itself and how much usage there is in each one of those ecosystems. And like the analogy is, you know, you're,

like you're booking a flight and you have like different airplane hubs, airports in different cities. And if you're a new airline company, you might want to support the largest cities first. Like maybe you start off with New York and London.

And then you might do like smaller cities after that. So like that's one go to market as well. But there's different go to markets. Like I think

It was maybe Ryanair or another, maybe Southwest, where their strategy was to launch in cheaper airports, like just outside large cities. And that's how they were able to really reduce the costs of those flights. And they became like the low cost leaders. So that's probably like another go to market.

But yeah, I think it's like up to the teams to figure out like where there is demand and kind of what's being underserved.

Totally. I'd like to wrap this conversation with something slightly different. It's actually not that different. I mean, we've been talking about a lot of the L1s, but then I think a lot of you also care about the liquidity fragmentation of L2. I guess that's also part of the reason why you guys invested in Connext. What's your view on the L2s competition playing out?

Yeah, I think there's a spectrum of controversial views, I guess. If you are...

a believer of zero knowledge technologies, then you're probably more bullish on like a Starkware or a ZK-SYNC as being like the most robust and safe solution. If you believe that a sufficiently robust... So let me rephrase, there is also...

an argument to be made that with a sufficiently robust bridge every L1 becomes a side chain or L2 of every other L1, if that makes sense. And the bare case for ETH tethered L2s is that you, like most users, don't really care about

security and they need like good enough security for um for most of those use cases um i i personally believe that there's going to be um uh still continuing demand for um eth level security um for a lot of like the defy um uh applications and i think you could also have um uh

kind of like application specific L2s or sidechains like what Ronin is doing with Axie. So I personally don't think there's ever going to be like a canonical L2.

I think there's going to be many. And I think that's why it's important to be able to transfer those funds. Because every time we try to build a cathedral in crypto, we end up with a bazaar. And we've seen that with L1s. And I think we're going to see that with

L2s. And I think it could be like a very similar dynamic to what has played out in L1s as well, which is different use cases, different geographies, different developers. And I think you almost need to expect that and to kind of skate to where the puck is going there and to not

try to win some battle to say, I am going to be the best L2 with 99% of activity here. It's more so saying, how can we enable a choice for application developers and users and facilitate that choice?

Got it. I really like the metaphor for the cathedral versus the bazaar. That's amazing. Well, I think, you know, what the summary of what you're saying about the spectrum, you know, what people kind of emphasize on actually inspired me quite a bit. I didn't think of this in this way in the past. But I think you're probably right in some to some extent.

I mean, I think, you know, for some of the, it's not going to be a lot of them because at the end, you know, the ones that aren't differentiating that much with slight, slight

slightly similar kind of security assumption and whatnot are just you know you'll probably just only have one of them surviving so I think you know it's kind of similar to the L1s and and then you know like the L2s the dominant ones are probably going to be a few and then each one of them doing different things that are they're good at I think that's

You know, that's actually something I would also choose to believe as well. Yeah, yeah, totally. And, you know, like the caveat is there are always power laws to all this stuff.

So, like, yes, there will be multiple, but I also think it's reasonable to say that there will be a, like, the majority is going to be in a relatively small number. Right, right, right. And that is due to, you know, liquidity moats, for example, or, you know, integrations and things like that.

So there's always like the balance there. But I think over time, it does like tend towards entropy. I agree. Cool. Thank you so much for joining us today. This is really inspiring conversation. Thank you, Dimitri. Yeah, for sure. Thanks for having me.