Skip to main content

Overview

The route policy system provides a lightweight way to determine which asset pairs can be traded without requiring individual API calls for each route validation. Instead of fetching all possible routes from the server, you can download a compact policy configuration and compute valid routes locally.
This approach significantly reduces API calls and enables real-time route validation in your application.

How it works

Route policies use a priority-based validation system with four key components:
  1. Isolation Groups (Highest Priority): Assets that can ONLY trade with each other.
  2. Whitelist Overrides: Explicit exceptions that bypass other restrictions.
  3. Blacklist Pairs: Forbidden trading pairs with wildcard support.
  4. Default Policy: Fallback behavior for unconfigured routes.
1

Isolation groups

If either asset is in an isolation group, the route is only valid if both assets are in the same isolation group.
2

Whitelist overrides

Explicit exceptions that allow routes regardless of other restrictions.
3

Blacklist pairs

Forbidden routes that override the default policy.
4

Default policy

Applied when no other rules match — either “open” (allow) or “closed” (deny).

Local route matrix generation

Here’s a complete script to route matrix generation for local route validation:

Integration guide

Use the validator to check if specific routes are allowed:

Wildcard patterns

The system supports wildcard patterns for flexible policy configuration:
Match all assets on a specific chain:
Match specific assets across all chains:
Match any asset (use with caution):

Best practices

  1. Store the policy configuration locally and refresh it periodically rather than fetching it on every route validation.
  2. Implement proper error handling and refresh the policy when a get quote or create order fails due to an unsupported pair.