How infiniX Works

This page explains the infiniX operating logic as a governed process from market intake to execution delivery. The goal is clarity: you should be able to understand how decisions are formed, where risk controls sit and how behaviour is verified.

Process Overview

Each cycle follows a fixed decision chain:

1. Run preflight checks and acquire core lock.
2. Build runtime context from market, account and order state.
3. Compute signal and pricing state (reservation price and spread logic).
4. Apply safety validation and market-regime controls.
5. Route maker execution through lifecycle and hygiene rules.
6. Publish telemetry, diagnostics and optional balance output.
7. Persist cycle state and release lock.

1) Data Intake and Integrity Controls

infiniX reads price, orderbook, balances, open orders and candle data. Before any action, it validates data quality and required inputs. If checks fail, posting is skipped for that cycle.

This prevents forced execution on incomplete or unreliable state.

2) Signal Construction and Confluence

The strategy derives market context from trend and volatility features, then forms a confluence state used for quoting decisions. Signal logic is designed to be adaptive across regimes rather than fixed to a single market condition.

3) Fair-Value and Quote Framing

infiniX calculates a dynamic reservation reference and frames quote zones around that centre. Spread logic is fee-aware and volatility-aware, so order intent changes with live conditions.

4) Risk and Inventory Governance

Before posting, infiniX applies explicit controls for:

• inventory exposure,
• volatility regime bounds,
• minimum order constraints,
• orderbook safety conditions.

If controls fail, the strategy can hold or suspend rather than force execution.

5) Maker-First Execution and Hygiene

When conditions pass, infiniX uses maker-first posting logic and orderbook-aware placement. It also enforces hygiene routines such as duplicate cleanup and max-depth control to keep execution quality stable over time.

6) Telemetry and Continuity

Each cycle emits runtime telemetry and persists state for continuity. This makes behaviour inspectable and supports faster diagnosis during abnormal conditions.

Runtime Flow (Code-Mapped)

This flow is mapped to the live cycle orchestration in quanta_infinix.js and represents the active maker-cycle control path.

flowchart TD
    A([Cycle Start]) --> B{"Preflight and data integrity OK?"}
    B -- "No" --> B1["Skip cycle and log reason"] --> Z([Cycle End])
    B -- "Yes" --> C["Acquire core lock (runCoreBusy)"]

    C --> D["Build runtime context<br/>balances, open-order state, depth limits"]
    D --> E["Signal and pricing engine<br/>reservation price, spread multiplier, volatility state"]
    E --> F{"Safety checks pass?"}
    F -- "No" --> F1["Abort execution path"] --> Y
    F -- "Yes" --> G["Execution Router (orderCentre)"]

    G --> G1{"Market regime safe?"}
    G1 -- "No" --> G2["Suspend posting<br/>high-volatility or guard breach"] --> H
    G1 -- "Yes" --> G3["Order lifecycle control<br/>cancel stale/duplicate, enforce max depth"] --> H
    G3 --> G4["Post buy and sell quotes<br/>maker-first, side guards and override timers"] --> H

    H["Publish operator telemetry<br/>reservation rails, sidebars and performance diagnostics"] --> I{"BALANCE_OUTPUT enabled?"}
    I -- "Yes" --> I1["Write balance snapshot JSON"]
    I -- "No" --> J
    I1 --> J["Persist cycle state<br/>signal memory, trade rates, housekeeping"]

    J --> Y([Cycle Complete])
    Y --> R["Release core lock<br/>finally: runCoreBusy=false"]
    R --> Z

Strategic Outcome Mapping

This operating model supports the same four outcomes used across the documentation set:

• capital efficiency through controlled turnover,
• repeatable two-sided volume participation,
• explicit risk containment through gating,
• continuous verification through telemetry and metrics.

These are design targets, not performance guarantees.