Blockchain Messaging with Axelar Network

All right, we're live. GM everybody. Welcome to what's going to be another great DevNTell. So, if you didn't know, DevNTell is a 30-minute window for builders to showcase something they're passionate about or been working on in Web3. It's an awesome project been working on, you're demonstrating some new testing best practices, automation goodies, smart contracts, how to structure projects, etc. Basically, if you've got a passion for something, it's your opportunity to share it with the Web3 community. And today, I'm ecstatic to have Ben Weinberg from Axelar Network. Welcome Ben. How are you doing?

Thanks for having me, doing great.

Excellent. Uh, yeah, I guess before we get going to the meat of the content, did you want to give a brief introduction about yourself?

Yeah, sounds good. Um, maybe can I share my screen? Yes, you can. Sounds good. Okay, can you guys see my screen? Now we can. Mirror. Death mirror there. Yeah. There you go. Nice. Um, all right, so I'll get into it if it's cool with you. Um, so thanks everyone for joining. Um, my name is Ben Weinberg. I'm a Developer Advocate with the Axelar team.

Just a brief overview of what we're going to be talking about for today. Um, we're going to go over the need for interchain, how we got here, and the problem with bridges. So what Axelar is, is an interoperability solution, basically to allow users to send messages and assets between different blockchains. So we're going to start off with a brief history and like go over how we got here, why this matters. We're then going to get into the Axelar network and look at what is it, what does it do, what's unique about it. And then we're going to get into a really cool feature called General Message Passing, otherwise known as GMP, which I'm really excited to share with you guys. And then we're going to end off with Axelar in the wild, who's actually using us, and show off some stats, like what are the numbers of people using Axelar. And yeah, let's get right to it.

A bit about myself, I first got into the blockchain space in late 2017. Um, and at the time, I liked to connect with people by going to meetups. That was kind of my grand strategy of how to get into the space and see what projects are popping and who's doing what. And at the time you'd go to these events and everyone seems to know a lot more than you. Um, and people were, many people were promoting different projects which they were invested in. There was of course Ethereum at the time, which was the front-runner that, you know, most people were invested in. But there were other projects such as NEO, which was branded as like the Chinese response to Ethereum. There was EOS, branded as like Ethereum on steroids because it was faster and cheaper. There was TRON, there was IOTA. Um, and many of these projects were branded as like Ethereum killers. In other words, that this project will be the project to kill Ethereum and be the be-all end-all of blockchains.

And this mentality that people had at the time was that of chain maximalism. In other words, one chain to rule them all. And I think that it's safe to say now, end of 2023, looking back, is that this idea of chain maximalism is wrong. We never actually saw one blockchain to rule them all. Um, rather what we saw was the increase in the number of blockchains that exist.

And I'm going to show you a brief video I took a few months ago now from a website called chainlist.org. Um, and what chainlist.org does is it shows you a list of many of the blockchains that exist today. And I say many, not all, because it's actually impossible to say for certain how many blockchains exist. Um, but what you can see here on chainlist.org is that there's hundreds if not thousands of blockchains that already exist. And that number's only going to continue to grow. And we've seen different types of blockchains. Uh, we've seen the rise of Layer 2s, people are talking about Layer 3s now. We've seen blockchains that are more optimized towards speed, blockchains that are optimized towards privacy. We've seen the rise of app-chains, which are blockchains that are geared towards one specific application. Um, I think you guys get the point here. Any questions so far? No, I'll keep going here.

And what we've seen with the rise of all these different blockchains is that um, that there is a need for interoperability between these chains. For us to be successful as an ecosystem, we know that chain maximalism won't happen. There won't be one blockchain to rule them all, but we need a way to actually connect these different blockchains. And this is not a new question. People have known this for years already. And what we saw was the rise of pairwise bridges. Um, in other words, many of these bridges were using assets such as WETH or WBTC. And these are wrapped assets which basically derive the token, so 1 WETH is equal to 1 ETH in value, 1 WBTC is equal to 1 Bitcoin in value. Um, and you could basically use these tokenized versions of native assets on different chains. Um, and this was great and it worked, but the problem with many of these bridges is that they were using multi-sig contracts.

