Why do older Stargate lists show different chain coverage?

Older lists can describe a different Stargate version or count only pool deployments. A list that includes Hydra representations or the interface's wider OFT ecosystem measures a different scope. Compare the version, asset set and meaning of support before treating different totals as evidence that a network has disappeared.

Are mainnet and testnet Stargate deployments interchangeable?

Mainnet and testnet deployments use separate token balances, contracts and endpoint identifiers. A successful testnet route does not establish availability for the corresponding mainnet asset. The source deployment and its configured destination must belong to the intended environment, even when the network labels or token symbols look similar.

Does a BTC label mean that a route transfers on Bitcoin mainnet?

A BTC asset label alone does not establish a Bitcoin-mainnet transfer. The route must identify its actual source network, destination network and token representation. The bridge's asset range and its chain coverage describe different properties, so a BTC-denominated token on another supported network cannot establish Bitcoin-mainnet connectivity.

How can an integration identify the asset that a StargatePool accepts?

The selected StargatePool's token() method identifies its underlying asset. An ERC20 pool returns the token contract address, while a native-coin pool returns address(0). Interpret that result on the pool's own network; the address alone does not identify an asset across every chain. This distinguishes the transferred asset from the pool contract itself.

Is every OFT in the bridge subject to the same security configuration?

A shared IOFT interface does not give every listed asset the same security configuration. Stargate-managed assets use the Stargate security stack. Issuer-owned OFTs and adapters use configurations that their issuers control, including verifier and execution settings. Interface compatibility therefore does not establish identical operators or trust assumptions.

Does Stargate support for IOTA EVM also cover IOTA L1?

Support must be established separately for IOTA EVM and IOTA L1. An EVM token deployment does not establish a compatible asset or transfer connection in the L1 environment. The relevant support belongs to the exact network and token instance that the route names, even when the environments share an ecosystem name.

What determines whether a source contract needs token approval?

For an ERC20 source asset, check the selected contract's approvalRequired() result and required allowance, including on mint-and-burn paths. Native-coin transfers supply the asset through transaction value, without ERC20 approval. Connecting the same wallet on another network does not substitute for the approval that a particular source contract requires.

Must a Stargate token have the same decimals on every supported chain?

Compatible Stargate v2 token deployments can have different local decimals while using the same shared precision. The protocol converts a source amount into shared units and reconstructs the destination amount in local units. Raw balance integers therefore need each token contract's decimal scaling before they represent comparable quantities.

Stargatebridge supported chains vary by token and transfer route

Stargatebridge supported chains include Ethereum, Arbitrum, Base and Avalanche, with documented v2 pools on each network. The available assets differ by chain. Hydra adds pool-backed token representations on other networks, while the bridge interface also serves issuer-owned Omnichain Fungible Tokens (OFTs). Compatibility depends on the source token, destination deployment and enabled pathway. A network that supports one asset or transfer mode does not automatically support every combination.

Last updated · Thu, 15 Oct 2026

Match the asset at both ends of the route

Start with the token that you hold and its source network, then identify the destination token that the receiving application accepts. A compatible path must connect those particular deployments. Choosing two chain names leaves the asset relationship unresolved, especially when the destination supports a bridged representation.

Pool-to-pool routes deliver the corresponding pool asset on the destination chain. A route into a Hydra contract delivers its backed OFT representation. An issuer-owned OFT follows that token's configured deployments. These options serve different receiving requirements even when their displayed symbols look similar.

Stargate v2 pools differ by network and asset

Documented v2 pool networks include Ethereum, Arbitrum, OP Mainnet, BNB Smart Chain, Avalanche, Polygon, Metis, Linea, Mantle, Base, Kava, Scroll, Aurora, Core, Sonic, Unichain, Gnosis and Soneium.

Ethereum, Arbitrum and OP Mainnet have documented v2 pools for USDC, USDT and ETH. BNB Smart Chain, Avalanche, Polygon, Mantle and Core list USDC and USDT pools. Base and Scroll list ETH and USDC pools.

