layerzero-labs / layerzero Goto Github PK

Hi I'm trying to follow the instructions to import the library "@layerzerolabs/contracts": "latest", in my package.json, but it
says it cannot be found. Here is the error trace when running npm install / yarn:

yarn install v1.22.17
warning package.json: No license field
warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised not to mix package managers in order to avoid resolution inconsistencies caused by unsynchronized lock files. To clear this warning, remove package-lock.json.
warning No license field
[1/4] 🔍  Resolving packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/@layerzerolabs%2fcontracts: Not found".
info If you think this is a bug, please open a bug report with the information provided in "/<redacted>/app/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

None yet

I wonder where is our official developer community?

Dear LayerZero devs,

Could you add a release version? This would allow us eth-brownie afficionados to install this repo easily (no need to fork to fix this).

This would probably also help solving #1

Cheers

i already declare LayerZero-SDK with this "const { LayerZero } require('@layerzerolabs/lz-sdk');"
but when i tried to run the code, i got this problem

EVM & Sol » node main-2.js                                                                                      ~/Desktop/EVM & Sol 1 ↵ 
file:///Users/alkindivv/Desktop/EVM%20&%20Sol/main-2.js:3
const { LayerZero } require('@layerzerolabs/lz-sdk');
      ^^^^^^^^^^^^^

SyntaxError: Missing initializer in destructuring declaration
    at ModuleLoader.moduleStrategy (node:internal/modules/esm/translators:155:18)
    at callTranslator (node:internal/modules/esm/loader:285:14)
    at ModuleLoader.moduleProvider (node:internal/modules/esm/loader:291:30)
    at async link (node:internal/modules/esm/module_job:76:21)

Node.js v20.10.0

you guys do great

Following issue appears at this tree (at commit).

yarn install results in:

error An unexpected error occurred: "https://registry.yarnpkg.com/@layerzerolabs/core-sdk/-/core-sdk-1.0.34-beta.40.tgz: Request failed \"404 Not Found\"".

and npm install results in:

npm ERR! 404 Not Found - GET https://registry.npmjs.org/@layerzerolabs%2fcore-sdk - Not found
npm ERR! 404
npm ERR! 404  '@layerzerolabs/[email protected]' is not in this registry.

Also missing: @layerzerolabs/[email protected]

Description: Integrate native support for atomic swaps with privacy features within the Layerzero network. This would allow users to seamlessly exchange tokens across different chains without revealing their identities or transaction details.

Rationale:

• Enhanced Privacy: Atomic swaps currently lack strong privacy features, exposing users' identities and transaction details on both chains. This feature would address this concern, attracting privacy-conscious users and promoting wider adoption.
• Cross-Chain Interoperability: Layerzero already excels at interoperability, and integrating atomic swaps would further expand its capabilities by enabling trustless token exchange across various blockchains.
• Decentralized Exchange Alternative: This feature would offer a decentralized alternative to centralized exchanges, promoting user autonomy and control over their assets.

Additional Context:

• Privacy Techniques: Consider utilizing zk-SNARKs or ring signatures to obfuscate transaction details and user identities during atomic swaps.
• Supported Chains: Initially focus on popular chains with significant user bases and Layerzero integration, such as Ethereum, Polygon, and Avalanche.
• Security Audits: Conduct thorough security audits of the implemented privacy features to ensure their effectiveness and prevent vulnerabilities.
• Community Engagement: Gather feedback from the Layerzero community to understand their needs and preferences regarding privacy features and supported chains.
• Regulation Compliance: Ensure compliance with relevant regulations and restrictions on cross-chain swaps and privacy features.

Benefits:

• Increased user privacy and security.
• Enhanced interoperability and cross-chain functionality.
• Decentralized alternative for token exchange.
• Potential for wider Layerzero network adoption.

Challenges:

• Implementing robust and secure privacy features.
• Ensuring compatibility with different chains and regulations.
• Integrating the feature seamlessly into the Layerzero network.

Conclusion:

Adding interoperable atomic swaps with privacy features to the Layerzero network could significantly enhance its appeal and utility. By addressing user privacy concerns and offering a decentralized exchange alternative, this feature could attract new users and developers, contributing to the overall growth and success of the Layerzero ecosystem.

I think layerzero should bring out further ways for for transaction to connect to other chains, imo

Hello, LayerZero team.
I need your help with implementing LayerZero protocol on PulseChain testnet, which is a trending one.

