[Phase 2] Improve the routing architect to select optimal quote and path

[bluezdot]

Is your feature request related to a problem? Please describe.
... Todo

Describe the solution you'd like
... Todo

Describe alternatives you've considered
... Todo

Additional context
... Todo

[ruhil6789]

Hi @bluezdot 👋,

I would like to work on this issue.

I have experience with routing algorithms, path optimization, and multi-path quote selection across DEX aggregators. I can start by reviewing the current routing architecture and propose improvements for selecting the optimal swap path and quote.

Please let me know if there are any specific requirements, constraints, or prior discussions I should follow before proceeding.

Thanks!

[bluezdot]

Hey @ruhil6789,
We haven't provided a specific solution plan for this Optimization Phase 2 yet. To understand the logic for this feature on SubWallet, you can follow along starting from this directory:
SubWallet-Extension/packages/extension-base/src/services/swap-service

[ruhil6789]

hi @bluezdot,
After going through the SubWallet-Extension/packages/extension-base/src/services/swap-service code i can we can improve the routing and quote selection.
Based on swap-service,routing and quete-selection are split like this :
=>Routing: findAvailablePath (backend) → returns a single path (or none).
=>Quotes: askProvidersForQuote on that path’s swap pair → getLatestDirectQuotes picks the highest toAmount with some provider bias.
=>Process: generateOptimalProcessV2 then adjusts steps/fees per provider.

To improve the “routing architecture” for optimal quote + path, I’d look at:

1. Separate concerns & scoring layer
   =>Introduce a dedicated “route planner” service that takes:
   -> Multiple candidate paths (not just one from findAvailablePath).
   -> Quotes per provider per path.
   => Have a single scoring function that ranks (path, quote) pairs with weights for:
   toAmount (primary)
   network fees (gas/bridge fees)
   slippage / price impact
   time-to-finality / reliability score per provider
   user preferences (e.g. “avoid bridges”, “prefer L1 liquidity”, “avoid provider X”).
2. Multiple candidate paths instead of just one
   )Extend the backend API to return several feasible paths (e.g. “direct”, “via bridge A”, “via bridge B”).
   )For each path:
   =>Build a path-specific swap request (like directSwapRequest, but per path).
   =>Fetch quotes per path, then feed them into the scoring layer.

This lets you choose between “slightly less toAmount but significantly cheaper gas / safer route” vs “max output but worse UX”.

3. Richer, configurable quote selection
   Replace the current inline sort in getLatestDirectQuotes with a pluggable strategy:
   Strategy interface like QuoteSelectionStrategy.select(quotes, context).
   Default strategy: highest effective output after total fees.
   Advanced strategies: “stablecoin safety”, “minimize bridges”, “respect blacklist/whitelist”.
   Makes it easy to evolve logic without touching core service

4. Better integration between path actions and process
   Today, you check consistency with:
   JSON.stringify(processStepsToPathActions(steps)) === JSON.stringify(path.map(e => e.action))

   Instead, make path the single source of truth:
   Each step in the process references back to a pathStepId.
   Providers generate process steps from path elements, not from scratch, so mismatches are structurally impossible.
   This will make multi-leg / multi-bridge routes more reliable

5. Observability & fallback
   Track per-provider and per-path stats (success rate, error types, avg latency, realized slippage).
   Feed these metrics into scoring (e.g. down-rank flaky providers).
   Design fallback:
   If best (path, quote) fails validation or execution, automatically retry with the next-ranked candidate if safe.

6. Caching & refresh
   Cache quotes + routes briefly (per request signature) to support:
   Quick “refresh quotes” without re-running full path finding.
   Fast UX when user tweaks slippage or gas presets.
   Use aliveUntil to proactively mark quotes stale and prefetch new ones in the background when near expiry.

[bluezdot]

@ruhil6789, Opt 1 and 2 are exactly what I'm evaluating for implementation. However, they also have implications on UX and Performance, because integrating various swap providers results in a very large number of available paths (or routes). Also, many small edge conditions affect the implementation feasibility as 1) Cross-chain swaps cannot be go with multiple steps swap (Swap with Bridge step); 2) Some providers have special quote types (e.g., Uniswap with a normal quote and a UniswapX quote); ...

[ruhil6789]

@bluezdot
Thanks for calling that out — I’m running into the same concerns.
For Opt 1 and 2, my current thinking is:
Route explosion & performance: Instead of evaluating all possible paths, we can:
-> Hard‑cap the number of candidate routes per request (e.g. top N from the backend, pruned by simple heuristics like max hops, avoid obviously dominated routes).
-> Do path discovery and quote fetching in two tiers:
-> cheap path pre‑filter → full quote + scoring only on the best few candidates.
-> Cross‑chain constraints:
I agree we should keep cross‑chain swaps single‑swap + bridge only and explicitly exclude multi‑step swap paths for those. In practice this means:
->Marking “cross‑chain” routes in the planner and applying a stricter rule set.
->Only allowing multi‑step optimization on same‑chain (L1/L2) routes for now.
Provider‑specific quote types (e.g. Uniswap vs UniswapX):
->Treat these as variants under one provider in the scoring layer, not as separate providers.
-> The routing/selection logic would see “Uniswap-normal” and “UniswapX” as separate options on the same path, each with its
own constraints (e.g. gasless, RFQ, etc.), and pick based on a unified score (output – fees – risk).
If this direction sounds reasonable, I can prototype a small “route + quote scoring” layer that:
->Accepts multiple candidate paths from the backend,
->Applies these constraints (cross‑chain vs same‑chain, provider capabilities),
And returns a single (path, quote) pair plus a small set of “next best” alternatives for the UI.

thank you!

[bluezdot]

@ruhil6789
Will dig deeper into those ideas when I have time. Thank you!