Stargate bridge is a cross-chain liquidity protocol for native asset transfers

Stargate bridge is a same-asset, cross-chain transfer workflow in which Taxi mode sends one transaction directly, without waiting for a batch. The reliable first-position routine is to prepare the exact token and route, sign any required ERC-20 approval, execute the transfer, confirm LayerZero delivery and the destination balance, then reverse the route only after the receipt is complete.

This page treats the process as a round trip. It focuses on route selection, the Fast or Taxi action, destination reconciliation, and a clean return, using concrete EVM identifiers and stable message states.

The short version: A 42-character EVM recipient address must match the intended destination before either leg of the round trip is signed.

Preventing an asset-and-network mismatch

The most common Stargate Taxi mistake is matching a familiar ticker to the wrong network or representation, so route review must precede every signature.

Start with the source wallet's actual balance, not an asset name remembered from another chain. USDC on Ethereum, USDC on Arbitrum One, and a Hydra representation are separate contract instances even when the interface presents a same-asset path. The destination selector must show the network that will receive the token, while the recipient field must resolve to the intended 20-byte EVM address. Compare the token symbol, source network, destination network, and recipient as one route. A correct ticker beside the wrong chain creates a different operation, and the return leg will not repair that selection.

Use the route that the current interface actually offers. Saved screenshots and old transaction history describe earlier paths; the live selector defines the next pair.

Fixed identifiers for the route review

Three fixed parameters anchor a Stargate Taxi review: the recipient size, the transaction identifier size, and the direct transport type.

An EVM address occupies 20 bytes and renders as 40 hexadecimal digits, or 42 characters with the 0x prefix. An EVM transaction hash occupies 32 bytes and normally renders as 64 hexadecimal digits, or 66 characters including that prefix.

These lengths are format checks, not proof that a route is correct. The wallet must still control the 20-byte recipient, and the 32-byte hash must belong to the expected source transaction. Taxi's 1-to-1 transport describes message handling: one user transfer is sent without waiting for other riders. Record the full hashes rather than shortened labels, because the first and last four characters shown by a wallet are insufficient for later reconciliation. A complete copy also distinguishes the outbound and return transactions when both use the same asset, address, and two networks during a round trip.

Preparing the wallet and same-asset path

A Taxi transfer is ready only when the source wallet holds the asset and native gas, and the interface exposes the exact same-asset pathway.

1. Connect the wallet that holds the source asset.
2. Select the wallet's active network as the source.
3. Choose the intended destination network.
4. Select the same asset and enter the amount.
5. Set the recipient, then choose Fast or Taxi.

Wallet network and gas

Connect the wallet on the source network first. A USDC transfer from Ethereum requires USDC plus ETH for the source transaction; an Arbitrum One source also uses ETH, while Avalanche C-Chain uses AVAX. Keep enough native gas for every source-chain signature, including a separate ERC-20 approval when the existing allowance is too low.

Asset, amount, and recipient

Stargate V2's same-asset rule keeps the selected asset within its supported route: USDC maps to USDC, USDT maps to USDT, and ETH follows an ETH route where offered. Enter the amount, inspect the destination amount shown by the interface, and set the recipient deliberately. The connected EVM account may keep the same address across Ethereum, Base, OP Mainnet, and Arbitrum One, yet a custom recipient remains possible. Make that choice before signing, because the signed transaction encodes the destination address. That encoded recipient becomes the address used for final receipt verification.

Taxi mode at the confirmation screen

The decisive Stargate control is the mode selector: choose Fast, labeled Taxi, after the route summary matches the intended source, destination, token, and recipient.

Set against that, Stargate V2 exposes two transfer modes, and Taxi is the direct 1-to-1 path rather than the batched Bus path.

An ERC-20 transfer such as USDC or USDT first needs enough allowance for the contract that spends the token. If the allowance is below the selected amount, the wallet presents an approval transaction before the transfer transaction. Approval changes an allowance on the source chain; it does not bridge the token. Wait for that receipt to succeed, return to the transfer panel, and review the quote again before signing the send. A native ETH route skips ERC-20 approval because ETH is supplied as transaction value, although the wallet still signs the actual Taxi send.

The send confirmation should show the source network, contract interaction, token amount, recipient, and native gas charge. Preserve the source transaction hash as soon as it is broadcast. A wallet notification that says submitted records only the source action; cross-chain receipt requires the later message and destination checks.

How do you confirm a Taxi transfer has arrived?

