LogoLogo
  • Introduction to Unizen
    • Unizen Overview
      • Unizen Liquidity Distribution Mechanism (ULDM)
        • ULDM Performance
      • Unizen Interoperability Protocol (UIP)
        • LayerZero
        • DeBridge
        • Stargate
        • Celer
        • Axelar
        • Thorchain
    • Unizen Dashboard
      • General
      • Portfolio
      • History
    • Unizen Trade
      • Fees
    • Unizen Explore
      • Unizen Omni-Chain Data Pool
    • Unizen Earn
  • ZCX
    • Token Utility
    • Tokenomics
  • API - Introduction
    • Introduction
    • Before you get started
      • Understanding Price Impact and Price Slippage in Token Swaps
      • Token Allowance Management for Non-updatable Allowance Tokens
      • Tokens with taxes
      • Wrapping and Unwrapping Native Tokens
      • Quote expiration deadline
    • Security Best Practices for Integrating Unizen
      • Why disable CORS
      • How to integrate with a reverse proxy
    • Version 2 of our smart contracts
      • Migration to smart contract v2
  • API - GET STARTED
    • QuickStart guide
    • Swagger
    • Information endpoints
      • GET /trade/v1/info/chains
      • GET /trade/v1/info/sources
      • GET/v1/info/cross-providers
      • GET /trade/v1/info/token/search
      • GET /v1/info/token/popular
      • GET /trade/v1/info/token/{chainId}/{tokenAddress}
      • GET /trade/v1/info/tokenLogo/{chainId}/{tokenAddress}
      • GET /info/thorchain-inbound-address
      • GET /trade/v1/info/tx/{txHash}
      • GET /trade/v1/info/trade/{chainId}/{txHash}
      • GET /trade/v1/info/trades
    • Approval
      • GET /trade/v1/{chainId}/approval/spender
      • GET /trade/v1/{chainId}/approval/transaction
      • GET /trade/v1/{chainId}/approval/allowance
    • Single-Chain Swap
      • GET /trade/v1/{chainId}/quote/single
      • GET /trade/v1/{chainId}/swap/single
      • Send transaction in evm chains
      • Send transaction in Solana
    • Cross-Chain Swap
      • GET /trade/v1/{chainId}/quote/cross
      • GET /trade/v1/{chainId}/swap/cross
      • Send transaction
    • Gasless orders
      • POST /trade/v1/gasless/typed-data
      • POST /v1/gasless/estimate
      • POST /v1/gasless/create
      • POST /v1/gasless/cancel
      • GET /trade/v1/gasless/status/{orderId}
      • GET /v1/gasless/orderByAddress/{address}
    • UTXO Assets and Cosmos Swap
      • GET /trade/v1/{chainId}/quote/cross 1
      • GET /trade/v1/{chainId}/swap/cross
      • Sending transactions
    • Efficient Quote Retrieval with Batch Processing
      • GET /trade/v1/{chainId}/batch_quote/single
    • Error Messages
  • GASLESS TRADES
    • Obtaining gasless quotes
    • Gas estimation
    • Executing the trade
    • Following the orders
  • On-Chain Contracts - Get Started
    • Integration with Unizen Contracts for Token Swapping
    • Registering Errors on Smart Contract Calls
  • PERMIT2
    • What is Permit2?
    • Usage in our api
  • WIDGET - Get Started
    • Embed the Unizen Widget
    • Playground
  • Other
    • Smart Contracts
    • Security Audits
    • Roadmap
  • links
    • Unizen
    • Marketing Website
    • Medium
    • Twitter
    • Discord
    • Telegram
Powered by GitBook
On this page

Was this helpful?

  1. Introduction to Unizen
  2. Unizen Overview
  3. Unizen Interoperability Protocol (UIP)

Axelar

Axelar delivers secure cross-chain communication for Web3. Secure means Axelar is built on proof-of-stake, the battle-tested approach used by Ethereum, Cosmos, Avalanche, and more. Cross-chain communication means you can build a complete experience for users that lets them interact with any asset, any application, on any chain with one click.

Gateway smart contracts

Gateway smart contracts allow Axelar to communicate messages across all connected chains. For each EVM chain connected to Axelar network, a Gateway contract is deployed to that chain. This Gateway contract is used to pass messages from the Axelar network to the connected chain, and the Gateway contract is controlled by a key, which is held jointly by all the Axelar validators. This is accomplished through a multi-party cryptography scheme, where the key is divided into many pieces, called key shares. Each validator holds many key shares, and the amount of shares is dictated by the amount of staked AXL tokens the validator has. The Gateway can only execute actions on the external chain if the number of validators holding key shares who authorize the action reaches a set threshold.

Validators

First, the validators participate in consensus on the Axelar network, producing blocks and validating transactions as with other proof-of-stake chains. Specifically, they perform the generic duties expected from validators of all Cosmos SDK-based chains.

Beyond this, Axelar validators also have additional duties as they are responsible for verifying all cross-chain activity being processed by the network. This requires validators to run nodes for Axelar-supported chains, and observe those external chains for activity. For example, in an asset transfer flow moving tokens from chain A to chain B, the user requesting the transfer must deposit tokens to a deposit address on chain A, and wait for Axelar network to confirm this deposit. This confirmation is done by the validators. A vote is started on the Axelar network, asking each validator to observe their chain A nodes for the deposit transaction made by the user. The validators then cast votes on whether or not the deposit transaction was observed on their chain A node. The votes are tallied and if the number of confirmation votes surpasses a set threshold, the deposit transaction is considered confirmed by the Axelar network.

At this point, Axelar's multi-party cryptography scheme kicks in. If destination chain B has an Axelar Gateway deployed, the tokens transferred must be minted by the Gateway smart contract and transferred to the user's chain B deposit address. Each Gateway contract is controlled by a key that is able to issue commands to the Gateway and approve transactions by signing. Each Axelar validator holds a piece of this key, called a key share. Validators agree through their confirmation votes to confirm a deposit and sign a transaction transferring the tokens to the user's address on chain B, which completes the asset transfer. Once enough key shares have agreed, the transaction can proceed.

Relayer services

Relayer services are a type of optional convenience service provided by Axelar. These are tasks that can be performed by anyone, and no form of trust is required to authorize or complete the task. These tasks are still important, as they must be done by someone to enable successful cross-chain communication. Because relayer services do not require any element of trust, and can be implemented by anyone, app developers within the Axelar community can choose to build their own version of existing relayer services for their app to use, instead of using the existing Axelar relayer services.

Gas receiver

The Gas Receiver is a smart contract that accepts tokens as payment to cover costs of contract execution for general message passing transactions. First, send funds to the Gas Receiver on the source chain, and specify the general message passing transaction that should be covered, as well as the payment token and amount. Axelar relayer services will confirm the gas payment on the source chain, then automatically execute the smart contract call on the destination chain when it gets approved.

PreviousCelerNextThorchain

Last updated 2 years ago

Was this helpful?