Skip to main content
Before setting your DVN and Executor Configuration, you should review the Security Stack Core Concepts.
Production deployments should use multiple required DVNs from independent operators. A single-DVN configuration means a compromise of that one verifier results in unrestricted forged messages on the pathway. The configuration examples on this page that show requiredDVNCount: 1 are illustrative only — production pathways should set requiredDVNCount >= 2 with DVNs from different operators. See the Integration Checklist for production DVN guidance.
You can manually configure your EVM OApp’s Send and Receive settings by:
  • Reading Defaults: Use the getConfig method to see default configurations.
  • Setting Libraries: Call setSendLibrary and setReceiveLibrary to choose the correct Message Library version.
  • Setting Configs: Use the setConfig function to update your custom DVN and Executor settings.
For both Send and Receive configurations, make sure that for a given channel:
  • Send (Chain A) settings match the Receive (Chain B) settings.
  • DVN addresses are provided in alphabetical order.
  • Block confirmations are correctly set to avoid mismatches.

Use the LayerZero CLI

The LayerZero CLI has abstracted these calls for every supported chain. See the CLI Setup Guide to easily deploy, configure, and send messages using LayerZero.

Self-Validation with cast

The recipes throughout this page use Foundry’s cast so you can read the exact on-chain values that govern message delivery on each pathway. Fill in the environment variables below once per pathway and the snippets in later sections will pick them up. Verify the EndpointV2 address for your chain at Deployed Contracts — the value shown is the current Ethereum mainnet address and most chains share it, but a handful do not.
These snippets are EVM-only. Solana, Aptos, Sui, TON, Starknet, Stellar, and Tron OApps must use their respective tooling — see the per-VM configuration pages under Developers.
# LayerZero V2 — environment for self-validation snippets
# Fill in for the pathway you are auditing.

# Source chain (A) — where messages are sent FROM
export RPC_A=https://...                      # JSON-RPC endpoint for chain A
export ENDPOINT_A=0x1a44076050125825900e736c501f859c50fE728c   # EndpointV2 on chain A
export OAPP_A=0x...                           # Your OApp address on chain A
export EID_B=30106                            # Destination endpoint ID (chain B)

# Destination chain (B) — where messages are RECEIVED
export RPC_B=https://...
export ENDPOINT_B=0x1a44076050125825900e736c501f859c50fE728c
export OAPP_B=0x...
export EID_A=30101                            # Source endpoint ID (chain A)

# Resolve libraries once per pathway
export SEND_LIB_A=$(cast call "$ENDPOINT_A" "getSendLibrary(address,uint32)(address)" "$OAPP_A" "$EID_B" --rpc-url "$RPC_A")
export RECV_LIB_B=$(cast call "$ENDPOINT_B" "getReceiveLibrary(address,uint32)(address,bool)" "$OAPP_B" "$EID_A" --rpc-url "$RPC_B" | head -1)
The UlnConfig tuple signature used in subsequent recipes is (uint64 confirmations, uint8 requiredDVNCount, uint8 optionalDVNCount, uint8 optionalDVNThreshold, address[] requiredDVNs, address[] optionalDVNs) and matches the struct defined in @layerzerolabs/lz-evm-protocol-v2. Older deployments may use different library versions — confirm against the ABI for the library address you resolved above.

Getting the Default Config

You can easily fetch and decode your OApp’s current Send/Receive settings via endpoint.getConfig(...). Below are two options:
// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.22;

import "forge-std/Script.sol";
import { console } from "forge-std/console.sol";
import { ILayerZeroEndpointV2 } from "@layerzerolabs/lz-evm-protocol-v2/contracts/interfaces/ILayerZeroEndpointV2.sol";
import { UlnConfig } from "@layerzerolabs/lz-evm-messagelib-v2/contracts/uln/UlnBase.sol";
import { ExecutorConfig } from "@layerzerolabs/lz-evm-messagelib-v2/contracts/SendLibBase.sol";

