DEV Community

ScriptMasterLabs
ScriptMasterLabs

Posted on Originally published at scriptmasterlabs.com

Fact Verification API for AI Agents: Cross-Checking Market Data Across 5 Providers

A single market-data reading is a claim, not a fact. SML Truth Verify cross-checks a ticker reading across independent market-data providers and returns the readings, the spread, the variance and a proof hash — disagreement shown, never averaged away.

Measured live on 2026-10-15

  • GET /api/truth/providers → HTTP 200, free: Alpaca, FRED, Massive, Polygon and Tradier live; Alpha Vantage not configured — 5 of 6 providers answering before any payment.
  • GET /api/truth/verify/AAPL → HTTP 402 in 0.95 s, quoting $0.005 (5,000 atomic USDC, Base mainnet) per cross-check.
  • A provider failure is reported as missing evidence. It is never replaced with synthetic consensus, and a 402 challenge is a price quote, not proof of delivery.

Scope, honestly

General fact-checking services verify statements and citations. This route is deliberately narrower: it verifies market-data claims — whether independent providers agree on what a ticker is doing right now — for agents that make decisions on price readings.

Full evidence and claim receipts: the canonical link on this article.

Top comments (1)

Collapse
 
arhancanli profile image
Arhan Canli •

Two things I'd want pinned down before reading the spread as independent agreement.

First, the provider list: as far as I know Polygon.io rebranded to Massive in late 2025, so "Polygon" and "Massive" may be one upstream under two names. If so, two of the five agreeing is one source agreeing with itself. Worth stating which entries have distinct upstream feeds (Alpaca's free tier is IEX-only, for instance, while a consolidated feed prints different last-trade prices and volumes).

Second, FRED. Its market series (SP500, NASDAQCOM, DGS10) are end-of-day values published with a lag, not "what a ticker is doing right now", so a spread against live quotes would measure timing, not disagreement. Each reading probably needs an as-of timestamp and a delayed/real-time flag, and the variance should only be computed across readings with the same basis.

Do the receipts record each provider's own timestamp, or only the time of the call?