Chainlink Data Streams
- Name: Chainlink Data Streams
- URL: https://docs.chain.link/data-streams
- Category: low-latency pull-oracle infrastructure / signed market-data distribution / onchain-verifiable report-delivery middleware
- Tags: ethereum-ecosystem
- Summary: Chainlink Data Streams is worth cataloging as a distinct oracle-distribution sublayer rather than as just another page under Chainlink. Its current primary materials separate a reporting DON that reaches consensus offchain, a Data Streams Aggregation Network that stores and serves signed reports through APIs, verifier contracts that let apps prove those reports onchain only when needed, and an optional Streams Trade path that folds Automation into the retrieval-and-execution flow. That decomposition makes Data Streams a useful comparison point for Chainlink push feeds, Pyth Pro, low-latency exchange-style market-data products, and other pull-oracle systems: the real control surfaces are who forms the signed report, who serves it and with what availability guarantees, which schema and market-status fields downstream apps rely on, when verification is paid for, and whether trade execution stays with the app or gets handed to the Automation-plus-Streams Trade pipeline.
- What it does:
- Delivers low-latency signed market-data reports offchain through REST, WebSocket, and SDK access instead of pushing every update onchain by default
- Lets applications retrieve a report only when needed and then verify the DON signature onchain through a verifier contract
- Offers multiple report schemas across crypto, exchange-rate, RWA, SmartData, and tokenized-asset categories, with fields such as bid/ask, liquidity depth, market status, staleness, NAV, and corporate-action multipliers depending on the stream type
- Uses an Aggregation Network with active-active multi-site deployment, origin publishing, and concurrent multi-origin WebSocket support to make report delivery itself a distinct infrastructure layer
- Supports an alternate Streams Trade flow that combines Data Streams with Chainlink Automation so a log-triggered request can fetch a report, verify it, and execute a trade atomically onchain
- Pushes substantial risk-management responsibility back to integrators through explicit market-integrity, market-hours, and application-code guidance
- Key claims:
- The overview docs describe Data Streams as low-latency market data delivered offchain and verified onchain, explicitly contrasting its pull-based model with traditional push-based oracle updates.
- The architecture docs make the stack legible as three separate layers: a reporting DON, the Data Streams Aggregation Network that stores and serves signed reports, and verifier contracts that prove the report was not altered after DON consensus.
- The active-active architecture is analytically important because it makes delivery infrastructure itself part of the control plane: global load balancing, origin publishing, and dual-origin WebSocket consumption are all first-class availability mechanisms rather than incidental CDN details.
- Streams Trade adds a second, distinct control surface beyond data delivery. In that path, Chainlink Automation watches for log triggers, requests a report through a StreamsLookup revert flow aligned with EIP-3668, passes the report into performUpkeep, and only then lets the application execute if the verifier response is valid.
- The report-schema docs show that Data Streams is no longer just a crypto-price product. The same delivery architecture now carries crypto order-book style prices, DEX-state prices for long-tail tokens, redemption-rate streams for staked assets, RWA market-status-aware reports, SmartData NAV / AUM reports, and tokenized-equity streams with corporate-action fields.
- The developer-responsibility docs are unusually revealing because they make downstream protocol teams, not Chainlink, the owner of market-hours logic, market-integrity safeguards, fallback policy, and circuit-breaker design. That is a meaningful governance and liability split, not just a legal disclaimer.
- Data Streams clears the corpus bar because it isolates a distinct low-latency oracle-distribution pattern: offchain consensus, offchain signed-report serving, optional onchain verification, schema-level market-structure encoding, and an optional automation-coupled execution path. Keeping that layer separate makes it easier to compare who controls latency, verification cost, risk policy, and execution timing across oracle systems.
- Whitepaper: No standalone canonical Chainlink Data Streams whitepaper surfaced in this pass. The strongest primary materials were the official docs overview, architecture and schema references, developer-responsibility guidance, and the Chainlink product page; see
../whitepapers/chainlink-data-streams-primary-sources-2026-05-15.md. - Sources:
- https://docs.chain.link/data-streams
- https://docs.chain.link/data-streams/architecture
- https://docs.chain.link/data-streams/reference/report-schema-overview
- https://docs.chain.link/data-streams/reference/overview
- https://docs.chain.link/data-streams/developer-responsibilities
- https://chain.link/data-streams
Internal linkages
Control surface
- The important split is simple: the DON forms the signed report, the Aggregation Network serves it, and the app chooses when to pay for onchain verification.
- That makes report serving, schema policy, origin availability, and automation-coupled execution more important than the generic
oraclelabel. - Read this beside chainlink when the question is low-latency delivery rather than the whole Chainlink bundle.
Governance / control risk
-
The main questions are who controls schema evolution, which origins and APIs integrators depend on, how failover behaves during delivery incidents, and how much fallback responsibility is dumped on the application team.
-
The rent sits in report serving, not just report signing.
-
Last reviewed: 2026-06-02 UTC