Stargate

Stargate app is a custom-address cross-chain transfer interface

Stargate app is a cross-chain transfer interface that lets a sender replace the connected wallet’s default destination with another valid address before confirming the source-chain transaction. In Advanced mode, the source wallet still signs and pays, while the chosen recipient receives the supported token on the selected destination network. The address, destination chain, token, quoted output, and fee must agree before signing because the confirmed message carries that recipient into destination-chain execution.

Updated: August 10, 2026

Fees attached to a custom-address transfer

A custom destination doesn’t add a separate address surcharge; the quote combines Stargate’s transfer fee, messaging cost, gas, and route-specific adjustments.

Stargate applies a 2-basis-point transfer fee, equal to 0.02% of the token amount, to transfers through its interface. One basis point is one hundredth of 1%, so 10,000 basis points equal 100%. That token-denominated component is separate from the native messaging fee returned for the route. At protocol level, quoteSend exposes two fee fields, nativeFee and lzTokenFee; the ordinary interface presents the payable route rather than asking users to calculate them. The chosen recipient doesn’t change the percentage.

The fixed 2-basis-point charge comes first. Source-chain gas, the LayerZero message quote, the transport mode, and any route reward or treasury adjustment set the remainder. Because those inputs move, the interface refreshes its quote after the recipient and amount are entered. The contract quote and submitted value must remain aligned: if the messaging price rises beyond the value attached to the call, the source transaction reverts; if it falls, the separate refund address receives the excess. Treat the refreshed receive amount and native fee as the confirmation values.

Recipient errors become destination-chain state

A confirmed custom recipient becomes part of the cross-chain instruction, so an incorrect destination can settle to the wrong account permanently.

Interface validation establishes that the text fits the selected network’s address format. It doesn’t establish who controls an externally owned account, whether a smart account is deployed on that chain, or whether a custodian credits the selected token. On an EVM route, the same 42-character form can identify a MetaMask account, a Safe smart account, an exchange deposit wallet, or another contract. Stargate and LayerZero execute the submitted recipient value; neither protocol substitutes the source wallet after confirmation or recalls a completed destination transfer. The address field is execution data, not an ownership directory.

Compare the entire recipient, destination network, and token before signing. The most reliable handoff is an address copied from the recipient’s wallet on the destination network, paired with the exact asset they expect. Once the source call is confirmed, correcting the field requires a separate transfer controlled by whoever received the original delivery.

Selecting the destination before wallet confirmation

Advanced mode exposes the recipient field before signing, while Simple mode keeps the connected wallet as the destination by default.

The Stargate app builds the transfer from four routing selections: source chain, source token, destination chain, and destination token. The amount and custom recipient complete the quote request. After connecting MetaMask or Rabby Wallet, choose Advanced mode, replace the default address in the destination section, and let the route recalculate. An ERC-20 route may first require one approval transaction followed by one send, producing two source-chain confirmations when no allowance exists. A sufficient existing allowance leaves one send confirmation. The custom recipient never signs the source call and needs no active session with the interface.

Which address should you enter?

Enter an address controlled or explicitly accepted by the recipient on the selected destination network, then preserve its exact character sequence.

For an EVM destination, an address occupies 20 bytes and displays as 40 hexadecimal characters after the 0x prefix, making 42 characters in total. EIP-55 adds a mixed-case checksum without changing those 40 hexadecimal positions. An EIP-55 address carries about 15 check bits on average, leaving a 0.0247% chance that a randomly mistyped address passes its checksum. The checksum catches many transcription errors, yet it doesn’t identify the intended owner or destination network.

MetaMask and Rabby Wallet show the active account address directly, while a Safe recipient should provide the smart account address for the chosen chain. Copying a contract address from Ethereum doesn’t prove that equivalent contract code exists on Base. Syntax, control, and chain deployment are three separate conditions, and all three determine whether the recipient can use the delivered tokens.

Same address text, different network context

The same 42-character EVM address can exist on many networks, but Stargate directs value by the destination network selection.

