On The Brink with Castle Island - Sergey Gorbunov (Axelar) on Blockchain Interoperability (EP.354)

Episode Date: September 28, 2022

Sergey Gorbunov, co-founder of Axelar joins the show. In this episode we discuss: Sergey's path to founding Axelar His views on blockchain interoperability and the design decisions of Axelar The different approaches to interoperability that are being attempted in the industry Views on DeFi composability and the role of privacy on public blockchains The L1/L2 landscape and how Axelar is positioned To learn more about Axelar visit axelar.network/    

Today on the podcast, I sat down with Sergey Gorbinov of Axelar. Axelar is a project that's focused on blockchain, cross-chain communication, and value transfer. This was a fun conversation and touched on topics including the future of L1s, the L2 landscape. We also talked about the future of financial services as it relates to decentralized exchanges and the future of privacy on Web3 networks. So without further ado, here's my conversation with Sergey Gorbanov. Matt Walsh and Nick Carter are partners at Castle Island Ventures. All of these expressed by them or the guests on this podcast are solely their opinions and do not reflect the opinions of Castle Island Ventures. You should not treat any opinion expressed by anyone on this podcast as a specific inducement to make a particular investment or follow a particular strategy, but only as an expression of their personal opinion.

This podcast is for informational purposes only. Brought down by bad mortgage investments, Lehman, which has 25,000 employees will be liquidated. The federal government loans American International Group, AIG, $85 billion. This is a different kind of market, and the Fed is asleep. The federal government is stepping it to stabilize Fannie Mae and Freddie Mac, the two mortgage giants that have been threatened by the housing crisis. The bank of England has pumped 75 billion pounds more to Britain's ailing economy with a new round of quantitative easing. You print a couple trillion dollars and all of a sudden people start to worry. So out of this worry, we have something called the Bitcoin. Bitcoin.

Sergey, well, thanks so much for coming on the podcast. This is airing after the merge. But as we sit right now, the merge is about 12 hours away. So hopefully it went well. Oh, thanks for having me. Let's hope it'll go well and went well. I guess it would be an eventful 24 hours if it does not go well. I guess it'll be eventful one way or the other. But excited to have you on to talk about Axelar.

I guess a good place to start is just tell us a little bit about your background and what got you into the space. Yeah, my background kind of technical originally. I worked in distributed systems, did a little bit of software-defined networking work. So that was pretty fun. We were thinking how do we improve the routing on the internet and creating a kind of centralized controllers that can handle some of the routing path. So spend a bit of time on that, then decided to study formal cryptography, went to grad school at MIT, doing a lot of protocol design, system design work for a few years.

And then afterwards, started to work in the blockchain space. So I collaborated with Sylvie McAlley to help design and take to the market, the out-ground platform with the team out of Boston. So that was pretty fun. And then, yeah, afterwards, just saw the next problem for the ecosystem, which is a problem of cross-chain communication, kind of decided to take. that had on because it would be fundamental that we have robust solutions to continue growing in the space.

I guess everyone comes at the blockchain space with their own biases and reasons for being excited about the space in general. So what was it for you that really clicked into focus that this was going to be a big industry? What got you excited in the first place? Yeah. I mean, for me, was, to be honest, technical challenges. Being a technologist, I would say, I like solving hard problems and I like solving more

important problems that would have an impact. I think at every phase of my life, when I pick a problem, I try to understand when is that impact going to happen. So, like, as an example for my PhD thesis, I was explicitly working on problems that I knew if they'll have an impact, it would be like 15 years in the future. But I strongly believe that it would have impact. So I'm still waiting for that, by the way. But that was fun. The one we did like some networking work, like I knew that stuff that we were doing, like will be used a year later, right? Because a company has been built around it and they were like real problems to solve that you can experiment with and measure outcomes. I would say like blockchain space for me, it's a beautiful merge of networking and cryptography.

