24/5 US Equities User Guide

Chainlink 24/5 U.S. Equities Streams provide real-time equity pricing data across all major U.S. single-name equities and ETFs spanning regular, pre-market, post-market, and overnight trading sessions. The advanced RWA schema includes fields such as market status flags, best bid and ask prices, bid and ask volumes, staleness measures, and last traded prices to facilitate more advanced execution and risk management.

The data referenced in this document covers 24/5 trading hours in US equities on a range of traditional venues. While there is currently no trading activity in traditional markets over the weekend on any venue, protocols can extend their pricing coverage to 24/7 in multiple ways, such as leveraging the pricing of tokenized stocks on secondary markets such as CEXes and DEXes.

Developers are responsible for choosing the appropriate feed and ensuring that the operation and performance of their choice matches expectations. For more information, please visit the Chainlink documentation.

Schema

The data is delivered using the RWA Advanced (v11) schema.

This advanced RWA schema is built to support 24/5 streams, including DON Consensus mid price (with its corresponding timestamp lastSeenTimestampNs for staleness tracking), order book depth (bid, ask, bidVolume, askVolume), execution data (lastTradedPrice), and granular market phases (marketStatus values for Pre-market, Regular hours, Post-market, Overnight, and Closed).

Feeds

Each instrument is exposed through three distinct data streams feeds, each corresponding to a specific trading phase: Regular Hours, Extended Hours, and Overnight Hours.

You can view all available 24/5 US Equities streams in the stream table viewer or see the complete list below.

For example, TSLA is available via the following streams:

• TSLA/USD-Streams-ExtendedHours
• TSLA/USD-Streams-OvernightHours
• TSLA/USD-Streams-RegularHours

To construct a continuous price feed, users must dynamically switch between these individual streams based on the value of marketStatus. The mapping logic is as follows:

Building a Continuous Price Feed

Building a continuous price feed by dynamically switching streams requires robust exception handling to manage edge cases effectively. Because different protocols have unique risk profiles and design requirements, Data Streams allows you to implement custom logic tailored to your specific needs.

There is no one-size-fits-all solution to integrating 24/5 streams. The sections below outline edge cases you will encounter when building a continuous price feed along with recommended mitigation strategies. For information on structural risks and protocol-specific considerations, see the Risks section.

If you wish to jump ahead to view an example of switching logic, jump to Stream Switching Example Logic.

Edge Cases and Mitigation

Price Jumps at Session Transition Boundaries

When transitioning between Regular ↔ Extended ↔ Overnight sessions, noticeable price dislocations can occur.

These differences are expected and normal due to unique liquidity conditions, venues, participants, and pricing sources per session. These are not bad data; they are true market microstructure effects.

Typical jumps are 1–2%, but larger spikes (10–20%+) are possible during low-liquidity environments or impactful news cycles.

Mitigation

Phase-specific streams are provided intentionally to give users control over when and how transitions occur. Optional safeguards:

• Pause or lock market activity during transition windows
• Delay feed switching until price convergence or stability threshold is met
• Apply price smoothing (EMA/VWAP/TWAP) across transition windows
• Temporarily reference tokenized asset price (where available)

Market Status Unknown/Unavailable (marketStatus = 0)

The system may return marketStatus = 0 (Unknown). If your implementation relies on automated feed switching based on market status, you must account for this scenario.

Market status is sourced from several independent providers configured as primary/fallback. While resilient, multiple providers can fail simultaneously.

Mitigation

Consumers must treat marketStatus = 0 (Unknown) as a valid state and define deterministic behaviors when it is returned. Potential actions include:

• Pause or lock market activity
• Allow restricted trading within a bounded range (e.g., last-valid price ± threshold)
• Temporarily reference tokenized asset price (where available)

Closed (marketStatus = 5)

Market status 5 indicates the market is closed, which includes weekends, public holidays, and unexpected market closures. During these periods, all three feeds will carry stale values. This reflects true underlying market inactivity rather than an outage or failure.

Mitigation

Consumers must treat marketStatus = 5 (Closed) as a valid state and define deterministic behaviors when it is returned. Potential actions include:

• Pause or lock market activity
• Allow restricted trading within a bounded range (e.g., last-valid price ± threshold)
• Temporarily reference tokenized asset price (where available)

Stale Data Detection

