Docs: BTC routed swap
BTC routed swap is a specialized product mode on top of the same order lifecycle. Quote, create-order, and status tracking remain the same, while payout follows an enhanced AML-aware route with additional screening signals.
BTC in → AML-aware routed flow → payout out
You send BTC into an AML-aware flow. The system evaluates incoming funds using screening signals and policy thresholds, then decides whether to reject by policy, proceed with normal routed handling, or require stricter AML-aware routed handling (including AML-swap scenario) before payout preparation.
Final payout can be BTC or another selected destination asset/chain, but it always follows the resulting screening-aware route model rather than a random transfer path.
What BTC routed mode is
BTC routed is built for BTC-first scenarios where payout-path control and route visibility are priorities. It does not introduce a separate backend contract; the same order API and lifecycle are preserved.
When to use it
Use BTC routed when you want stronger screening-oriented route semantics and clearer payout-path context. Use Standard for direct everyday swaps with simpler route behavior.
How it differs from Standard swap
| Field | Standard swap | BTC routed swap |
|---|---|---|
| Primary intent | Cross-chain swap with a direct DEX-focused route. | BTC-first flow with enhanced AML-aware route for payout-path control. |
| Routing visibility | Execution detail appears when provider data is available. | Policy-level route model is always shown; execution detail appears when available. |
| Screening layer | Baseline policy checks apply. | Enhanced screening signals are applied before payout-path progression. |
| Settlement window | Usually narrower in low-complexity routes. | Can be wider due to screening progression and confirmation depth. |
| Outcome range | Payout follows the selected destination path under normal routed handling. | Policy can result in BTC payout, destination-chain payout, or reject/refund path. |
How BTC routed works
Step 1
Deposit intake
The order receives deposit and starts the same lifecycle as standard mode.
Step 2
Enhanced screening signals
Additional AML-aware screening signals are evaluated before payout-path progression.
Step 3
BTC-first route selection
Router applies a BTC-focused path under DEX-only execution policy.
Step 4
Risk-screened payout preparation
Destination payout is prepared after route and screening checks align.
Step 5
Settlement window
Final payout timing remains route-dependent and confirmation-dependent.
Policy thresholds and handling outcomes
The AML layer evaluates screening scores and tags. Product-level semantics follow policy ranges: lower-risk flows can proceed with normal handling, gray-zone flows can proceed with additional controls, and high-risk flows can trigger stricter AML-aware routed handling (`requires_aml_swap`) or policy rejection.
Internal scoring formulas and provider-specific risk engine details are not disclosed in public UI.
High-level BTC AML lifecycle
- 1. Deposit received (WAIT_DEPOSIT → DEPOSIT_UNDER_AML).
- 2. Deposit under AML review and routing decision (ROUTING).
- 3. Routed execution starts and may include AML-swap scenario (EXECUTING).
- 4. Payout may undergo additional AML review (WAIT_PAYOUT → PAYOUT_UNDER_AML).
- 5. Final outcome: DONE, PAYOUT_REJECTED, REFUNDING/REFUNDED, or EXPIRED.
Cross-chain payout examples
These are policy-model examples for clarity. They explain routed intent and destination settlement, not a guaranteed live venue-by-venue trace.
Example A
BTC deposit → AML-aware review → stricter routed handling → BTC payout prepared on Bitcoin.
Example B
BTC deposit → AML-aware review → routed handling → ETH payout prepared on Ethereum.
Example C
BTC deposit → AML-aware review → routed handling → SOL payout prepared on Solana.
Example D
BTC deposit → AML-aware review → payout blocked by policy → reject/refund path.
What AML-aware screening means in practice
Screening is based on provider and router signals. The UI exposes resulting status and route notes, but does not disclose internal scoring rules or private routing heuristics.
This means users see handling outcomes and route semantics, not raw internal risk-engine math.
What may remain internal
Policy-level route model is always shown. Full venue-by-venue and hop-by-hop graph may remain internal when provider/runtime data is not publicly exposed.
What destination chain selection changes
Destination chain selection defines where final payout is prepared and settled. BTC routed mode keeps BTC as the routed origin context while adapting settlement to your selected destination network and asset.
What settlement window means
Settlement window is the interval in which payout can complete after screening and network confirmations. In BTC routed mode, this can vary more due to route depth and additional screening progression.
What stays unchanged
- DEX-only execution policy.
- Non-custodial flow from user perspective.
- Same order lifecycle and status progression model.
What route visibility means in BTC routed mode
Route visibility is structured in three layers: policy route model (always visible), execution detail visibility (shown when runtime fields exist), and routing-layer managed internals (may remain non-public).
What the user sees in UI
- Mode labels and mode-specific explanation on landing and swap widget.
- Screening status and settlement notes on swap and order views.
- Policy-level route model for BTC routed mode.
- Execution detail rows on order page when runtime data is available.
FAQ
- Why is BTC routed a separate mode?
- BTC routed is designed for BTC-first payout-path control. It adds enhanced AML-aware screening and stronger route visibility while keeping the same order API and lifecycle.
- Does BTC routed change custody?
- No. The flow remains non-custodial from the user perspective: you send from your wallet and track the order through the same lifecycle.
- Does the route reveal every internal venue and hop?
- Not always. The UI shows policy-level route steps and execution details when available. Some routing-layer details may remain internal if providers do not expose them publicly.
- Why can settlement take longer in BTC routed mode?
- Settlement can vary due to screening checks, route complexity, and network confirmation depth. This is reflected as a route-dependent settlement window.
- What signals are shown to users versus kept internal?
- User-visible signals include screening status, mode, policy route model, timeline, and available execution steps. Internal scoring thresholds and full private venue graph remain routing-layer managed.
- Can BTC routed settle to a non-BTC destination chain?
- Yes. BTC routed keeps BTC as routed origin context while settlement is prepared for your selected destination chain and asset, such as Ethereum, Solana, or Arbitrum.