Skip to content

gmx-io/layer-zero

Repository files navigation

LayerZero

MintBurnOFTAdapter Example

Quickstart | Configuration | Message Execution Options | Endpoint Addresses

This repository contains an example implementation of the MintBurnOFTAdapter, a variant of the OFTAdapter.sol standard from LayerZero. The purpose of this contract is to enable the deployment of more than one OFTAdapter within the mesh network, by utilziing an already deployed ERC20 token's external mint and burn methods on each chain.

Homepage | Docs | Developers


Usage

OFTAdapter additional setup:

  • In your hardhat.config.ts file, add the following configuration to the network you want to deploy the OFTAdapter to:
    // Replace `0x0` with the address of the ERC20 token you want to adapt to the OFT functionality.
    oftAdapter: {
        tokenAddress: '0x0',
    }

Developing Contracts

Installing dependencies

We recommend using pnpm as a package manager (but you can of course use a package manager of your choice):

pnpm install

Compiling your contracts

This project supports both hardhat and forge compilation. By default, the compile command will execute both:

pnpm compile

If you prefer one over the other, you can use the tooling-specific commands:

pnpm compile:forge
pnpm compile:hardhat

Or adjust the package.json to for example remove forge build:

- "compile": "$npm_execpath run compile:forge && $npm_execpath run compile:hardhat",
- "compile:forge": "forge build",
- "compile:hardhat": "hardhat compile",
+ "compile": "hardhat compile"

Running tests

Similarly to the contract compilation, we support both hardhat and forge tests. By default, the test command will execute both:

pnpm test

If you prefer one over the other, you can use the tooling-specific commands:

pnpm test:forge
pnpm test:hardhat

Or adjust the package.json to for example remove hardhat tests:

- "test": "$npm_execpath test:forge && $npm_execpath test:hardhat",
- "test:forge": "forge test",
- "test:hardhat": "$npm_execpath hardhat test"
+ "test": "forge test"

Deploying Contracts

Set up deployer wallet/account:

  • Rename .env.example -> .env
  • Choose your preferred means of setting up your deployer wallet/account:
MNEMONIC="test test test test test test test test test test test junk"
or...
PRIVATE_KEY="0xabc...def"
  • Fund this address with the corresponding chain's native tokens you want to deploy to.

To deploy your contracts to your desired blockchains, run the following command in your project's folder:

npx hardhat lz:deploy

More information about available CLI arguments can be found using the --help flag:

npx hardhat lz:deploy --help

By following these steps, you can focus more on creating innovative omnichain solutions and less on the complexities of cross-chain communication.



Join our community! | Follow us on X (formerly Twitter)

What is an OFT Adapter?

OFT Adapter allows an existing token to expand to any supported chain as a native token with a unified global supply, inheriting all the features of the OFT Standard. This works as an intermediary contract that handles sending and receiving tokens that have already been deployed. Read more here.

Ideally, when you want to convert an existing ERC20 token with its current fixed supply into an Omnichain token, you can use the OFTAdapter as a wrapper around that ERC20.

There are several ways to go about it since the base code of OFTAdapter keeps contract logic implementation up to the developer. Eg., the Adapter could be implemented in such a way that the original ERC20 is locked inside the Adapter on chain A and the OFT is minted on chain B.

Key Features

  • Mint and Burn Access: Enables the MintBurnOFTAdapter to interact with ERC20 tokens that have minting and burning capabilities. This is crucial for maintaining unified token supply across different blockchain networks in a decentralized manner.

  • Access Control Integration: Ensures that only authorized entities (deployers or specific contracts) have the permissions to mint and burn tokens. This is managed through an access control or allowlist mechanism.

  • Multiple Adapter Deployments: Supports the deployment of multiple instances of the MintBurnOFTAdapter, each configured with different token contracts and LayerZero endpoints, thus enhancing flexibility in cross-chain operations.

Deployment Requirements

  1. ERC20 Token Access: The deployer must ensure that the ERC20 token contract allows the MintBurnOFTAdapter to access its mint and burn methods. This typically requires configuring the ERC20 token's access control mechanisms to include the adapter's address in an allowlist.

  2. Adapter Deployment and Configuration: Deploy the MintBurnOFTAdapter with references to the ERC20 token, the LayerZero endpoint, and any relevant delegate addresses. Add the address of the newly deployed MintBurnOFTAdapter to the ERC20 token's allowlist to enable minting and burning.

MintBurnOFTAdapter

MyMintBurnOFTAdapter is a variant of OFT Adapter that can use a token's external permissions to burn on chain A (source chain), as opposed to lock, and mint on chain B (destination chain).

Requirement

The only requirement is that the base ERC20 must have an external or public burn and a mint function, and implement the IMintableBurnable.sol interface found in ./devtools/packages/oft-evm/interfaces/IMintableBurnable.sol.

Contracts Structure

MinterBurner

This is a periphery contract for minting or burning tokens and executing arbitrary calls on the underlying ERC20.

MintBurnOFTAdapter.sol

Variables

This is the actual OFT Adapter contract that maintains two constants: innerToken and minterBurner

  • innerToken: underlying ERC20 implementation
  • minterBurner: reference to the IMintableBurnable implementation that has the implementation of burn and mint functions

Functions

  • _debit: Calls burn on minterBurner effectively burning tokens from sender's balance from source chain.
  • _credit: Calls mint on minterBurner, effectively minting tokens to sender's balance on destination chain.

Important

The default OFTAdapter implementation assumes lossless transfers, ie. 1 token in = 1 token out. If the underlying ERC20 applies something like a transfer fee, the default will not work. A pre/post balance check will need to be added to calculate the amountReceivedLD.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published