Chain identity supplies the missing context. Ethereum uses chain ID 1, OP Mainnet uses 10, Polygon PoS uses 137, Base uses 8453, and Arbitrum One uses 42161. Stargate maps that selected network to LayerZero’s endpoint identifier; examples include 30101 for Ethereum, 30110 for Arbitrum, 30111 for OP Mainnet, and 30184 for Base. Users choose the named network rather than entering either identifier. This mapping prevents the readable address from acting as a network selector; the interface selection supplies that dimension. A Base address pasted while Arbitrum remains selected is therefore an Arbitrum recipient, even when both networks display identical address text.

Smart accounts and custodial deposit addresses

A contract or custodial deposit address is valid only when that destination accepts the exact token and route being delivered.

An EVM externally owned account can hold ERC-20 balances without running code. A Safe smart account, vault, or application contract has different operational requirements: the contract must exist on the destination chain, and its owners or functions must permit later movement of the asset. The custom field supplies an address, not a deployment instruction. Sending to a counterfactual or undeployed smart-account address can leave the balance waiting until compatible code is deployed and controlled. Holding and later operating the balance are separate capabilities.

Custodial recipients add an accounting layer outside the protocol. If a service lists a specific network and deposit address for USDC, use that exact pairing; don’t substitute USDT because both are dollar-denominated ERC-20 tokens. Stargate’s recipient value contains one destination address and no separate exchange memo field. A deposit flow requiring an additional memo or tag therefore needs a route that carries that second identifier, as broken down in Stargate explainer.

Quote amounts, minimum output, and approval steps

The quote binds the amount, minimum received, route, and recipient before the wallet submits the final Stargate contract call.

In Stargate V2, amountLD and minAmountLD are 256-bit unsigned integers expressed in the token’s local decimals. USDC uses six decimal places, so 1 USDC is encoded as 1,000,000 local units. The quoteOFT call returns three components: transfer limits, an array of fee or reward details, and an OFT receipt containing two amounts, sent and received. If the calculated delivery falls below minAmountLD, the send reverts and the custom recipient receives nothing. A separately confirmed ERC-20 approval remains available until its allowance is spent or changed.

A worked custom-recipient transfer

A worked calculation shows that changing the destination address doesn’t alter the fixed percentage component of the overall transfer cost.

Every changing input in this hypothetical example is hypothetical: Ethereum as the source, Base as the destination, 500.000000 USDC, a valid custom EVM recipient, no route reward or additional token adjustment, and messaging gas paid separately in ETH. Those assumptions isolate the 0.02% Stargate transfer fee from live network pricing.

Multiply 500 USDC by 0.0002 to obtain a 0.10 USDC fee. Subtracting that amount leaves 499.90 USDC for the destination address under the stated inputs. At six decimal places, the send amount is 500,000,000 local units, the fee is 100,000 units, and the delivered amount is 499,900,000 units. The native ETH messaging payment doesn’t reduce this token total because the example pays it separately.

Recipient encoding inside Stargate V2

Under Stargate V2, the custom address becomes the to value inside a seven-field LayerZero OFT SendParam structure.

The to field is 32 bytes, giving the protocol a common recipient container across supported environments. An EVM address occupies 20 bytes, so conversion to bytes32 adds 12 leading zero bytes. The structure also carries a 32-bit destination endpoint ID, 256-bit amountLD, 256-bit minAmountLD, and three variable byte fields named extraOptions, composeMsg, and oftCmd. Taxi mode uses an empty, 0-byte command; bus mode uses a 1-byte command. The refund address remains a separate argument, so refund value and token delivery go to two independently specified addresses.

Tracking delivery to the chosen wallet

Delivery is verified by matching the source transaction, LayerZero message, destination token event, and chosen recipient on the destination chain.

A successful send returns a LayerZero messaging receipt with a 32-byte GUID, a 64-bit nonce, and fee details. Taxi mode dispatches the message immediately. Bus mode batches between 2 and 10 passengers, and its ticket identifier is a 56-bit value; a queue’s next ticket ID moving beyond that value indicates departure. These identifiers let the status view follow one message without treating the recipient as the sender. Arrival time still reflects source confirmation, message verification, executor delivery, and destination confirmation rather than a fixed timer.

For an ERC-20 destination, the Transfer event has three values: from, to, and value, with the first two addresses indexed. Match to against the custom recipient and read value using the token’s decimals. The source transaction proves dispatch, while the destination event proves that the selected account received the token balance.

Stargate app: reader questions