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 (
exactInonly vsexactIn+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({})],
});
}