AnySwap Must Be Verified Before Any Commitment

The correct decision is to give AnySwap no new approval, signature, or bridge deposit until the live interface, exact contract address, transaction simulation, and destination asset all match independently verified records. The name is historical: Anyswap announced its rebrand to Multichain in December 2021. This answer holds whenever a site using the AnySwap name asks a wallet to commit assets or permissions.

Technical fact	What must match before action
Protocol identity	The displayed name, official domain, contract publisher, and current operating status.
Origin network	The wallet’s selected chain, token contract, amount, and available gas token.
Destination asset	The destination chain and the exact token contract—not just its ticker, icon, or displayed balance.
Wallet request	Whether it is a transaction, an ERC-20 approve, or an EIP-2612 permit signature.
Spender and recipient	The contract receiving permission and the address receiving the resulting asset.
Route economics	Protocol fee, swap fee, network gas on both sides, minimum received, and any route expiry.

What must be true before AnySwap receives a commitment?

Four checks must pass together. First, the name must resolve to a documented protocol history and a current operator; a familiar brand label is not identity. Second, the wallet must show the intended network before anything is signed. Third, the contract address must match an authoritative record for that chain. Fourth, the transaction preview must state an amount, recipient, and permission scope that make sense for the intended transfer.

A bridge is not merely a payment form. It is an interoperability system that moves an asset or its representation between separate networks; Ethereum’s bridge guide describes bridges as a way to move assets across blockchains for different applications and ecosystems. That basic bridge model is why the origin chain, destination chain, and resulting token contract are all part of the decision, not background details.

Which technical facts should be read before the wallet popup appears?

Read the route before connecting the wallet. A usable route names the source token contract, the destination token contract, the networks, the expected output, and each fee category. “USDC to USDC” is incomplete: the same ticker can represent different contracts, issuers, bridged versions, or wrappers. The contract address is the identifier that settles the question.

Then separate a transfer from a permission. An ERC-20 allowance is the amount a token holder authorizes a spender to withdraw through transferFrom; it can outlive the bridge transaction. If the interface requests an unlimited amount when a limited amount would complete the stated task, the efficient response is to stop, not to rationalize the difference.

Also inspect chain IDs in the wallet and the block explorer. A legitimate-looking contract address on the wrong network is still the wrong destination. The same applies to a native token versus an ERC-20 representation: a route can complete exactly as coded while delivering an asset that cannot be used where the user intended.

Why does the AnySwap name change the first check?

The historical identity must be resolved before technical convenience matters. The project’s December 16, 2021 announcement states that Anyswap rebranded to Multichain. It also said that the original Anyswap site would no longer be updated.

“Anyswap is pleased to announce that from now on, Anyswap shall be known as Multichain.”

— Multichain, December 16, 2021

That history makes “official-looking” an inadequate test. A user should seek a current, independently corroborated statement of who operates the interface, what contracts it uses, and whether the route is active. A domain, search result, social post, or old tutorial cannot supply those facts by itself. Before any signature, the reader can inspect the displayed networks, contract details, and route information in the AnySwap interface; if those details cannot be verified elsewhere, no commitment is justified.

What does an approval or permit actually allow?

An approval is not a harmless preparatory click. Under ERC-20, approve lets a specified spender withdraw up to the approved amount, while allowance reports what remains available to that spender. The shortest safe path is to approve only the amount required for the transaction, then confirm that the spender address is the contract expected for that route.

Why is a typed signature still a commitment?

A permit is a signed authorization that changes an ERC-20 allowance without the usual on-chain approve transaction. It can feel like a login because it is signed off-chain, but the signed fields still matter: owner, spender, token, value, deadline, chain ID, and verifying contract. The signing screen should be read as carefully as a transaction screen. A vague request, an unexpected spender, an excessive value, or a distant deadline is enough reason to decline it.

Can a low fee quote outweigh the bridge’s trust model?

No. Fees answer the cost question; the bridge design answers the custody and execution question. Trusted bridges depend on an operator or external system, while other designs rely more directly on smart contracts and underlying-chain verification. Ethereum’s overview notes that bridge designs carry smart-contract, operational, custody, and user-error risks, and that trusted designs introduce additional trust assumptions. Those bridge trade-offs should be evaluated before comparing a few dollars of gas.

History reinforces the point. Chainalysis reported that Multichain experienced unauthorized withdrawals exceeding $125 million in July 2023 and that the team later announced it had ceased operations. The reported cessation and withdrawals are facts to weigh before treating an AnySwap-branded route as routine infrastructure.

How should the user verify the thing that actually moves funds?

1. Open a trusted block explorer for the selected origin chain and confirm the token and spender contracts character by character.
2. Run the smallest practical test only after the route, allowance, and destination token have been verified; record the transaction hash and confirm the received asset on the destination chain.
3. Revoke or reduce any allowance that is no longer needed, then repeat the check before a larger transfer because contracts, interfaces, and route conditions can change.

A test transaction is not proof that a later transaction is identical. It proves only the precise route, contracts, amounts, and wallet state used in that test. The next transaction still deserves a new preview.

When is the decision settled?

The decision is settled when identity, current status, contract addresses, wallet request, destination asset, and full fee path agree—and when a small verified route behaves as expected. If any one of those checks is missing, the efficient choice is to keep the wallet disconnected and commit nothing.