Venue resolver & routing
Where an asset can be traded, whether execution is acceptable, and which route wins on total cost — not the displayed price.
The venue resolver decides where an asset can be traded and whether execution is economically and technically acceptable. It compares venues on total expected cost, never on the displayed price alone.
What it compares
For every candidate venue and route, the resolver gathers a uniform set of signals. Each is deterministic — pulled from venue capability flags, live market data, on-chain reads or the venue trust record — never inferred by a model:
- venue availability
- deposit/withdrawal state
- liquidity & order-book depth
- pool reserves
- spread
- expected price impact
- expected slippage
- trading fee
- gas & priority fee
- approval cost
- bridge / withdrawal cost
- latency & reliability
- sellability
- contract risk
- venue trust tier
- legal / account constraints
A venue can be excellent on one axis and disqualifying on another. A deep order book with a wide spread, or a tight spread with no exit liquidity, both lose. The resolver scores the whole route, not a single attribute.
The route decision
The resolver emits exactly one decision per candidate:
EXECUTE_VIA_CCXT
EXECUTE_VIA_EXCHANGE_NATIVE_EXTENSION
EXECUTE_VIA_SOLANA_AGGREGATOR
EXECUTE_VIA_EVM_AGGREGATOR
EXECUTE_VIA_DIRECT_DEX
REQUIRE_HUMAN_APPROVAL
OBSERVE_ONLY
REJECT_NO_SAFE_ROUTE| Decision | Chosen when |
|---|---|
| EXECUTE_VIA_CCXT | A CCXT-supported venue clears the checklist and wins on total cost |
| EXECUTE_VIA_EXCHANGE_NATIVE_EXTENSION | CCXT lacks an order type/endpoint the venue needs natively |
| EXECUTE_VIA_SOLANA_AGGREGATOR | Best Solana route is via Jupiter (or a native integration) |
| EXECUTE_VIA_EVM_AGGREGATOR | Best EVM route is via 0x / 1inch aggregation |
| EXECUTE_VIA_DIRECT_DEX | A specific pool/protocol beats every aggregator route |
| REQUIRE_HUMAN_APPROVAL | A safe route exists but trust tier / size / novelty needs a human gate |
| OBSERVE_ONLY | Worth tracking, but no acceptable execution route right now |
| REJECT_NO_SAFE_ROUTE | No route passes security, sellability or cost limits — do not trade |
Every execution flows through the VenueAdapter interface, so the strategy never calls CCXT, Jupiter or 0x directly — it asks the resolver for a route and hands the chosen adapter a structured, time-limited order.
Economic route comparison
A quoted price proves nothing about what an order actually costs. The resolver compares the full acquisition or disposal cost across every viable route and picks the cheapest net outcome that also clears risk:
- +quoted asset cost
- +exchange trading fee
- +spread
- +expected slippage
- +expected price impact
- +network gas
- +priority fee / validator tip
- +token approval cost
- +bridge / withdrawal fee
- +expected failure cost
- +provider / aggregator fee
Each comparison is persisted as an execution_quotes row, and the realized breakdown lands in trade_costs after the fill — so quoted-vs-realized drift becomes a measurable, per-venue signal that feeds back into routing (see the operational schema page).
Why a price alone is misleading
- a $100 DEX buy that realizes $94 of tokens is a 6% immediate loss before the price moves at all — price impact plus slippage plus gas;
- the exit is usually worse than the entry on an illiquid pool, and may not clear;
- a CEX route may quote a worse headline price yet win on total cost once gas, approval and bridge fees are removed;
- a $20/month LLM bill is economically irrelevant next to one badly routed trade.
Because routing decisions, not model spend, dominate net PnL, the resolver is a deterministic service with explicit limits — never an LLM, and never bypassable by one.