Linea and Unichain list native ETH pools, while Kava lists a USDT pool. Mantle also has an mETH pool. These deployment entries describe particular assets; they do not establish support for every token on those networks.

Stargate pools can hold ERC20 tokens or the network's native coin. In pool transfers, native asset distinguishes the pool asset from a Hydra representation. The pool's transferred asset and the network's gas currency can differ.

Hydra support follows each token deployment

Hydra extends the network through StargateOFT contracts whose asset coverage can differ from the pool deployments on other chains. Its documented deployments include Kaia, IOTA EVM, Taiko, RARI Chain, Flare, Gravity, Berachain and ApeChain.

Hydra OFTs represent assets backed by Stargate pool liquidity. A pool-to-Hydra transfer locks the underlying pool asset and mints its representation. Transfers between compatible Hydra deployments burn and mint that representation. Redemption to a compatible native pool burns the OFT and releases the underlying pool asset.

Classification also changes within a network: Sei combines stablecoin pools with Hydra WETH. The selected token determines which contract model applies, so the network name alone cannot distinguish its pool transfers from its Hydra transfers.

LightLink and Abstract combine native ETH pools with Hydra stablecoins. Classifying either network entirely as a pool chain or a Hydra chain would hide the per-asset deployment model and its applicable credit conditions.

Can Stargate bridge to non-EVM chains?

The Stargate bridge interface supports OFT transfers across EVM and non-EVM environments, while Stargate v2 pool and Hydra contracts operate on EVM networks. The interface also supports Circle's Cross-Chain Transfer Protocol (CCTP). Availability follows the selected asset's transfer system and configured destinations. An issuer-owned OFT route can therefore appear alongside Stargate protocol assets without using the same liquidity contracts.

Configured connections determine the available direction

A token deployment needs a configured connection to its destination before it can transfer across networks. LayerZero endpoints supply messaging infrastructure, while the token application's peer configuration identifies the remote contract that it recognizes. For an OFT connection, the deployments must recognize the correct peers and have compatible messaging settings.

Those settings belong to the application operators; selecting a destination in a wallet cannot create a missing connection. The same interface can expose several token systems, so the selected asset determines which connection applies. A route between two pool deployments also has its own directional credit allocation. Its reverse direction can have different available capacity. Keeping the asset and direction fixed makes transfer quotes comparable, while changing the destination representation changes the receiving asset.

Why can a listed v2 route reject a transfer?

A listed v2 route can reject a transfer when its current credit, contract state or output conditions prevent that particular send, even though its deployments still exist. For finite-credit paths, v2 rejects an output amount that exceeds the available destination-path credit.

The Planner reallocates credits as demand changes, so a credit shortage differs from an unsupported token combination. The Path_InsufficientCredit error identifies the credit condition; it does not establish that the network has permanently lost support. A paused source contract blocks sends through that contract for a separate reason. Output protection creates another distinct rejection. Stargate checks the resulting token amount against the minimum that the sender specifies. An amount below that minimum triggers a slippage error. Increasing a tolerance cannot supply missing path credit or unpause a contract. The actual error determines which condition needs attention.

Transfer mode limits the destination operation

On compatible Stargate v2 routes, Bus and Taxi provide different transport options, while Taxi also supports a composed destination call. Bus batches transfers and does not trigger that callback. A destination application that requires a composed call therefore needs Taxi support as well as an available asset route.

View image file

A successful token transfer does not establish that a separate destination action succeeded. Transfer fees also depend on the selected mode and execution options, so those settings must match when comparing otherwise identical routes.

The destination balance needs the right form of gas

Receiving a bridged token does not automatically fund subsequent transactions that charge the destination network's native currency. An ERC20 balance alone does not establish that the recipient has native gas funds.

