Solana routing

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.

Solana’s chain ID is 1861167595. Use it only as destinationChainId in Route API requests.

How it works

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.
`destinationChainId`	`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.

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

Review the returned quote, including amountOut, minAmountOut, and metadata.bridgeFees. The request cannot set minAmountOut, but the response can include the calculated minimum.
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.
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.

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

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:

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.

Updated

Build

Examples

Reference

How it works

Request requirements

Example: Ethereum USDC to Solana USDC

Submit the source transaction

Route modes

Track delivery and refunds

Unsupported features

​How it works

​Request requirements

​Example: Ethereum USDC to Solana USDC

​Submit the source transaction

​Route modes

​Track delivery and refunds

​Unsupported features

How it works

Request requirements

Example: Ethereum USDC to Solana USDC

Submit the source transaction

Route modes

Track delivery and refunds

Unsupported features