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

# Solana routing

> Route assets from EVM chains to Solana and track delivery or refunds.

export const date_0 = "2026-09-12"

The Route API supports EVM → Solana transfers. Solana is a destination only, and each route ends with token delivery to the Solana receiver. Availability depends on the source chain and requested assets.

<Note>
  Solana's chain ID is `1861167595`. Use it only as `destinationChainId` in Route API requests.
</Note>

## How it works

```mermaid theme={null}
flowchart LR
    A["Source EVM transaction<br/>Optional swaps or position exits"] --> B["Bridge"]
    B --> C["Solana receiver<br/>Requested output token"]
```

Request a route with an EVM input asset and a Solana output token. Enso returns a transaction to sign and submit on the source EVM chain. Depending on the route mode, this transaction can include swaps or position exits before bridging.

The requested output token arrives at `receiver` on Solana. The receiver does not sign a Solana transaction for this transfer. Enso does not execute destination callbacks or compose additional actions on Solana.

## Request requirements

| Parameter                                                        | Requirement                                                                                                                  |
| ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| `chainId`                                                        | The supported source EVM chain ID.                                                                                           |
| <code style={{ whiteSpace: "nowrap" }}>destinationChainId</code> | `1861167595`, the current Enso identifier for Solana.                                                                        |
| `fromAddress`                                                    | The source EVM wallet address.                                                                                               |
| `tokenIn`                                                        | Exactly one source-chain asset address.                                                                                      |
| `amountIn`                                                       | Exactly one positive, fixed integer string in the input token's base unit. Dynamic amounts and placeholders are unsupported. |
| `tokenOut`                                                       | Exactly one case-sensitive Solana mint address, or the native SOL identifier below.                                          |
| `receiver`                                                       | An explicit, case-sensitive Solana recipient address.                                                                        |
| `refundReceiver`                                                 | An explicit, nonzero EVM address on the source chain for bridge refunds.                                                     |
| `slippage`                                                       | Slippage tolerance in basis points. `"50"` means 0.5%. Use this instead of `minAmountOut`.                                   |

Preserve the original case of Solana addresses throughout your integration, including requests, storage, and display. The Solana `receiver` and EVM `refundReceiver` are separate addresses on different chains.

## Example: Ethereum USDC to Solana USDC

Set `ENSO_API_KEY` to your Enso API key, `EVM_ADDRESS` to your source wallet, and `SOLANA_ADDRESS` to the recipient's Solana wallet address.

This request routes 100 USDC from Ethereum to USDC on Solana with 0.5% slippage.

```bash theme={null}
curl --request POST \
  --url https://api.enso.build/api/v1/shortcuts/route \
  --header "Authorization: Bearer $ENSO_API_KEY" \
  --header 'Content-Type: application/json' \
  --data @- <<EOF
{
  "chainId": 1,
  "destinationChainId": 1861167595,
  "fromAddress": "$EVM_ADDRESS",
  "receiver": "$SOLANA_ADDRESS",
  "refundReceiver": "$EVM_ADDRESS",
  "routingStrategy": "router",
  "tokenIn": ["0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"],
  "tokenOut": ["EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"],
  "amountIn": ["100000000"],
  "slippage": "50"
}
EOF
```

To receive native SOL, replace `tokenOut` with `["11111111111111111111111111111111"]`. This identifier belongs in `tokenOut`; `receiver` must still be the recipient's Solana wallet address.

## Submit the source transaction

1. Review the returned quote, including `amountOut`, `minAmountOut`, and `metadata.bridgeFees`. The request cannot set `minAmountOut`, but the response can include the calculated minimum.
2. For the `router` strategy used above, submit required `preTransactions` in order on the source chain and wait for each receipt. Skip a `tokenApproval` only when the existing allowance is sufficient.
3. Sign and submit the returned `tx` with the source EVM wallet, preserving its `to`, `data`, and `value`. Save the source transaction hash for status checks.

<Note>
  Source confirmation and Solana delivery are separate stages. A successful source transaction does not confirm that the recipient has received tokens on Solana.
</Note>

## Route modes

`crosschainRouteMode` controls whether Enso can add source-chain routing before bridging. It defaults to `"full"`.

| Mode                                          | Behavior for Solana destinations                                                      |
| --------------------------------------------- | ------------------------------------------------------------------------------------- |
| `"source"`, `"sourceOrDestination"`, `"full"` | Allow source-side EVM swaps or position exits before bridging into `tokenOut`.        |
| `"direct"`, `"destination"`                   | Bridge the requested input directly into `tokenOut`, without additional Enso routing. |

No mode enables Enso execution on Solana. In particular, `"destination"` does not enable a Solana callback or destination-side composition.

## Track delivery and refunds

Use `GET /api/v1/bridge/route` with the source EVM chain ID and source transaction hash. Poll every 30 seconds; in-progress results are cached for up to 30 seconds.

For the Ethereum example, set `SOURCE_TX_HASH` to the transaction hash saved after submission:

```bash theme={null}
curl --get https://api.enso.build/api/v1/bridge/route \
  --header "Authorization: Bearer $ENSO_API_KEY" \
  --data-urlencode 'chainId=1' \
  --data-urlencode "txHash=$SOURCE_TX_HASH"
```

The response includes an overall `status` and a `hops` array with each bridge transfer's details.

* `inflight` means the route has not completed.
* `delivered` confirms delivery. The Solana hop's `destinationTxHash`, when present, is a case-sensitive transaction signature.
* `failed` can represent a failed transfer or a refund. A refunded hop includes `refundChainId` and `refundTxHash` when the payout is available. The refund goes to `refundReceiver` on the source EVM chain.
* `unknown` means the checker could not determine the status. Inspect `traversal` and the entries in `hops` for available details.

## Unsupported features

* Routes originating on Solana.
* Explicit `minAmountOut` requests, including `"0"`.
* Intents, the `checkout` routing strategy, and destination fees through `destinationFeeReceiver`.
* Destination callbacks or composition, and public Solana Bundle API actions. Source-side composition uses the Route API.

<div className="text-right text-xs gray-200 font-semibold w-full" style={{marginTop: '0'}}>
  <p style={{
        color: "#b2b2b2"  
    }}>Updated {date_0}</p>
</div>