Core Design Principles

The Open Nile Protocol makes six deliberate architectural choices that shape every aspect of how positions are opened, priced, margined, and settled. This page explains each principle, its trade-offs, and how the overall design compares to alternative approaches.

​

Zero-Sum Pool Model

The ERC-4626 vault is the sole counterparty to every trade. There is no order book, no peer matching, and no AMM curve. When a trader opens a position, the pool takes the opposite side. When a trader profits, the pool pays. When a trader loses, the pool collects. Why this design:

• Instant execution — any trader can open a position at any time as long as pool capacity and risk limits allow. No waiting for a matching counterparty.
• Simplified liquidity — LPs deposit USDC into a single vault and passively provide liquidity to all positions. No active market-making required.
• Deterministic pricing — entry prices come from the oracle (with risk adjustments), not from bid/ask negotiation. Every trader opening the same tenor at the same moment gets the same price.

Trade-offs:

• LPs bear directional risk. If most traders are long and the market moves in their favor, the pool loses. This is the fundamental risk that LPs accept in exchange for fee income.
• The pool can become capacity-constrained. Exposure caps and utilization limits prevent the pool from taking on more risk than it can absorb.

Structural pool edge: Every position pays fees — opening fees, closing fees, and liquidation penalties. These fees accrue to the pool regardless of directional outcome, creating a statistical advantage for LPs over a large number of positions. In liquidation scenarios, the pool collects the trader’s loss (capped at locked margin) plus its 70% share of the liquidation penalty and trading fee. Any remaining margin after losses and fees is returned to the trader. See Liquidation for the full flow.

​

Isolated Margin

Each position has independent collateral. A trader can hold multiple positions simultaneously, and each one has its own locked margin, entry price, and maturity. Liquidation of one position does not affect others held by the same account. How it works:

• When a position is opened, the required initial margin is locked from the trader’s MarginAccounts balance
• Unrealized PnL is computed per-position against the position’s own entry price
• If a position’s equity falls below maintenance margin, only that position is liquidated
• Maximum loss per position is capped at locked margin — any loss beyond that is bad debt absorbed by the pool

Why not cross-margin: Cross-margining (where collateral is shared across positions) enables capital efficiency — gains on one position can offset losses on another, reducing total margin requirements. However, it introduces significant complexity: Cross-margin is a planned enhancement for M3. See M3 Plan for details.

​

Immutable Contracts

All contracts are deployed as immutable bytecode — no proxy patterns, no upgradeability, no delegatecall-based logic swaps. The code that executes today is the code that was deployed. What’s fixed (logic):

• Position lifecycle state machine (open, increase, reduce, close, settle, liquidate)
• PnL calculation formulas
• Fee computation logic
• Settlement and liquidation execution paths
• Oracle validation checks
• Margin accounting

What’s configurable (parameters):

• Fee rates (opening, closing, liquidation, termination)
• Margin requirements (initial, maintenance)
• Risk caps (exposure, utilization, position/account limits)
• Oracle thresholds (staleness, deviation, move limits)
• Pricing adjustments (spread, premium/discount)

All configurable parameters are managed through the Config contract with onchain access control. What happens when logic needs to change: Full redeployment. A new contract set is deployed, positions on the old contracts continue to be serviced until maturity, and new positions are opened on the new contracts. This is more operationally complex than proxy upgrades but eliminates an entire class of upgrade-related vulnerabilities (storage collisions, initialization bugs, governance attacks on upgrade paths). Admin key and parameter risk: The contract owner (admin) can modify all configurable parameters — fee rates, margin requirements, risk caps, oracle thresholds, and pricing adjustments — without a timelock. However, these changes only affect newly opened positions: existing positions use snapshotted parameters from open time and cannot be retroactively modified. The admin cannot alter contract logic, move funds, or bypass the settlement/liquidation rules. In M2, the admin key is held by the protocol team. A timelock and multi-sig governance are planned for M3.

​

Permissionless Settlement

Anyone can settle matured positions or liquidate underwater ones. The SettlementEngine imposes no restrictions on the caller — the smart contracts validate all preconditions (maturity reached, fixing price recorded, equity below maintenance margin) regardless of who submits the transaction. In practice:

• The keeper service automates settlement and liquidation, monitoring onchain state and submitting transactions when conditions are met
• In M2, the keeper is operated by the protocol team — there is no decentralized keeper network or incentive mechanism yet
• If the keeper goes down, anyone can call the same functions directly. Protocol correctness does not depend on keeper liveness for safety, only for timeliness

M3 evolution: Keeper incentives (gas reimbursement, liquidation bonuses) are planned for M3 to encourage a decentralized keeper network. See M3 Plan.

​

Oracle-Driven Pricing

Prices are not discovered through trading activity. Instead, the protocol relies on two external price sources:

• Spot prices from the Pyth Network — the current EUR/USD exchange rate, aggregated from institutional publishers
• Forward prices computed off-chain by the authorized publisher using interest rate parity and submitted onchain via the OracleModule

Published forward prices pass through multiple oracle safeguards (movement limits, deviation checks, staleness rules) before being accepted. If safeguards fail, the protocol escalates to a restricted mode to protect open positions. For the full pricing mechanics, see Oracle & Forward Pricing. Trust assumption: In M2, the publisher is a single trusted service operated by the protocol team. There is no decentralized oracle network for forward prices. This is a known centralization point — the publisher role has the PUBLISHER_ROLE onchain and can only publish price rounds, not modify any other protocol state.

​

Single Collateral

USDC is the sole collateral and settlement currency. All PnL, fees, and margin are denominated in USDC. The pool holds only USDC — no multi-asset complexity. Why USDC-only:

• Eliminates cross-collateral pricing risk (no need to value collateral against position denomination)
• Simplifies accounting — one unit of account throughout the system
• Matches the non-deliverable nature of the product (cash settlement in a stable unit)
• Reduces smart contract surface area (no collateral swaps, no liquidation auctions, no haircut calculations)

Future multi-collateral: Support for additional collateral types (other stablecoins, yield-bearing assets) is under consideration for M3. This would require a collateral pricing module and haircut framework. See M3 Plan.

​

How It Differs from Alternatives

Key distinction from perpetuals: Perpetual contracts have no expiry — they use funding rates to keep the perp price anchored to spot. The Open Nile Protocol uses fixed-maturity forwards that settle at a specific date and time. There is no funding rate. The forward premium naturally converges to zero as maturity approaches. For a deeper comparison, see Forwards vs. Perpetuals.

​

Next Steps