We aggregate quotes across multiple CEXs, compute the net price (taker + VWAP + withdrawal), and in real time pick the best route—direct or via a bridge (EUR/USDT)—only if it maximizes the output amount. Each route passes hard gates for liquidity/spread/withdrawal, receives a risk score, and is auto-enabled/disabled under live monitoring.

What it delivers: lower slippage, a predictable all-in price, minute-level execution, and a compliance-friendly UX for B2B/B2C.

Conditions

• KYC passed.
• Routing is BTC/EUR → EUR/ETH (EUR bridge is mandatory).
• User has a positive BTC balance (≈ $11,610 notional).
• Withdrawal: Ethereum L1 only.
• Price anchor: ETH ≈ $4,000.
• Our markup: 0.3% (USD).

Roles

• User: asks to swap BTC/ETH.
• System: pulls quotes across CEX and builds the best route (under the hood we always route via EUR).

Goal

• Find the route that gives the best user payout (BTC/ETH after all fees) while keeping our margin competitive

How we measure a result

Primary (what the user feels):

• USD out after fees - the final amount the user gets.
• Price advantage vs alternatives - delta vs the next-best route (and vs DEX benchmark when we compare). Target: stay better by 5–10 bps when possible.

Business (KPI and North Star Metric)

• Revenue per swap = (USD out * 0.3%),
• Gross margin % vs total routing cost.

Speed & reliability:

• RFQ response P95 ≤ 500 ms.
• End-to-end time (P50/P90) from user confirm to withdrawal txid.
• Quote stability - % of swaps executed without re-quote within TTL = 10s (higher is better).
• Success rate - completed swaps / started swaps (target ≥ 99.5%).

Quality of pricing:

• Quote accuracy - difference between quoted ETH out and filled ETH out (bps).
• Win-rate by venue - how often each CEX route wins in our internal ranking at this notional.

Routing

Direct and alternative routes are described here with output amount, commission and breakeven point.

Flow (Direct & Convert) BTC/EUR → EUR/ETH

Prepared as draft requirements for development

1. User selects
   1. From: BTC (any supported deposit network) → To: ETH.
   2. Withdrawal network: Ethereum L1.
   3. Amount: ~$11,610 notional in BTC.
      1. If the user has a positive BTC balance, the Swap button becomes active after we run the route simulation.
      2. If validation fails, suggest buying BTC via the ramp.
      3. Min/Max limits for this flow: min $40 / max $17,500.
2. System scans 4 CEX: Kraken, Binance, Bitstamp, Coinbase to simulate and build the smart route. We always keep the EUR bridge under the hood. We consider:
   1. Full cost at this notional (in bps from ~$11,610).
   2. Pairs present: BTC/EUR → EUR/ETH.
   3. Direct (Spot)
      1. Formula: 2×taker + 2×VWAP + withdraw(L1) + network + quantize(lot/tick).
      2. Inputs: live markets BTC/EUR and EUR/ETH; order books (VWAP for the whole notional), retail taker fees, ETH L1 withdraw (incl. network if not already included), lot/tick rounding.
   4. Convert (if enabled in config)
      1. Build candidates: Convert BTC/EUR → Convert EUR/ETH (must keep the EUR leg).
      2. Components: convert_btc_eur + convert_eur_eth + withdraw(L1) + network.
   5. Liquidity filter
      1. If on any EUR leg Depth@±0.5% < 5× of notional → try batched execution 2–4× within TTL=10s; if still not OK → drop the candidate.
   6. Pick the winner
      1. Choose the minimum Total; if two options are very close (≤ 5–10 bps), prefer the one with cheaper/faster withdrawal.
3. System routes the result (within TTL 10s)
   1. Auto-requote: If TTL expired, the book thinned, or withdraw is temporarily unavailable - immediately re-simulate and show a fresh RFQ (or a transparent decline).
4. System shows a result for a user (Total out):
   1. USD out and ETH out (finals).
   2. Rate: BTC→ETH (also show ETH/USD for context).
   3. Fee: 0.3% + Routing fee (one line).
5. User clicks Swap → we build the transaction
6. System executes on the selected CEX:
   1. Place taker orders on both EUR legs (batch 2–4× within TTL if needed; notional stays the same).
   2. Trigger ETH withdrawal on Ethereum L1.
