Anyswap routes depended on token and destination liquidity

For Anyswap, the right route once depended on the exact token and the destination chain’s liquidity, but that choice is no longer live: the service ceased operations in July 2023. Before that, “router” and “bridge” described different ways to deliver an asset, with different outcomes for the token a user received. That distinction still matters when reading old transaction records or evaluating how cross-chain routes work, but a token listing or a displayed route cannot make the service operational today.

The protocol began as Anyswap and was later renamed Multichain. Its routing model offered a useful contrast: a liquidity route could pay out the destination chain’s underlying token from a pool, while a bridge route could issue a wrapped token there. The archived material associated with anyswap describes these as separate mechanisms. To understand a historical transfer, start with the pair of chains and token contract addresses, then identify which mechanism its configuration used.

That sequence is more reliable than choosing by ticker alone. A token called USDC, for example, may refer to different contracts on different chains; the same symbol does not establish that two assets are interchangeable or that a route is available. The transfer’s destination contract and the token representation received are part of the route decision.

How did Anyswap routes differ by token?

A router route drew on destination-chain liquidity to pay out the underlying token, while a bridge route locked an asset on the source side and minted a corresponding wrapped token on the destination side. Which options existed depended on the token and chain pair.

In the router model, destination liquidity did the practical work. If a pool held enough of the underlying asset, it could pay the recipient that asset directly. If liquidity was insufficient, historical router documentation says the transfer could instead leave the recipient with an anyToken liquidity-pool token to redeem later. That is a materially different outcome from receiving the underlying token immediately, even if the ticker looked familiar.

The bridge model followed a different path: an asset was held on the source chain and a wrapped representation was minted on the destination chain. The recipient therefore needed to check whether that representation was accepted for their intended use. A wrapped asset can track an underlying token without being the same contract or having the same acceptance across applications.

So token choice was not just “which coin?” It also meant asking which contract was being sent, what contract would arrive, and whether the pair supported a router, a bridge, or both. Those details explain why two routes that displayed the same ticker could have different liquidity needs and end states.

Why did destination liquidity matter?

For a liquidity route, destination liquidity set a practical limit on how much underlying token could be paid out at that moment. A route’s presence in a token list did not by itself prove that its pool could cover a particular transfer.

That creates a trade-off. A sufficiently funded router pool can deliver the canonical token directly, avoiding a separate redemption step. But pool balances can change, and a transfer too large for available liquidity could produce a pool token rather than the expected underlying asset. A bridge route instead depends on the bridge’s support for that token pair and on its wrapped-token mechanism; it does not use the same pool payout in the same way.

Before Anyswap’s shutdown, a careful route check therefore meant comparing the exact source and destination contracts, the route type, the quoted amount after fees, and the expected token on arrival. The destination balance mattered alongside nominal token support. If the interface showed a pool-token outcome, that should have been treated as a different delivery—not as a minor variation of the same route.

Can users choose an Anyswap route now?

No: the relevant change is that route choice is historical, not a current transfer decision. In July 2023, Multichain said it was forced to cease operations; users were told to stop using its services after abnormal asset movements and stalled transfers. A web page or token listing still visible today is not evidence that a route can safely complete.

For an old transaction, the useful checks are concrete:

• Confirm the source and destination chain and the token contract addresses.
• Identify whether the transfer used a pool router or a lock-and-mint bridge.
• Check the transaction outcome and the contract that actually arrived, rather than relying on a ticker or interface label.
• For any unresolved transfer or approval, consult current chain records and verified project notices before taking action.

These checks help explain what a historical route was designed to do; they do not restore the service. Anyone assessing another cross-chain route can apply the same questions: what exact asset goes in, what exact asset comes out, what liquidity or minting mechanism supports it, and what happens if the route cannot complete as quoted?

The signals that would change this assessment are an authoritative announcement that operations have resumed, working route status backed by current on-chain activity, and independently verifiable liquidity for the specific token pair. Until those signals exist, the sound conclusion is not to select between Anyswap routes: its former token and liquidity logic explains past transfers, but does not establish a usable route today.