I think LayerZero endpoint and library should be deployed on this chain and need your help with this.

[https://gitlab.com/pulsechaincom/pulsechain-testnet]

Thanks
Regards

[ERC20]
https://github.com/LayerZero-Labs/solidity-examples/blob/main/contracts/token/oft/IOFTCore.sol#L20
https://github.com/LayerZero-Labs/solidity-examples/blob/main/contracts/token/oft/IOFTCore.sol#L32

[ERC721]
https://github.com/LayerZero-Labs/solidity-examples/blob/main/contracts/token/onft/IONFT721Core.sol#L19
https://github.com/LayerZero-Labs/solidity-examples/blob/main/contracts/token/onft/IONFT721Core.sol#L27

By determining the interface of these functions, a contract wallet, for example, would be able to say that it supports chain-to-chain transfers if the tokens are compatible with LayeyZero.
Because Axelar has a fixed interface for the function that sends the tokens, it is in a position to easily accommodate large-scale development and inter-chain movement of contract wallets.

Following the news would be great to support Goerli.
We are moving to Goerli testnet and this is a blocking issue.

https://github.com/clearpool-finance/website/issues/542

Hello, I need your help with sending ONFT from Polygon or Mumbai to the other chains.
The LayerZero Protocol says that the Native Fee is insufficient, even though I have enough Matic.

Do you have any solution to this?

I use your system very much. if you examine the tx I sent below, you will see that the layerzero system is at a loss. I suggest you make an edit on this issue.

https://layerzeroscan.com/tx/0xbe0d80e92f7216f36984f4fee3738148843fc5d1d46e090de331087c50c71f7d

have a good day
I paid 0.11 $ on the base side, but the tx fee you pay on the blast side is 0.9 $

I need help
My tokens have been stolen in a fake airdrop using the name @layerzero, the phishing address Wallet is 0x0000553F880fFA3728b290e04E819053A3590000 and the phishing link is https://get-layerzero.com/zro-token/ please do something. How can I recover my money / my tokens? My Wallet ist 0x4420bac9f40fd33083594fd9f7f2fd15537b2ccc

I want to do a layer 3 task, it keeps giving errors on the refrigerator to make USDC liquidity on the optimisim network.

As you can see in this example, the second argument of estimateFees is the address of the chain to which the message is sent.

https://layerzero.gitbook.io/docs/faq/ultra-light-node/economic-and-fees#manage-fees

However, this example shows that the sender's address is set.

https://github.com/LayerZero-Labs/solidity-examples/blob/main/contracts/token/oft/OFT.sol#L21

Which is correct?

and....

If the destination address needs to be specified, shouldn't the type be bytes, not address, as it is in other functions?

https://github.com/LayerZero-Labs/solidity-examples/blob/main/contracts/interfaces/ILayerZeroEndpoint.sol#L41

I think there is a problem with estimateFee function. I tried to send transaction from polygon to arbitrum. At first, the fee was small but as I sent more transactions, the fee grew enormously bigger which made me unable to send transaction.

Hey guys :) I noticed that you currently use a 'lint' name for the script which runs Prettier for code formatting.

I am referencing this part of the code, inside package.json:

While Prettier is excellent for enforcing code formatting rules, it's not designed to catch other types of issues like ESLint does. By using ESLint additionally, you can achieve a more comprehensive approach to code quality and style consistency.

My proposal is to install and configure eslint for this repo and I can assist with setting up the initial configuration if needed.

Thank you for considering this proposal to integrate ESLint into this project. I believe that adopting ESLint will significantly enhance the codebase's quality and maintainability, leading to a more efficient and collaborative development process.

The contract mints the NFTs for free. Is there any way deployer can set a mint fee?

Main links for LayerZero:

LayerZero Website:
https://layerzero.network/

LayerZero Scan:
https://layerzeroscan.com/

LayerZero Introduction:
https://layerzero.gitbook.io/docs/

LayerZero Developer Docs:
https://layerzero.network/developers

LayerZero Medium Articles:
https://medium.com/layerzero-official

LayerZero White Paper:

Omnichain Interoperability Protocol: https://layerzero.network/pdf/LayerZero_Whitepaper_Release.pdf
ColorTrace: https://layerzero.network/publications/ColorTrace.pdf
ColorFloat: https://layerzero.network/publications/ColorFloat.pdf

