Cross-chain / Bridge·EVM · Bitcoin · Starknet · Solana · Multi-chain
Orbiter Finance
Cross-rollup bridge connecting 100+ Ethereum L1/L2/L3 networks plus Bitcoin, Starknet, zkSync, and Solana via a maker-relayer model and canonical-bridge fallback. Ships an Ultra Bridge product that lets teams deploy customizable native bridges on top of Orbiter's liquidity.
- 01cross-rollup ETH/USDC/USDT transfers
- 02Bitcoin <-> EVM transfers
- 03Starknet / zkSync / non-EVM L2 bridging
- 04white-label native bridges (Ultra Bridge)
- 05low-latency stablecoin rebalancing
- pnpm add @orbiter-finance/bridge-sdk viem
| Variable | Scope | Description |
|---|---|---|
| ORBITER_API_BASE | Client | Optional override for the Orbiter REST API base URL. Pin in production. Default: `https://api.orbiter.finance`. |
Orbiter is REST-API-first as of 2026 — the legacy JS SDK is marked outdated in their docs. Quote a route via `GET /quote` with `srcChainId`, `tgtChainId`, `srcToken`, `tgtToken`, `srcAmount` and read `expectValue`, `gasFee`, `withholdingFee`, `dealerAddress` (the maker address to send to), and `tradeFee`. Build the source-chain tx with `createTransfer` from the SDK — the return type varies by source: EVM yields a `TransactionRequest`, Bitcoin yields a PSBT, Starknet yields a `Call[]`. Crucially, the transfer amount must include a SECURITY CODE in its last 4 digits (a per-target-chain identifier appended sub-wei) — the SDK calls this `securityCode`/`tradingFee`. Track status via `GET /transaction/status?hash=...&srcChainId=...` until `status === 9` (success).
- ⚑Same security-code trap as Owlto: the LAST 4 DIGITS of the transfer amount encode the destination chain. Stripping/rounding the amount sends to the maker WITHOUT routing info and the funds will be refunded (best case) or stuck (worst case). Always submit the exact value returned by the SDK.
- ⚑The official JS SDK is explicitly marked OUTDATED in current docs; new integrations should call the REST API directly (or use the SDK only for the `createTransfer` builder, then submit through your own wallet).
- ⚑Maker (`dealerAddress`) liquidity per pair is bounded — quotes return `min`/`max` and amounts outside this range are rejected; handle this gracefully.
- ⚑Non-EVM origins (Bitcoin PSBT, Starknet Calls, Solana versioned tx) each need a chain-specific signer/wallet adapter — no single `signer.sendTransaction` works.
- ⚑Ultra Bridge deployments are separate per integrator; the public Orbiter pools and a customer's Ultra Bridge pools are NOT shared liquidity.
- ⚑Status codes are numeric and undocumented in some legacy docs (0=pending, 1-8=intermediate, 9=success, 99=failed). Always treat unknown codes as pending and re-poll.
- ⚑Maker-pays settlement means a sufficiently large outage on the maker side delays fills; surface the Orbiter support contact in your UI for stuck transfers.