LogoLogo
  • ⏩Introduction
    • Hyperlane Introduction
    • Getting started
    • Why Should You Use Hyperlane?
  • Permissionless Interoperability
    • Overview
    • Deploy Hyperlane
    • Warp Routes
      • Deploy a Warp Route
      • Deploy a UI for your Warp Route
    • Modular Rollup Interoperability
  • Build With Hyperlane
    • Quickstarts
      • Messaging
      • Accounts
      • Queries
      • hyperlane-quickstart repo
    • Guides
      • Finding my messages
      • Automatically pay for interchain gas
      • Manually pay for interchain gas
      • Choosing an interchain gas paymaster contract
      • Unit testing
      • Specifying an ISM
      • V2 migration guide
    • Explorer
      • Debugging messages
      • Configuring PI Chains
      • REST API
      • GraphQL API
    • Troubleshooting/Developer FAQ
    • Example apps
  • APIs and SDKs
    • Messaging API
      • Send
      • Receive
    • Accounts API
    • Queries API
    • Warp Route API
    • Interchain gas paymaster API
    • Hyperlane App Framework
      • Example usage
        • HelloWorld
        • Interchain Token
      • Solidity SDK
        • HyperlaneConnectionClient
        • Router
      • NodeJS SDK
        • RPC Providers
        • Deployment
        • Interchain testing
        • Quoting gas payments
        • App Abstraction
    • Hooks API
      • Contract addresses
  • Protocol
    • Overview
    • Mailbox
    • Interchain security modules
      • Interface
      • Multisig ISM
      • Routing ISM
      • Aggregation ISM
      • Optimistic ISM
      • Wormhole ISM
      • Hook ISM
      • CCIP-Read ISM
    • Interchain gas payments
    • Staking and slashing
    • Agents
      • Validators
      • Relayers
      • Watchtowers
    • Warp Routes
    • Implementation Guide
  • Operators
    • Validators
      • Guide
      • AWS setup
      • Monitoring and alerting
    • Relayers
      • Guide
      • Message filtering
    • Agent keys
      • Hexadecimal keys
      • AWS KMS keys
    • Agent configuration
      • Configuration reference
    • Running with docker compose
  • Resources
    • FAQ
    • Glossary
    • Contract addresses
      • Permissionless Deployment Contract Addresses
    • Domain identifiers
      • Permissionless Domain Identifiers
    • Default ISM settings
    • Coming Soon: Hyperlane v3
    • Token sources & faucets
    • Latencies
    • Github
    • Discord
    • Website
Powered by GitBook
On this page
  • Choosing a relayer
  • Choosing an IGP contract
  1. Build With Hyperlane
  2. Guides

Choosing an interchain gas paymaster contract

Which IGP contract should you use?

PreviousManually pay for interchain gasNextUnit testing

Last updated 2 years ago

There may be many interchain gas paymaster (IGP) contracts on a given chain, this guide helps you understand which one you should use to pay for message delivery.

Choosing a relayer

Each relayer must deploy one or more IGP contracts through which it can accept payment to deliver messages to a remote chain.

Not all Relayers will be able to deliver all messages. For example, some relayers may only deliver messages between a specific subset of chains, or some relayers may only deliver messages between specific sender and recipient contracts.

Be sure that you're using an IGP for a relayer that is capable of delivering all of the messages that your application might send.

In some cases, this may mean using different IGP contracts depending on the destination of the message.

Choosing an IGP contract

Many relayers will deploy two types of IGP contracts. Read below to understand which one to use and how to use it.

When using the default ISM (for most applications)

If the message recipient uses the default Interchain security modules, your application can make use of the DefaultIsmInterchainGasPaymaster.

The default ISM is the security module used if no security model is specified explicitly by the recipient. Learn more about Specifying an ISM.

When using the DefaultIsmInterchainGasPaymaster, the _gasAmount to use when calling the payForGas or quoteGasPayment functions only needs to be the amount of gas that your message's recipient handle function will use at the destination.

Behind the scenes, the DefaultIsmInterchainGasPaymaster is configured to automatically add to the provided _gasAmount all overhead gas amounts that your message will use at its destination-- this includes any gas used by the Mailbox or the default ISM (for example, verifying validator signatures). This allows messages to be fully paid for without requiring any knowledge of the internal gas usage of the destination's Mailbox contract or default ISM when a message is processed.

Find the deployed contract addresses for the Abacus Works relayer.

When using a custom ISM (advanced)

If the message recipient is Specifying an ISM other than the default ISM, you should instead use the InterchainGasPaymaster.

This IGP requires that the _gasAmount used when calling the payForGas or quoteGasPayment functions accounts for all gas required by the relayer to process the message on the destination chain.

The gas amount required to process the message should include:

  • Intrinsic transaction gas costs, including gas for calldata

  • The amount of gas used by the Mailbox.process function

  • The amount of gas used by the ISM to verify the message

  • The amount of gas used by the message's recipient handle function

TL;DR

Recipient specifies an ISM
IGP Contract
_gasAmount

No

DefaultIsmInterchainGasPaymaster

Only recipient handle function gas usage

Yes

InterchainGasPaymaster

All gas used by a transaction that processes the message

Find the deployed contract addresses for the Abacus Works relayer.

DefaultIsmInterchainGasPaymaster
InterchainGasPaymaster