LayerZero V2 Integration: OApp, OFT, and Security

Integration of LayerZero V2

Note: when a user transfers tokens through a classic bridge, they entrust their funds to a custodian. The Ronin bridge hack for $600M showed that this approach is dangerous. LayerZero V2 solves this problem fundamentally differently: the token is burned on the source and minted on the destination — no locked liquidity. This makes OFT 100 times safer than traditional bridges since there is no single point of failure. We integrate LayerZero V2 into DeFi projects — from simple OFT to complex cross-chain DAOs. Stack: Solidity 0.8.x, Foundry, Hardhat. We work with Ethereum, Arbitrum, Polygon, BNB Chain, and Base. We have 30+ projects and $10M+ in managed liquidity.

According to LayerZero V2 Documentation, the protocol provides omnichain messaging with verification via DVN. DVN configuration is set via setConfig, allowing security to be tailored to the specific project.

How does LayerZero V2 work?

V2 simplified the architecture compared to V1. Endpoint is a singleton contract in each network. Address: 0x1a44076050125825900e736c501f859c50fE728c in all supported networks. DVN are verifiers that confirm delivery. The developer chooses the configuration: number of required/optional DVN. Example providers: Google Cloud, Polyhedra, Axelar. Minimum secure configuration: 2 independent DVN in required. Executor is an agent that calls lzReceive on the destination after DVN confirmation. You can use the standard LayerZero executor or your own.

Why is OFT safer than a classic bridge?

In a classic bridge, you lock the token and rely on the custodian not to steal it. In OFT, the token exists natively in each network: on transfer, it is burned on the source and minted on the destination. No locked liquidity. A bridge hack like Ronin ($600M) is impossible — there is no single point of failure. The only risk is incorrect setPeer configuration. Compare:

OApp: Basic Integration Pattern

OApp is the base contract for any integration. Example implementation:

import { OApp, Origin, MessagingFee } from "@layerzerolabs/oapp-evm/contracts/oapp/OApp.sol";

contract CrossChainMessenger is OApp {
    event MessageReceived(uint32 srcEid, bytes32 sender, string message);

    constructor(address _endpoint, address _owner)
        OApp(_endpoint, _owner) {}

    function sendMessage(
        uint32 dstEid,
        string calldata message,
        bytes calldata options
    ) external payable {
        bytes memory payload = abi.encode(message);
        MessagingFee memory fee = _quote(dstEid, payload, options, false);
        require(msg.value >= fee.nativeFee, "Insufficient fee");
        _lzSend(dstEid, payload, options, fee, payable(msg.sender));
    }

    function _lzReceive(
        Origin calldata origin,
        bytes32,
        bytes calldata payload,
        address,
        bytes calldata
    ) internal override {
        string memory message = abi.decode(payload, (string));
        emit MessageReceived(origin.srcEid, origin.sender, message);
    }

    function quoteSend(
        uint32 dstEid,
        string calldata message,
        bytes calldata options
    ) external view returns (MessagingFee memory) {
        return _quote(dstEid, abi.encode(message), options, false);
    }
}

options encode gas limit for lzReceive, airdrop ETH, ordered delivery. Use OptionsBuilder. Insufficient gas causes revert on destination. Excessive gas leads to overpayment. Profiling through tests is necessary.

OFT: Omnichain Fungible Token

OFT is the main use case. The token exists natively in each network. The contract is minimal:

import { OFT } from "@layerzerolabs/oft-evm/contracts/OFT.sol";

contract MyOFT is OFT {
    constructor(string memory _name, string memory _symbol, address _lzEndpoint, address _owner)
        OFT(_name, _symbol, _lzEndpoint, _owner) {}
}

Deploy in each network and link via setPeer. This operation is critical for security — if the wrong address is specified, messages will go nowhere.

OFTAdapter for Existing Tokens

If the token already lives on one network, use OFTAdapter:

import { OFTAdapter } from "@layerzerolabs/oft-evm/contracts/OFTAdapter.sol";

contract MyTokenAdapter is OFTAdapter {
    constructor(address _token, address _lzEndpoint, address _owner)
        OFTAdapter(_token, _lzEndpoint, _owner) {}
}

On the home chain, deploy an Adapter (custodian); on the others, a regular OFT.

How to Configure DVN?

