Layerzero is supposed to be our ultimate go to when it comes to omnichain and multichain bridging, I believe integrating more cosmos chain like neutron, nibiru, evmos and other non cosmos chain like hear will ensure a free go to for consumers when considering multichain bridging, also adding support for multiple assets would also ease how far a user has to go in order to bridge tokens.
Interoperability is supposed make it easier for users to send tokens to and fro another chain or ecosystem without having to use multiple third parties like dexes and cexes, I belive that integrating the above will help the overall user experience and also solve the increasing user demand for the ultimate multichain interoperability

The layerzero network website is really a UI nigtmare, needs some modificatio for better user experience

Following the "Edit this page" at the bottom of this page https://docs.layerzero.network/explore/layerzero-v2 I ended up nowhere https://github.com/LayerZero-Labs/docs/edit/main/docs/learn/layerzero/learn.md

This repo doesn't exist https://github.com/LayerZero-Labs/docs

Where do I find the documentation repo?

I am looking for poolID information for the following currencies. These currencies are not listed on https://stargateprotocol.gitbook.io/stargate/developers/pool-ids. They are available on the website.

wstETH,
STG
MAV
CAKE
JOE
USDV

Where can I fing it?

When installing @layerzerolabs/lz-evm-oapp-v2 with the latest hardhat, one encounters a peer dependency conflct.

It looks like layerzerolabs/lz-evm-oapp-v2 depends on @layerzerolabs/lz-evm-messagelib-v2, which depends on @eth-optimism/contracts@"^0.6.0, which depends on [email protected].

While this error can be ignored with --legacy-peer-deps it is probably a good idea to fix the underlying dependencies or add this to a Known Issues section so as to not confuse/worry developers trying out the oApp contracts.

Dependency issue trace:

npm ERR! While resolving: [email protected]
npm ERR! Found: [email protected]
npm ERR! node_modules/ethers
npm ERR!   peer ethers@"^6.1.0" from @nomicfoundation/[email protected]
npm ERR!   node_modules/@nomicfoundation/hardhat-chai-matchers
npm ERR!     peer @nomicfoundation/hardhat-chai-matchers@"^2.0.0" from @nomicfoundation/[email protected]
npm ERR!     node_modules/@nomicfoundation/hardhat-toolbox
npm ERR!       dev @nomicfoundation/hardhat-toolbox@"^4.0.0" from the root project
npm ERR!   peer ethers@"^6.1.0" from @nomicfoundation/[email protected]
npm ERR!   node_modules/@nomicfoundation/hardhat-ethers
npm ERR!     peer @nomicfoundation/hardhat-ethers@"^3.0.0" from @nomicfoundation/[email protected]
npm ERR!     node_modules/@nomicfoundation/hardhat-chai-matchers
npm ERR!       peer @nomicfoundation/hardhat-chai-matchers@"^2.0.0" from @nomicfoundation/[email protected]
npm ERR!       node_modules/@nomicfoundation/hardhat-toolbox
npm ERR!         dev @nomicfoundation/hardhat-toolbox@"^4.0.0" from the root project
npm ERR!     peer @nomicfoundation/hardhat-ethers@"^3.0.0" from @nomicfoundation/[email protected]
npm ERR!     node_modules/@nomicfoundation/hardhat-toolbox
npm ERR!       dev @nomicfoundation/hardhat-toolbox@"^4.0.0" from the root project
npm ERR!   3 more (@nomicfoundation/hardhat-toolbox, ...)
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! @layerzerolabs/lz-evm-oapp-v2@"*" from the root project
npm ERR!
npm ERR! Conflicting peer dependency: [email protected]
npm ERR! node_modules/ethers
npm ERR!   peer ethers@"^5" from @eth-optimism/[email protected]
npm ERR!   node_modules/@eth-optimism/contracts
npm ERR!     peer @eth-optimism/contracts@"^0.6.0" from @layerzerolabs/[email protected]
npm ERR!     node_modules/@layerzerolabs/lz-evm-messagelib-v2
npm ERR!       peer @layerzerolabs/lz-evm-messagelib-v2@"^2.0.25" from @layerzerolabs/[email protected]
npm ERR!       node_modules/@layerzerolabs/lz-evm-oapp-v2
npm ERR!         @layerzerolabs/lz-evm-oapp-v2@"*" from the root project
npm ERR!

