Interactive Guide

Deployment Failure Diagnostic Wizard

Select your error code below and follow the step-by-step remediation path. Each flow ends with a clear next action and a legal disclaimer.

Important: Simulations are based on historical and modeled data and do not guarantee future market performance. This wizard diagnoses configuration discrepancies only. It does not predict profitability or prevent all market risks. Bot performance is never guaranteed.

Step 1 of 4 — Select Error Code

What error code did you receive?

Choose the code that appeared in the BitThor deployment modal or API response.

HASH_MISMATCH
1
Diagnosis — Identify the Configuration Drift

This error means the current live settings for your bot do not perfectly match the parameters used during your successful simulation. This is a critical safety feature designed to help identify configuration discrepancies.

Note: Bot performance is never guaranteed, and this feature helps manage configuration risk.

Check the current bot’s live configuration hash against the Blueprint Draft hash recorded at simulation time. Use the Blueprint Drift Comparison View inside BitThor to see which fields differ.

2
Action — Update Live Bot Settings

If the hashes do not match, you must update the live bot’s settings to reflect the validated Blueprint Draft parameters.

  1. Return to the Edit Bot screen.
  2. Use the Blueprint Draft Comparison View to identify the exact mismatched parameters.
  3. Manually update the necessary fields, or use the Apply Blueprint Changes function if available.
  4. Save your updated bot configuration before re-running the simulation.
3
Remediation — Re-simulate and Confirm

Re-run the simulation from the updated live bot configuration to generate a new, valid Blueprint Draft.

Final Guidance: Do not proceed to live deployment until the newly generated Blueprint Draft hash matches the live bot’s configuration hash. Always treat the deployment gate as a sequence: Configuration → Token → Health Check. Any failure resets the process.
This tool diagnoses configuration discrepancies and does not guarantee future profitability or prevent all market risks. Simulations are based on historical data and do not guarantee future performance.

CONNECTION_ERROR
1
Diagnosis — Identify the Source

This error indicates a temporary break in communication between your client and the BitThor platform. Connection stability is subject to external network factors and is not guaranteed.

Check your internet connection and ensure the bot service is running on your end. Also verify whether the exchange itself has a known maintenance window by checking their public status page.

2
Action — Attempt Reconnection

Attempt to reconnect via the Reconnect button in the BitThor interface. If the issue persists:

  1. Review your firewall and VPN settings — either may be blocking outbound API calls.
  2. Check the BitThor service status dashboard for reported rate limits or service degradation.
  3. If a rate limit is suspected, wait the recommended time period shown in the error detail before retrying.
3
Remediation — Escalate or Wait

If the connection cannot be restored after waiting, consult live support channels. Do not attempt critical trading actions until a stable connection is verified.

Final Guidance: Only proceed after confirming stable connectivity. If the connection issue persists for more than 30 minutes, review your Watched Symbols list for potential single-exchange dependencies.
Connection issues are subject to external network factors and do not guarantee the bot’s ability to execute trades or maintain operational status. This wizard does not guarantee connectivity restoration.

TOKEN_EXPIRED
1
Diagnosis — Confirm Token Expiry

Your activation token has expired (typically within 5 minutes of initial verification). This is a standard security measure to ensure deployment integrity.

Confirm the time elapsed since your initial successful verification. If more than 5 minutes have passed, the token is invalid and must be refreshed.

2
Action — Do Not Reuse Old Credentials

Do not attempt to use old credentials. You must restart the finalization process.

  1. Close the current deployment modal.
  2. Click Re-run Verification. This forces the system to re-authenticate the bot’s configuration against the live service and issue a new time-sensitive activation token.
  3. Once the new token is confirmed, submit deployment immediately without pausing.
3
Remediation — Complete Deployment

With a fresh token issued, complete the deployment walkthrough without delay. Tokens expire on a fixed 5-minute window regardless of activity.

Final Guidance: Always treat the final deployment gate as a strict sequence: Configuration → Token → Health Check. Any failure resets the process. If a token expires, the process restarts from step one — not from the token step.
This tool diagnoses token-related configuration issues only. It does not guarantee future profitability or prevent all market risks.

MISSING_MARKET_REGIME
1
Diagnosis — Missing Context Parameter

The MISSING_MARKET_REGIME error occurs when a non-wizard simulation run does not include the required marketRegime parameter. Valid values are: Bullish, Bearish, Sideways, Volatile.

The Market Regime is a mandatory audit context parameter. BitThor requires a declared regime for all non-wizard POST /api/v1/simulate/run-sample requests so that every simulation run has a permanent, auditable market context record.

Note: The Setup Wizard automatically defaults to Sideways when no regime is supplied. Only direct API calls are affected by this error.

2
Action — Include marketRegime in Your Request

Update your simulation request body to include the marketRegime field with one of the four supported values:

  1. Add "marketRegime": "Sideways" (or your preferred regime) to your JSON request payload.
  2. Choose the regime that most accurately represents your hypothesis about the current or expected market environment during the simulation period.
  3. The declared regime is persisted in the audit trail alongside all trade decisions — it does not alter the SMA crossover signal logic.

{ "symbol": "BTCUSDT", "durationCandles": 100, "isWizardRun": false, "marketRegime": "Bullish" }

3
Remediation — Retry the Simulation Request

With the marketRegime field present, resubmit the simulation request. The server will validate the value, persist it on every generated trade record, and return it in the response as marketRegime.

Final Guidance: Every non-wizard simulation run must declare a Market Regime. The value is a permanent, auditable record of the market context assumption used during the simulation. It does not alter signal logic — it ensures your historical analysis record is complete and reviewable.
Simulations are based on historical and modeled data and do not guarantee future market performance. The Market Regime parameter documents an analytical assumption only — it does not constitute a prediction of future market conditions or investment returns.

Related Guide

Full troubleshooting flowchart covering all deployment failure paths.

View Full Flowchart