DVN configuration is a key security step. Follow these steps:

1. Select at least 2 independent DVN providers (e.g., LayerZero Labs and Google Cloud).
2. Determine required/optional configuration. We recommend 2 required, 0 optional.
3. Use ILayerZeroEndpointV2.setConfig to apply settings.

Example configuration:

const configParams = [{
  eid: dstEid,
  configType: CONFIG_TYPE_ULN,
  config: ethers.AbiCoder.defaultAbiCoder().encode(
    ['tuple(uint64,uint8,uint8,uint8,address[],address[])'],
    [[0, 2, 1, 0, [dvn1, dvn2], [dvn3]]]
  )
}];
await endpoint.setConfig(oappAddress, sendLibAddress, configParams);

This configuration ensures that for message delivery, confirmation from two of the three specified DVNs is required. 10 times more reliable than using a single verifier.

Step-by-Step Integration Guide for LayerZero V2

1. Choose the integration type (OApp, OFT, or OFTAdapter).
2. Develop a smart contract using @layerzerolabs/oapp-evm.
3. Deploy the contract in target networks (minimum 2).
4. Configure setPeer to link contracts between networks.
5. Configure DVN via setConfig (minimum 2 required).
6. Test on testnets (Sepolia, Mumbai).
7. Launch on mainnet and set up monitoring via lzScan.

Testing and DevTools

For local testing, use TestHelper from @layerzerolabs/test-devtools-evm-foundry:

contract OFTTest is TestHelper {
    function setUp() public virtual override {
        super.setUp();
        setUpEndpoints(2, LibraryType.UltraLightNode);
    }
}

lzScan is the official explorer for debugging. For production errors, it's the first tool.

Common Errors

• Insufficient gas on destination – solutions: increase gas in OptionsBuilder, pre-measure via tests.
• Unordered delivery – if order matters, use ordered delivery (30% more expensive).
• Fee estimation – call _quote immediately before the transaction: fee depends on destination gas price and changes quickly.

What's Included in the Integration

• Cross-chain interaction architecture
• Smart contract development (OApp/OFT/OFTAdapter)
• Deployment in 2–5 networks (Ethereum, Arbitrum, Polygon, BNB Chain, Base)
• DVN and Executor configuration
• Testing on testnets (Sepolia, Mumbai)
• Monitoring via lzScan
• Documentation and team training

Basic OFT integration (existing token + cross-chain transfer) takes 2–3 weeks. Custom application with multiple networks and UI takes 6–8 weeks. For OFT with significant liquidity, we recommend auditing contracts and setPeer configuration.

We guarantee security and reliability of integration. We will assess your project — get a consultation. Contact us to discuss your project and receive an estimate of timelines and cost. Order LayerZero integration today.

Cross-Chain Bridge Development: Architecture, Risks, and Implementation

We develop cross-chain bridges and cross-chain solutions end-to-end. We know how to avoid disasters. A few years ago, the Binance BNB Chain bridge lost $570M — the attacker forged a Merkle proof in BSC's native bridge. That same year, Wormhole lost $320M: guardian signature verification was bypassed through a bug in Solana's secp256k1 program. Ronin Bridge — $625M. These are not coincidences. Bridges are the most attacked infrastructure in Web3 because they aggregate liquidity and have complex cross-chain verification logic.

Why Do Bridges Break? Three Architectural Classes of Vulnerabilities

Finality and Reorg Issues. Ethereum has probabilistic finality before The Merge and economic finality after (2 epochs, ~12 minutes). Bitcoin — ~6 blocks (~60 minutes). Solana — ~400ms. If a bridge mints wrapped tokens on the destination chain immediately after 1-2 blocks on the source — a reorg of 3+ blocks allows the attacker to obtain tokens on the destination while the source transaction is reverted. Correct protection: wait for finality confirmation specific to each chain. For Ethereum — 64+ blocks (2 epochs). Not one block.

Signature Verification. Most bridges use a multisig committee or threshold signature: N out of M validators must sign the event from the source chain. Wormhole used 13 out of 19 guardians. The attack was not on the keys themselves — the attacker found a vulnerability in the signature verification code on Solana, where an outdated sysvar account was accepted as valid without verification. On-chain signature verification is harder than it seems.