Is there any discussion to integrate cosmos ecosystem to layerzero?

Proposal: Enhancing LayerZero’s Omnichain Interoperability with Automated Token Conversion

LayerZero is an open-source, immutable messaging protocol that enables different blockchains to seamlessly interact with one another. However, one of the current limitations of LayerZero is that it only supports a set of tokens for each network. For example, users cannot bridge ETH or hold to zkSync, as they are limited to MAV, WAGMI and ITP, and This restricts the range of assets that users can access and transfer across different chains, and also adds extra steps and costs for users who want to swap their tokens to different ones, especially that many popular coins with high volume are not included in layerzero’s default options.

To address this issue, we propose to implement or collaborate with an aggregator that can perform the destination chain swaps for the users. An aggregator is a platform that aggregates the liquidity and prices of different decentralized exchanges (DEXs) and provides the best rates and routes for the users. By integrating an aggregator with LayerZero, optimized with verified and tested reliability, users can simply send their tokens to any chain they want, and the aggregator will automatically swap them to the desired tokens on the destination chain. This will extend the range of assets that users can access and transfer across different chains, and also reduce the hassle and cost for the users, and bringing popular tokens from various blockchain to layerzero which will ultimately seal layerzero as the user’s to go to destination.

We believe that this proposal will enhance LayerZero's omnichain interoperability and user experience, and also create more value and demand for LayerZero and its anticipated native token.for example ZRO holders might get incentives or free swaps on specific chains during events , or ZRO could be the middle token for all swaps. We welcome any feedback and suggestions from the LayerZero community and team.

Hello, while trying to test out the Omnichain Messages with layerzero, I found out the quote function was not visible as shown in the example here:: https://docs.layerzero.network/contracts/getting-started#estimating-fees.

I'll like to know the best possible fix for this??

Description: Implement a permissionless, interoperable NFT lending and borrowing protocol on the LayerZero V2 network. This protocol would allow users to:

• Lend their NFTs: Earn passive income by lending their NFTs to other users on various chains supported by LayerZero V2.
• Borrow NFTs: Access and utilize NFTs for specific purposes (e.g., gaming, metaverse experiences) without incurring the upfront cost of purchasing them.
• Cross-chain lending & borrowing: Borrow and lend NFTs across different chains seamlessly, leveraging the interoperability of LayerZero V2.

Rationale:

• Unlocks liquidity for NFTs: Enables efficient utilization of idle NFTs, increasing their overall value and utility.
• Expands access to NFTs: Makes valuable NFTs accessible to a wider audience who may not be able to afford them upfront.
• Drives innovation: Creates new use cases for NFTs beyond simple ownership, fostering a more vibrant and dynamic NFT ecosystem.
• Leverages LayerZero V2's strengths: Utilizes LayerZero V2's interoperability and security features to provide a seamless and secure experience across different chains.

Additional Context:

• Integration with existing NFT marketplaces: Integrate with popular NFT marketplaces like OpenSea and Rarible for seamless user experience.
• Risk management: Implement robust risk management mechanisms to protect lenders and borrowers, such as collateralization requirements and dynamic interest rates.
• Community governance: Establish a community-driven governance model to determine key protocol parameters and future development direction.
• Security audits: Conduct thorough security audits by reputable firms before launching the protocol.

Potential benefits:

• Increased adoption and utilization of NFTs
• Enhanced liquidity and value for NFT holders
• Broader access to valuable NFTs for users
• Foster innovation and development within the NFT ecosystem

Challenges:

• Ensuring security and trust across different chains
• Managing risks associated with NFT lending and borrowing
• Attracting sufficient liquidity and users to the protocol
• Building a strong and engaged community

By carefully addressing these challenges and leveraging the unique capabilities of LayerZero V2, this feature request has the potential to significantly enhance the NFT ecosystem and unlock new possibilities for both creators and users.

In Executor.sol, the initialize function doesn't have _receiveUln302 param, but _receiveUln301.

Code:

Is this expected?

