Axelar’s General Message Passing (GM(P)) technology offers a powerful solution for cross-chain communication and composability in the Web3 ecosystem. This innovative web3 technology enables developers to call functions on any connected blockchain, facilitating seamless interaction between smart contracts, applications, and protocol layers. By connecting Ethereum Virtual Machine (EVM) and Cosmos ecosystems, GM(P) supports a new generation of cross-chain applications that can take advantage of the unique features offered by each chain. With ongoing development and increasing adoption, GM(P) is set to become a critical component in the future of decentralized
applications and protocols.
Features
Cross-Chain Composability:
Axelar’s GM(P) enables a developer to call functions on any connected chain, including smart contracts at the application layer and functions built at the protocol layer. This cross-chain composability allows for a wide range of applications and use cases, such as calling a contract on one chain from another chain, or calling a contract and attaching tokens from a different chain.
Supported Chains:
GM(P) currently supports EVM and Cosmos chains, with plans to add more chains and technology stacks in the future. For GM(P) to work, both the source and destination chains must have a deployed Axelar Gateway contract. The list of supported EVM chains is regularly updated as new chains are added.
Architecture
The GM(P) architecture consists of a series of steps that enable cross-chain communication,
Source Chain:
User (dApp) calls a callContract (or callContractWithToken) function on the Axelar Gateway contract to initiate a call. The user can then track the status of the call on the AxelarScan website or programmatically via the AxelarJS SDK.
The user prepays the relayer gas fee on the source chain to Axelar’s Gas Services contract.
The call enters the Axelar Gateway from the source chain.
Axelar Network:
Axelar network confirms the call and converts the paid gas from the source chain’s native token into the destination chain’s native token.
Destination Chain:
The call is approved and emerges from the Axelar Gateway on the destination chain.
The executor service relays and executes the approved call to the application’s Axelar Executable interface.
If the paid gas is insufficient to relay the transfer to the application interface, monitoring and recovery steps are in place to deal with such scenarios.
Expansion to Cosmos
Axelar has expanded GM(P) to support Cosmos blockchains, allowing for the sending and receiving of messages on both EVM and Cosmos chains. Messages sent to Cosmos chains can be received by CosmWasm smart contracts or natively at the consensus layer as part of Go code. This expansion enables a broader range of cross-chain communication and applications.
Real-World Applications
Axelar’s GM(P) technology is already being used by projects like Sommelier Finance, a Cosmos-based smart-vaults protocol. By connecting to Arbitrum using GM(P), Sommelier Finance can run vaults across the combined architecture of its Cosmos appchain and Axelar GMP, accessing unique DeFi applications like GMX on Arbitrum One. GM(P) allows applications to securely move any payload cross-chain, including function calls and other logic, providing a level of interoperability that goes beyond traditional bridges.
Development and Testing
Axelar has created a simple local development environment to help developers create EVM chains, develop, and test their contracts end-to-end. This environment allows for the simulation of all steps of the computation and the relaying of transactions locally. Once satisfied with the results, developers can transition to the testnet.
Integrating with General Message Passing
Developers who wish to utilize GM(P) in their applications should follow a series of steps to integrate with the Axelar network. These steps vary depending on the type of chain and the method of communication. Please see their documentation for details.
Messages from EVM to CosmWasm
To send a message from an EVM chain to a Cosmos CosmWasm contract, the payload must be encoded before calling the standard payNativeGasForContractCall and callContract methods (or token-including equivalents). The payload must specify the method name of the CosmWasm contract to call, the names of all arguments, the types of all arguments, and the values of all arguments. An example encoding can be found in the MultiSend Example provided earlier in the conversation.
Messages from EVM to Native Cosmos
When sending a message to a Cosmos chain with native (consensus layer) support for GM(P), developers must encode a version number with the intended payload. This allows the consensus layer to know what to do with the payload.
Messages from Native Cosmos
To send a message from Native Cosmos Go code, developers must send a message to the Axelar GMP Account via IBC. When sending messages from Cosmos, standard GM(P) ABI encoding should be performed using the github.com/ethereum/go-ethereum/accounts/abi package.
Messages from CosmWasm
To send a message from CosmWasm Rust code, developers must send a message to the Axelar Gateway via IBC. Payload encoding should be done using ethabi.
Chain Support
For a Cosmos blockchain to support receiving GM(P) messages (naively or via CosmWasm), it should implement the appropriate middleware in Go as part of the consensus layer.
