Building a cross-chain app with bridge aggregator SDKs is a 1- to 2-week integration that gives an app instant access to 30+ bridges across 20+ chains. The major aggregator SDKs — LiFi, Socket, Squid, and Rango — share an integration shape: configure once, request a quote, execute the transaction, poll status until settlement. The differences are in API ergonomics, type safety, status reporting, and how each SDK handles the failure modes that bridge transfers expose. This guide walks through the integration patterns that work in production, the gotchas that bite teams shipping cross-chain features, and the operational tooling that production aggregator integrations need beyond the SDK itself.
​

The audience for this guide is developers who have decided to use a bridge aggregator (rather than direct bridges or an orchestration layer) and need to ship the integration. For the architecture decision itself, see our aggregator-vs-direct-bridge framework. For an orchestration layer that sits above all aggregators, see Eco Routes at the end of this guide.
​

Every aggregator SDK exposes the same four operations: configure, quote, execute, and status. The semantic shape is consistent across LiFi, Socket, Squid, and Rango even though the type signatures differ.
​

Configure sets up the SDK instance with RPC URLs for each chain, an optional integrator fee, the wallet signer, and any feature flags (slippage, gas-on-destination, allowed bridges). Configuration is heavy in LiFi (passes RPC URLs for all 30+ chains) and lighter in Squid and Rango where defaults handle most cases.
​

Quote requests a route for a specific transfer: source chain, source token, source amount, destination chain, destination token, slippage tolerance. The aggregator returns the best route plus calldata. Quotes are valid for 30-60 seconds typically and include the underlying bridge name and expected output.
​

Execute sends the transaction. The SDK handles allowance approvals, the actual bridge transaction, and any wrapping or DEX swaps that the route requires. The SDK returns a transaction hash on the source chain and an internal transfer ID for status tracking.
​

Status polls the in-flight transfer state. The aggregator returns one of PENDING, DONE, FAILED, or REFUNDED, plus the destination-chain transaction hash once the transfer settles. Status polling typically runs at 5-10 second intervals until the transfer reaches a terminal state.
​

The canonical integration looks roughly like this in TypeScript using LiFi's SDK. The pattern is similar across all aggregators with API surface differences:
​

The integrating app instantiates the SDK once at startup with RPC URLs and the user's signer. On each cross-chain transfer request, the app calls the quote endpoint with the user's specified source and destination, gets back a route description plus calldata, and submits the transaction. The user signs once.
​

After the transaction is submitted, the app polls the status endpoint at 5-10 second intervals. The aggregator's status reflects the underlying bridge's state. For fast routes (Across, CCTP V2) the status flips to DONE in 15-30 seconds. For slow routes (Wormhole canonical, exotic-chain bridges) the status can take 5-15 minutes. The integrating app surfaces this estimated time to the user upfront based on the route choice.
​

Error handling at quote time is straightforward — the API returns no route or an error code. Error handling at execute time is harder because the transaction is already onchain. A failed execution where the source-chain transaction reverted is recoverable (the user just retries). A failed execution where the source-chain transaction succeeded but the bridge couldn't process it (e.g., the destination chain was paused) requires manual recovery through the underlying bridge's UI.
​

The most important configuration parameter most teams forget to set is bridge whitelisting. Every aggregator SDK lets the integrating app restrict which underlying bridges the aggregator can route through. LiFi's allowedBridges parameter takes an array of bridge IDs. Socket's includeBridges parameter does the same. Squid's denyList works inversely.
​

The default whitelist for every aggregator includes bridges the integrating team would not necessarily approve on first principles. After the Multichain exit scam in mid-2023, every aggregator removed Multichain from their default route list — but until that point, integrating apps that hadn't explicitly whitelisted were exposed. Rekt News documented roughly $130M in losses across users.
​

The right pattern in production is to maintain a whitelist of approved bridges in application configuration, update it through a code review process, and pass the whitelist on every quote request. A typical conservative whitelist for stablecoin transfers includes CCTP, Across, Stargate, Hop, and the canonical L1-L2 bridges. Adding a bridge to the whitelist requires reviewing its audit history, governance status, and recent incident reports.
​

Every aggregator SDK exposes a status endpoint that returns the current state of an in-flight transfer. The states are similar across SDKs: PENDING (transfer in flight), DONE (settled successfully), FAILED (settlement failed), REFUNDED (source funds returned).
​

For polling, the right interval is 5-10 seconds. Polling more aggressively wastes API quota and adds load with no benefit; polling less aggressively delays the user-visible "transfer complete" signal. Most production integrations use exponential backoff — 5 seconds for the first 60 seconds, 15 seconds afterwards.
​

For settlement notification, the aggregators expose webhooks where the integrating app can register a callback URL that fires when the transfer reaches a terminal state. LiFi's webhooks are the most polished. Socket and Rango expose webhook support with similar shape. Webhooks reduce the polling burden but require the integrating app to maintain a public HTTPS endpoint that the aggregator can call.
​

For terminal-state handling, DONE is the success path (typically 95-98% of transfers). FAILED and REFUNDED together represent 2-5% of transfers in production data. Both require the integrating app to surface the failure to the user and either retry, refund off-chain, or guide the user to a manual recovery flow on the underlying bridge. The recovery UX is one of the larger gaps in current aggregator SDKs.
​

Cross-chain transfers fail in five common ways, and the integrating app needs to handle each one:

