Risk Is a Routing Decision

CloddsBot does not treat risk as a report generated after an order. Its repository contains several points where a proposed action can be sized, warned about, paused, or rejected before reaching a venue. This chapter separates the RiskEngine’s analytical model from the process-wide gate, SafetyManager, execution circuit breaker, and TradingOrchestrator that wrap order paths. The reader will be able to ask the important systems question: which control is actually enforcing a limit on this path, and what happens when one of its inputs is missing?

Analysis, global state, and order-path enforcement

The name “risk engine” can hide several distinct responsibilities. CloddsBot’s RiskEngine presents the most comprehensive conceptual checklist. Its validateTrade() method can examine a kill switch, circuit breaker, maximum order size, exposure limits, daily loss, drawdown, concentration, Value at Risk, volatility regime, and Kelly sizing. It returns an approval decision with individual check results, warnings, a volatility regime, and a possibly adjusted size.

That is a useful model of the questions a trading system should ask. It is not automatically the same as the gate that every order encounters. In the current gateway, the richer RiskEngine is also exposed through a risk API with a risk context, while the execution path is visibly wrapped through a process-wide pre-trade gate, an execution circuit breaker, a SafetyManager, and a TradingOrchestrator. The distinction matters because an implemented class can offer an analysis endpoint without proving that all of its checks are invoked in every route.

A risk snapshot describes the condition of a portfolio or market. It can report VaR, drawdown, daily P&L, volatility regime, concentration, open positions, or Kelly information. A global safety state answers whether new trading is currently allowed at all. A pre-trade gate answers whether a particular request has an acceptable notional and is not blocked by the active breaker or safety state. A guarded execution wrapper makes those checks reusable for callers that would otherwise invoke the raw venue adapter directly.

CloddsBot’s process-wide gate exists because the application has execution paths that load at different times. Futures and Solana handlers can consult the same active safety sources even when their heavier modules are loaded lazily. The gate checks the circuit breaker and SafetyManager, validates a known USD notional when required, and compares it with the strictest configured order-size cap. This is a policy boundary shared across otherwise different execution modules.

The TradingOrchestrator adds another layer around the native execution service. It can pause the whole orchestrator, ask the SafetyManager whether trading is enabled, run trade-level validation such as concentration checks, and inspect the execution circuit breaker before calling the underlying buy, sell, maker, or protected method. It returns a rejection instead of sending a request when a check fails. Because the gateway replaces the raw service with the guarded version for downstream consumers, bots, signal routing, copy trading, and related callers can share the same wrapper.

This wrapping pattern is significant. A policy placed only in a user-facing command handler can be bypassed by an automated bot or background signal. A policy placed around the common execution object has a better chance of covering those callers. It still depends on every relevant consumer receiving the guarded object and on independent paths consulting the process-wide gate.