‍Katherine

Hello everyone and welcome to episode seven of Cross-Chain Examination. I'm your host, Katherine Wu. Each week on Cross-Chain examination, we have on the smartest and most interesting people working full time in the crypto industry to tell us what's top of mind for them.

So our topic today is on bridges, but not the physical bridges we use to cross between two places. This is a bridge that connects different blockchains and enables apps built on different blockchains to communicate and work together. And the reason why this is important is because over the last few years we've seen different layer ones getting built. Ethereum is the OG layer one blockchain, but in recent years we've seen the rise of other types of layer one blockchains. So for example, Solana, Cosmos, Avalanche and more. And these different blockchains have different programming languages and standards, so sometimes the apps built on one cannot communicate or work with an app that's built on another layer one blockchain. This, of course, poses problems, and sometimes that communication is pretty necessary.

Now, where there is a genuine problem, there are smart folks working on a solution. And with us today is one such person, Pranay Mohan, the founder of Nomad, which is a security first cross-chain messaging protocol. Welcome to the show, Rene.

‍

Pranay

Thanks, Catherine. Super excited to be here.

‍

Katherine

So another reason, aside from just you being really smart and working on a really interesting solution, we want to have you on this because according to Ash, who is my partner at the fund, you have one of the most soothing voices in all of crypto.

‍

Pranay

Yeah. So this is something that people have commented on and something that's new to me to be acclaimed for this. But given that James, one of my co-founders at Nomad, has the “best hair” in, I think Etherium or crypto I had to kind of I had to bring some weapons of my own. So this is the radio DJ voice that I'm bringing to the table.

‍

Katherine

That's a great dual team. Well thank you for taking the time. So I just gave a little intro into bridges 101, and I wanted to start off with you breaking down the what, why, and how as it pertains to interoperability between blockchains. So maybe let's start there and then let's go into defining Nomad.

‍

Pranay

Where we find ourselves today is in a world where there is no one chain to rule them. So this was a thesis from the early days of crypto, and I think that's where this idea of maximalism comes from, that you can just choose one chain or one coin or one community and that becomes the one to rule them all. And I think what we found is different strokes for different folks, right? That expression exists for a reason, which is that there are so many needs in this world and each of them cannot be met by any one monolithic solution. And so rather, what has happened is there has been a tapestry of solutions that have been developed over the various bear/bull cycles that we've had, and that has led to this flourishing of the many different chain ecosystems, some of which you mentioned. You mentioned the Ethereum, Polkadot, Cosmos, but there are several others beyond that. And this number only seems to keep increasing.

And I think this makes sense because the heterogeneity of technical solutions that exist mirrors the diversity of thought that exists in the world, and the diversity of need as well. And so the what is that there are many different chains that have now come to fruition that all have apps, users and use cases that are perhaps suitable for those chains. But anytime you solve a problem, you often end up with these second order problems that emerge. And so now the problem that we're facing is you have all of these different chains that cannot talk to each other. And so the users, the liquidity and the applications on them are siloed from each other. So a common example is say you want to use Aave, right? You want to borrow assets on one chain. If you are doing that on mainnet Ethereum, and you move your assets to another chain, you still have to close your position on Ethereum. Your position doesn't move with you, even though your assets can get bridged over these days, right?

So I think where we're at is that historic market structures have led to a world where many chains exist. They all have different use cases and users, but the user experience is now throttled by the fact that they are gated and they are separated in these discrete ways. And what bridges offer is the ability to kind of connect all of these ecosystems almost in a horizontal way. So instead of creating one monolithic chain to suit everybody, we now have all of these chains that offer different solutions but can be connected by bridges and offer scalability and execution environments that can tap into a much larger demand user base. And then I think we covered the what, the why, and I think we're getting into the how. You teed up Nomad very well.

Nomad is an arbitrary message passing solution. And what Nomad allows you to do is leverage the standard to connect all of these different chains. And particularly for us in the how, what matters most for us is security. There's a reason we have security first in that description, because any time new technological solutions roll out, especially when they're dealing with the value, the bottom of crypto Maslow's hierarchy is safety because any time any new category of tech gets rolled out in the space, the first thing we see is it gets exploited. It often goes through this painful maturation process where we test in product according to quotes from some famous builders in the space. And that leads to a lot of failures in product as well, which burns real people. And so as part of that maturation process, at Nomad, we feel a great need to target that specific value proposition first. And before these chains can be united by a common standard of bridges, that standard needs to be safe before it can do anything else. And so, of course, in the various space of bridging, there are many tradeoffs. But we feel that if you anchor to a high level of safety and security first, everything else that you desire can be figured out as you go as.

