> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nilemarkets.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Tenors

> Six default maturities — 1D, 1W, 1M, 3M, 6M, 1Y — plus a 60s test tenor on local. Tenor is a dynamic uint32-seconds registry; admins can add new maturities onchain without a protocol upgrade.

A **tenor** defines the maturity period of a forward contract — how long from position open until
settlement. Each tenor is a duration in seconds, and the protocol computes the exact maturity
timestamp when you open a position.

## Available Tenors

| Tenor        | Duration (seconds)    | Settlement                                  |
| ------------ | --------------------- | ------------------------------------------- |
| **1 Day**    | 86,400                | Next business day at the pair's fixing time |
| **1 Week**   | 604,800               | Same weekday next week at the fixing time   |
| **1 Month**  | 2,592,000 (30 days)   | 30 days later at the fixing time            |
| **3 Months** | 7,776,000 (90 days)   | 90 days later at the fixing time            |
| **6 Months** | 15,552,000 (180 days) | 180 days later at the fixing time           |
| **1 Year**   | 31,536,000 (365 days) | 365 days later at the fixing time           |

<Info>
  A 60-second test tenor is available in local development environments for rapid testing. It is not
  enabled on Sepolia or any public deployment.
</Info>

## Dynamic Tenor Registry

Tenors are **not a fixed enum**. They live in an onchain registry (`Config.getEnabledTenors()`) that
stores uint32 seconds values. The seconds value *is* the tenor identifier — there is no separate
label or ordinal layer.

**What this means in practice:**

* The protocol ships with the six defaults above plus one test tenor.
* Operators can register new maturities — e.g. 2 weeks, 9 months, 18 months — with a single admin
  transaction, without a contract upgrade.
* Every consumer (app, CLI, agent tooling, analytics) reads the live registry and surfaces new
  tenors automatically.
* Positions store their maturity as seconds at open time, so changes to the registry never
  retroactively affect existing trades.

See [Dynamic Registries](/nile-markets/dynamic-registries) for how this pattern extends to pairs
as well.

## Choosing the Right Tenor

<Columns cols={3}>
  <Card title="Short (1D / 1W)" icon="clock">
    **Event-driven and short-horizon trades**

    * Lowest forward premium/discount
    * Fast settlement
    * Ideal around specific data releases (NFP, CPI, central bank meetings)
    * Less time for adverse moves, but also less time for the trade to work
  </Card>

  <Card title="Medium (1M / 3M)" icon="calendar-week">
    **Monthly hedging and quarterly views**

    * Moderate forward premium/discount
    * Matches common corporate invoice and payroll cycles
    * Aligned with how interbank FX forward quotes are priced
    * Practical middle ground — enough time for a macro move to develop
  </Card>

  <Card title="Long (6M / 1Y)" icon="calendar">
    **Treasury and positioning**

    * Largest forward premium/discount
    * Suited to annual budget cycles, subscription revenue hedging, and structured cash flows
    * Use higher margin (lower leverage) — EUR/USD can move 5–10% over a year
    * Liquidity and forward curve depth still evolving in early milestones
  </Card>
</Columns>

<Tip>
  If you are unsure which tenor to use, the 1-month tenor offers a practical middle ground. It aligns
  with standard corporate hedging cycles, gives enough time for FX moves to develop, and keeps the
  forward premium manageable.
</Tip>

## How Maturity Dates Work

When you open a position, the protocol computes your **fixing timestamp** — the exact moment when
your position will settle.

<Steps>
  <Step title="Add tenor duration to open time">
    The raw maturity is your open time plus the tenor duration in seconds. A 3-month position
    opened Monday at 2 PM UTC has a raw maturity 90 days later at 2 PM UTC.
  </Step>

  <Step title="Adjust to next business day at the pair's fixing time">
    The fixing is set to the pair's configured fixing time on the next business day at or after
    the raw maturity. Weekend dates roll forward to Monday.
  </Step>

  <Step title="Fixing timestamp is locked">
    Once computed, the fixing timestamp never changes. This is when the fixing price will be
    recorded and your position can be settled.
  </Step>
</Steps>

<Note>
  The fixing time is **per-pair**. EUR/USD fixes at 4 PM UTC (aligned with the WM/Reuters London
  Fix); USD/JPY fixes at 6 AM UTC (aligned with the Tokyo 15:00 JST fix). See
  [Supported Pairs](/nile-markets/supported-pairs) for each pair's fixing time.
</Note>

## How Tenor Affects Forward Pricing

Longer tenors produce larger forward premiums because there is more time for the interest rate
differential between the base and quote currencies to accumulate.

<Accordion title="Example: forward prices at different tenors">
  Assume EUR/USD spot = 1.08000 and a forward rate of 1.5% annualized:

  | Tenor    | Forward Price | Premium Over Spot |
  | -------- | ------------- | ----------------- |
  | 1 Day    | 1.080044      | 0.4 pips          |
  | 1 Week   | 1.080311      | 3.1 pips          |
  | 1 Month  | 1.081331      | 13.3 pips         |
  | 3 Months | 1.083994      | 39.9 pips         |
  | 6 Months | 1.087988      | 79.9 pips         |
  | 1 Year   | 1.096000      | 160.0 pips        |

  Longer tenors scale roughly linearly with duration for small rate differentials. At higher forward
  rates or longer tenors the compounding gap grows.
</Accordion>

**Onchain**: each position stores its tenor as uint32 seconds in the Position struct.
**Computed**: forward prices per tenor are published by the oracle and read at trade time.

For runtime lookup in code — including raw-seconds fallback for tenors added after an SDK build —
see [TypeScript SDK](/build/typescript-sdk) and [Code Examples](/build/code-examples).