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

# M3 Plan

> M3 roadmap: professional security audit, mainnet deployment, GBP and JPY pairs, persistent rate limiting, automated keeper rewards, and formal verification of core invariants.

M3 is the mainnet-ready milestone for the Open Nile Protocol. The goal is a production
deployment with professional security, advanced risk management, operational maturity, and institutional-grade
infrastructure. This page outlines the planned scope -- priorities may shift based on audit findings,
market feedback, and technical feasibility.

<Note>
  M3 is a planned milestone. Features described here are subject to change. The M2 deployment on Sepolia
  testnet is the current live version. See [M2 Scope](/nile-markets/m2-scope) for what is available today.
</Note>

## Security

Professional security is the highest priority for M3. The protocol must pass independent review before
handling real funds.

<Steps>
  <Step title="Professional Smart Contract Audit">
    Engage 1-2 independent audit firms to review the full contract suite. The audit scope includes all
    8 core contracts, the Protocol registry, and all library code. The 550-test suite with 95%+ line
    coverage provides auditors with comprehensive test vectors.
  </Step>

  <Step title="Formal Verification">
    Apply formal verification tools (Certora or Halmos) to critical protocol invariants. Priority
    invariants include solvency (pool equity >= 0 under all conditions), margin sufficiency, and
    fee distribution correctness.
  </Step>

  <Step title="Bug Bounty Program">
    Launch a public bug bounty program with tiered rewards for vulnerability severity. The program will
    run continuously after mainnet launch to incentivize ongoing security research.
  </Step>

  <Step title="Multi-Sig Governance">
    Transition admin operations from a single EOA to a multi-signature wallet (e.g., Safe). Critical
    operations like mode transitions, parameter changes, and emergency actions will require multiple
    signers.
  </Step>

  <Step title="Emergency Shutdown Module">
    Implement an emergency shutdown mechanism inspired by MakerDAO's ESM. This provides a last-resort
    circuit breaker that can wind down the protocol in an orderly fashion if a critical vulnerability
    is discovered post-deployment.
  </Step>
</Steps>

## Risk Management

M3 introduces advanced risk controls and broader market coverage.

<Columns cols={2}>
  <Card title="Multiple Markets / Pairs" icon="globe">
    Expand beyond EUR/USD to additional FX pairs: GBP/USD, USD/JPY, AUD/USD, and more. Each pair
    requires its own Pyth price feed, forward price publisher configuration, and risk parameters. The
    contract architecture already supports multi-pair registration -- this is primarily an operational
    and parameter calibration effort.
  </Card>

  <Card title="Cross-Margin & Portfolio Margin" icon="arrows-cross">
    Implement cross-margin (shared margin across multiple positions within the same account) for improved
    capital efficiency, where gains on one position can offset losses on another. Longer-term, introduce
    portfolio margin with cross-pair netting and scenario-based risk assessment for diversified portfolios.
  </Card>

  <Card title="Multiple Collateral Types" icon="coins">
    Accept collateral beyond USDC -- additional USD-denominated stablecoins (USDT, DAI) and potentially
    other approved tokens. Each collateral type requires its own price feed and haircut parameters to
    account for depegging risk.
  </Card>

  <Card title="Non-USD Collateral" icon="money-bill-wave">
    Support non-USD-denominated collateral assets, enabling participants to post margin in EUR-denominated
    stablecoins (e.g., EURC) or other non-dollar assets. This requires real-time collateral valuation
    against USD and introduces additional FX risk that must be incorporated into margin calculations.
  </Card>

  <Card title="Dynamic Margin Parameters" icon="sliders">
    Introduce volatility-responsive margin requirements that adjust based on market conditions. Higher
    volatility periods would automatically increase initial and maintenance margin factors, reducing
    leverage and protecting the pool.
  </Card>

  <Card title="Insurance Fund" icon="piggy-bank">
    Create a dedicated insurance fund to absorb bad debt before it impacts LP share price. Funded by a
    portion of liquidation penalties or protocol revenue. Provides an additional buffer between trader
    defaults and LP losses.
  </Card>
</Columns>

<Info>
  A proper FX market holiday calendar will also be implemented in M3. This ensures fixing dates correctly
  skip bank holidays (not just weekends), aligning with standard FX market conventions for each currency
  pair.
</Info>

## Multi-Chain Deployment

