Routing policies

Routing rules live inside each UDA: they are copied onto the UDA when it is created, so changing them later means editing every UDA one by one. That does not scale once you have thousands of UDAs.

A routing policy lifts that rule set into a single, tenant-scoped object. UDAs reference a policy instead of carrying their own copy of the rules. Edit the policy once and every UDA that points at it — and every UDA that inherits your default policy — follows immediately, with no change to any UDA record.

Policies vs. inline rules

Both express the same idea — divert a deposit based on its source — but differ in scope and how they are evaluated:

The two compose. A UDA's own inline rules are always tried first; the policy is only consulted when no inline rule matches.

Resolution order

When a deposit is confirmed, Stridge resolves its destination top-down and stops at the first match:

Within a policy (tiers 2–3), rules are evaluated in the order they are stored — the first matching rule wins — and an empty policy simply falls through to tier 4.

The default policy

Every tenant has exactly one default policy, provisioned automatically. It starts empty (no rules), so until you add rules to it, UDAs that inherit it behave exactly as before — every deposit settles to the UDA's default destination.

Add rules to the default policy and all UDAs that inherit it (anything created without an explicit policy, including your existing addresses) pick them up — the central edit routing policies were built for.

Attaching a policy to a UDA

Pass routing_policy_id when creating a UDA. An empty or omitted value attaches the tenant's default policy:

{
  "owner": "user_8a7f3c",
  "destination": {
    "address": "0x8f4a2c9e1b3d7f5a6c8e0d9b2a4c6e8f0a2c4d6e",
    "asset_symbol": "USDC",
    "network_id": "9002"
  },
  "routing_policy_id": "rpol_2f8c1a9d4e5f6071"
}

The attached policy is echoed back as routing_policy_id on the UDA record (omitted when the UDA inherits the default).

Reading policies

curl https://api.stridge.com/v1/routing-policies \
  -H "X-API-Key: $STRIDGE_API_KEY"

{
  "data": [
    {
      "id": "rpol_2f8c1a9d4e5f6071",
      "name": "vip_tier",
      "is_default": false,
      "rules": [
        {
          "match": { "source_network_id": "195", "source_asset_symbol": "USDT" },
          "destination": { "treasury": "treasury_tron" }
        }
      ],
      "created_at": "2026-05-20T14:03:12Z",
      "updated_at": "2026-05-20T14:03:12Z"
    }
  ],
  "pagination": { "page": 1, "limit": 20, "total_items": 1, "total_pages": 1 }
}

Fetch a single policy with GET /v1/routing-policies/{id}.

Behaviour

• No per-UDA writes. Editing a policy never touches uda_addresses; UDAs read the live policy at settlement time.
• In-flight settlements are unaffected. A settlement snapshots its resolved destination when it opens; later policy edits do not move it.
• Retries re-resolve. A failed settlement that is retried re-runs the full resolution order, so fixing a policy lets a stuck settlement pick up the correction on its next retry.
• One default per tenant. The default policy cannot be deleted or duplicated; it is managed for you.

Next

• Routing rules — per-UDA inline overrides (tier 1).
• Treasuries — named destinations a policy rule can point at.
• Settlements — settlement lifecycle and retries.
• API reference — list and read policies.