Markets may stop updating due to exchange outages, circuit breakers, trading halts, or corporate actions. The marketStatus field will continue reflecting the status that it normally would. Use the lastSeenTimestampNs field (which reflects the timestamp of the last update for the mid price only) to detect staleness by comparing it against the current time. When this timestamp stops advancing, it indicates the underlying venue has stopped providing updates.

Phase-specific feeds can introduce unique behavior due to venue-specific operational characteristics and market microstructure. The following are some examples of scenarios that may occur during session transitions or under specific market conditions:

Regular Hours Session: Delayed Quote Availability at Market Open

During the first 10–20 seconds after regular hours open (9:30am ET), bid/ask quotes may not yet be available from the regular hours venue. In those cases, the reported price may still reflect the previous regular hours close rather than live market data.

Users should factor this transition period into their switching logic and consider alternative strategies during the first ~20 seconds of regular hours, such as:

• Pause or lock market activity
• Continue using the pre-market (Extended Hours) stream until fresh regular hours quotes are available
• Temporarily reference tokenized asset price (where available)

Overnight Session: Stale Bid/Ask at Session Start

During the early overnight session -- before the overnight venue begins publishing data -- the feed may display the last bid/ask prices and volumes from the previous regular session. This occurs because no new quotes are available yet from the overnight venue.

Once the overnight venue starts publishing its own quotes, the data will update to reflect current overnight market conditions. This behavior is normal market microstructure, not a data quality issue. It reflects the actual state of the market during the transition period when overnight liquidity has not yet begun.

Users relying on bid/ask data during early overnight hours should be aware of this carryover behavior and implement appropriate safeguards, such as checking lastSeenTimestampNs for staleness or widening risk parameters during overnight session transitions.

Mitigation

Consumers must have fallback logic in place when the data is stale. Potential actions include:

• Pause or lock market activity
• Use last-valid price as reference
• Allow bounded-range trading based on last-valid price
• Temporarily reference tokenized asset price (where available)

Stream Switching Example Logic

The following examples demonstrate how to implement a continuous price feed by dynamically switching between phase-specific streams. These examples use tokenized asset prices as the fallback strategy for edge cases (stale data, Unknown market status, and Closed). Developers may choose alternative mitigation strategies based on their protocol's risk requirements.

Developers interested in using tokenized assets can find the list of supported assets and schema in the Tokenized Assets documentation. Using tokenized assets carries its own risks, including liquidity limitations and price deviations from spot markets. Evaluate these factors carefully before integrating tokenized prices into your protocol.

Decision Flow

To build a continuous price feed, follow this general decision flow. This is a simplified outline that leverages tokenized asset prices as fallback; your implementation must account for all risks outlined above and in the Risks section below.

1. Fetch and decode the Regular Hours stream report to get marketStatus and lastSeenTimestampNs

2. Check staleness first:

   • If data is stale (timestamp older than your threshold) → Use Tokenized Asset stream or apply custom risk mitigation
   • If data is fresh → Continue to step 3

3. Route based on market status:

   • marketStatus = 0 (Unknown) → Use Tokenized Asset stream or apply custom risk mitigation
   • marketStatus = 1 (Pre-market) → Use Extended Hours stream
   • marketStatus = 2 (Regular) → Use Regular Hours stream
   • marketStatus = 3 (Post-market) → Use Extended Hours stream
   • marketStatus = 4 (Overnight) → Use Overnight Hours stream
   • marketStatus = 5 (Closed) → Use Tokenized Asset stream or apply custom risk mitigation

4. Apply additional safeguards as needed for your protocol (e.g., price jump checks, circuit breakers, holiday calendars, bounded trading ranges)

5. Return the mid price from the selected stream

Example Implementation Logic

This example demonstrates switching logic with tokenized asset prices as fallback. View examples in different SDK languages.

Please note that these code snippets are illustrative and may require adaptation to fit your specific environment, SDK versions, and error handling practices. Refer to the guide to fetch and stream decoded reports in your chosen SDK.

import { createClient, decodeReport } from "@chainlink/data-streams-sdk"

const client = createClient({ apiKey, userSecret, endpoint })

