Bridge

Cross-chain token movement. Bridge routes differ from swap routes in a way that matters to users: they trade off against each other on three axes, not one.

Route: /defi/bridge · Source: defi-dex/src/pages/defi/bridge.tsx · Fee: 0.1% of input

What it does

The user picks a source chain and token, a destination chain and token, and an amount. The app quotes every bridge-capable provider in parallel and shows the routes side by side so the user can choose on:

• Price — output amount after the bridge's own fees.
• Speed — estimated time to finality on the destination.
• Trust assumptions — a canonical bridge, an optimistic bridge, a liquidity network and an intent solver have genuinely different risk profiles, and users with size care about that.

Then one approval and one signature, same as a swap.

Bridge providers

Provider	Model	Notes
Across	Optimistic / relayer-filled	Usually the fastest for supported pairs
deBridge	Liquidity network
LiFi	Meta-aggregator	Aggregates other bridges itself
Squid Router	Axelar-based	Backend-proxied (integrator id)
Rango	Meta-aggregator
Symbiosis	Cross-chain AMM	Excluded from the swap path, included for bridge
XY Finance	Cross-chain aggregator
Relay	Intent solver	Fills asynchronously — see the caveat below
Nordstern	Intent solver	Same caveat
Near 1Click	NEAR intents
RhinoFi	L2 bridge	Multi-step: quote → commit → calldata
GasZip	Gas top-up	Small native amounts to a fresh chain
Houdini	Privacy-oriented
ChangeNow / Changelly	Custodial exchange	Deposit-address model
Kima	Custodial	Currently disabled (backend origin returning 520)
Butter Network	Cross-chain	Excluded from bridge path by default

Full table with endpoints and proxy status: providers.

Default bridge excludes

bz-backend/services/swap.service.js excludes these from the bridge fan-out by default:

Excluded	Reason
icecream_swap	Same-chain only
one_inch	Same-chain only
butter_network	Excluded by default
open_ocean	Same-chain only

Bridge-into-only destinations

A chain can be a bridge destination without having a BlazpayRelayer deployment. Adding one requires only:

1. A Network record and at least one Token record, seeded from LiFi's chain/token data.
2. A production cache bust.

You then get "bridge into this chain" without swap or bridge-out support. Robinhood Chain (4663) was added this way; it has since had a relayer deployed too, so it now supports both directions. Procedure: add a chain.

Route comparison caveat — solvers deliver nothing in-transaction

Intent-based providers (Relay, Nordstern) do not produce output inside your transaction. They take your funds and a solver fills the order moments later, off the critical path.

This is fine for an interactive bridge, where the user watches a status poll. It is not fine for automation: the DCA and Autopilot vaults measure the balance delta inside the transaction, see zero, and correctly revert with OutputBelowMinimum. That is why the automation path route-probes every candidate with estimateGas before selecting one. See execution engine.

Nordstern in particular

nordstern returns calldata whose selector is 0x57f96440… and delivers zero output in-transaction. If you see a vault revert with OutputBelowMinimum and the route was Nordstern, that is working as intended — the probe should have filtered it out earlier.

Status tracking

Bridges are not atomic, so a bridge transaction has two lifecycles: source-chain confirmation and destination-chain delivery.

Mechanism	Where
Per-provider status endpoint	swap-sdk routers map in utils/constants.ts; getTxStatus(chainId, hash) per aggregator
Backend refresh sweep	GET /defi/txn/:walletAddress re-checks pending transactions for that wallet
Background cron	bz-backend/services/bridgeStatusCron.js
Status update endpoint	PATCH /defi/transaction/update
Qube-specific completion	POST /defi/bridge/qube

History surface: /defi/bridge-history.

Deep links and SEO

Bridge corridors have their own prerendered landing pages: /bridge/{from}-to-{to} covering four top sources × ten emerging destinations plus fifteen major pairs. BridgeRoutePage.tsx is also the dispatcher for /bridge/:chain — if the param contains -to- it renders the corridor page, otherwise it delegates to ChainLandingPage in bridge mode.

/defi/bridge?chain=sei preselects that chain as the destination (toToken), whereas the swap page preselects it as the source. Data model: defi-dex/src/data/bridgeRouteSeo.mjs. See SEO subsystem.

Redesign in flight

A visual redesign is approved — "Concept 1". The reference mockup is defi-dex/design/bridge-redesign-concept1.html. Targets: TokenModal.tsx, bridge.tsx and ProviderList. The app's existing Kodchasan font stays as-is; do not introduce a per-page font class.

Under the hood

Bridging shares almost the entire pipeline with swap — same SSE fan-out, same two-round-trip build, same relayer settlement. The differences are:

Concern	Swap	Bridge
fromChain / toChain	Equal	Different
Provider set	excludeBridge unused	excludeBridge applied
Completion	Atomic in one transaction	Two-phase, needs status polling
Relayer requirement	Source chain only	Source chain only — destination needs no relayer

Known limits

• No destination-side guarantee. Once the source transaction confirms, delivery depends on the bridge. Blazpay surfaces the provider's status but cannot force a fill.
• Bridge-out from a destination-only chain is unavailable until a relayer is deployed there.
• Kima is disabled, so its custodial deposit-address route is not offered.
• Intent solvers cannot be used by automation. See the caveat above.