Your Edge Isn't Intuition. It's the Data You Wire In.
Most people who build a first trading bot focus on the model. The if-then rules. The position sizing. The stop-loss. All of that matters, but almost none of it is where edge comes from.
Edge comes from the data you feed in. Two bots with identical rules can produce wildly different outcomes if one of them reads a 30-second-old price and the other reads a fresh one. One of them wins; the other pays the spread.
On Turbine, every data field your bot can read lives behind a simple path: edge.<provider>.<field>. That's the whole vocabulary. You write a rule like "when edge.btc.change_15m is above 0.4%, short the contract," and the runtime resolves it against live data, with historical backfill for backtests.
This post walks through every field available right now.
What Counts as an "Edge"
Before the catalog, a definition. In Turbine, "edge" is any data source outside the venue itself. The Kalshi orderbook is not an edge. The Bitcoin spot price, the current temperature in LaGuardia, the last five minutes of volume on Coinbase: those are edges.
The reason matters. Kalshi contracts are derivatives. A "Will BTC close above $100k this week" contract is mathematically a function of what BTC spot is doing. If your bot only reads the contract price, it's watching a shadow. If it also reads the BTC spot price, it's watching the thing that casts the shadow.
Every strategy on Turbine ultimately asks: what does the outside world look like right now, and what should that do to my position on this contract? The edge.* fields are how you answer the first half.
Coinbase: Twenty-Six Fields on Every Crypto Pair
The coinbase provider wires in live spot data for any pair Coinbase lists. You select a pair with the alias:
edge.btc (resolves to BTC-USD)
edge.eth (resolves to ETH-USD)On each alias, twenty-six fields are available.
Spot and top-of-book:
price, last trade pricebid,ask,spread,spread_bps, inside quote
Change windows (percent, signed):
change_5m,change_15m,change_1h,change_4h,change_24h
High and low windows:
high_15m,high_1h,high_4h,high_24hlow_15m,low_1h,low_4h,low_24h
Volume and volume-weighted:
volume_24hvwap_1h,vwap_24h
Moving averages (derived):
sma_20_1m,ema_12_1m, fast minute-scalesma_50_5m,ema_26_5m, slower five-minute-scale
Velocity:
velocity_1m, rate of change on 1-minute resolution
The derived indicators (SMAs, EMAs, VWAPs) are computed server-side and delivered as fields, not computed in your bot. This matters: the bot sees the same number a professional quant shop would see, not a stale ±30-second approximation you'd have to compute locally from partial data.
NWS: Observations for Weather Markets
The nws provider covers live weather observations for the cities Kalshi offers daily temperature contracts on: New York, Chicago, and a handful of others. You select a station with the alias:
edge.nyc (Central Park observation)
edge.chi (O'Hare observation)Available fields:
current_temp_f, current temperaturehumidity, relative humiditywind_speed_mph,wind_direction_degpressure_mb, atmospheric pressure in millibarsdew_point_fprecip_amount_in,precip_type, precipitation if anyobservation_age_sec, seconds since the last reading refreshed
The last field is the sleeper. Weather observations update on a roughly hourly cadence. A bot that trades a daily-temperature contract at 3:42 PM wants to know whether the "current" temperature it's reading is 2 minutes old or 58 minutes old. observation_age_sec is how you condition on freshness.
Why Precomputed Indicators Matter
A lot of first-generation trading systems let you write rules against raw prices and expect you to compute indicators yourself. That sounds flexible. In practice it's expensive and wrong.
It's expensive because every bot ends up re-implementing the same VWAP calculation, badly, with subtle off-by-one bugs on how windows start.
It's wrong because the bot and the backtest end up computing indicators differently. Your backtest looks amazing, live trading loses money, and the difference is that your live VWAP was computed on 12 minutes of partial data while your backtest VWAP was computed on a clean 60-minute window.
Turbine precomputes the indicators on the server side, using the same code path for live and backtest data. Your rule sees the same number either way. That's one fewer source of backtest-to-live drift.
What's Coming
Two additions on the near horizon: social sentiment (an edge.social.* provider reading X, Reddit, and news-wire signal density), and orderbook depth as a first-class field, not just top-of-book. We'll announce these when they're in. In the meantime, the existing twenty-six Coinbase fields and the weather observation set cover the strategies that have produced the strongest backtests on the platform so far.
The Practical Upshot
You do not need a Bloomberg terminal to trade prediction markets profitably. You need two or three data signals that are genuinely relevant to your strategy, delivered fresh and consistently, with an honest backfill for backtesting.
That's what the edge.* surface is. It's not a lot of data. It's the right data.
Build a strategy that uses it.
This post is for informational purposes only and does not constitute financial advice. All strategies described carry risk of loss. Never trade with money you can't afford to lose.