18. Six Proposed Algorithms Worth Testing

Proposal A — The Tennis-Kalshi Maker

Thesis: on Kalshi in-play tennis, the durable edge is a fast, correct fair value plus event discipline — not raw speed.

Design. (1) Fair value: a hierarchical Markov model (point→game→set→match, O'Malley/Barnett tradition) driven by each player's serve-win probability, updated on every point — closed-form and microsecond-fast. (2) Quoting: AS-in-logit — compute reservation and spread on x = ln(p/(1−p)) with belief volatility σ_b, map back through the logistic; skew leans against inventory exactly as Chapter 6, with a literal (T−t) from the match state. (3) Event gating: on every point boundary (or jump detector trigger), pull/widen for a cooldown calibrated to your feed latency, reprice, re-tighten. (4) Constraints: maker-only always; quote only 30–70¢; hard per-match inventory cap.

• Data: point-by-point feed (latency is the risk budget), player serve/return priors, Kalshi L2 + queue positions.
• Parameters: γ from your loss tolerance per match; σ_b estimated per score-state from historical log-odds moves; cooldown ≈ your latency disadvantage + model compute time (typically 2–5s); cap sized so a settle-against-you is a bad day, not a bad month.
• Edge sources: spread from recreational flow; model-vs-market mispricing on re-quotes; courtsider avoidance via gating (recall the ~3.56%-in-5-seconds hazard of Chapter 8).
• Risks: feed latency loss; model misspecification at rare score states (injuries, tiebreak nerves); thin books; resolution carry.
• Testing: in Nautilus Trader, replay recorded Kalshi book deltas synchronized with the point feed; simulate maker fills with queue-position logic; requote via the Amend endpoint semantics. Primary metrics: post-fill markouts inside vs. outside the cooldown window (the whole strategy lives or dies here), inventory paths, P&L per match phase. Stress: inject simulated courtsider sweeps 0–3s after each point.

Proposal B — The Cricket T20 Maker

Thesis: the same skeleton as A survives transplantation if — and only if — the event model respects cricket's chunkier randomness.

Design. Fair value from a ball-by-ball state model (runs, wickets, balls remaining, batting depth; DLS-aware). Every ball is a potential jump; wickets and boundaries are large jumps; the innings break is a regime reset of σ_b. Spread widens on every delivery with extra width at wickets/boundaries and in death overs, where variance is maximal; inventory caps tighten as balls-remaining shrinks.

• Data: ball-by-ball feed, team/player priors, venue/pitch effects.
• Differences from A: larger jump-size variance; an explicit two-regime structure (innings 1 vs. 2 — the second innings is a chase against a known target, where the model is strongest); fewer liquid Kalshi cricket markets ⇒ wider baseline spreads and smaller size.
• Edge thesis: cricket's modeling community is thinner than tennis's; the gap between a real state model and the market's heuristics is wider — your secondary-edge intuition for T20/IPL, formalized.
• Testing: identical replay architecture to A; validate the model offline on historical T20 ball-by-ball data before quoting a cent.

Proposal C — The Polymarket Reward-Optimal Quoter

Thesis: Polymarket's liquidity rewards are a salary for parked, two-sided depth; the optimal quoter maximizes salary minus expected adverse selection, explicitly.

Design. Each minute, choose distance-from-mid d and sizes to maximize: E[reward share | d, size, competitors' depth] − γ·InventoryRisk(fills | d) − E[adverse selection | market regime]. Because the score collapses quadratically with d (Chapter 10's figure), the optimum sits as close to mid as the market's jump risk permits: in calm, long-dated markets, quote tight and harvest; in news-driven markets, the adverse-selection term pushes d out — and when it exceeds the scoring spread, the answer is "don't farm this market." Always two-sided (min(Q_yes,Q_no) scoring); rebalance inventory through the spread, never by crossing it.

• Data: reward pool size, max scoring spread and min size per market (Gamma/CLOB APIs), live depth of competing makers, your fill history, realized jump frequency per market.
• Edge sources: daily rewards (paid in pUSD, regardless of fills) + maker rebates + occasional spread capture; structurally, yield farming with a microstructure brain.
• Risks: UMA resolution risk (cap carry-to-resolution positions); reward dilution as competitors crowd; Polygon/contract risk; regime misclassification (farming a "calm" market into a news cycle).
• Testing: Nautilus Trader ships a real Polymarket adapter (outcome tokens as BinaryOption instruments, data + execution) — prototype the quoter there; the reward optimization itself is testable offline — replay book snapshots, simulate the per-minute sampling score against recorded competitor depth, and verify your projected reward share against actually-paid epochs before going live.

Proposal D — The Hyperliquid Funding-Aware Perps MM

Thesis: on a venue where funding settles hourly against the oracle, the correct inventory target is not zero — it's leaning toward the side that's being paid.

Design. GLFT quoting anchored on the oracle price (not the book mid — funding and liquidations key off the oracle), with the reservation price's q replaced by (q − q*), where the target q* = f(funding rate, conviction, caps) leans short when funding is persistently positive (shorts get paid) and long when negative. Maker-rebate tiers are a first-class objective: the engine prefers resting fills and sizes quotes to sustain tier volume. Quote only deep majors (BTC/ETH/SOL) — the JELLY chapter is a hard constraint, not advice.

• Data: L2 book, oracle feed, hourly funding prints, your fills/position, tier progress.
• Parameters: funding-bias coefficient (start tiny: |q*| ≤ 20% of inventory cap); γ from majors' realized vol; spread floored by fee math at your current tier.
• Edge sources: spread + maker rebate + funding carry — three uncorrelated trickles on one book.
• Risks: funding regime flips (carry becomes cost mid-position); oracle gaps vs. CEX moves; liquidation cascades; on-chain latency vs. CEX-informed arbs.
• Testing: Nautilus Trader strategy against replayed Hyperliquid book + funding + oracle history; simulate hourly funding settlement on the held inventory path; A/B q*=0 vs. funding-biased q* over months of replay; stress with a JELLY-style oracle/illiquidity shock even on majors.

Proposal E — The Binance Long-Tail Cross-Exchange Hedged MM

Thesis: the only durable small-operator MM niche on big crypto venues is wide-spread long-tail pairs with the inventory risk engineered away by instant hedging.

Design. Quote pair X on the venue where its spread is widest; on every fill, hedge within milliseconds on the deepest venue for X (often Binance). Quote width = max(GLFT optimal, fees both legs + measured hedge slippage + toxicity margin). A VPIN-style toxicity gate (Chapter 7) pulls quotes when bucketed flow turns one-sided — long-tail toxicity arrives in bursts when a coin moves cross-venue. Inventory that can't hedge cleanly (hedge book suddenly thin) triggers an immediate quote pull.

• Data: both venues' L2, your fee tiers, continuous latency and slippage measurements, toxicity estimator.
• Edge sources: the long-tail spread minus engineered-away inventory risk; rebates at tier.
• Risks: hedge-venue outage = naked inventory; balance fragmentation across venues; toxicity bursts faster than the gate; fee drag if hedge legs are takers (they usually are — price it).
• Testing: this is the one proposal with a ready-made lab — Hummingbot's cross_exchange_market_making strategy: configure maker venue, taker (hedge) venue, min profitability, and run paper-mode first to validate the fee + slippage inequality with live data before any capital. Graduate to Nautilus for custom toxicity gating.

Proposal F — The General-Purpose Adaptive MM (flagship)

Thesis: the catalog's algorithms are modules; composed with safety bounds, they form one engine portable across every venue in this book.

• Per-venue configuration, not per-venue code: Kalshi = model anchor, maker-only, 30–70 band; Polymarket = reward-objective in L4; Hyperliquid = oracle anchor + funding-biased q*; Binance = hedge module + toxicity gate prioritized.
• Edge sources: each layer attacks one failure mode of naive MM; the composition's edge is surviving regime changes that kill single-idea bots.
• Risks: complexity itself — interaction bugs, overfit learning, silent layer failures. Mitigation: every layer ships with a kill switch and a fixed-parameter fallback.
• Testing: build each layer as an independent Nautilus component with its own replay tests; integration-test by A/B against a frozen GLFT baseline on identical replays; promote layers to live one at a time, L5 first (safety before alpha), L4 last and clamped. A layer that can't beat the baseline on replay doesn't ship.

The recommended campaign order

1. A (tennis-Kalshi) — where regulation is clean, the API is maker-friendly, and your modeling edge is sharpest. Build the model first, the quoter second.
2. E in paper mode (Hummingbot) — cheapest way to learn cross-venue mechanics and fee math with zero custom code.
3. C — reward farming as a capital-efficient parallel income while A matures.
4. B, D — after A's replay infrastructure and D's funding data pipeline exist.
5. F — assembled from the survivors, layer by layer, never all at once.