Phase 1 Architecture
This section describes the Aporia Protocol in detail — the off-chain core architecture, on-chain settlement layer, and cross-chain bridge design.
This section describes the Phase 1 architecture of the Aporia protocol: a traditional linear order book DEX built on Igra Labs, a Kaspa L2. Phase 1 is not yet the parallel-native exchange described in Sections 4 and 8. It is a production-grade trading infrastructure — off-chain matching with on-chain settlement anchoring — that establishes Aporia as the primary liquidity venue in the Kaspa ecosystem, and that begins accumulating the consensus ordering data that EigenFlow requires to power Phase 2's parallel execution. The parallel-native architecture is enabled in Phase 2 upon the launch of Kaspa vProg.
Important: The architecture described in this section is the Phase 1 linear order book DEX. Matching is single-path and sequential. Multi-frontier parallel quoting, acceptance-time concentration, and full EigenFlow execution are Phase 2 capabilities, contingent on the Kaspa vProg launch (targeted Q4 2026). Phase 1 intentionally mirrors the proven hybrid architecture of leading order book DEXs while laying the technical and data foundation for the parallel-native transition.
Phase 1 Architecture Overview
Phase 1 deploys a battle-tested hybrid model: off-chain order matching combined with on-chain settlement anchoring. This is the same architectural pattern used by leading order book DEXs — and deliberately so. The goal of Phase 1 is not architectural novelty; it is to establish deep, reliable liquidity on Kaspa with a system that is fast, secure, and immediately usable by professional market makers and retail traders alike.
In this model, the matching engine and all latency-sensitive logic run off-chain, where sub-millisecond execution is achievable without gas cost constraints. Asset custody, deposit minting, and settlement anchoring run on-chain via igra L2 and Kaspa L1, providing cryptographic finality for all asset movements. Single-path, price-time priority order matching is the execution model throughout Phase 1.
What distinguishes Phase 1 from a generic order book DEX is its forward design: every component is built with the Phase 2 migration in mind. The matching engine interface is designed to accommodate multi-frontier quote management when vProg is available. EigenFlow-lite runs in data-collection mode from day one, building the conflict-resolution dataset that the full spectral kernel requires. The off-chain ledger and settlement infrastructure are architecturally compatible with the on-chain vProg execution environment. Phase 1 is the foundation, not the ceiling.
The Phase 1 protocol is organized into three layers:
Off-chain Core — all latency-sensitive logic: API ingress, identity and session management, single-path order matching, real-time risk evaluation, ledger management, market data feeds, oracle integration, and the settlement orchestrator.
On-chain Settlement (igra L2 and Kaspa L1) — asset custody, deposit minting across two paths (Kaspa-native and EVM), withdrawal execution, and settlement anchoring via the L2 Settlement Contract and L2 Vault.
Signing & Key Service — an isolated module with KMS/HSM key custody that executes all platform-side on-chain actions: mint instructions, settlement submissions, and withdrawal transactions.
Phase 1 Architecture Primary Flows
Off-Chain Core
The off-chain core is the operational heart of the protocol. It is responsible for all functions that require sub-millisecond latency, stateful session management, or computational intensity that would be cost-prohibitive on-chain. The core is designed for high availability, with replay-capable components and idempotency controls throughout to support failure recovery without data loss or double-processing.
The core consists of nine functional modules:
API Gateway
Unified REST/OpenAPI ingress and request routing. Handles authentication and session management: token issuance and renewal, authorization, rate limiting, and time-window replay protection. Enforces user signature verification (EIP-712) and provides unified error codes, gradual rollout support, and trading security controls.
Identity & Wallet
Login challenge and signature verification, multi-wallet binding, and primary wallet resolution and switching. Manages address-to-user resolution, session state, and compliance fields including timestamp, chain identifier, and protocol version. Supports account-level access controls for institutional participants.
Trade Ingress
Order parameter validation and normalization, idempotency handling, and reference generation. Executes pre-trade risk checks and manages funds lock and unlock. Owns the full order lifecycle — creation, cancellation, rejection, and timeout — and maintains reliable interaction with the matching engine through acknowledged message delivery.
Matching Engine
Multi-instrument central limit order book (CLOB) with single-path, price-time priority matching. Processes orders sequentially in the canonical linear queue. Emits execution and cancellation events consumed downstream by Trade Ingress and the Market Feed. Supports high-availability deployment with event replay for crash recovery. The matching engine interface is forward-designed for Phase 2 multi-frontier integration, but in Phase 1 operates as a traditional linear CLOB.
Ledger
Single source of truth for all user balances across the user, account type, and coin dimensions. All credit, debit, lock, unlock, and fee operations are atomic, with idempotency keyed by business reference to prevent double-processing. Journal entries record before-and-after balance snapshots for reconciliation and audit. Amount normalization (truncate to coin precision, trim trailing zeros) is applied consistently at the ledger boundary.
Market Feed
Real-time push of incremental execution events and order book snapshots to connected clients. Provides batch query endpoints for depth, trade history, candlestick (kline) data, and ticker summaries. Integrates with the Oracle module to supply mark prices and risk inputs alongside market display data.
Risk Engine
Operates as a pre/in/post-trade control loop integrated with Oracle, Market Feed, and the On-chain Listener. Trading risk controls include per-user and per-instrument notional and frequency limits, allow/deny lists, and real-time anomaly detection. Deposit and withdrawal risk controls cover source and destination policies, limit and frequency thresholds, on-chain receipt verification, and a manual review channel for flagged transactions.
Settlement Orchestrator
Aggregates net ledger changes across all matched trades into settlement batches and constructs the corresponding anchor transactions for the L2 Settlement Contract. Manages retry logic on submission failure, tracks on-chain finality for each batch, and produces verifiable settlement artifacts for reconciliation and external audit.
Oracle
Ingests external price feeds and risk parameters with configurable freshness thresholds and multi-source fallback logic. Provides trusted mark prices to the Risk Engine for margin and liquidation calculations, and to the Market Feed for display. Oracle inputs are the only external dependency of the off-chain core's risk calculations.
On-chain Listener & Credit
The On-chain Listener bridges the on-chain settlement layer and the off-chain ledger. It subscribes to event streams from all relevant L1 and L2 contracts, applies configurable confirmation windows and delay strategies to each event type, and triggers the appropriate credit or debit operation in the Ledger once sufficient confirmation depth is reached.
The Listener's behavior differs by deposit path. On the Kaspa-native path, the L2 Native Deposit Contract automatically calls the L2 Vault to mint wrapped tokens — the Listener's only job is to confirm the mint and credit the Ledger. On the EVM path, the Listener acts as the initiating agent: it detects the L1 deposit event, invokes the Signing Service to call the L2 Vault mint function, records the resulting L2 transaction hash, and then credits the Ledger once the mint confirms. This two-step sequence on the EVM path ensures that all minting is recorded and auditable before any credit is applied.
Phase 1 vs Phase 2 — Matching Engine: In Phase 1, the matching engine is a traditional single-path linear CLOB. Orders are processed one at a time in strict price-time priority sequence. There is no multi-frontier quoting, no acceptance-time concentration, and no EigenFlow kernel optimization at the execution layer. These capabilities are unlocked in Phase 2 when the matching engine migrates to Kaspa vProg, enabling simultaneous quote placement across parallel frontier views. Phase 1 EigenFlow-lite integration is limited to data collection only — recording conflict-resolution events from the Kaspa network to train the spectral consensus kernel ahead of Phase 2 deployment.
On-Chain Settlement Layer
The on-chain layer provides verifiable finality for all asset movements — deposits, withdrawals, and settlement anchoring. It is implemented across two environments: igra L2 (the Kaspa Layer 2 built by Igra Labs) and Kaspa L1. The L2 environment hosts the operational contracts that interact with traders daily; Kaspa L1 provides the base-layer security anchor via the Kaspa Bridge.
Deposit Path 1 — Kaspa Native
Users holding native KAS or Kaspa-ecosystem assets bridge their funds to the igra L2 balance via the L1 Kaspa Bridge. Once bridged, the user initiates a deposit into the L2 Native Deposit Contract. This contract, rather than requiring an external mint call, automatically invokes the L2 Vault to mint the corresponding wrapped token representation. The entire mint step is initiated and completed on-chain in a single user-signed transaction. The On-chain Listener detects the resulting L2 event, confirms it against the required depth, and credits the off-chain Ledger. No platform-side signing is required for this path, which minimizes operational custody risk for Kaspa-native assets.
Path 1 flow: User → L1 Kaspa Bridge → Igra Labs L2 Balance → L2 Native Deposit Contract → (auto-mint) L2 Vault → Wrapped Token. On-chain Listener confirms and credits Ledger.
Deposit Path 2 — EVM Chain
Users depositing from EVM-compatible chains (Ethereum, Arbitrum, and others) interact with an L1 Deposit Contract deployed on the relevant EVM network. After the deposit transaction achieves sufficient confirmation depth on the source chain, the On-chain Listener detects it and acts as the minting agent: it instructs the Signing Service to submit a mint call to the L2 Vault on igra L2. The Signing Service executes this using a platform-controlled key held in isolated KMS/HSM custody. The L2 transaction hash is recorded in the Off-chain Core, and the Ledger is credited once the L2 mint confirms.
Path 2 flow: User → L1 EVM Deposit Contract → (confirmation) On-chain Listener → Signing Service → L2 Vault mint → Wrapped Token. Listener records L2 tx hash and credits Ledger.
Withdrawal Flow
Withdrawals are initiated by the user through the API Gateway and follow a risk-gated sequence before any on-chain action is taken. The Risk Engine evaluates the request against source and destination policies, withdrawal limits, frequency thresholds, and on-chain receipt checks. Requests that fall outside configured parameters are routed to a manual review channel rather than being silently rejected.
Once approved, the Ledger freezes and then debits the relevant balance, creating a hold that prevents the funds from being used in further trading while the on-chain transaction is pending. The Settlement Orchestrator passes the withdrawal instruction to the Signing Service, which submits the appropriate on-chain action — a direct transfer for L2 balances, a burn-and-bridge operation for cross-chain withdrawals, or a bridge call for Kaspa-native exits. The On-chain Listener monitors the submission, confirms finality, and writes the result back to the Off-chain Core, completing the withdrawal record.
MVP note: The Phase 1 settlement model begins with off-chain reconciliation and progressive on-chain anchoring. Full real-time settlement anchoring via the L2 Settlement Contract will be enabled as the igra L2 infrastructure matures. All off-chain ledger state is designed for auditability and can be independently reconciled against on-chain events at any time.
Settlement Anchoring
Trade settlement on Aporia follows a net-settlement model. Rather than anchoring every individual trade on-chain — which would be cost-prohibitive even on a low-fee L2 — the Settlement Orchestrator aggregates net position changes across all matched trades within a settlement window into a single batch. This batch is submitted to the L2 Settlement Contract as a net settlement instruction, which interacts with the L2 Vault to reflect the net token movements for all participants in that window.
Each settlement batch produces a verifiable artifact — a structured record of the inputs, net changes, and on-chain transaction reference — that can be used by any participant or external auditor to independently verify that their position was updated correctly. The Settlement Orchestrator retries failed submissions with exponential backoff and tracks confirmation depth before marking a batch as final.
Signing & Key Service
All platform-side on-chain actions — L2 Vault mint calls on the EVM deposit path, settlement batch submissions, and withdrawal executions — are performed by an isolated Signing & Key Service that operates independently of the rest of the off-chain core. This isolation is a deliberate security design: a compromise of any other module cannot directly access the signing keys.
The Signing Service provides two distinct functions:
User-side verification — validating user-submitted signatures using digest verification and EIP-712 structured data signing. This function is read-only and does not require access to platform keys.
Platform-side execution — submitting on-chain transactions on behalf of the protocol using keys held in KMS/HSM custody. All key usage is logged, rate-limited, and subject to an operation whitelist that restricts which contract addresses and function selectors can be called.
The key custody architecture follows the principle of least privilege: the signing key for L2 mint operations cannot be used to authorize withdrawals, and vice versa. Key rotation procedures and multi-party authorization thresholds for high-value operations are implemented as configurable parameters. All signing requests are audited with full context — requesting module, operation type, destination address, and amount — before execution.
Cross-Chain Bridge Design
Aporia's cross-chain architecture is designed around a core tension: user experience favors frictionless, fast deposits from any chain, while security favors minimizing trust assumptions and maximizing verifiability of asset movements. The design resolves this tension through a hybrid model with distinct inbound and outbound policies.
Inbound (Deposit) Path
On the inbound side, Aporia accepts deposits via third-party bridge integrations — including Across, deBridge, and Symbiosis — in addition to its own L1 Deposit Contract. This multi-path inbound design maximizes accessibility: users on any major EVM chain can deposit into Aporia without first acquiring a specific bridge asset. Each third-party integration carries its own trust assumptions, and these are surfaced transparently in the user interface rather than abstracted away. A user depositing via Across is using UMA's optimistic oracle model; a user depositing via deBridge is using a de-pooled real-time execution model. Aporia treats these as distinct and does not conflate their security properties.
Outbound (Withdrawal) Path
On the outbound side, Aporia uses its own bridge path as the preferred route — a validator-threshold or multisig model with a dispute window and freeze/unfreeze controls. This asymmetry is intentional: the risk profile of withdrawals is higher than deposits (the platform holds funds during the withdrawal process), and the outbound path must be maximally auditable and controllable by the protocol's own security mechanisms.The outbound bridge implements four security controls drawn from the Hyperliquid bridge model:
Dispute window — a time-bounded period after a withdrawal is submitted during which anomalies can be detected and the bridge frozen before funds are released.
Freeze/unfreeze mechanism — the bridge can be paused by a threshold of authorized signers in response to detected anomalies, pending investigation and cold-wallet re-authorization.
Withdrawal quotas — per-user and aggregate daily limits configurable by asset and destination chain, providing a rate-limiting backstop against large-scale fund extraction.
Risk allow/deny lists — destination address screening integrated with the Risk Engine's policy framework, enabling compliance-driven blocking of flagged addresses.
Design principle: Aporia follows the hybrid path recommendation derived from comparative analysis of Hyperliquid (validator-signed threshold bridge, audited by Zellic) and Aster (multi-chain Treasury + internal clearing). The inbound side optimizes for user accessibility; the outbound side optimizes for security and verifiability. Both sides surface their trust assumptions clearly to users and operators.
Operational Monitoring
Production operation of the bridge layer requires continuous visibility into the health of all cross-chain positions and mechanisms. Aporia maintains permanent monitoring dashboards and automated alerts covering:
Bridge balance deltas — real-time tracking of inflows and outflows across all supported chains, with alerts on unexpected divergence from expected patterns.
Signature-threshold health — monitoring of the authorized signer set for the outbound bridge, with alerts on signer availability falling below the required threshold.
Dispute-window trigger rate — frequency of dispute-window activations as a leading indicator of anomalous withdrawal activity.
Withdrawal latency — P95 and P99 end-to-end withdrawal times by chain and asset, tracked against SLA targets.
Third-party bridge failure rates — availability and error rates for each integrated inbound bridge path, informing user-facing routing recommendations.
Last updated