LayerZero Audit Reports:
https://layerzero.gitbook.io/docs/technical-reference/audit

LayerZero Github Repositories:
https://github.com/LayerZero-Labs

LayerZero Discord:
https://layerzero.network/discord

Unofficial List of Progects Building on LayerZero
https://twitter.com/i/lists/1508156511264071697/members

I've identified a security vulnerability in LayerZero. How can I report this vulnerability safely?

Everything about layerzero is good but bridging through stargate consume high gas..please work on that or use bnb data availability to reduce cost of gas

The Figure 5 in the Whiepaper has a small mistake - at the bottom, there are two times "msg2 Received" in blue, while there should be: "msg1 Received" and "msg2 Received".

In this section: https://github.com/LayerZero-Labs/LayerZero#adding-a-new-network
the following links give 404:

• https://github.com/LayerZero-Labs/LayerZero/blob/main/utils/deploy.js
• https://github.com/LayerZero-Labs/LayerZero/blob/main/constants/endpoints.json

I've noticed that many of the npm packages used in this project have undergone major version updates.

Updating these packages to their latest versions can bring various benefits, such as improved security, bug fixes, and new features. However, updating packages also carries the risk of introducing breaking changes or compatibility issues with existing code. Because of that, advice is to update them incrementally. This approach allows you to identify and resolve any issues introduced by specific package updates before proceeding with others.

I was using this package to check newest versions of the packages: https://www.npmjs.com/package/npm-check-updates

Description:

I've identified a potential improvement in the way cross-chain messages are managed between two chains, referred to as chainA and chainB, and their respective userApplication (ua) contracts, uaA on chainA and uaB on chainB.

Current Behavior:

When uaA sends a cross-chain message to uaB, it retrieves the relayer and oracle configuration for chainB from appConfig[uaA][chainB]. Let's assume the addresses are relayerA and oracleA. The fees for this operation are sent to relayerA and oracleA.
Upon execution of this cross-chain message on chainB, the system looks up appConfig[uaB][chainA] to confirm the configuration of relayerB and oracleB, ensuring the correct entities are relaying the message.
Similarly, when uaB initiates a cross-chain message to uaA:

It checks appConfig[uaB][chainA] for relayerB and oracleB's addresses, directing the fees to these addresses.
Upon execution on chainA, appConfig[uaA][chainB] is consulted to verify relayerA and oracleA's involvement.
Issue:
There seems to be an inconsistency. When uaA sends a message to uaB (chainA to chainB), relayerB and oracleB contribute to relaying and verifying the message, yet the fees are directed to relayerA and oracleA, and vice versa for messages from uaB to uaA.

Suggested Improvement:

To add flexibility and ensure the correct entities receive the fees for their services, I propose adding an extra key to the appConfig mapping: appConfig[sourceUa][destChainId][destUa]. This change should allow the system to directly associate fees with the relayers and oracles actually involved in a specific cross-chain transaction.

When uaA sends a cross-chain message to uaB, it retrieves the relayer and oracle configuration for chainB from appConfig[uaA][chainB][uaB] to get the addresses.
Upon execution of this cross-chain message on chainA, the system looks up appConfig[uaB][chainB][uaA] to get the relayer and oracle addresses.

Question:

Is my understanding correct that this proposed change would improve the fee distribution and overall flexibility of the cross-chain message handling?

First of all, thanks for this protocol serving OmniChain for ONFT mint and transfer.

I am building a project that requires transferring NFT from one chain to another, but having trouble on Polygon to the other chains.

I followed the guide and made everything clear with setTrustedRemote.
https://polygonscan.com/address/0xA11937C76F8569fC47fe2D7d3EB80288812Ef380

Please make sure the transfer functionality works on Polygon.

Thanks.

Hello LayerZero Community,

I hope this message finds you well. I'm reaching out to express my enthusiasm for the LayerZero and to advocate for the inclusion of Solana support within the platform. As a user and supporter of both LayerZero and Solana, I believe that would greatly enhance the capabilities and utility of both projects.

Here are a few reasons why I believe adding Solana support would be beneficial:

Scalability: Solana is known for its high throughput and low latency, making it an ideal choice for LayerZero's infrastructure. By integrating Solana, LayerZero could benefit from these scalability features, enabling faster transaction speeds and improved performance.

Ecosystem Growth: Solana has a rapidly growing ecosystem with a diverse range of decentralized applications (dApps) and projects. By supporting Solana, LayerZero could tap into this vibrant ecosystem, attracting more developers and users to the platform.

