Chainlink Data Streams primary sources

Reviewed: 2026-05-15 UTC

Core product framing

  • https://docs.chain.link/data-streams
    • Best concise official overview. Explains the pull-based low-latency design, on-demand report retrieval, onchain verification, comparison with push feeds, active-active availability posture, and the Streams Trade variant.
  • https://chain.link/data-streams
    • Best official product page for how Chainlink currently markets Data Streams: sub-second delivery, modular report design, tokenized-market support, and enriched market fields such as market-status and liquidity indicators.

Architecture and control-plane split

  • https://docs.chain.link/data-streams/architecture
    • Most important architecture source in this pass. Separates the reporting DON, the Data Streams Aggregation Network, verifier contracts, and the alternative Streams Trade path that combines Data Streams with Chainlink Automation.
  • https://docs.chain.link/data-streams/reference/overview
    • Useful reference entrypoint because it clarifies the split between the signed Data Streams API and the separate candlestick-oriented API, plus the authentication and verification paths across SDKs, REST, WebSocket, EVM, and Solana.

Report schemas and market-structure encoding

  • https://docs.chain.link/data-streams/reference/report-schema-overview
    • Best source for what kinds of information Data Streams actually carries. Shows the schema split across crypto, exchange-rate, RWA, SmartData, and tokenized-asset reports, including market-status flags, staleness fields, liquidity-weighted bid/ask data, NAV/AUM data, and tokenized-equity corporate-action fields.

Shared-responsibility and downstream risk policy

  • https://docs.chain.link/data-streams/developer-responsibilities
    • Important analytical source because it explicitly pushes market-integrity and application-code risk management onto integrators. Useful for comparing Chainlink’s low-latency oracle model against systems where the oracle provider claims more responsibility for market-hours handling, circuit breakers, or stream-selection logic.

Main takeaways from this pass

  • Chainlink Data Streams is best treated as a distinct low-latency oracle-distribution layer, not merely as another feed SKU under the broader Chainlink brand.
  • The key control-plane split is between offchain consensus formation (DON), report serving and uptime policy (Aggregation Network), optional onchain verification (verifier contracts), and execution orchestration (the Streams Trade + Automation path).
  • The report-schema surface is one of the strongest reasons to keep Data Streams separate in the corpus: the same transport layer now carries very different market structures, from crypto liquidity-weighted bid/ask data to RWA market-status fields to tokenized-equity corporate-action parameters.
  • The active-active multi-site design matters analytically because it turns delivery availability, origin discovery, and multi-origin subscription policy into explicit oracle infrastructure rather than invisible backend implementation.
  • The developer-responsibility docs matter because they show that low-latency oracle design does not remove downstream protocol governance; it often relocates it into app-side market-hours logic, stream selection, fallback policy, and circuit breakers.
  • Good comparison targets after this pass: Chainlink push feeds, Pyth Pro, Switchboard low-latency / pull products, RedStone-style pull delivery, and any oracle/market-data system where serving signed reports is separated from settlement-time verification.