1inch availability is fusion+ Coverage Across EVM Networks and Solana

1inch availability is the set of source-and-destination networks where Fusion+ quotes and settles cross-chain swaps through linked escrows. The published scope spans Ethereum-compatible networks and Solana, while usable access rests on the selected token pair, amount, resolver liquidity, and a returned quote.

Every Fusion+ settlement links two escrows, so both endpoint deployments must support the requested assets.

Solana Extended Fusion+ Beyond an EVM-Only Map

Solana gives Fusion+ a non-EVM endpoint alongside a broad group of Ethereum-compatible networks.

The consistently listed core contains 13 networks: 12 EVM environments and Solana. Ethereum, BNB Chain, Polygon, Optimism, Arbitrum, Gnosis, Avalanche, zkSync Era, Base, Linea, Unichain, and Sonic share the EVM account model. Solana adds a different address system, token program, transaction format, and finality path. That split matters because cross-chain support isn’t a generic wallet feature. Fusion+ needs escrow logic, quoting, resolver execution, and token handling on both selected endpoints before a route appears.

This wider map makes EVM-to-Solana corridors the notable addition. It also makes network identity more important than a familiar ticker.

Where Does 1inch Fusion+ Work?

1inch Fusion+ works across a consistently listed core of 12 EVM networks plus Solana.

The first group includes Ethereum with chain ID 1, BNB Chain with chain ID 56, and Polygon with chain ID 137. These identifiers matter at quote time because each chain keeps separate balances, token contracts, and allowances. A USDC balance on Ethereum doesn’t become spendable on Polygon merely because both assets use the same ticker. The source field, destination field, and exact token address must describe one supported corridor before resolvers see an order they can price.

Optimistic and zero-knowledge rollup coverage includes Optimism at chain ID 10, Arbitrum at 42161, Base at 8453, Linea at 59144, Unichain at 130, and zkSync Era at 324. Fusion+ treats each as a separate settlement environment, even when ETH serves as the native gas asset, which is examined in 1inch requirements.

The remaining EVM endpoints are Gnosis at chain ID 100, Sonic at 146, and Avalanche at 43114. Their native assets and liquidity differ, so a route available from Avalanche needn’t exist from Gnosis for the same displayed symbol and amount.

Solana uses 501 as 1inch’s network identifier. It connects SPL-token and native-SOL routes to the EVM set through separate Solana escrow programs. Together, these endpoints define the stable core of 1inch availability for Fusion+.

Chain Coverage Isn’t Token-Pair Coverage

A listed network establishes an eligible endpoint, not blanket support for every asset or route direction.

The supporting detail is gathered in 1inch walkthrough. Fusion+ needs a valid source token, a valid destination token, and resolvers willing to settle the requested amount. Each EVM token is identified by a 20-byte contract address, while a Solana mint uses a 32-byte public key. USDC and USDT therefore remain network-bound assets even when an interface shows familiar symbols. Liquidity for the source swap, resolver inventory for the destination payout, and gas costs on both chains all enter the quote. When one component is missing, chain-level support alone doesn’t produce an executable corridor.

Direction matters as well. A quote from Base USDC to Solana USDC doesn’t prove the reverse route has identical depth or resolver participation. The returned quote is the decisive availability signal for one asset pair, amount, direction, and wallet context.

Fusion+ and Bridge Availability Use Different Dependencies

Fusion+ availability follows resolver-supported trading corridors, while bridge availability follows each bridge’s deployments and accepted assets. Wormhole exposes its own transfer and messaging paths, and Across Protocol quotes intent-based routes across its supported networks. Fusion+ links two escrows with a shared hashlock, then resolvers source the destination asset and include execution costs in the exchange rate. The user receives the selected destination token rather than relying on one universal wrapped representation. On the workflow dimension, a signed intent replaces manual bridge, destination-gas, and follow-up swap steps with two escrow deposits.

Chain Identifiers Keep Quotes on the Intended Network

Fixed network identifiers bind a Fusion+ quote to the intended source and destination environments.