7. System shows statuses in UI:
   1. Show txid/stages → then the success screen when withdrawal is confirmed.

Flow Compare (Kraken Priority): Direct vs. Convert via the EUR bridge

• Rank by ETH-out: Binance Convert ≳ Binance Direct » Kraken Direct » Kraken Convert.
• Cost driver: taker+VWAP decide; withdraw/quantise are minor. EUR bridge kept in all flows.
• Rule: pick lowest total bps; if gap ≤ 5–10 bps, prefer cheaper/faster withdraw. TTL=10s, batching 2–4× ok

Short summary

• Binance < Kraken on fees → higher ETH-out. On our EUR-bridge routes, Binance consistently prices better than Kraken at this notional.
• Convert-EUR (2 legs): we price two converts (BTC→EUR, EUR→ETH) on each CEX. For illustration:Binance ≈ ~10 bps/leg (~20 bps total), Kraken Instant ~1%/leg (~200 bps), Coinbase retail convert ~50 bps/leg (~100 bps). This explains why Binance Convert often tops the table.
• Withdraw fees differ by venue. Some CEX include L1 gas in the withdraw fee, some don’t; we normalize to bps vs mid for apples-to-apples, and in this draft we don’t add variance/buffer.

At the time of this simulation, Convert on Binance produced a better ETH-out than Spot on Binance. Live results can vary with liquidity and spreads.

Why

• I optimize the route for the best user take-home.
  • The engine factors in depth/spreads, per-leg fees, withdraw, and quantization so the user gets the maximum USD/ETH out. This directly lifts %conversion_rate_swap_success and %total_volume while keeping %receive_fee healthy through volume.
• I minimize execution costs.
  • The router picks the path with the lowest all-in cost (taker + VWAP + withdraw + quantize), which protects user payout and supports %total_volume / %receive_fee .
• Asynchronous simulation → instant RFQ.
  • Quotes are computed in the background and returned fast, improving UX and increasing %conversion_rate_swap_success.
• Single-CEX execution with a mandatory EUR bridge.
  • Fewer operational hops, lower latency/risk. This stability positively impacts %conversion_rate_swap_success.
• Convert as an alternative on volatility.
  • During sharp moves or micro-volatility, a Convert quote can occasionally beat spot routing. I keep it as an option, but I always weigh risk vs benefit (final user payout may differ).
• TTL = 10s.
  • Quotes don’t go stale, and we still have a window to batch 2–4× without changing the user’s notional.
• Built to scale across new CEX via API.
  • As new data providers appear and traffic grows, the system already has what we need:
    • Liquidity floor in simulation. Filter out candidates that don’t meet depth/spread criteria.
    • Telemetry-driven routing. Collect sim/exec data and shift flow to venues with lower cost and better user payout.
    • Standardized API for integrators. Easier partner integrations → more %total_volume.

Alternative flow (BTC/EUR → EUR/USDT → USDT/ETH)

USDT-3 legs = 3×taker + VWAP(BTC/EUR) + VWAP(EUR/USDT) + VWAP(USDT/ETH) + withdraw + quantize + overhead.

What changed vs base

• We keep the EUR bridge (EUR/USDT is mandatory), but we split the EUR→ETH leg into two stable legs: EUR/USDT + USDT/ETH.
• Extra cost comes from +1 taker and a small execution overhead (coordination/TTL).

When can USDT be cheaper?

Key idea: compare one complex leg (EUR/ETH) vs two stable legs (EUR/USDT + USDT/ETH) plus the extra taker and overhead.

USDT route is beneficial on a single CEX if: VWAP (EUR/ETH) > VWAP (EUR/USDT) + VWAP (USDT/ETH) + taker +overhead

On Binance (taker = 10 bps, overhead ≈ 3 bps):

• Need VWAP(EUR/ETH) > VWAP(EUR/USDT)+VWAP(USDT/ETH) + 13 bps.

Example “EUR/ETH”: EUR/ETH = 35 bps, EUR/USDT = 3, USDT/ETH = 6 → 35 > 9 + 13 → USDT bridge wins.

Quick stress test (Binance, thin EUR/ETH)

