Skip to main content

38. Hardware Isolation for Live Trading Safety

Status: Accepted Date: 2025-07-06

Context​

In a trading system with multiple instances running (Read-only, Live, Experimental), there is a significant risk that an experimental or read-only instance could accidentally execute a live trade due to a bug or misconfiguration. A simple software flag (e.g., isLive = false) is not a sufficient safeguard against potentially catastrophic financial errors. A stronger form of isolation is required.

Decision​

We will enforce safety through hardware isolation. The API keys required for live trading will only be provided to the production environment of the dedicated W (Live Trading) instance. The R (Read-only) and ABH (Experimental) instances will be physically incapable of executing live trades because they will not have access to the necessary credentials. Their environment will contain dummy or read-only keys. This makes it impossible for them to place a real order, regardless of any bug in the application logic.

Consequences​

Positive:

  • Maximum Safety: This is the strongest possible guarantee against accidental live trades from non-live instances. It moves the safety control from software (which can have bugs) to the infrastructure layer.
  • Reduced Risk: Drastically reduces the risk profile of running experiments, allowing for more aggressive testing in the ABH environment without fear of financial loss.
  • Simpler Logic: The application logic does not need to be littered with if (isLive) checks. If the code attempts to trade from a non-live instance, it will simply fail at the API call level due to invalid credentials.

Negative:

  • Configuration Management: Requires careful management of deployment environments to ensure that the correct set of API keys is delivered to each instance type.

Mitigation:

  • Ansible Vault: Use Ansible Vault or a similar secrets management system to securely store and provision the different sets of API keys for each environment.
  • Strict Deployment Process: Implement a strict, automated deployment process with clear separation between the deployment configurations for the W, R, and ABH instances.
  • Health Checks: The application startup process for the W instance should include a health check to validate that its API keys have live trading permissions, and fail to start if they do not. Conversely, the R and ABH instances should validate that their keys do not have trading permissions.