Interoperability: With interoperability becoming increasingly important in the blockchain space, integrating Solana into LayerZero would facilitate seamless communication and interoperability between different blockchain networks, enhancing the overall user experience.

I understand that implementing Solana support may require significant development effort, but I believe that the long-term benefits outweigh the costs. I encourage the LayerZero development team to consider this proposal and explore the possibility of adding Solana support to the platform.

Thank you for considering my request. I look forward to seeing the continued growth and success of LayerZero, and I believe that supporting Solana could play a significant role in achieving that.

Best regards

Add support for Gnosis chain pls. K thx bai.

Hello LayerZero team & community,

Small technical challenge I'm facing here with LZ OFTv2, appreciate any insights or feedbacks anyone would be able to share with me :)

Context:

• I've deployed this base LayerZero OFTv2 contract on my base chain Polygon
• I've deployed this remote LayerZero OFTv2 contract on my remote chain Optimism
• I've used the setTrustedRemoteAddress function on the base Polygon contract to point to the Optimism remote contract (transaction here)
• And vice versa for Optimism->Polygon here

Problem:

• Trying to use sendFrom on the base contract yields a Fail with error 'LayerZero: incorrect remote address size' error (example in this failed transaction)
• I'm assuming it's related to the regular ETH wallet account 0x... type of address I've used for the "_toAddress" parameter, which is actually expecting a bytes32 instead

Question:

• How to properly use sendFrom, and more precisely, how to format my value for "_toAddress" so it's accepted by LayerZero BaseOFTV2 ?
• Bonus points if anyone has any idea on how to convert an address type of input into a bytes32 one in Python? I will be making these kind of sendFrom transactions as part of ApeX/ape which is using the underlying eth-abi Python library

I am trying to send an OFNTv2 from fuji to goerli I am running into LayerZero: wrong path data error but cannot see where the contract calls the send function.

Below is my code:

const { ethers } = require("hardhat")
require('dotenv').config()

// Initiate token names
const NAME = "TestBridge"
const SYMBOL = "TESTBRIDGE"
const SHARED_DECIMALS = 5

const firstEndpoint = '0x93f54D755A063cE7bB9e6Ac47Eccc8e33411d706'
const secondEndpoint = '0xbfD2135BFfbb0B5378b56643c2Df8a87552Bfa23'
const firstLZId = 10106
const secondLZId = 10121

// Initiate two ethers instances 1 for each chain
const firstProvider = new ethers.JsonRpcProvider(process.env.FUJI_RPC_URL)
const secondProvider = new ethers.JsonRpcProvider(process.env.GOERLI_RPC_URL)
const firstWallet = new ethers.Wallet(process.env.PRIVATE_KEY, firstProvider)
const secondWallet = new ethers.Wallet(process.env.PRIVATE_KEY, secondProvider)

const initialAmount = ethers.parseEther("1.00000001").toString() // 1 ether
const amount = ethers.parseEther("1.00000000")
const dust = ethers.parseEther("0.00000001")

const abiCoder = ethers.AbiCoder.defaultAbiCoder()
const walletAddressBytes32 = abiCoder.encode(["address"], [firstWallet.address])


async function main() {
  await deployContracts()
}
main()