Um, and over the past few years, we've seen um, the dangers of multi-sig contracts uh, with powering pairwise bridges, or I should say securing pairwise bridges. These are some headlines I've taken from over the past few years of hacks that have occurred on bridges. The most famous one being the one on the top left corner, uh, the Ronin Network bridge hack that happened for about $625 million dollars. Um, several other ones here.

And there's another interesting article from a firm called Chainalysis. They estimated that in 2022, $2 billion dollars um, worth of funds, which is about 69 percent of total funds stolen in all of Web3, were attacks on these bridges. So if we pause here and let's let's look at what we've already talked about. The number of blockchains is rising. Um, we need interoperability. Chain maximalism is wrong. But we as an ecosystem have a lot of improving to do in the way we conduct interoperability between blockchains. Everyone with me so far?

And this, at this point, is where Axelar comes in. So what is Axelar? Axelar is a blockchain that connects blockchains, enabling universal Web3 interoperability. That's in its simplest terms what Axelar is. And this is a mouthful, um, and a bit jargony, so let's break down this definition a bit here.

Um, so if we look at this diagram of the Axelar network, we can see it at a 50,000-foot view. Axelar operates a hub-and-spoke model, which means that these blockchains connect or transact through Axelar to get to um, another blockchain. And I want to focus right now on these last three words from this previous definition: universal Web3 interoperability.

What do I mean by that? Well, let's look at some of these protocols that are actually connecting to Axelar, or via Axelar. Um, if you look at the top left here you can see Ethereum, Fantom, Polygon, Avalanche. These are examples of blockchains that are running the Ethereum Virtual Machine that are powered by proof-of-stake. Um, we also have projects such as Osmosis, Juno, the Cosmos Hub, Evmos. These are projects built in the Cosmos ecosystem. We even have projects like Arbitrum, we have Linea, Base, though I don't think these last two are on this diagram. But Linea, Arbitrum, and Base are examples of Layer 2s. And you could see what I mean here by universal Web3 interoperability. That it doesn't matter what virtual machine your chain is running, it doesn't matter what consensus mechanism your chain is running, Axelar can connect any different type of blockchain: universal Web3 interoperability.

And right out of the box, when you connect your blockchain to Axelar, there are two major improvements which you get, just by the nature of the design of Axelar. And those are scalability improvements and security improvements. Okay?

So let's look at scalability improvements first. Imagine a scenario where we have three blockchains, let's call them Ethereum, BNB, and Polygon. Okay? And now I want to connect these three blockchains to each other. You can just count the numbers here. If I want to connect Ethereum to BNB to Polygon and each to in every every way or any to anyway, then you need six bridges to connect each of those blockchains to each other.

Now imagine I want to add one more blockchain, let's say Avalanche. Now to connect all these blockchains to each other, that number goes to nine bridges for just one more blockchain that you added. Now imagine um, if we want to connect every blockchain that exists. Hundreds or thousands of blockchains that exist, how many bridges we'll need to connect each of those blockchains.

So by using a hub-and-spoke model, all you need is just one connection to Axelar and by extension you're now connected to every single blockchain that is also connected to Axelar. And I like to think of this in my head as um, pairwise bridges are more like train tracks. You can go from point A to point B and that's it. Um, but whereas with the Axelar design it's more like an airport. You just need that one connection to Axelar, in other words you need like one airport in your city and you can now in theory get to any other city in the world that also has an airport. So in terms of the way this design scales, um, it's much more scalable than having just pairwise bridges.

The next major improvement which Axelar brings out of the box, in addition to scalability improvements, is security improvements. Okay?

So if we go back to this definition, we talked about universal Web3 interoperability. Let's look at this first sentence, or this first line. Axelar is a blockchain that connects blockchains. Now what does that mean? Well, Axelar is a blockchain that is built on top of the Cosmos SDK. It currently has 75 validators running a delegated proof-of-stake consensus mechanism. Uh, these are some of the validators that are maintaining the Axelar blockchain. Anyone here in the Cosmos ecosystem might be familiar with some of these validators. They're well-known validators that are maintaining many other Cosmos blockchains in addition to just Axelar. Uh, so these are like Figment, Informal Systems, P2P.org. And you could see here having an actual blockchain that handles the interoperability layer of Web3 is a tremendous step up from just having like a 3-of-4 multi-sig uh, which you're relying on for security.

