Bridge Tokens with LayerZero

LayerZero is not a bridge. It is a messaging protocol that bridges are built on top of — which matters enormously, because it means the security of your transfer is set by whoever deployed the token or application you are using, not by LayerZero itself. This guide covers the OFT model, the Stargate route most users actually take, how the messaging fee is assembled, and the specific configuration question that decides how risky any given LayerZero route really is.

What LayerZero actually is

At the base of the stack sits the Endpoint: an immutable smart contract deployed on each supported chain that acts as the entry and exit point for messages, exposing standardised interfaces for sending, receiving and configuring them. Chains are addressed by an Endpoint ID (eid) rather than their native chain ID — mainnets use the 30xxx range, testnets 40xxx — which is why a LayerZero explorer shows you "30101" where a block explorer would show "1".

Between the two Endpoints, two off-chain roles do the work. DVNs — Decentralized Verifier Networks — independently verify the payloadHash of each message to confirm its integrity. The Executor is a permissionless off-chain service that watches for verification to complete and then executes the verified message on the destination chain, handling gas payment and delivery. Nothing is "wrapped by LayerZero" in the way older bridges wrapped assets; a message is verified and then executed, and what that execution does is entirely up to the application.

An application built on this is an OApp. The token-flavoured version is an OFT, and it is the one you will encounter most.

OFT, OFT Adapter, and Stargate: three different things

People say "bridge with LayerZero" to mean at least three distinct operations.

OFT (Omnichain Fungible Token)

An OFT extends a standard fungible token with LayerZero messaging so it can move between chains directly. The mechanic is debit on the source chain and credit on the destination: tokens are burned or locked on one side — effectively removed from circulation — and the same amount is minted or unlocked on the other. The result is what LayerZero's docs call a unified global supply: one token, many chains, no per-chain wrapper. When you move an OFT, there is no liquidity pool involved and no price impact, because nothing is being swapped.

OFT Adapter

Existing tokens that cannot be modified use an adapter contract instead: it locks the original token on the source chain and mints the omnichain representation on the destination. Functionally similar for you as a user, but note the implication — the adapter holds a real, growing pot of the underlying asset, and that pot is a target.

Stargate

Stargate is an application built on LayerZero, not LayerZero itself. It is what you want when the asset you hold is not an OFT and you need a liquidity-backed transfer — the classic "I have USDC here and want USDC there" case. Stargate v2 also serves as the reference user-facing front-end for many OFT routes, so in practice most people bridging "with LayerZero" are using the Stargate interface.

What you'll need (prerequisites)

• A self-custodial wallet (MetaMask, Rabby, or a hardware wallet driving one) connected to the source chain.
• Native gas on the source chain — and more of it than a same-chain transfer needs. The messaging fee that pays the DVNs and the Executor is charged on the source side, in the source chain's native token, as part of your send transaction.
• Native gas on the destination chain, or an explicit plan for getting some. This is the most common way people strand themselves: the tokens arrive, and there is nothing to pay for the transaction that would move them.
• The token's official contract address on both chains, taken from the issuer. An OFT deployment is only legitimate if the issuer deployed it.
• An approval, for ERC-20 sends — see how to revoke token approvals.

Step-by-step: a transfer through the Stargate interface

1. Step 1: Open the official app and verify the URL

   Go to the Stargate app at stargate.finance, typed or bookmarked. Bridge front-ends are among the most heavily cloned pages in crypto, and a convincing fake needs only to change the contract you approve. Do not arrive from a search advertisement, a DM, or a link in a token's Telegram.

2. Step 2: Connect your wallet and pick source and destination

   Connect the wallet, then set four things: source chain, source token, destination chain, destination token. In simple mode the destination defaults to your connected wallet address. Advanced mode lets you specify a Custom Address on the destination — useful, and also the single most dangerous field on the page. If you use it, verify the full address character by character, and never paste one out of transaction history; see how to detect address poisoning.

3. Step 3: Fund the source chain for the messaging fee

   Enter the amount. The interface will quote a fee that is larger than a plain token transfer, because you are prepaying the whole cross-chain lifecycle out of the source chain's native token: the source transaction itself, each configured DVN for verification, and the Executor for execution on the destination. Make sure your native balance covers the amount plus that fee, and do not bridge your entire gas balance away in the same transaction.

