SignalForge

SignalForge is the quantitative index and strategy platform behind ARKONIX's model-driven vault products. It defines rules-based indices, backtests and validates strategies against real venue data, wraps qualified strategies in a capital-protection layer, and publishes the resulting signals, marks, and execution directives — every one of them cryptographically signed — for consumption by the platform's execution layer.

Owned and operated by Arkonix Capital Management

SignalForge is a product of Arkonix Capital Management (ACM), a separate entity from the platform operator (Arkonix Finance). ACM produces signals; the platform executes them under its own risk controls. The platform consumes SignalForge outputs as strategy inputs — execution, settlement, custody, and infrastructure remain platform concerns. For due diligence this is the key boundary: signal generation and trade execution are separated by both system and corporate lines.

The SignalForge section has three pages:

• This page — what the service is, how it fits the stack, and how its outputs reach the platform.
• Index Catalog & Strategies — the published indices, the HAVEN protection wrapper, the ARIA meta-allocator, and the research-to-freeze workflow.
• Attestation & Verifiable Compute — the signing, anchoring, and verification stack that makes every publication independently checkable.

What SignalForge does

1. Rules-based indices. Six indices are currently published — DGI, JRRT, BYI, APYC, ATLAS, and ATLAS-L — each defined as a declarative, versioned methodology and computed by a deterministic calculator engine. See the index catalog.
2. Strategy research and validation. A simulation suite ("Strategy Lab") backtests rules-based strategies on real venue data, with frozen, checksummed data snapshots for reproducibility and a formal research → validation → freeze workflow.
3. HAVEN. A capital-protection wrapper that converts a qualified strategy into a capital-protected or defined-outcome fixed-tenor vault product using a capital-protection mechanism — two assets and a rebalancing rule, no options or derivatives.
4. A machine-ingestable signal service. Strategy discovery, daily attested signals, intraday marks, and complete vault execution directives for the downstream execution platform. Every published number is cryptographically signed, and daily signals are anchored on-chain.

Role in the stack

SignalForge (ACM)                          ARKONIX platform
─────────────────                          ────────────────
market data ─▶ deterministic ─▶ attested ─▶ strategy      ─▶ policy check,
               calculators      signals,    subscriptions    simulation,
               (frozen          marks,      (keepers          signed
               parameters)      directives   verify)          execution
                    │                            │
                    ▼                            ▼
             on-chain anchor  ◀── verify ──  target allocations
             (daily, write-once)             within vault risk controls

• Strategies subscribe to SignalForge outputs through the platform's strategy catalog; each subscription records provenance (which signal or index a vault follows).
• Execution is gated — signal outputs feed target allocations, which pass through the platform's policy verification and simulation pipeline before any transaction is signed (see Execution & Strategy Layer). A signal cannot move funds by itself.
• Everything is verifiable — each signal, mark, and directive carries a signed attestation envelope, and the platform verifies it before acting. Provenance is surfaced in the partner portal (signal source, run history, execution health), so partners can see what drove each rebalance. See Attestation & Verifiable Compute.

Parameters as data

The core design principle: published risk parameters are data, not code. Every strategy publishes a versioned, machine-readable risk-engine contract alongside its methodology, and the service serves that contract verbatim with every signal, merging in live daily state. The execution platform never derives, infers, or chooses — it replicates published methodology or executes explicit publisher instructions. This is a deliberate regulatory posture, not just an engineering convenience.

The contract covers, per strategy:

• Jump-exposure attestation — a signed scalar bound on the worst single-block loss the strategy can take, with the basis for how it was derived. This bound is what licenses a strategy for capital-protected wrapping. Strategies without a signed bound carry an explicit machine-readable refusal: subscribable for ingestion, but rejected for protection wrapping.
• Wrapper parameters — floor, tenor, multiplier policy, and rebalancing gates for any protected product built over the strategy.
• Engine invariants — facts a consumer must replicate or enforce, such as leverage caps and drawdown throttles.
• Halt policy — staleness windows for signals and price feeds, and per-source failure handling.
• Disclosures — honest caveats: concentration, behaviour beyond the attested bound, capacity limits, cost ceilings.

Consumer rules are equally explicit: ingest rather than hardcode (parameters may change with a methodology version bump), enforce the static contract, watch the live state merged into each signal, and reject any contract version you do not understand. Published risk parameters change only through a methodology version bump — see governance and frozen artifacts.

The daily production cycle

SignalForge runs one canonical production cycle per day, with four responsibilities in strict order:

gather ──▶ commit ──▶ compute ──▶ attest & publish

1. Gather. All inputs for the day — frozen historical snapshots plus live market and macro data — are assembled into a content-addressed input bundle per index and profile, with per-source status recorded.
2. Commit. The bundle is persisted before anything is signed. If the bundle cannot be committed, publication is refused — the pipeline fails closed rather than publishing an output whose inputs cannot be audited.
3. Compute. Index levels, weights, and risk-engine state are computed as a pure function over the committed bundle, so any output can be deterministically recomputed from its inputs.
4. Attest and publish. Each output is wrapped in a signed attestation envelope, persisted as the single canonical signal for that day, and anchored on-chain in a write-once daily record.

Three publication tiers reach consumers, all attested:

Tier	Cadence	Anchored on-chain
Signal	Daily — one canonical, immutable publication per index/profile per day	Yes (write-once)
Mark	Intraday — the day's fixed weights priced with live feeds, on monitoring ticks of up to 30 seconds	No — cryptographically chained to the day's anchored signal
Directive	On demand — a complete vault execution instruction	No — chained to the anchored signal via attestation references

How outputs reach the platform

Every published product reaches the platform through one of three paths, all delivered over ACM's service-internal signal API:

1. Index signal subscription — the platform's strategy keepers consume the daily attested signal for an index and profile: level, target weights (including explicit spot/perpetual splits for levered indices), realized volatility, rebalance flag, and the full risk-engine contract with live state.
2. Vault execution directives — for protected vault products that subscribe to a published index, the platform requests a complete, signed directive: floor value, cushion, multiplier, target strategy weight, halt state, and scaled per-asset weights. The directive leaves zero decisions to the executor and chains cryptographically to the day's anchored signal. This index-subscription path is the regulatory-preferred pattern.
3. Wrapped simulation strategies — protected products over simulation-path strategies (such as HAVEN over ARIA) deliver directives from a cached daily production run of the same wrapper engine.

On the platform side, keepers verify the attestation envelope before acting, and the resulting target allocations still pass through the vault's own Merkle-allowlist policy checks and pre-flight simulation — see Execution & Strategy Layer and the custody model. Actions are ultimately built and executed through the platform's DeFi SDK.

What SignalForge does not do

• It does not hold keys to user funds, sign vault transactions, or touch user assets.
• It does not operate vault settlement or the public platform API (see platform services).
• Its outputs are not investment advice to end users; they are inputs to vault strategies whose terms are disclosed per vault.

Further reading

• Index Catalog & Strategies — the six indices, HAVEN, ARIA, and the research workflow.
• Attestation & Verifiable Compute — the trust and verification stack.
• Execution & Strategy Layer — how the platform consumes signals and executes under its own controls.
• Custody & Key Management — why a signal alone can never move funds.