Axelar works closely with various Cosmos chains to provide Cosmos-EVM cross-chain capabilities and link other non-IBC ecosystems to Cosmos-interconnected chains.

Jack Zampolin is a prominent developer operating across various projects on the Cosmos ecosystem. He’s working on the Sommelier Finance interoperability project and Strangelove Ventures. Jack’s continued work in the space has led to many developments and capabilities associated with Cosmos, delivering innovative tech to the growing community.

This forward-thinking innovation is a concept shared by Axelar, facilitating the aforementioned developments between the two leading networks.

Sergey Gorbunov, CEO of Axelar, sat down with Jack to discuss security in blockchain, the future of interoperability and development in the space. You can listen to the full recording of the Jack Zampolin AMA on Axelar’s YouTube channel. Subscribe there for more like this in the future as we sit down with key Axelar partners and leaders in blockchain infrastructure, applications and interoperability.

Sergey Gorbunov, CEO of Axelar

Hello everyone. For those of you that are joining I’m Sergey, currently working on the Axelar network and super excited for today’s conversation with Jack. Jack is working on a lot of things, including Strangelove Ventures and Cosmos. Could you please introduce yourself and let us know some of the things you’re working on?

Jack Zampolin

Absolutely. My name is Jack Zampolin, and I’ve been working on Cosmos since 2018. I’ve mainly worked on the developer and user experience for the Cosmos SDK, as well as IBC (the Inter-Blockchain Communication Protocol). As a part of that, I’ve worked on a lot of different things in the ecosystem. I’ve also advised on projects like Juno and worked closely with the Osmosis team to help shape features there. In many ways, I am broadly active throughout the entire Cosmos ecosystem.

Sergey Gorbunov, CEO of Axelar

Awesome. Would love to step back and learn a little bit about how you got started in the Cosmos ecosystem, and how you got started in blockchain. What brought you here?

Jack Zampolin

That’s a great question. I’ll go all the way back to 2013 when I was a professional chef at the time. I bought my first bitcoin which I then went on to sell. This triggered a fascination with space and pushed me to learn how to code. I started coding soon after, mostly in my free time. I then participated in a boot camp in 2015, which allowed me to start working on a database company called Influx DB. Fast forward to 2017 when my roommate quit his job in traditional tech to work on Blockstack. I had been spending more and more time hacking on various crypto projects so he invited me to join him to help with developer evangelism.

Sergey Gorbunov, CEO of Axelar

What key messaging or key technical pieces attracted you to Cosmos at that time?

Jack Zampolin

I’ve always had concerns about the energy usage of proof-of-work. Climate change is a massive social issue caused by humans that we need to face. We need to figure out more efficient ways to get consensus, rather than smashing computers together. So therefore the core innovation behind proof-of-stake (PoS) is something I am a fan of. It also looks a lot like the distributed systems that run in Facebook, Apple and Google, alongside other large institutions that maintain huge computer installations. It is a better and more secure version of that.

That is what drew me to PoS and the vision of IBC. With IBC, there is no individual system that is lording over all the others. Systems that interoperate on a peer-to-peer basis look a lot like the original vision of the internet, which we are all nostalgic for. That is something that I want to help build, and that’s why I’ve joined Cosmos and spent the past five years of my life on this.

Cosmos-EVM cross-chain and beyond

Sergey Gorbunov, CEO of Axelar

Great. Let’s talk a little bit more about interoperability and IBC and how it connects everything. I want to focus on the properties that interoperability should provide. You mentioned peer-to-peer connectivity as one of the main characteristics of IBC. With this in mind, there are a lot of things we can discuss, from security to what types of messages can be passed. I’d like to know how you define security for an interoperability protocol. What is good or bad security?

Jack Zampolin

That is a broad and expansive topic so let me attempt to explain this. I think that when you’re thinking about security, one way to think about it is through threat modeling, so what are the threats that we should protect against? Bitcoin, and broadly crypto in general, is looking to protect against overweening government influence, protecting against individual actors shutting down the whole network or even small groups of actors shutting down the network.