• EUR-2 legs: 20 + (5 + 35) + 1.2 + 1 = 62.2 bps → $72.21
• USDT-3 legs: 30 + (5 + 3 + 6) + 3 + 1.2 + 1 = 48.2 bps → $55.96Gain: ~14 bps (≈ $16.25 on $11,610).
• On Kraken the extra taker is 40 bps and overhead ≈ 3 bps, so the threshold is > 43 bps. EUR/ETH must be very poor to justify USDT; on majors this is rare.

Rule of thumb (single-venue)

Enable the USDT bridge only if all are true:

• EUR/ETH slippage exceeds EUR/USDT + USDT/ETH by at least (taker + overhead):
  Binance: > 13 bps; Kraken: > 43 bps.
• TTL fits (three legs inside ~10s).
• Depth ok on all three books (Depth@±0.5% ≥ 5× notional).
• Total bps for USDT-3 legs ≤ your cap (e.g., ≤ 65 bps).
• Withdrawal on the requested network is available.

Do not enable if any condition fails, or if the saving is < 5–7 bps (doesn’t cover 3-leg risk).

Summary (2-legs vs 3-legs)

• On liquid majors, EUR-2 legs are usually cheaper.
• The USDT bridge is a fallback optimization for moments when EUR/ETH on a venue is temporarily thin/expensive.
• Simple check (Binance): pick USDT if VWAP(EUR/ETH) − [VWAP(EUR/USDT)+VWAP(USDT/ETH)] ≥ ~15 bps (includes a small risk buffer).

Handle pairs not listed on Kraken

• Switch to another CEX (single venue). Condition: the venue has A/EUR and EUR/B, B withdrawal is enabled on the chosen network, and the notional fits the order book. Respect the minimum competitive size. If any leg is thin - try batching 2–4× within TTL.
• Use Convert-EUR on another CEX (2 steps: A→EUR and EUR→B). Take both quotes and store both quote_id.
• Integrate new CEX where the pair exists. Add to the pool and include in auto-scan.
• Recommendation system. If the pair/network is unavailable or too expensive - suggest an alternative asset or network (e.g., instead of Ink, propose an ETH L2 we support).
• Token list button: “Didn’t find the asset you need? Leave a request”.
• Coverage config. Periodically walks the asset list, checks A/EUR, EUR/B, withdrawals, limits; updates the status “available/unavailable.” This is a preventive signal that shows how well our coverage supports the UI.
• Log unsuccessful routes. Capture reason and point of failure: no pair, no withdrawal, thin book, TTL expired, expensive price, etc.
• Coverage alerts. If for top assets the share of available A/EUR + EUR/B drops below a threshold - send a signal to Product/BD

Break-even markup vs DEX aggregators (1inch, Jumper)

• Notional: $11,610.
• Mandatory EUR bridge (BTC/EUR → EUR/ETH).
• CEX considered: Binance Direct, Kraken Direct
• DEX benchmark built from Tenderly sims of on-chain swaps.
  • Scenario A (Conservative): Gas fee 5$ + Provider fee 0.25% + LP fee 0.3% + Slippage 0.5% + MEV 0.1%.
  • Scenario B (Highly liquid pairs like ETH/USDT, BTC/USDC): Provider fee 0.25% + LP fee 0.3% + $5 Gas fee + Slippage 0.1% , MEV 0%

Scenario A : Conservative DEX (BTC/ETH)

Model: Gas $5 + Provider 0.25% + LP 0.3% + Slippage 0.5% + MEV 0.1% = 1.15% + $5

Scenario B : High-liquidity DEX (ETH/USDT → USDT/ETH)

Model: Provider 0.25% + LP 0.3% + Slippage 0.1% + MEV 0% + Gas $5 = 0.65% + $5

Break-even CEX vs DEX

$ out for CEX already includes routing fees 0.3%

Why CEX (Binance, 2-leg EUR bridge) beats DEX in both scenarios

• Deep EUR books → low taker + tight VWAP on both EUR legs.
• No on-chain costs (gas / MEV) that DEX must pay on every swap.
• Small L1 withdraw and safe 2–4× batching within TTL=10s keep the net payout higher.
• Bottom line (CEX vs DEX): at $11,610 notional, Binance Direct pays $11,542.69 vs
  • DEX Scenario A (1.15% + $5): $11,471.49 → + $71.20 to CEX.
  • DEX Scenario B (0.65% + $5): $11,529.54 → + $13.15 to CEX.

