Stargate is a Cross-Chain Liquidity Protocol With Transfer Verification

Reading the fee preview before signing

The destination amount, source-chain gas, protocol adjustment, and LayerZero messaging charge decide whether a Stargate quote is acceptable before the wallet opens.

Read the preview as a balance equation. The source amount is what leaves the wallet, while the destination amount is what the route expects to credit. A separate minimum-received value is the contract’s lower bound. Pool routes apply a treasury fee or a balancing reward through the fee library; a Hydra OFT route doesn’t issue a reward, although it can charge a treasury fee. The messaging quote and source transaction gas remain separate from that token-side adjustment, so one percentage never describes the whole transfer cost.

Protocol amount

The token-side quote distinguishes amount sent, amount received, and minimum amount received; signing commits the last value as an execution boundary.

For an OFT listed under Stargate’s frontend listing rule, the defined protocol fee is 2 basis points, or 0.02%. One basis point equals 0.01%, so the conversion is fixed even though the displayed token amount changes. Decimal precision also matters. Ethereum USDC and USDT each use 6 decimals, meaning 1 token unit is encoded as 1,000,000 base units. ETH uses 18 decimals, with 1 ETH represented by 1,000,000,000,000,000,000 wei.

Messaging charge

The LayerZero V2 messaging quote pays for moving and executing the cross-chain instruction, and Stargate displays that charge before submission.

At contract level, the MessagingFee structure has 2 fields: nativeFee and lzTokenFee, both expressed as unsigned 256-bit integers. The common wallet path pays the native fee in the source chain’s gas asset. Taxi sends one message for the transfer, while bus shares messaging cost across a batch. Driving a partly filled bus means covering the remaining tickets, so the preview changes before the transfer is signed.

Source-chain gas

The wallet adds source execution gas to the route economics, and an ERC-20 approval introduces another transaction when allowance is insufficient.

On Ethereum, chain ID 1 uses EIP-1559 fee controls with 2 user-facing caps: maximum fee per gas and maximum priority fee per gas. MetaMask and Rabby estimate them at signing time. An existing allowance can reduce an ERC-20 route to 1 source transaction; a new approval followed by the transfer produces 2 receipts. A native ETH route has no ERC-20 approval, although it still pays execution gas and messaging value.

Which route fields decide the transfer?

A valid Stargate route is decided by 5 visible choices: source network, source asset, destination network, destination asset, and recipient.

Network identity is exact, not visual. Ethereum uses EVM chain ID 1, Arbitrum One uses 42161, Optimism uses 10, Base uses 8453, Avalanche C-Chain uses 43114, and BNB Smart Chain uses 56. These identifiers don’t establish that a route is available; the live quote does that for the selected asset pair. They do let the wallet prove that it’s connected to the quoted source. The destination selector separately controls where the cross-chain instruction delivers value, even when both networks use ETH as their gas symbol.

Stargate V2 routes preserve asset identity: USDC routes to USDC, rather than becoming USDT at settlement. Simple mode fills the destination with the connected account; advanced mode accepts a custom recipient. An EVM recipient is 20 bytes, written as 40 hexadecimal characters or 42 characters including the 0x prefix. Inside the OFT SendParam, that recipient occupies a 32-byte field, while the LayerZero destination endpoint uses a 32-bit integer.

Use this decision checklist before opening the wallet:

• The wallet holds the selected asset and the source network’s native gas token.
• The source chain ID matches the network named in the quote.
• The destination asset is the same asset that the route preview names.
• The connected or custom recipient is the intended destination account.
• The displayed minimum received remains acceptable after the latest refresh.

The two wallet actions behind an ERC-20 transfer

An ERC-20 Stargate route uses an allowance action and a transfer action unless the bridge contract already has enough approved allowance.

Allowance transaction

The approval sets how many token units the named Stargate contract may spend from the source account; it doesn’t move the tokens cross-chain.