If we are looking at security from that perspective, I think IBC offers unique security guarantees because even if one of the PoS networks that make up the broader IBC network is compromised, there are others. Systems like Polkadot, which have one chain that’s meditating the communications between other chains, take on the security properties of the chain that does the mediation. Whereas IBC has a heterogeneous group of chains, in which each has its own security properties. That comes with its own set of issues, but it also solves a number of other security problems.

Sergey Gorbunov, CEO of Axelar

Let’s talk a little bit about this connectivity topology that could happen and peer-to-peer connectivity. IBC is good with that. Then you have a Hub-and-Spoke connectivity model, where there’s a hub connected to various spokes passing messages, that are relaying them across. Even in an IBC world with hundreds or thousands of different chains, we can’t really assume that every chain is going to be directly interconnected with each other. That would require N2 connections, which requires all the management to relay between them, so on and so forth.

You will probably still be in a position where some of the chains are routing or delivering information across other chains and, potentially, assuming all the chains along the path that you’re sending information through, are actually secure. This means you will be relying on some transmitters. With that in mind, I think you actually did some work on routing for the IBC hub?

Jack Zampolin

Yeah, definitely. I’ve been the largest proponent of that in the Cosmos ecosystem, and have probably done the most work on it. Right now, when the IBC network is small, you’re right, that N2 is very manageable, but as it grows – and we are seeing it grow very, very quickly – we are going to need to start having some sort of routing to help manage the complexity here from an operations point of view. We are beginning to reach the edge of where it’s possible to manage that without routing. In the last Cosmos Hub upgrade, I pushed for a change that enabled you to route tokens through the Hub. However, the token routing comes with its own particular set of concerns and problems.

I think in the future, we’re gonna move to this world where we’re not necessarily routing tokens, we’re routing smart contract calls or data, which comes with fewer problems. I think that in order for routing to be really fully fleshed out, we’re gonna need a) a larger network and b) a change in the type of data traveling over that network. This would mean changing from concrete representations of value as the way that we currently transmit data between these networks, to smart contract calls and other data-based intercommunication. I’m really excited for that world. I’m doing a lot of work to help bring that about. One way is through IBC queries which allow one Cosmos chain to query data from another Cosmos chain, as well as bringing interchain accounts to market, which is the ability to do these cross-chain function calls in Cosmos.

Sergey Gorbunov, CEO of Axelar

I think one of the differences between the internet and blockchain is that whenever you’re talking about peer-to-peer routing on the internet, it’s okay to take as many hops as possible. This is because you’re not actually assuming that there are any type of trust properties in the networks or any security from the networks. You are only there to guarantee delivery of messages.

As an example, if you go from one website to a backend server, your packet will probably go from eight to 20 hops or eight to 20 different networks along the way. That’s fine because none of these networks are actually supposed to guarantee any security. You are only there to guarantee delivery. Then you have protocols built on top of it, like HTTPS and SSH that are application layer protocols that are there to guarantee security. I think one of the big differences between the blockchain model and the internet model is that if we were to directly apply this analogy to the blockchain space, my packet goes through 20 other networks as I’m transmitting it.

No matter what, the blockchain network is supposed to provide trust, authenticity and verifiability of information so that you can link it back to the value. I think there are security assumptions that are going to have to be taken that will start being amplified. I do think in the blockchain world, minimizing the number of hops and minimizing the number of connections actually comes with significant benefits where you can reduce the attack surface. You also reduce the layer of assumptions that you make along the way as you transfer the packets. What are your thoughts on this?

Jack Zampolin

I completely agree with this. I think this is where a network like Axelar really has a strong market niche. Cosmos chain to Cosmos chain, once you’re in this IBC world, being able to send between chains is very easy. But, bringing in some of these other chains like you guys are, Cosmos-EVM cross-chain and proof-of-work chains, requires a specifically designed zone. You guys really are making the best effort right now to play that role of bringing assets that are hard to build IBC directly into, into the Cosmos ecosystem. Axelar is doing a great job at that.

