> ## 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.

# FAQ

> Answers to common questions about collateral (USDC only), fees (0.05% trading), leverage (up to 50x), liquidation, testnet access, and the difference between forwards and perpetuals

## General

<AccordionGroup>
  <Accordion title="What is the Open Nile Protocol?">
    The Open Nile Protocol enables EUR/USD non-deliverable forward (NDF) trading onchain. Traders take long or short positions on future EUR/USD exchange rates with fixed maturity dates (tenors). The protocol is a zero-sum system: trader profit equals pool loss, and vice versa. An ERC-4626 liquidity pool acts as the counterparty to all trades, earning fees and liquidation penalties in return.
  </Accordion>

  <Accordion title="What network is the protocol deployed on?">
    The protocol is currently deployed on **Ethereum Sepolia testnet only**. This is experimental software and should not be used with real funds. Mainnet deployment is planned for the M3 (Mainnet Ready) milestone, following professional audits and formal verification.
  </Accordion>

  <Accordion title="What collateral does the protocol accept?">
    The protocol uses **USDC** (6 decimals) as its sole collateral token. On Sepolia (M2), the protocol uses a MockUSDC token for testing purposes. Production deployment (M3) will use canonical USDC on mainnet.
  </Accordion>
</AccordionGroup>

## Trading

<AccordionGroup>
  <Accordion title="What tenors are available?">
    Three tenors are available for trading:

    | Tenor   | Duration |
    | ------- | -------- |
    | 1 Day   | 24 hours |
    | 1 Week  | 7 days   |
    | 1 Month | 30 days  |

    A 60-second test tenor is also available in local development environments for rapid testing.
  </Accordion>

  <Accordion title="What is the minimum position size?">
    The minimum position size is **100 USDC** (100,000,000 raw units with 6 decimals). This parameter is configurable by the protocol admin via the Config contract and may be adjusted in future deployments.
  </Accordion>

  <Accordion title="How is my PnL calculated?">
    PnL is calculated based on the difference between the current forward price and your entry price:

    * **LONG position:** `PnL = notional * (currentPrice - entryPrice) / 1e18`
    * **SHORT position:** `PnL = notional * (entryPrice - currentPrice) / 1e18`

    Your entry price is locked at the time the position is opened and does not change. PnL is unrealized until the position is closed or settled at maturity.
  </Accordion>

  <Accordion title="Can I get liquidated?">
    Yes. If your position equity (margin + unrealized PnL) falls below the **maintenance margin (MM)** threshold, your position becomes liquidatable. Any keeper can trigger the liquidation, and a liquidation penalty is applied. The penalty is deducted from your remaining margin and accrues to the liquidity pool.

    <Tip>
      Monitor your position equity and add margin before it approaches the maintenance margin level to avoid liquidation.
    </Tip>
  </Accordion>
</AccordionGroup>

## Liquidity Providers

<AccordionGroup>
  <Accordion title="How does the LP vault work?">
    The liquidity pool is implemented as an **ERC-4626 vault**:

    1. **Deposit** USDC into the vault and receive share tokens in return
    2. Share tokens represent your proportional ownership of the pool
    3. **Share price** reflects pool performance — it increases when the pool earns trading fees and liquidation penalties, and decreases when traders are net profitable
    4. **Withdraw** by redeeming shares for USDC at the current share price

    Withdrawals are subject to utilization limits — if the pool's capital is heavily utilized by open positions, some liquidity may be temporarily locked.
  </Accordion>

  <Accordion title="What are the risks of providing liquidity?">
    The pool is the counterparty to **all** trader positions. Key risks include:

    * **Directional risk** — If traders are net profitable over a period, the pool (and LP share value) decreases
    * **Utilization risk** — High utilization may temporarily prevent withdrawals
    * **Smart contract risk** — As with any DeFi protocol, there is inherent risk in the smart contract code

    However, the pool benefits from:

    * **Trading fees** collected on every position open and close
    * **Liquidation penalties** seized from underwater positions
    * **Diversification** — many positions in different directions tend to offset each other

    <Warning>
      The protocol is currently on testnet only. Do not provide liquidity with real funds until mainnet launch.
    </Warning>
  </Accordion>
</AccordionGroup>

## Why?

<AccordionGroup>
  <Accordion title="Why EUR/USD first?">
    EUR/USD is the world's most traded currency pair — over \$1 trillion in daily spot volume with the deepest oracle support from Pyth Network. It also has the clearest demand: crypto-native companies with European operations, EUR-denominated invoices, and non-USD treasury needs. Starting with the most liquid, best-supported pair minimizes oracle risk while serving the largest user base.
  </Accordion>

  <Accordion title="Why not use perpetual futures for FX hedging?">
    Perpetual funding rates average \~11% annualized and fluctuate unpredictably with market demand. A 1-month EUR/USD hedge via perps costs roughly \$917 per \$100K notional in funding alone. The same hedge with a Nile Markets forward costs \$50 (0.05% trading fee). Forwards also settle on a specific date, which matches how real-world FX obligations (payroll, invoices) work. See [Forwards vs Perpetuals](/nile-markets/forwards-vs-perpetuals) for a detailed comparison.
  </Accordion>

  <Accordion title="Why isolated margin instead of cross margin?">
    Risk containment. In cross margin, a single bad trade can drain your entire account. With isolated margin, each position's risk is capped at its own locked margin. Your other positions and free collateral are completely unaffected by any single liquidation. This is safer for both traders (no cascading losses) and the protocol (clearer risk boundaries).
  </Accordion>

  <Accordion title="Why the zero-sum pool model?">
    The pool-as-counterparty model eliminates the need for order matching. Any trader can open a position at any time, as long as pool capacity allows. There is no waiting for a counterparty, no order book spread, and no liquidity fragmentation across price levels. LPs earn fees as compensation for bearing the directional risk that traders create.
  </Accordion>

  <Accordion title="Who provides liquidity?">
    Anyone can deposit USDC into the protocol's ERC-4626 vault and become a liquidity provider. LPs earn 70% of all trading fees (0.05% per trade) and liquidation penalties (0.30% per liquidation). In return, they bear the counterparty risk of all open trader positions. See [LP Risk & Reward](/deploy/lp-risk-reward) for scenario analysis.
  </Accordion>
</AccordionGroup>

## Technical

<AccordionGroup>
  <Accordion title="Why are there no proxy upgrades?">
    All protocol contracts are **immutable** — once deployed, the contract code cannot be changed. This is a deliberate security choice that eliminates an entire class of upgrade-related risks (malicious upgrades, storage collisions, governance attacks on proxy admin).

    Protocol parameters (fee rates, margin requirements, risk caps, etc.) are configurable via the **Config contract** by the admin, but the logic itself is fixed.

    If contract logic changes are needed, a full redeployment is required with migration of state. This tradeoff favors security and auditability over upgrade convenience.
  </Accordion>
</AccordionGroup>