Skip to main content
The Open Nile Protocol is built on a set of explicit assumptions about the business environment, technical infrastructure, and operational model. Understanding these assumptions is important for evaluating the protocol’s risk profile and applicability to different deployment scenarios.
The current deployment targets the M2 (External Testnet) milestone on Ethereum Sepolia. These assumptions reflect testnet conditions and may evolve as the protocol progresses toward M3 (Mainnet Ready). Do not use this deployment with real funds.

​
Business Assumptions

The protocol uses a USDC-like ERC-20 token with 6 decimals as its sole collateral currency. On Sepolia testnet, this is a mock USDC contract deployed alongside the protocol. In production, the protocol will use canonical USDC or an equivalent USD-denominated stablecoin.Key properties assumed of the collateral token:
  • Standard ERC-20 interface with transfer, transferFrom, and approve
  • 6 decimal precision
  • No rebasing, fee-on-transfer, or other non-standard mechanics
  • Sufficient liquidity and price stability (1:1 USD peg)
All settlement is denominated and executed in USDC. The protocol is a non-deliverable FX forward product — there is no physical delivery of EUR. There is no EURC token or EUR-denominated collateral involved.PnL is calculated in USD terms (using the EUR/USD exchange rate) and settled entirely in USDC between the trader’s margin account and the liquidity pool.
Each trader may hold multiple open forward contracts concurrently. Positions are fully independent under the isolated margin model:
  • Each position has its own locked margin, entry price (strike), and fixing timestamp
  • The entry price is set at open time using OracleForward(t_open, FixingTimeUtc) plus pricing adjustments (spread, premium/discount), and is stored immutably
  • Liquidation of one position does not affect others
  • Bad debt on one position is absorbed by the pool, not cross-marginalized

​
Technical Assumptions

The protocol requires an authoritative forward price OracleForward(t, FixingTimeUtc) for EUR/USD that can be obtained for any maturity timestamp FixingTimeUtc at the current time t.The current implementation derives forward prices as follows:
  • Spot price: Sourced from the Pyth Network EUR/USD price feed onchain
  • Forward prices: Computed off-chain by the Publisher service using interest-rate parity (covered interest rate parity formula applied to EUR and USD benchmark rates) and submitted onchain via OracleModule.publishForwardRound()
  • Safeguards: Onchain checks enforce price movement limits, deviation bounds vs. spot, and minimum update spacing to prevent erroneous or manipulated prices
The forward price formula uses covered interest rate parity: F(t, T) = S(t) * (1 + r_USD * tau) / (1 + r_EUR * tau) where tau = (T - t) in year fractions, r_USD and r_EUR are the respective risk-free rates, and S(t) is the current spot rate.
Onchain maturity settlement is anchored to a specific fixing time on business days:
  • Fixing time: 16:00 UTC (configurable via fixingHourUtc, fixingMinuteUtc, fixingSecondUtc)
  • Maturity calculation: FixingTimeUtc = NextBusinessDayAt16UTC(OpenTime + TenorSeconds[tenor]) where tenor is one of the supported durations (1D, 1W, 1M, or TEST_60S on testnet)
  • Business day definition (M2): Monday through Friday. Weekends are excluded. There is no holiday calendar — all weekdays are treated as business days.
  • Weekend roll: If the raw maturity falls on Saturday, it rolls +2 days to Monday. Sunday rolls +1 day to Monday.
Two pricing adjustments modify the raw forward price:
  • Premium/Discount Adjustment (PremiumDiscountAdj): Applied to incentivize pool exposure rebalancing. When the pool is skewed long, short positions receive a favorable adjustment, and vice versa. Controlled by premiumDiscountAdjBps and baseSpreadBps in Config.
  • Early termination pricing: Positions closed before maturity use OracleForward + PremiumDiscountAdj + TerminationFee, where OracleForward is the current forward for the same maturity timestamp as the position. The TerminationFee compensates the pool for the early unwind.
The oracle module supports a distinct “weekend mode” pricing policy that can affect how forward prices are treated when markets are closed. This mechanism accounts for the fact that FX spot markets are closed on weekends, so price feeds may become stale.On Sepolia testnet, weekend mode can be disabled to allow continuous testing without interruption.
Each position’s entry price (strike) is determined at open time and stored immutably:
entryPrice = OracleForward(t_open, FixingTimeUtc) + spreadAdjustment + premiumDiscount
This price never changes for the lifetime of the position. All PnL calculations (unrealized during the position’s life, and realized at settlement) reference this fixed entry price against the current or fixing price. This makes position economics fully deterministic from the moment of opening.

​
Operational Assumptions

Liquidations and batch settlements are executed by an off-chain Keeper service that monitors onchain state and submits transactions when conditions are met:
  • Liquidation: The Keeper continuously monitors position equity against maintenance margin. When equity < maintenanceMargin, it calls SettlementEngine.liquidate().
  • Settlement: After maturity and fixing price recording, the Keeper calls SettlementEngine.batchSettle() to process matured positions.
The protocol’s correctness does not depend on Keeper liveness for safety (positions cannot be unfairly liquidated without meeting the onchain criteria), but Keeper availability affects timeliness of settlements and liquidations.
In M2, the Keeper is operated by the protocol team. There is no decentralized keeper network or incentive mechanism. Keeper failure would delay settlements and liquidations but would not compromise the integrity of onchain state.
Withdrawals from the liquidity pool may be locked or utilization-limited to prevent bank-run dynamics while the risk model is being validated:
  • Utilization cap (maxUtilizationBps): LPs cannot withdraw if it would push pool utilization (total notional / total assets) above the configured cap
  • Future consideration: Additional time-lock or queue-based withdrawal mechanisms may be introduced in later milestones
These restrictions protect traders by ensuring the pool has sufficient liquidity to cover potential payouts on open positions.

​
Assumption Dependencies

The following table summarizes which protocol components depend on each assumption:
AssumptionDepends OnIf Violated
B1. USDC collateralMarginAccounts, PoolVaultToken incompatibility, precision errors
B2. USD settlementSettlementEngine, PnL mathN/A (fundamental design constraint)
T1. Forward price sourceOracleModule, PublisherPositions cannot be opened or priced
T2. Business day ruleDateTime library, PositionManagerIncorrect fixing timestamps
O1. Keeper availabilitySettlementEngineDelayed settlements and liquidations
O2. Withdrawal limitsPoolVaultPotential liquidity shortfall