Relayers, fees and other components of interop infrastructure

Sergey Gorbunov, CEO of Axelar

Thank you. Let’s talk about other pieces of infrastructure needed to make interoperability happen. I think a part of it is relayers. I think you’ve also done a lot of work on relayers for IBC and Cosmos. I am curious, can you summarize for the listeners the current state of IBC relayers? What are they doing? Then we can talk about some economic models behind them.

Jack Zampolin

Yeah, for sure. Relayers are the little machine elves behind the scenes, making everything happen. In reality, if you’re looking at these systems, all of these interoperability pieces that we’re talking about so far are all the on-chain pieces of this. Now this is kind of technical, but a blockchain cannot make a HTTP request to another blockchain. It can properly format a transaction that will be accepted on another blockchain, but it can’t actually submit that transaction to another blockchain. There’s some actor that needs to do that. That is fundamentally what a relayer is. It’s the piece of the system that helps complete a lot of these sorts of automated transactions, and do them repeatedly. Now, what is the current state of this? Right now in IBC, relayers are not incentivized, but practically what’s happening is that each project in the IBC space is sort of paying a small set of people to do this relaying.

This looks like a lot of other infrastructure providers: You’re providing quality of service and you’ve got an on-call rotation, making sure that the quality of services is maintained on the channel. That’s all well and good. But another thing that relayers are doing is also working really hard on individual node performance, fixing issues with different pieces of the system, and working to push forward the scalability of IBC. Relayers sit in this kind of unique position where if we think of the different layers of the Cosmos stack, there’s the proof-of-stake layer down at the bottom with Tendermint, there’s the application layer with the Cosmos SDK, there’s this on-chain IBC code, and then relayers kind rely on, and work with, every different piece of that stack. So we’re running into issues often before users are, and we’re helping to fix those issues and push forward the user experience for all of these chains.

Sergey Gorbunov, CEO of Axelar

I think if I had to make another comparison here, the proof-of-stake blockchain ecosystem is possible because of the validators, services that have been providing by running nodes, participating in testnets, helping hundreds of projects bootstrap. I think that relayers is probably going to be one of the next critical infrastructure pieces that these validators will be uniquely positioned to address for the market. Like you said, they already have experience running validator nodes or nodes of different blockchains. It is an infrastructure piece that has the same demand for that quality of service with high availability, high uptime, quick responsiveness, and so on. I would just offer a huge thank you to all of the validators and the folks that have been running relayers for the Cosmos ecosystem and for other ecosystems, because I think it’s a hugely important piece of infrastructure.

Jack Zampolin

Definitely.

Sergey Gorbunov, CEO of Axelar

What do you think is going to be the economic model behind relayers down the line? And, just to expand it, relayers are not specific to IBC. We at Axelar have relayers that connect IBC and Cosmos-EVM cross-chain. Between the Axelar network and other EVM chains, similar types of functionalities need to be provided. You have a lower guarantee in terms of the number of people that you need to run these things, on average. We talked about this last week. Maybe a couple of people is usually enough, because you need at least one delivery of the message, but you don’t need the kind of decentralization on the relay layer which is already achieved by the underlying protocols. Going back to the question, how do you think relayers should be incentivized? What can we do to continue growing that ecosystem?

Jack Zampolin

There’s a huge amount of work that needs to be done to make it easier. Users can end up relaying their own packets via the browser in some kind of end state. But I think there is always going to be this sort of role for these server-side relayers. There’s been some work on a relayer incentivization proposal. Basically, each packet that gets transferred via IBC would have a wrapper on it that includes some fees, and those would be sent to the relayer. I think that’s part of the answer. Another part of the answer is users relaying their own packets, as well as more ease of use for this relayer software, to make it easier to set up. If you could go to a website and say, “Hey, I’ve got this new chain. I need a relayer on this chain. Here’s a button I can click that gives me relayers on that chain, and I can pay their costs.”

These are all different things that are being developed right now. And I think that some combination of them will end up ensuring quality of service across the interchain. There is not one answer to the relayer incentivization problem. It’s an extremely complex problem. Fees within blockchains are probably one of the hardest and most open design pieces for blockchains. We get at this from a variety of angles, both making it easier as well as adding direct incentives.