Um, so scalability and security improvements right out of the box are what you get when you use Axelar um, for interoperability. But um, I want to talk about a very, very exciting feature which Axelar brings. Um, if you remember what we talked about in the early days of bridging, what you can do is actually use wrapped assets um, to interact with different blockchains. And this is really, really cool using wrapped assets, but we want to do a lot more than just use wrapped assets and that's the be-all and end-all of interoperability.

And that's where General Message Passing comes in. So what is General Message Passing for those who haven't heard? It's, well, exactly like it sounds. It's the ability to send messages from one blockchain to another blockchain. Okay? So you can see here um, a very simple example. Myself on Ethereum and myself on Avalanche. And in the first message I am saying like 'Hey wagmi?' Um, 'Are we going to make it in this crazy ecosystem that we find ourselves in?' Um, and then on Avalanche back to Ethereum I'm sending a message saying like 'Hey, safeMint() 5 apes'.

And what I'm trying to show you here is that in addition to sending like silly little 'hello world' messages like I'm sending on this top example here, what you can actually do is send function calls from one blockchain to another. You can send data from one blockchain to another that you could use in a function call on another blockchain. And that is true interoperability. It's the ability to actually interact with contracts on different blockchains as easily as you can interact with them on your own blockchain. Um, I'm going to stop here for any questions um, that people might have. Yeah, gang. Be sure to ask any questions you may have in the comments and I will bring them up on the screen here. Um, and I guess one question from me before we get you continue on, why Cosmos? Why Cosmos over any other chain to act as the foundation on Axelar?

Yeah, Cosmos was a very easy way to actually develop the Axelar blockchain in it and itself. Um, so there are other ecosystems there to develop app-chains, but I think Cosmos was just a very simple way to develop um, to develop an actual blockchain to handle the security of the interoperability layer of Web3. Again, the the key feature which Axelar has for security is the fact that it that Axelar actually is a blockchain. Um, having it so it allows for the most decentralized secure approach to actually sending or to handle interoperability between different blockchains. And Cosmos just presented itself as an easy way to do that. Awesome. Excellent. No, no other questions thus far, but I'll let you know if anything comes up.

Awesome. So just to recap where we were, we were talking about General Message Passing. It's the ability to actually send data between blockchains. So I want to go into this a bit deeper and then we're actually going to step through a brief code example with whatever time we have left.

Um, so the way this works under the hood, let's say I want to send an ERC-20 token and a message from Avalanche to Polygon. Okay? So you have a smart contract which you have deployed on two blockchains, Avalanche and Polygon. And now what you have to do is, your contract could be a game, it could be a DeFi protocol, it could be anything. But what you have to do actually to trigger that interchain message from Avalanche to Polygon is import a service called the Gateway. The Gateway is a contract which Axelar has deployed on at every different blockchain which is connected to Axelar. So you have to import that Gateway. And then the Gateway exposes several different functions. One of those functions is callContractWithToken(). Uh, so let's say you have your contract, you import the Gateway and then you call this function. This now triggers a trans- this now triggers a transaction which basically allows the Gateway to emit an event.

The event is then submitted via a relayer to the Axelar network. The Axelar network, which remember this X right here is an actual blockchain. Um, so it's maintained by 75 validators. Um, and those validators will basically come to consensus about this message like 'Hey, did Ben actually send this message from Avalanche and is it actually going to Polygon?' If yes, then we notify the Gateway on the destination chain, at this point on Polygon, that 'Yes, Ben actually did send this message. We are confirming that we're good to go'. And then the Gateway via something called a relayer will call this executeWithToken() function, which we will have written on our smart contract on our destination chain. And then in the executeWithToken() function, we can do any bit of logic which we want um, with that data. And I know that was a lot and we will actually go through a code example so you can see all this in action step-by-step. We'll break it down very, very clearly.

Um, but one more time, just before we get into the code, our contract is deployed on Avalanche and on Polygon. The contract on Avalanche imports the Gateway, it executes with this callContractWithToken() function which is defined on the Gateway. The Gateway emits an event. The event goes to the Axelar network. It comes to consensus about the message that was sent. It notifies the Gateway on the destination chain like 'Yes, this message was sent' and then it calls the executeWithToken() function which we will have implemented on our contract.