Deploy on Ethereum mainnet plus L2 networks (Arbitrum, Base) and additional chains as the protocol sees
fit. Each deployment operates independently with its own liquidity pool, oracle configuration, and
settlement logic. L2 deployment offers significantly lower gas costs for frequent keeper and publisher
transactions while inheriting Ethereum's security.

The final network choice for the initial mainnet deployment depends on gas cost analysis, oracle
availability, and user concentration. Subsequent chain deployments will follow based on demand.

## Operations

Operational maturity is essential for a reliable mainnet deployment.

<Tabs>
  <Tab title="Keeper Incentives">
    Design and implement onchain economic incentives for keeper operations:

    * **Liquidation rewards**: A portion of the liquidation penalty paid to the liquidator as gas
      reimbursement and profit incentive
    * **Settlement rewards**: Small bounty for settling matured positions, ensuring timely settlement
      even without an official keeper
    * **Competitive keepers**: Open keeper participation to any address, creating a competitive market
      for settlement and liquidation execution

    This removes the dependency on Nile Markets operating the sole keeper service.
  </Tab>

  <Tab title="Publisher Redundancy">
    Establish multiple independent forward price publishers:

    * **Primary/backup architecture**: At least two publisher instances with automatic failover
    * **Publisher health monitoring**: Onchain tracking of publisher uptime and accuracy
    * **Decentralized publisher network**: Long-term path to a permissionless publisher set with
      stake-based incentives and slashing for incorrect prices

    This eliminates the single-publisher bottleneck in M2.
  </Tab>

  <Tab title="Monitoring & Alerting">
    Production-grade observability infrastructure:

    * **Structured metrics**: Prometheus/Grafana dashboards for all protocol state (pool equity,
      utilization, open interest, oracle freshness)
    * **Alerting**: PagerDuty/Opsgenie integration for critical events (mode transitions, high
      utilization, publisher failures, unusual trading patterns)
    * **Dead-man-switch**: Automated mode escalation if the keeper or publisher stops reporting
      within configurable thresholds
  </Tab>

  <Tab title="Key Management">
    Secure key management for operational services:

    * **Encrypted keystore**: OS keychain or age encryption for publisher and keeper private keys
    * **Key rotation**: Procedures for rotating operational keys without service interruption
    * **Separation of concerns**: Distinct keys for admin, publisher, and keeper roles with minimal
      required permissions
  </Tab>
</Tabs>

## Infrastructure

<AccordionGroup>
  <Accordion title="Canonical USDC Integration">
    Replace MockUSDC with Circle's canonical USDC contract on the target network. This requires
    verifying compatibility with the ERC-4626 vault (USDC uses 6 decimals, same as MockUSDC) and
    testing edge cases around USDC's blocklist and admin functions.
  </Accordion>

  <Accordion title="Persistent Rate Limiting">
    Implement Redis-backed rate limiting (Upstash Redis) for the x402 API and MCP server. M2 uses
    in-memory rate limiting which resets on service restart. Persistent rate limiting ensures fair
    usage across service deployments.
  </Accordion>

  <Accordion title="CI/CD Pipeline">
    Automated deployment pipeline for contract upgrades (new deployments, not proxy upgrades):

    * Automated Foundry test suite execution
    * SDK regeneration and verification
    * Subgraph ABI sync and deployment
    * Frontend deployment with updated addresses
    * Deployment artifact archival and verification
  </Accordion>
</AccordionGroup>

## Timeline

<Warning>
  No fixed dates are committed for M3. The timeline depends on audit availability, audit finding
  remediation, and security review thoroughness. Security will not be rushed to meet a deadline.
</Warning>

The general sequencing is:

| Phase           | Activities                                                                         |
| --------------- | ---------------------------------------------------------------------------------- |
| **Pre-Audit**   | Cross-margin implementation, additional pairs, insurance fund, operational tooling |
| **Audit**       | 4-8 week audit engagement with 1-2 firms, concurrent formal verification           |
| **Remediation** | Fix all audit findings, re-verify critical changes                                 |
| **Staging**     | Full deployment rehearsal on testnet with production configuration                 |
| **Launch**      | Mainnet deployment with monitoring, gradual parameter relaxation                   |

## Related Pages

<Columns cols={2}>
  <Card title="M2 Scope" icon="flag-checkered" href="/nile-markets/m2-scope">
    What is currently live on Sepolia.
  </Card>

  <Card title="Future Vision" icon="telescope" href="/nile-markets/future-vision">
    Long-term protocol vision beyond M3.
  </Card>
</Columns>