Like both things I loved. Actually, like when I was going to grad school, I couldn't make up my mind what I should study like networking or cryptography. I decided to do cryptography, but then blockchains came in and sort of a beautiful blend. So yeah, I would say technical problems. But ever since playing with a space, it's been more and more about the impact that it solves. I understand fundamentally how it changed. developers paradigm, how it changes communities, paradigm, how they can attract with these technology and like different properties with it.

Those properties will not even know, I would say, to anybody, right, seven, eight years ago, but now I think they're becoming more and more evidence. What's your view on the smart contract platform space? Obviously, we've seen tremendous innovation in this category. You could argue it's the most vibrant category within all of the blockchain space. And you see new L1s being launched every year. You also see L2s emerging on top of those chains, obviously see big upgrades, the would be a textbook example there, of just new technology being brought to bear on the existing chain.

So what's your just overall sense of the competitive landscape there? And maybe what's that going to look like in the future? I think kind of smart contracts for platforms is one of the most exciting thing, right, about the spaces. And I think my view is, again, like technological is that if we do it right, building software and building software with global distribution on these platforms is going to be easier than ever. And so that's the premise that we want to get to, at least for development. Then for users, we can talk about what the value prop is. And then you ask yourself, how can you do this?

So kind of a monolithic stack like Ethereum, right, with solidity, language and everything sharing the same compute environment is there one way of doing this? Then we're seeing, we saw an array of Ethereum competitors that introduced solidity to their consensus, going to optimize consensus, try to execute more transactions per second, better latency, right, cheaper gas costs and so on and so forth. That I think is pretty exciting, you know, and in some sense, put solidity as being the standard language that every developer, every developer works with. And then you have one-off attempts, which I think are all very interesting individually. You know, how Solana experimented with their virtual machine environment, right, like at Algrant.

Then there is now, I think there's the Facebook mafia, right, with like Mistin and Aptos and the move language, which I think a lot of people are finding quite exciting. So, yeah, I mean, I think the space is still continues to innovate on the languages. And I think that's why allowing people to continue innovating while still being able to talk to one another is really something an invariant at least I'm trying to preserve. I guess that's a great dovetail into Axelar. So maybe tee that up for us in terms of what was the impetus for starting the project and what exactly it does. Yeah. So what led us to start Axler was that when we shipped outgrant, one of the first thing we wanted to connect it with other networks. At that time, Bitcoin, you know, Ethereum.

And we looked a little bit at the solution space, nothing really that you could take and plug and play. So everything that was out there was either centralized or required years of engineering practice, right, to kind of re-implement how we're doing consensus, things like light clients and so on and so forth. So that wasn't really a path. And then at the same time,

just saw this array of all these other platforms being built from Solano, you know, Avalanche, Cosmos, Polka, dot, you know, near, and the list goes on and goes on. And so we asked ourselves a question, like how can we connect all these ecosystems in an easy way where developers of those platforms can continue innovating, making the best technical decisions for those platforms, but we can still connect them so that the developers at the end of it,

they can build anywhere they want, any smart contract language that best meets their needs, but still have access to global distribution, global liquidity, and be able to interact with everyone else without losing composability, because composability is critical, critical property in the space. And so that's what we started to work on, and that led us to accelerate. And the high level, we'll focus on building secure infrastructure for Web3

that deals with communication and cross-chain communication. The end goal is to allow users to interact with any application, any asset, any chain with one-click from their wallet. To get there, we need a certain layers of infrastructure, similar to the built and the development of the Internet, but now they're missing in the blockchain space, and that's what we're working through. How do you generally think about the interoperability space in the blockchain industry?

There's a number of products out there. There's a number of projects. There's bridges. Some have gone incredibly poorly. There's been a lot of security issues. So is there a framework for how to think about the various approaches to interoperability? And how would you describe what you're doing in relation to other attempts? Yeah.