/// @title GetConfigScript
/// @notice Retrieves and logs the current configuration for the OApp.
contract GetConfigScript is Script {
    /// @notice Calls getConfig on the specified LayerZero Endpoint.
    /// @dev Decodes the returned bytes as a UlnConfig. Logs some of its fields.
    /// @param rpcUrl The RPC URL for the target chain.
    /// @param endpoint The LayerZero Endpoint address.
    /// @param oapp The address of your OApp.
    /// @param lib The address of the Message Library (send or receive).
    /// @param eid The remote endpoint identifier.
    /// @param configType The configuration type (1 = Executor, 2 = ULN).
    function getConfig(
        string memory _rpcUrl,
        address _endpoint,
        address _oapp,
        address _lib,
        uint32 _eid,
        uint32 _configType
    ) external {
        // Create a fork from the specified RPC URL.
        vm.createSelectFork(_rpcUrl);
        vm.startBroadcast();

        // Instantiate the LayerZero endpoint.
        ILayerZeroEndpointV2 endpoint = ILayerZeroEndpointV2(_endpoint);
        // Retrieve the raw configuration bytes.
        bytes memory config = endpoint.getConfig(_oapp, _lib, _eid, _configType);

        if (_configType == 1) {
            // Decode the Executor config (configType = 1)
            ExecutorConfig memory execConfig = abi.decode(config, (ExecutorConfig));
            // Log some key configuration parameters.
            console.log("Executor Type:", execConfig.maxMessageSize);
            console.log("Executor Address:", execConfig.executor);
        }

        if (_configType == 2) {
            // Decode the ULN config (configType = 2)
            UlnConfig memory decodedConfig = abi.decode(config, (UlnConfig));
            // Log some key configuration parameters.
            console.log("Confirmations:", decodedConfig.confirmations);
            console.log("Required DVN Count:", decodedConfig.requiredDVNCount);
            for (uint i = 0; i < decodedConfig.requiredDVNs.length; i++) {
                console.logAddress(decodedConfig.requiredDVNs[i]);
            }
            console.log("Optional DVN Count:", decodedConfig.optionalDVNCount);
            for (uint i = 0; i < decodedConfig.optionalDVNs.length; i++) {
                console.logAddress(decodedConfig.optionalDVNs[i]);
            }
            console.log("Optional DVN Threshold:", decodedConfig.optionalDVNThreshold);

        }
        vm.stopBroadcast();
    }
}

Setting the Send and Receive Libraries

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.22;

import "forge-std/Script.sol";
import { ILayerZeroEndpointV2 } from "@layerzerolabs/lz-evm-protocol-v2/contracts/interfaces/ILayerZeroEndpointV2.sol";

contract SetLibraries is Script {
    function run(
        address _endpoint,
        address _oapp,
        uint32 _eid,
        address _sendLib,
        address _receiveLib,
        address _signer
    ) external {
        ILayerZeroEndpointV2 endpoint = ILayerZeroEndpointV2(_endpoint);

        vm.startBroadcast(_signer);
        endpoint.setSendLibrary(_oapp, _eid, _sendLib);
        console.log("Send library set successfully.");
        endpoint.setReceiveLibrary(_oapp, _eid, _receiveLib);
        console.log("Receive library set successfully.");
        vm.stopBroadcast();
    }
}

Asymmetric Library Configuration

Pin the send and receive libraries on both sides of every pathway. If one side calls setSendLibrary / setReceiveLibrary and the mirror leaves the library implicit, the implicit side will silently inherit whatever LayerZero Labs ships as that EID’s default — and that default can change. Do:
  • Call EndpointV2.setSendLibrary(oapp, dstEid, sendLib) on the source side and EndpointV2.setReceiveLibrary(oapp, srcEid, recvLib, gracePeriod) on the destination side for the same pathway.
  • Pin the same library version on both sides — for example, SendUln302 on the sender, ReceiveUln302 on the receiver.
  • Re-run the validation snippet below any time you add a new chain, migrate to a new library version, or rotate the OApp’s delegate.
Don’t:
  • Leave one side on the default library because it “works today.” Defaults are mutable; LayerZero Labs may publish a new library version and roll the default forward without your involvement.
  • Assume getSendLibrary returning a non-zero address means the library is pinned — it falls through to defaultSendLibrary if the OApp has not set its own.
Default libraries are not a contract — they are a setting LayerZero Labs controls. If a default migration ships while only one side of your pathway is implicit, the explicit and implicit sides drift, and messages already in flight may stop verifying until you setConfig against the new library address.

How to check

