Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Providers

Your provider set is the most important configuration decision in spanDEX. Think in terms of a portfolio: you want enough provider diversity to improve route quality, resilience, and throughput under real load. No single aggregator wins every trade or delivers 100% uptime.

Supported Providers

Why Use Multiple Providers

  • Better fill quality: different routers are stronger on different chains, pools, and token pairs.
  • Better uptime: provider outages, brownouts, or temporary API issues do not fully block quoting.
  • Better fee opportunities: providers differ in integrator fee/surplus support and commercial terms.
  • Better latency under load: requests can race in parallel and still respect a global deadline.

What Differs Across Providers

When choosing providers, compare these dimensions:

  • Functionality (exactIn only vs exactIn + targetOut)
  • Provider-imposed fees (surplus taking or swap fees)
  • Integrator fee and surplus support (see fees page)
  • Base API requirements (keys, partner IDs, referral codes)
  • Rate limits and plan capacity
  • Chain and token coverage

Production Planning

In production with real volume, configure multiple providers and choose provider plans that match your expected quote throughput. A single free-tier or low-rate plan is usually a bottleneck.

Multi-Region and Edge Deployment

If you run spanDEX as an edge service, you can use dynamic provider configuration by region to keep quote latency lower and improve reliability. If you have any regional latency data for providers, please contribute.

import { createConfig, fabric, relay, velora } from "@spandex/core";
 
export function configForRegion(region: string) {
  if (region.startsWith("eu")) {
    return createConfig({
      providers: [fabric({ appId: "..." }), relay({})],
    });
  }
 
  return createConfig({
    providers: [fabric({ appId: "..." }), velora({})],
  });
}