I mean, I would say kind of all the other attempts, they essentially fall in one or two buckets. I would say there is light, client philosophy, right, I would say, right, that serve example would be kind of an IBC or within PolkaDOT. There's an XEM, light client surf verification approach. It's mostly a pairwise protocol that talks about how to connect A&B. So it's a protocol. It's a protocol semantic and you can think about how do you make it, you know, as decentralized or as trustless as possible. So that's fine. And then you have more of an interoperability protocols that for the most part to date, like you said, been poorly done, and they've been kind of centralized.

They've been pairwise, and they mostly dealt with token transfers. And let me kind of elaborate on those things. So centralized, I think, pretty straightforward, right? Many of the protocol, you see, you know, kind of a small multi-sid, like two out of three, five out of five, whatever, five out of seven. Many of them get hacked or compromise. They really not even closely meet the robustness requirements needed to guarantee safety and liveliness of networks, right?

So those, you know, need to go. Paraguize is another property which I think many people don't quite follow, but I think because everything was focused on these badly connected connections, people just focused on how do you connect A and B and how to make it as secure as possible. But when we think about cross-chain communication and interoperability, it's not about how you connect A-Tchance, it's how you connect a thousand chains with another thousand chains. It's like many to many properties that you need to have on the internet today when we're speaking. There's thousands of networks. They all talk to one another, right? we're not thinking about how does A, go to B.

We're talking about advanced protocol routing, message delivery, content delivery networks, right, and kind of various services that glue these things together. And so how do you build infrastructure that can support really many to many scale? This is something that has not been addressed and we're addressing with Axler. And the final point is that initially all the interoperability protocols mostly focused about token transfers, right? So how do it transfer value?

We want to go beyond that because that ultimately led, into a situation where we turned users into human routers, because you couldn't go from A to B and C automatically, so you had to go to some breach software. You had to click 15 things. You have to move your things, then you want to go somewhere else. Oh, you need to pay gas. You need to click on another wallet.

Oh, you can go there. And then you can use the application, right? So it's like a multi-hub process and humans are the ones that are doing all these movements. And so with new paradigms like general message passing that were introduced interaxilar, you can go beyond that where you can automate all this complexity, automate a lot of the steps for the users, where they can get this user experience that we're after that you can interact with any asset, any chain, just with one click from your wallet. And so that's something which completely changes how the applications need to be structured,

architected, and requires a lot of tooling in process. And we're working on those things as well. It's got to be a challenging problem to get that generalized many-to-many framework in place because you have some blockchains that already exist that are very difficult to change. Bitcoin comes to mind is almost impossible to push an upgrade through Bitcoin. Now, you have others that are launching where you might be able to have a very close relationship with the core development team and to get some changes on their side that make it easy to interact. So what's your overall philosophy of how to deal with these disparate chains and get that interoperability?

Yeah, no, great question. Honestly, there's been a requirement for us from day one to make sure that we can connect the chain without talking to the chain developers, and without them having to do any work, period, right? Because like I said, I think we have to continue innovating. We have to allow those developers to continue innovating. How to design a plug-and-play approach in a secure way, in a decentralized way? And so that's how we architected the network.

The network layer, there is always a notion of a gateway that sits on those blockchains. Gateway is the same thing as router at your home. You have a router. What does it do? It takes messages like video and text messages that you're sending from your home network, delivers them to a router, and then there's all kinds of infrastructure that picks up those messages from the router and delivers it somewhere else. So we can design it in the same way that on any chain you can deploy this notion of a gateway or router,

and then the network needs to be able to understand requests coming into those routers, route them accordingly, and deliver them to these destination routers. So, and then all the complexity, right, and all the logic for dealing with the interoperability, all the translation is then dealt at the axle network itself, which is on its own, like a proof of stake network. So it has similar types of security properties as you have from the chains that you're connecting, but you can make these very gas efficient. You can make this very efficient because the network has been designed to move messages in an efficient way.

That's a good explanation. Maybe we can just dive in a little bit to a typical user journey. So how would you think about the use cases for the network and let's call it the next 18 months versus where you see this going over a five plus year time period? What will people actually use it for? Yeah. So I think like next 18 months, right, we're going to see examples where all of the defy is probably going to start moving to be chain agnostic. So here's what I mean by this. Suppose you have Bitcoin, right, or ether as an asset. And suppose you want to take a loan against it on an application that resides on Avalanche. And you want to take a lot.

