FEEX: Crypto Execution Intelligence
A working execution-intelligence prototype for comparing the all-in cost of crypto trades across exchanges, combining deterministic fee and route logic with optional public order-book snapshots and a constrained AI explanation layer.
Launch Prototype →01 · PROBLEM
Execution cost is harder to see than the trading fee
Crypto traders can compare headline trading fees, but the real cost of execution also depends on spread, book impact, withdrawal and network costs, and whether a route is even available. Those inputs are fragmented across exchange pages, calculators and network notices.
For a $5,000 ETH/USDT market buy withdrawn via Arbitrum on a standard retail profile, the modelled best route is Binance at $9.88 all-in. The headline trading fee is only part of that number.
ETH/USDT · $5,000 · Market · Trade + withdraw · Arbitrum · Standard retail
Headline trading fee
The single number most exchange pages lead with, and the one traders typically compare.
Trading fee + spread or book impact + withdrawal/network cost
The all-in cost of completing the trade and, if needed, moving funds out over a specific network.
02 · MARKET GAP
The gap was not more fee data. It was decision support.
A competitive scan suggested the problem was less about finding individual fee tables and more about turning fragmented cost inputs into one comparable execution decision.
Trading fees may be visible, but spread, withdrawal and network costs are rarely presented as one comparable execution cost.
A trader still has to move between exchange fee pages, calculators and network information to understand the real route cost.
Even when cost data exists, most tools do not explain why one execution path is preferable or what trade-off created the difference.
Examples reviewed in the scan included fee aggregators, portfolio trackers (e.g. CoinGecko, CoinMarketCap, CoinStats) and exchange-native fee pages.
03 · DECISION ENGINE
Two calculation paths. One comparable result.
Every comparison resolves to a single normalised FEEX result before anything is ranked or explained. The engine picks one market-data mode for the whole comparison, so every row in a ranking is calculated the same way.
Users choose whether the route ends on the exchange or in their own wallet. Withdrawal and network costs only apply to the second.
Withdrawal routes are gated on exact exchange × asset × network combinations. Unmodelled combinations are excluded, not estimated.
Representative account-tier profiles with separate maker and taker rates, so the same trade can be compared on a consistent basis.
Spread and impact come from deterministic assumptions per venue. Reproducible, testable and always available.
For OKX, Binance and Bybit marketable/taker trades, FEEX takes a public order-book snapshot and estimates market-buy VWAP and book impact from visible asks. Trading fees and withdrawal/network costs stay modelled.
Always modelled. A snapshot cannot capture queue position, fill probability or adverse selection, so FEEX does not pretend it can.
If live coverage is insufficient for any eligible venue, the whole comparison falls back to the deterministic model. Live and modelled rows are never mixed in one ranking.
Live order-book ranking varies by snapshot. Any live example is illustrative of the beta mode, not a guaranteed current result.
04 · PRODUCT SYSTEM
From trade intent to execution intelligence
A comparison is only useful if FEEX preserves the context behind it. Trade parameters, the fee and route model, market-data provenance and the resulting intelligence travel together through every stage, so each recommendation can be explained, saved and revisited.
Choose pair, trade amount and preferred network.
Gate eligible routes, then calculate fees, spread or book impact and withdrawal cost.
Normalise into one FEEX result and rank eligible routes deterministically.
Claude explains the typed result and its provenance without recalculating it.
Save the preferred route and watch for material cost changes.
Restore prior trade context, re-run analysis and show cumulative savings.
05 · AI INTELLIGENCE LAYER
The model explains the decision. It does not make the calculation.
Claude parses what the user is asking and explains the result FEEX has already calculated. Every financial value, every ranking and every provenance note comes from application code.
Deterministic financial calculations. Live rows come from FEEX’s normalised market-data layer, not from Claude.
A typed FEEX result with provenance. Never raw exchange API payloads.
Calculate costs, change values or re-rank routes. Structured output is schema-validated before it reaches the UI.
Data notes such as live vs modelled are built deterministically by application code, so the model cannot misstate where a number came from.
If the AI call fails or returns invalid output, the underlying FEEX comparison stays fully usable.
Anthropic API · intent parsing and explanation only · schema-validated output · comparison independent of model response
06 · WHAT CHANGED AS I BUILT IT
Three assumptions the build corrected
Static fee and spread assumptions were enough to demonstrate the core comparison concept.
Presenting those assumptions with live-style language created a trust problem.
Separated Modelled and Live order-book beta modes, added explicit provenance, and introduced whole-ranking fallback when live coverage is insufficient.
The AI layer could both interpret the user’s request and generate the comparison.
Allowing an LLM to calculate financial values made the result non-reproducible and weakened trust.
Moved all financial computation into FEEX. Claude now parses intent and explains only the typed FEEX result.
Asset-level withdrawal-network support was sufficient for the prototype.
Real exchanges support specific exchange × asset × network combinations.
Added a conservative route-validity matrix that excludes unmodelled combinations instead of guessing.
07 · PRODUCT SURFACES
Each surface resolves a different product decision
Each surface represents a deliberate decision about what to calculate, what to explain, what to persist and what to disclose.
Make execution cost comparable
DecisionCompare deterministic all-in cost or supported live order-book execution estimates.
Explain why one route ranks first
DecisionExplain why one route ranks first without letting the model calculate financial values.
Turn one comparison into repeat value
DecisionPersist illustrative scenarios, potential savings and model explanations using the deterministic engine.
Show where every number comes from
DecisionShow what is live, what is modelled, route assumptions, fee-profile assumptions and prototype limitations.
Simplified diagrams of the prototype surfaces, not screenshots · values follow the modelled canonical scenario
08 · VALIDATION & NEXT STEPS
What FEEX demonstrates today, and what still needs evidence
Validates FEEX’s core economic value
Tests whether comparison becomes repeat behaviour
Measures whether saved intelligence creates enough value to register
Makes FEEX’s value tangible