A wallet’s network label is presentation. The chain ID or platform identifier is the machine-readable parameter used by the quoter, SDK, and signing flow. Five representative endpoints show where mismatches arise:

Ethereum uses EVM chain ID 1, while Arbitrum uses 42161 and Base uses 8453. A Fusion+ quote also binds token addresses, amounts, maker address, receiver, and chain IDs. An ERC-20 allowance exists inside one token contract on one network, so an approval on Ethereum doesn’t authorize the matching-looking contract on Base. Developers pass numeric identifiers into the Cross-Chain Swap SDK; wallet interfaces translate a human network choice into the same field. This layer rejects a familiar ticker when its routing context points elsewhere.

Native Coins and Token Standards Shape Endpoint Support

Token-format support determines whether a valid chain corridor accepts the selected source and destination assets.

EVM routes identify ERC-20 assets through 20-byte contract addresses, and native-coin orders use a separate native asset path. Ethereum, BNB Chain, and Avalanche each express native balances with 18 decimal places. Solana accounts use 32-byte public keys, while SOL uses 9 decimal places. Its token side includes the SPL Token program and Token-2022, although only supported Token-2022 extensions fit the Fusion+ escrow implementation. A symbol match can’t bridge these structural differences; the quote must resolve the exact contract or mint on each side.

Native ETH, BNB, AVAX, and SOL inputs don’t require manual wrapping for Fusion+. One ETH contains 10^18 wei, while one SOL contains 1,000,000,000 lamports. Amounts sent to the quoter must use the selected asset’s smallest unit, or the request describes the wrong trade size.

Resolver Participation Defines the Executable Corridor

Resolver participation turns a listed source-and-destination pair into an executable Fusion+ corridor. Resolvers compete through a Dutch auction, fund destination liquidity, pay gas on both chains, and recover their source-side asset through the linked escrow. They include that gas expense in the offered exchange rate. A route disappears when no resolver accepts the asset combination, direction, amount, and minimum return under present conditions. Availability therefore belongs to a specific quote, such as USDC from Base to Solana.

Why Does a Supported Fusion+ Pair Return No Quote?

A supported pair returns no Fusion+ quote when one required corridor input falls outside live resolver coverage.

The absence of a quote is narrower than network deprecation. It says the requested order can’t be priced and settled with the supplied parameters at that moment. Common causes include:

• A source or destination token address belongs to another network.
• The requested amount sits outside resolvers’ accepted fill range.
• Resolver inventory supports the opposite direction but not this one.
• An EVM address appears where the Solana endpoint expects a public key.
• A token’s transfer behavior or Token-2022 extension isn’t supported.

Re-selecting the network-bound asset fixes address mistakes. Adjusting the amount tests a different fill range, while reversing the pair tests a different corridor. If those inputs are correct, no quote means the route isn’t executable under the available resolver offers.

Solana - EVM Edge Cases in Secret Release and Recovery

Solana - EVM routes add address, publication, and finality differences without changing Fusion+’s paired-escrow settlement.

Fusion+ generates each escrow secret from 32 random bytes before hashing it for the order. A single fill uses one secret hash. Multiple fills use separate secrets whose hashes become leaves in a Merkle tree, allowing each completed fill to reveal only its assigned preimage. The client releases a secret after both escrows exist and the destination finality lock passes. That sequence connects availability to more than quote creation: both chain deployments must reach the state required for withdrawal.

The settlement has 3 operating phases - announcement, deposit, and withdrawal - plus an optional 4th recovery phase. It involves 2 principal roles: the maker signs the intent, and a resolver executes it. Timelocks return assets through cancellation paths when completion doesn’t occur.

A Solana-source order is published on-chain and announced to the relayer, whereas an EVM-source order follows the EVM signing path. Different finality locks reflect each network’s reorganization model before secret release. Partial fills also raise the secret count beyond 1, so clients must submit the matching secret for every ready fill. These edge cases preserve the same two-endpoint promise across Ethereum, Solana, and the other supported networks.