> ## Documentation Index
> Fetch the complete documentation index at: https://docs.polygon.technology/llms.txt
> Use this file to discover all available pages before exploring further.

# Solana support

> How widget modes handle EVM and Solana origin and destination addresses, and the automatic chain syncing that keeps them aligned.

The widget supports cross-chain flows between EVM networks and Solana across the `Swap`, `Pay`, `Fund`, and `Withdraw` modes. The widget detects address type on both the funding side and the recipient side and aligns the origin and destination selections to whichever network the connected wallet and recipient can actually transact on.

This page is a reference for that behavior. No additional component props are required to enable it: connect a Solana-compatible wallet, paste a Solana recipient, or both, and the widget reacts.

## Supported widget modes

| Mode                                      | EVM ↔ Solana          | Notes                                                                                         |
| ----------------------------------------- | --------------------- | --------------------------------------------------------------------------------------------- |
| `Swap`                                    | Yes                   | Origin and destination both sync to match wallet and recipient address types.                 |
| `Pay`                                     | Yes                   | Recipient address drives destination chain and token.                                         |
| `Fund` (`EXACT_INPUT` and `EXACT_OUTPUT`) | Yes                   | Same recipient-driven destination sync as Swap.                                               |
| `Withdraw`                                | Yes                   | Same recipient-driven destination sync as Swap.                                               |
| `Earn`                                    | EVM destinations only | Earn keeps the destination strict: an EVM recipient is required when the origin is on Solana. |

Solana to Solana flows are unsupported. When one side of the trade is Solana, the opposite side's token and chain selectors hide Solana from the list of options.

## Origin and destination auto-sync

The widget keeps the origin and destination aligned with the connected wallet and recipient address. The behavior is automatic; integrators do not need to handle these transitions in application code.

### Recipient drives destination

When the recipient address changes, the destination token and chain switch to match the address type:

* A Solana recipient switches the destination to a default Solana token.
* An EVM recipient, while the destination is on Solana, switches the destination to a default EVM token and chain.

If a previously selected destination becomes invalid (for example, an existing Solana → Solana state), the widget repairs it by switching the destination back to a default EVM token where possible.

### Funding wallet drives origin

When a Solana-only wallet is selected as the funding wallet, the origin auto-selects SOL on Solana as a placeholder, then upgrades to the appropriate default origin token through the same default-token logic used elsewhere in the widget.

### Token-selector behavior

The `TokenSelector` and the full-screen chain list both respect disabled chains consistently. When a previously selected chain becomes disabled (for example, after a wallet switch makes it unreachable), the selector reflects the new state rather than keeping the stale value.

## Recipient validation

Recipient validation is symmetric across the two address types:

* A Solana recipient on `Swap`, `Pay`, `Fund`, or `Withdraw` is valid; the destination switches to a default Solana token.
* An EVM recipient on a Solana destination in those same modes is also valid; the destination switches to a default EVM chain and token.
* An EVM recipient on a Solana destination in `Earn` is rejected: Earn requires an EVM destination when the origin is Solana.

When the destination token is switched to Solana and no Solana-compatible wallet is connected, an existing EVM recipient is cleared and the recipient field resets to "Select recipient." This prevents the widget from submitting a quote against a recipient the destination cannot use.

## Recipients screen

The recipients screen separates connected wallets from address history:

* **Connected wallets** appear in their own section at the top of the picker, so users can pick a wallet they have already authenticated without retyping the address.
* Connected wallets are hidden from the **Recents** list to avoid duplicate entries.
* Pasting a valid address auto-selects it and returns to the previous screen.
* The recents list scrolls beyond four entries.

Picker-time validation is separate from submit-time validation. The widget applies picker-specific rules so that a user can browse and select recipients freely; final validation runs again when the quote is submitted.

## Funding-method UI

In the `Fund` flow, wallet addresses on the Fund Methods screen are now copyable. The funding-wallet row also no longer renders a chain badge: chain badges remain on token selectors but are dropped from the recipient-address and funding-wallet rows to keep those rows focused on the address itself.

For chain badges that do appear elsewhere in the widget, behavior is unchanged.

## Related references

* [Swap component](/cross-chain/sdk/swap)
* [Pay component](/cross-chain/sdk/pay)
* [Fund](/cross-chain/fund)
* [Withdraw component](/cross-chain/sdk/withdraw)
* [SDK configuration](/cross-chain/sdk/configuration)