Comparison of high-liquidity pairs with dynamic fee

• For high-liquidity pairs, keep our fee small and win on volume.
• Regular fee scans (by pair / size / network) let us tune fees dynamically and stay competitive.
• Use dynamic per-pair fees: compute headroom vs DEX, set a target fee range (e.g., 0.31–0.36% on CEX routes) and a cap; adjust automatically as markets move.

Pair Auto-Discovery & Activation (MVP)

Workflows/workers + validator and activator: fully automate pair onboarding with zero manual setup, governed by thresholds and policies in the admin console

Automated trading pair discovery and activation (MVP)

Ready-to-use JSON spec for market scanning: sources, metrics (depth/volume/spread/withdraw), hard gates, 0-100 scorecard, activation policy (LIVE/PROBATION/CANARY/REJECT), monitoring cadence and auto-kill; suitable for ingestion by the validator/orchestrator.

{
  "ttl_defaults": {
    "rfq_ttl_s": 10
  },
  "tiers": ["MAJOR", "MINOR", "EXOTIC"],
  "trigger_inputs": {
    "source": "discovered_route_candidate",
    "routes_supported": ["CEX→CEX (2-leg via EUR)", "CEX→CEX (optional 3-leg via USDT)"],
    "context_fields": [
      "base_asset",
      "quote_asset",
      "notional",
      "venues",
      "networks",
      "taker_fees",
      "withdraw_fees",
      "lot",
      "tick",
      "ttl_s"
    ],
    "tiering": "pair is classified as MAJOR / MINOR / EXOTIC for thresholding"
  },
  "data_fetch": {
    "order_books": "full depth per leg",
    "recent_trades": true,
    "fees": {
      "taker": "live",
      "withdraw": "live",
      "withdraw_status": "live"
    },
    "market_meta": ["lot", "tick", "venue_health"],
    "volumes": ["5m", "1h", "24h"],
    "volatility_sigma_5m": true
  },
  "validation_gates": [
    {
      "id": "depth_0p5pct",
      "name": "Depth @ ±0.5%",
      "metric": "sum volume within ±0.5% price corridor",
      "thresholds": {
        "two_leg_min_multiple": 5,
        "weak_leg_three_leg_min_multiple": 7
      },
      "reject_on_fail": true,
      "notes": "Apply per leg; use notional as target"
    },
    {
      "id": "volume_multi_window",
      "name": "Volume (5m/1h/24h)",
      "metric": "notional coverage by window",
      "thresholds": { "5m_min_x": 1, "1h_min_x": 6, "24h_min_x": 60 },
      "reject_on_fail": true
    },
    {
      "id": "spread_bps",
      "name": "Spread",
      "metric": "(ask - bid) / mid in bps",
      "thresholds_bps_by_tier": { "MAJOR": 25, "MINOR": 60, "EXOTIC": 120 },
      "reject_on_fail": true
    },
    {
      "id": "vwap_impact_per_leg",
      "name": "VWAP impact / leg",
      "metric": "book simulation impact per leg, bps",
      "thresholds_bps_by_tier": { "MAJOR": 30, "MINOR": 45, "EXOTIC": 70 },
      "reject_on_fail": true
    },
    {
      "id": "withdraw_health",
      "name": "Withdraw health",
      "metric": "network status & fee & success rate",
      "thresholds": { "network_status": "ON", "max_fee_bps": 40, "min_success_rate_1h": 0.99 },
      "reject_on_fail": true
    },
    {
      "id": "quantization_loss",
      "name": "Quantization (lot/tick)",
      "metric": "rounding loss in bps per leg",
      "thresholds": { "max_bps_per_leg": 5 },
      "reject_on_fail": true
    },
    {
      "id": "route_cap_total",
      "name": "Route cap (Σ taker + impact + withdraw)",
      "metric": "total effective cost in bps",
      "thresholds_bps_by_tier": { "MAJOR": 65, "MINOR": 110, "EXOTIC": 180 },
      "reject_on_fail": true
    },
    {
      "id": "usdt_bridge_rule",
      "name": "USDT bridge rule (3-leg only)",
      "metric": "net advantage of 3-leg vs 2-leg, bps",
      "thresholds": { "low_taker_delta_bps_min": 13, "high_taker_delta_bps_min": 43 },
      "reject_on_fail": true,
      "applies_when": "candidate has both 2-leg and 3-leg options"
    }
  ],
  "risk_score": {
    "range": [0, 100],
    "weights_percent": {
      "liquidity_coverage": 35,
      "vwap_impact": 20,
      "spread": 15,
      "volume": 10,
      "withdraw_health": 5,
      "volatility_sigma_5m": 5,
      "venue_risk": 5,
      "quantization_loss": 5
    },
    "normalization": {
      "more_is_better": ["liquidity_coverage", "volume", "withdraw_health"],
      "less_is_better": ["vwap_impact", "spread", "volatility_sigma_5m", "venue_risk", "quantization_loss"],
      "clamp_range": [0, 2],
      "map_to_subscore": "0..100 then apply weights"
    },
    "explain_top_n": 3
  },
  "activation_policy": {
    "thresholds": [
      { "min_score": 80, "status": "LIVE", "caps": { "notional_multiplier": 1.0, "ttl_s_adjust": 0 } },
      { "min_score": 70, "max_score": 79, "status": "PROBATION", "caps": { "notional_multiplier": 0.5, "ttl_s_adjust": -5 } },
      { "min_score": 50, "max_score": 69, "status": "CANARY", "caps": { "published": false } },
      { "max_score": 49, "status": "REJECT" }
    ],
    "audit": { "persist_inputs": true, "persist_decision": true }
  },
  "monitoring": {
    "cadence_s": {
      "depth_spread_impact": { "min": 2, "max": 5 },
      "volume_volatility": { "min": 30, "max": 60 },
      "withdraw_fees": {
        "interval": 60,
        "event_driven": true,
        "ttl_s": { "min": 300, "max": 600 }
      }
    },
    "auto_kill_triggers": [
      { "condition": "spread_or_depth_out_of_bounds", "duration_s_min": 15, "action": "disable_or_downgrade" },
      { "condition": "withdraw_off_or_fee_spike_bps_gt_20", "action": "disable_or_downgrade" },
      { "condition": "execution_drift_bps_gt_15_vs_simulation", "action": "disable_or_downgrade" },
      { "condition": "risk_score_below_status_floor", "action": "disable_or_downgrade" }
    ]
  },
  "outputs_contract": {
    "status_enum": ["LIVE", "PROBATION", "CANARY", "REJECT"],
    "fields": {
      "status": "enum",
      "risk_score": "number(0..100)",
      "caps": { "max_notional": "number", "ttl_s": "integer" },
      "explain": "array[max 3] of {component, value, target, delta_bps}",
      "route_id": "string",
      "venue_ids": "array[string]",
      "timestamp": "iso8601"
    },
    "publish": {
      "route_registry_on_status": ["LIVE", "PROBATION"],
      "consumer": "RFQ/Quote API"
    }
  },
  "config_runtime": {
    "mutable_without_release": [
      "thresholds_by_tier",
      "risk_score_weights",
      "usdt_bridge_delta_bps",
      "probation_canary_caps",
      "allowed_networks_and_withdraws_per_venue"
    ],
    "audit_all_changes": true
  },
  "non_functional": {
    "sla": { "end_to_end_decision_within_s": 10 },
    "observability": {
      "store": ["inputs", "gate_results", "subscores", "final_score", "status"],
      "dashboards": ["pass_rate", "score_distribution", "auto_kill_reasons"]
    },
    "graceful_degradation": "prioritize MAJOR routes; queue without inconsistent states"
  }
}

