Getting Started
Dive into the world of cutting-edge algorythmic trading with our powerful platform. Start by clearing the onboarding troubleshooting guide below so your first required simulation runs on clean, validated data, then choose your desktop platform and finish setup.
Resolve the three most common onboarding simulation blockers
Use this plain-language guide when the starter simulation stops before completion. Start with the code shown in BitThor, follow the non-technical steps below, and rerun the same request once the issue is cleared.
BitThor needs more historical candles before it can test this setup
The starter simulation needs at least 50 candles to warm up the indicators safely. If the selected history window is too short, BitThor stops early instead of showing a misleading result.
- Switch to a supported symbol with deeper bundled history, such as BTCUSDT or ETHUSDT.
- If you narrowed the candle window or changed the data source, widen it so the run includes at least 50 complete candles.
- Run the data check again before starting the sample simulation.
BitThor detected a settings change between review and simulation
This usually means the saved bot settings changed after the current page loaded. BitThor stops so you do not validate one configuration and activate another by mistake.
- Reload the bot or reopen the setup wizard so the latest saved settings are back in view.
- Confirm the symbol, indicator settings, and risk controls still match what you expect.
- Run the simulation again only after the refreshed settings are visible.
BitThor found a data or simulation-record integrity problem
BitThor stopped because the historical candles, simulation payload, or audit record did not pass an integrity check. This protects you from reviewing incomplete or inconsistent results.
- Refresh the page and rerun the onboarding data check so BitThor can request a clean dataset.
- If you imported or edited historical data, replace incomplete rows or switch to a bundled supported symbol.
- If the issue repeats, restart BitThor so the simulation audit store can be rebuilt cleanly before you continue.
From Simulation to Live Trading: The 3-Step Journey
Learn how to move from a successful simulation to a live trading bot through the three critical stages of drafting, validation, and deployment gates.
Deployment Failure Diagnostic Wizard
Enter your error code and follow the branching, step-by-step remediation path — covering HASH_MISMATCH, CONNECTION_ERROR, TOKEN_EXPIRED, and MISSING_MARKET_REGIME.
The Blueprint Standard: From Simulation to Immutable Record
A Blueprint Draft creates an immutable record of the parameters, indicators, and risk controls documented during a simulation. It preserves Verifiable History for later process review, regardless of later configuration changes.
Use this procedural path to document what was tested before deployment gates are reviewed: Simulate -> Archive Blueprint Draft -> Validate Gates -> Deploy Live. The Blueprint Draft is a Compliance Artifact and historical configuration record, not a prediction tool.
1. Simulate
Run a historical simulation against bundled OHLCV data to create an auditable record of trade decisions, signal contribution, and recorded outcomes for process review only.
Risk note: Simulated P&L and historical results are hypothetical, educational outputs. They do not guarantee future performance or reduce live-trading risk.
2. Archive Blueprint Draft
Save the tested parameters as an immutable Blueprint Draft: a Verifiable History and Compliance Artifact containing the exact 13 parameters, indicators, and risk settings documented in the run.
3. Validate Gates
Review the three deployment integrity gates - Configuration Hash Check, Activation Token Check, and Market Connection Health - against the archived Blueprint Draft before live deployment is available.
The Blueprint Draft: Compliance Artifact and Auditable Record
BitThor uses a four-stage documentation path: Simulate → Archive Blueprint Draft → Validate Gates → Deploy Live. The Blueprint Draft is a Compliance Artifact and Auditable Record for process review, not a prediction tool.
Simulate & Audit
Run the historical simulation, then review trade activity, signal context, and audit notes as a completed diagnostic record.
Archive to Blueprint Draft
Save the tested parameters as an immutable Compliance Artifact so later reviewers can identify exactly which configuration was documented.
Validate Gates
Compare the live deployment path against configuration hash, activation token, and connection-readiness gates before any live action.
Review how the Auditable Record is structured
The explainer shows how Blueprint Drafts connect simulation evidence, archived parameters, and validation review without treating the archive as a forecast.
The Blueprint-First Workflow
Treat the Blueprint Draft as the recommended Auditable Record between simulation review and deployment validation. The goal is auditability, reproducibility, and process integrity: each validation step should point back to the same archived configuration record.
This workflow is educational and diagnostic. It does not provide personalized trading advice, and it does not imply that a simulated or historical result will repeat in live market conditions.
1. Simulate and audit
Review the completed run, trade audit trail, signal attribution, and any simulated P&L as historical modeling evidence only.
2. Archive Blueprint Draft
Save the tested parameters as an immutable Blueprint Draft so the configuration can be referenced later without relying on temporary results screens.
3. Validate gates
Use the active Blueprint Draft as the preferred validation context for configuration hash, activation token, and market connection readiness checks.
4. Deploy live
Proceed only after technical gates pass and you understand that live trading uses real capital and remains exposed to changing market conditions.
Review the Bot DNA Profile before deployment validation
The Bot DNA Profile explains how the archived Blueprint Draft, signal weighting, and historical snapshot fit together as a diagnostic record.
The Blueprint Standard: From Simulation to Immutable Record
BitThor uses a structured documentation workflow centered on an immutable Blueprint Draft: the archived parameter record required before deployment validation.
Document the process in four procedural stages: Simulate -> Archive Blueprint Draft -> Validate Gates -> Deploy Live. The Blueprint Draft records the exact configuration used during analysis as Verifiable History and a Compliance Artifact for later review.
1. Simulate
Run the simulation wizard against historical data to create a completed diagnostic record of parameters, signal activity, and recorded trades.
2. Archive Blueprint Draft
Save the configuration as a Blueprint Draft. This creates the immutable record that documents the tested parameters before validation gates are reviewed.
3. Validate Gates
Review the configuration hash, activation token, and connection-health gates using the Blueprint Draft as the source of truth for the archived parameters.
4. Deploy Live
Proceed only after technical gates pass and you accept that live trading uses real capital and remains exposed to changing market conditions.
From Simulation to Live: What to Expect When Deploying Your Bot
When you click View Live Trading Options after a successful simulation, BitThor opens the Deployment Readiness Check modal. This modal walks you through three server-side gates that must all pass before your bot can go live. You must acknowledge each step before proceeding.
Step 1 — Bot Configuration Hash Check
What happens: The server recomputes your bot’s configuration hash and compares it against the hash recorded when you ran the simulation.
Why it matters: This confirms the activation request is using the exact configuration that was tested. Any change to your bot settings after the simulation invalidates the match.
If it fails: Deployment is blocked. Close the modal, review your bot settings, and re-run the simulation before trying again.
Step 2 — Activation Token & 5-Minute Window
What happens: When the hash check passes, the server issues a 5-minute activation token tied to this bot and session. If the same valid configuration is confirmed again within the window, the server returns the same token.
Why it matters: The time-limited token prevents a stale approval from being used after conditions have changed.
If it fails: If the window expires before you submit, close the modal and re-open it to begin a fresh validation pass.
Step 3 — Live Analyzer Connection Health
What happens: BitThor confirms that its live market analyzer is in an active, connected state before issuing the deployment token.
Why it matters: A bot activated before the analyzer is ready would miss market signals and potentially enter the market at the wrong time.
If it fails: Wait a moment for the connection to establish, then re-open the modal and try again.
All three gates passed — what happens next
Once you acknowledge all three steps and click Submit Deployment, the server activates your bot. Its status changes to Active and it immediately begins monitoring the market using the configuration and strategy settings from your simulation. The first real order will be placed the next time entry conditions are met on your exchange.
The Three Pillars of Deployment Integrity
Before a bot can move from simulation review toward live activation, BitThor checks the configuration fingerprint, activation-token window, and live market connection. Use this guide to translate the three most common deployment blockers into plain-language recovery steps.
Configuration Hash Check
HASH_MISMATCHPlain language: Your bot's saved settings no longer match the Blueprint or simulation snapshot being used for deployment review.
Why it happens: A setting, indicator, symbol, or risk control was changed after the historical configuration was recorded.
- Open the Bot Drift Comparison View and review the highlighted parameter differences.
- Choose whether the live bot or the Blueprint snapshot is the correct process record.
- Save the intended settings and rerun simulation before attempting deployment again.
Activation Token Check
TOKEN_EXPIREDPlain language: The temporary deployment key is no longer valid for the current bot and session.
Why it happens: The 5-minute activation window elapsed, the workflow was reopened, or the session context changed before final activation.
- Return to the deployment walkthrough for the same bot and session.
- Run the validation steps in one continuous pass so BitThor can issue a fresh token.
- Complete activation before leaving the walkthrough or allowing the token window to expire.
Market Connection Health Check
CONNECTION_ERRORPlain language: BitThor could not confirm that the live market connection was ready at the moment deployment was checked.
Why it happens: The exchange, local network, analyzer startup state, or rate-limit window was temporarily unavailable.
- Wait briefly and verify your local network and exchange access.
- Retry the live market health check without changing bot parameters.
- If the issue repeats, capture the failure time and error code for support review.
Understanding Your Bot's DNA Profile
Remember that the Blueprint Draft saves the configuration state, not the outcome. This immutable snapshot is vital for auditing system configuration integrity across deployments. Your archived Blueprint Draft is a precise record of the parameters used during a historical simulation — it serves as a verifiable reference for system integrity, not a predictor of future market performance or profitability.
Blueprint Drafts document system parameters at a point in time and do not guarantee future results. Always consult the full documentation for deployment risk assessment.
Engineer Your Strategy: Understanding Your Bot's DNA Profile
Learn how Blueprint Drafts, Signal Impact Score, and archived strategy inputs combine into a historical diagnostic profile before deployment review.
Understanding Signal Attribution
After a completed simulation, BitThor uses the read-only endpoint GET /api/v1/simulation/signal-breakdown/{sessionId} to populate the Simulation Summary Card's attribution layers. This endpoint returns the signal weights behind the run so you can inspect the raw component contributions that formed the final P&L and the educational Signal Impact Score summary.
Risk note: Any displayed P&L is simulated or historical and is provided for educational review only. It does not guarantee future results or reduce the risk of loss in live cryptocurrency trading.
Deep Dive: Signal Breakdown Data
Input: the sessionId from a completed simulation. Output: buy-side and sell-side weighting arrays, exact SignalName and SignalConfidence values, capped top-signal rows, total session P&L, signal diversity, and the historical weighting data used to explain the final result.
P&L and signal weighting outputs are simulated or historical diagnostics only and do not predict future returns.
If the sessionId is invalid or the simulation record is missing, BitThor shows an inline reminder telling you to complete a simulation first before reviewing signal attribution data.
Simulation Troubleshooting Hub
Use this plain-language guide when the starter simulation stops before completion. Start with the code shown in BitThor, follow the non-technical steps below, and rerun the same request once the issue is cleared.
BitThor needs more historical candles before it can test this setup
The starter simulation needs at least 50 candles to warm up the indicators safely. If the selected history window is too short, BitThor stops early instead of showing a misleading result.
- Switch to a supported symbol with deeper bundled history, such as BTCUSDT or ETHUSDT.
- If you narrowed the candle window or changed the data source, widen it so the run includes at least 50 complete candles.
- Run the data check again before starting the sample simulation.
BitThor detected a settings change between review and simulation
This usually means the saved bot settings changed after the current page loaded. BitThor stops so you do not validate one configuration and activate another by mistake.
- Reload the bot or reopen the setup wizard so the latest saved settings are back in view.
- Confirm the symbol, indicator settings, and risk controls still match what you expect.
- Run the simulation again only after the refreshed settings are visible.
BitThor found a data or simulation-record integrity problem
BitThor stopped because the historical candles, simulation payload, or audit record did not pass an integrity check. This protects you from reviewing incomplete or inconsistent results.
- Refresh the page and rerun the onboarding data check so BitThor can request a clean dataset.
- If you imported or edited historical data, replace incomplete rows or switch to a bundled supported symbol.
- If the issue repeats, restart BitThor so the simulation audit store can be rebuilt cleanly before you continue.
Establishing Your Blueprint: Documenting Your Strategy
A Blueprint Draft documents the strategy parameters, indicator settings, risk controls, and simulation context that existed at the time of a completed historical run. The purpose is record-keeping: it gives you a fixed reference for later review before deployment gates are evaluated.
1. Run the historical simulation
Review the completed run as a historical software record, including the parameters and signals used during that test window.
2. Save the Blueprint Draft
Archive the selected configuration as an immutable historical record so later checks can reference the same documented parameters.
3. Review deployment gates
Use the archived record when reviewing configuration hash, activation token, and connection-readiness checks.
Download BitThor for Your Desktop
Get BitThor for your desktop and open the auditable control panel workflow on the platform that matches your machine.
Choose a platform before you continue · Version 0.0.89.5 · All versions →
Risk Disclosure: Download CTAs are provided for educational pattern recognition workflows and software evaluation only. This content does not constitute a recommendation for specific trading strategies. Cryptocurrency trading involves substantial risk of loss and is not suitable for every user. BitThor provides software tools only and does not provide investment advice.
Review installation steps
After choosing your platform above, use the download page to review the .NET prerequisite and the full install flow for your operating system.
View install guide
Explore our Blog
Explore our comprehensive blog topics to get started and discover the full capabilities of BitThor. Our blog covers topics from initial setup to advanced features, including running options, ensuring you have all the information you need.
Explore the topics
View our FAQ
Checkout the FAQ section to learn about the most common asked questions and get up and running quickly.
FAQ
How It Works
Be sure to checkout this section to understand how BitThor works in the background.
Explore the topics