Stratz.in

The Problem

Each linked account has different positions and available margin. Orders can be delayed or rejected, protective orders can fail to place, and local records can fall behind the exchange. Automating a trade means managing all of these conditions for every signal. Stratz needed to handle them across linked accounts.

What We Built

Stratz.in evaluates each signal separately for every linked account. Before sending an exchange order, it checks:

• Account state and position alignment
• Risk sizing and margin adequacy
• Reconciliation with exchange data
• Market-data freshness gates
• Idempotency and duplicate prevention
• Protection-order readiness

Only after all checks pass does the system send an order to the exchange. Once the entry order fills, it immediately places protective stop-loss and take-profit orders. It trails stops to breakeven, adopts orphaned exposure (open exchange positions with no matching local record), and reconciles trade records after every fill.

Architecture

The platform separates concerns into distinct execution layers:

1. Signal evaluation — strategies publish trade signals with entry, stop-loss, and take-profit parameters.
2. Per-account safety pipeline — each linked account is independently evaluated for readiness. The same signal may be valid for one account and rejected for another.
3. Order execution — orders are sent via exchange API with idempotency keys, retry classification, and rate-limit handling.
4. Protective order management — stop-loss and take-profit orders are placed immediately after entry fills. The system tracks breakeven trails, retries failed placements, and verifies each lifecycle step.
5. Accounting convergence — fills, fees and profit or loss are recorded and reconciled with exchange data. Every trade can be reconstructed from signal decision through final status.

Production Metrics

The following figures cover 8 March to 25 June 2026. They describe order handling and reliability, not trading returns:

• Zero observed broker-side 5xx or timeout order-create rejects
• 0.14% rate-limit rejection rate (33 out of 23,843 order requests)
• Sub-second broker acknowledgement at p50: entry 391ms, TP 269ms, SL 170ms
• ~9,000 take-profit placements, ~9,500 stop-loss trails
• ~3,200 breakeven lifecycles with 643 retry events
• 2,732 margin addition events
• 856 orphan/open-exposure adoptions
• 91 position reconstruction events

What We Learned

Across the recorded window, the platform saw no broker-side 5xx or timeout order-create rejects, but rate-limit rejects still occurred. The 391ms median measures broker acknowledgement of entry requests, not the full time from signal to execution.

Running the platform requires checks before an order is sent, and recovery when an exchange response is missing or state has drifted. The architecture section explains how those checks work.

→ Engineering deep dive: How we built the institutional-grade crypto trading engine