A Stargate Taxi transfer has arrived only when the LayerZero message is Delivered and the intended destination address shows the credited token (more on this in Stargate bridge walkthrough ).

Source transaction receipt

Begin with the source receipt. It should show a successful transaction on the selected source chain and the exact sending address. An EVM transaction hash is 32 bytes, displayed as 64 hexadecimal digits after the 0x prefix. Copy the whole value into the Stargate tracker or LayerZero Scan; a shortened wallet label is convenient for display, not for matching two records.

LayerZero message state

LayerZero Scan separates the message from the source transaction that created it. Inflight means the message is still passing source confirmation, Decentralized Verifier Network verification, or destination execution. Confirming means the Executor has submitted the destination transaction and finality remains pending. Delivered means the destination receive function executed successfully. Those three labels describe different checkpoints, so a successful source receipt cannot stand in for Delivered. Save the destination transaction hash once it appears, then match its destination network and recipient against the transfer summary prepared before signing. The sequence records the same message, not three separate bridge attempts.

Destination balance and token

Open the destination network in the wallet and inspect the intended asset, not merely the account's total value. Match the token contract or native asset, the recipient, and the credited amount. The destination transaction receipt supplies the onchain record that completes this comparison.

The check is complete when the source receipt, LayerZero message, and destination credit describe one transfer. This three-part record is stronger than treating a refreshed wallet balance as the receipt.

Reconciling destination units and representations

Destination reconciliation is exact when the displayed token units are converted with that token's decimals and matched to the amount shown in the bridge receipt.

Ethereum USDC and USDT each use 6 decimal places, so 1 whole token equals 1,000,000 base units in an EVM receipt. ETH uses 18 decimal places, and 1 ETH equals 1,000,000,000,000,000,000 wei. Wallets perform this conversion for display, while explorers expose raw integers or formatted values. Read the token contract beside the amount before comparing the figures. A raw value interpreted with 18 decimals instead of 6 produces a trillion-fold mismatch, even though the underlying receipt is correct. The same decimal check applies after the asset returns to the original chain during the second leg.

If the destination uses a Hydra OFT representation, reconcile the exact received contract and symbol shown by the route. A core-chain native pool and a Hydra representation are different receipt contexts, even when Stargate supports redemption between them.

Contract-level reconciliation beats comparing portfolio values, which move with market pricing and hide the asset units that the bridge actually delivered.

Building the return route

A clean Stargate return begins only after destination delivery, because the received network now becomes the source network for a separate Taxi transaction.

Restoring source and destination

Switch the wallet to the network that received the asset, then reverse the chain selectors. Network identifiers remove ambiguity: Ethereum uses chain ID 1, OP Mainnet uses 10, BNB Smart Chain uses 56, Polygon PoS uses 137, Base uses 8453, Avalanche C-Chain uses 43114, and Arbitrum One uses 42161. These are EVM chain IDs, not LayerZero endpoint IDs. Match the wallet's active network with the new source selector, and keep enough of that network's native gas token for the approval and send that follow.

Confirming the reverse asset

Select the exact token that arrived. A same-asset return uses USDC back to USDC, USDT back to USDT, or the available ETH path back to ETH; it does not turn the round trip into a swap. For a Hydra route, choose the redemption path that the interface offers to the desired core chain, then read the destination representation before continuing.

Signing and verifying again

Review the new recipient, select Fast or Taxi, sign any destination-chain ERC-20 approval, and then sign the return send. Record a second source hash, a second cross-chain message, and a second destination receipt. The original chain balance confirms the exit only after the return message is Delivered and the credited asset matches the original contract or native asset. That two-leg record is more reliable than inferring completion from a single portfolio screen.

Taxi execution under the hood

For most users, Stargate Taxi execution uses the LayerZero V2 OFT interface to debit the source asset and deliver one cross-chain message without waiting for a batch. For a pool route, Stargate locks or accounts for liquidity on the source and releases the corresponding asset on the destination. An OFT route burns or locks on one side and mints or unlocks on the other. Decentralized Verifier Networks verify the message, and an Executor delivers it. Taxi prioritizes direct dispatch over Bus batching.

Maintaining a bridge record

A durable Stargate bridge record ties each round trip to four fields: full transaction hashes, chain IDs, token contracts, and recipient addresses. Store the outbound and return legs separately with Delivered status and destination receipts. Recheck contract addresses before reusing the route, because supported pathways change while completed transaction identifiers remain fixed. This ledger makes reconciliation faster than searching wallet history across several networks.