‍

Katherine

No, that's great. And I think that explains the what and the why really, really, well. And as you were saying I remember a couple of years ago, I think it was a really common hot take kind of question to ask someone, do you think in the world of blockchains it's one chain to rule them all or it's many others existing? And that was like for a long time, I think a big source of debate, right? Whether or not it was going to be one blockchain ecosystem and there's no room for others.

And now I think the ecosystem has matured, the industry has matured to the point where instead of fighting one another, we're actually just trying to find ways to make everyone work together. So in a way, I think that's actually an improvement. And it shows just how in a few short years so much technological improvements have been made. So now turning back to, I guess, digging more into the how - so even in the world of blockchain interoperability, I think there are some different approaches to exactly even the kind of bridge that's being built. For example, Nomad, as you said, is a generalized messaging network, but there's also other types of bridges, there's a wormhole, which is one bridge that's kind of more of an asset bridge. I want to try to have you help us define the different bridge categories and the pros and cons of each approach.

‍

Pranay

With any complex thing, there are many ways you can slice and dice it, and I think we can explore several of them if we have time. One of them that you just mentioned is, what application use cases does the message passing layer support? You mentioned asset bridging, that's one specific use case where users can move assets, but just one of many if powered by this generalized message passing capability. But I think the particular vector in which bridges should be or message passing layers should be analyzed is from asking the question, what is the verification mechanism underlying this protocol? And this dovetails from my previous point around security, which is that really what we are doing when we are sending messages between two chains — when we say chain, chain is short form for essentially a network boundary or a trust network. Everybody has different names for these things. I know that the Celestia folks have called them clusters, but really what we're talking about is validator sets at the end of the day, really the innovation in crypto and I know I'm kind of passing back to the lowest layer, but I promise I will answer the question building back up. Really, the heart of what crypto innovates on is this idea of censorship resistant applications that can be deployed on execution environments powered by multiple actors that can basically include state commitments. Right? So we talk about validators, miners, and what we're trying to do is send messages between these discrete validator or miner sets. So from Ethereum, which has a distinct miner set, to Polygon, which has a distinct validator set. Right. And what we're doing at the end of the day is we are making a state commitment within one trust network and then verifying that that state commitment has happened, passing that to another trust network and then taking a follow on action.

So in the case of asset bridging the most common method is wrapping assets, or generating representational assets by locking and minting. So somebody sends assets to a smart contract on one chain, it gets locked in that smart contract. Something verifies that this happened. Then that verified action gets relayed to another chain where once that relayed state is accessible, anybody can prove a message against that and mint assets now towards the recipient on that chain. But the key part of this that is still a black box is, who does that verification when that state commitment happens on that first chain?

And really the differences between all of the solutions that have flourished is basically figuring out how do you handle that verification? And so in order to understand what exists out there, we need to anchor against what is the strongest possible design that we can have. And that's what we often call native verification, where who verifies the action is the underlying validator set of that same chain. So in this example that I brought up earlier about sending assets from Etherium to Polygon, when you lock those assets on Ethereum, you ideally want the Etherium miner set being able to verify that that happened. And so often what this design uses is a light client and the gold standard or the most widely in use version of this category of solutions is IBC.

Everybody's familiar with IBC because it's the first class interoperability protocol that powers the Cosmos ecosystem. And the way it works is every Cosmos zone is running a light client of any other Cosmos zone sending messages. And so any time a message gets committed within a Cosmos zone, that state commitment can be verified within the light client running on the destination chain. So the destination chain actually has a facsimile of the consensus process from the sending chain, and therefore you don't need anything else to verify it. You're just relying on the validator sets of the two chains. This is the ideal setup, but there are drawbacks to this, and the drawback is primarily that this is really hard to engineer. There's a lot of complexity in building light clients, and particularly when you get to a heterogeneous ecosystem of chains, all of which have different consensus mechanisms, different cultures, it's hard to reliably develop on chain light clients that can be deployed everywhere. And so if you ask, why hasn't IBC propagated to Ethereum, to Avalanche, to Solana, it's because it's really hard to develop these light clients and it takes a lot of engineering effort and it fundamentally lacks this property that we call extensibility, which is the ability to extend or be deployed in heterogeneous environments.