async function getPrice() {
  const regularReport = await client.getLatestReport(REGULAR_HOURS)
  const decoded = decodeReport(regularReport.fullReport, regularReport.feedID)

  // Check staleness (5 minute threshold)
  const isStale = (Date.now() - decoded.lastSeenTimestampNs / 1000000) > 300000

  // Determine which stream to use
  if (isStale || decoded.marketStatus === 0 || decoded.marketStatus === 5) {
    // Stale, Unknown, or Closed -> use tokenized asset
    const tokenReport = await client.getLatestReport(TOKENIZED_TSLA)
    return decodeReport(tokenReport.fullReport, tokenReport.feedID).mid
  } else if (decoded.marketStatus === 1 || decoded.marketStatus === 3) {
    const report = await client.getLatestReport(EXTENDED_HOURS)
    return decodeReport(report.fullReport, report.feedID).mid
  } else if (decoded.marketStatus === 2) {
    return decoded.mid
  } else if (decoded.marketStatus === 4) {
    const report = await client.getLatestReport(OVERNIGHT_HOURS)
    return decodeReport(report.fullReport, report.feedID).mid
  }
}

import "github.com/smartcontractkit/data-streams-sdk/go/feed"

func getPrice() (*big.Int, error) {
    report, err := client.GetLatestReport(REGULAR_HOURS)
    if err != nil {
        return nil, err
    }

    decoded, err := feed.Decode(report.FullReport)
    if err != nil {
        return nil, err
    }

    // Check staleness (5 minute threshold)
    isStale := time.Since(decoded.LastSeenTimestamp) > 5*time.Minute

    // Determine which stream to use
    if isStale || decoded.MarketStatus == 0 || decoded.MarketStatus == 5 {
        // Stale, Unknown, or Closed -> use tokenized asset
        tokenReport, _ := client.GetLatestReport(TOKENIZED_TSLA)
        tokenDecoded, _ := feed.Decode(tokenReport.FullReport)
        return tokenDecoded.Mid, nil
    } else if decoded.MarketStatus == 1 || decoded.MarketStatus == 3 {
        extReport, _ := client.GetLatestReport(EXTENDED_HOURS)
        extDecoded, _ := feed.Decode(extReport.FullReport)
        return extDecoded.Mid, nil
    } else if decoded.MarketStatus == 2 {
        return decoded.Mid, nil
    } else if decoded.MarketStatus == 4 {
        ovnReport, _ := client.GetLatestReport(OVERNIGHT_HOURS)
        ovnDecoded, _ := feed.Decode(ovnReport.FullReport)
        return ovnDecoded.Mid, nil
    }
}

use data_streams_sdk::{client::Client, feed};

async fn get_price() -> Result<i128, Box<dyn std::error::Error>> {
    let report = client.get_latest_report(REGULAR_HOURS).await?;
    let decoded = feed::decode(&report.full_report)?;

    // Check staleness (5 minute threshold)
    let is_stale = (SystemTime::now().duration_since(UNIX_EPOCH)?.as_nanos()
        - decoded.last_seen_timestamp_ns as u128) > 300_000_000_000;

    // Determine which stream to use
    if is_stale || decoded.market_status == 0 || decoded.market_status == 5 {
        // Stale, Unknown, or Closed -> use tokenized asset
        let token_report = client.get_latest_report(TOKENIZED_TSLA).await?;
        let token_decoded = feed::decode(&token_report.full_report)?;
        Ok(token_decoded.mid)
    } else if decoded.market_status == 1 || decoded.market_status == 3 {
        let ext_report = client.get_latest_report(EXTENDED_HOURS).await?;
        let ext_decoded = feed::decode(&ext_report.full_report)?;
        Ok(ext_decoded.mid)
    } else if decoded.market_status == 2 {
        Ok(decoded.mid)
    } else if decoded.market_status == 4 {
        let ovn_report = client.get_latest_report(OVERNIGHT_HOURS).await?;
        let ovn_decoded = feed::decode(&ovn_report.full_report)?;
        Ok(ovn_decoded.mid)
    } else {
        Err("Unknown market status".into())
    }
}

Risks

While 24/5 streams provide extended market coverage, they introduce specific risks related to liquidity, volatility, and data sourcing. Users must understand these factors and implement appropriate safeguards.

In the following sections, we outline key risks and recommended mitigation strategies.

Single Provider for Extended & Overnight Data

Extended and overnight session price feeds are currently sourced from a single data provider, making these sessions less reliable than the regular hours price feed which is multi-sourced.