The fifth case is where most teams under-invest. An aggregator API outage doesn't break in-flight transfers, but it does break the integrating app's ability to report status to users. The right pattern is to fall back to direct on-chain queries for in-flight transfers when the aggregator API is unreachable. Artemis stablecoin volume data shows the top aggregators handled $580M in weekly cross-chain volume in March 2026 across roughly 230,000 transfers, with brief 5-15 minute API outages occurring 3-4 times per quarter on average across the major aggregators.
​

Cross-chain transfers involve gas on both chains plus the underlying bridge's protocol fee plus any aggregator markup. The SDK abstracts most of this — the quote response includes total cost in dollar terms — but production teams need to manage gas explicitly for two cases: destination-gas-on-arrival and gas variance during high-congestion periods.
​

Destination-gas-on-arrival is the case where the user arrives on the destination chain with the destination token but no native gas to spend it. Socket's Refuel feature sends $1-3 worth of native gas alongside the transfer; LiFi has similar functionality. For wallet integrations this is meaningful — a user transferring USDC to Arbitrum arrives with 0 ETH for gas, which breaks the next interaction. Refuel typically adds $0.20-$0.40 to the total transfer cost.
​

Gas variance during congestion affects the integrator fee economics. If gas spikes during a transfer, the underlying bridge's costs go up, and the integrator's expected revenue compresses. The SDK handles this transparently, but at the application layer the integrator needs to monitor and adjust fee tiers accordingly.
​

The four major aggregator SDKs differ on coverage, ergonomics, and ecosystem fit. The decision framework:
​

LiFi is the default choice for most EVM-and-Solana integrations. Best documentation, broadest bridge coverage, polished SDK, and active developer support. Pick LiFi unless there's a specific reason not to.
​

Socket is the right choice for wallet integrations, particularly inside the Coinbase Wallet or MetaMask ecosystems where Socket has parity. Refuel feature is unique. Documentation is solid.
​

Squid is the right choice when the flow involves Cosmos chains. Native Axelar integration covers Cosmos-EVM transfers without wrapped IOUs. For non-Cosmos flows, LiFi or Socket is usually a better fit.
​

Rango is the right choice for breadth-first products covering Bitcoin, Tron, NEAR, Aptos, Sui, and other exotic chains. Cost is higher than LiFi or Socket on mainstream routes; coverage is unmatched.
​

For most production stablecoin teams, the answer is LiFi for the breadth-first integration plus a direct bridge integration for the highest-volume route. For stablecoin orchestration at scale, the answer is to skip the aggregator integration entirely and use an orchestration layer that abstracts the route selection.
​

Every aggregator SDK exposes a quote-execute-status interface that the integrating team has to operate. The team has to maintain bridge whitelists, monitor underlying bridge health, handle failure modes, and reconcile settlement against the application's accounting. This is meaningful operational work — the SDK does the routing but not the operations around the routing.
​

Eco Routes is the orchestration layer above the aggregators for stablecoin flows. Instead of a quote-execute-status interface, Eco exposes an intent interface: the app submits "transfer 10,000 USDC from Ethereum to Arbitrum" and gets a settlement event. Eco's network handles the bridge selection (which might be CCTP, Across, deBridge, or any other route the network has solver liquidity for), the failure handling (retry on a different route), and the reconciliation (a single settlement record per intent).
​

For stablecoin teams, this is meaningfully less code than a direct LiFi or Socket integration. The aggregator SDKs are 200-500 lines of integration code plus operational tooling on top. Eco's intent API is closer to 30-50 lines for equivalent functionality, with the operational tooling handled by the network. Eco Routes covers 15 chains with stablecoin coverage spanning USDC, USDT, USDS, FDUSD, PYUSD, and RLUSD.
​

For non-stablecoin or arbitrary-token flows, the aggregator SDKs remain the right pattern. Eco does not aggregate arbitrary tokens; it is purpose-built for stablecoin orchestration on the chains where stablecoin volume concentrates. The decision is the same as the architecture decision earlier in this guide: stablecoin breadth-first plus production reliability points to Eco; arbitrary-token breadth-first points to LiFi or Rango.
​

LiFi is the default choice for most EVM and Solana integrations: broadest bridge coverage, polished documentation, and active support. For Cosmos use Squid. For exotic chains use Rango. For wallet integrations Socket has parity inside Coinbase and MetaMask. See our cross-chain bridging guide.
​

A basic integration takes 1-2 weeks of engineering for any of the major SDKs. Production hardening (failure handling, status polling, bridge whitelisting, gas management) takes another 2-4 weeks. Total: 3-6 weeks for a production-ready integration including operational tooling.
​

The bridge whitelist. Every aggregator SDK lets you restrict which underlying bridges can be routed through. Default whitelists include bridges most teams would not approve on first principles. Set this explicitly and update it through a code review process.
​

Failure handling is the largest operational gap in current SDKs. Surface the failure state to users, expose the underlying bridge's transaction hash for manual recovery, and consider an orchestration layer for production stablecoin flows where reliability matters most. See our cross-chain swap guide.
​

For arbitrary-token flows or breadth-first apps, use an aggregator SDK (LiFi, Socket, Squid, or Rango). For stablecoin-specific orchestration at production scale, use Eco Routes. The orchestration layer abstracts the bridge selection and operational tooling that aggregators expose.
​