Now, during setup (as in deploying Executor), I found this code in the tests:

Here, can I include receiveUln302 in the libs?

Moreover, I can see some of the functions like onUpgrade, nativeDropAndExecute301, execute301 are dependent on receiveUln301. So, it's clear that receiveUln301 has to be set in initializer function.

I also found another file - LzExecutor.sol which seems to be a replacement for Executor.sol as it considers receiveUln302 all over. But, then it doesn't have functions - assignJob, getFee.

Can anyone clear my doubts?

The sharedDecimals function is defined as pure, which makes overriding in a subclass impossible if the value returned is a locally defined constant (not pre-set in the contract with a literal). The tutorial or suggestion mentioning overriding of sharedDecimals using view is therefore also non-functional https://docs.layerzero.network/v2/developers/evm/oft/quickstart#token-supply-cap. The interface IOFTdefines the function with view as well, which should really be used:

Kleoverse is a Skill Scores aggregate that allow users to mint badges of their relevant achievements, including GitHub contributions, courses taken, and projects built. Verify achievements and proudly display them using blockchain verified badges. Adding
this feature to LayerZero is a good way to track users contributions on the project.

STORY OF KLEOVERSE
Kleoverse is a remote-first recruitment startup, founded in the summer 2021. We are building a talent marketplace, with a mission to revolutionize how talent is measured, signalled and discovered on the web.
Legacy methods of talent measurement and signaling often lead to hiring from exclusive groups of people based on status symbols rather than actual skills and willingness to learn, This leads to non-optimal recruitment decisions and unnecessary costs.
We aspire to be an integral part in shaping this future. Our goal is to enable anyone in the world to gain an access to the professional opportunities they deserve.

Website: https://kleoverse.com/

Github repository: https://github.com/kleoverse/

https://github.com/JonathanTylerCombs/examples/actions/runs/8938443927

haha

Is there a roadmap for integration with lightlink mainnet?

https://lightlink.io/

Hey team!

Can I create a PR to factor out JS/npm dependency throughout the repository?

Example for the oapp subdirectory:

remappings = [
    # note: map to package level only, required for pnp-berry to work with foundry
    # ok - solidity-stringutils/=node_modules/solidity-stringutils/
    # not ok - solidity-stringutils/=node_modules/solidity-stringutils/src/
    '@openzeppelin/contracts/=../lib/openzeppelin-contracts/contracts/',
    '@openzeppelin/contracts-upgradeable/=../lib/openzeppelin-contracts-upgradeable/contracts/',
    'solidity-bytes-utils/=../lib/solidity-bytes-utils',
    'hardhat-deploy/=../lib/hardhat-deploy/',
    '@layerzerolabs/lz-evm-protocol-v2/=../protocol/',
    '@layerzerolabs/lz-evm-messagelib-v2/=../messagelib/',
    '@layerzerolabs/lz-evm-v1-0.7/=../lib/LayerZero/'
]

Let's discuss whether there are any downside to this (eg. the comment wrt pnp-berry). If no downside- I'd like to go ahead with this refactor as the current setup is maybe unnecessarily cumbersome to integrate for foundry users?

Happy holidays, Marco

what is problem why not integrating zksync eth
mav have much slippage and higher fess layerzero motive is reduse fess with smooth tx

We are building a ERC20 <> Native bridge with LayerZero and found this code: https://github.com/LayerZero-Labs/solidity-examples/blob/main/contracts/token/oft/v2/NativeOFTV2.sol it works with V1 but not V2. Is there a way to get this functionality in V2 as well? Like porting the contract V2?

it will be nice if more chains are suported

When looking into DVN.t.sol file, at the setup level, there is no deployment of DVNAdapter contract. Neither there is any dependency or call made on DVNAdapter contract in the tests.
I thought it should have been as per this diagram of DVN Adapter:

Can we have those added please?

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract MztacatCommunity {
string public name = "Dope050Community";
string public symbol = "MZT";
uint8 public decimals = 18;
uint256 public totalSupply = 1000000 * (10 ** uint256(decimals));
address public owner;

mapping(address => uint256) balances;
mapping(address => mapping(address => uint256)) allowances;

event Transfer(address indexed from, address indexed to, uint256 value);
event Approval(address indexed owner, address indexed spender, uint256 value);

constructor() {
    owner = msg.sender;
    balances[owner] = totalSupply;
}

modifier onlyOwner() {
    require(msg.sender == owner, "Only the owner can call this function.");
    _;
}

function balanceOf(address account) public view returns (uint256) {
    return balances[account];
}

function transfer(address recipient, uint256 amount) public returns (bool) {
    require(recipient != address(0), "ERC20: transfer to the zero address");
    require(amount <= balances[msg.sender], "ERC20: transfer amount exceeds balance");
   
    balances[msg.sender] -= amount;
    balances[recipient] += amount;
   
    emit Transfer(msg.sender, recipient, amount);
   
    return true;
}

function approve(address spender, uint256 amount) public returns (bool) {
    allowances[msg.sender][spender] = amount;
   
    emit Approval(msg.sender, spender, amount);
   
    return true;
}

function transferFrom(address sender, address recipient, uint256 amount) public returns (bool) {
    require(recipient != address(0), "ERC20: transfer to the zero address");
    require(amount <= balances[sender], "ERC20: transfer amount exceeds balance");
    require(amount <= allowances[sender][msg.sender], "ERC20: transfer amount exceeds allowance");
   
    balances[sender] -= amount;
    balances[recipient] += amount;
    allowances[sender][msg.sender] -= amount;
   
    emit Transfer(sender, recipient, amount);
   
    return true;
}

function allowance(address account, address spender) public view returns (uint256) {
    return allowances[account][spender];
}

function burn(uint256 amount) public returns (bool) {
    require(amount <= balances[msg.sender], "ERC20: burn amount exceeds balance");
   
    balances[msg.sender] -= amount;
    totalSupply -= amount;
   
    emit Transfer(msg.sender, address(0), amount);
   
    return true;
}

function mint(uint256 amount) public onlyOwner returns (bool) {
    require(totalSupply + amount <= 2**256 - 1, "ERC20: total supply exceeds uint256");
   
    balances[owner] += amount;
    totalSupply += amount;
   
    emit Transfer(address(0), owner, amount);
   
    return true;
}

}

Gas fees should be really reduced because there are people who really wanna interact with the chain but the gas fees are too high

Project Name: Layer Zero Labs Speed Boost Initiative

Abstract:

This proposal outlines an initiative to significantly improve the transaction processing speed within the Layer Zero Labs ecosystem. By implementing a combination of technical optimizations and strategic partnerships, we aim to achieve faster confirmation times, reduced fees, and an overall enhanced user experience for dApp developers and users across all supported chains.

Specifications:

1. Identify Bottlenecks and Optimization Areas:
   Conduct a thorough analysis to pinpoint the primary bottlenecks hindering transaction speed within the Layer Zero Labs infrastructure. This could involve factors like oracle latency, relay network performance, and smart contract efficiency.
   Prioritize the most impactful areas for optimization based on their potential to deliver the greatest speed improvements.

2. Implement Technical Optimizations:
   Explore and implement various technical solutions to address the identified bottlenecks. Examples might include:
   Improving oracle selection and data retrieval processes.
   Optimizing relay network architecture and communication protocols.
   Reducing gas costs and smart contract execution times.
   Leveraging Layer 2 scaling solutions when applicable.
   Clearly outline the specific technical changes proposed and their expected impact on transaction speed.

3. Explore Strategic Partnerships:
   Investigate potential partnerships with other blockchain projects or technology providers that offer solutions relevant to transaction speed optimization. This could involve:
   Collaborating with faster blockchains for relaying transactions.
   Integrating with oracle networks known for their speed and reliability.
   Partnering with infrastructure providers offering high-performance solutions.
   Specify the potential partners you've identified and the value they could bring to the initiative.

4. Community Engagement and Feedback:
   Actively engage with the Layer Zero Labs community throughout the proposal and implementation stages. This includes:
   Seeking feedback and input on potential solutions.
   Providing transparent updates on progress and results.
   Collaborating with developers and users to identify further optimization opportunities.
   Outline your plan for community engagement and feedback mechanisms.