So in lieu of having something like IBC, this golden standard that extends across many different chains, what people have had to do is come up with ad hoc solutions for who does that verification process. And understandably, these solutions that take root are the ones that are easiest to deploy, which is custodial or multisig based solutions. If you look at the recent bridge hacks that have happened, often they happened because there is this multisig set, five of nine or three or five or whatever, and if you corrupt that multisig now you have the ability to corrupt that verification process. And so this is the second large category of verification mechanisms that exist that we call external verification, meaning that there exists another verifier set outside of the validator sets of the two chains trying to communicate that handles that verification process. And the key caveat with this category is that if that external verified set is weaker in security than the validator sets of the underlying chains, you have now bet the farm on this the weakest link. I cannot stress how important that is. That is the thing people need to understand is nothing else about the bridge you're using matters if the root of the rust verification mechanism is a custodial or centralized verifier set. And so I think this gets glossed over in this desire to figure out, okay, what application use cases are possible? None of that matters if the fundamental substrate you're building on is untenable. And so I think in the desire for speed, in the desire to meet user needs, this has largely flourished. I think whether you're talking about multi sigs, oracles, validator sets, they all fall in this category of externally verified systems.

Now, some might say, okay, well, can't you just make this really robust? Have a chain, have a validator set and add more parties in this verifier. So that's one way to approach this. But any time you add, you're basically recreating the wheel. Instead of using the validator sets of the two underlying chains, you now have this third validator set that you're bringing on board. You have to pay them somehow, and then you also have to deal with the overhead of all of them verifying the system. So at Nomad, we feel that this is one approach some folks have pursued, but it's largely kind of delaying the inevitable, which is throwing more bodies at the problem.

Now, the third option, which Nomad has pioneered, is optimistic verification, which instead of relying on native verification, which is very secure but complex and hard to deploy, or external verification which is easy to deploy but less secure, we've leveraged I’d argue Pareto principles, which is this 80/20 rule that by giving up 20% you can actually get 80%. And the last 20% is the hardest thing to really claw back because you have diminishing returns. So what Nomad tries to do and what optimistically verified systems tries to do is say, hey, we will try to be as trust minimized and secure as possible, but we will also make it very easy to deploy. And how this verification mechanism works is, you do rely on somebody in the real world, an external verifier to say, okay, this commitment happened and you can take an action upon it on the destination chain. But what we do is we introduce this time out period, this window where if something bad has happened, if that verifier has tried to commit fraud, another class of actors called watchers can flag that fraud and prevent it from going through. And by doing this, we get wins on both sides. We're not at risk of the external verifiers being corrupted because there is this checks and balances with the watcher set. But unlike natively verified solutions where it couples with consensus and requires on chain light clients, this only requires verification on the sending chain, and so it becomes much easier to basically take the same contracts, the same set up and deploy it everywhere.

And so our bet is that you need not have the full, air tight security that our client system may offer. You need to get as close to that as you can. But what matters more is meeting the market where it is now and helping people bridge safely when they need to, which was yesterday. And so to kind of package everything up, what we've kind of just gone through is one vector in which you can evaluate interoperability solutions is, who does the verification? And the reason this is the kind of way we should look at all of these systems is because this is the place where there is the most risk. Once we figure this layer out, then everything else is above on Maslow's hierarchy. We can figure out economics, we can figure out use cases, we can figure out etc., etc.. But at the end of the day, what matters is safety. We need to nail that, and that lies at the heart of the verification mechanisms used.

‍

Katherine

I mean, that makes a lot of sense to me. I think what you were saying earlier about, I mean, to really dumb it down, there's kind of two core tenets you want to take away. One is you're only as strong as your weakest link. And the second is, you don't want too many cooks in the kitchen.

‍

Pranay

I'm gonna start using that, but I'll credit you.