MetaMask, Rabby, or a Ledger account connected through either wallet shows the spender, token contract, and allowance amount. Exact approval covers the quoted source amount. A larger existing allowance remains on that source chain after the route uses what it needs. Because allowance belongs to one token contract, one owner, one spender, and one chain, an approval for USDC on Arbitrum doesn’t authorize USDC on Base.

Transfer transaction

The transfer call supplies the destination endpoint, recipient, source amount, minimum destination amount, messaging options, composed message, and transport command.

Those are the 7 fields in LayerZero V2’s SendParam structure. Stargate’s sendToken call adds a refund address and returns 3 records: a messaging receipt, an OFT receipt, and a bus ticket structure. Taxi uses an empty transport command; bus uses a 1-byte command. The wallet’s final confirmation should therefore match the refreshed route’s contract, value, and network rather than the earlier approval screen.

Only the second action starts delivery. An approval receipt by itself leaves the destination balance unchanged.

What changes after the source transaction confirms?

A successful source confirmation debits the selected amount, settles the local Stargate obligation, and creates the cross-chain instruction for destination execution.

LayerZero’s transfer tracker represents the lifecycle with 5 status values: PENDING, PROCESSING, SUCCEEDED, FAILED, and UNKNOWN. Its execution history separates 3 events: SENT on the source, BUS_RODE for a Stargate V2 batch, and DELIVERED on the destination. A Stargate V2 bus groups between 2 and 10 passengers, while taxi submits the message without waiting for a batch. Source settlement therefore precedes destination visibility for a bus ride. The credit system reserves the pathway’s capacity when the source action settles, while the destination transaction later releases pool assets or completes the relevant OFT state change.

Verifying the destination balance

Destination verification is complete only when the delivery record and recipient balance agree on the chain, token contract, and credited amount.

Match the two transaction records

The source receipt proves submission, while the destination receipt proves that the LayerZero instruction executed on the chain selected in Stargate.

An EVM transaction hash is 32 bytes, displayed as 64 hexadecimal characters or 66 characters with its 0x prefix. LayerZero Scan connects the cross-chain message to both hashes. Etherscan, Arbiscan, and BaseScan then expose each chain’s receipt independently. On EVM networks, receipt status 1 means execution succeeded and status 0 means it reverted. Matching the recipient and token contract on the destination record prevents a same-symbol asset from being mistaken for the quoted token.

Read the asset record

The destination account’s asset record is decisive: an ERC-20 credit appears in its token balance and in the destination transaction’s event log.

The ERC-20 Transfer event carries 3 values: from, to, and value. Its value is stored in the token’s smallest unit, so wallet formatting must apply the destination contract’s decimals. MetaMask and Rabby sometimes need the token contract added before the balance becomes visible in the interface. The block explorer remains readable without that wallet metadata. Native ETH differs because its balance change isn’t an ERC-20 Transfer event; read the account balance and transaction value instead.

Finish by comparing the credited amount with the previewed destination amount, not with the original source amount. The supporting detail is gathered in Stargate app.

Resolving a wrong-network wallet setup

A wrong-network setup is resolved by matching the wallet’s chain ID to the quoted source chain, then refreshing the route before signing again.

If Stargate quotes Arbitrum One but the wallet is connected to Ethereum, the contract call belongs to a different execution environment and the intended request can’t proceed. Switch the wallet to chain ID 42161, confirm that the selected source token balance appears there, reconnect if the account state hasn’t refreshed, and request a new quote. Don’t reuse the earlier gas figure or minimum-received value, because both belong to the previous route snapshot. The recipient and destination selections should remain visible after the source network is corrected.

If the approval already confirmed before the mismatch became apparent, inspect its chain and spender. An approval on the intended source chain remains valid up to its recorded allowance, so the refreshed route may proceed directly to the transfer. An approval on another chain has no effect on the intended route. There’s no destination state to recover until sendToken itself confirms on the quoted source network.

The next wallet prompt should show the corrected chain, Stargate contract, and refreshed value together.