4. Step 4: Approve the token (ERC-20 sends)

   The first send of a given ERC-20 needs an approval granting the OFT or Stargate contract permission to move it. Where your wallet lets you edit the allowance, approve the exact amount rather than an unlimited one — that bounds your exposure if the spender is ever compromised, which for a bridge contract is exactly the scenario worth bounding.

5. Step 5: Choose the route, set slippage, and send

   Once an amount is entered the interface presents route options — a Recommended Route (currently defaulting to fastest), a Fastest Route and a Cheapest Route — and shows the estimated fees, the transfer time, and the amount you will receive. Slippage tolerance sits under Advanced Settings, with typical presets of 0.1%, 0.5%, 1% and 3%. Compare the "amount you'll receive" figure across the routes rather than the headline fee, then confirm in your wallet.

   Underneath, the fast/cheap distinction is Stargate v2's two modes of transport. Taxi sends the omnichain message immediately at the moment of the swap — faster, more gas. Bus batches your transfer with others: your swap settles instantly on the local chain with guaranteed finality, but the cross-chain message waits until the bus has between two and ten passengers before it departs. Stargate's docs credit this batching with cutting costs by over 95% relative to Stargate v1. An impatient passenger can buy up the remaining tickets to make the bus leave immediately.

6. Step 6: Track the message on LayerZero Scan, then verify the destination

   Paste your source transaction hash into layerzeroscan.com. This is the authoritative view of a cross-chain message and it will tell you exactly which stage you are at, rather than leaving you refreshing a wallet. Once it reads Delivered, open the destination chain's block explorer, confirm the credited token contract is the one you expected, and save both hashes — reconstructing a cross-chain movement at tax time from balances alone is painful.

Fees: what you are actually paying for

A LayerZero send is prepaid on the source chain. The protocol's quote function returns a MessagingFee struct with two fields — nativeFee and lzTokenFee — because a message can be paid for in the source chain's native gas token or in ZRO, LayerZero's token, depending on how the application is configured. In practice, front-ends quote you the native figure. LayerZero's docs note that the quote is accurate because the same function the interface calls is the one the Endpoint uses when pricing the send.

That single number covers three things: the source chain transaction, a fee to each configured DVN for verifying the message, and a fee to the Executor for executing it on the destination. This is why bridging from an expensive chain costs more than bridging to one, and why the same route can be priced very differently at two times of day — destination gas is being estimated and prepaid at source.

Stargate then adds its own layer on top for pool-backed transfers, and it is genuinely dynamic: the docs state that fees "are set by the AI Planning Module on a per pathway basis," with no fixed percentage. The interesting detail is that quoteOFT returns fee details as a signed integer, so the value can be negative — meaning some pathways pay you a reward rather than charging a fee, because your transfer happens to rebalance a pool in a direction the protocol wants. There is no published rate card to memorise here. The only correct answer is to read the quote in the interface at the moment you transact, and to compare it against at least one alternative route.

Finally, budget for a destination-side transaction. Arriving with tokens and zero native gas is the most common self-inflicted problem on this route. Some applications support a "native drop" that delivers a small amount of destination gas alongside the transfer — if the interface offers it and you have no balance on the destination chain, take it.

Security: the DVN configuration is the security model

This is the part that most guides skip, and it is the only part that determines whether a LayerZero route is safe. LayerZero deliberately does not impose one security model. Instead, every application configures its own: which DVNs must verify its messages, and how many of them, expressed as an X-of-Y-of-N threshold. Two OFTs on the same two chains can therefore have wildly different security while looking identical in a wallet.

LayerZero's own documentation is unusually direct about the danger in the defaults. Placeholder configurations for new channels typically designate LayerZero Labs as both the required DVN and the Executor — a single point of control over the pathway — and the docs state that production deployments "should explicitly configure their security stack with at least one required DVN that is not operated by LayerZero Labs." On some chains only one DVN provider is available at all, leaving deployers to run their own, wait, or ship anyway.