‍

Katherine

Perfect, and our listeners will hear it here first. But I wanted to also dig in more on from people who maybe aren't so familiar - why did you choose to go the optimistic verification route and maybe even define it like a TLDR really quickly what that really means.

‍

Pranay

Yeah, it's a great question and I think it comes from the constraints at hand, which is that crypto waits for nobody. If you try and build the most secure thing or the ideal thing, by the time you're able to ship it, the market will have moved on. We've seen this time and time again where one example is ETH 2 roadmap, right? ETH 2 has been a thing - exactly, those of us who have been in the space for, oh man. That's the response because it has evolved over so many years. And by the time the roadmap had kind of started to settle I'm not even going to speak to the set of the roadmap. The point I'm trying to make is rollups came and now everybody had to adapt to rollups. The rollup centric future for Ethereum kind of caught everybody by surprise because that was the organic solution rather than the kind of top down prescribed one.

‍

And so the fundamental reason for the optimistic design is that I cannot take any credit for it. I think credit actually belongs to James and Barbara, my co-founders at Nomad, who have spent the last four or five years working on interoperability. They have worked on these client based systems, natively verified systems such as TBTC and seen firsthand the complexity of the engineering and the hard work it takes to build and deploy these systems. Not to mention the cost of maintaining them with proof of work networks like Bitcoin and Ethereum. And so I think it's more of a practical reason that we've kind of developed this optimistic verification mechanism, which is that the market needs something safe and it needs it yesterday. And this is the thing that, at least according to us, fits those checkboxes the closest and offers us a way forward to where as this industry matures and develops like more trust-minimized and secure systems, we're happy to ship it out. We see Nomad as a scout. The idea is to be good enough for today such that people can build applications that they know are safe upon which the underlying plumbing or infrastructure can evolve and become more secure over time. Our number one goal is to do what's right for the space in the long run. We just believe that that's a path-dependent process and the optimistic mechanism is the right way to get there.

‍

Katherine

That certainly makes sense. And I think bridges today is probably just a fraction of what it could be in just the next five years, just as more value accrues on all these different ecosystems. And as new entrants come into the space and build on whatever suits them best. And so, I think about this question maybe just selfishly for me, which is, as Nomad or other bridges decide to support whatever ecosystem, whatever chains, what is the decision making process. And speaking as, obviously, as a VC, do you view it as a venture style bet or you make assumptions on where activity will go? Or are there other metrics or things you think about that I'm not.

‍

Pranay

Yeah, I think this is a fantastic question and really insightful because the underlying question here is what makes block space valuable, right? Because each of these, what every chain is doing or every execution environment is doing right now is they are selling block space. And historically block space, like smart contract block space, has been fungible, meaning that it's really been this generic compute block space and the primary focus has been scaling up the production of block space. So when we talk about scalability, that's really what has been happening behind the scenes. And so when we think about where we should deploy Nomad, I think the number one thing is we want to be able to deploy it anywhere that's safe. Again, I apologize to the listeners who are going to hear me say the word safe too many damn times on the show. But really, if the underlying chains themselves aren't safe, then we don't want to deploy Nomad there. End of story, right? If we care about safety, if we care about users being safe, it doesn't matter if the bridge fails or the chain fails, the user feels the failure, right? So if we have chains that overnight go to zero. Not that that's ever happened, then that's a major issue. And we apply a lot of scrutiny when thinking through where we want to deploy. But provided that that underlying chain is safe, then the question becomes, does this chain have users and liquidity and use cases already? If it does, then I think it's already kind of like hit escape velocity, right? So these are the table stakes chains that every bridge is deploying on. So that's Ethereum, grandaddy, you got to do Ethereum because that's where everybody wants to bridge from. Then it's Polygon, Avalanche, L2s, Optimism, Arbitrum, Solana, BSC. Like largely EVM-compatible chains, but the ones where there's already been this kind of feeling that they're going to persist through this market cycle, that everybody has to deploy there in order to have competitive parity with everyone else. So that's the easy bucket to take care of.

