Phase 1 Trading System Design

This section covers the trading system design, including order types, risk management, and liquidity architecture.

This section describes the design of Aporia's trading system in Phase 1: the order types and market structure available to traders, the three-stage risk management framework, the liquidity architecture and how market makers interact with the platform, and the security model protecting user assets and platform integrity. Where Phase 2 capabilities differ, they are noted explicitly.

Market Structure and Order Types

Market Types

Phase 1 launches with two market categories:

• Spot markets — direct token-to-token trading with immediate settlement. Spot markets on Aporia operate as traditional central limit order books (CLOBs) with price-time priority matching. All spot trades settle to the off-chain Ledger with progressive on-chain anchoring via the L2 Settlement Contract.

• Perpetual futures — leveraged synthetic exposure to underlying asset prices, with funding rates that keep the perpetual price anchored to the spot index. Perpetuals require margin collateral, are subject to auto-liquidation if the margin ratio falls below the maintenance threshold, and use oracle-sourced mark prices for all risk calculations.

Fee Model

Aporia uses a maker-taker fee model with a zero-fee maker rebate structure designed to attract professional liquidity providers:

• Maker fee: 0.00% — market makers who add liquidity to the order book pay no fee and receive a rebate from the taker fee pool.

• Taker fee: 0.02% — traders who remove liquidity pay a taker fee, of which 70% is redistributed as maker rebates, 20% goes to protocol development, and 10% is allocated to token buyback and market support.

This fee structure mirrors the incentive model proven effective at attracting institutional market makers on leading venues. A zero maker fee with meaningful rebate is the clearest possible signal to professional liquidity providers that Aporia competes for their business.

Order Types

Phase 1 supports a full suite of order types covering retail, professional, and institutional execution needs:

Order Type	Description	Primary Use Case
Limit	Buy or sell at a specified price or better; rests in the order book if not immediately matched	Market making, passive entry, spread capture
Market	Execute immediately at the best available price; consumes liquidity from the order book	Urgent directional execution, immediate fill
Post-Only	Cancels if it would execute immediately; guarantees maker status and fee rebate eligibility	Market makers enforcing zero-taker-fee execution
IOC	Immediate-or-Cancel: fills what it can instantly, cancels any unfilled remainder	Partial fill strategies, latency-sensitive routing
FOK	Fill-or-Kill: must fill the entire order immediately or cancel with no partial execution	Block trades, institutional size requirements
Stop-Limit	Triggers a limit order when the mark price crosses a specified stop level	Risk management, systematic strategies, stop-loss
TWAP / Algo	Time-Weighted Average Price execution sliced across a defined window; Phase 2 AI-optimized routing	Large order execution, reduced market impact

TWAP and algorithmic order routing are introduced in Phase 2, where they can be optimized across parallel frontier views using EigenFlow acceptance probabilities as routing inputs.

Market Making APIs

Professional market makers require low-latency, high-throughput programmatic access. Aporia provides:

• REST API — full order management (create, cancel, modify, query), account management, and market data endpoints. Authenticated via HMAC with time-window replay protection.

• WebSocket API — real-time streaming of order book updates, execution reports, position changes, and account balance deltas. Sub-50ms update latency target for connected sessions.

• FIX protocol support (Phase 2) — industry-standard Financial Information eXchange protocol for institutional connectivity, enabling drop-in integration with existing trading infrastructure.

• Co-location advisory — documentation and support for market makers optimizing their network topology relative to the Kaspa block propagation network, directly relevant to EigenFlow execution class selection.

---

Risk Management

Aporia operates a three-stage risk management framework: pre-trade controls that gate order admission, in-trade monitoring that tracks live exposure in real time, and post-trade auditing that creates a fully reconstructable record of every transaction. Each stage is integrated with the off-chain core modules described in Phase 1 Architecture.