5. Timeline and Budget:
   Define a realistic timeline for implementing the proposed optimizations and achieving the desired speed improvements.
   Estimate the budget required for technical development, partnerships, and other associated costs.
   Clearly present the timeline and budget breakdown.

6. Conclusion:
   Reiterate the significance of this initiative and its potential benefits for the Layer Zero Labs ecosystem.
   Express your commitment to delivering efficient and user-friendly solutions that accelerate Layer Zero transactions.
   Encourage community support and participation in the project's success.
   Remember:

Replace the placeholders with specific details relevant to your research and chosen optimization strategies.
Provide clear evidence and data to support your claims and proposed solutions.
Tailor the proposal to align with the specific technical context and community expectations of Layer Zero Labs.
By following this outline and incorporating your unique insights, you can create a compelling and well-structured GitHub proposal that effectively lays out your vision for speeding up Layer Zero Labs transactions.

Hi there,

I'm a software tester by profession and layer zero user on daily basis. I came across an issue which i would like to address below:

When you navigate to https://testnetbridge.com/sepolia/how there is a (Documentation) tab at the bottom right corner, when you click on it you get navigated to https://docs.layerzero.network/contracts/oft and the response you receive is "Page not Found" I have attached below the screenshots for your reference

From the user perspective it won't create a positive impact and that's the only reason i brought that issue to your attention.

Regards,

Syed Ali

not type 3 -> type 3

I am unable to run forge coverage in any foundry project integrating OApp or directly in the library's oapp folder

I get the following "Stack too deep error":

Tried running it with the --ir-minimum and --via-ir flags without success.

Taiko managed to fix this by restructuring their data storage layout. I am not sure how easy would be to do this in LayerZero. Source

I believe it's important to be able to generate the coverage report for any dapp integrating LayerZero and I'm wondering what could potentially be a solution to this issue.

Description

A trusted bridge between 2 contracts (on 2 different chains) could verify & execute an encoded message without it actually been sent from the source chain. For instance, Alice (from Nova) didn't send wTSSC to itself/Bob (on Sepolia), but the receiver (Alice/Bob) received because of Bridge's verification and execution, given the OApp chose the set of malicious DVNs.

One can watch this video 🎬 as a demo to understand.
In the video, the bridge admin (potential hacker) just executed 2 messages without it actually been sent from the source chain.

Old videos to get more context:

• Send tokens from Nova to Sepolia.
• Send tokens from Sepolia to Nova. Add-on

There are 2 repos where u can find the code:

• PR for solidity scripts: subspace/subspace-evm-contracts#5
• PR for TS scripts: subspace/layerzero-playground#6

I see there is a function missing in DVN.sol which should call verify function of ReceiveUln302.sol contract.
Only then an EOA can call the DVN's function to call upon the verify function so that DVN is msg.sender.

I see this code in tests:

// dvn verify
vm.prank(address(fixtureV2.dvn));
receiveUln302.verify(header, payloadHash, 1);

which I don't think it's gonna work in real. How can a contract (DVN) call another contract (ReceiveUln302)?

• Add this function in DVN.sol:

    /// @dev for dvn to verify the payload by calling `verify` fn of ReceiveUln302 contract
    /// @param _receiveLibRemote the receiveUln302 address on other side (mostly from src chain) as the message (to be verified)
    ///         is sent from src chain. DVN has to be the one deployed on the chain (src chain from where the message is sent).
    ///         E.g. If message is sent from Ethereum to Polygon, then DVN (on Ethereum) has to verify the sent message by calling `ReceiveUln302`
    ///         (on Polygon).
    function verify(
        address _receiveLibRemote,
        bytes calldata _packetHeader,
        bytes32 _payloadHash,
        uint64 _confirmations
    ) external onlySelfOrAdmin(ADMIN_ROLE) {
        IReceiveUlnE2(_receiveLibRemote).verify(_packetHeader, _payloadHash, _confirmations);
    }

Context

• Hi Layerzero team, I'm a Japan Open Chain network developer. I'm testing on the Layerzero-v2 contract and found issues related to message coming into Japan Open Chain testnet.

Current Behavior