Lock-and-Mint vs Burn-and-Mint. In the lock-and-mint model, original tokens are locked in a contract on the source chain, and wrapped tokens are minted on the destination. The source contract is a honeypot: all locked TVL is there. One bug in the unlock logic — and all funds are available to the attacker without needing to do anything on the destination chain. Native burn-and-mint (like Circle CCTP for USDC) is safer: no locked pool.

How to Choose a Messaging Layer for Your Project?

LayerZero — a protocol for arbitrary message passing between chains. Not a bridge itself, but infrastructure for building bridges and omnichain applications.

Architecture: Endpoint contract on each chain, Executor (delivers messages to the destination chain), DVN (Decentralized Verifier Network — verifies the transaction fact on the source chain).

Source chain:
  OApp.send() → Endpoint.send() → [emits packet event]

Destination chain:
  DVN verifies packet hash → Executor calls Endpoint.deliver() → OApp.lzReceive()

In v2, the developer chooses DVNs: official (LayerZero Labs, Google Cloud, Polyhedra), or custom. One can configure required DVN + optional DVN: a message is accepted only if all required DVNs confirm. This allows building bridges with different trade-offs between security and speed.

OApp (Omnichain Application) — the base contract for integration. Inherit OApp, implement _lzSend and _lzReceive. For token bridges — OFT (Omnichain Fungible Token) standard out of the box does burn-on-source / mint-on-destination.

Wormhole uses a network of 19 guardians (large companies like Jump Crypto, Everstake, etc.), each signing observed events. Threshold — 13 out of 19. VAA (Verified Action Approval) — a signed message that is accepted on the destination chain.

Main difference from LayerZero: Wormhole has native support for non-EVM chains: Solana, Aptos, Sui, Algorand, Near. For projects needing a bridge between Ethereum and Solana — Wormhole is often the only production-ready option.

After the exploit, Wormhole added Native Token Transfers (NTT) — an architecture without a locked pool, similar to CCTP. NTT + Hub-and-Spoke model: redundant liquidity is not accumulated on one chain.

Relay Architecture and Light Client Verification

Relay-based bridges (IBC in Cosmos ecosystem, Succinct's Telepathy) verify the source chain's state via a light client on the destination chain. For EVM→EVM: a contract on Ethereum stores and verifies BLS signatures of the source chain's blocks.

ZK-bridges are the next level. Succinct, Polyhedra zkBridge, Electron Labs generate a ZK-proof of the correctness of the source chain's consensus. On the destination chain, the proof is verified, not the validator signatures. Removes trust in the committee. But ZK-proof verification is gas-expensive — from 200k to 500k gas on Ethereum L1 depending on the proof system. A ZK-bridge is safer than a relay-based bridge but requires 2-3 times more gas for verification.

What Does Cross-Chain Bridge Development Include?

We implement the project turnkey and deliver a complete set of results. Our clients receive:

Implementation: What to Consider Before the First Line of Code

Mandatory components for any production bridge:

Pauser. Emergency pause function, called by multisig or automatically upon anomaly detection (suspicious volume, atypical call sequence). Most hacked bridges did not have or did not use a pauser in time.

Rate limiting. Limit output volume per time interval. If an attacker drains the bridge — rate limit gives time to react. Implementation: transferVolume[currentEpoch] += amount; require(transferVolume[currentEpoch] <= epochLimit).

Finality checks. Specific to each chain. Not "wait 1 block", but use finality API or wait for required number of confirmations.

Relayer monitoring. An autonomous service that monitors the state of both bridge sides. If a message is sent but not delivered within N minutes — alert. If locked balance diverges from totalSupply of wrapped token — critical alert.

Timeline and Cost

A simple ERC-20 bridge on top of an existing messaging layer (LayerZero OFT or Wormhole NTT) — 4-8 weeks including testing and audit. A custom bridge with own verification, multi-chain support, rate limiting, monitoring — 12-24 weeks. A ZK-bridge with custom proof circuits — from 6 months.

Bridge audit takes longer than a standard DeFi protocol audit: cross-chain scenarios, finality edge cases, reorg attacks must be tested. Minimum 3-4 weeks for a production-grade solution.

Cost is calculated individually after workload assessment. We have been working since 2018 and have completed 15+ projects in blockchain infrastructure. Contact us — we will evaluate your project and propose the optimal bridge architecture.