Propose how to handle long-tail assets not listed on CEXs

For assets not listed on CEX, we build a hybrid route: CEX → EUR/USDT → (bridge) → DEX swap → target token; in parallel we search for alternative CEXs that list the pair. (I’m not fully sure we always need an EUR leg, or whether we can interact directly with aggregators.)

• Every 2 hours we scan sources (Coingecko, public tokenlists, DEX/bridge aggregators, public CEX APIs) and extend our token list. We can add a config rule that sends alerts if tokens are available on any supported CEX.
• We ran a service that updated token lists every 24 hours and ran shadow simulation on new tokens.
• If a route was built under the set parameters - all good.
• If not - a Sentry alert fired; the team reviewed the tokens and considered integrating new DEX providers to keep routing coverage across the token list at ~80–85%+.

Competitive Positioning & GTM Strategy

My hypothesis: Many DeFi products (wallets, DEXs, NFT apps) embed a meta-onramp that routes based on variables like output amount, fee, network, payment method, user location, input/output size, etc. To lift ARPU, my USP is to deliver a best-in-class solution on these axes and capture a leadership position:

• Best routing by maximizing output amount with flexible fees per asset/route
• Broad coverage of networks and assets with seamless support
• B2B segmentation
• High transaction speed
• Seamless integration via API/SDK/Widget with a high SLA and strong fault tolerance

