Solana support

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

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
• Pay component
• Fund
• Withdraw component
• SDK configuration