Stargate app is a route preview before cross-chain signing

Stargate route previews versus Across Protocol intent quotes

Stargate route previews expose transport mechanics, whereas Across Protocol quotes express a relayer-filled outcome for the same transfer intent. Both show input, output, fees, and expected timing, but they reach the destination through different systems. A matching output amount does not make the settlement path equivalent.

The table separates durable mechanics from changing availability. The Stargate app only presents routes that match the selected asset mesh, networks, amount, and available pathway capacity. Circle CCTP applies specifically to native USDC, while an OFT route follows the mesh configured by its issuer. Across Protocol uses an intent and relayer model. The next screen still needs an amount-level reading because fees and capacity are calculated for that exact request.

Reading estimated output before wallet confirmation

Estimated output states the token amount expected at the destination after route deductions, before source-chain gas is paid. The input and output also belong to separate chain contracts, so matching ticker text does not prove an identical representation. Anything left over is addressed in Stargate explainer.

Normalize the token units

USDC uses 6 decimal places on its established EVM deployments, making one USDC equal to 1 000 000 base units. A displayed amount of 10 USDC therefore corresponds to 10 000 000 units in contract calldata. ETH and WETH use 18 decimal places, with one ETH equal to 10 ¹⁸ wei. The interface converts these integers for human reading, but the wallet ultimately signs integer amounts. Decimal precision explains formatting; it does not identify the destination contract. Each conversion preserves the token's smallest-unit accounting exactly.

Separate output from network gas

The destination amount reflects the asset delivered by the route. Source gas is paid separately in ETH or another native network token, while an optional destination native-token drop appears as its own route component. Read those values independently.

Once the units agree, the transport label explains when and how that amount moves.

How do Fast Taxi and Economy Bus differ?

Fast Taxi sends one transfer immediately, while Economy Bus waits to combine compatible transfers into one batch. Taxi prioritizes dispatch speed; Bus distributes messaging and destination execution costs across passengers on the same pathway.

A Stargate V2 Bus is configured for a batch of between 2 and 10 passengers. It departs when its seats are paid for or its configured maximum wait is reached. A user may also pay for the remaining seats to drive the Bus. The estimated departure time therefore describes batch progress, not source-chain confirmation speed.

Taxi carries one transfer in one message and supports destination composability. Bus does not execute a composed call after arrival. That boundary matters when a route must do more than deliver the asset, such as invoke a destination contract. For a plain USDC transfer, the visible choice remains cost sharing versus immediate message dispatch.

Fees that move between preview and signature

The displayed fee changes with source gas, destination execution, LayerZero messaging, route demand, and any native-token drop. One basis point equals 0.01%, and 100 basis points equal 1%, which makes percentage deductions comparable with token-denominated output.

The app's estimate combines values with different causes. Source gas follows the selected network, LayerZero workers quote message verification and execution, and Stargate pathway fees respond to credit conditions. A Bus passenger shares the batched message cost, while Taxi pays for a dedicated message. Fee inputs can move after the preview loads, so a refreshed destination amount replaces the earlier quote. Compare the final minimum received rather than subtracting a stale fee line from the original input. This comparison uses two snapshots: the displayed quote and the transaction that the wallet is preparing.

Recipient, token, and chain checks

Recipient, token contract, and destination network must describe the same intended endpoint before the wallet prompt opens. Advanced transfer mode permits a custom destination address, while simple mode reuses the connected account.

Recipient encoding

An EVM address contains 20 bytes. Its conventional hexadecimal form uses 40 digits after the 0x prefix, producing 42 visible characters. Stargate's transfer parameter stores the recipient in a 32-byte field, so an EVM address is padded for cross-chain encoding. A custom recipient receives the destination asset, even when a different account signs the source transaction.

Network identity

Chain identity prevents a familiar address from being read in the wrong network context. Ethereum uses chain ID 1, Optimism uses 10, Polygon uses 137, Base uses 8453, Arbitrum One uses 42161, and Avalanche C-Chain uses 43114. These identifiers name networks; they do not guarantee that one token contract has a route between every pair.