After that, then you start thinking about where do we expand to? And I think historically we have chosen a different path than most other interoperability solutions in that we have deployed to frontier chains, where, you said, we have made this venture style bet that we want to grow with the chain. We think that these chains have unique value propositions and by deploying there we will facilitate their growth and benefit from it by being the premier bridge on these chains. And some examples that we have targeted is our first deployments were on Moonbeam, Milkomeda, and Evmos, all three chains that we think hold very unique value propositions moving forward. Moonbeam being the kind of onramp for Polkadot. Milkomeda being that for many different ecosystems, they’re deploying EVM environments on Algorand, on Solana, even on Cardano, right, which is where a lot of traction has surprisingly developed. And then Evmos being this port of entry for Cosmos that historically has not had EVMs, Evmos kind of serves as this dual system that sits between the EVM world and the Cosmos world, which has really popped off recently. And so that is one style of bet that we've been very interested in. But there are others in this category as well.

We're big fans of Aurora and Neon as well, Aurora and Neon are for Near and Solana, respectively. So that's one big category that I think is these gateway chains or frontier chains that sit between two large ecosystems. Then I think there's others like Kronos, which have more close relationships with certain companies or exchanges in the space and offer this unique capability of being an onramp to a much larger user base. So largely, I think if I were to distill it, when we're taking of interest, I'll bet on these chains. It's either technical, there's something new and technically interesting about these chains, or they have a massive user base and distribution that we can tap into. And I think there's more to come. People have been really talking about Aptos and Sui recently, and I think that's because they offer new technical capabilities there as well. And so we want to bet on these chains because we think that if Nomad can help bootstrap these ecosystems and then they really develop these flywheels, then Nomad will kind of benefit from the draft of these flywheels.

‍

Katherine

I think that's way more nuanced than just simply thinking about total value locked on whatever chain or just how many dapps were built. I think that's just a more comprehensive view. It makes a lot of sense given where you're building and user.

‍

Pranay

Sorry to interrupt, but those are all lagging metrics, right? TVL and apps deployed and transactions or whatever. That will all come. But really what you want to bet on is - if each chain is producing block space and block space is a proxy for censorship resistant compute, what user base does this censorship resistant compute target and how efficiently can deliver it, are really the two questions. And this early in this category, if you're relying on metrics like TVL to make bets, then you're not thinking aggressively enough about the potential that the space has.

‍

Katherine

Yeah, and you have non-negotiable considerations when it comes to picking chains. And of course, all the teams that we talk to, including portfolio or ones that we just meet day to day, almost everyone has a desire or a roadmap plan to deploy on more than one blockchain, which makes sense. So if I were a team that wanted to deploy on whatever, two chains right, Ethereum and something else, how can I utilize Nomad to achieve cross-chain applications? Or I guess, in other words, how would you pitch me to serve a multichain app deployment?

‍

Pranay

Yeah. I think this is a super interesting question. I would be lying if I said I had the full picture answer for this. It really is a case by case basis for the application. There is no one size fits all answer here. And I think there are like two styles of one size fits all answer, which is one, just deploy on one chain, that's your home, don't worry about anything else. And get product market fit, get users there and then think about expansion. And then more recently, I think there's been this a bit of a zeitgeist shift, I think largely pushed by Layer zero and wormhole. And some of the others that have been pushing heavily on this generalized message passing to deploy on the omni chain or the interchange or like this, deploy on every chain and don't have any discretion about why you're doing it. Just spam your deploy across eight chains and don't worry about it. I think the truth, as with everything, lies somewhere in between these two outcomes, where I think the world where you would deploy on one chain and not worry about it is gone. But I think the world where you just spam deploy the same carbon copy across many chains is also naive because it doesn't take into account the heterogeneity of the underlying chains. Maybe right now they're mostly homogeneous, but, why would you just spam deploy across various compute environments? You should be thinking deeply about what does each environment have to offer you as the app developer? And that is unique to the application use case. If you are in an application that is going to market targeting users in the developing market, then high fees are not something you can tolerate. So your decision criteria involves likely wanting to be able to buy cheap block space that may not be as secure. Right? And maybe you have assets that these users are putting on chain that at aggregate does require and call for greater security and you can do that on Ethereum.

