Metisnetwork bridge readiness depends on matching the asset to its supported destination

From Submission to Destination Receipt

Bridge submission starts a source-chain operation whose outcome remains distinct from the destination token balance. A wallet signature authorizes the proposed action. A transaction identifier names the submitted request without proving the network executed it. The source transaction record shows whether that operation succeeded. Destination receipt concerns the actual asset delivered to the intended address on the other network.

The canonical bridge issues supported representations for Ethereum deposits and handles redemption in the opposite direction. Andromeda processes Ethereum-originated bridge transactions through its sequencer infrastructure.

Deposit Assets and Destination Tokens

Ethereum deposits and Andromeda balances can use different token names, so destination expectations must follow the canonical mapping. The receiving network matters alongside the symbol. A matching ticker on another chain does not make that token a supported Ethereum deposit asset.

USDC and USDT

A canonical USDC deposit from Ethereum issues m.USDC on Andromeda. Ethereum USDT deposits produce m.USDT. Those destination tokens have their own contracts and balances. The mapping identifies the asset the receiving wallet should show; it does not make another project's similarly named token interchangeable.

ETH and METIS

Ethereum ETH deposits produce WETH on Andromeda. METIS also belongs to the supported canonical bridge assets, and Andromeda uses METIS as its native token. These relationships concern the Ethereum-Andromeda route. They do not establish support for every token a wallet displays or every network using an EVM-compatible address.

Andromeda as the Receiving Network

Andromeda and Hyperion are distinct networks within Metis, so a transfer intended for Andromeda must target Andromeda explicitly.

The canonical route described here connects Ethereum and Andromeda. Hyperion's Ethereum compatibility and performance architecture do not extend that route automatically. A transaction addressed to one network does not credit another network simply because both belong to the same ecosystem. The selected destination therefore determines which token balance the transfer can change.

Network selection also controls which records a wallet displays. The receiving address, network and token contract together identify the expected balance. Reading that address on Ethereum cannot establish its Andromeda token balance.

Can the Canonical Bridge Send Directly From BNB Chain?

The Ethereum-Andromeda canonical route requires a separate transfer to Ethereum before it can receive an asset starting on BNB Chain. LayerZero V2 can connect Andromeda with BNB Chain through an application's enabled pathway. That carries a different support condition from a canonical Ethereum deposit. An indirect route must support the asset on every leg, including its Ethereum representation before the final deposit. Finishing an earlier leg supplies a balance on that leg's destination; it does not establish receipt on Andromeda.

Funds, Gas and the Transfer Quote

Available funds must cover both the selected transfer amount and the transaction costs applicable to its source network. Ethereum transaction gas uses ETH, while Andromeda uses native METIS for ordinary transaction gas. A token other than the source network's gas token does not itself cover ordinary gas costs. If the interface separates fees from a receiving estimate, compare each amount in its stated unit.

The receiving estimate must also identify the destination asset. A quoted amount is not a balance already credited. Any minimum, maximum or expiry the chosen interface displays applies to that selection. Another bridge's amount limits or an old fee estimate cannot establish the terms of the current request.

Approvals, Recipient Data and Signing

Token approval grants spending permission without itself proving a cross-chain deposit or destination credit. An ERC-20 allowance lets the approved spender access a specified token balance within that allowance. If an allowance request appears, check which contract may spend the token and how much it may spend.

The request the wallet signs should agree with the selected asset, amount and receiving network. If the interface exposes a recipient field, its value must match the intended receiving address. A connected account does not override another recipient explicitly named in the signed request.

A bridge transaction also has a contract target and transaction costs. An unexpected spender, token or recipient changes what the transaction permits, so stop before authorizing that request.

Application-Specific LayerZero V2 Support

Readiness on the replacement LayerZero V2 services depends on the application's enabled pathway as well as the selected source and destination chains. Even on a covered chain pair, a send through the replacement services reverts if the application's pathway is not enabled.

Covered Chain Pairs

The replacement DVNs and Executor cover Andromeda pathways with Ethereum, BNB Chain and GOAT Network. Their coverage does not include Andromeda pathways to other chains. A route outside those pairs requires migration before the October 30, 2026 service cutoff.

Issuing Project Migration

Transfers of other projects' LayerZero-bridged assets, including USDe and FRAX, through the replacement services depend on the issuing project's pathway migration. The project's token and its enabled connection determine whether transfers can proceed. Canonical m.USDC or m.USDT support does not establish support for those separately issued assets.

Verification and Execution

A Decentralized Verifier Network, or DVN, verifies cross-chain messages, while an Executor handles destination execution. Successful message verification and successful destination execution establish different states. An application's transfer needs the services configured for its actual pathway; the availability of another project's working connection does not establish that configuration.

October 2026 Service Deadlines

Stargate support for Metis Andromeda ends on October 23, 2026. This cutoff covers Stargate V1 and V2. LayerZero Labs' DVN and Executor stop serving Andromeda on October 30, 2026. These changes concern the affected services and integrations; canonical bridge minting and redemption remain outside the shutdown.

METIS, HERA, QI and MTVT bridged to another chain through LayerZero V1 need to return before October 23, 2026. The return must use the same route used to leave Andromeda. After that date, those V1 routes lose support. Contact the Metis team about a missed V1 return deadline. Ordinary METIS holdings already on Andromeda carry no new return requirement from that cutoff.

Stargate Pool Exposure and Redemption

Stargate liquidity positions on Andromeda require withdrawal before October 23, 2026, while directly held canonical tokens have no new withdrawal requirement from this shutdown. A pool position and a wallet balance create different obligations even when they concern the same underlying asset.

V1 and V2 Positions

Affected Stargate V2 pools carry USDT, ETH and METIS labels. Affected V1 pools hold USDT, METIS and MAI positions. If LP tokens are staked, unstaking must precede redemption of the liquidity position. Releasing tokens from staking does not by itself withdraw the underlying pool assets.

Open full-size image

Liquidity-Dependent Withdrawals

Stargate withdrawals depend on available liquidity at the time of redemption. Assets left in Andromeda pools after October 23 can become difficult or impossible to withdraw through the normal interface. Waiting for the later global V1 closure would miss Andromeda's earlier deadline.

The V2 USDT pool uses m.USDT as its underlying asset, while the V2 ETH pool uses WETH.

Should I Wait or Retry After the Source Transaction Succeeds?

A successful source transaction does not justify resending the transfer; compare the source and destination records before deciding what remains. Waiting is appropriate while records show unfinished processing for a request whose route remains supported. Elapsed time alone cannot distinguish processing delay from a disabled application pathway.

If the route offers a recovery action, use it for the existing request. For a verified LayerZero V2 message whose destination execution failed, address that error before retrying. Use LayerZero Scan or the destination Endpoint contract's lzReceive call to retry that same message. A fresh deposit creates a different request. If the source operation failed, establish whether any transfer committed before considering another submission. An unsupported asset, incorrect destination or provider cutoff requires addressing that condition rather than assuming more time will finish the transfer.

An Ethereum transaction can consume gas even when its contract execution reverts. A lower ETH balance therefore cannot by itself prove the bridge accepted a deposit. Separate the gas charge from the token movement recorded by the transaction. Any new submission needs enough remaining funds for its current transaction estimate.

Another supported route can serve a new transfer only if it supports the source asset and intended destination. It does not change the destination of tokens already delivered. A missing LayerZero application migration needs project action; a missed V1 return deadline belongs with the Metis team. October 30, 2026 marks the affected LayerZero services' cutoff, not a universal canonical-transfer deadline.