alone, maybe in an asset that lives on avalanche. So let's call it USDC, for instance, because you want to do something there. So today, traditionally that has been done, again, by you having to go to like some bridges, moving things around, the being gas and so on and so forth. But at the end of the day, you just need like this USDC as the asset that you desire for your collateral. So while having applications integrate with Axelot Protocol, then these steps can be abstracted from the user.

So the user, you can say, okay, here's my wallet. I have my Bitcoin or Ether. I press one click and it goes to this application that lives on another network on Avalanche. The message already encodes everything I want to do. So it says, this is my loan. It has been locked. Please give me a loan against it. And then the application will execute this logic.

And it will also know where you want to receive those funds. Do you want to receive it on the same network? Do you want to receive it on a different network? But you don't have to think about those things. So they can be executed transparently for you and you just get the loan. So without having to move things back and forth and so on and so forth. I think Prime is a good example that's building something like this. They're building on Moonbeam and a bunch of other networks really trying to get this cross-chain,

borrowing and linen platforms stood up. You see a lot of examples of automated market makers that are going cross-chain and multi-chain where user can swap Ethereum for AvaX directly with one-click without having to bridge anything, without having to move anything. And then you see wallets embracing these functionalities as well and as well. So this is what I would say the next 18 months are, right? So applications that we know product market fit for, TFI, you know, NFTs are kind of transition to this unifying liquidity and eliminating user barriers to interact with them.

And I would say beyond that, what I'm really excited are we already see interest in use cases where different chains have different properties. And sometimes you want to export those properties to everyone else. So as an example, Osmosis does swaps. And we're actually working on a project with them where the swap functionality is potentially available to other chains or other applications on other chains as a service. So meaning that you can call it,

the request will be routed to as most is going to execute it and then routed back to the users' wallets, whatever chains there, they access it to. We're seeing interesting examples around privacy preserving networks like this where you want to leverage a network for privacy features, maybe do some operations there without revealing the data or the transactions and then moving them out to the destination chain. We've seen that with things like IPFS where you have storage and you want to build

applications around it. And the chain itself is not optimized for hosting a lot of applications, but you still want to export its sort of API or functionality to other ecosystems. So that's another use case. I think that's going to happen more and more where we'll probably still have some kind of hubs of liquidity or activity because there are some benefits for it. but there are going to be many more chains that provide these properties. And the way they're going to compose with one another is by talking to one another.

And in Web 2, we have framework for doing that, right? We have intranet, we have protocols, HTTP, HTTPS, and so on and so forth. And these protocols are going to be defined more and more, I would say, for the blockchain space, where chains can continue specializing, can continue serving their needs and when they need to, but still being composed with one another. And so that's, I think, something we're going to see more and more over the next four or five years. And the end result of all this is that user actually won't have to know about all that. So they'll say, okay, I do a swap, where it happens, you know, maybe it happens in the mousas.

Maybe it actually routed to another chain because it has better liquidity. I need to access the file. I can still access from my wallet through a unified interface. And it's in the same way as we have a browser where you can access any application and pretty much do all the action. I think we're going to see the same type of layers of interfaces built for the Web 3 users where one single place we can go to, you can access anything and can I do any action. Yeah, it's a fascinating description because you just think about the low-hanging fruit here of Bitcoin on other chains. I think there's a lot of demand for that.

You look at the levels of USDC on all sorts of different chains, and there would be presumably a pretty big appetite to have Bitcoin as collateral within a defy context on any number of chains. It's almost surprising that you haven't seen that yet. Yeah, no, for sure. I think Bitcoin's that we've been working with. Actually, for a while, we had it on the test network and now doing some signature migrations to support it. Yeah, I would say Bitcoin for sure, definitely being, that's another example, right, where the network was built, right? And then people started to think, okay, how do I program around it? People started to think about, you know, payment networks, layer two is around Bitcoin and so forth.

