How We Built an Institutional-Grade Crypto Trading Engine for Retail Traders

Why We Built Account-Level Checks

A trading signal does not say whether a particular account can act on it. The account may lack margin, already hold a conflicting position or have an order awaiting confirmation. After entry, protective orders still need to be placed and checked.

Stratz.in evaluates these conditions separately for each linked account. This Deep Dive explains those checks, how the system handles retries and how its records are reconciled with the exchange.

The Safety Pipeline

Every trade signal in Stratz.in passes through a multi-stage safety pipeline before any exchange order is sent. Any stage can block the signal for a given account, so account-specific decisions stay ahead of order placement.

Stage 1: Signal Evaluation

A strategy publishes a signal containing the instrument, direction (long/short), entry parameters, stop-loss level, and take-profit target. The signal is generic — it doesn't know about any specific user's account.

Stage 2: Per-Account Readiness

For each linked account, the system independently evaluates whether the signal is actionable:

def evaluate_readiness(account, signal):
    checks = [
        check_account_state(account),          # Is the account active? API key valid?
        check_position_state(account, signal), # Is there an existing position that conflicts?
        check_risk_sizing(account, signal),    # Does the account have sufficient margin?
        check_exchange_truth(account, signal), # Does our state match the exchange's state?
        check_market_data_freshness(signal),   # Is the market data current enough?
        check_idempotency(account, signal),    # Has this signal already been processed?
        check_duplicate_prevention(account),   # Is there a pending order for the same signal?
    ]
    return all(checks)

The same signal can pass for one account and fail for another. An account with sufficient margin and no conflicting position can proceed; one that fails either check cannot.

Stage 3: Order Execution

Only after all readiness checks pass does the system construct and send the order. The order includes:

• An idempotency key derived from the signal and account, so retried orders don't duplicate
• The correct order type (market, limit) based on strategy parameters
• Position sizing calculated from the account's available margin and the strategy's risk parameters

Stage 4: Protective Order Placement

Immediately after the entry order fills, the system places:

• Initial stop-loss — at the level specified by the strategy
• Take-profit — at the level specified by the strategy

These are separate exchange orders, so they remain on the exchange if Stratz.in goes offline. In the recorded production window, median broker acknowledgement was 170ms for stop-loss requests and 269ms for take-profit requests. Those figures measure acknowledgement, not the full protection workflow.

Exchange-Truth Reconciliation

Local account state can drift from exchange state. The system may record a position; the exchange may not. This happens because:

• API responses are eventually consistent
• Webhooks arrive out of order
• Network partitions cause retries that may or may not have succeeded
• Exchange maintenance windows change state without notification

Stratz.in handles this with continuous exchange-truth reconciliation. The system periodically fetches the actual account state from the exchange and compares it against its internal model. When they disagree, the system reconciles — adopting orphaned positions, closing phantom ones, and correcting accounting records.

Over the production window, the system processed 2,558 exchange-truth reconciliation events.

Breakeven and Trailing Stops

A breakeven trail moves the stop-loss to the entry price once the configured threshold is reached. Stratz.in automates this:

1. Detect — the system monitors the position's unrealised PnL. When it reaches the breakeven threshold, the trail begins.
2. Command — the system sends a modify-order request to move the SL to the entry price.
3. Verify — the system waits for exchange acknowledgement and verifies the SL was actually moved.
4. Retry — if the modify fails (network error, rate limit), the system retries with backoff.

Over the production window, the system ran ~3,200 breakeven lifecycles, each requiring command, verification and retry handling. It logged 643 retry events and zero orphaned breakeven operations.

Idempotency: Why It Matters

In distributed systems, retrying a failed request is standard. Without duplicate prevention, a retried trade request could create a second order and more exposure than intended.

Every order in Stratz.in has a deterministic idempotency key. If the system sends an order, doesn't get a response, and retries, the exchange recognises the idempotency key and returns the original order's status instead of creating a duplicate. The key must be stable across retries for the same request; a new key on every attempt would defeat duplicate prevention.

Accounting Convergence

The accounting layer records fills, fees and profit or loss. Every fill generates a fee, and every trade generates a PnL event. These must be tracked accurately for the user to understand their performance.

Stratz.in materialises accounting records from exchange fill data, not from internal order state. When the exchange says a fill happened at price X with fee Y, that's the truth. Internal state may lag; the exchange is the source of truth.

The system converges: it continuously processes fill events, reconciles them against order records, and computes position-weighted average costs, realised PnL, and unrealised PnL. The user's records are therefore based on exchange fills, with reconciliation correcting discrepancies.

The Numbers

Recorded from 8 March to 25 June 2026. These metrics describe execution infrastructure, not trading returns:

There were no observed broker-side 5xx or timeout order-create rejects in this window. Rate-limit rejects still occurred, and the median acknowledgement figures do not measure the full time from signal to execution.

What This Means for Your Project

The same problems arise when a payment request is retried or an inventory record disagrees with a fulfilment provider. Stable request identifiers and reconciliation give a system ways to detect and recover from those failures. Which checks are needed depends on the consequences of a duplicate or missing operation.

→ See the Stratz case study — the live trading platform, with its recorded production snapshot and account-level checks.