# Compare each OApp's effective library against the endpoint's default for that EID.
APP_SEND_LIB=$(cast call "$ENDPOINT_A" "getSendLibrary(address,uint32)(address)" "$OAPP_A" "$EID_B" --rpc-url "$RPC_A")
DEFAULT_SEND_LIB=$(cast call "$ENDPOINT_A" "defaultSendLibrary(uint32)(address)" "$EID_B" --rpc-url "$RPC_A")
[ "$APP_SEND_LIB" = "$DEFAULT_SEND_LIB" ] && echo "A→B sender is on DEFAULT library" || echo "A→B sender pinned: $APP_SEND_LIB"

APP_RECV_LIB=$(cast call "$ENDPOINT_B" "getReceiveLibrary(address,uint32)(address,bool)" "$OAPP_B" "$EID_A" --rpc-url "$RPC_B" | head -1)
DEFAULT_RECV_LIB=$(cast call "$ENDPOINT_B" "defaultReceiveLibrary(uint32)(address)" "$EID_A" --rpc-url "$RPC_B")
[ "$APP_RECV_LIB" = "$DEFAULT_RECV_LIB" ] && echo "B receive is on DEFAULT library" || echo "B receive pinned: $APP_RECV_LIB"
If exactly one of the two prints DEFAULT, the pathway is asymmetric — pin both sides to the same explicit library.
getSendLibrary returning the same address as defaultSendLibrary does not prove the OApp is on the default. The OApp may have explicitly called setSendLibrary with the default’s address, in which case the side is pinned even though the equality test reports DEFAULT. To disambiguate, read sendLibrary[oapp][eid] directly from the endpoint: a value equal to the DEFAULT_LIB sentinel means implicit, any other address (including one that happens to equal the current default) means explicitly pinned. The same caveat applies to getReceiveLibrary / defaultReceiveLibrary.

Setting Custom Send Config (DVN & Executor)

In this example, we configure both the ULN (DVN settings) and Executor settings on the sending chain.
// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.22;

import "forge-std/Script.sol";
import { ILayerZeroEndpointV2, SetConfigParam } from "@layerzerolabs/lz-evm-protocol-v2/contracts/interfaces/ILayerZeroEndpointV2.sol";
import { UlnConfig } from "@layerzerolabs/lz-evm-messagelib-v2/contracts/uln/UlnBase.sol";
import { ExecutorConfig } from "@layerzerolabs/lz-evm-messagelib-v2/contracts/SendLibBase.sol";

/// @title LayerZero Send Configuration Script
/// @notice Defines and applies ULN (DVN) + Executor configs for cross‑chain messaging via LayerZero Endpoint V2.
contract SetSendConfig is Script {
    uint32 constant EXECUTOR_CONFIG_TYPE = 1;
    uint32 constant ULN_CONFIG_TYPE = 2;

     /// @notice Broadcasts transactions to set both Send ULN and Executor configurations
    function run() external {
        address endpoint = vm.envAddress("SOURCE_ENDPOINT_ADDRESS");
        address oapp      = vm.envAddress("SENDER_OAPP_ADDRESS");
        uint32 eid        = uint32(vm.envUint("REMOTE_EID"));
        address sendLib   = vm.envAddress("SEND_LIB_ADDRESS");
        address signer    = vm.envAddress("SIGNER");

        /// @notice ULNConfig defines security parameters (DVNs + confirmation threshold)
        /// @notice Send config requests these settings to be applied to the DVNs and Executor
        /// @dev 0 values will be interpretted as defaults, so to apply NIL settings, use:
        /// @dev uint8 internal constant NIL_DVN_COUNT = type(uint8).max;
        /// @dev uint64 internal constant NIL_CONFIRMATIONS = type(uint64).max;
        UlnConfig memory uln = UlnConfig({
            confirmations:        15,                                      // minimum block confirmations required
            requiredDVNCount:     2,                                       // number of DVNs required
            optionalDVNCount:     type(uint8).max,                         // optional DVNs count, uint8
            optionalDVNThreshold: 0,                                       // optional DVN threshold
            requiredDVNs:        [address(0x1111...), address(0x2222...)], // sorted list of required DVN addresses
            optionalDVNs:        []                                        // sorted list of optional DVNs
        });

        /// @notice ExecutorConfig sets message size limit + fee‑paying executor
        ExecutorConfig memory exec = ExecutorConfig({
            maxMessageSize: 10000,                                       // max bytes per crosschain message
            executor:       address(0x3333...)                           // address that pays destination execution fees
        });

        bytes memory encodedUln  = abi.encode(uln);
        bytes memory encodedExec = abi.encode(exec);

        SetConfigParam[] memory params = new SetConfigParam[](2);
        params[0] = SetConfigParam(eid, EXECUTOR_CONFIG_TYPE, encodedExec);
        params[1] = SetConfigParam(eid, ULN_CONFIG_TYPE, encodedUln);

        vm.startBroadcast(signer);
        ILayerZeroEndpointV2(endpoint).setConfig(oapp, sendLib, params);
        vm.stopBroadcast();
    }
}

