Routing rules

By default a UDA has one destination: every deposit, on every chain, in every accepted asset, settles to the single destination you set when the UDA was created.

Routing rules turn that one destination into a small routing table. Each rule matches deposits from a specific source chain and asset, and sends those deposits to a destination of their own. Anything that matches no rule still settles to the default destination.

Why routing rules

A single fixed destination is the right default, but two cases need finer control:

• Non-routable assets. Some assets have no cross-chain route. TRX on Tron cannot be swapped or bridged off Tron, so it can never settle to, say, USDC on Polygon. The only way to accept it is a rule that keeps it on Tron — a same-chain internal transfer to a Tron address.
• Per-corridor destinations. You may want most deposits pooled into one treasury asset, but a specific corridor — say USDT on Tron — delivered untouched to a separate address for accounting, liquidity, or compliance reasons.

Routing rules cover both: they pin a (source chain, source asset) pair to an explicit destination.

How matching works

When a deposit is confirmed, Stridge resolves its destination before opening a settlement.

1. The deposit carries a source network and a source asset.
2. Stridge checks the UDA's routing_rules for a rule whose match equals that pair.
3. If a rule matches, the deposit settles to that rule's destination.
4. If no rule matches, the deposit settles to the UDA's default top-level destination.

A rule matches on both match.source_network_id and match.source_asset_symbol. A partial match — the right chain but the wrong asset, or the reverse — does not trigger the rule. Each rule must target a distinct (source chain, source asset) pair.

Defining rules

routing_rules is an optional array on the POST /v1/uda body. Each entry has a match block and a destination block.

{
  "owner": "user_8a7f3c",
  "accepted_assets": ["USDC", "USDT", "TRX"],
  "destination": {
    "address": "0x8f4a2c9e1b3d7f5a6c8e0d9b2a4c6e8f0a2c4d6e",
    "asset_symbol": "USDC",
    "network_id": "9002"
  },
  "routing_rules": [
    {
      "match": {
        "source_network_id": "195",
        "source_asset_symbol": "USDT"
      },
      "destination": {
        "address": "TJDENsfBJs4RFETt1X1W8wMDc8M5XnJhCe",
        "asset_symbol": "USDT",
        "network_id": "195"
      }
    },
    {
      "match": {
        "source_network_id": "195",
        "source_asset_symbol": "TRX"
      },
      "destination": {
        "address": "TJDENsfBJs4RFETt1X1W8wMDc8M5XnJhCe",
        "asset_symbol": "TRX",
        "network_id": "195"
      }
    }
  ]
}

The UDA above settles everything to USDC on Polygon by default, with two exceptions:

• USDT on Tron → delivered as USDT to a Tron address, untouched.
• TRX on Tron → delivered as TRX to a Tron address, untouched.

Any other deposit — USDC on Base, USDT on BNB Smart Chain, ETH on Arbitrum — falls through to the default destination and is routed to USDC on Polygon.

Rules and accepted_assets

Routing rules do not bypass the accepted_assets whitelist. A rule's match.source_asset_symbol must also appear in accepted_assets — or accepted_assets must be omitted, which accepts every configured asset. If you add a rule for TRX but leave TRX out of accepted_assets, the deposit is ignored before any rule is ever evaluated.

Tron and non-routable assets

The same constraint applies to any asset Stridge cannot route. The safe pattern when you accept Tron deposits is to pair every non-routable Tron asset with a same-chain rule:

"routing_rules": [
  {
    "match": { "source_network_id": "195", "source_asset_symbol": "TRX" },
    "destination": {
      "address": "TJDENsfBJs4RFETt1X1W8wMDc8M5XnJhCe",
      "asset_symbol": "TRX",
      "network_id": "195"
    }
  }
]

Limits and behaviour

• Maximum 3 rules per UDA. Requests with more are rejected.
• One rule per source pair. Two rules cannot match the same (source_network_id, source_asset_symbol).
• The default destination is always required, even when every corridor you expect is covered by a rule — it catches anything you did not anticipate.
• Rules are part of the UDA record. Update them with PATCH /v1/uda/{id}; in-flight settlements keep the destination they were opened with.

Next

• UDA Overview — the UDA model, creating a UDA, and the full API surface.
• Settlements — settlement lifecycle, scenarios, and the settlement record.
• Supported networks — chain identifiers, including the Tron network_id.
• API reference — POST /v1/uda request and response schemas.