Target audience

B2B

Cohort A: Crypto-native, non-custodial/custodial (Wallets, DEX, NFT/games, browser extensions, CEX).

• Who they are: non-custodial products with a large user base; they want retention and monetization without building an exchange; they offer a Web3 interface and aim to make the UX friendlier.
• What they want: widget/SDK with high SLA, white-label, revenue-share, broad network/asset coverage, compliance “in the background.”
• Why we’re confident: the market is widely embedding providers like Mercuryo/MoonPay/Transak/Changelly for better onboarding and retention

Cohort B: Traditional fintech / neobanks / payments / brokers.

• Who they are: financial services with millions of users, strict compliance, familiar Web2 UI;
• What they want : they need a turnkey solution: KYC/AML, reporting, SLA, white-label,API, predictable pricing, SEPA/ACH/cards, EU/US compatibility.
• Why we’re confident: 51% of US citizens are ready to buy “through their bank”; banks and neobanks are looking for licensed providers with a simple API.

Examples: Regulation is getting more friendly, crypto is entering portfolios. 401(k) plans are adding crypto options, and institutional funds actively invest in RWA products like Ondo and Centrifuge. Giants like BlackRock and Franklin Templeton offer blockchain-based treasuries. This is a signal that traditional players will create the most favorable investing conditions.

B2C

Cohort A : New users.

• Who they are: first purchases and simple swaps, no DeFi skills.
• What they want: “like a bank” : clear price, one button, fast, no gas and no technical hassle.
• Why we’re confident: widespread on-ramp embedding in wallets/neobanks; strong demand to “buy through the bank.” Our benchmark shows that at a ~$11.6k ticket, a 2-leg CEX route often delivers better net than DEX (no gas/MEV) with a more flexible, simpler UX

Cohort B : Advanced traders.

• Who they are: sensitive to price and quote breaks, move tens of thousands; depth and SLA matter.
• What they want: low net cost (bps), predictable TTL, no on-chain risks (gas/MEV), payout where liquidity is; want a bit of customization.
• Why we’re confident: our simulations show headroom vs DEX on liquid majors (especially via Binance Direct), and CEX order books digest size better.

Examples: “shift 50–100k between BTC/ETH with no slippage,” “quickly move capital across chains.”

Unique selling proposition

• All-in-one infrastructure. We provide an all-in-one infrastructure for categorized assets and the best route for B2B businesses to perform buy/swap-bridge in one click.
• Network coverage. Broad support for EVM and non-EVM networks via a flexible wallet adapter and smart routing.
• Fast integration with no standard limits. Smart routing lets us rapidly support and integrate new networks/assets without constraints on token standards (including ERC-20, 4626, and others).
• Revenue growth & scale. With minimal effort we scale the architecture horizontally and vertically, increasing revenue from current flows and opening new markets (staking, earn, LST/LRT, etc.).
• B2C as an extension. This approach also lets grow a native B2C UI (web + mobile) using a single entry point via API and our own library.

Why?

• Practical foundation 500+ experiments over the last few years from smart routing on an interoperable platform to proving product–market fit combining key components in one app.
• B2B focus. The B2B segment clearly has broader reach than B2C, and an all-in-one model lets us monetize across the entire flow.
• Multi-monetization. For Token A → Token B we earn a swap fee; by offering passive-yield assets, we also earn a share of user yield (as CEX providers already do).
• Revenue dynamics. Farming is dynamic, not static; with this approach ARPU can increase by at least 20%.

Position against DEXs: latency, slippage, gas costs, compliance, UX

Go-to-Market Strategies

GTM visualization based on the USP