Setting Custom Receive Config (DVN Only)

On the receiving chain, only the ULN (DVN) configuration is needed since the Executor is not enforced on destination (i.e., the call can be made by anyone without permission).
This config enforces all of the configuration settings from the source chain. Ensure that the DVNs in this config object match the sender side of the channel, otherwise messages will be blocked.Blocked messages can be caused by:
  • Mismatch of block confirmations: if source block confirmations are less than the destination
  • Mismatch of DVNs: the source DVNs do not match the threshold requirements of the destination
A mismatch will result in a config error, and in some cases can result in a loss of funds if not caught.
Since anyone can call endpoint.lzReceive(...) for a verified LayerZero message, if you require specific execution requirements you will need to enforce them in your child contract’s internal _lzReceive(...). See the Integration Checklist for more details.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.22;

import "forge-std/Script.sol";
import { ILayerZeroEndpointV2, SetConfigParam } from "@layerzerolabs/lz-evm-protocol-v2/contracts/interfaces/ILayerZeroEndpointV2.sol";
import { UlnConfig } from "@layerzerolabs/lz-evm-messagelib-v2/contracts/uln/UlnBase.sol";

/// @title LayerZero Receive Configuration Script
/// @notice Defines and applies ULN (DVN) config for inbound message verification via LayerZero Endpoint V2.
contract SetReceiveConfig is Script {
    uint32 constant RECEIVE_CONFIG_TYPE = 2;

    function run() external {
        address endpoint = vm.envAddress("ENDPOINT_ADDRESS");
        address oapp      = vm.envAddress("OAPP_ADDRESS");
        uint32 eid        = uint32(vm.envUint("REMOTE_EID"));
        address receiveLib= vm.envAddress("RECEIVE_LIB_ADDRESS");
        address signer    = vm.envAddress("SIGNER");

        /// @notice UlnConfig controls verification threshold for incoming messages
        /// @notice Receive config enforces these settings have been applied to the DVNs and Executor
        /// @dev 0 values will be interpretted as defaults, so to apply NIL settings, use:
        /// @dev uint8 internal constant NIL_DVN_COUNT = type(uint8).max;
        /// @dev uint64 internal constant NIL_CONFIRMATIONS = type(uint64).max;
        UlnConfig memory uln = UlnConfig({
            confirmations:      15,                                       // min block confirmations from source
            requiredDVNCount:   2,                                        // required DVNs for message acceptance
            optionalDVNCount:   type(uint8).max,                          // optional DVNs count
            optionalDVNThreshold: 0                                       // optional DVN threshold
            requiredDVNs:       [address(0x1111...), address(0x2222...)], // sorted required DVNs
            optionalDVNs:       []                                        // no optional DVNs
        });

        bytes memory encodedUln = abi.encode(uln);

        SetConfigParam[] memory params = new SetConfigParam[](1);
        params[0] = SetConfigParam(eid, RECEIVE_CONFIG_TYPE, encodedUln);

        vm.startBroadcast(signer);
        ILayerZeroEndpointV2(endpoint).setConfig(oapp, receiveLib, params);
        vm.stopBroadcast();
    }
}

Debugging Configurations

A correct OApp configuration example:
SendUlnConfig (A to B)ReceiveUlnConfig (B to A)
confirmations: 15confirmations: 15
optionalDVNCount: 0optionalDVNCount: 0
optionalDVNThreshold: 0optionalDVNThreshold: 0
optionalDVNs: Array(0)optionalDVNs: Array(0)
requiredDVNCount: 2requiredDVNCount: 2
requiredDVNs: Array(DVN1_Address_A, DVN2_Address_A)requiredDVNs: Array(DVN1_Address_B, DVN2_Address_B)
The sending OApp’s SendLibConfig (OApp on Chain A) and the receiving OApp’s ReceiveLibConfig (OApp on Chain B) match!

Block Confirmation Mismatch

