How G-Type Works

This page explains G-Type as a governed geometric execution system from bounds setup to ongoing trade mode management.

Process Overview

Each cycle follows a fixed chain:

1. Run preflight checks and acquire core lock.
2. Build runtime context from market, account and order state.
3. Construct grid geometry and expected order depth.
4. Select and apply trade mode (accumulate, decumulate, rebalance, auto).
5. Apply risk envelope checks and evaluate reset conditions.
6. Route execution through cancel/rebuild/post lifecycle controls.
7. Publish telemetry, diagnostics and optional balance output.
8. Persist cycle state and release lock.

1) Bounds and Grid Geometry

G-Type computes ladder levels between LOWER_BOUND and UPPER_BOUND using configured interval spacing. This geometric structure drives both buy-side and sell-side order targets.

2) Auto Setup and Entitlement

When AUTO_SETUP is active, G-Type can perform initialisation checks and state writes for starting values. The strategy validates capital, bounds distance, min notional and mode eligibility before placing initial orders.

3) Trade Mode Selection

G-Type calculates buy-order value (BOV) and sell-order value (SOV) and uses hysteresis logic to determine mode:

• accumulate
• decumulate
• rebalance
• auto (strategy selected)

This mode logic governs how inventory is managed across range evolution.

4) Order Construction and Depth

The strategy builds viable buy and sell arrays from grid levels, then applies ORDER_DEPTH and amount viability checks to construct executable order sets.

5) Lifecycle and Safety Controls

Before posting, G-Type enforces checks for:

• min notional compliance,
• watch/kill switch state,
• partial-order conditions,
• stale and duplicate order handling.

6) Telemetry and Persistence

Each cycle updates chart targets, sidebar diagnostics and persistent state files. Metrics include TVIC, uPNL, trade mode, BOV/SOV context and trade-vs-HODL comparison.

Runtime Flow (Code-Mapped)

This flow is mapped to the live cycle orchestration in quanta_gtype.js and reflects the real grid control path used in production.

flowchart TD
    A([Cycle Start]) --> B{"Preflight and state checks OK?"}
    B -- "No" --> B1["Pause execution and log reason"] --> Z([Cycle End])
    B -- "Yes" --> C["Acquire core lock (runCoreBusy)"]

    C --> D["Build runtime context<br/>balances, bounds, intervals and precision"]
    D --> E["Grid engine<br/>generate ladder, order arrays, expected depth"]
    E --> F["Mode engine<br/>accumulate, decumulate, rebalance, auto"]
    F --> G["Risk envelope<br/>kill switch, watch mode, entitlement and partial-order checks"]

    G --> H{"Order reset required?"}
    H -- "No" --> I
    H -- "Yes" --> H1["Rebuild order basis<br/>manual reset, first-run, mismatch, parameter change"] --> I

    I["Execution Router (orderCentre)"] --> J{"Execution allowed?"}
    J -- "No" --> K["Hold state and monitor"]
    J -- "Yes" --> L["Cancel/refresh stale orders and post buy/sell grid sets"]
    K --> M
    L --> M

    M["Publish operator telemetry<br/>chart targets, sidebar diagnostics, mode metrics"] --> N{"BALANCE_OUTPUT enabled?"}
    N -- "Yes" --> N1["Write balance snapshot JSON"]
    N -- "No" --> O
    N1 --> O["Persist cycle state<br/>MSP, mode, intervals, timestamps"]

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

Strategic Outcome Mapping

G-Type’s operating model is designed to support:

• disciplined long-horizon inventory management,
• controlled accumulation/decumulation behaviour,
• deterministic order lifecycle execution,
• measurable runtime and performance transparency.

These are design objectives, not guaranteed outcomes.