Sergey Gorbunov, CEO of Axelar

Do you imagine a world where users will relay their own transactions? One challenge with that, especially if it’s not a direct connection, but a multihop relay, user would need to have tokens on different chains.

Jack Zampolin

I think that in the case of multihop, the users relaying their own packets is easier. Let’s say they are routing through the Cosmos Hub. They could use the Gravity dex to automatically trade into the fee tokens for the various chains that they are interacting with. That would leave them exactly where they want, having paid fees along the way, without the user having to make any direct interventions. That’s one way to go. As you mentioned, that is kind of the big sticking point in users relaying their own packets. And there’s a number of things that are in flight to enable that.

One is the ability to pay fees in denominations other than the native chain token. That’s sort of natively within Cosmos right now, but we’re adding code to make things like consensus fees easier. There’s a lot of work happening on that. This combination, having multiple fee currencies and consensus fees, plus having the ability to trade into assets along your route, plus having the JavaScript relaying software in advance, will bring us to a place where users could realistically relay their own token transfers in six to twelve months. Now, if we’re talking about some of these data packets, there is a different model there. I think that will be handled differently.

Sergey Gorbunov, CEO of Axelar

Another layer in between the users and the network relayers is application layer relayers. We thought a lot at Axelar about for some applications you could set up your own relayer and then you could cover all of the fees for your users. Imagine you are talking between two smart contracts or two Cosmos chains. You know what the calls are, you know what types of messages will be routed, and you cover the fees for your users, providing this kind of quality of service.

Jack Zampolin

This is why I advocated that we drop fees in IBC for the release. I figured this would be the primary model and that has turned out to be the case. We spent three weeks shedding fees in IBC, and the design that we came up with required an oracle, required a stablecoin, and we were converting all the fees into dollars. It was incredibly complex and would have added a year of engineering effort to shipping IBC. So, when talking about application specific blockchains, this argument that the applications would cover this fee for their user is great.

Sommelier Finance and cross-chain message passing

Sergey Gorbunov, CEO of Axelar

Do you want to talk a little bit about Sommelier and some of the work you guys are doing? I think you’re doing a lot of interesting things there, including message passing. Do you want to give a quick overview?

Jack Zampolin

Yeah, for sure. The core idea behind the Sommelier chain is that it is a blockchain that manages smart contracts and financial products on other blockchains. To do this, we have our own custom Ethereum-to-Cosmos bridge. It’s a fork of the Gravity Bridge that the Sommelier team has been working on since the beginning and we’ve been deeply involved with that project. The specific fork of the Gravity Bridge that we have has been developed to be able to format an Ethereum transaction over on the Cosmos side, and then send that over to the Ethereum side to do automatic rebalancing of Uniswap V3 pools.

This was the first use case, but we pivoted away from that. The first seller that we’re going to be launching is an automatically rebalancing Aave pool, where you’re moved into the most profitable stablecoin on Aave automatically as that changes dynamically. This machinery can be used to manage contracts on any EVM chain, and we’re going to be expanding that network and adding more Cosmos-EVM cross-chain capabilities. This sort of general architecture can also be used on Cosmos to manage liquidity within Osmosis pools or positions on Anchor Protocol on Terra. We’re also working pieces to enable this sort of data and smart contract call-based system to be adopted all across the Interchain.

Sergey Gorbunov, CEO of Axelar

I’m actually quite interested in that. If we dive a little bit deeper, where does the message construction happen? As a user, you send a message to the Sommelier chain, and then you have on-chain logic that takes that message and creates an EVM-compatible message, and then you want to relay it via Cosmos-EVM cross-chain to the EVM chain and execute it there. Is that the correct flow?

Jack Zampolin

That is kind of the correct flow, except these Cosmos-EVM cross-chain calls are not user-initiated. They are initiated from within the state machine. So, the state machine over on Sommelier has a list of Ethereum contracts that it is managing, and the validators periodically vote to send smart contract calls over to those managed contracts. So, the smart contract calls all originate from within the state machine on the Sommelier side.