And so I think we are trending to this world where you're going from this pendulum swing of maximalism to, is, omnialism a word? Where you just try and go everywhere without thinking about it. And I think we'll swing back to the middle where it's like, okay, I will deploy here because the underlying infra has something unique to serve my application such as security or speed, or maybe it's developed for file retrieval or some other different technical quality. And then you start adding different chains as almost microservices or different things as needed for your use case. Because at the end of the day, what every application developer should be anchoring towards is getting product market fit by building a product that users want. And largely crypto still hasn't crossed the chasm to where there are real world users. And I think one example that I really like to highlight is Centrifuge. So Centrifuge is a very cool parachain that is focused on real world assets. And this means being able to bring assets that exist in the physical world and put them on chain to increase the efficiencies of transacting with them. And I think this is one of the frontier use cases that has not yet picked up steam because crypto has largely been for the early adopters and insiders. But as we cross that chasm, this is the type of use case that's going to help real people understand why we're building any of this shit. And so we've recently announced with Centrifuge and Moonbeam and Avalanche that we are doing this partnership to allow for cross-chain real world assets powered by Centrifuge connectors that use Nomad for EVM comms. And so I think this is a great example of how Centrifuge has been really intentional about its go to market for the time that they've been around. And furthermore, they continue to be intentional about why they are tapping into certain ecosystems like Ethereum and Avalanche. Because imagine if you're putting a mortgage on chain or something, you likely want that to be on Ethereum which has great liveness, properties and security. But then if you want to be able to issue loans against it or something, then you can do that on Avalanche or you can use Moonbeam as this transit route to be able to then interact with the various features that the Centrifuge chain has developed. So I really like that as an example that highlights this. They haven't gone and deployed across various chains. They've been very intentional about choosing a few that are tailored towards the specific demands of the use cases that they're targeting. I really hope to see more of that, but I think it's still so early that we're still laying the underlying infra, and if I have to hit my quota of saying safety 15 times in this podcast, then we're still not yet there to where we can talk about higher order desires.

‍

Katherine

One of the amazing things about building out solutions that allow for better interoperability and safer ways to do so, obviously allows for people just have more options. Teams have more options. Ops have more options. But given that it's crypto and everything in crypto just has to be more complicated, how do you feel as kind of interoperability matures or how does that effect or how will that help or maybe not help with cross-chain governance? Do you think that in a cross-chain world, governance can still happen effectively? And, do you think about solving this as Nomad or, what is your take on that?

‍

Pranay

Yeah, I think you're speaking to a use case that lies close to the heart of a lot of folks at Nomad. We are really bullish on cross-chain governance. It's the second use case after asset bridging that we've developed a solution for. In partnership with Gnosis, we built Zodiac modules. Zodiac is a suite of DAO tools that Gnosis Guild has built. And we built the Zodiac Nomad module, which allows DAOs to be able to basically use Nomad’s message passing layer to control Gnosis Safes across different chains. And I think this is really cool and really important because a lot of people have this misconception of Gnosis Safe being just a multisig tool, right? You generate a multisig with a Gnosis safe and that's it. You just do it on one chain and that’s it. But Gnosis Safe actually has more capabilities than just being a multisig. It allows you to generate these avatars that if you give them predicates, they can create follow on actions on different chains. And one of the use cases that we are pretty interested in is using this for is, whenever a proposal happens on one chain, largely Ethereum, whenever a governance proposal passes, the current problem that a lot of DAOs are facing is that how do you then get the results of that vote to a destination chain? And I think that highlights kind of where we are in the market right now. Because flagship apps such as Uniswap, for example, have made many different deployments across, V3 has been deployed across different chains like Polygon, Arbitrary, Optimism, and what we've seen is that each and every time that a vote happens on Uniswap V3, on Ethereum, that that result has to be propagated to these L2s. But each L2 or each chain has its own bespoke bridge, if at all, that handles messaging. And so every time that governance result has to be passed, the developers and the community that is coordinating this governance process has to painstakingly develop tooling for each route that we've seen. So it's a different set up for Polygon. It's a different setup for Optimism. It's a different set up for Arbitrum. And this friction gets in the way of having more governance that allows these apps to be decentralized.

So one of the first things we've targeted is because chains have deployed separate apps, have deployed different instances on all these sidechains and L2s, standardizing the way by which they connect the home deployment with the satellites - the home meaning where the tokens live and where governance happens - so with this Zodiac module, we hope that defi apps who are already mature and have decentralized their governance into DAOs will now be able to effectively manage the fleet of the deployments they have.

