SOL to Hyperliquid: bridges you can call from code

SOL to Hyperliquid: bridges you can call from code. The question keeps showing up in builder chats: is there a path from Solana into Hyperliquid that is not “open a website and click Deposit”? Yes — with caveats. This is the map of programmable options, what each actually settles, and how to verify before you hard-code a route.

Click to zoom

What “to Hyperliquid” means

Hyperliquid is its own L1. Trading collateral and spot live on HyperCore; general EVM contracts live on HyperEVM. Official onboarding still talks about an EVM wallet and collateral (especially USDC), with additional asset onboarding paths that can start from Solana-native assets and end as tradeable balance on Hyperliquid.

For an integration, be explicit about the destination:

• HyperCore — core trading / spot balances (Across lists this as chain id 1337 on the Swap API).
• HyperEVM — EVM RPC surface (999 on Across; deBridge also lists HyperEVM).

If your product needs “user can trade perps after one signature flow,” you care about collateral ending in the right HL account model — not only that a token appeared on some related chain.

The short chooser

Community shorthand you will hear: “HL ↔ Across integration,” “just use Jupiter or deBridge.” Those are not contradictory — they point at different layers of the same journey.

Across: one Swap API surface

Across markets itself as fast cross-chain infra with a single Swap API. Production base URL: https://app.across.to/api. You request a route; the response is approval + swap transaction data to execute. Settlement path is chosen under the hood.

For builders, the useful fact is on chains: live Swap API chain lists include Solana, HyperCore, and HyperEVM alongside the usual EVM L2s. The public UI has also pushed Hyperliquid-oriented routes (e.g. bridge flows into HyperCore with stable assets) — treat the API chain/token endpoints as source of truth for what your key can quote today.

Shape of an integration:

1. Get API key + integratorId from Across tooling docs.
2. GET /swap/chains and GET /swap/tokens for the origin / destination you care about.
3. GET /swap/approval with origin/destination chain ids, input/output mints or addresses, amount, depositor, trade type.
4. Execute returned approvals + swap tx (Solana vs EVM signing differs — use the chain’s native tx type from the response).
5. Track deposit status endpoints until filled.

# Illustrative — pin chain IDs and token addresses from live /swap/* responses
curl -sG "https://app.across.to/api/swap/approval" \
  -H "Authorization: Bearer $ACROSS_API_KEY" \
  --data-urlencode "tradeType=exactInput" \
  --data-urlencode "originChainId=SOLANA_CHAIN_ID_FROM_API" \
  --data-urlencode "destinationChainId=1337" \
  --data-urlencode "inputToken=..." \
  --data-urlencode "outputToken=..." \
  --data-urlencode "amount=..." \
  --data-urlencode "depositor=..." \
  --data-urlencode "integratorId=0x...."

Docs note Solana-aware fee recipients (base58) when you charge appFee on Solana destinations — a sign the API is multi-VM, not EVM-only. Still: quote failures mean the route is off, not that your HTTP client is wrong. Log the API error body.

deBridge DLN: intents and solvers

deBridge positions DLN as a 0-TVL execution layer: orders lock input on source, solvers fill on destination, contracts act as pipes not pools. Same API family covers same-chain and cross-chain. Solana is a first-class chain in supported-chain info; HyperEVM appears as well.

Typical programmatic loop (names vary slightly by doc version — follow current quick start):

• Estimate / create order with src and dst chains + tokens + receiver.
• Receive a ready transaction (EVM calldata or Solana VersionedTransaction).
• Sign and submit quickly (quotes go stale).
• Track order status until fulfilled.

Hooks (post-fill calls) matter if you need “bridge then do X on destination.” For pure “get USDC-like collateral onto HL-adjacent rails,” start without hooks and add them when the product needs composition.

Where Jupiter fits

Jupiter is the default Solana liquidity brain. Use it when the user holds SOL (or a random SPL) and your bridge leg wants a canonical stable or a specific mint. Ultra / Swap APIs give you quote → sign → land on Solana.

Jupiter does not replace a Hyperliquid deposit bridge. The clean mental model is:

Solana wallet asset → (optional Jupiter) → bridge API → Hyperliquid balance model.

If someone in chat says “use Jupiter or deBridge,” they often mean “Jupiter for the Solana hop, deBridge (or Across) for the cross-chain hop.”

Official deposit path (do not skip)

Before you promise users “one click from Phantom to perps,” read Hyperliquid’s own onboarding. The product still centers an EVM-style account model and lists concrete deposit assets and networks. Native Solana asset onboarding may exist for specific tickers and still ends as HL trading balance after their conversion flow.

Your bridge integration should end in a state HL recognizes as funded — verified with a test size on mainnet, not only a successful origin tx hash.

Suggested build path

1. Decide destination: HyperCore trading collateral vs HyperEVM contract balance.
2. Pull live chain + token lists from Across and/or deBridge; dump them into your repo as a fixture you refresh in CI.
3. Prototype the smallest quote: USDC-class on Solana → USDC-class on HyperCore (or whatever the API returns as supported).
4. Add Jupiter only if users start from SOL or long-tail SPL.
5. Build status UX (pending / filled / refund) — cross-chain support tickets are almost always “where is my money,” not “how do I sign.”
6. Mainnet dust test with a burn-in checklist: amount out, receiver, time-to-fill, fee total.

Honest limits

• Route availability changes. Cache nothing as permanent except your error handling.
• “Hyperliquid” in a UI label might mean HyperCore, HyperEVM, or a partner front-end — check chain ids.
• Flatmate-built private integrations exist in the wild; unless they publish an API and SLA, they are not your production dependency.
• Compliance and geo restrictions on perps venues are product constraints, not bridge-API parameters.

People and links

Resources

• Across introduction
• deBridge DLN overview
• Jupiter Metis binary (Solana routing)
• LI.FI cross-chain aggregation