Once token, chain, and recipient agree, the next decision concerns destination gas.

What does destination gas change?

Destination gas adds native tokens for the recipient's next transaction; it does not increase the bridged asset output. It is useful when the destination wallet lacks enough native currency for a swap, approval, or contract call.

At contract level, a Bus ride records native drop as one Boolean choice: enabled or disabled. Taxi uses LayerZero execution options and supports a custom drop amount. The user interface translates those controls into a simpler selector, then includes the added delivery cost in the quote. The destination balance and the destination gas amount remain separate assets. Sending USDC to Arbitrum One, for example, leaves USDC as the route output and ETH as the gas asset.

Slippage and minimum output at the signing boundary

Minimum output converts the previewed destination amount into a hard lower bound inside the signed transfer parameters. If the executable quote falls below that amount, the contract does not complete the send on those terms.

At the other end, Stargate V2 uses amountLD and minAmountLD as 256-bit unsigned integers in local token decimals. For 6-decimal USDC, the smallest base unit equals 0.000001 USDC. The quote function calculates the received amount after route-level fees or rewards, and the interface derives the minimum from its tolerance setting. This protects an amount boundary even though V2 performs same-asset transfers such as USDC to USDC.

Treat a changed minimum as a new route decision rather than a cosmetic refresh.

Approval and transfer signatures

An ERC-20 route may require an approval transaction before the transfer transaction, producing two separate wallet prompts. An existing sufficient allowance removes the first prompt, while a native asset has no ERC-20 approval step.

The allowance prompt

ERC-20 allowances use a 256-bit unsigned value. The approval names a token contract, a spender, and an amount; it does not perform the cross-chain transfer. An exact allowance matches the planned input, while a larger allowance remains available for later calls until it changes. MetaMask and Rabby display this source-chain contract interaction separately from the send.

The transfer prompt

The transfer prompt calls the route contract with the destination endpoint, recipient, input amount, minimum output, and transport command. It also carries the quoted messaging fee in the source network's native token. Taxi uses an empty transport command, whereas Bus uses a one-byte command. Native ETH follows the send path without an ERC-20 allowance transaction.

Count the prompts shown by the route, then match each one to its stated purpose.

What happens after a Bus route is chosen?

After you sign a Bus route, the source transaction creates a ticket and waits for the selected batch's departure. The source-side settlement succeeds before the shared LayerZero message leaves for the destination.

The V2 ticket stores a 56-bit ticket identifier alongside passenger data. Queue state advances through the next ticket identifier; once that value passes the user's ticket, the Bus has departed. A non-final passenger sees the source transaction first, while LayerZero Scan gains the cross-chain message after dispatch. The app's transaction tracker connects those stages for the same transfer.

Full seats or the configured maximum wait trigger departure, and paying for the unfilled seats triggers it earlier. The useful post-signing question is whether the ticket exists, the Bus has left, or destination delivery has completed.

The quote path under LayerZero V2

LayerZero V2 carries the message, while Stargate contracts calculate asset limits, received amount, and transport-specific fees. The app turns those contract reads into the route card shown before signing.

A Stargate SendParam contains 7 fields: a 32-bit destination endpoint, a 32-byte recipient, two 256-bit amount fields, and three dynamic byte fields for options, composition, and transport. quoteOFT calculates transfer limits and received amount, while quoteSend aggregates the messaging fee. The wallet signature then submits send with the same parameters and a refund address. Changing the amount, recipient, route mode, or destination requires those calculations to run again.

A final route-review sequence

The final review should reconcile six relationships before the Stargate app hands control to the connected wallet. Match source chain to gas balance, input ticker to contract, destination ticker to representation, recipient to network, estimated output to minimum output, and route mode to timing.

Read the preview from assets to execution. The token pair establishes what moves, the route card establishes how it moves, and the wallet prompts establish which source-chain calls authorize it. If any input changes, let the interface rebuild the quote and repeat that reading from the destination amount onward. When those fields agree, the wallet signature confirms a route that is already understood.