How KEK Works

KEK is designed as a validation layer between strategy generation and capital deployment.

Every strategy moves through a structured lifecycle that separates intelligence, testing, refinement, and execution. No strategy becomes eligible for live execution without first being evaluated under historical simulation and real-market paper conditions.

This architecture exists to reduce execution risk, enforce discipline, and maintain clear non-custodial custody boundaries, where users retain control of their funds and authorizations.

What this page covers

This page explains:

  • The end-to-end strategy lifecycle within KEK
  • How intelligence, validation, and execution are separated
  • Where and how risk is controlled at each stage
  • How strategies improve over time through monitoring and refinement

Core design philosophy

KEK is not an execution-first trading platform.

KEK is built around validation before deployment.

Strategies are treated as hypotheses that must earn the right to execute. This approach prioritizes:

  • repeatability
  • transparency
  • risk awareness
  • long-term performance over speed

Validation is mandatory. Execution is optional.

Strategy flow overview

At a high level, strategies move through KEK in the following sequence:

1) Strategy generation

AI agents generate structured strategy candidates using market context, constraints, and objective-driven strategy templates.

Output: machine-readable strategy specifications (hypotheses)

2) Backtesting & optimization (historical validation)

Strategies are evaluated using historical data to measure performance behavior, risk, and failure modes.

Backtesting is the practice of simulating a trading strategy on historical data to analyze results and risk before risking capital.

Output: backtest reports, risk metrics, variant comparisons

3) Paper trading (real conditions, no capital risk)

Strategies that pass historical validation can be run in live market conditions without real money at stake, allowing execution behavior to be observed without exposing capital.

Output: live simulated performance, signal quality diagnostics, drift evidence

4) Monitoring & meta-learning (strategy health)

Performance is continuously monitored to detect drift, regime mismatch, or degradation that may trigger refinement and re-optimization cycles.

Output: monitoring alerts, refinement triggers, decision support

5) Execution (optional, user-authorized)

Only explicitly authorized strategies may execute through a non-custodial execution layer.

KEK's execution interface (KEK DEX) is Omnichain and built on Orderly Network's decentralized exchange infrastructure, which combines orderbook-based trading infrastructure with a liquidity layer for perpetual markets.

Output: live orders and fills — only when the user authorizes execution

Risk controls at each stage

KEK controls risk by enforcing boundaries between stages.

Intelligence / generation stage

Risk controlled by: structured strategy definitions, constraints, versioning

Prevents: ambiguous "ideas" from becoming deployable logic

Backtesting stage

Risk controlled by: historical simulation + measurable risk metrics

Prevents: untested strategies from reaching real conditions

Paper trading stage

Risk controlled by: real-market simulation with no real money risk

Prevents: fragile execution behavior from reaching capital

Monitoring stage

Risk controlled by: drift detection + refinement cycles

Prevents: "set-and-forget" decay in changing regimes

Execution stage

Risk controlled by: user authorization + non-custodial boundaries

Prevents: autonomous execution or custody exposure

Why this structure exists

This system design exists to:

  • Reduce execution and operational risk
  • Prevent untested strategies from reaching capital
  • Encourage disciplined, systematic trading
  • Maintain clear separation between intelligence and execution
  • Preserve non-custodial custody boundaries (users retain control of funds and keys)

KEK does not place trades autonomously and never has custody of user funds.

How to use this documentation

Each stage of the system is documented in detail.

Readers may:

  • Explore individual components independently, or
  • Follow the documentation in lifecycle order to understand how strategies evolve from hypothesis → validation → optional execution

Together, these components form a system designed to validate ideas before capital is exposed.