Backtesting on Mini Fish https://blog.minifish.org/tags/backtesting/ Recent content in Backtesting on Mini Fish Mini Fish https://blog.minifish.org/android-chrome-512x512.png https://blog.minifish.org/android-chrome-512x512.png Hugo -- 0.161.1 en-US Mini Fish 2014-present. Licensed under CC-BY-NC Sun, 31 May 2026 09:00:00 +0800 cta-guard: Risk Controls Before Trading Logic https://blog.minifish.org/posts/cta-guard-trading-risk-system/ Sun, 31 May 2026 09:00:00 +0800 https://blog.minifish.org/posts/cta-guard-trading-risk-system/ A sanitized project note on cta-guard, a Rust trading runtime and research tool focused on risk controls, ingestion, backtesting, and operational guardrails. cta-guard is a private trading-system project. It includes a runtime loop, ingestion tools, backtesting, walk-forward validation, health checks, and venue integration.

This is the kind of project where the most useful public topic is not the trading strategy. It is the guardrail design.

Why risk first

Trading code has a dangerous failure mode: a bug can become a position.

That changes the engineering priority. Before clever strategy logic, the system needs operational controls:

  • dry-run mode
  • explicit venue adapters
  • heartbeat checks
  • halted state
  • read-only mode
  • data freshness checks
  • position and exposure constraints
  • clear separation between research and live execution

The project name reflects that priority. The guard matters before the CTA.

System shape

The maintained path is a modular trader stack:

  • runtime orchestration
  • risk app service
  • strategy app service
  • backtest app service
  • domain models and ports
  • SQLite repositories
  • venue adapters and stubs

There are separate binaries for live or dry-run runtime, health checks, ingestion, historical import, backtest, and walk-forward validation.

That separation is important. A backtest binary should not have the same operational authority as a live execution process.

What should stay private

Some details are not appropriate for a public blog:

  • strategy parameters
  • production configuration
  • account or venue details
  • exact deployment topology
  • operational thresholds
  • anything that could imply a trade recommendation

The safe public layer is architecture: how to keep execution constrained, observable, and stoppable.

What I learned

Risk control is not one module. It is a state machine that should shape the whole runtime.

A good trading system needs to answer boring questions quickly:

  • is data fresh?
  • is the venue reachable?
  • is the runtime allowed to trade?
  • what happens after an error?
  • can the system stop without making things worse?
  • can research code accidentally reach execution?

If those answers are unclear, the system is not ready for live use.

Current status

cta-guard is private. I may continue writing about its engineering lessons, but only at the level of risk design, runtime isolation, and validation workflow.

]]>