// Get contract factories
async function deployContracts() {
  console.log('Getting contract factories...\n')
  const ERC20 = await ethers.getContractFactory("ERC20Mock", firstWallet)
  const ProxyOFTV2 = await ethers.getContractFactory("ProxyOFTV2", firstWallet)
  const OFTV2 = await ethers.getContractFactory("OFTV2", secondWallet)


  // const erc20Address = "0xF49c606621280Ec3Be5861c2eb0e919C8d171F54"
  // const localOFTAddress = "0xBa8a5316744A3Cb4C07f9bEb428447b8Af4448a6"
  // const remoteOFTAddress = "0x6B50f3dA64742dE3cAC38c818f528A4F90988eCF"

  // const erc20 = ERC20.attach(erc20Address)
  // const localOFT = ProxyOFTV2.attach(localOFTAddress)
  // const remoteOFT = OFTV2.attach(remoteOFTAddress)


  // Deploy ERC20 on Fuji chain
  // Deploy proxy on Fuji chain
  // Deploy OFTV2 on Mumbai chain
  console.log('Deploying Contracts...\n')
  const erc20ConstructorArgs = [NAME, SYMBOL]
  const erc20 = await ERC20.deploy(...erc20ConstructorArgs) // Deploy token
  await erc20.waitForDeployment()
  const erc20Address = await erc20.getAddress()
  console.log("ERC20: ", erc20Address)

  const localOFTConstructorArgs = [erc20Address, SHARED_DECIMALS, firstEndpoint]
  const localOFT = await ProxyOFTV2.deploy(...localOFTConstructorArgs) // Deploy proxy to token with token address and local endpoint address
  await localOFT.waitForDeployment()
  const localOFTAddress = await localOFT.getAddress()
  console.log("Fuji OFT: ", localOFTAddress)

  const remoteOFTConstructructorArgs = [NAME, SYMBOL, SHARED_DECIMALS, secondEndpoint]
  const remoteOFT = await OFTV2.deploy(...remoteOFTConstructructorArgs) // Deploy remote token with remote endpoint address
  await remoteOFT.waitForDeployment()
  const remoteOFTAddress = await remoteOFT.getAddress()
  console.log("Remote OFT: ", remoteOFTAddress)


  // Set paths
  console.log('Setting Paths...\n')
  firstPath = ethers.solidityPacked(["address", "address"], [secondEndpoint, firstEndpoint])
  secondPath = ethers.solidityPacked(["address", "address"], [firstEndpoint, secondEndpoint])
  await localOFT.setTrustedRemote(secondLZId, firstPath) // for A, set B
  console.log('Set path for first')
  await remoteOFT.setTrustedRemote(firstLZId, secondPath) // for B, set A
  console.log('Set path for second')


  // Mint tokens
  console.log('Minting Tokens...\n')
  let tx = await erc20.mint(firstWallet, initialAmount)
  await tx.wait()

  // SWAP TOKENS FROM ALICE TO BOB

  // 1. Approve the proxy to swap your tokens
  console.log('Approving Tokens...\n')
  tx = await erc20.approve(localOFTAddress, initialAmount)
  await tx.wait()

  // Set min gas fee
  console.log('Setting min dst gas...\n')
  tx = await localOFT.setMinDstGas(secondLZId, 0, 200000)
  await tx.wait()
  tx = await localOFT.setMinDstGas(secondLZId, 1, 200000)
  await tx.wait()
  tx = await remoteOFT.setMinDstGas(firstLZId, 0, 200000)
  await tx.wait()
  tx = await remoteOFT.setMinDstGas(firstLZId, 1, 200000)
  await tx.wait()

  // 3. Estimate gas
  console.log('Estimating Fee...\n')
  let nativeFee = (await localOFT.estimateSendFee(
    secondLZId, // layezero chain id
    walletAddressBytes32,
    initialAmount,
    false,
    "0x"
  )).nativeFee

  let adapterParams = ethers.solidityPacked(["uint16", "uint256"], [0, 200000]) // 0 for sendFrom

  // 4. Send to end chain
  console.log('Sending Transaction...\n')


  tx = await localOFT.sendFrom(
    firstWallet.address, // from address to send from
    secondLZId, // layerzero chain id
    walletAddressBytes32, // bytes of to address
    initialAmount, // amount to send
    [
      firstWallet.address,
      ethers.ZeroAddress,
      adapterParams
    ],
    { value: nativeFee }
  )
  const receipt = await tx.wait()
  console.log(receipt)
  console.log('\n\n\nSwap has been made \n\n\n')

  // SEND TOKENS BACK TO START CHAIN
  const halfAmount = amount.div(2)

  // 1. Create bytes32 of alice's address
  const aliceAddressBytes32 = abiCoder.encode(["address"], [firstWallet.address])

  // 2. Estimate gas fee
  nativeFee = (await remoteOFT.estimateSendFee(firstLZId, aliceAddressBytes32, halfAmount, false, "0x")).nativeFee

  // 3. Send to alice
  tx = await remoteOFT.sendFrom(
    firstWallet.address,
    firstLZId,
    aliceAddressBytes32,
    halfAmount,
    [firstWallet.address, ethers.ZeroAddress, "0x"],
    { value: nativeFee }
  )
  const receipt2 = await tx.wait()
  console.log(receipt2)
  // TOKENS HAVE BEEN SWAPPED
  console.log('\n\n\nSwapped back\n\n\n')

}

I want a general-purpose storage area at the endpoint where data can be shared across the chain.