An example of an incorrect OApp configuration:
SendUlnConfig (A to B)ReceiveUlnConfig (B to A)
confirmations: 5confirmations: 15
optionalDVNCount: 0optionalDVNCount: 0
optionalDVNThreshold: 0optionalDVNThreshold: 0
optionalDVNs: Array(0)optionalDVNs: Array(0)
requiredDVNCount: 2requiredDVNCount: 2
requiredDVNs: Array(DVN1, DVN2)requiredDVNs: Array(DVN1, DVN2)
The above configuration has a block confirmation mismatch. The sending OApp (Chain A) will only wait 5 block confirmations, but the receiving OApp (Chain B) will not accept any message with less than 15 block confirmations.Messages will be blocked until either the sending OApp has increased the outbound block confirmations, or the receiving OApp decreases the inbound block confirmation threshold.
The reverse case — send confirmations higher than receive (send-confirmations-higher) — does not block delivery: messages still verify. The sender simply waits more confirmations than the receiver requires, adding latency with no security gain. Resolve it by lowering the send-side confirmations to the receiver’s value (or raising the receiver’s to match, if you want the extra finality) via setConfig on the ULN.

DVN Mismatch

Another example of an incorrect OApp configuration:
SendUlnConfig (A to B)ReceiveUlnConfig (B to A)
confirmations: 15confirmations: 15
optionalDVNCount: 0optionalDVNCount: 0
optionalDVNThreshold: 0optionalDVNThreshold: 0
optionalDVNs: Array(0)optionalDVNs: Array(0)
requiredDVNCount: 1requiredDVNCount: 2
requiredDVNs: Array(DVN1)requiredDVNs: Array(DVN1, DVN2)
The above configuration has a DVN mismatch. The sending OApp (Chain A) only pays DVN 1 to listen and verify the packet, but the receiving OApp (Chain B) requires both DVN 1 and DVN 2 to mark the packet as verified.Messages will be blocked until either the sending OApp has added DVN 2’s address on Chain A to the SendUlnConfig, or the receiving OApp removes DVN 2’s address on Chain B from the ReceiveUlnConfig.
A DVN mismatch is blocking when the receiver’s required DVNs are not a subset of the sender’s effective DVN set, or when the worst-case overlap is smaller than the receiver’s threshold — messages cannot accumulate the attestations they need and the channel halts at the next nonce.

Non-Blocking DVN Mismatch

Pin identical DVN sets on both sides of every pathway. Some asymmetries do not block delivery — they still let messages verify — but they leave the on-chain enforced posture stricter than the documented send posture, which auditors and on-call engineers reading the send config will get wrong. A non-blocking DVN mismatch occurs when the send and receive DVN sets are not identical, but in every adversarial pick of send’s optional DVNs the receiver’s required-subset and optional threshold are still satisfied. Messages flow. Observed posture differs from enforced posture. Do:
  • Compare the merged (getUlnConfig) configurations on both sides and align them intentionally. To bring the differing side into line, call setConfig using the same recipe as Asymmetric DVN Configuration.
  • If the sides differ on purpose (for example, the sender pays an additional optional DVN that the receiver does not require, in order to publish extra attestations downstream observers can read), document the rationale next to the deployment artifact.
  • Treat any silent drift between sides as a regression — promote a CI check that diffs getUlnConfig(send) against getUlnConfig(receive) for every pathway.
Don’t:
  • Read only the send config and infer the application’s security posture from it — the receive side is the enforcement boundary.
  • Add a new optional DVN on one side without mirroring on the other.
  • Assume “messages are still delivering” means the configuration is correct; non-blocking mismatches deliver until the next default rotation changes the merged set.
The effective security of a non-blocking mismatch is whichever side is stricter, not the union of the two configs. An auditor inspecting only the send config will overcount or undercount the DVNs your messages actually require, depending on which side has the wider set.
How to check
# Merged config (defaults filled in) is what messages actually enforce.
echo "Send-side (A→B) merged:"
cast call "$SEND_LIB_A" \
  "getUlnConfig(address,uint32)((uint64,uint8,uint8,uint8,address[],address[]))" \
  "$OAPP_A" "$EID_B" --rpc-url "$RPC_A"

echo "Receive-side (B from A) merged:"
cast call "$RECV_LIB_B" \
  "getUlnConfig(address,uint32)((uint64,uint8,uint8,uint8,address[],address[]))" \
  "$OAPP_B" "$EID_A" --rpc-url "$RPC_B"

