Cross-chain / Bridge·EVM · Multi-chain
Owlto Finance
Fast cross-rollup bridge specializing in low-cost ETH and stablecoin transfers between Ethereum L2s and L3s (Arbitrum, Optimism, Base, Scroll, Linea, zkSync, Mantle, Taiko, Blast, etc.). Maker-relayer model: users send to a maker address on the source chain and receive on the destination within seconds.
- 01fast L2 <-> L2 transfers (seconds)
- 02low-fee ETH and USDC bridging
- 03cross-rollup UX in consumer apps
- 04100+ Ethereum L2/L3 coverage
- 05aggregator backends needing a cheap rollup leg
- pnpm add owlto-sdk viem
| Variable | Scope | Description |
|---|---|---|
| OWLTO_API_BASE | Client | Optional override for the Owlto bridge API base URL (defaults to `https://owlto.finance/api/bridge_api/v1`). Pin in production. |
Use the Owlto bridge API directly or via `owlto-sdk`. Discover supported routes with `GET /api/bridge_api/v1/get_all_pair_infos` (returns per-pair `min`/`max`, `fee`, `dtc` time-to-confirm, and the maker address). Build a transfer with `bridge.getBuildTx({ fromChainName, toChainName, token, amount, fromAddress, toAddress })` — this returns `txs.approveBody` (if ERC20) and `txs.transferBody` (the transfer to the maker address with a sub-wei amount suffix that encodes the destination chain ID). Submit both through viem/ethers. Poll `bridge.getReceipt({ fromChainName, txHash })` until status is `success` and the destination tx hash is returned. The crucial detail: the LAST DIGITS of the transfer amount encode the destination — do NOT round or strip them.
- ⚑Owlto encodes the destination chain in the LAST DIGITS of the transfer amount (a sub-wei suffix). Stripping or rounding the amount BREAKS the bridge — the maker will refund or, worse, the funds may be stuck. Always send the exact `transferBody.value` returned by `getBuildTx`.
- ⚑Maker liquidity is finite per chain pair; transfers above `max` (or below `min`) are silently rejected by the maker — pre-validate against `get_all_pair_infos` and fall back to canonical/aggregator bridges.
- ⚑There is NO on-chain settlement contract; this is a maker-pays model. If the maker is offline or under-collateralized, fills are delayed and you must rely on Owlto's centralized refund flow — surface the support link in your UI.
- ⚑Maker addresses change per chain pair and are rotated periodically — never hard-code; always read `makerAddress` from the API response at quote time.
- ⚑Fees are quoted as a fixed amount per pair (not a bps), so small transfers are uneconomical — display effective rate to users.
- ⚑Receipts are eventually consistent; `getReceipt` may return `pending` even after the destination fill confirms on-chain — also check the destination chain explorer for the maker's outbound tx.