So let's actually step through this. Um, can you guys see, yeah. Ben, we do have a couple questions. Did you want to save them for the end or go through them? Ah no, let's let's go through it now while while I'm talking. Sure. Um, so one here, Nikitas asks, 'Is Axelar centralized or is it decentralized?'

Yeah, so remember what I was saying before, that Axelar is a blockchain of blockchains with 75 validators. So it's as decentralized as an interoperability solution as you can get because these are 75 validators, it's permissionless, we don't control like who's going to be a validator who's not going to be a validator. Um, anyone can go and stake a bunch of AXL token and if you're one of the top 75 validators then you will actually be um, a validator who's maintaining this network. Um, we plan on increasing that number from 75 validators to to much more. Um, for now that's what we're at, but compared to other interoperability solutions it's by far the most decentralized solution uh, to conducting interoperability.

Sweet. Another question here. Vasilika asks, 'What blockchains are harder to connect than others?' I guess is there a special, a certain type of blockchain that's harder to integrate with Axelar than another?

Yeah, that's a great question. It's not a question for me unfortunately. I have not connected blockchains to Axelar. Um, I know that we're working on many other blockchains including um, hopefully Solana coming out soon. Um, but actually that is a good segue for um, a new feature that's coming out very soon. Um, and I'll talk about that very briefly before we get into the code example and it's called the Axelar Virtual Machine. So right now we have 53 blockchains that are connected to Axelar. Um, this is the most of any interoperability solution. And the thing is, right now every new chain that is connected to Axelar actually has to go through the Axelar team um, to actually onboard that chain.

The Axelar Virtual Machine changes that. It allows teams to actually connect their blockchain to the Axelar ecosystem themselves. Um, so right now I think that's scheduled to still launch before the end of the year, the Axelar Virtual Machine. Um, but that is kind of our holy grail of interoperability, the idea that that anyone can connect their own chain and that's how we get from 53 blockchains that are connected to hundreds or hopefully thousands of blockchains connected via Axelar someday. Interesting. Yeah. Um, one last one I think is almost similar to Vasilika's is 'Do you face any differences when connecting a Proof-of-Stake chain versus a Proof-of-Work chain?'

Good question. Um, again, I have not personally been involved in the process of connecting chains. I think I don't think we have any proof-of-work chains connected right now. Most of our chains that are connected are either with Proof-of-Stake consensus mechanism or that are Cosmos chains with CometBFT um, or formerly known as Tendermint. Sweet. Yeah, all good. And uh, great questions gang. Keep them coming. Uh, in the meantime let's get into the code here.

Yeah, awesome. And for record, continue asking questions. Feel free to cut me off at any point. I want to keep this as informal as possible and and as helpful as possible. Um, so what we're going to try to do here in this contract, and I just want to refresh you guys on this chart right here, we're going to actually be implementing a contract which will go through the steps that we just outlined of a protocol which or a smart contract which will send a token and a message via the Gateway contract or with the Gateway contract via the Axelar network to um, our smart contract which will be deployed on another blockchain. And remember these two key functions: callContractWithToken() and executeWithToken(). We're going to be using both of these.

So first off, can you guys see my code or should I make it bigger? Sorry. Uh, could you make it a teensy bit bigger? Uh, sorry about that. Yeah. Better? Or a bit bigger? I think that's good. I think that should be good. Yeah. Sounds good. Um, yeah so we import the ERC-20 interface, we import the Axelar Executable which I will come back to this import in a bit, we import the Axelar Gateway interface. Remember the Gateway, that is let me flip this so you guys can see it, sorry.

The Gateway interface, that is this contract which I was referencing here in the diagram. So we import this interface. We then import the Axelar Gas Service, which I have not talked about yet and I'm going to get into now quickly. The Gas Service is basically a tool which the Axelar team makes available um, for you to actually have an easier experience sending an interchain transaction. So if we think about it, if we want to send a transaction from let's say Polygon to Ethereum via Axelar, that means you'll need three tokens. You need MATIC for Polygon, you need AXL, which is the token for Axelar because remember Axelar is a blockchain so gas needs to be paid on it as well, and third, you'll need Ether, the token of the destination chain which in this example is Ethereum. Now I don't know about you guys, but I don't want to have to hold three different tokens each time I want to send an interchain transaction.