And why this is close to our heart in particular is again, safety, right? Because like assets, governance is another area where corruption can have massive damage. If we think all the stuff that we're doing is going to onboard the world’s capital markets and replace the traditional financial systems or supplant them, whatever you want to say, then all of the governance processes become incredibly consequential. It's like a board of a company voting on a massive outcome for what that company's going to do. It'll control M&A it'll control the executives that they hired there. They're going to be massive implications of governance that I don't think people put stock into right now. And so while we are in the phase where we have the ability to make the infrastructure seamless, we're really keen on doing so. And the other really nice thing about governance, particularly with regards to Nomad, is governance is largely latency agnostic. Right. So one of the things about Nomad is because it uses an optimistic mechanism, there's a very mild latency added to message passing. Now if you're doing something like gaming, if you're shooting a bullet from one chain to another, the Lord knows why you'd be doing that, you may want you're all bridges have asynchronous. You may be willing to tolerate 5 to 10 minutes, but maybe you're not willing to wait longer than that. But governance, which happens over the span of days, at times, you really don't care about a couple extra minutes waiting. I'd much rather wait a little bit longer to make sure it's bulletproof and secure. And so I don't know if you're teeing up with that question, but we love the governance we love DAOs, please hit us up.

‍

Katherine

I'm teeing up the longest and nerdiest PSA of all time.

‍

Pranay

That's right. You're going to get that with me. Like if you tee me up for a PSA, I'm going to go on a rant.

‍

Katherine

Okay. Well, given our time, I'm going to have one last question for you, which is sorry, this is actually a big question. Looking forward, what do you think the role of bridges in the blockchain ecosystem becomes? So does that look more like a layer 1 or do you think the whole process just becomes abstracted away from end users?

‍

Pranay

The latter, for sure. For sure. If we don't do that, we don't succeed as an industry. And I know it's a big claim, but I think we're firmly in a world, in a multi-chain world where there's not going to be one chain to rule them all. As we discussed earlier, there are going to be multiple chains, not only for technical reasons, but because of socio cultural ones. And we have to live with that. As much as the maxis would hate to admit, we have gone past the stage of maximalism.

So if that's the case and I'm a user, you cannot expect users to know, oh yes, my assets live on Solana and I must go and use this specific bridge to move them into Ethereum or say, move them into Avalanche. If I use the wrong bridge, I end up with a different representational asset and therefore I won't be able to transact with my favorite app. That's three mental hurdles too many already. At the end of the day, the key thing that we are all selling as an industry is censorship resistant compute for applications that should not be deployed on private company servers. There's a reason this whole space started with Bitcoin because Bitcoin basically created money as an application deployed on censorship resistant computers. And since then we've realized that it's not just money, but it's financial services, it's governance. It's art and other non-fungible assets that need to have high security and protection from being seized by central parties. That's what we're doing. And if that is to meet real users' needs, the users should not even know that there is a chain or a bridge underneath. They should just be able to use a browser, visit a website which over the course of the last 20, 25, maybe 30 years, people have been trained how to do and then use the app. In the long term, there should be no additional mental hurdle except for the fact that now there is a layer of value and censorship resistance powering that value already added to the internet. That's where we're all going.

And I feel fortunate to be able to go on nerdy PSAs because it means that we're early enough in the industry such that I can geek out about optimistically verified systems. Yeah. None of that matters, right? But it is, it is, it is great that we can talk at this level now because it means we're building the future systems that will then help real people. We're just fabulously early.

‍

Katherine

Awesome. Well, I'm going to end it on this fabulous note. Thank you so much, Pranay, for coming on and geeking out about all things cross-chain and interoperability and safety.

‍

Pranay

Totally. Thank you for having me.

‍

Katherine

Thank you all for tuning in to another episode of Cross-Chain Examination. As a reminder, please remember to like, subscribe, leave me comments, tweet at me. And we also have a Twitter handle for the podcast at Cross-Chain Pod. We have an email that's open, it’s crosschainexamination@gmail.com. I would love to hear any feedback, thoughts, ways to improve, and I'll see you all next week.