Don't trust us. Verify us.

1. Cryptographic build identity (Layer A)

The Spring Boot api, Java worker, and Express site are all signed with the same offline key before rollout. An Ed25519 signature over the canonical manifest {service, commit, image_digest, builtAt} is written into Cloud Run env vars and exposed via identity endpoints. If someone swaps the image — the signature won't match. If someone forges the manifest — it won't verify against the committed public key.

What this closes

• An attacker with Cloud Run or build-pipeline access who tries to push a malicious image — the Pulse probe catches the mismatch within an hour.
• A contractor with temporary deploy rights cannot later sign their own build in our name — they don't hold the key.
• "Someone swapped the bytes" stops being a guess and becomes arithmetic: either the signature is valid or it isn't.

2. Explicit risk gates before any LIVE order

Before a real order reaches the exchange, the request passes through a layered chain of independent checks in strict order. Each gate has a unit test and throws a structured ProductPolicyException with a specific risk_code. PAPER mode has only 2 gates — symbol allowlist + plan allows paper. LIVE passes the full chain.

1. Symbol allowlist SYMBOL_NOT_ALLOWED
   Symbol must be on the permitted list.
2. Regime guard DANGEROUS
   Market must not be in DANGEROUS regime (realised volatility + drawdown).
3. Runtime kill switch quantor.trading.live.enabled
   Global flag must be on.
4. User allowlist quantor.trading.live.allowedUserIds
   User ID must be in the runtime allowlist.
5. Non-zero notional
   Cannot start LIVE on zero order size.
6. Active subscription
   Subscription must be active and current.
7. Account not frozen
   Account in good standing, bot count under plan limit.
8. Plan allows LIVE
   The current plan permits LIVE — FREE does not. Starter allows LIVE on EMA only; advanced strategies (Breakout V1, TS Momentum V1, Adaptive Pro, Custom) require Pro or Teams.
9. LIVE_ADVANCED mode advancedStrategies
   Advanced mode requires a plan with the advanced-strategies feature.
10. Telegram linked
    Telegram account must be linked — dual-channel control.
11. Strategy whitelist
    Strategy must be in the permitted set for the execution mode.
12. Exchange keys verified
    Exchange API keys must be verified live, not just entered.
13. Max-notional ladder
    Per-plan cap on order notional:
    Starter ≤ $250 Pro ≤ $5k Teams ≤ $25k
14. Daily-loss ladder
    Per-plan daily-loss circuit breaker (source of truth: PlanLimitsCatalog.java):
    Free ≤ 1% Starter ≤ 2% Pro ≤ 5% Teams ≤ 10%

3. Regime detector — we're willing to sit on the bench

Quantor calculates the current market regime from realised volatility and drawdown from peak. When the regime is DANGEROUS, LIVE starts are blocked — regardless of plan, allowlist, or any other permission. PAPER works in DANGEROUS: a hostile market is a great time to test strategies on paper rather than on real money. The current regime is open to everyone: api/v1/market/regime.

The kind of contract this is

Most bots in this category optimise for volume — more trades, more fees, more vendor revenue. We optimise for "don't lose the user's money on a bad day." This reduces our own revenue during volatile periods, and we consider that a conscious trade-off.

4. Self-custody — by construction, not by promise

Quantor doesn't hold your money. Ever. By design:

• You create the exchange API key yourself on the venue you pick in the dashboard. Required permissions: spot trading only, withdrawals disabled — keys with withdrawal permission are rejected during save and verification.
• The key is encrypted with an AES-GCM master key that lives in GCP Secret Manager — a separate trust boundary from the database.
• The database holds only the encrypted blob + last4 + a verified=true/false flag.
• Even if Quantor's database leaks — keys can't be decrypted without the master key. And even if decrypted, funds can't be withdrawn — the exchange key forbids it.

5. Tamper-evident audit chain (Layer B)

Every audit-relevant event written through the API is recorded with a keyed hash that depends on the previous one: chain_hash = HMAC‑SHA256(secret, prev_hash || sha256(canonical_payload)). Any attempt to silently modify or delete a record after the fact breaks the chain — subsequent hashes stop matching. The HMAC secret lives in Secret Manager, outside the database, which is the point: an intruder holding the database cannot recompute a forged chain. The verifier endpoint reproduces the head hash server-side, and the Pulse probe obs.audit-chain.head checks integrity every hour.

The one exception, stated rather than buried

If the worker cannot reach the API at the moment a trade closes, it writes the fill straight to the ledger rather than lose it — a missing close would corrupt a track record far worse than an unchained one would. A row written that way carries no per-trade signature and no chain entry, because both are produced on the API path. As of 2026-08-31 this has happened twice: two closes on 2026-07-21, out of 203 rows since per-trade signing began. Both sit in the ledger with correct PnL, and neither is ever served as “verified” — the public verifier returns not-found for an unsigned row instead of pretending. A separate hourly sweep — the ledger-integrity sentinel, not the head-integrity probe above — counts the unsigned rows and any audit-chain shortfall, so the number is measured rather than discovered later.

Threat model

The scenario "a future intruder with database access quietly deletes a bad trade and pretends it never happened" — caught arithmetically. The scenario "a future founder edits history to suit themselves" — same. The chain cannot be forged without holding every key and every hash.

6. Pulse — one-click synthetic probe

13 probes through every layer of the stack in ~10 seconds. Side-effect free — writes nothing, sends no messages to real users, buys nothing. If anything turns red, the row shows the exact file:method:line where the chain broke. It isn't a "notification" — it's a real synthetic test scenario the operator runs after every deploy.

What it checks

Compared to a typical crypto-bot SaaS

Open numbers from public pricing pages as of June 2026. Not an attack on competitors — just facts.