So what the Axelar Gas Service does is it abstracts that difficulty. It basically says you only need to pay the interchain transaction in the token of the source chain. So in the example of sending a message from Polygon to Ethereum, all I need is MATIC. I just pay MATIC to the Gas Service and it handles actually paying the gas on the Axelar blockchain for us and on the destination chain on Ethereum. That doesn't mean we actually get the payment for free, the money still comes out of our pocket but we pay it in the form of the source chain. So that is the Gas Service. So let me go to step 2 actually start writing this out.

So the first thing we do is write out our constructor function, which we're going to pass in the address of our Gateway and our Gas Service. Remember these are contracts which are deployed by the Axelar team um, which we will need to actually interact um, with the Axelar network. We pass in the address of the Gateway to the Axelar Executable. Um, we then pass in the address of the Gas Service to this public variable right here on line 11. Step 3 is where it starts to get interesting. We have our first function called sendToMany(). Um, and these um, inline comments here are just to help a bit, but I will speak about it myself. This is a function which we're defining which we're going to actually use to send an ERC-20 token and a message from one blockchain to the other. So it takes five parameters.

It takes, hey, what is the name of the destination chain? Like where is this going to? What is the address on the destination chain that we're going to? So like we're sending to Ethereum let's say, well, once we get to Ethereum where are we going to in Ethereum? Like what address are we going to be interacting with? So that's the second parameter. The destinationAddrs, this is a third parameter which I promise I will come back to, don't worry about it for now. And the last two parameters are relevant to the token which we're sending. So what is the symbol of the ERC-20 token that we're sending and what is the amount, like how many tokens are we sending? Is that clear these five parameters? So destination chain, the address in the destination chain, a mysterious third parameter which I'll get to, the symbol of the token and the amount of the token.

I'll go to step 4 in the meantime. So let's actually start writing out this logic. The first thing we want to do is a simple require statement. We say like 'Hey make sure that some gas or some tokens are sent along with this contract'. Uh message.value is greater than zero, which we will eventually use to pay the Gas Service. If we don't send any message.value, we revert because we will not be able to pay the Gas Service. Next thing we want to do is with our friendly Gateway contract, remember that we um, that we passed in earlier up here we're passing in. Um, we will pass in the symbol of the token that we're going to be sending and the Gateway contract will return an address of that token. We're going to need the address of the ERC-20 token to actually um, interact with it.

Now with the address of that token, we're going to be doing some standard ERC-20 functionality. We're going to transfer the tokens from our from our wallet to this contract and then we're going to approve the Gateway to spend the tokens on our behalf. And then we are going to encode this third parameter which I promised that I would talk about. So remember what we're trying to do here. We're sending this ERC-20 token from one blockchain to another, but what we're also doing is sending this message. For example, 'wagmi' um, we're sending a message from one blockchain to the other.

Now to send that message from one blockchain to another, there's a very specific data type which it needs to be at and that is bytes. So notice this third parameter is an array of addresses, so we're going to be encoding that into a type bytes so we can actually send that message, this array of addresses, um, across Axelar to our destination chain. Step 5 is where we actually now interact with Gas Service, with with Axelar services. The first one is this Gas Service, remember which we um, we passed in earlier. And the Gas Service um, is going to be exp- exposing this function called payNativeGasForContractCallWithToken(). Um, and basically what this function does is it's going to allow us to send in a message.value, send in our native token, and then basically tell the Gas Service like which blockchain will we be needing uh, gas for? Where do you need to pay the token um, to?

And then our final parameter here, um, a very important parameter is message.sender. So if let's say we have a transaction which costs half an ETH, but we send in one ETH to the Gas Service, then it will refund us the difference. So this is basically saying like 'Hey, where's the refund supposed to be going to?' Um, and these other parameters here are specifying like the chain, the destination chain, like where is the destination chain, so which chain will we be needing gas gas payment for, um, and then our other GMP related functionality. So our destination contract address, our message, our symbol of the ERC-20 token and the amount.

Then we will actually be interacting with our Gateway contract with the callContractWithToken() function. Remember that is the function which I had pointed out here on our on our diagram. So our callContractWithToken() will require the same parameters which we just passed in before. Um, so the name of the chain where we're going, the address on the chain where we're going, what is the the GMP message that we're actually sending? Uh, so our encoded recipient addresses here, that is our message that we're sending, the symbol of the token and the amount of the token. So if we pause right here and we actually call this function, we will now successfully pay gas to our Gas Service and then with our Gateway contract actually trigger a transaction that will go to Axelar and then come out the other side on a new blockchain.