example)
ILayerZeroEndpoint.setValue(bytes32 memory _key, bytes32 memory _value);

ILayerZeroEndpoint.getValue(bytes32 memory _key) view return (bytes32);

[Assumed Use]
I want to store the total value of the total supply of ERC20 tokens for all chains.

In English, LayerZero is an infrastructure protocol designed to enhance inter-blockchain communication. It introduces a novel concept called Omnichain DApps (ODApps) and facilitates the creation of ODApps across different blockchains, similar to developing regular DApps for a single network like Ethereum or Polygon. The key feature of LayerZero is that it allows developers to harness the liquidity of various networks without the need for trust intermediaries or consensus protocols.

Currently, when you want to transfer liquidity from one blockchain (Chain A) to another (Chain B), bridges are often used as the primary option. However, bridges are not always optimal, being slow, expensive, and sometimes lacking in asset security, resulting in a suboptimal user experience.

For DEX platforms that aim to operate on multiple blockchains, they need to fragment their liquidity across different networks. This fragmentation can lead to high fees, slippage, reliance on third parties, and other obstacles for end users.

LayerZero aims to simplify the process by allowing DEX platforms to use a single interface and a set of pre-written code for each pair of blockchains, making multi-chain integration more efficient.

LayerZero focuses on low-level messaging interoperability between distributed networks, enabling higher-level crypto applications to be built on top of it, providing their features across various blockchains.

To achieve inter-blockchain communication, LayerZero employs oracles and relays. Oracles fetch block headers from one blockchain and send them to another, while relays retrieve transaction proofs.

Security in this architecture depends on the honesty of these two parties. If both the oracle and relay are honest, the transaction is validated and sent to the target chain. If either is dishonest, the transaction cannot be verified.

To ensure secure communication between blockchains, LayerZero employs a "valid delivery" mechanism, coupling each message with a transaction on the sender's chain. This ensures that a message is delivered to the receiver only if the associated transaction is valid and has been validated on the sender's chain.

LayerZero also utilizes "Endpoints" as user interfaces on each network. These endpoints consist of Communicators, Validators, Networks, and Libraries. Adding new chains to LayerZero is made easy through the modular design.

The combination of LayerZero and the Inter-Blockchain Communication (IBC) protocol from Cosmos enhances communication and token standardization across different networks. This approach provides a more comprehensive solution for inter-chain communication than the IBC alone, which is limited in connecting with Ethereum and EVM-based networks.

LayerZero Labs raised $135 million in funding from prominent institutions, and the project is continually evolving.

In conclusion, LayerZero is part of a new wave of projects focused on composability and interoperability. Its integration with the IBC protocol allows it to serve as a versatile messaging layer for communication between various blockchains, potentially shaping the future of inter-chain communication. The success of LayerZero will depend on the dApps built on it, the choice of oracles and relays, and the integration of new chains into its ecosystem.

Hey, y'all!

Are there any plans to add the Solana blockchain into the supported set of Chains?
Thanks!

Upon integration with Chanlink Oracles, how do you expect addressing potential scalability bottlenecks that might come from Chainlink oracle data delivery on-chain? Can you advise on strategies like threshold signatures, oracle data aggregation off-chain, or zero-knowledge proofs to optimize data transmission and verification?

https://github.com/LayerZero-Labs/LayerZero/blob/main/contracts/Endpoint.sol#L92

I wanna send msg by this method which requests the destination chainId , but many chainIds are larger than uint16.max , just like mumbai (80001), Should I convert it in someway?

I'm wondering if there is a package / register or anything else I can use to fetch the EIDs listed here dynamically on my code?

It's nice that there's slippage tolerance on bridging, but there's zero consideration for slippage when it comes to gas. if you do max gas when bridging from Optimism to Metis, the amount of ETH you spend (approx 0.0928 or $334 per last check) gets you much less METIS than you would expect (2.5 METIS or $254 per last check). That's 24% slippage. However, the UI only shows you the amount of ETH you are spending and the amount of METIS you are getting, so it is hard to know how bad the slippage is. Further, it is quite possible that someone bridging 2.5 METIS would not realize that is far more gas than they will need. I am attaching images of both the current UI and a proposed UI to show the difference.

It's hard to develop a secure off-chain relayer. Could we open-source the off-chain relayer, or release a demo project?

The docs link is redirecting to the old Docs page.

please add option to collapse it, it's affecting the readability of the docs