Sergey Gorbunov, CEO of Axelar

Got it. That’s super interesting. I guess what you’re saying is that, traditionally as a user, I have to if I wanna rebalance, I go and execute these transactions? And you’re saying, okay, we now have an application-specific chain that automates this all for you and you can walk away right. You don’t have to worry about whether something needs to be rebalanced and moved from one pool to another.

Jack Zampolin

Exactly. And you know, all of the efforts to do this so far have all relied on custodial services, where some smart contract, or off chain process, is given ownership over the funds within a smart contract. I think you can very easily see how that is counter to this decentralization narrative, that we as a community encounter this autonomous part of DAOs. At the end of the day, anything that’s happening in an automated fashion, we’re delegating responsibility to an individual key running on a cloud server somewhere, in those security trade-offs are not great. As an Ethereum user and as somebody who uses some of these contract protocols, I’m not a huge fan of that architecture.

One of the main reasons why we’ve built Sommelier is to take that out of this custodial nature, which not only has security implications, but also regulatory and legal implications that are not great. And as a US citizen, I am probably more exposed to this than some others that don’t live in the US. You know, having that behind a decentralized set of validators that is making those decisions in a transparent way is better from all of those perspectives. And I think it’s a model that we’re going to end up moving towards as an industry.

Sergey Gorbunov, CEO of Axelar

Yeah that makes sense. We’re allowing general message passing through the Axelar stack. So then you can technically also develop cross-chain apps that route your message as an IBC message to an Axelar-connected network, from which it gets delivered Cosmos-EVM cross-chain and executed on EVM chains as well. Because it’s just a general payload.

Jack Zampolin

Exactly.

Sergey Gorbunov, CEO of Axelar

Yeah. Makes sense. Awesome. Well I think this is super interesting. Anything else you want to talk about?

Jack Zampolin

Well, I’m excited to work more with you guys. I think we’re working together right now to set up some IBC channels with Juno. I know that you guys have a lot of exciting things going on within the Cosmos ecosystem, and as you continue to turn on more pieces of functionality of Axelar, I think you guys are gonna play an increasingly large role within the ecosystem. So, I’m really excited to work more closely with you.

I guess on questions I have — I see Joe Bowman here in the chat. When we were talking about things like IBC queries and the ability to do more complex forms of interoperability, Joe and the Quicksilver team are working on a liquid staking protocol, where there’s an entire Cosmos blockchain that’s managing the distribution of stake between a number of different validators. These are the kinds of things that we’re gonna see increasingly moving forward. And the work that you guys are doing — that I’m doing — is all helping to bring that into reality.

Earlier in this conversation, we were talking about how I got started in crypto. When I started at Cosmos, people would talk about IBC and I was like: “yeah, sure.”. Maybe when we ship the platform, I’ll believe this IBC thing. Watching a lot of these things that we talked about theoretically, before this stuff was even live, sort of happen – the competition between various different peg zones, the more advanced forms of interoperability – it’s really, really exciting and really awesome to see. I’m excited that we’re here now.

Sergey Gorbunov, CEO of Axelar

Yeah, for sure. I’m super excited to see everything you guys are working on. You kind of helped the whole ecosystem across the stack, from infrastructure all the way to protocol and application development. I still think it’s quite early, right. For everybody. I think we’re still kind of at a place where we’re setting up core connectivity pipes and core, basic relaying and message passing, routing; I think it’s still in its infancy. And I think all of that is going to continue being built over the years, with some of the work you guys are doing, and us at Axelar. We need better application layer protocols. To make it easier for the applications and the users to interact with the cross-chain ecosystem. So likewise, super excited to continue working with you guys and the rest of the ecosystem. Thanks so much for your work and everyone else that’s here on the call.

Jack Zampolin

Thank you for having me, Sergey.

Sergey Gorbunov, CEO of Axelar

Thanks. Thanks everyone for tuning in. And, see you later