# Futures
Source: https://docs.chain.link/data-streams/rwa-streams/futures

> For the complete documentation index, see [llms.txt](/llms.txt).

> **NOTE: Beta**
>
> Futures streams are in beta. To request access, contact
> [chainlink\_data\_feeds@smartcontract.com](mailto:chainlink_data_feeds@smartcontract.com).

Futures streams provide price data for exchange-traded futures contracts. These streams enable onchain protocols to build markets around futures price exposure. Coverage currently includes commodities — energy and precious metals — described below.

Because futures contracts expire, Data Streams does not publish one feed per contract. Instead, each instrument is represented by three **generic** feeds that always track the current front, second, and third contract. This is explained in [Rotation methodology](#rotation-methodology) below.

Developers are responsible for choosing the appropriate feed and ensuring that the operation and performance of their choice matches expectations. For more information, see the [Developer Responsibilities](/data-streams/developer-responsibilities) guidance.

## Schema

Futures streams use the v14 schema.

| Field                 | Description                                                                                                      |
| --------------------- | ---------------------------------------------------------------------------------------------------------------- |
| `mid`                 | Mid price                                                                                                        |
| `bid`                 | Bid price                                                                                                        |
| `ask`                 | Ask price                                                                                                        |
| `expiry_time`         | Contract expiration time                                                                                         |
| `roll_date`           | First day of notice, as a Unix timestamp                                                                         |
| `lastSeenTimestampNs` | Timestamp of the last update received from the data provider                                                     |
| `marketStatus`        | Market status indicator                                                                                          |
| `contract_month`      | Standard futures month code (F=Jan, G=Feb, H=Mar, J=Apr, K=May, M=Jun, N=Jul, Q=Aug, U=Sep, V=Oct, X=Nov, Z=Dec) |

## Coverage

Futures streams are currently available for the following commodities. Additional commodities and asset classes may be added based on demand.

| Commodity   | Generic feeds                  |
| ----------- | ------------------------------ |
| Gold        | Front, second, and third feeds |
| Silver      | Front, second, and third feeds |
| US Oil      | Front, second, and third feeds |
| Natural Gas | Front, second, and third feeds |

## Naming and price representation

Feed names use the plain instrument name only (for example, "US Oil," "Gold," "Natural Gas").

Contract specifications — contract size, tick size, quotation units, and similar terms — can vary between exchanges for the same underlying instrument. Chainlink does not publish these specifications, since they belong to the exchange where a given contract is listed. If your application needs exact contract specifications, consult that exchange's own public product documentation directly.

## Rotation methodology

Unlike spot instruments, futures contracts have a finite life. For example, a given month's Natural Gas contract trades for a limited window and then expires. If Data Streams published a dedicated feed per contract, integrators would need to re-point their integration to a new feed every time a contract expired.

To avoid this, each instrument is represented by three static, non-expiring **generic feeds** that always represent the near-term forward curve of eligible contracts:

| Generic feed    | Meaning                                                    |
| --------------- | ---------------------------------------------------------- |
| **Front feed**  | Tracks the nearest unexpired eligible contract             |
| **Second feed** | Tracks the next eligible contract after the front contract |
| **Third feed**  | Tracks the eligible contract after that                    |

This design means:

- **Zero maintenance.** Integrate the three generic feeds once. You never need to re-point feed endpoints when a contract expires — the feeds re-map internally.
- **Full visibility of the curve.** Because the front, second, and third contracts are exposed simultaneously, you retain full autonomy over your own rolling logic. You can roll positions on a fixed schedule ahead of expiry, or when liquidity migrates from the front contract to the second — Data Streams does not impose a roll strategy.

### How the roll works

When the front contract reaches its expiration, the generic feeds cascade forward:

- The **front feed** takes over the contract previously tracked by the second feed
- The **second feed** takes over the contract previously tracked by the third feed
- The **third feed** begins tracking the next eligible contract in that instrument's cycle

A few properties of the roll are worth calling out explicitly:

- **The roll is triggered by the front contract's expiration**, as defined by the listed expiration calendar for that specific instrument. Expiration conventions differ by instrument, so rolls for different instruments happen on different dates — there is no single "roll day" across all instruments.
- **The roll is a re-mapping, not a price adjustment.** At the moment of the roll, the front feed switches from quoting the expiring contract to quoting what was previously the second contract. Because different contract months can trade at different prices, **expect a price discontinuity on the generic feed at each roll**. Feeds are not back-adjusted into a smooth continuous series — if your application needs a continuous series, construct it from the raw generic feeds on your end.
- **Until expiration, the front feed continues to track the expiring contract**, even in its final days when liquidity has typically already migrated to the next contract. This is precisely why the second feed is exposed — so you can implement your own liquidity-based rolls ahead of expiry instead of holding the front contract to the end.

### Contract eligibility varies by instrument

The front feed does not necessarily track the nearest calendar month — it tracks the nearest unexpired eligible contract, whatever month that happens to be. Each instrument has its own set of listed contract months, and for several instruments, the actively traded contracts are only a subset of what is listed:

- **Energy** (US Oil, Natural Gas): every calendar month is listed, though liquidity is generally concentrated in nearer maturities. The generic feeds walk the full monthly strip regardless, so the front, second, and third feeds track three **consecutive** calendar months.
- **Precious metals** (Gold, Silver): many calendar months are listed, but liquidity concentrates in a benchmark cycle. The generic feeds follow the benchmark cycle only and skip non-benchmark months, even though those contracts exist and trade.

| Commodity | Benchmark months             |
| --------- | ---------------------------- |
| Gold      | Feb, Apr, Jun, Aug, Oct, Dec |
| Silver    | Mar, May, Jul, Sep, Dec      |

The practical consequence: **the gap between the front, second, and third feeds is not always one month.** For Gold or Silver, consecutive generic feeds can be one to three months apart. Do not assume monthly spacing in your integration.

### Worked example

Gold follows its benchmark cycle (Feb/Apr/Jun/Aug/Oct/Dec). In August 2026, before the August contract expires:

| Feed        | Contract tracked |
| ----------- | ---------------- |
| Front feed  | August 2026      |
| Second feed | October 2026     |
| Third feed  | December 2026    |

When the August contract expires, the front feed jumps directly to October, the second feed jumps to December, and the third feed begins tracking February 2027 — skipping the non-benchmark September and November contracts entirely, since they never appear on the generic feeds.

## Integration guidance

- **Do not hardcode contract-month assumptions.** The spacing between the front, second, and third feeds varies by instrument — one month for energy, up to a few months for precious metals.
- **Expect price steps at rolls.** A protocol using the front feed directly for margining or liquidation should either accept the step as economically correct (the front contract genuinely changed), implement its own early roll using the second feed, or build an adjusted continuous series off-chain from the raw generic feeds.
- **Roll early to avoid volatility near expiry.** In the final days of a contract's life, trading volume typically migrates to the next contract while the front feed still tracks the expiring one. Thin liquidity in the expiring contract can increase price volatility, which may unexpectedly trigger perpetual trades, liquidations, or other price-sensitive logic. If your application is sensitive to this, consider rolling ahead of expiry using the second feed.
- **Follow the listed expiration calendar.** Expiration dates follow the official listed calendar of the exchange where the underlying contract trades, including holiday adjustments. Consult that exchange for the operative source of truth.

## Trading hours

Futures trade during standard trading hours for each instrument, with a scheduled break each trading day. Consult the exchange where the underlying contract is listed for holiday and early-close schedules.

Each feed's `marketStatus` field reflects the current market status of the primary exchange venue for that instrument.

## Risk considerations

Integrating protocols are responsible for implementing appropriate monitoring and risk mitigation mechanisms to ensure safe market operation.

### Single-source data

Each Futures instrument is sourced from a single institutional-grade data provider per feed. While this enables high-frequency, low-latency delivery, it introduces dependency on that provider's data quality and availability. There is no redundant cross-validation between providers for a given feed.

If the underlying provider fails to deliver data, there is no fallback source, and a gap in data may not be immediately obvious from price alone. Protocols should continuously monitor feed freshness and implement safeguards — such as pausing trading or restricting liquidations — if updates stop arriving or a feed appears stale. Review the [Developer Responsibilities](/data-streams/developer-responsibilities) guidance before integration.

## Support

For inquiries related to a data outage, contact Chainlink Labs at [chainlink\_data\_feeds@smartcontract.com](mailto:chainlink_data_feeds@smartcontract.com).