Adding Configurations
To configure your OApp, you will need to change yourlayerzero.config.ts for your desired pathways.
LayerZero’s CLI makes use of the @layerzerolabs/metadata-tools package, which allows for a human readable layerzero.config.ts file.
Here’s how to use it:
-
Install metadata-tools:
pnpm add -D @layerzerolabs/metadata-tools -
Create a new LZ config file named
layerzero.config.ts(or edit your existing one) in the project root and use the examples below as a starting point:- Example: EVM chains only
- Example: EVM chain and Solana
- The above examples contains a minimal mesh with only one pathway (two chains) for demonstration purposes. You are able to add as many pathways as you need into the
connectionsparam, viagenerateConnectionsConfig.
- Run the wire command:
config, containing multiple configuration structs for changing how your OApp sends and receives messages, specifically for the chain your OApp is sending from:
Adding sendLibrary
Every configuration should start by adding a sendLibrary.
lz:oapp:wire, this will call EndpointV2:
You should use the
sendLibrary address for the chain you’re sending from (i.e., SendUln302.sol on BSC).The MessageLib Registry is append only, meaning that old Message Libraries will always be available for OApps. Locking your Library is only necessary to prevent updates.
Adding receiveLibrary
Every configuration should also add a receiveLibrary. Similar to the sendLibrary, the OApp owner must also set the Receive Library to ensure that your configured application settings will be locked.
To do this, add a receiveLibraryConfig:
-
gracePeriod: the time to wait before updating to a new MessageLib version during version migration. If the grace period is 0, it will delete the timeout configuration. -
expiry: the time at which messages in-flight from the old library will be considered invalid. This is mainly for handling messages that are in-flight during the migration.
gracePeriod to 0 will be sufficient.
When running lz:oapp:wire, this config will call EndpointV2:
Adding sendConfig
Your sendConfig controls what DVN addresses and Executor addresses should be paid to verify and execute when a message is sent.
Each DVN and Executor contains both onchain and off-chain component. When sending a message, you pay the DVNs and Executors contracts on the source chain, and they relay the message to the equivalent contracts on the destination chain.For your
sendConfig, use the DVNs and Executor contract addresses on the same chain as your sending OApp.EndpointV2.setConfig:
configType and config:
Adding receiveConfig
The receive configuration controls what DVN addresses your OApp expects to have verified the message in-flight.
receiveConfig in EndpointV2.setConfig:
Adding enforcedOptions
You can specify both a minimum destination gas and msg.value that users must pay for both your contract’s lzReceive and “lzCompose` logic to execute as intended.
The CLI Toolkit enables you to configure your message options in a human-readable format, provided that your OApp has added an Enforced Options.
The Omnichain Fungible Token (OFT) Standard by default already has Enforced Options added to the contract, with two message types available:
OApp.setEnforcedOptions assuming your OApp has inherited from OAppOptionsType3.sol:
Adding delegate
Adding owner
Applying Changes
Wiring your contracts will set thepeer address for your OApp or OFT and initialize the desired configuration in your layerzero.config.ts.
Wiring Contracts
The CLI Tool makes this one step easier by enabling you to wire and configure your contract pathways with a single command:layerzero.config.ts to ensure that you have specified accurately the configuration you want to set.
Wiring your contracts will set the peer address for your OApp or OFT and initialize the desired configuration in your layerzero.config.ts.
The CLI Tool makes this one step easier by enabling you to wire and configure your contract pathways with a single command:
layerzero.config.ts to ensure that you have specified accurately the configuration you want to set.
Checking setPeers
To check if your contracts have correctly been set to communicate with one another, you can run:
Checking Pathway config
To confirm your OApp’s configuration has been set as intended, you can run:
Checking executor
To see your OApp’s configured executor, you can run:
Checking enforcedOptions
To see your OApp’s configured execution gas has been set as intended, you can run:
Checking Pathway defaults
To see what the default configuration is for any pathway, run:
Wiring via Safe multisig
If your contracts are owned by a Safe multisig wallet, you must define the multisig’ssafeUrl and safeAddress per chain in your hardhat.config.ts file to enable the submission of wire transactions for multisig approval. safeUrl refers to the URL of the Safe Transaction Service for a given network. For the endpoints deployed by Safe themselves on popular networks, you can find the URLs in the Safe Transaction Service API Reference.
Step 1: Configure your Safe multisig
In your hardhat config, addsafeConfig to your networks, with your network specific safeUrl and safeAddress mapped accordingly:
Step 2: Use your safe config
When wiring, pass the--safe flag in your wire command.
Ensure your development tools are up to date to utilize this feature, as it relies on the latest versions of the required dependencies.