Stage	Control	Description
Pre-Trade	Notional limits	Per-user and per-instrument maximum order size and aggregate open notional
Pre-Trade	Frequency limits	Max order submissions per second per user; protects matching engine from message flooding
Pre-Trade	Allow / deny lists	Address-level access controls; supports KYC/AML hooks and institutional access tiers
Pre-Trade	Margin checks	Sufficient collateral verification for leveraged perpetuals before order admission
In-Trade	Real-time risk engine	Continuous monitoring of open positions, notional exposure, and portfolio-level risk metrics
In-Trade	Oracle integration	Mark price from multi-source oracle feeds; used for margin, liquidation trigger, and PnL calculation
In-Trade	Anomaly detection	Statistical detection of wash trading, spoofing patterns, and unusual order flow; routes to manual review
In-Trade	Auto-liquidation	Triggered when margin ratio falls below maintenance threshold; closes position at best available price
Post-Trade	Audit journal	Before-and-after balance snapshots for every ledger event; idempotency keyed by business reference
Post-Trade	Settlement reconciliation	Net settlement artifacts reconcilable against on-chain events by any participant or external auditor
Post-Trade	Reporting	Trade history, position reports, and fee statements; institutional export formats for compliance teams

Oracle and Mark Price

All risk calculations for perpetual futures — margin requirements, liquidation triggers, and unrealized PnL — use a mark price derived from multiple external oracle sources rather than the last traded price. This prevents manipulation via thin-liquidity trades that could artificially trigger liquidations. The Oracle module applies freshness thresholds (maximum age per price feed) and falls back to secondary sources if the primary source becomes stale. Oracle inputs are the only external data dependency of the risk engine's margin calculations.

Liquidation Engine

When a user's margin ratio falls below the maintenance threshold, the liquidation engine executes an automatic position reduction at the best available price in the order book. If the order book cannot absorb the full liquidation at a price above the bankruptcy price, the remaining shortfall is covered by the insurance fund — a protocol-owned reserve seeded at launch and replenished by a portion of liquidation fees. If the insurance fund is depleted, auto-deleveraging (ADL) reduces positions of the most profitable traders on the opposing side, in priority order by PnL and leverage.

Phase 1 risk framework note: The Phase 1 risk framework operates on a single-path linear execution model. All margin calculations, liquidation triggers, and notional limit enforcement assume sequential order processing. In Phase 2, the risk framework will be extended to account for multi-frontier quote exposure — a market maker's aggregate risk across all active frontier paths — requiring new position-level risk metrics not present in Phase 1.

---

Liquidity Architecture

Deep, persistent liquidity is the defining quality metric for an order book DEX. Every other aspect of Aporia's design — tight spreads, fast execution, fair pricing — depends on having professional market makers willing to quote continuously across all listed instruments. This section describes how the liquidity architecture is designed to attract and retain that participation.

Market Maker Module

The Market Maker module is the interface between external market making participants and the matching engine. It supports two quoting modes:

• Passive quoting — the market maker submits resting limit orders at specified price levels and updates them as market conditions change. The module handles order lifecycle management (placement, refresh, cancellation) and provides execution reports in real time.

• Active quoting — the market maker provides parameters (target spread, inventory limits, skew sensitivity) and the module dynamically computes and refreshes quotes using the current oracle price as a reference. This mode is designed for market makers who want to delegate spread optimization to the platform while retaining control over key risk parameters.

Both modes support:

Inventory management: configurable maximum net inventory per instrument, with automatic quote withdrawal when limits are approached

Dynamic parameterization: spread, size, and refresh rate adjustable via API without session interruption

Multi-instrument quoting: simultaneous quoting across all listed instruments from a single session

Execution attribution: full trade-level attribution distinguishing maker fill, taker fill, and liquidation fill for P&L accounting

Liquidity Incentive Program

Phase 1 launches with a structured liquidity incentive program to attract market makers before organic volume reaches self-sustaining levels. The program has three components:

• Market maker agreements — bilateral agreements with professional market makers committing to minimum quoting obligations (minimum time at quote, maximum spread width, minimum size) in exchange for enhanced maker rebates and reduced collateral requirements.

• Token incentives — protocol token distributions to market makers meeting quoting performance thresholds, calculated on a rolling basis from observed order book quality metrics.

