# 24/5 US Equities User Guide Source: https://docs.chain.link/data-streams/rwa-streams/24-5-us-equities-user-guide > For the complete documentation index, see [llms.txt](/llms.txt). 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](/data-streams/reference/report-schema-v11) 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. (Image: Image) 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](#stream-switching-example-logic) 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](/data-streams/developer-responsibilities). ## Schema The data is delivered using the [RWA Advanced (v11) schema](/data-streams/reference/report-schema-v11). 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). > **CAUTION: Important: Timestamp Scope** > > The `lastSeenTimestampNs` field reflects the timestamp of the last update for the `mid` price only. This timestamp > does **not** apply to other fields in the report such as `bid`, `ask`, `bidVolume`, `askVolume`, or `lastTradedPrice`. > Different fields may have been updated at different times. > **NOTE: Bid/Ask Volume Interpretation** > > For U.S. equities, there is no single consolidated order book—multiple venues each maintain their own. The `bidVolume` > and `askVolume` reported come from one specific order book at a time, not an aggregate across all venues. These values > should not be treated as a proxy for total market liquidity and are primarily informational. ## 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](/data-streams/stream-ids) or see the [complete list below](#available-streams). For example, **TSLA** is available via the following streams: - `TSLA/USD-Streams-ExtendedHours` - `TSLA/USD-Streams-OvernightHours` - `TSLA/USD-Streams-RegularHours` > **CAUTION: Use marketStatus for Stream Selection** > > Always use the `marketStatus` field to determine which stream to consume and whether the market is currently open. Do > not rely on `lastSeenTimestampNs`, `observationsTimestamp`, or any other timestamp to infer market activity or select > among streams — timestamps indicate when data was last recorded, not the current state of the market. 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: | Market Status | Stream | | ----------------- | --------------------------------- | | `1` (Pre-market) | `TSLA/USD-Streams-ExtendedHours` | | `2` (Regular) | `TSLA/USD-Streams-RegularHours` | | `3` (Post-market) | `TSLA/USD-Streams-ExtendedHours` | | `4` (Overnight) | `TSLA/USD-Streams-OvernightHours` | > **NOTE: Note** > > Market status `0` (Unknown) and `5` (Closed) require custom handling. See the [Building a Continuous Price > Feed](#building-a-continuous-price-feed) section below. ## 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](#risks) section. If you wish to jump ahead to view an example of switching logic, jump to [Stream Switching Example Logic](#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. (Image: Image) ##### 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](#stream-switching-example-logic) 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](#stream-switching-example-logic) 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](#stream-switching-example-logic) 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](#stream-switching-example-logic) 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. Separately, the overnight stream can occasionally surface **atypical `mid` values**—including **zero**—while timestamps still update. Treat unexpected zeros or discontinuities as unsafe inputs unless confirmed against your reference logic; see [Single Provider for Extended & Overnight Data](#single-provider-for-extended--overnight-data). ##### 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](#stream-switching-example-logic) 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](/data-streams/tokenized-asset-streams). 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. > **NOTE: Note** > > Tokenized Assets are often Total Return Trackers (TRT). If used, the price should be normalized back to a non-TRT > price: `Spot_RWA_Price = Tokenized_RWA_Price / TRT_Multiplier` #### 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](#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](/data-streams/tokenized-asset-streams)** 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 > **CAUTION: Important** > > This is a simplified decision flow. Your implementation must account for all risks outlined in the [Risks](#risks) > section below, including price jumps at transition boundaries, corporate actions, public holidays, and > protocol-specific edge cases. Each protocol has unique risk requirements—design your switching logic accordingly. #### 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](/data-streams/tutorials/go-sdk-fetch) and [stream](/data-streams/tutorials/go-sdk-stream) decoded reports in your chosen SDK. > **CAUTION: Disclaimer** > > This guide represents an example of using a Chainlink product or service and is provided to help you understand how to > interact with Chainlink's systems and services so that you can integrate them into your own. This template is provided > "AS IS" and "AS AVAILABLE" without warranties of any kind, has not been audited, and may be missing key checks or > error handling to make the usage of the product more clear. Do not use the code in this example in a production > environment without completing your own audits and application of best practices. Neither Chainlink Labs, the > Chainlink Foundation, nor Chainlink node operators are responsible for unintended outputs that are generated due to > errors in code. ## 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. The following risks are closely related: - **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. **Atypical `mid` values (including zero):** In edge cases—most often during **overnight** or other thin-liquidity windows—the reported `mid` can be **zero** or otherwise not a valid economic reference, even when `lastSeenTimestampNs` is advancing. This is a different failure mode from staleness: the stream can look “fresh” while the numeric answer is unsafe for automated risk or execution. **Validate** `mid` (non-zero when required for your model, bounds vs. prior observations, spread plausibility) before using it for liquidations, collateral, or other critical paths. ##### 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 value-level checks on `mid`:** Reject or treat as invalid **zero** and other out-of-range answers; compare against your previous accepted tick and configured bands. Apply these checks especially to **Overnight Hours** (and extended-hours) reports, where single-provider risk is highest. - **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](#stream-switching-example-logic) 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](/data-streams/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.