Plenty ship anyway, and the consequences are not hypothetical. The KelpDAO rsETH bridge exploit of April 2026 cost roughly 116,500 rsETH — about $292M — when an attacker defeated a single one-of-one DVN by compromising RPC nodes. The code was not broken in the classical sense. The security threshold was one, and one was bought.

That failure sits in a long line of bridge losses driven by verification and signer design rather than exotic bugs: Ronin ($620M, validator keys phished), Wormhole ($326M, signature verification bypassed), BNB Chain Token Hub ($568M, forged Merkle proofs), Nomad ($190M, a bug anyone could copy-paste), and Multichain (~$210M, keys simply became inaccessible). See also Orbit Bridge and Poly Network.

Practical implications: prefer OFTs deployed by issuers with a published, multi-party DVN configuration over anonymous deployments; treat a route's security as unknown until you have checked who verifies it, and size accordingly; split large transfers into tranches; always send a small test amount on an unfamiliar route and wait for Delivered before sending the rest; and never leave meaningful size sitting in a bridged representation you do not need to hold. A hardware wallet remains the cheapest available reduction in the wallet-compromise half of the risk.

When not to use this route

• You are only moving between an L2 and its own L1. A canonical rollup bridge inherits the rollup's security and adds no third party. If you are going from Arbitrum to Ethereum and are not in a hurry, see how to bridge to Arbitrum; for Base, how to bridge to Base.
• You are only moving USDC. A native burn-and-mint route such as Circle's CCTP avoids ending up holding a wrapped representation you then have to swap out of.
• The OFT deployment is not from the issuer. Anyone can deploy an OFT. If the issuer has not published the destination contract address, you are not bridging their token — you are buying someone's IOU. Check the liquidity before you assume you can exit.
• You cannot establish who verifies the route. A one-of-one DVN configuration on a large transfer is the exact shape of the KelpDAO loss. If the security stack is undisclosed, treat the route as size-limited.
• The amount is small relative to the messaging fee. The DVN and Executor components do not scale down with your transfer. On expensive source chains a small transfer can lose a large fraction of itself to fees; consolidate, or start from a cheaper chain.
• You need the funds at a hard deadline. Bus mode waits for passengers, and destination congestion can delay execution. Use taxi mode, or budget slack.

Troubleshooting

• The source transaction confirmed but nothing arrived. Look the hash up on LayerZero Scan before doing anything else. Inflight means the message is waiting on source block confirmations, verification, or execution on the destination — it is in progress and you should wait. Confirming means the destination transaction has been submitted and is waiting to reach finality there.
• LayerZero Scan shows "Blocked". Per the documented statuses, this means a previous message nonce has a stored payload that is halting the current one. Messages on a pathway are ordered; the queue has to be cleared before yours moves. This is an application-level condition, so raise it with the application's support channel rather than retrying the send.
• LayerZero Scan shows "Failed". The transaction encountered an error and did not complete. Common causes are insufficient gas supplied for destination execution or a revert in the receiving contract. Do not resend blindly — the funds are usually still recoverable through a retry of the delivery, and sending again may simply duplicate the problem.
• The transaction reverted with a slippage error. Stargate's fee library reverts with SlippageTooHigh when the amount that would actually arrive, after fees and rewards are applied, falls below the minimum you specified. Raise the tolerance in Advanced Settings modestly, or reduce the size on a thin pathway. Do not set an extreme tolerance to force a transfer through.
• My tokens arrived but I cannot move them. You have no native gas on the destination chain. Send a small amount of the destination's gas token from another wallet or withdraw a little from an exchange; nothing is lost, but nothing can move until you do.
• The destination balance is slightly less than I entered. That is the fee, and on some pathways the difference can go the other way as a reward. The "amount you'll receive" figure shown before you confirmed is the number to reconcile against.
• I approved a contract I should not have. Revoke the allowance immediately, then move the remaining balance to a fresh wallet if you suspect an active compromise. Our approvals guide covers the steps.
• The source transaction is stuck pending. This is an ordinary EVM problem, not a LayerZero one. Replace it by fee at a higher gas price, or cancel it with a zero-value transaction to yourself at the same nonce and higher gas.

FAQ