Layerswap supported networks show which routes fit before a transfer is submitted

Compatibility begins with a complete route

Route compatibility is the intersection of several selections, not a property attached to one network name. A usable path is directional, connects two token records, accepts the requested amount, and supplies a funding method.

• The source network identifies where the funds currently exist.
• The source token identifies the asset record that will be sent.
• The destination network identifies the intended receiving environment.
• The destination token identifies what the route will deliver.
• The amount must fall within the bounds returned for that combination.

Changing any one of these inputs creates a different route check. Keep the request unfunded while the selections are still moving, then require a quote that repeats the combination you intend to use.

The source side

The source must match the wallet, account, or transfer method that actually holds the asset. A familiar network label isn’t enough if the selected token record or funding method belongs to another environment. Read the returned network and token together.

The destination side

The destination combines a network, a token record, and a receiving address. Those fields need to agree before the address is used. A destination that accepts one token doesn’t automatically accept another asset with the same ticker or branding.

The amount and availability

Amount is part of compatibility because routes can expose minimum and maximum bounds. Read the route’s bounds, then enter the amount in the standard quote request; don’t infer amount compatibility from a general list of networks.

Direction changes the answer

Source and destination availability are separate. Route discovery can narrow sources by a selected destination network and token, while destination discovery can narrow the other side by the chosen source.

A network may appear as a source for one pair yet be absent as a destination for that same-looking selection. This doesn’t create a contradiction. It means the current discovery response doesn’t report an executable connection in both directions. Reverse the selection only by running a new lookup and obtaining a new quote.

Because one selector constrains the next, an interface should clear dependent choices whenever the upstream network or token changes. Keeping an old destination token visible after a new source selection can make an impossible pair look ready. Rebuild the dependent options from the filtered response before asking for a quote.

Network records carry more than a display name

The returned record separates a readable label from an internal network name, chain identifier, network type, and token metadata. Together, those fields prevent similarly named environments from being treated as interchangeable.

The network endpoint returns token records with each network. Source and destination queries then apply the opposite side’s selected network and token as filters. This relationship is more useful than a static list because it shows which combinations can connect.

Network type also helps an integration choose the correct address rules and wallet adapter. It remains a classification, not proof that every token, amount, direction, or deposit method works on every member of that family.

Internal values should remain intact even when an interface shortens a display label. Chain identifiers that name a network are identifiers, not quantities, and should be stored exactly as returned. This matters when multiple environments share branding but use different transaction rules.

Token support is network-specific

A token symbol alone can’t establish compatibility. The route data can distinguish a token by its network, display asset, contract when applicable, decimal precision, and internal grouping. Match the returned record instead of relying on a logo or ticker.

Native assets may be represented without a token contract, while contract-based assets need the identifier returned for that network. Don’t fill a missing contract field with an address copied from another chain. The surrounding network metadata determines how that record should be interpreted.

The source token and destination token are separate route inputs. They may represent the same asset form or different accepted outputs, but the connection must explicitly support the chosen pair. Two individually listed tokens don’t prove that a conversion exists between them.

A current quote tests the selected route

A quote request requires the source network, source token, destination network, destination token, and amount. A successful response ties availability to those inputs and returns the expected output, lower output boundary, fee data, rate, path, and estimated completion field for that request.

Some deposit flows allow swap creation without a quote. When you request one, use it as a consistency check rather than a permanent promise. If a selection changes, request another quote and compare the returned route fields with the new choice. An error or empty response isn’t a valid quote. Check authentication and request validity before deciding whether the route itself is unavailable. Either result says nothing about the network as a whole.

Detailed quote data can describe candidate paths and their minimum and maximum amounts before the final amount-specific request. It helps narrow the choice, but it doesn’t replace the fresh quote that reflects the amount and settings the reader intends to submit.

Limits qualify an otherwise valid pair

A route can support both network endpoints and both tokens while rejecting a particular amount. Detailed route data can expose minimum and maximum amounts for the selected path, so the amount has to be tested against the current bounds.

View full-size image

Those limits belong to the route, not to the token everywhere. Decimal precision also controls which amount can be represented correctly. If the amount falls outside the returned range, change it only within a fresh request. Splitting a transfer shouldn’t be assumed to bypass a limit, because each part needs its own valid route and quote.

Alternative provider paths may carry their own bounds and quote results. Don’t combine a limit from one path with the expected output from another. The selected path, amount range, and delivered value need to come from the same response.

Deposit methods shape the source action

Network support includes the way funds can enter the swap. Returned network data can list deposit methods, and a created swap can supply ordered deposit actions with a destination, amount, base-unit amount, network, token, fee token, and call data where applicable.

Connected-wallet funding

A connected wallet should be on the selected source network and control the asset being sent. The transaction preview needs to agree with the active route. Connecting a wallet doesn’t add a missing route, widen its amount limits, or make a mismatched token compatible.

View full-size image

Instructions supplied by the swap

Manual funding depends on the address and amount generated for that particular request. Copy both from the same active record and preserve the swap identifier. Instructions from an older or changed selection may point to a different route state and shouldn’t be reused.

Destination details complete the compatibility check

A route isn’t ready until the receiving details fit the selected destination network. Address validation should use that network’s format and the destination recorded for the active swap, rather than a visually similar address saved for another environment.

A valid-looking address doesn’t prove that the intended recipient controls it, and a quote doesn’t provide that proof either. Confirm control through the receiving wallet or application before commitment. Displaying the destination network beside the address reduces the chance of approving the correct string in the wrong context.

Some address formats can look alike across different environments, so syntax alone may not expose a wrong-network selection. Keep the network label or identifier visible with the recipient during confirmation, and compare both fields with the destination recorded in the quote.

Unavailable and unmatched entries aren’t executable routes

Discovery calls can include unavailable or unmatched records when those optional filters are enabled. Their presence expands what an integration can inspect; it doesn’t turn those records into funded routes.

An unavailable entry should remain disabled until a new response reports a usable connection. A cached result, screenshot, or previous quote can’t change its state.

An unmatched entry still lacks the compatible counterpart needed for execution. It may help explain why a network or token appears in discovery without producing the requested connection.

Retry only after changing a relevant input or refreshing live data. The decision changes when the complete combination returns as available and produces a valid quote, not when one network name reappears by itself.

Commit only against a fresh match

The final check is consistency across one request. Source network, source token, destination network, destination token, amount, receiving address, limits, deposit method, and quoted output should all refer to the same route state.

Preserve the quote details and swap identifier before submitting the source transaction. If any selected field changes first, discard the old funding instructions and request new ones. Once the source transfer has been submitted, a compatibility mistake is no longer a reversible route choice; follow the swap status and any available recovery path instead. Network support has a practical limit: it applies only to the exact combination that the active request accepts.