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
- What is an OFT Adapter?
- Key Features
- Deployment Requirements
- MintBurnOFTAdapter
- Requirement
- Contracts Structure
- 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', }
We recommend using pnpm
as a package manager (but you can of course use a package manager of your choice):
pnpm install
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"
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"
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)
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.
-
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.
-
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.
-
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.
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).
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
.
This is a periphery contract for minting or burning tokens and executing arbitrary calls on the underlying ERC20.
This is the actual OFT Adapter contract that maintains two constants: innerToken
and minterBurner
innerToken
: underlying ERC20 implementationminterBurner
: reference to theIMintableBurnable
implementation that has the implementation ofburn
andmint
functions
_debit
: Callsburn
onminterBurner
effectively burning tokens from sender's balance from source chain._credit
: Callsmint
onminterBurner
, 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
.