Send Titan a signal. It runs 26 safety checks, then forwards or blocks — and hands back the decision, the reason, and a decision receipt you can verify later.
Titan is one instrument. It performs four operations on every automated trading decision your strategy makes, and each operation has a recorded boundary.
| Operation | Recorded evidence | Refusal boundary | Operator surface |
|---|---|---|---|
| Record | Signal payload, gate verdicts, evidence, timing, config hash, eval hash, decision signature. | Payloads carrying broker credential fields are rejected; missing agent keys cannot write a live signal. | Decision receipt |
| Replay | Candidate config, replay run, selected signal window, per-signal verdict flips, cascade state mutations. | Replay is not backtesting and does not predict profit; it only re-evaluates recorded decisions. | Deploy Gate run |
| Verify | Audit-chain leaf, per-account root, daily aggregate root, OpenTimestamps proof when available. | Bitcoin anchoring proves commitment to recorded evidence, not that the original input was complete. | Anchor proof file |
| Watch | Released candidate, live decision observation, warning materialization, drift status, review state. | Low evidence stays low evidence; release status is withheld when the observation window is too thin. | Release Watch |
The dashed arrow is the boundary. Everything to its left is the hosted Titan server; everything to its right runs on your machine. Titan evaluates, records, and anchors the decision — then your forwarder, holding your broker keys, is the only thing that places, closes, or cancels an order.
| Layer | What happens | Recorded as |
|---|---|---|
| Ingest | Normalize field aliases, dedupe by signal id, enforce the 1 MB body limit, reject any broker-credential field, and authenticate the agent key. The account is bound to the key — never to a value in the payload. | rate-limited · 400 on broker keys |
| Evaluate | Run the configurable 26-check pipeline. The first failing check stops evaluation — the checks after it never run. EXIT signals skip the entry-only checks. | Gate verdicts |
| Decide | Forward or block. A forward records the order intent it would hand off — the order it would submit, or the position it would close. The cloud sends nothing to a broker. | status + order intent |
| Record | Write the decision receipt: signal, normalized payload, every gate verdict, timing, config hash, evaluation hash, decision signature, and the broker-state source it read. | Decision receipt |
| Anchor | Append one tamper-evident leaf to your account's hash chain in the same database transaction. Leaves roll into a daily Merkle root; the root is committed to Bitcoin via OpenTimestamps. | Hash chain → Bitcoin |
| Execute | Off-cloud. Your forwarder polls the forwarded decision, executes it with your broker keys, then pushes broker state and fills back so the next decision sees reality. | Fills + broker state |
Every signal runs the same ordered pipeline. Each check is individually toggleable per account — resolved from your agent override, then your account setting, then the system default. The first failure stops evaluation, so a blocked signal records exactly which check stopped it and leaves the rest unevaluated.
Two dozen toggleable gates plus the always-on account-readiness and price-validity checks. Options signals add the expiry, Greeks, and portfolio-VaR checks (20–23 and beyond); equities skip them. EXIT signals skip the entry-only checks and record them as not-applicable rather than passing them silently.
Deploy Gate replays a candidate config against the signals that actually crossed your pipeline. CI/CD for trading rules — change a setting, replay your real signals, see what would change before going live.
Standard replay evaluates signals independently. Cascade replay is sequential: each forwarded signal changes portfolio state, and the next signal evaluates against that new state. Both replay real signals with real broker state — not backtesting, not synthetic data. You see what the candidate policy would have decided on every signal that actually crossed the pipeline, with the actual state evidence Titan recorded at the time.
Counterfactual replay applies the same machinery to a single past decision. Re-evaluate one historical trade under hypothetical config overrides, without writing anything. The evidence chain that runs against a cohort runs against a single decision.
Titan publishes Bitcoin-anchored commitments to canonical audit state at known times. Downstream users can take the trust-minimized local verification path with Bitcoin Core, or run a convenient external block explorer check with the explorer's trust assumptions.
Each recorded decision evaluation produces a leaf hash, written in the same database transaction as the decision itself. Leaves aggregate daily into per-account roots. Account roots aggregate into a single daily aggregate root. The aggregate root is committed to Bitcoin via OpenTimestamps and typically receives a Bitcoin attestation within hours.
Once anchored, a changed record no longer matches the published Bitcoin commitment — tampering becomes detectable by anyone, using only public data and the proof file. Input soundness is a separate layer (Titan's state provenance and deterministic re-evaluation handle that); Bitcoin provides the post-hoc proof that a record is the one Titan committed to, at the time it says.
| Rung | What you trust | Setup |
|---|---|---|
| 1 | OpenTimestamps calendars | No Bitcoin node required — inspect the proof file and calendar attestations |
| 2 | A public Bitcoin block explorer (mempool.space, blockstream.info) | None — open a URL |
| 3 | Local Bitcoin Core node | ~10 GB pruned, one-time sync |
The published commitment is the same at every rung. Bitcoin Core gives the strongest local verification path; block explorers are faster external checks that leave the explorer in the trust model.
Anchored traces in the operator console show anchor status. .ots proofs are downloadable when proof bytes are available; pending or unavailable proofs stay visible as status, not as a promised file. For proof-backed decisions, checking the commitment against Bitcoin is a one-command walkthrough — the same command an external auditor would run.
The verifier at /verify-decision recomputes the entire chain in your browser — its own SHA-256, its own Merkle folding, no server calls and no libraries. It walks a decision's leaf up through the per-account root and the daily aggregate root to the exact fingerprint handed to Bitcoin, and ships a self-test that rejects five tamper cases before it trusts itself. You are not asked to trust Titan; you re-derive the commitment and check it against a public block explorer or your own node.
A candidate's job isn't done when it goes live. After release, Titan compares live behavior against the replayed expectation and flags drift when the decision stream no longer matches the baseline.
When a candidate is released, Release Watch attaches to the release record. It evaluates live decision observations against the warnings the Deploy Gate run produced — for example, additional Position Limit blocks after a tighter config. If live behavior matches a recorded warning, Release Watch writes a flagged observation with evidence linked back to the original Deploy Gate run.
Every Release Watch evaluation is recorded. The release timeline becomes an auditable record of replayed expectation versus live behavior.
After release, Titan compares live behavior against the replayed expectation and flags drift. A flag can route back into the candidate lifecycle — a Deploy Gate re-evaluation or a config rollback.
Trace → Candidate → Deploy Gate → Release → Release Watch.
Every link is recorded. Proof-backed transitions are independently checkable through the published anchor/proof path when proof is available; recorded release and decision evidence can be checked against the anchor context those records carry.
A strict, typed, agent-key-authed surface. One header authenticates; the account is bound to the key. Malformed input returns a structured 422 — never a guessed decision.
| Endpoint | What it does |
|---|---|
POST /api/public/v1/eval |
Dry-run gate evaluation. Returns the allow/deny decision and a receipt id; never executes. |
POST /api/public/v1/signal |
Live ingestion through the full pipeline. Records the decision; in enforce mode your forwarder picks up the forward. |
GET /api/public/v1/decisions/{id} |
The verifiable decision receipt: gate verdicts, the eval hash, the decision signature, and anchor status. |
GET …/decisions/{id}/audit-anchor.ots |
The OpenTimestamps proof file for an anchored decision, for trustless Bitcoin verification. |
tak_ agent key, HMAC-SHA256. One canonical error envelope {"error":{"code","message"}}. Rate limits 120 eval/min, 60 signal/min per key. Config resolves agent override → account setting → environment default. Payloads carrying broker credentials are rejected with a 400.
GET /status (public, no auth). Public beta runs single-region on Render — no SLA yet, and we will not pretend otherwise; if Titan is unreachable, nothing forwards (fail-closed, by design).
Works with TradingView, Python bots, any REST client. Broker support starts with Alpaca.
Every plan, including the free one, gets all 26 safety checks, decision receipts, and Bitcoin anchoring. A paid plan changes how much of Titan you get, never how safe it is. If your account existed before launch, you keep full access free — founders terms, and they are already applied.
| Plan | Price | What it is for |
|---|---|---|
| Sandbox | Free | One agent, sandbox mode, the full gate pipeline, Bitcoin-anchored decision receipts (detailed history kept 30 days). Cage your bot and watch it get told no. |
| Operator | $29 / month | Live forwarding through your own forwarder, two agents, receipts retained while subscribed, standard Deploy Gate replay, the preflight and diagnosis API. |
| Desk | $99 / month | Up to ten agents and strategies, cascade replay and Deploy Gate run history, Release Watch, front-of-queue support. |
A system built to record evidence has to be straight about what the evidence settles — and what it doesn't. So it is here, once, instead of hedged into every paragraph above it.
Upload your Alpaca trade history. No account needed.
Your data is analyzed in real time and never stored.