And I think with this kind of composability, right, that opens it up to a whole other array where you can say, okay, all these other chains that actually were specialized, right, effectively become. layer two with respect to Bitcoin if you want to say so. That makes sense. So you can see how your gateways are just really important in this vision of the future here. So how do you think about liquidity and how much liquidity you need, what type of liquidity you need at these gateways, and then how do you incentivize good behavior with the gateway actors? Great question. So let me answer the second question.

Then I'll answer the first one, right? So how do we incentivize good behavior overall? it's through building a network that's robust and decentralized, meaning that no single party should be able to control the gateways, right? No single actor. There is a protocol that's implemented at the Axler's serve network layer, right? Then they decentralized diverse set of validators needs to obey the rules of that protocol. If people want to change it, they can change it, propose governance,

the software upgrades, validators, vote, and so on and so forth. But I strongly believe that the only way to get robustness in the space, safety and liveness is through these decentralization mechanics that's on the second point. And the first one on the question of liquidity and how do we incentivize and how do we think about liquidity? The short answer is that liquidity is actually sort of an application layer problem that needs to be solved above the gateways. So what I mean by this is the following. We support things like general message pass. So what that means is that you can actually do three things or more with it. You can send tokens if you want. You can use that as functionality to send tokens back

and forth, or you can send messages. And when I say a message, it could really be a program. And so what that results in is that we now have a new paradigm for building in Web3, where traditionally we had tokens move to the programs, then programs do actions on those tokens, and then the user takes those tokens and then moves them somewhere else. So that's like moving tokens to the compute. And with the general message pass, you can think of it the other way around where you can take compute environments, move them to where the tokens are, do some computation of it, and then return the result of this compute environment somewhere else you need to. So that means you can actually build networks where liquidity doesn't even have to move,

potentially. Liquidity can stay where it was created by its creator. Maybe it has the deepest liquidity there, but programs all of a sudden become mobile. Because to execute a program, you can send a request, do some operation liquidity update your balance table of your program, and return that balance table back to your home state of an application. And this is really what I think is starting to happen now, where we're seeing these applications like Prime, right, like automated market makers that are building, dexes, and other shapes of forms of applications around X Alert,

that liquidity may move, and there is certain advantages to move in tokens to where the compute is, but there are a lot of advantages of actually moving compute to where the tokens is and not doing some synchronization. And I think that's going to be a new trend. So liquidity-wise, our gateway does support tokens as like first-class citizen, right? So you can send it very easily with one-way call. But I would say, I don't know what the breakdown is, but actually I would guess more than 50% of applications being built is going to be in this latter category over the years. It's fascinating to think about what the composition of the types of people that would be working on these gateway. are. Do you envision that in the future you would have exchanges that are maintaining this

infrastructure? Do you think that you'll have individuals that continue to do it? How do you think about just the validator set at that gateway level? For us, actually, we try to build a network that's open and permissional is that anybody can contribute and do what they want, right? So we actually have three independent projects that are building these gateways in their own languages, right? Like with their own frameworks, we're helping them answer the questions, kind of how they're designed and so on and support. Same thing, we are working with a couple of projects to allow them to customize this validator set for this gateway.

So there is kind of the Axel network, which is like a default. Like it's been done very thoughtful and like with the security in mind. If you want to augment it with other validators sets, you'll be able to do that. Right. So if you want to pick your own validator set, if you want to take your token holders and like have them do kind of covalidation across it, you can do that. You can actually do even more interesting things where you can. say, okay, there's like three independent validator sets and I'll need to trust like two out of

three of them. That gives you both robustness properties and safety properties that you can amplify at the application layer. And I think that's what's going to happen more and more, right, is that we're going to see this gateway's potential instantiated like multiple times. You can compose them between each other and you'll be able to compose how the validation of the messages in and out of those gateways happens. That's fascinating. What are the social parameters around decisions on which blockchains to support. Obviously, something like Avalanche comes across and there's broad community support, I would imagine, because there's a lot of things being built on