The v2 transfer interface offers an optional destination-gas setting where available. Bus permits the configured default amount, while Taxi permits a custom amount. For a subsequent transaction that charges native currency, the receiving wallet needs that currency balance alongside its bridged tokens. Native-coin source transfers also require enough source currency to cover the transfer amount and the native portion of the messaging fee, alongside transaction gas.

A return route needs its own compatibility check

If access to the underlying asset matters after bridging, compare the destination token form before committing the transfer. Hydra redemption provides a route back to native pool assets where compatible pools exist. Returning funds requires another transfer with its own route conditions and does not undo the original send.

If the destination requires the pool asset, select a route that delivers that exact asset.
If it accepts a Hydra OFT, identify a compatible pool destination for later redemption.
If a return transfer matters, check its direction separately from the outward route.
Treat the redemption mechanism as a design property and available credits and quotes as changing conditions.
Confirm the delivered token and amount in the destination transaction or receiving balance; the source signature alone does not establish receipt.

Changing the destination from a native pool to Hydra changes what the recipient holds and how it reaches native pool liquidity again. Confirmed token delivery does not establish the capacity or price of a future return transfer.

Endpoint identifiers distinguish the selected network

LayerZero endpoint IDs identify messaging destinations, while EVM chain IDs identify blockchain networks to wallets and applications. An integration must use the destination endpoint ID in Stargate's dstEid field, rather than substituting the wallet's chain ID.

For Arbitrum, the destination parameter uses LayerZero v2 endpoint ID 30110. The wallet identifies the same network through EVM chain ID 42161.

Still wondering about Stargatebridge supported chains?

Why do older Stargate lists show different chain coverage?: Older lists can describe a different Stargate version or count only pool deployments. A list that includes Hydra representations or the interface's wider OFT ecosystem measures a different scope. Compare the version, asset set and meaning of support before treating different totals as evidence that a network has disappeared.
Are mainnet and testnet Stargate deployments interchangeable?: Mainnet and testnet deployments use separate token balances, contracts and endpoint identifiers. A successful testnet route does not establish availability for the corresponding mainnet asset. The source deployment and its configured destination must belong to the intended environment, even when the network labels or token symbols look similar.
Does a BTC label mean that a route transfers on Bitcoin mainnet?: A BTC asset label alone does not establish a Bitcoin-mainnet transfer. The route must identify its actual source network, destination network and token representation. The bridge's asset range and its chain coverage describe different properties, so a BTC-denominated token on another supported network cannot establish Bitcoin-mainnet connectivity.
How can an integration identify the asset that a StargatePool accepts?: The selected StargatePool's token() method identifies its underlying asset. An ERC20 pool returns the token contract address, while a native-coin pool returns address(0). Interpret that result on the pool's own network; the address alone does not identify an asset across every chain. This distinguishes the transferred asset from the pool contract itself.
Is every OFT in the bridge subject to the same security configuration?: A shared IOFT interface does not give every listed asset the same security configuration. Stargate-managed assets use the Stargate security stack. Issuer-owned OFTs and adapters use configurations that their issuers control, including verifier and execution settings. Interface compatibility therefore does not establish identical operators or trust assumptions.
Does Stargate support for IOTA EVM also cover IOTA L1?: Support must be established separately for IOTA EVM and IOTA L1. An EVM token deployment does not establish a compatible asset or transfer connection in the L1 environment. The relevant support belongs to the exact network and token instance that the route names, even when the environments share an ecosystem name.
What determines whether a source contract needs token approval?: For an ERC20 source asset, check the selected contract's approvalRequired() result and required allowance, including on mint-and-burn paths. Native-coin transfers supply the asset through transaction value, without ERC20 approval. Connecting the same wallet on another network does not substitute for the approval that a particular source contract requires.
Must a Stargate token have the same decimals on every supported chain?: Compatible Stargate v2 token deployments can have different local decimals while using the same shared precision. The protocol converts a source amount into shared units and reconstructs the destination amount in local units. Raw balance integers therefore need each token contract's decimal scaling before they represent comparable quantities.