So that's great, we've done this first half and I promise the second half will be faster. Uh, we have to implement one more function because once we get to that um, to the destination chain, well what do we do? Well, what's going to be called is this executeWithToken() function. That is this function here on the other side. Okay?

And once we get in our executeWithToken() function, we're going to have to implement some logic. So the only parameter I want you guys to focus on right now for here is our payload. And what the payload is, is this message that we sent from one blockchain to the other. It's going to be our list of addresses. So, we want to decode that list of addresses, so we decode the payload which is of type bytes. So now we have a list of addresses. Remember that list of addresses is relevant to this list of addresses that we passed in. It's the same data that's just on the other side now. We then grab our token address of the token that was sent from one blockchain to the other. We then want to run some very basic functionality. So imagine we send six tokens, six USDC, from chain A to chain B and we sent three addresses in that list of addresses. And now let's say we want to divide up those six tokens and send it to those three addresses.

So now we have two tokens that are going to each address and now we simply loop over that list of addresses and transfer the tokens. And that is it. That will allow us to actually in a very, very simple contract, send tokens from chain A to chain B. With that those tokens that were sent we also send a list of addresses. Then on our executeWithToken() function, we decode that message so now we have our list of addresses again. We then divide up the tokens between those addresses on a different blockchain, keep that in mind, and we send those tokens evenly. Um, any questions so far before I run this? I know we're short on time here.

There is a question, but uh, let's let's finish this one off and then we'll get to it.

Sounds good. So, I'm going to run our deploy script to actually oh whoops. Let me get back to the main branch. The deploy script is basically deploying this contract, let me zoom out a bit. It's deploying this GMP Distribution contract on two different blockchains. Okay? Now hopefully it goes fast. There we go, so we've deployed it on Polygon at this address and it should also I think be deploying it on Fantom.

Now we're going to use our hardhat console to interact with this live with this contract GMP Distribution live on Polygon. So I use our Ethers factory. I pass in this address that we just deployed to. So now we actually have this contract live on the Polygon blockchain and we can now actually interact with it. So which function do we want to interact with? We want to do the sendToMany() function. So let's pass in the parameters which this function needs.

It needs the destination chain, so let's say Fantom. It needs the destination contract address, so that is this contract which we deployed on Fantom. It needs a list of addresses which will be our GMP message. I have this saved here from before, so we now pass in this array of three addresses. It needs the symbol of the token that we're sending, aUSDC, and how many tokens do we want to send? Let's say 6 million, or six but it's USDC so it's six decimal points. And then the last thing we need to do is pass in some gas or it will revert as per our require statement. Um, let me pass that in here and now once we press enter here, it executed.

And I wish I had more time to show this off, but we will actually be using Axelarscan to track this transaction. So I can pass in that hash which was just spat out to us. And you will be able to actually see this transaction going through Axelarscan. Cool. I did not pay enough gas. I could actually do that here directly via Axelarscan. Um, should pop up a transaction, I confirm it and now gas is actually being topped off here. So for time sake we're not going to wait for this transaction to get through. I want to show you what a complete transaction looks like.

You see the transaction was sent from Polygon to Fantom. You can see all the steps that were that have taken place to send the transaction of paying the gas, confirming the transaction on the Axelar blockchain, and then eventually executing it on the destination chain. From Axelarscan I can actually click here and it takes me to the native blockchain um, which the transaction executed on. So for example, I'm sending from Polygon, I can press to here and it'll take me right to Mumbai and I can see this transaction being executed on Mumbai.

And I can see on the destination chain on Fantom we received those six tokens and sent two of them to each of those three addresses that we sent in. So that is an example of a message and tokens being sent through Axelar from one blockchain to the other. Um, yeah any questions on that?

That was pretty neat man. Uh, yes, one good tangent question here. Uh Ankur Daharwal asks: 'You mentioned that the Gateway is a smart contract deployed on all blockchains within the Axelar network. How is a gateway added to a network that doesn't support smart contracts, for example: Bitcoin?'