Unlike regular hours where multiple independent sources cross-validate each other, a single provider means there is no redundant check on individual quote quality. This creates two distinct risks:

• Provider outage or disruption: If the provider experiences downtime, technical failures, or connectivity disruption, the feed may flatline or report highly inaccurate figures, which can prevent users from reacting to real price movements. Such issues may lead to mispricing, failed liquidations, and potential bad debt accumulation.
• Erroneous individual quotes: Even when the provider is operational, it may publish a single bid or ask quote that is significantly off from the prevailing market price — for example, a bid price printing far below the previous in-session price. Because there is no second source to cross-validate against, this outlier quote directly distorts the mid-price calculation, creating a large artificial price move.

Mitigation

Consumers should not rely on the staleness indicator alone. A feed can be actively updating with a technically fresh timestamp while still publishing an incorrect mid price derived from a single outlier quote. Recommended safeguards include:

• Monitor bid/ask spread: A sudden, significant widening of the spread between bid and ask is a strong indicator that a single outlier quote has distorted the mid-price. Implement a maximum spread threshold — for example, if (ask - bid) / mid exceeds a percentage beyond a configured threshold, treat the price as unreliable and restrict or pause exposure accordingly.
• Implement price deviation checks: Compare the current mid-price against a reference (e.g., the previous valid price or a short-term moving average) and trigger a circuit breaker if the move exceeds a configured threshold.
• Do not use data when marketStatus is closed: When the market is closed, data providers may perform maintenance, which can result in stale or incorrect prices being published. Consuming or acting on feed data during a closed market status is not recommended — pause or restrict all activity until the market reopens and a valid open status is confirmed.
• Check staleness via lastSeenTimestampNs: Detect when data stops updating entirely, which is a separate but complementary signal to the above.
• Pause or lock market activity when any of the above conditions are triggered.
• Restrict to narrow price bands based on a recent valid reference price.
• Temporarily switch to the tokenized asset feed (understanding that it also carries liquidity limitations).

Structural Illiquidity and Volatility in Extended & Overnight Hours

Pre-market and post-market sessions are typically thinly traded, with fragmented liquidity and higher spreads, leading to stale ticks, price gaps, and elevated volatility. These conditions are inherent to the market, not to the feed, and will be visible in the published data.

Mitigation

Users should evaluate whether the full 24/5 price coverage is appropriate for their use case. Consider the following:

• Configure risk thresholds, circuit breakers, or mode switching aligned with your risk appetite
• Validate these configurations during integration and simulation, not post-deployment

Corporate Actions

Traditional equities are subject to corporate actions which can dramatically change the price of an asset overnight, especially in the case of stock splits and reverse stock splits. These actions are usually announced outside regular trading hours and can cause substantial price movements when markets reopen.

Additionally, the overnight session data provider may disable trading for individual symbols during pending corporate actions such as dividends, splits, or mergers. When this occurs, there will be no overnight session data available for that specific symbol, and this closure will not be reflected in the marketStatus field. The overnight feed may continue to display stale data from the previous session, or the data may flatline, making it critical to monitor lastSeenTimestampNs for staleness detection.

Mitigation

Consumers should:

• Actively monitor corporate action announcements
• Adjust pricing logic, risk parameters, and open positions accordingly
• Consider pausing markets during corporate action windows to prevent unfair liquidations
• Implement staleness checks on lastSeenTimestampNs to detect when overnight session data stops updating due to symbol-specific trading halts

Trading Halts Are Not Explicitly Flagged

Trading halts can occur for various reasons including regulatory actions, pending news announcements, volatility circuit breakers, or operational issues. When the underlying market is halted, this will not be reflected in the marketStatus field.

Automated switching logic that relies only on marketStatus or staleness signals can incorrectly interpret halt inactivity as an outage or unexpected feed degradation, leading to unnecessary fallbacks, paused markets, or erroneous risk decisions.

Mitigation

Consumers must:

• Monitor exchange halt notifications and adjust protocol behavior accordingly
• Implement appropriate safeguards when trading halts are detected to prevent unfair liquidations or trades at stale prices

For detailed market hours and trading schedules, see the Market Hours documentation.

Available Streams

The table below shows all available 24/5 US Equities streams. Use the Time segment filter to view streams for specific trading sessions.