# Compare requiredDVNs / optionalDVNs / optionalDVNThreshold by hand.
# If sets differ but the sender still satisfies the receiver's required-subset
# and threshold, this is non-blocking — messages flow, but observed posture
# differs from enforced posture. Align both sides intentionally.

Asymmetric DVN Configuration

Pin DVNs explicitly on both sides of every pathway. If one side calls setConfig with explicit requiredDVNs and the mirror leaves the value implicit (the OApp has never called setConfig for that field), the implicit side inherits the chain’s default DVN set — and LayerZero Labs can change that default at any time without notice. A pathway that is symmetric today can become asymmetric overnight when the default rotates. The same drift applies to optionalDVNs and optionalDVNThreshold: an implicit threshold of 0 follows the default, not whatever the mirror has pinned. Do:
  • Call EndpointV2.setConfig(oapp, sendLib, [...]) on the send side and EndpointV2.setConfig(oapp, recvLib, [...]) on the receive side with matching UlnConfig values for every pathway.
  • Pin requiredDVNs, optionalDVNs, and optionalDVNThreshold on both sides — even if the explicit value happens to match today’s default.
  • After every LayerZero default migration, re-run the validation snippet below for every pathway you operate; one side flipping from implicit to a new default is exactly the asymmetry this finding catches.
Don’t:
  • Rely on getUlnConfig (the merged view) for parity checks — it hides asymmetry by filling in defaults on both sides. Use getAppUlnConfig to see RAW values.
  • Treat an empty requiredDVNs: [] and requiredDVNCount: 0 as “no DVNs” — it means “use the default.”
Defaults are mutable. LayerZero Labs can change the default DVN set for any EID at any time. An OApp on the default for one direction and explicit for the other will silently shift to a new posture when the default updates; messages already in flight may stop verifying until the asymmetric side is brought into alignment.
How to check
# `getAppUlnConfig` returns RAW values (zeros where the OApp hasn't set anything).
# `getUlnConfig` returns the MERGED values (defaults filled in).
# Asymmetry = one side has zeros, the other side has non-zeros, for the same field.

# Send side (what chain A's OApp pays for)
cast call "$SEND_LIB_A" \
  "getAppUlnConfig(address,uint32)((uint64,uint8,uint8,uint8,address[],address[]))" \
  "$OAPP_A" "$EID_B" --rpc-url "$RPC_A"

# Receive side (what chain B's OApp requires)
cast call "$RECV_LIB_B" \
  "getAppUlnConfig(address,uint32)((uint64,uint8,uint8,uint8,address[],address[]))" \
  "$OAPP_B" "$EID_A" --rpc-url "$RPC_B"

# Interpret: if either side returns
# `(0, 0, 0, 0, [], [])` while the mirror returns non-zero, the configuration is asymmetric.
# Resolve by calling setConfig on the side with zeros to pin the same DVNs as the mirror.

Dead DVN

This configuration includes a Dead DVN:
SendUlnConfig (A to B)ReceiveUlnConfig (B to A)
confirmations: 15confirmations: 15
optionalDVNCount: 0optionalDVNCount: 0
optionalDVNThreshold: 0optionalDVNThreshold: 0
optionalDVNs: Array(0)optionalDVNs: Array(0)
requiredDVNCount: 2requiredDVNCount: 2
requiredDVNs: Array(DVN1, DVN2)requiredDVNs: Array(DVN1, DVN_DEAD)
The above configuration has a Dead DVN. Similar to a DVN Mismatch, the sending OApp (Chain A) pays DVN 1 and DVN 2 to listen and verify the packet, but the receiving OApp (Chain B) has currently set DVN 1 and a Dead DVN to mark the packet as verified.Since a Dead DVN for all practical purposes should be considered a null address, no verification will ever match the dead address.Messages will be blocked until the receiving OApp removes or replaces the Dead DVN from the ReceiveUlnConfig.

Summary

  • Retrieve defaults: Use getConfig if you need to review existing settings.
  • Set Libraries: Choose your Message Library version by calling setSendLibrary and setReceiveLibrary.
  • Set Configurations: Update your DVN (ULN) and Executor settings with setConfig.
  • Ensure matching configurations: The Send settings on one chain must match the Receive settings on the other chain.