Yeah, we're not connected with Bitcoin right now. I'm not sure how that would work in the case of Bitcoin, but right now we're with um, well I'll I'll stick to EVM right now. All the EVM chains that we're on actually do support smart contracts. There are other Cosmos chains that were we're connected to that um, some that support CosmWasm, some that don't. Um, it's a bit different in the Cosmos ecosystem. I'm going to stick just to EVM for now. All the EVM chains that we are on support smart contracts. Sweet. And I suppose adding support is basically a an internal process within Axelar to onboard a new chain onto the the hub, pretty much.

Yes, until what I was talking about before, the Axelar Virtual Machine is rolled out. We're still onboarding uh, each new chain ourselves.

Cool. Uh, I guess um, yeah unfortunately we are are close to time here. Uh one question I want to ask you uh that I didn't get a chance to mention in the beginning is um, how did you end up uh with Axelar? I know you mentioned an interesting story uh that all began I I want to get that in here just before we we leave off.

Yeah, yeah. So I I kind of went into the talk a bit fast for time sake, but it it really is a special talk for me giving this one at DevNTell. I actually um, was able to get into Axelar largely because of Developer DAO um, last year when Consensus conference happened in Austin. I was able to score tickets to that conference um, through Axelar, or sorry through Developer DAO um, at that conference where I connected with my now manager there. Uh so that really kicked off the process for me um, joining Axelar. I really owe a lot to Developer DAO, so it's a big moment for me to now be speaking uh with Developer DAO on behalf of Axelar.

That's an awesome story man and yeah sometimes you never know. You just go to a conference or you just participate in the space and you never know what will happen. But uh in this case the the best possible outcome happened. So I'm I'm really glad to hear that and have you on here today as well to to share uh Axelar and your experience with us. Uh I guess just before we uh leave off here, what's the best way for people to get in touch with you or Axelar Network if they're interested in starting playing around?

Yes, yes, yes. So, I didn't get a chance to go through all the slides here. These are some QR codes I want to leave for you guys open here. I'll leave them for briefly. On the left is QR code for a list of of videos that we have um, just going through like the example I just gave as well as other simple examples using Axelar. On the right is a link to a really, really awesome GitHub repository that we have uh showing off um examples of actually using Axelar. Um, some of them even have front-ends wired up to that, so I highly encourage everyone to check both of these out. Both the YouTube tutorials on the left and the GitHub repository on the right.

For me personally, um, you can email me ben@axelar.network, you can message me on LinkedIn, um, Facebook, um yeah anyway possible, um Twitter, um I'm super happy to connect even if it's like a year from now. Don't ever hesitate reaching out. I'm always happy to chat about this stuff. Um, yeah.

Excellent. And uh yeah gang we'll have all those resources for you um in the description of the YouTube video below. Uh I don't believe we have the examples there but we'll get those added um ASAP uh right after the call. Beauty. Yeah, so if you can get those uh scanned, uh I have one more QR code for everybody to scan once uh you're all done in 3, 2, 1.

Do you want to share your screen?

Ah, not the screen but bang! This QR code right here. Uh so this QR code, uh I know we had a lot of QR codes. Uh this QR code is for you to scan, those of you in the audience uh who were attendees today at DevNTell, for you to get your NFT for being an attendee today. So what you want to do is grab your regular QR code scanner, scan this bad boy, fill out the form and you'll be air dropped a attendee NFT within the next couple of days uh for coming on the show with us today. Uh and you'll have an hour and a half from uh right now to do that uh before the form closes.

And with that, I just want to wish everybody a very happy Friday, happy weekend. Ben, thank you again for coming on the show. Uh really informative, interesting talk. Uh I personally didn't know about Axelar Network before, but uh it seems like a very promising project that I'll be uh digging through and adding to my list of things to uh research. Yeah, one last shameless one last shameless plug here. I just wanted to show this off. We just hit our millionth transaction, I believe it was this week or maybe maybe last week. But very recently we've had almost $7 billion dollars in volume go through us, so it's a really exciting time to to now get into Axelar.

Amazing. Congratulations. And yes, uh like I said, uh looks really neat and uh I'll definitely be researching it a bit more uh after today. Uh and with that, uh yeah again, just have a happy weekend everybody. Happy Friday, and uh we'll catch you back here next week on DevNTell. See ya gang. Peace. Thank you. Bye.