Sardine: Kalshi crypto settlement history
REMOTE · SARDINE.INFO · 2 COMPONENTS
How often Kalshi BTC/ETH/XRP contracts settled YES, counted not forecast, with a public record
Available components
Last scanned (15 hours ago)
Scores higher than 60% of remote servers
Unreachable for 1 day in a row. Last reached 4 Nov 2026.
Category Finance and Payments
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security11
- TLS not yet verified: we couldn't open a connection to check the certificate. View diagnostics → Unverified
- Authorisation not yet verified: we couldn't confirm whether this endpoint requires it. View diagnostics → Unverified
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS not yet verified: we couldn't read the response headers to check for it. View diagnostics → Unverified
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability0
- Transport check failed: declared streamable-http, but we couldn't connect to verify it. See how to fix → View diagnostics → Fail
Schema Quality & AI Usability0
- Schema not yet verified: we couldn't read the endpoint's schema, or could read only part of its tool list.Unverified
Stability & Change Management0
- Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage0
- Tool coverage not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.Unverified
Tool Safety0
- Tool safety not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.Unverified
Capabilities0
- Capabilities not yet verified: we couldn't read the endpoint's capabilities.Unverified
Unverified: 5 categories
Categories scored 0 because we could not verify them: authentication we do not have, an unreachable endpoint, or not enough scan history. We only credit what we can confirm.
Checks we ran (3)
- HTTPS
- DNSSEC
- Transport
Checks we could not complete (8)
These are gaps on our side, not findings about this hosted endpoint. We only credit what we can confirm, so a category made up entirely of them scores 0.
- TLS certificate in Endpoint SecurityTLS not yet verified: we couldn't open a connection to check the certificate.
- Authorization in Endpoint SecurityAuthorisation not yet verified: we couldn't confirm whether this endpoint requires it.
- HSTS header in Endpoint SecurityHSTS not yet verified: we couldn't read the response headers to check for it.
- Schema quality in Schema Quality & AI Usability (scores 0 for this)Schema not yet verified: we couldn't read the endpoint's schema, or could read only part of its tool list.
- Stability in Stability & Change Management (scores 0 for this)Stability not yet verified: not enough scan history yet (needs a 30-day window).
- Tool coverage in Tool Coverage (scores 0 for this)Tool coverage not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.
- Tool safety in Tool Safety (scores 0 for this)Tool safety not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.
- Capabilities in Capabilities (scores 0 for this)Capabilities not yet verified: we couldn't read the endpoint's capabilities.
Does not apply to this hosted endpoint (2)
- Supply Chain SecurityScored on package channels only. This is a hosted endpoint, so there is nothing to install or inspect.
- Provenance & TransparencyScored on package channels only. This is a hosted endpoint, so there is nothing to install or inspect.
The score does not measure everything. What the score does not measure →
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 5 Nov 26 0
- Endpoint reachability: reachable → unreachable ▼ security
- Authorization: partial → unverified ▼ security
- HSTS header: fail → unverified ▼ security
- TLS certificate: pass → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- Stability: 0.30 → unverified ▼ security
- Transport: pass → fail ▼ security
- Schema quality: 100 → unverified ▼ functional
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- 4 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 27 to 30. That category is still filling its 30-day observation window: 8 days of observed history at the previous scan, 9 at this one. The score rises as the window fills, whether or not the server changes.
- 2 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.
- 31 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 13 to 17. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 5 at this one. The score rises as the window fills, whether or not the server changes.
- 29 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.
- 27 Oct 26 0
- Tool “get_live_board” rewrote its description, which is the text the model reads security
- Tool “get_settlement_rate” rewrote its description, which is the text the model reads security
- Schema quality: 132 → 151 ▼ functional
- Stability: unverified → 0.03 ▲ functional
- Server version: 0.1.1 → 0.2.0 functional
- New tool “backtest_signals” functional
- New tool “get_z” functional
- 26 Oct 26 69
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Probed https://sardine.info/mcp
TLS unreached
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of sardine.info. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | Trust anchor | 20326, 38696 | 8, 8 | Verified |
| info. | DS published | 9986 | 8 | Verified |
| sardine.info. | No DS | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Inconclusive
We could not reach the endpoint well enough to judge its authorisation posture.
| Result | Inconclusive |
|---|
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://sardine.info/mcp | Unreachable | ||
| http (plaintext) | http://sardine.info/mcp | HTTPS enforced |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
backtest_rule ~343
Would this rule have made money? Replays recorded Kalshi quotes, second by second. Describe a rule for Kalshi's 15-minute crypto up/down contracts: which side to buy, when (minutes left), at what prices (cents), and optionally only when Sardine's history beats Kalshi's ask plus fee by `min_gap_cents` (side BEST picks whichever side has the larger gap). Sardine replays its per-second recordings of Kalshi's order book: one trade per window, a limit order at the ask landing after `latency_seconds`, filled only up to the size resting there, Kalshi's real fee, and Kalshi's official settlement. Returns profit per contract after fees with a 95% interval, win rate, fill behaviour, a zero-latency comparison (exposes stale-quote illusions), a first-half/second-half stability check, breakdowns by minutes left and price, and warnings. Results only; no raw data. Dates are UTC YYYY-MM-DD. Present results as what happened historically, never as a forecast.
| Name | Type | Req | Description |
|---|---|---|---|
| contracts | integer | – | – |
| end_date | – | – | – |
| latency_seconds | integer | – | – |
| market | string | – | – |
| max_gap_cents | – | – | – |
| max_minutes_left | number | – | – |
| max_price_cents | number | – | – |
| min_gap_cents | – | – | – |
| min_minutes_left | number | – | – |
| min_price_cents | number | – | – |
| side | string | – | – |
| start_date | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
backtest_signals ~242
Replay YOUR OWN signals on recorded per-second Kalshi quotes, after fees. `signals` is a list of {"ts": <UTC epoch seconds>, "side": "YES"|"NO", "contracts": <int>} (at most 5,000). Each one is treated like a trigger: the ask seen at that second for that side, a limit order landing after `latency_seconds`, filled only up to the size resting there, Kalshi's fee, Kalshi's official settlement. One trade per 15-minute window: the first signal in a window is used and later ones are counted as ignored. Returns aggregates only (profit per contract with interval, win rate, zero-latency comparison, stability, breakdowns, warnings), plus `signals_used` and `signals_outside_data`. Needs a free key when served remotely. Present results as what happened, never as a forecast.
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| latency_seconds | integer | – | – |
| market | string | yes | – |
| signals | array | yes | – |
| start_date | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
get_live_board ~131
Open Kalshi contracts right now, each with Sardine's historical count. No prices. Optionally filter to one market. Each row has the contract, the minutes left, the historical settlement rate with its interval and sample size, and a one-sentence summary of the count. Kalshi's prices are deliberately NOT included (pending Kalshi's Redistribution licence): read them from Kalshi's own API, then pass kalshi_ask to get_settlement_rate for the fee and the gap.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
| market | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
get_rate_table ~85
The full lookup table behind every Sardine number for one series. Each row is a (distance-from-strike, time-left) bucket: distance in volatility units, seconds left, the share that settled YES, its 95% interval, and the number of independent windows counted.
| Name | Type | Req | Description |
|---|---|---|---|
| asset | string | – | – |
| window_minutes | integer | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
get_settlement_rate ~226
How often has a contract like this one settled in favour of `side`? Uses the asset's live spot price. Give the contract's strike (target price), the minutes left until it settles, and optionally Kalshi's ask in dollars (0.01-0.99) to get Kalshi's fee and all-in price on the same line. Returns the historical settlement rate, its 95% interval, the number of past windows counted, the 1-minute realised vol and z behind the lookup, and with `kalshi_ask`: the fee, the all-in price and the gap after fee (`gap_after_fee`, `gap_cents`, signed: positive means history is above the price). A small `windows_counted` means a weak answer.
| Name | Type | Req | Description |
|---|---|---|---|
| asset | string | yes | – |
| kalshi_ask | – | – | – |
| minutes_left | number | yes | – |
| side | string | – | – |
| strike | number | yes | – |
| window_minutes | integer | yes | – |
Structured output declared, but exposes no named fields.
No examples provided.
get_track_record ~57
How accurate Sardine's published numbers have been, scored against settlements. For each series and probability bucket: what Sardine said, what actually settled, and the miss in points. Use this before relying on any number.
Input schema present but exposes no named parameters.
Structured output declared, but exposes no named fields.
No examples provided.
get_z ~110
Where a contract sits in the table's coordinates right now: spot, sigma_1m, z and the bucket. For a builder running the table offline against Kalshi's feed: the formula is returned with the numbers. No settlement rate here; use get_rate_table for the cells and get_settlement_rate for the count.
| Name | Type | Req | Description |
|---|---|---|---|
| asset | string | yes | – |
| minutes_left | number | yes | – |
| strike | number | yes | – |
| window_minutes | integer | yes | – |
Structured output declared, but exposes no named fields.
No examples provided.
list_datasets ~56
Downloadable CSV history files, with row counts, date ranges and URLs. Files open directly in Excel, pandas or any CSV reader. Credit "Sardine (sardine.info)" when you use them.
Input schema present but exposes no named parameters.
Structured output declared, but exposes no named fields.
No examples provided.
list_markets ~84
List the Kalshi series Sardine covers, and whether each is currently served. Each entry gives the Sardine key (e.g. "BTC-15M"), the Kalshi series ticker, the window length, and the latest calibration check: the largest gap, in probability points, between what Sardine published and what then settled.
Input schema present but exposes no named parameters.
Structured output declared, but exposes no named fields.
No examples provided.
How do I install the Sardine: Kalshi crypto settlement history MCP server?
Sardine: Kalshi crypto settlement history is a hosted endpoint at https://sardine.info/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · sardine.info
claude mcp add --transport http info-sardine-sardine 'https://sardine.info/mcp'
What is the Sardine: Kalshi crypto settlement history MCP server?
Sardine: Kalshi crypto settlement history is an MCP server listed in the public MCP registry as info.sardine/sardine. How often Kalshi BTC/ETH/XRP contracts settled YES, counted not forecast, with a public record. This page covers its hosted endpoint (https://sardine.info/mcp).
Is the Sardine: Kalshi crypto settlement history MCP server safe to use?
Sardine: Kalshi crypto settlement history scores 73 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Sardine: Kalshi crypto settlement history MCP server expose?
Sardine: Kalshi crypto settlement history exposes 9 tools: list_markets, get_settlement_rate, get_live_board, get_rate_table, get_track_record, and 4 more. Their descriptions and schemas cost roughly 1,334 tokens of context every time the server is loaded.
Does the Sardine: Kalshi crypto settlement history MCP server require authentication?
Its publisher declares no required credentials for Sardine: Kalshi crypto settlement history. We have not been able to confirm that against the live endpoint, and a server can require authorisation without declaring it here.
Is the Sardine: Kalshi crypto settlement history MCP server still maintained?
Sardine: Kalshi crypto settlement history is still listed in the MCP registry, though our most recent checks did not reach this channel. We last reached this channel on 4 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What did VerifyMCP test on the Sardine: Kalshi crypto settlement history MCP server?
VerifyMCP ran 3 checks on Sardine: Kalshi crypto settlement history, covering HTTPS, DNSSEC and Transport. 8 items could not be completed, a gap on our side rather than a finding about Sardine: Kalshi crypto settlement history: TLS certificate, Authorization, HSTS header, Schema quality and 4 more. 5 categories score 0 for that reason, because we only credit what we can confirm. Supply Chain Security and Provenance & Transparency do not apply to a hosted endpoint, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.