• Fee waivers — zero-fee API access and zero-fee listing for initial partner market makers during the Phase 1 bootstrap period.

Phase 2 liquidity transition: As EigenFlow activates in Phase 2, incentive-driven liquidity is gradually replaced by structurally-driven liquidity. Market makers will remain on Aporia because their Sharpe ratios are higher here than on competing venues — not because of rebate programs. The goal of Phase 1 incentives is to build sufficient order book depth that the EigenFlow data pipeline accumulates high-quality conflict-resolution observations, accelerating the Phase 2 model calibration.

EigenFlow Integration (Phase 2 Preview)

In Phase 2, the Liquidity Architecture gains a new layer: EigenFlow-informed spread optimization. Market makers using Aporia's active quoting mode will be able to opt into EigenFlow-optimized routing, where the platform's spectral consensus kernel outputs — acceptance probabilities per execution class, current EigenFlow weights, and spectral gap stability indicator — are used as inputs to the spread computation engine.

In Phase 2, the Liquidity Architecture gains a new layer: EigenFlow-informed spread optimization. Market makers using Aporia's active quoting mode will be able to opt into EigenFlow-optimized routing, where the platform's spectral consensus kernel outputs — acceptance probabilities per execution class, current EigenFlow weights, and spectral gap stability indicator — are used as inputs to the spread computation engine.

This integration exposes three new parameters to market maker APIs:

• Acceptance probability vector — per-frontier-path probability of first inclusion, updated on each new block observation. Allows market makers to size their quotes proportionally to path reliability.

• Spectral gap indicator — a real-time stability metric for the current ordering structure. Market makers can configure automatic spread-widening when the spectral gap falls below a threshold, providing a built-in adversarial robustness control.

• Recommended fee schedule — the EigenFlow-computed optimal fee premium per execution class for the current network state, enabling market makers to achieve ordering priority without overpaying for it.

---

Security Model

Aporia's security model is designed around a single principle: every layer that holds, moves, or authorizes the movement of user assets must be independently hardened, narrowly scoped, and fully auditable. No single component failure should be able to compromise the integrity of user funds.

Layer	Mechanism
Key Custody	Isolated Signing & Key Service with KMS/HSM hardware; least-privilege key scoping per operation type; full audit log of every signing request with context, destination, and amount
Key Rotation	Configurable rotation schedules; multi-party authorization thresholds for high-value operations; cold-wallet fallback for bridge controls
User Auth	EIP-712 structured data signing for all order submissions; prevents replay attacks via time-window and chain-ID enforcement; multi-wallet binding with primary address resolution
Session Mgmt	Short-lived JWT tokens with renewal flows; rate limiting per session and per API key; session revocation on anomaly detection
Bridge Security	Dispute window on all outbound withdrawals; freeze/unfreeze controls with threshold-signer authorization; withdrawal quotas by asset and destination; destination address screening via Risk Engine
Smart Contract	L2 Settlement Contract and L2 Vault audited before mainnet launch; operation whitelisting restricts callable function selectors; upgradeable proxy pattern with timelock on protocol parameter changes
Data Integrity	Idempotency keys prevent double-processing across all ledger operations; journal entries with before/after snapshots for full reconstruction; settlement artifacts independently verifiable against on-chain state

Audit and Compliance Roadmap

Before mainnet launch, all on-chain components — the L2 Settlement Contract, the L2 Vault, and the bridge contracts — will undergo independent security audits from recognized firms. The off-chain core will be reviewed for logic correctness, data integrity, and key management practices. Audit reports will be published in full. An ongoing bug bounty program will be established post-launch with tiered rewards for critical, high, medium, and low severity findings.

KYC and AML integration hooks are built into the Identity & Wallet module and the Risk Engine's allow/deny list framework. Compliance requirements vary by jurisdiction and will be activated on a market-by-market basis as Aporia expands to serve regulated participants. The base protocol is designed to be non-custodial: users retain control of their assets until they voluntarily deposit into the L2 settlement environment, and they can exit at any time via the withdrawal flow described in Phase 1 Architecture.