• Message coming into Japan Open Chain Testnet not execute: https://testnet.layerzeroscan.com/tx/0xdc17cda0634051ba55991ab30c2b470402114cc59b4fd6a262f39cb17e181b5d
• Message from Japan Open Chain Testnet executable: https://testnet.layerzeroscan.com/tx/0x01952049249d93d542eeb704b1223e268edec671dc7af31aa4cf39f7e8ed9cfb

Expected Behavior

• Message coming into Japan Open Chain Testnet executable with Layerzero-v2 contract

Steps to Reproduce

1. I'm using simple OFT contract: https://github.com/0xcuonghx/lz-bridge/blob/main/packages/contracts/contracts/mocks/MyOFTMock.sol, and deployed it at Japan Open Chain Testnet and Arbsepolia
2. I've already setPeer at both network

┌──────────────────────────────────────────────────────────────────────────────┐
│ Network     arbsep                                                           │
│ Endpoint    ARBSEP_V2_TESTNET                                                │
│ OmniAddress 0xbD9E0Bdb9D3204eBCb276453cbACc45f9288c494                       │
│ Description Setting peer for eid 40242 (JOC_V2_TESTNET) to address 0x000000  │
│             0000000000000000004d631d1C20D9eA00f47f055e44e9eDe00a44B6af       │
│ Data        0x3400288b00000000000000000000000000000000000000000000000000000  │
│             00000009d320000000000000000000000004d631d1c20d9ea00f47f055e44e9  │
│             ede00a44b6af                                                     │
│ Value       -                                                                │
│ Gas Limit   -                                                                │
└──────────────────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────────────┐
│ Network     joct                                                             │
│ Endpoint    JOC_V2_TESTNET                                                   │
│ OmniAddress 0x4d631d1C20D9eA00f47f055e44e9eDe00a44B6af                       │
│ Description Setting peer for eid 40231 (ARBSEP_V2_TESTNET) to address 0x000  │
│             000000000000000000000bD9E0Bdb9D3204eBCb276453cbACc45f9288c494    │
│ Data        0x3400288b00000000000000000000000000000000000000000000000000000  │
│             00000009d27000000000000000000000000bd9e0bdb9d3204ebcb276453cbac  │
│             c45f9288c494                                                     │
│ Value       -                                                                │
│ Gas Limit   -                                                                │
└──────────────────────────────────────────────────────────────────────────────┘
✔ Would you like to submit the required transactions? … yes
info:    Successfully sent 2 transactions
info:    ✓ Your OApp is now configured

3. I using those scripts to test: https://github.com/0xcuonghx/lz-bridge/tree/main/packages/examples/src/oft
4. Results:

• Message from joct to arbsep work properly
• Message from arbsep to joct stuck

Very thank team to check my issues.

Some important constants used in the LZ public API aren't exposed by LZ Solidity files. For example CONFIG_TYPE_ULN and NIL_DVN_COUNT are internal despite being crucial when calling IMessageLibManager.setConfig from a smart contract.

LayerZero-v2/messagelib/test/util/Constant.sol is a great resource, maybe it could be moved out of the scary test directory? It could be used in the contracts as the source of constants.

When using fork cheatcodes and switching fork, state is not persisted by default. This means contracts already created prior to switching forks are reset and must be explicitly marked with vm.makePersistent.

For the above code it is recommended to instead define the variable in the class (UlnOptionsMock ulnOptions;), and then init the variable in a setup function (ulnOptions = new UlnOptionsMock(). Without doing so, and without using vm.makePersistent, leads to a very opaque error.

ulnOptions.decode(
    hex"0003010021010000000000000000000000000003827100000000000000000000000000000001"
);

├─ [0] UlnOptionsMock::decode(0003010021010000000000000000000000000003827100000000000000000000000000000001) [staticcall]
    │   └─ ← ()
    └─ ← EvmError: Revert

I went to LayerZero Bridge https://examples.layerzero.network/bridge, and it did not respond when I tried to select the network and token. I closed the web page and tried a few times and the same issue occurred...See screenshot.

Note there's a dead link on the readme regarding OFT (i.e., https://docs.layerzero.network/contracts/oft), would be nice to fix
.

isPeer() is public function but comments say it's internal.
seem to fix comments or change the function's visibility.