it. Maybe not the case for something like Bitcoin SV or something like that. So what's that process look like now? And how do you think it unfolds in the future in terms of just where you plug into? Yeah. I mean, now at least initially, right, for go to market has been like an exercise that we have gone through, right? As a team, we say, okay, this is different chains. This is, we think the activity is going to be over the next six months, 12 months, two years. This is what the ecosystem is going to look like and weigh in technical effort.

The beautiful thing that we have done at the network layer is that at least for solidity-based chains, it's actually all programmed at the network that you can actually literally just run commands to make a connection. You still have to do a little bit of testing before. You have to make sure solidity is actually that they use is compatible, right?

And like these gateways are compatible with that form. But once you're done with that testing, then the actual connection is just programmability on the network and you connect it, and it's automatically then interconnected with everything else. Same thing for Cosmos chains, because we support IBC natively at the protocol layer. Since Axel is built around Tenderman Consensus, any Cosmos chain is added, then automatically can talk to all the other Cosmos chains, but also all these other EVM chains, right, and

solidity chains, and it doesn't have to do anything else for it. So kind of really strong compounded effects. And we are still having some of these one-off project or integrations, right, for chains that specific, but I would say we're already finding ourselves in this position where people understand what we have done and people understand the power of this and they're trying to extend it themselves. This is something I want to see more and more is kind of external communities and collaboration seeing and plug it into this protocol, building their own gateways, maybe even defining their own validators if you want, but still abain the semantics and like these core properties of connectivity,

many-to-man route and, you know, general message pass and things like that. So yeah, I hope that we're going to see a lot more of this and we're already seeing early use cases for people just going and doing their own things, which is, I think, this is the beauty of the platforms. At some point in the future here, it's going to be just very obvious, I think, to even traditional non-blockchain people, that the flow of value that is not going through centralized exchanges is pretty significant here. So what do you think a centralized crypto exchange looks like 10 years from now?

I mean, do they even exist? I don't think they exist. I think they exist as chains potentially. Like I think Asmosis is sort of an example, but not in the centralized way. I think a decentralized exchange with maybe a front end that needs to follow like regulations based on like the customers that they serve, whether or not it's kind of KYC, you know, rules or OPEC or whatever that is. So I think like the front end of these things will probably need to and we'll get to the point

of being regulated. The back end is going to be decentralized. And I can tell you why, right? Because I think some people are for the purpose of decentralization, which is great. The point of a lot of these, it's so much easier to build a composable application, which is build on a decentralized Web3 stack. And if you're building something like an exchange where what you're trying to optimize for, how many assets can you support, how many users can you have,

what other functionalities can you give for your users to compete with everyone else out there? And so building a product that has global distribution can scale much more efficiently on board new chains or integrations and reach all the users and offer different functionalities is just going to be easier in the Web3 stack than it is working with the Web 2 stack and then trying to retrofit it always back and say, I can access this interface or I can access that the interface. So yeah, to me, that's the end goal, is that the development is simpler, it's faster and it's just more powerful.

And I think we're starting to see that, right? I think the volumes with decentralized exchanges keep growing. I think interfaces become easier and easier. They're so painful. Once we get to the point where these decentralized exchanges is just as simple as the centralized one, I think we'll part win the battle, but right now it's still more complex. So the AMM model has been obviously very popular within the community. How important do you think the central limit order book is to that future?

Do you think in order really destroy centralized exchanges you need to have central limit order books that are actually highly performant? I think we're going to see both. I think that the reason we saw AMMs is because nobody could put a central order book on chain in Ethereum. So people started to think about, well, what are the workarounds in some sense, right? And I think AMMs are started as a workaround, but I think have been developed over the years very, very well that it's now people understand some of their benefits more and more, right?

