DFS Desk Strategy Spec

DraftKings Daily Fantasy + Kalshi Cross-Platform Signals

Date: 2026-03-28

Panel: Opus + Sonnet + Grok 4.2 + Gemini Pro 3.1 (Grade: A)

OVERVIEW

The DFS desk has two value streams:

1. Win DraftKings DFS contests (Cash, GPP, H2H) using custom projection models, ownership leverage, correlation stacking, and late-swap exploitation
2. Beat Kalshi player props using DK salary as implied projection, ownership as crowd signal, and late-swap patterns as information signal

DraftKings is the primary DFS platform. FanDuel sportsbook remains the sharp anchor for player props — DFS crowd wisdom is secondary and generally inefficient (Gemini's critical correction).

PART 1: WINNING DFS CONTESTS

Contest Types and Optimization Targets

Core Formulas

Cash Score (lineup optimization target):

CashScore = 0.7 * Projection + 0.3 * Floor(P10)

GPP Score:

GPPScore = 0.5 * Projection + 0.5 * Ceiling(P90) - 0.3 * (ProjectedOwnership * 100)

H2H Score:

H2HScore = 0.6 * Projection + 0.25 * Floor(P10) + 0.15 * Ceiling(P90)

Floor/Ceiling Distributions

Single-point projections are insufficient. Model the full distribution using gamma fit:

Score ~ Gamma(k, theta) + shift
Floor(P10) = gamma.ppf(0.10, k, theta) + shift
Ceiling(P90) = gamma.ppf(0.90, k, theta) + shift

Fit from player's last 30-game DFS score distribution.

Thresholds:

• Cash: Floor > 3x Salary/1000
• GPP: Ceiling > 5x Salary/1000

Ownership Leverage (GPP)

Ownership-Adjusted Value (OAV):

OAV = (our_projection - consensus_projection) / projected_ownership

Ownership Leverage Rating (OLR):

OLR = (edge / salary) / sqrt(projected_ownership)

Thresholds:

• GPP: OAV > 1.5 or OLR > 1.2
• Cash: ignore ownership, focus on floor
• H2H: mild tilt (OAV > 0.5)

Sum of Ownership Cap (Gemini):

Lineup_Own_sum = sum(Own_i for all players)

Keep GPP lineup sum ownership below 120% for large-field tournaments.

Contrarian triggers:

• Player owned 30%+ but our projection is below consensus → FADE
• Player owned <8% but our projection is 10%+ above consensus → CORE GPP PLAY

Correlation Stacking

Build pairwise correlation matrices from historical DFS scores. For GPPs, maximize lineup variance through positive correlations. For Cash, minimize variance.

NBA Stacking:

• Primary: 3 players from same team in high-total game (Vegas total >= 228)
• Bring-back: 1 opposing player (captures shootout)
• Target: Game_Attractiveness = implied_total * (1 / (1 + abs(spread)))
• WARNING: PG and PF on same team negatively correlate — steal rebounds/assists from each other (Gemini)

NHL Stacking:

• Primary: PP1 line stack (C + W + W) — correlation r = 0.35-0.50
• Goalie: align with own team's defense
• Target: games with total >= 6.0

MLB Stacking:

• Primary: 4-5 hitters from same team, adjacent batting order (3-4-5)
• Stack against weak pitchers (high SIERA/xFIP)
• Stack_Score = implied_team_total * (1 - pitcher_quality_pct) * handedness_factor
• Negatively correlate opposing batters and pitchers (Cov ~ -0.4)

Correlation thresholds:

• r > 0.30: Strong stack (GPP)
• r 0.10-0.30: Mild positive (Cash OK)
• r < 0.05: Uncorrelated (diversification)
• r < -0.10: Negative — GPP contrarian play or avoid

Late-Swap Exploitation

Largest underexploited edge in DFS. Most casual players set-and-forget.

Information triggers (ranked by priority):

1. Confirmed scratch/out — backup's usage spikes, most casuals won't swap
2. Starting lineup confirmation — locks in minutes projection
3. Vegas line movement — reprices all affected players
4. Weather changes (MLB) — adjust hitter/pitcher ceilings

NBA usage boost:

• Star SG/SF out → backup gets +25-35% usage
• Star C out → backup C gets +30-40%

Dynamic programming for late-swap (Gemini):

• Trailing (bottom 50% after early games): Pivot remaining slots to high-variance, low-ownership (<5%) — maximize P99 finish
• Leading (top 1% after early games): Swap to highest-median players, ignore ownership — protect the lead

Sport-Specific Metrics

NBA:

• Pace_Adjusted = base * (matchup_pace / league_avg_pace)
• Usage_Boost = base * (1 + teammate_absence_usage_increase)
• UAP = (Usage_Rate * Minutes * 0.4) + Opponent_Defensive_Adj
• Back-to-back: 0.95x multiplier, 2+ days rest: 1.02x
• Foul trouble risk: penalize floor +5% for players >3.5 fouls/40min

NHL:

• PP_TOI_Share is the ceiling driver — PP1 promotion = +15-25% projection jump
• LSV = (Line_Shots * Line_GPG * 0.3) + PP_Bonus
• Goalie: model win probability AND save projection separately

MLB:

• BvPE = (wOBA_vs_Handedness * 0.5) + (Park_Factor * 0.2) - xFIP_Adj
• Park factor: Coors +15-20%, pitcher-friendly parks deflate
• Weather: wind out at Wrigley = ceiling boost for hitters
• Platoon advantage: opposite-hand = 1.15x multiplier

PART 2: BEATING KALSHI WITH DK DATA

Critical Rule (Gemini)

DFS crowd is NOT smart money. When FanDuel or Kalshi disagrees with DFS ownership, the sportsbook is almost certainly correct. DK data is a SECONDARY signal — FanDuel remains the sharp anchor.

Signal 1: DK Salary as Implied Projection

Step 1: Salary-to-FP regression (fit from historical data):

DK_Implied_FP = a * salary + b

NBA example: DK_Implied_FP ≈ 0.0057 * salary - 2.5

Step 2: Decompose FP to individual stats using player's historical distribution:

Implied_Points = DK_Implied_FP * (pts_share / pts_FP_weight)

Step 3: Convert to probability at Kalshi threshold:

P(over T) = 1 - NormalCDF((T - implied_stat) / historical_std_dev)

Use Normal for volume stats (points, rebounds). Poisson for count stats (blocks, steals).

Step 4: Compare to Kalshi:

edge = DK_implied_prob - kalshi_implied_prob

Trade threshold: edge >= 5 cents WITH FanDuel confirmation.

Signal 2: Salary Momentum

Salary_Momentum = (today_salary - avg_salary_last_5_slates) / avg_salary_last_5_slates

• Up > $700: DK expects 10%+ more production → check if Kalshi reflects this
• Down > $700: Short the over on Kalshi

Highest-alpha signal — DK salary changes are proprietary information embedded in pricing.

Signal 3: Ownership as Crowd Wisdom (use cautiously)

DFS ownership is actionable ONLY when it confirms the FanDuel sharp anchor:

Where DFS crowd is informative: Blowup spots (backup starting), pace environments Where DFS crowd is wrong: Mean reversion, low-volume stats (steals/blocks)

Signal 4: Late-Swap as Information Signal (highest alpha, most time-sensitive)

OwnershipDelta = OwnershipAt(lock - 5min) - OwnershipAt(lock - 60min)

• Delta > +8% in final hour → mass swap toward player (positive news)
• Delta < -8% → mass exodus (negative news)

Cross-platform execution window: 5-15 minutes. Requires automation — manual is too slow.

If DFS projections for a backup's minutes jump from 12 to 32 → execute immediate BUY on Kalshi for that player's props before market makers adjust.

POSITION SIZING

DFS Contest Sizing

• Maximum single contest entry: 2% of bankroll
• Maximum daily DFS exposure: 10% of bankroll
• GPP entries: spread across multiple lineups (3-5 per slate)
• Cash: single lineup per contest

Kalshi Cross-Platform Sizing

Same as Player Props desk:

• Maximum single prop bet: 3% of bankroll
• Minimum edge: 5 cents with FanDuel confirmation
• Late-swap signal: full size, execute within 5 min

DATA SOURCES

COLLECTION SCHEDULE

BUILD PRIORITY

PANEL RULING REFERENCE

Full ruling: /home/ubuntu/edgeclaw/results/panel-results/dfs-panel-ruling.md Panel: Opus (judge) + Sonnet + Grok 4.2 Reasoning + Gemini Pro 3.1 Date: 2026-03-28, Grade: A

TODO: Upgrade Kalshi REST to WebSocket Feed

Status: NOT BUILT — add when this desk goes live for execution

Current state: All Kalshi data (prices, order books, trades) is fetched via REST API polling on cron schedules. This is fine for edge detection and monitoring, but NOT sufficient for live trade execution.

Why WebSocket matters:

• REST polling introduces lag — by the time you see a price, it may already be gone
• On tight edges (2-5 cents), even 1-2 seconds of lag can eat the entire edge
• WebSocket gives real-time order book deltas and trade notifications
• Essential for hitting specific fill prices and monitoring execution quality

Note: Sports markets use RFQ (Request for Quote) so the visible order book is usually empty — but the trade feed still matters for freshness signals and the WebSocket is required for order submission. Weather and politics markets DO have real visible order books where this upgrade is even more critical.

Added 2026-03-29 — upgrade REST to WS when desk moves to live execution