consensus_anchor

consensus_anchor asks two betting markets the same question and averages their answers. When an event is listed on both Kalshi and Polymarket — the September Fed meeting, tonight's Tigers game — each book has its own price. This signal takes the midpoint of each book's bid and ask, averages the two, and calls the result the consensus fair value: one number, in cents, that is meant to be a better estimate than either book on its own. You set a threshold. The bot may only trade markets whose consensus clears it.

Bots using it

0 (none live, none out-of-sample, none ever)

Data source

Kalshi + Polymarket public APIs — no feed of its own

Poller · table

Neither. Computed in memory, cached 120 s

Markets it can answer for

27 of 1,552 open Kalshi markets (1.74%, checked today)

Backtest-replayable

No — though 361,439 rows of the exact number are already on disk (catch #6)

Anchor module

quants/consensus_anchor.py

This is the companion to arb_anchor, and it is worth being clear about the difference. arb_anchor gates on the gap between the two books — the disagreement. consensus_anchor gates on the blend — what the two of them jointly imply. Same plumbing, same matched pairs, opposite question. Everything the arb page says about that plumbing applies here too, so read that one as well if you are thinking of using this.

Two things make this page different from most in the dictionary. The first is good news, and it is rare enough on this shelf to lead with: the settings the site ships for consensus_anchor are real settings. The builder's default of 60¢ is open on 12.30% of the matched-market readings we have recorded; the starter bot's 55¢ is open on 21.86%. After a run of signals whose recommended numbers turned out to be permanently on or permanently off — btc_dominance_anchor's default has been unable to open since June 2024 — this one discriminates. And its validate_config is the first in this dictionary to reject a backwards band: {above:70, below:30} is refused with a real error message, where finance_anchor and four others accept the same nonsense and quietly never open.

The second thing is not good news. Right now, every single one of the eighteen Fed pairs this signal can see is matching one year's meeting against a different year's. The Kalshi leg is December 2027; the Polymarket leg is December 2026. The matcher keys on the month name and throws the year away. The docstring calls these "identical-resolution events only" and the plain-English rendering the builder shows you ends with the words "same event". Eighteen out of eighteen, they are not the same event.

Where the number actually comes from

Nowhere, in the sense this dictionary usually means. consensus_anchor has no poller, no cron job and no table. The registry agrees — it resolves the poller as null and the cron as null — and for once that is not an artefact, it is the truth. The number is computed from scratch, in the web process's memory, the moment a bot asks for it.

What it is computed from is two market feeds we already run for other reasons:

• Kalshi's public API, fetched by predictive/run_poller.sh on * * * * * — once a minute — into the kalshi_markets table.
• Polymarket's public API, fetched by predictive/run_poller_poly.sh on */2 * * * * into polymarket_markets.

When the gate is called, quants/arb.py reads both tables, pairs them by rule into matched events, and computes for each pair:

fair_cents = round( ( (kalshi_bid + kalshi_ask)/2 + (poly_bid + poly_ask)/2 ) / 2 )

That result is cached for 120 seconds in a module-level dictionary keyed by Kalshi ticker, and the gate is a two-line comparison against your threshold. That is the whole signal. There is no model, no history, no training. It is arithmetic on two prices.

The one thing the registry gets wrong

The registry reports a table called arb_anchor. No such table exists — not in predictive.db, quants.db, analytics.db or tinycorp_signal.db, all four checked. The cause is the same regex artefact that put a phantom eco_anchor table on the eco_anchor page: the registry harvests any back-ticked lowercase word out of a docstring and calls it a table, and this module's docstring mentions arb_anchor in a sentence about which signal is which.

There is a history — it just isn't the one the gate reads

Every five minutes, predictive/kalshi_finance_poller.py calls arb.snapshot(), which writes the current matched pairs — including fair_cents — into a table called cross_market_history. It holds 361,439 rows covering 1,429 distinct market pairs across 17,241 snapshots, from 10 June to today. Median gap between snapshots: 300 seconds. In sixty-four days there has been exactly one interruption longer than an hour (1.8 h, on 21 July).

That is the healthiest data pipeline described anywhere in this dictionary, and it is worth pausing on, because most of the other pages here are about feeds that died. Nothing reads this table. The gate recomputes the number live and the recording is a side effect — which turns out to be the only reason this page could be written at all, and the reason catch #6 is as damning as it is. (Small correction while we are here: arb.py's own comment says the snapshot "rides the existing kalshi poller cron". It doesn't — it rides kalshi_finance_poller at */5, which is exactly why the recorded interval is five minutes and not one.)

What it does for your bot

It is a per-market filter, not a master switch. Unlike crypto_momentum_anchor or aqi_anchor, which shut a bot down globally, this one is asked market by market: for this specific contract, is the blended fair value above (or below) my number? Markets that clear it stay in the candidate list; markets that don't are dropped.

And it fails closed on everything it cannot answer for. That is a much bigger deal than it sounds. The index is keyed by Kalshi ticker and contains only Fed rate decisions and MLB games — the only two event types arb.py has a verified matcher for. Right now that is 27 tickers out of 1,552 open Kalshi markets: 1.74%. Over the whole recorded window it has been 1,585 tickers out of the 543,978 we have ever seen. Everything else returns False. Turning this signal on does not filter your bot's universe so much as replace it.

Polymarket is worse than that. The index is keyed by Kalshi ticker; Polymarket's own ticker column holds URL slugs like will-austria-win-the-2026-fifa-world-cup. Zero of the 137,324 Polymarket rows we hold can ever match a key in this index, so a bot configured for both books — which is exactly how the starter bot ships — will never place a Polymarket trade while this gate is on. The signal reads both books and can only ever trade one of them.

Find #1 — eighteen out of eighteen Fed pairs are the wrong year

Kalshi names its FOMC markets KXFEDDECISION-<YYMON>-<OUTCOME>: KXFEDDECISION-26DEC-H0 is "no change at the December 2026 meeting". The matcher in arb.py pulls the month out with parts[1][2:] — the last three characters — and builds its lookup key from the month and the outcome only. The two-digit year is read and discarded. On the Polymarket side, _poly_fed_key() scans the title for a month name and does the same thing.

Kalshi currently lists twelve future FOMC meetings, running from September 2026 to January 2028. Four month names appear twice in that list — September, October, December, January — which means 20 of the 60 open Kalshi Fed markets are fighting over 20 keys. The pairing is built into a plain dictionary, so the loser is not reported or logged. It is simply overwritten.

Here is the entire live Fed surface, read from production today. Every row is a mismatch:

I did not take this from a code reading. I reproduced the shipped numbers by hand from the raw prices on both books, three times over, and they match to the cent. For the December no-change row: Kalshi's 2027 market is bid 51 / ask 52, midpoint 51.5; Polymarket's 2026 contract is bid 68 / ask 69, midpoint 68.5; average them and round and you get 60, which is exactly what the live index serves. The correctly-matched pair — Kalshi's 2026 market, bid 68 / ask 73 — gives 70.

The knock-on for its sibling signal is worse than for this one. The cross-book gap that arb_anchor reads and that the arbitrage page displays as an edge is currently averaging 10.78¢ across these pairs. The correctly-matched gap is 1.61¢. Roughly six-sevenths of the Fed "edge" on that surface right now is a calendar artefact, not a disagreement between traders.

It happened at 16:20 UTC on 16 June, and we recorded it

The pairs were right when the recording started. At 16:15 UTC on 16 June the September pair was KXFEDDECISION-26SEP-H0 against Polymarket's September 2026 contract, consensus 74¢. At 16:20 — the very next snapshot — the Kalshi leg was KXFEDDECISION-27SEP-H0 and the consensus was 64¢. Nothing happened in the world. Kalshi listed its 2027 calendar, the new tickers landed later in the result set, and they took the keys. June, July and September all flipped in that same five-minute window. The June pair flipped the day before the June 2026 meeting it was supposed to be tracking.

Ten cents in one poll, and the label on the row still said "September 2026" — because fed_pairs() builds its display label as the month name plus the hardcoded string " 2026". That is why our own recorded history contains 1,684 rows labelled "January 2026", a meeting that took place seven months before the row was written, whose meeting_date column in the same row reads 2028-01-26.

What it has cost on the market that matters

"Will the Fed hold rates in September 2026" is the single most liquid contract in this signal's universe and the only kind of market the shipped starter bot can reach. Both legs of the correct pair have full price history in market_price_snapshots, so I rebuilt what the consensus should have been, day by day, and set it against what the gate actually read. Fifty-three consecutive days, 22 June to today:

• Mean absolute error 4.22¢; largest 11¢.
• Mean signed error +0.71¢ — so it is not a bias you could correct for. It is noise, which for a threshold gate is worse.
• At the starter's 55¢ the two versions disagree on 5 of 53 days. At the builder's default 60¢ they disagree on 11 of 53 — one day in five.

That last number is the honest measure of the defect. One day in five, on the flagship market, the gate says trade when it should say stand down, or the reverse.

Find #2 — "better than either book alone" does not replicate

The module's docstring makes a specific, testable claim: the blend is "the single consensus probability a trader actually wants, better than either book alone." We can check it, because 107 of the matched MLB pairs in our recorded history have since settled and Kalshi tells us which way.

For each of those, I took the last reading before the game started and scored three forecasts against the real result with the Brier score — the standard measure for probability forecasts, where lower is better and 0.25 is what you get from knowing nothing but the base rate.

The blend came third of four, a rounding error behind Kalshi's own midpoint. Paired bootstrap on the same 107 games: consensus minus Kalshi mid is +0.00017, 95% CI [−0.00502, +0.00535]; consensus minus Polymarket is −0.00174, CI [−0.00720, +0.00363]. Both intervals straddle zero comfortably.

So the honest verb is "unsupported", not "false". With 107 games we cannot tell these three apart, and we would not expect to — major-league moneylines are close to coin flips and all four forecasts sit within 0.007 of the base rate. What we can say is that after two months of recording, the claim printed in the code has no evidence behind it, and the one ordering we did observe puts the blend below one of its own ingredients.

Find #3 — a second test, and a correction we owe you

A single result on 107 games proves little, so here is an independent check that needs no settlements at all, only arithmetic. Each FOMC meeting has five mutually exclusive outcomes — hold, cut 25, cut more, hike 25, hike more. Exactly one must happen, so a coherent set of probabilities has to sum to 100¢. How close each book gets is a measure of how much like a probability its numbers really are.

The first version of this test, which was on this page for about an hour, was wrong, and the correction reverses its conclusion. It compared the sum of Kalshi's asks against a consensus built from midpoints — an ask sum is inflated by the spread by construction, so Kalshi was always going to lose — and it ran over the mismatched pairs from Find #1, where the Kalshi legs are thinly-quoted 2027 contracts. It produced a headline number of 43.84¢ for Kalshi against 5.70¢ for the blend. That comparison was not like for like and the number meant nothing.

Done properly — year-correct pairs only, midpoints on both sides, across 53 meeting-days rebuilt from stored prices for all ten legs of each meeting:

All three within 0.2¢ of each other. The blend is nominally the most coherent of the three, and beats Kalshi's midpoint on 27 of the 53 days — which is to say, a coin flip. The honest verdict is a wash, and the corrected test agrees with the Brier test rather than adding to it: we cannot tell these three apart.

That is not a mystery and it is not a bug. It is what an unweighted average of two correlated estimates does — it lands between them, and can only beat both if their errors point in opposite directions. Here the two books already correlate at r = 0.80 across our whole record (0.97 on baseball), so there is very little room between them for a blend to occupy. And the average is a fixed 50/50, blind to which book is liquid and which is thin. If you wanted a blend that could genuinely beat both, the obvious candidate is weighting each book by how tightly it is quoted rather than splitting evenly — that is not what this does, and nobody has tested it.

What the blend does buy you is insurance. Without knowing in advance which book is sharper on a given market, averaging lands you near the sharper one. That is a real and unglamorous benefit. It is not "better than either book alone".

The catch

The case for the defence

What this page does not tell you

• 107 settled games is a small sample and the games are not independent draws. They are the subset our matcher indexed, chosen by which team disagreed more across books — a selection on disagreement, which is not neutral. Games on the same night share weather, umpires and a slate, so the bootstrap intervals above are, if anything, too narrow; widening them only reinforces "we cannot tell these apart". I could not measure which way the selection biases the comparison, so treat Find #2 as "no evidence for the claim", not "evidence against it".
• 361,439 rows is not a sample size. It is a five-minute recording of about 20 to 40 live pairs — 1,429 distinct markets, 2,894 market-days. Anywhere a percentage on this page compares two rules, it is computed on the market-days. Where a figure describes how much of the time something was true — the duty cycles, say — the five-minute readings are the right unit, because that is a measure of clock time and not of independent evidence.
• Nobody has actually run this gate. Everything here measures the number the gate reads. The thing that ships is a bot, and the honest final test — paper-trading {above: 55} against a plain 55¢ price filter at the ask, with fees — has not been done, because the signal is not replayable in the backtester (catch #6) and no bot has ever been armed with it.
• The Kalshi midpoint in that test is reconstructed, not stored. cross_market_history keeps the Kalshi ask and the Polymarket price but not the Kalshi bid, so I recovered the midpoint algebraically from the stored fair value. That is exact for MLB — where the Polymarket leg uses one outcome price as both bid and ask — which is why the test is restricted to MLB and excludes the two settled Fed rows.
• The 53-day reconstruction in Band C covers one market. The most important one, and the only one with complete stored history on both correct legs, but one. The 4.28¢ figure across all 18 live pairs is a snapshot of today, not an average over time.
• I have not checked whether the year collision affects the MLB side. MLB games are matched on team set plus start time within six hours, which has no year field to lose, and 690 of 696 games behaved consistently — but I tested the Fed matcher, not the baseball one.
• No trades were examined, because none exist. Everything here is a measurement of the signal, not of a strategy that used it.

The record: there isn't one

No bot has ever used consensus_anchor. Not live, not out-of-sample, not archived, not as a draft. 0 of the 76 strategy configurations on the site mention it, 0 of 88 saved strategy versions, and 0 of the 1,064 configurations in the genome bank. There are no trades, no fills, no evaluations and no profit or loss, and this page invents none.

Which makes it the third signal in this dictionary with a starter bot, a builder recipe and a builder default that nobody has ever clicked. "Market-Consensus Favorite" is on the starters shelf right now: buy YES on economics markets priced 40–85¢ when the blended consensus is above 55¢. Its universe is Fed decisions, since those are the only economics markets in the index. Run the full funnel over our recorded history and seven distinct markets have ever cleared both its price band and its gate — and every one of the seven is a "No change" outcome. It is a bot that buys "the Fed holds rates", six meetings in a row. That may well be a reasonable bet. It is not the diversified consensus-following strategy the blurb describes, and — see catch #1 — for most of the recorded window it would have been reading the wrong year's meeting.

Everything on this page traces to one of three places: the output of python3 -m quants.signal_registry --json; the source of quants/consensus_anchor.py and quants/arb.py on the production server; or a read-only query against predictive.db and quants.db whose window is stated where the number appears. The recorded window is 10 June – 13 August 2026, 361,439 pair-readings. Settlement outcomes are Kalshi's own result field. Live figures were read from production on 2026-08-13. The registry's arb_anchor table does not exist and the page says so; its live_bots: 0 is correct, and here 0 really does mean 0. All TinyCorp bots trade simulated money.
New here? What is a signal? · Glossary · How a bot works