But things like Uniswap v3 is moving towards more and more of this orderbook type of model, not exactly, but kind of closer and closer. And I think with the special purpose chains where you can have your own functionality and chain and still do it very, very efficiently, I think we're just going to see different categories of exchanges, right? So I think DYDX is another example, right, where they were building on Ethereum, couldn't quite scale, like needed to have an orderbook also on chain. And so they went to Cosmos, right, and started to build their own.

chain now. And I think you'll see kind of a few different classes of exchanges being that way. But the what can you put on chain is no longer going to be a limit with these faster chains. And so you can continue innovating. That makes sense. So obviously the past few months haven't been great from a macro perspective for the industry, rising rate environment, a credit crisis in the industry, some regulatory actions, a blow up of a very prominent L1 and Terra. What's that been like to navigate through this storm? It's been interesting. right? Like,

we worked with Terra connection on the network layer when they were actually going down. So that was a good experiment of kind of air safety mechanisms we put in our network where the Terra went down and we had to like pause traffic from Terra to, you know, like all the other chains we were connecting them with and then we had to resume it and then we had to, you know, restart it. So it was interesting on the network layer that I anticipated some of the stuff. It kept us awake all night for a couple weeks.

I mean, look, I think more broad. Probably, I think it's whatever has happened over the last few months or six months has been somewhat healthy for the ecosystem. I mean, it's sad that a lot of amazing projects and, you know, some people lost money in this process. It's never a good outcome. But at the same time, I would think now at least people that are really focused on deep technology and building, like have a little bit of a breathing room. And we can say, okay, you know, now we can kind of, there's a little bit less of a pool of ship tomorrow, right? I remember even when we were raising our seed rounds and starting axler, people were telling us, well, like, okay, this is going to take at least six or eight months to build or whatever the time was.

And people are like, what can you do in three months? I'm like, I'm going to do something else in three months. I should not be doing this in three months. They just wanted the token. They wanted a token fast. Right, right. So yeah, now I think people are a lot more thoughtful, right? I would say it allows people to take a pause, understand what are the lessons.

from that we can learn over the last few years, what are the infrastructure gaps that we have, which are many, I would say, like on the infrastructure side, there's so many things we still have to build to get us to the next level with better UXs, with better security, with better composability and simple developer environments. And so that's what I'm excited about, at least right now, for this server pause, is having a chance to rethink some of these fundamental problems. And I think one thing we have learned, right, from the last bull cycles, is that people are fed up with multi-chain experiences. Nobody said it when everything is great, but everybody felt it, I would say the moment that they had a pause and they could say, okay, this is really messed up.

And like, we have to do better. Yeah, absolutely. What impact do you think the merge will have? So presuming it happens later tonight or tomorrow morning, what impact do you see the merge having on the industry and then on your business? I think for everybody, it's a positive thing. I actually don't think there is going to be any immediate impact. I think the impact will be realized probably over a longer term scale when, you know, Ethereum kind of hopefully finally starts addressing some of the scalability issues, right? I mean, at least my understanding, I think there has been like some conflicting thoughts online, but my understanding of this merge actually does not solve a lot of scalability issues,

gas cost issues, and like by now, the latency is still very, very long. You have 10 plus minute finality that's still going to. remain on Ethereum. So I don't think actually we'll see anything change overnight. I think it's great that we're moving away from proof of work for Ethereum because a lot of compute and a lot of stuff was burnt in that process. So I do think that's a positive thing for the Ethereum network. Don't think anything will change overnight. And I think we're going to have to wait and see still how some of these, you know, scalability issues will be solved, how layer twos will play a role in this, how zero knowledge, scaling technologies will play a role with

So, yeah, I would say things will continue improving. This is not the type of event where it happens. And that's it. Like we see this for a bright future. This is like one step in that process only. And yeah, I think there's still a lot of things to do after that. Yeah, that makes sense. You mentioned zero knowledge.

How do you think about privacy and confidentiality in the context of what you're building? Yeah. So, I mean, look, privacy confidentiality is a right and a property that we have to preserve one way another. It's been a battle to preserve it in cloud-based applications, right, in Web 2, where data goes to centralized parties that can monetize over it. So, yeah, I think before going to DeepOn Privacy, I think it's important to understand that this is what Web3 changes, right, is that instead of having an aggregator of your data that monetizes over it, by default, if you don't have privacy, the data is publicly available, so anybody can do anything with it.

And then it becomes a question of who can build a better product or better community around it or liquidity and so on and so forth. But the data by default is publicly available. Anybody can do anything. Now, privacy properties are going to be critical for a lot of traditional use cases, banking types of applications, governments, right, and so on and so forth. I don't think to a level where everything is going to be private. I think there's always going to be kind of this dual model where certain metadata or certain information is probably going to be public, certain information will probably be private, right, and kind of preserve through the transactions or the compute environments.

But I think I'm actually a little bit controversial on this, but I actually think, unfortunately, the result is going to be that we're going to see less privacy in Web 3 than we're seeing in Web 2, even with zero knowledge, right? The zero knowledge was not available in Web 2 and take whatever technology you want, any privacy or in technology breaks composability. That's the problem.

It breaks it fundamentally. You have to rewrite your application. You have to build new interfaces. And I would love to see it being solved. But the zero knowledge and everything else is it's a new programming model. You always have to write most of the time, like in a new language.

Some people do like solidity, but a lot of it is new languages, new interfaces. Your program often even gets unrolled and has to execute it in the worst time. complexity and things like that. So there's a lot of good basic developer problems that are introduced when you add zero knowledge. And I am amazed and I will continue supporting projects

that are continuing to improve that curve. But it is a battle that I would say that we'll have to continue. That's a really good point. Do you imagine that there's a world for privacy at the wallet level that would maintain some of that composability? Or do you think it's just too difficult to imagine that future? I hope so. But again, like by default, unless applications can compose with that and one another, so we'll definitely be able to have privacy in an end-to-end way. You have a wallet, you want to execute a transaction to an application X, you send that transaction application in a standalone way executes, it returns your result, like it's all hidden, it's all, it's all private. I think that's fine. I think the question is, how powerful can you make then

that application on the back end to be able to still compose with other applications. Some of them are privacy preserve and some of them may not be privacy preserved. And when you compose with things that are partially even privacy preserving, then you're leaking privacy, right? So you might not even want to compose with them. And so then that becomes like the friction and the sticky part. So at the wallet level for the users, I think a lot of use cases like token transfers, I want to execute a privacy preserve a trade or I want to preserve a privacy, you know,

preserving loan, I think those will be available. The question is how well can those backend scale beyond solving a specific user need for some subset of the users and being actually the dominant default parties where 90% of the traffic goes to 80% of the traffic versus 5% or 10%. And I think right now, my guess, we're still going to be in those 5% to 10% ranges. But this is something I would like to be proven on. Yeah, I mean, when you think about traditional centralized financial services, the answer here is you inject a trusted intramed. mediary and they serve as a privacy layer, right? And we don't want to do that. Exactly. Yeah. Well, Sergey, this has been great. I feel like we could have gotten on for another hour.

But where can we send people to learn more about Axelar and to follow what you're doing? Yeah, I mean, I think a good place to start is our website. You know, you can go to Axelot network. From there, there is various links to Discord. We have a pretty vibrant developer community there and developer channel. There's a Twitter handle you can follow at Axelaccore and follow us on Telegram and other places. We try to create content all the time, right, on kind of post updates whenever we have. But back to what I was saying earlier, I think we are building a platform and it's sort of a movement, right, to build this chain agnostic application. So I kind of invite everybody to start contributing and participating.

Well, it really enjoyed chatting with you. I hope that you and the team get some sleep tonight with the merge. Awesome. It was great chatting. Thanks for listening to another episode of On the Brink with Castle Island. To find out more about Castle Island, visit. at castle island.vc. To listen to all of our podcast episodes, please go to on the brink dashpodcast.com or just click on the tab in our website. Thanks for listening.