What MACD Actually Measures​

MACD stands for Moving Average Convergence Divergence. The calculation is simpler than the name implies:

1. MACD line: 12-period EMA minus 26-period EMA
2. Signal line: 9-period EMA of the MACD line itself
3. Histogram: MACD line minus Signal line

Because MACD is derived from EMAs, it inherits their characteristics. It's a trend-following, lagging indicator. When the 12-period EMA is above the 26-period EMA, the market has trended up recently and the MACD line is positive. When those conditions flip, MACD goes negative.

The signal line smooths the MACD line, adding another layer of lag. The histogram shows the momentum of that difference: how fast MACD is changing relative to its own recent average.

MACD doesn't tell you where price is. It tells you the difference between two trend estimates, and how fast that difference is changing.

This is a subtle but important distinction. RSI measures where price sits within a recent range. Bollinger Bands measure how far price has strayed from a rolling mean. MACD measures the relationship between two trend lines. This makes it a trend momentum indicator, not a mean reversion tool. Applying it as if it were RSI is one of the most common mistakes algorithmic traders make.

The Three MACD Signals​

Signal 1: MACD/Signal Line Crossover​

The most widely used MACD signal:

• Buy when the MACD line crosses above the Signal line
• Sell when the MACD line crosses below the Signal line

This is a double-smoothed trend signal. The crossover indicates that short-term trend momentum (MACD) has turned relative to its own recent average (Signal). It's slower than a simple EMA crossover. The 12/26/9 default parameters on daily charts mean you're capturing trends that unfold over several weeks.

A common refinement: only take buy crossovers when both lines are below zero, and sell crossovers when both are above zero. Crossovers while both lines sit on the same side of zero have historically lower success rates because they fire while the dominant trend is still intact.

Strengths: Clear entry/exit signals, fewer whipsaws than raw price-based crossovers, good performance in trending markets.

Weaknesses: Lags significantly; generates frequent false signals in sideways or choppy markets.

Signal 2: Zero Line Cross​

• Buy when the MACD line crosses from negative to positive (the 12-period EMA crosses above the 26-period EMA)
• Sell when the MACD line crosses from positive to negative

This is the underlying EMA crossover expressed through MACD. It's slower and more conservative than a Signal line crossover, confirming a trend direction change with more conviction, but typically missing 30-40% of the move before signaling.

Zero line crosses work best for longer-duration position entries. On daily charts with standard parameters, a trending market might produce only 4-8 zero line crosses per year. That low frequency makes this signal better suited to swing or position trading than active algorithmic systems.

Signal 3: Divergence​

Divergence is the most powerful MACD signal and the most frequently misapplied:

• Bullish divergence: Price makes a lower low, but the MACD histogram makes a higher low — momentum is building even as price dips.
• Bearish divergence: Price makes a higher high, but the MACD histogram makes a lower high — momentum is fading even as price rises.

Divergence flags exhaustion in the prevailing trend. It does not provide a precise entry point. It tells you the trend may be running out of fuel. Entering on divergence alone without a confirmation signal (a crossover, a volume spike, a candlestick pattern) is a common mistake.

MACD Default Parameters: Why 12, 26, 9?​

The 12/26/9 settings originated in commodity markets in the 1970s, calibrated for weekly charts covering roughly two weeks, one month, and two weeks of smoothing. They've survived because they work reasonably well across timeframes, not because they're mathematically optimal.

Common alternative settings:

• Scalping (1h/4h charts): 3/10/16 or 5/13/8 — faster response, more signals per day
• Swing trading (daily charts): 19/39/9 — reduces noise in range-bound periods
• Position trading: 50/100/9 — captures only the strongest multi-week trends

The only way to know what parameters work for a specific asset and timeframe is systematic backtesting. Forum recommendations and YouTube guides are a starting point at best.

Building a MACD Strategy in VolatiCloud​

In the Strategy Builder, MACD conditions are built visually without writing code. The full indicator is available with configurable parameters, and it exposes three output values you can reference in conditions: macd (the MACD line), signal (the signal line), and histogram (the difference between them).

Basic MACD/Signal crossover entry:

1. Add a CROSSOVER node as your entry condition.
2. Set the left operand to an Indicator node: select MACD, output field macd.
3. Set the right operand to an Indicator node: select MACD, output field signal.

This fires when the MACD line crosses above the Signal line.

Adding a zero-line filter (MACD must be negative at the crossover):

Wrap the crossover in an AND node:

• Condition A: CROSSOVER — MACD over Signal (as above)
• Condition B: COMPARE — MACD line < 0

Exit condition:

Use a COMPARE node: MACD line < Signal line (exit when MACD drops back below Signal), or configure fixed stoploss and ROI targets in the strategy parameters.

Once you've defined the strategy structure, VolatiCloud stores it as an immutable version — so testing different parameter combinations never overwrites a configuration that was working. See strategy versioning for how that works.

Backtesting MACD Strategies​

MACD is a trend-following indicator, which means its performance varies dramatically across market regimes. Before backtesting, set the right expectations:

• Trending markets: MACD crossover strategies typically have a 40-55% win rate with a favorable win/loss ratio — many small losses, fewer but larger wins.
• Ranging markets: Frequent crossover signals each produce small losses as price oscillates. The strategy bleeds out through transaction costs.

Check your backtest across multiple periods:

Run backtests across at least 12 months to capture both trending and ranging periods. If you only backtest a trending period, the strategy parameters will be tuned to conditions that won't always hold. The avoiding overfitting guide covers why out-of-sample testing is essential before any MACD configuration reaches a live bot.

Metrics to focus on for MACD strategies:

• Profit factor above 1.3 as a minimum — the low win rate requires strong winning trades to compensate
• Max drawdown — MACD trend strategies can have extended losing streaks in choppy conditions
• Average bars in trade — if MACD is exiting trades after only 1-2 bars on average, the signal is too noisy for your timeframe

Combining MACD with Other Indicators​

MACD works better as part of a multi-indicator system than as a standalone signal. Effective combinations:

MACD + RSI: Use RSI to filter overextended entries. If MACD gives a buy signal while RSI is above 70, the price move has already run far. Skip that trade. The RSI mean reversion guide explains RSI behavior and how it complements trend signals.

MACD + Bollinger Bands: Take MACD crossover longs only when price is in the lower half of the Bollinger Band (below the midline). This reduces entries into already-extended moves. The Bollinger Bands strategy guide covers Band interpretation in detail.

MACD + EMA trend filter: Only take buy signals when the 50 or 200-period EMA is sloping upward — trading with the primary trend. This single filter substantially reduces whipsaws in downtrending assets. Building on EMA crossover mechanics helps you understand why this filter works.

MACD + Volume: Require above-average volume on the crossover bar to confirm the signal has real participation behind it. In VolatiCloud's Strategy Builder, the PRICE operand with the volume field gives you access to volume in your condition logic.

When MACD Fails — and How to Filter It​

MACD's main weakness is low-volatility, range-bound markets. During these periods:

1. MACD oscillates around zero without conviction
2. Signal line crossovers occur every few bars
3. Each crossover produces a small loss before the next reversal
4. Trading costs erode the account even when individual losses are small

Two practical filters:

ATR threshold filter: Only take MACD signals when the ATR (Average True Range) is above a minimum threshold. Below the threshold, the market doesn't have enough volatility for a trend to develop profitably, so skip all signals.

Histogram expansion filter: Only act on a MACD/Signal crossover when the histogram has been expanding (increasing in absolute value) for at least 2 consecutive bars before the crossover. This filters weak crossovers that fire as momentum is already fading, which is a common source of losing trades.

Both ATR and MACD's histogram output are available as indicator nodes in VolatiCloud's Strategy Builder, so either filter can be added to an existing strategy without restructuring the core logic.

VolatiCloud's MACD Toolset​

The three MACD output values (macd, signal, histogram) are all directly accessible as condition operands in VolatiCloud's Strategy Builder, which is not always the case on other platforms. Having all three enables the divergence-aware conditions and histogram momentum checks described above, without requiring any custom code.

After building a MACD strategy structure, hyperparameter optimization can search the parameter space automatically. Set fast EMA to a range of 8-15, slow EMA to 20-32, and signal to 7-12, then let the optimizer find combinations that performed well over your backtest window. What would take hours of manual configuration runs in the background, leaving you to review results rather than run them.

Before putting any MACD configuration into a live bot, run it through Monte Carlo simulation to understand worst-case drawdown across thousands of trade sequence permutations. MACD trend strategies can have extended losing periods in choppy markets. Monte Carlo tells you the shape of that worst case before real capital is at risk.

A Practical Starting Point​

A straightforward MACD strategy to build and backtest on VolatiCloud:

1. Open the Strategy Builder and create a new strategy
2. Set the entry condition: MACD line crosses above Signal line, with a zero-line filter (MACD < 0 at entry)
3. Configure stoploss at -5% and a trailing ROI exit
4. Run a backtest over 12+ months on your target pair and timeframe
5. Analyze results — check profit factor, max drawdown, and average trade duration
6. If metrics are promising, run hyperparameter optimization across fast/slow/signal ranges
7. Validate with out-of-sample data before deploying a live bot

MACD is most effective when you understand which of its three signals you're using and why. Start with the Signal line crossover, backtest it in isolation, and only add filters after you understand the baseline behavior.

Start building your MACD strategy at console.volaticloud.com.

What Bollinger Bands Measure​

Bollinger Bands consist of three lines plotted around price:

• Middle band: A simple moving average (default: 20-period SMA)
• Upper band: Middle band + (standard deviation × multiplier)
• Lower band: Middle band − (standard deviation × multiplier)

The default multiplier is 2.0. With normally distributed returns, bands set at 2 standard deviations capture approximately 95% of price action — meaning price spends only about 5% of the time outside the bands. When it does venture outside, that's a statistically unusual event.

What that means, however, depends entirely on the market context. And that's where most BB-based strategies go wrong.

Two additional derived values are worth knowing:

• %B: Shows where price is relative to the bands. A %B of 1.0 means price is at the upper band; 0.0 means it's at the lower band; 0.5 means it's at the middle. Values above 1.0 or below 0.0 indicate price has broken outside the bands.
• Bandwidth: (Upper Band − Lower Band) / Middle Band × 100. Measures how wide the bands are relative to price. Low bandwidth indicates compressed volatility.

Bandwidth is particularly useful for detecting the Bollinger Squeeze — when volatility contracts to its lowest level in weeks before a large directional move.

Two Valid Strategies, Two Opposite Logics​

BB strategies split into two approaches with opposite entry logic:

These two setups operate on opposite assumptions. Mean reversion expects price to return from the band toward the center. Breakout trading expects price to continue moving away from center.

Using mean reversion logic during a breakout is one of the most common — and expensive — mistakes in algorithmic trading. A narrow band that suddenly expands can send price far above the upper band and keep going for days. Buying that as "overbought" means fighting momentum at exactly the wrong moment.

The key is detecting which regime the market is in before applying the corresponding strategy.

Mean Reversion Setup​

The classic BB mean reversion trade works in ranging conditions where price oscillates between the upper and lower bands without breaking through consistently.

Entry logic:

• Close price is below the lower Bollinger Band (period 20, multiplier 2.0)
• Optional: RSI (period 14) below 35 as additional oversold confirmation

Exit logic:

• Price returns to the middle band (the 20-period SMA)
• Or a fixed stoploss triggers if the move continues lower

The rationale: a close below the lower band means price has moved more than 2 standard deviations from its recent mean. In a ranging environment, this level of deviation is temporary. Buying the extreme and targeting a return to average is a positive-expectancy trade — as long as the market is not trending.

That last condition is the catch. In a sustained downtrend, price can walk along the lower band for extended periods, triggering entry after entry as the trend grinds lower. Adding a trend filter — for example, only taking long signals when price is above the 200-period SMA — substantially reduces this failure mode.

This is the same trend-filter concept discussed in the EMA crossover strategy post, applied here to mean reversion: let the long-term trend determine which direction signals you accept.

The Bollinger Squeeze: Detecting Breakouts​

Financial markets alternate between contraction and expansion. Periods of narrow, quiet price action build energy for the next large move. Bollinger Bands visualize this directly: when the bands compress to their tightest reading in weeks, a breakout is typically near.

Squeeze detection:

1. Calculate bandwidth over the last N bars
2. When bandwidth drops to its lowest value in 20 bars, the squeeze is "on"
3. When bandwidth starts expanding and price breaks above the upper band → buy
4. When bandwidth starts expanding and price breaks below the lower band → short

The breakout entry does the opposite of mean reversion: instead of fading price toward a band, it follows price after the band is broken. The logic is that the breakout represents the release of compressed volatility, and that momentum tends to carry price significantly further in the breakout direction.

Building These Strategies in VolatiCloud​

VolatiCloud's Strategy Builder supports Bollinger Band indicators natively. Both the mean reversion and breakout setups can be configured visually without writing any code.

Mean reversion setup — step by step:

Open the VolatiCloud console, create a new strategy, and select the UI Builder mode. Add a COMPARE node with:

• Left operand: PRICE (close)
• Operator: lt (less than)
• Right operand: Bollinger Lower Band, period 20, multiplier 2.0

This fires when the closing price drops below the lower band.

To add RSI confirmation, add a second COMPARE node:

• Left operand: RSI, period 14
• Operator: lt
• Right operand: CONSTANT, value 35

Connect both COMPARE nodes to an AND node. The strategy enters only when price is below the lower band and RSI is simultaneously below 35 — filtering out entries where price is falling but momentum is not yet oversold.

To add the 200-period trend filter, add one more COMPARE node:

• Left operand: SMA, period 200
• Operator: lt
• Right operand: PRICE (close)

This reads as "price is above the 200-period SMA." Connect it to the same AND node. Now all three conditions must hold before the strategy enters a long trade.

Target exit: Set the ROI target to the middle band area. In practice, a fixed ROI of +2% to +4% at a short time horizon captures the mean reversion move without waiting for an exact band return.

Parameter Selection and Optimization​

The 20-period SMA and 2.0 multiplier are reasonable starting points — not optimal for every pair or timeframe.

Lowering the multiplier to 1.5 creates tighter bands that price touches more frequently, generating more entry signals at the cost of more false positives. Raising it to 2.5 generates rarer signals that represent more extreme price moves.

Period and multiplier interact: changing one changes the meaning of the other. Optimize them together, not in isolation.

VolatiCloud's Hyperparameter Optimization can search across both parameters simultaneously. A practical search space:

{
  "bb_period": {
    "type": "int",
    "low": 15,
    "high": 35,
    "step": 1
  },
  "bb_std_dev": {
    "type": "float",
    "low": 1.5,
    "high": 2.5,
    "step": 0.1
  }
}

Always validate any optimized combination on a holdout date range the optimizer never saw. The hyperparameter optimization guide explains how to configure parameter spaces and evaluate results without overfitting to historical data.

Backtesting Bollinger Band Strategies​

BB mean reversion strategies have a characteristic backtest profile: relatively high win rates (often 60–75%), but occasional large losses during trending periods. Understanding this profile helps you evaluate backtests honestly.

Key metrics to examine:

Maximum consecutive losses. Mean reversion strategies that work in ranging markets will have losing streaks during trending periods. How long are those streaks? What percentage of capital do they consume?

Performance segmented by market regime. Run separate backtests for a trending period and a ranging period. A strategy that looks excellent on a combined view can mask severe underperformance during one regime. VolatiCloud's backtesting engine lets you specify exact date ranges for each test.

Profit factor. For mean reversion strategies, a profit factor above 1.3 is a reasonable target before accounting for fees. Below 1.1, real-world transaction costs and slippage will likely eliminate the edge entirely.

See analyzing backtest results for a breakdown of each metric and how to interpret them.

After backtesting, run Monte Carlo simulation on your trade history to stress-test the strategy against random orderings of the same trades. If the edge is real, it should hold across thousands of alternative trade sequences — not just the one that happened to occur in your backtest. The Monte Carlo simulation guide explains what to look for.

Common Mistakes​

Treating the bands as hard support/resistance. Price can and does close below the lower band on multiple consecutive candles. A band touch is a signal, not a guarantee of reversal.

Mixing mean reversion and breakout logic on the same pair. Running a BB mean reversion bot alongside an EMA trend-following bot on the same pair creates conflicting signals. The EMA bot enters long precisely when the BB bot is hoping to close its position at the middle band. Use different pairs or coordinate deliberately.

Forgetting transaction costs when optimizing. A mean reversion strategy may generate many trades. At 0.1% per trade (maker + taker), ten trades per week produces an annual drag of roughly 10%. Always include realistic fee assumptions in your backtests.

Ignoring regime context during optimization. An optimizer that searches the entire backtest window may find parameters that work well in the dominant regime (trending or ranging) but fail badly in the other. Checking performance across both regimes prevents this. The avoiding overfitting guide covers this in detail.

Get Started​

Bollinger Bands are one of the more flexible tools in algorithmic trading. The mean reversion version suits traders who want higher win rates and more frequent entries. The breakout version suits traders comfortable with directional bets after volatility compression.

Both setups can be built and backtested in VolatiCloud without writing any code:

1. Open the VolatiCloud console and create a new strategy
2. Configure your BB conditions in the Strategy Builder
3. Run backtests across multiple market regimes using the backtesting guide
4. Optimize parameters with hyperparameter optimization
5. Stress-test results with Monte Carlo simulation before committing real capital

For context on how Bollinger Bands compare to RSI for mean reversion setups, see the RSI mean reversion strategy post.

The pattern is familiar: a strategy backtests well, hyperparameter optimization finds good parameters, and confidence runs high. So the bot goes live, often with full position sizes, on a live account, from day one. What follows is a rude lesson in the difference between historical simulation and real-world execution. This guide outlines a concrete framework for moving from backtest to paper trading to live deployment in a way that actually reduces risk.

Why Backtests Are Not Enough​

A backtest tells you how your strategy would have performed on historical data. That is genuinely useful. It can eliminate strategies that never had any edge, and it can reveal parameter sensitivity, drawdown depth, and how the strategy behaves across different market regimes.

What backtests cannot tell you:

• How your strategy performs when the future differs from the past. Markets evolve. A strategy optimized on 2023-2025 data may encounter conditions it has never seen.
• Whether your execution assumptions are realistic. Backtests assume you fill orders at the signal price. In live markets, slippage, partial fills, and API latency all eat into returns.
• Whether you can psychologically tolerate the drawdowns. Seeing a 15% drawdown in a backtest chart is very different from watching it happen to your real account over three weeks.

Paper trading solves the first and third of these. You run the real strategy logic, in real time, against live market data, but without real money on the line. This means you accumulate real performance data under real conditions, while still being able to abort without losing capital.

What Paper Trading Actually Tests​

Paper trading is sometimes dismissed as "not real because there's no emotional pressure." That is true but beside the point. The value of paper trading is not psychological rehearsal. It is data collection.

When you run a bot in paper mode for several weeks, you are measuring:

• Signal accuracy in live conditions. Does your indicator trigger when you expect it to?
• Trade frequency vs. expectation. A strategy that generates 50 trades per month in a backtest might generate 15 or 80 live, depending on market conditions.
• Drawdown behavior in the current regime. A trend-following strategy will underperform in ranging markets. Paper trading catches this before it costs you money.
• Execution quality. Most paper trading engines simulate fills at the signal price. Some, including Freqtrade (which powers VolatiCloud bots), apply configurable slippage models. Check your settings.

The goal at the end of a paper trading period is not "the strategy made money in paper mode." The goal is: does the live paper performance resemble the backtest, and are the differences explainable?

How Long to Paper Trade​

There is no universal answer, but the following thresholds are a useful starting point:

The trade count is more important than calendar time. Statistical significance requires a sample. A strategy that averages one trade per week has not been validated after two weeks and four trades. You simply do not have enough data to distinguish skill from luck.

Running Paper Mode in VolatiCloud​

VolatiCloud makes it straightforward to separate paper and live deployments. When you create a bot, you select the exchange configuration it uses — and VolatiCloud supports paper trading exchange configurations that simulate order execution without touching a real exchange account.

The bot lifecycle follows a clear path:

1. Draft — the bot is created but not yet running.
2. Running — the bot is actively trading (paper or live, depending on the exchange config).
3. Stopped — trading is paused; the bot retains its configuration and history.

You can run two bots with identical strategies simultaneously: one against a paper exchange, one against a live exchange with a small allocation. This lets you directly compare paper vs. live performance side by side and quantify your actual slippage in real time.

The bot lifecycle documentation covers the full state machine and how to configure exchange connections for paper trading.

The Paper-to-Live Transition Checklist​

Before moving any strategy from paper to live with meaningful capital, work through each of these checks:

1. Performance matches the backtest within reasonable tolerance​

Calculate the Sharpe ratio, win rate, and average profit per trade for your paper trading period. Compare to the same metrics from your backtest. Some divergence is expected. Aim for the direction and magnitude to be consistent. A strategy that showed 55% win rate in backtesting but 38% in paper trading has a problem worth investigating before deploying live.

2. Drawdown stayed within expected range​

Your backtest shows a maximum drawdown. Your paper trading period will show a different drawdown because it covers different market conditions. What you are checking is whether the paper trading drawdown is plausible given the backtest's worst-case figures. If paper trading produced a drawdown 3x worse than your backtest's maximum, that is a red flag.

3. Trade frequency is consistent​

A significant mismatch in trade frequency usually means your signal logic behaves differently on live data than on historical data, often due to indicator calculation edge cases, timeframe alignment issues, or data feed differences. Resolve this before going live.

4. You understand every losing trade​

Review the losing trades from your paper trading period. For each one, can you explain why the strategy entered? Does the loss make sense given the strategy's logic? Random-looking losses from a systematic strategy are a warning sign.

5. Alerts are configured​

Set up alerts before your bot goes live — not after. VolatiCloud's alert system can notify you by email when a bot stops unexpectedly, when a trade is executed, or when your bot's equity drops below a threshold. See the alerts documentation for configuration options.

Starting Small: Position Sizing for the First 30 Days​

Going live does not mean immediately deploying at your full intended stake. Use a graduated approach:

Week 1–2: Deploy at 25% of your intended stake amount. This is enough to experience real fills, fees, and slippage without full exposure.

Week 3–4: If performance is on track, increase to 50%. Review the fills from weeks 1–2 to quantify slippage relative to your paper mode.

Month 2+: Move to full stake only if live performance is consistent with paper trading and backtests.

The purpose of this approach is not timidity. It is calibration. Your first two weeks of live data will reveal whether your slippage assumptions were accurate. If real fills are 0.05% worse than paper fills on average, and you are trading 200 times per month, that is 10% annualized return drag you did not account for. Better to discover this at 25% stake than at 100%.

For a deeper treatment of position sizing methodology, see Position Sizing and Risk Management for Automated Crypto Bots.

Monitoring Live Performance​

Once live, your job shifts from building to observing. The first 30 days of live trading should involve active monitoring:

• Check equity curves daily. A healthy live strategy should produce equity curves that trend similarly to your backtested equity curve, with normal fluctuation.
• Review open positions. Make sure the bot is entering and exiting as expected. An open position that has been held far longer than your average holding period suggests something is wrong with your exit logic.
• Track slippage. Compare your average fill price to the signal price. Over time, this tells you whether your fee and slippage estimates in backtesting were accurate.

VolatiCloud's real-time monitoring panel shows live trade feeds, equity tracking, and position status with WebSocket-powered updates. You do not need to refresh a page to see what your bot is doing. The dashboard updates as trades happen. Read more in Real-Time Bot Monitoring: Live Trade Feeds and Equity Tracking.

When to Pull the Plug​

Knowing when to stop a live bot is as important as knowing when to start one. Pre-define your kill conditions before going live, not in the moment when emotions are running high:

Write these conditions down before you start. When a condition is triggered, you stop the bot first, investigate second. The temptation to give a live bot "a few more days" to recover is how small losses become large ones.

Connecting the Full Pipeline​

The paper-to-live framework only works if the earlier stages were done rigorously: backtesting, parameter optimization, and overfitting avoidance. A strategy that was overfit to historical data will fail in paper trading, and a strategy that fails in paper trading will fail in live trading. Each stage is a filter.

If you have not yet run hyperparameter optimization on your strategy, or you have not stress-tested it with Monte Carlo simulation, those steps belong before paper trading, not after. See Stop Guessing Your Parameters: Introducing Hyperparameter Optimization and Beyond the Single Backtest: Introducing Monte Carlo Simulation for details on those stages.

For guidance on building a backtest that reflects real conditions rather than historical coincidence, Avoiding Overfitting: Build Backtests That Predict Live Performance is the companion piece to this post.

Going Live With Confidence​

Paper trading is not a formality. It is the final validation gate before real capital enters the picture. The framework above is not about being cautious for its own sake. It is about making the paper-to-live transition a deliberate, data-driven decision rather than an act of faith in a backtest chart.

Start your strategy on VolatiCloud today: create a bot against a paper exchange, configure your alerts, and set a paper trading window based on your strategy's expected trade frequency. When the checklist above is complete, going live is a step you will take with actual evidence behind it, not just hope.

Get started at console.volaticloud.com or read the quick-start guide to set up your first bot.

What Is the AI Chat Assistant?​

The AI Chat Assistant is an agentic AI panel embedded in the VolatiCloud dashboard. It lives in a slide-out panel accessible from any screen, and it has access to your organization's resources: strategies, bots, backtests, exchanges, and performance data.

Unlike a generic chatbot, this assistant operates with org-scoped authorization. Every conversation is authenticated using your existing session. The assistant sees exactly what you see: scoped to your organization, respecting your role and permissions. It cannot access data from other organizations, and it cannot perform actions you don't have permission to perform yourself.

The VolatiCloud MCP Server works differently: it lets external AI tools (Claude in your terminal, Cursor) connect to VolatiCloud via a protocol bridge. The AI Chat Assistant is built into the product — no configuration required, no tokens to manage, no external tools to install.

Agentic: It Can Act, Not Just Answer​

The word "agentic" describes the key distinction here. A traditional chatbot responds to questions with text. An agentic assistant can execute tools (queries, mutations, lookups) to accomplish tasks on your behalf.

When you ask "What's my best-performing strategy this month?", the assistant doesn't guess. It queries your backtest results, compares Sharpe ratios and profit factors across your strategies, and returns a ranked answer backed by real data from your account.

When you ask "Create a backtest for the RSI mean reversion strategy over the last 90 days on BTC/USDT", it can initiate that backtest run. It doesn't just tell you how to do it.

Every tool call the assistant makes is visible in the chat UI. You'll see a collapsible card showing what action was taken (query name, inputs, output status) before the assistant's response. This transparency means you always know what the assistant did, not just what it said.

What the Assistant Can Do​

The assistant has access to the same GraphQL API that powers the dashboard, which means it can:

• Query your data — list strategies, bots, exchanges, backtest results, trade history
• Explain results — interpret a backtest's profit factor, Sharpe ratio, max drawdown, or win rate in plain language
• Compare options — rank strategies by performance metrics, compare runner configurations, evaluate exchange connections
• Trigger operations — initiate backtests, check bot status, start or stop bots (with your confirmation)
• Surface context — when you're looking at a specific strategy or bot, ask questions about it in natural language

This turns the dashboard from a series of static screens into a conversational interface for your trading data.

Org-Scoped Auth: Your Data Stays Yours​

Security and data isolation are not an afterthought. The auth model is identical to the one used throughout VolatiCloud: every request the assistant makes goes through the same JWT verification and Keycloak-enforced permission checks that protect your organization's resources.

Concretely, this means:

• Your session, your scope: The assistant authenticates using your existing dashboard session. It inherits your role (admin, member, viewer) and cannot escalate privileges.
• Organization isolation: If you're in Org A, the assistant cannot access Org B's data even if you're a member of both. Conversations are scoped to the currently active organization.
• Viewer-safe: A viewer-role user can ask the assistant to retrieve data, but it will refuse to execute write operations (creating bots, starting backtests) because your role doesn't permit those actions.
• Conversation history is private: Past conversations are stored under your organization's namespace. Other members of your organization cannot read your conversations.

The org-scoped model also makes the assistant context-aware. When you navigate to a specific strategy page and open the chat panel, the assistant knows which strategy you're viewing. You can ask "What are the RSI parameters in this strategy?" without specifying which one — it understands the current context.

Persistent Conversation History​

Each chat session creates a named conversation. Conversations persist across sessions. Close the panel, come back tomorrow, and your conversation history is intact.

The conversation list view shows all your past sessions, ordered by recency. Each conversation shows a title (auto-generated from the first message) and timestamp. You can switch between conversations, continue where you left off, or start a new chat when switching context.

This is useful for iterative work. A typical workflow might look like:

1. Monday: You ask the assistant to analyze your last three backtest runs and identify the parameter that most affects drawdown
2. Tuesday: You reopen the same conversation, apply the suggested parameter change in the Strategy Builder, run a new backtest
3. Wednesday: You come back to compare before/after results in the same conversation thread, with context intact

Rather than starting from scratch each session, you build up a working thread with full history.

Practical Use Cases​

Strategy Research​

When you're building a new strategy in the Visual Strategy Builder, the assistant can help you think through indicator combinations and their historical behavior. Ask it to explain what a crossover between a 12-period EMA and 26-period EMA signals, or whether adding an RSI filter to your existing trend-following logic makes conceptual sense.

More practically, once you've run a backtest, you can ask the assistant to interpret the results:

"My backtest shows a profit factor of 1.4 with a Sharpe of 0.8 and a max drawdown of 23%. Is this worth deploying?"

The assistant won't just recite definitions. It'll put the numbers in context — a 23% max drawdown is substantial for a strategy targeting 15% annual returns, and it'll tell you that.

Operational Questions​

Not everything requires deep analysis. Sometimes you just need quick answers:

• "How many bots do I have running right now?"
• "Which exchange is connected to my BTC/USDT bot?"
• "What was the last trade my ETH scalper made?"
• "Is my Binance API key still valid?"

These are the kinds of questions that normally require clicking through multiple screens. The assistant handles them in one message.

Backtest Comparison​

After running multiple backtests with different parameter sets, comparing results by hand is tedious. The assistant can pull all backtest results for a strategy, extract the key metrics (profit factor, Sharpe, win rate, max drawdown, trade count), and present them as a ranked comparison. You identify which parameter combination performs best without opening each result individually.

This pairs naturally with hyperparameter optimization: run an optimization pass, then use the assistant to interpret which parameter set won and why.

Pre-Deployment Checklist​

Before moving a bot from paper trading to live, you can use the assistant as a sanity check:

"Review my RSI mean reversion bot setup — is there anything I should verify before switching to live trading?"

The assistant will check the configuration, look at recent backtest performance, verify the exchange connection is active, and surface any obvious issues: a stoploss percentage that's unusually tight, or a timeframe mismatch between the strategy's backtest config and the live bot config.

How It Compares to the MCP Server​

VolatiCloud now has two AI-powered interfaces, and they serve different workflows:

The two interfaces are complementary. Use the in-dashboard assistant when you're analyzing data or making operational decisions. Use the MCP server when you want your AI coding assistant to help you write and iterate on strategy logic, or when you prefer to work from your terminal.

For a deep dive on the MCP server workflow, see Control VolatiCloud with AI: Introducing the MCP Server.

Getting Started​

The AI Chat Assistant is available to all VolatiCloud users. Open the dashboard at console.volaticloud.com and look for the chat icon in the navigation bar. The panel slides in from the right side of any screen.

A few suggestions for getting the most out of it:

Start with questions about your data. The assistant is strongest when it can pull real data from your account and reason about it. Generic questions about trading theory will work, but specificity gets much better results.

Name your conversations. When you start a new thread for a specific project (researching a new strategy, preparing to deploy a bot), give it context in your first message. The assistant will use that context throughout the conversation.

Check the tool call cards. Every action the assistant takes is shown as a collapsible card in the chat. Reviewing these helps you understand what data the assistant used to form its answer, and it's a good habit for validating responses.

Use it iteratively. The persistent history makes iterative workflows natural. Start a thread when you're researching a strategy, and keep adding to it as you backtest, optimize, and eventually deploy.

The AI Chat Assistant is live now. Log in to console.volaticloud.com and open the chat panel to try it. If you have feedback or feature requests, the assistant itself is a good place to report what's not working.

For a broader view of how AI fits into the VolatiCloud workflow, see Real-Time Bot Monitoring and Strategy Versioning and Forking for context on the underlying features the assistant can work with.

What Is an EMA and Why Do Traders Use It?​

An Exponential Moving Average (EMA) is a moving average that gives more weight to recent price data. Unlike a simple moving average (SMA), which treats every bar equally, the EMA reacts faster to new price action. The weight applied to each new candle is determined by the period:

Multiplier = 2 / (period + 1)
EMA = (Price × Multiplier) + (Previous EMA × (1 - Multiplier))

A 12-period EMA reacts quickly to price changes. A 26-period EMA moves more slowly. When the fast EMA crosses above the slow EMA, momentum is shifting upward. When it crosses below, momentum is shifting downward. This crossing event is the signal.

The EMA crossover is one of the most studied signals in technical analysis, not because it's magical, but because it captures a real phenomenon: trends tend to persist for longer than random chance would predict. When a market breaks out, it often keeps running.

How EMA Crossover Differs from RSI Mean Reversion​

Before building a crossover strategy, it's worth understanding when each approach is most effective:

Both strategies can be profitable in the right conditions. The key insight is that they perform best at different times. That makes them strong candidates for running simultaneously as separate bots.

If you're new to the mean reversion side of this equation, the RSI mean reversion post walks through building that strategy step by step.

The Classic EMA Crossover Setup​

The most commonly tested EMA crossover uses a 12-period fast EMA and a 26-period slow EMA. These same periods underpin the MACD indicator, which is essentially a normalized view of the difference between the two EMAs.

Entry rules:

• Long entry: 12 EMA crosses above 26 EMA
• Long exit: 12 EMA crosses below 26 EMA (or a separate stoploss triggers)

For a short-only or long/short strategy, the reverse signals apply.

A common variation adds a 200-period EMA as a trend filter: only take long signals when price is above the 200 EMA, and only take short signals when price is below it. This filter reduces total trades but improves the win rate on the trades taken.

Building This Strategy in VolatiCloud​

VolatiCloud's Strategy Builder has dedicated crossover nodes that make this setup straightforward without any code. Here's how to wire it up:

Step 1 — Open the Strategy Builder

In the VolatiCloud console, create a new strategy and select the UI Builder mode. The canvas opens with an empty condition tree.

Step 2 — Add the long entry condition

Drag a CROSSOVER node onto the canvas. Configure it with:

• indicator_a: EMA, period 12, source: close
• indicator_b: EMA, period 26, source: close
• Direction: upward (fast crosses above slow)

Step 3 — Add the 200 EMA trend filter (optional but recommended)

Add a COMPARE node:

• Left operand: EMA, period 200, source: close
• Operator: lt (less than)
• Right operand: PRICE (close)

This reads as "close price is above the 200 EMA."

Connect the CROSSOVER node and the COMPARE node with an AND node. The strategy only enters a long trade when both conditions are true simultaneously.

Step 4 — Set stoploss and ROI

Under the bot configuration, set a stoploss percentage (e.g., −3%) and a minimum ROI target (e.g., +5% at 24h). Trend-following strategies typically use wider stoplosses than mean reversion strategies because the trade needs room to develop.

Step 5 — Choose a timeframe

1h or 4h candles are a good starting point for EMA crossover. The signal appears less frequently but each signal carries more weight.

Why Win Rate Isn't Everything​

New traders often abandon trend-following strategies after seeing backtests with a 38% win rate. This is a mistake. A strategy that wins 35% of its trades but makes 4× its risk on winners still has a positive expectancy:

Expected value per trade = (0.35 × 4R) − (0.65 × 1R)
                         = 1.4R − 0.65R
                         = +0.75R per trade

Where R is the amount risked per trade. A strategy with this profile makes money over time. It just requires the discipline not to abandon it during the losing streaks — and automated bots have an advantage here, since they don't get discouraged.

This is one reason automated strategies have an advantage here. A bot doesn't get discouraged after five losing trades. It executes the next signal exactly as it would have after five winners.

Backtesting EMA Crossover Strategies​

EMA crossover strategies deserve careful backtesting because they are prone to two specific failure modes:

1. Overfitting to bull market conditions

If your backtest window only covers a bull run, the strategy looks spectacular. Run the same strategy over a ranging or bear market period and performance often collapses. Always test across at least two full market cycles.

2. Whipsawing in low-volatility ranges

When the market chops sideways, a crossover system generates multiple false signals in quick succession. The fast EMA crosses above, then below, then above again, each time triggering a trade that loses to fees and stoploss. The 200 EMA filter described above reduces this, but it doesn't eliminate it entirely.

VolatiCloud's backtest runner lets you specify exact date ranges, so you can deliberately test your strategy through difficult periods. Run separate backtests for:

• A sustained trending period
• A prolonged ranging/consolidating period
• A sharp drawdown or black swan event

If the strategy survives all three with acceptable drawdown, you have more confidence in its robustness. See running backtests for step-by-step instructions.

Using Hyperparameter Optimization to Find the Best Periods​

The 12/26 combination is a common starting point, not a magic number. Different pairs and timeframes respond to different EMA periods. VolatiCloud's Hyperparameter Optimization can search the parameter space systematically to find the combination that performs best on your target pair, without you manually running dozens of individual backtests.

A reasonable parameter space for EMA crossover optimization:

{
  "fast_period": {
    "type": "int",
    "low": 8,
    "high": 21,
    "step": 1
  },
  "slow_period": {
    "type": "int",
    "low": 20,
    "high": 50,
    "step": 2
  }
}

The hyperparameter optimization guide covers how to configure parameter spaces and interpret the results.

Running EMA Crossover Alongside a Mean Reversion Bot​

One practical approach is to run both strategy types simultaneously on the same trading pair:

• EMA crossover bot at 4h timeframe — captures large directional moves
• RSI mean reversion bot at 1h timeframe — collects smaller, frequent profits in ranging conditions

During a trending period, the EMA bot captures the bulk of the move while the RSI bot may struggle with false reversals. During a ranging period, the RSI bot earns steady returns while the EMA bot sits idle or takes small losses on failed breakouts.

Neither strategy needs to be exceptional in isolation for the combination to produce a smoother equity curve. Reducing correlation between your bots' signals is one of the more reliable ways to improve portfolio-level performance.

VolatiCloud supports running multiple bots with different strategies, timeframes, and exchange connections independently. Each bot has its own configuration, stoploss, and ROI target. You can monitor all of them from a single dashboard and get notified when any of them opens or closes a trade.

What to Expect During Live Trading​

A few practical observations for anyone moving an EMA crossover strategy from backtest to live:

Fewer signals than you expect. A 4h EMA crossover might generate only 5-10 trades per month on a single pair. This is normal. Forcing more signals usually means reducing the timeframe, which increases noise.

Flat periods are uncomfortable but expected. Between trends, the strategy does nothing, or takes small losses on false starts. Periods of weeks with no significant profit are part of the strategy's nature, not a sign that something is broken.

Slippage matters less than in higher-frequency strategies. Because entries and exits are triggered on candle closes rather than intraday ticks, the actual execution price is usually close to the signal price.

Before deploying real capital, running the strategy in paper trading mode for several weeks lets you observe how it behaves in current market conditions without any financial risk.

Get Started​

EMA crossover strategies are a strong foundation for any algorithmic trading portfolio. They require patience, but when trends develop, they capture moves that most discretionary traders miss by getting out too early.

To build your own EMA crossover strategy:

1. Open the VolatiCloud console and create a new strategy
2. Use the Strategy Builder to configure your crossover conditions
3. Run a backtest across multiple market conditions using backtesting
4. Use hyperparameter optimization to tune your EMA periods before going live

The visual strategy builder post covers the full builder interface if you're setting up your first strategy.

Almost certainly, you overfitted your strategy.

Overfitting is the most common and most expensive mistake in algorithmic trading. A strategy that is overfitted to historical data learns the specific quirks and noise of that period rather than durable market patterns. It looks perfect on paper, then falls apart the moment it encounters data it has never seen.

This guide explains how overfitting happens, how to detect it before you go live, and how to design backtests that give you an honest picture of future performance.

What Overfitting Actually Means​

A trading strategy has parameters: indicator periods, entry thresholds, stop-loss percentages, take-profit targets. When you backtest, you are searching for values that produce good results on historical data.

The problem is that historical data contains two things: real signal (persistent market behavior you can profit from) and noise (random fluctuations specific to that period). An overfitted strategy has learned to exploit the noise. It knows, in effect, that on March 14, 2023, the price dipped exactly 2.3% before recovering — not because that is a reliable pattern, but because it happened and the optimizer found it.

The more parameters you optimize, and the more parameter combinations you test, the higher the risk of finding a configuration that fits noise rather than signal. This is not a flaw in any particular optimization tool. It is a mathematical inevitability when the number of free parameters grows relative to the amount of data.

A strategy with 20 tunable parameters tested against 2 years of daily bars has more degrees of freedom than the data can support. It will find a "good" configuration because it has enough knobs to fit almost anything.

Signs Your Strategy May Be Overfitted​

Before running a single live trade, check your backtest results for these warning signs:

Suspiciously smooth equity curves. Real strategies have rough patches. If your equity curve climbs steadily upward with tiny drawdowns across all market conditions (bull, bear, and sideways), that is unusual. Real market patterns have periods where they simply do not work.

Too many trades per period. A strategy that enters and exits dozens of times per day and still produces a high win rate on historical data has likely found intraday noise patterns that will not repeat.

Parameter sensitivity cliffs. Test your strategy with parameter values slightly above and below your optimized values. If changing the RSI period from 14 to 15, or the stop-loss from 2% to 2.1%, causes performance to collapse, your parameters are tuned to a specific pocket in the fitness landscape rather than a broad, robust zone.

Performance that degrades on recent data. Split your backtest period in half chronologically. If the first half performs significantly better than the second half, the strategy may have been inadvertently optimized on older market conditions that no longer hold.

Win rate above 70%. In most liquid crypto markets, genuine edge produces win rates in the 45–65% range when combined with good risk/reward ratios. A win rate of 80% or above is a red flag worth investigating.

The Out-of-Sample Test​

The single most important technique for detecting overfitting is out-of-sample testing: reserve a portion of your historical data during development and never use it for optimization.

A common split is 70/30: use 70% of your data for developing and refining the strategy, then test the final version on the remaining 30%, without any further adjustments. The out-of-sample period should be the most recent data, since it is closest to the market conditions you will actually trade in.

If your strategy performs well in-sample but poorly out-of-sample, it has overfitted. If performance is roughly consistent between both periods (degraded somewhat, but not dramatically), you have a more honest signal.

Critically, the out-of-sample data must remain untouched until you are done with all optimization. The moment you use it to inform any decision, even a small tweak, it becomes in-sample data and loses its value as an independent test.

Walk-Forward Optimization​

Out-of-sample testing gives you one data point. Walk-forward optimization gives you many.

The concept is straightforward:

1. Use a sliding window of historical data as your in-sample training period
2. Optimize parameters on that window
3. Test the optimized parameters on the immediately following out-of-sample period (the "forward" window)
4. Slide both windows forward in time and repeat
5. Stitch together all the out-of-sample results into a single performance record

The resulting out-of-sample equity curve reflects how your strategy's optimization process would have performed in real time, tested repeatedly across different market regimes. A strategy that consistently degrades in the forward window across all periods is almost certainly overfitted. A strategy that maintains reasonable performance, even if lower than the in-sample results, has demonstrated robustness across changing conditions.

Walk-forward testing is time-consuming to set up manually, but the signal it provides is far more trustworthy than a single in-sample backtest.

How Many Parameters Is Too Many?​

A rough heuristic: you need roughly 50–100 trades per free parameter to have meaningful statistical confidence. A strategy with 5 parameters needs 250–500 trades to draw reliable conclusions from optimization.

This is why short backtests are dangerous. If you optimize 5 parameters against 3 months of hourly data that generated 60 trades, you have far too few observations to distinguish signal from noise. The optimizer will still find a best configuration. It just will not mean anything.

Practical limits:

If your strategy requires 10+ parameters to define its behavior, that complexity may be a sign you are fitting to market microstructure rather than a durable edge.

Using Hyperopt Without Creating an Overfitted Strategy​

Hyperparameter optimization tools, including VolatiCloud's Hyperopt feature, are powerful. They can also accelerate overfitting if used carelessly.

When running hyperopt, a common mistake is to optimize every parameter simultaneously across a wide search space on all available data. You end up with a configuration that maximizes backtest performance specifically on that dataset. This is not wrong; it is what optimization does. But the result is only useful if you treat it as a starting point, not a final answer.

A more disciplined approach:

1. Constrain the search space. Use domain knowledge to limit parameter ranges. If RSI periods between 5 and 8 are known to produce noisy signals, exclude them — do not let the optimizer explore territory that does not make logical sense.

2. Reserve out-of-sample data. Run hyperopt only on 70% of your historical data. Test the winning configuration on the remaining 30% before making any trading decisions.

3. Optimize for robustness metrics, not just returns. VolatiCloud's hyperopt supports multiple loss functions. Metrics like the Sortino ratio or Calmar ratio penalize drawdowns heavily, which tends to produce more conservative and stable configurations than pure profit maximization.

4. Use fewer epochs than you think you need. More optimization passes increase the chance of finding a noise-fitting configuration. Stop before the optimization has exhaustively searched the parameter space.

Read more about the available loss functions and epoch settings in the hyperparameter optimization guide.

Stress-Testing With Monte Carlo Simulation​

Even a well-designed, out-of-sample-validated strategy will experience variance in live trading. The sequence of trades matters — a strategy that produces 100 trades over a year could encounter those trades in almost any order, and some orderings produce severe drawdowns even if the overall expectancy is positive.

VolatiCloud's Monte Carlo simulation addresses this directly. Rather than asking "what did this strategy return historically?", Monte Carlo asks: "across thousands of possible trade orderings, what is the realistic range of outcomes?"

This gives you two critical numbers before you risk real capital:

• Worst-case drawdown at a given confidence level. For example, "there is a 95% chance the maximum drawdown will be below 22%." If 22% is within your acceptable risk tolerance, you can proceed with appropriate position sizing.
• Probability of ruin. The fraction of simulated sequences that result in a catastrophic loss. If this number is above zero, your position sizing or risk parameters need adjustment.

Monte Carlo simulation does not fix an overfitted strategy. If the backtest trades are themselves noise-fitted, the simulations will extrapolate from flawed data. But applied to a robustly validated strategy, it provides a realistic picture of the variance you should expect and plan for.

Practical Rules for Backtest Integrity​

Summary of actionable steps:

Design phase:

• Choose indicators based on trading logic, not by testing many combinations and keeping what works
• Keep the parameter count small — aim for 3–5 free parameters maximum
• Define entry and exit rules completely before looking at backtest results

Optimization phase:

• Reserve at least 20–30% of your data as out-of-sample — touch it only once
• Constrain hyperopt search spaces to logically valid ranges
• Use Sharpe, Sortino, or Calmar as loss functions rather than raw profit

Validation phase:

• Test final parameters on the out-of-sample period — without further changes
• Check parameter sensitivity: how much does performance degrade if you shift key parameters by 10–20%?
• Run Monte Carlo simulation to understand realistic drawdown and variance
• If performance degrades dramatically out-of-sample, the strategy is overfitted — do not paper over this by adjusting parameters on the out-of-sample data

Paper trading phase:

• Before going live, run the strategy in paper mode for at least 2–4 weeks
• Compare paper results to the out-of-sample backtest period — are trade frequencies and win rates consistent?
• Do not adjust parameters during paper trading; you are observing, not optimizing

Putting It Together in VolatiCloud​

VolatiCloud's backtesting workflow is designed to support each of these stages. You can run multiple backtests on the same strategy with different date ranges — one for in-sample development and one as a held-out validation period — tracking each independently without losing prior results. See the backtesting overview for how backtest history is organized per strategy.

After validating in-sample performance, run Hyperopt with explicit start and end dates scoped to your training period only. Once you have a configuration you believe in, create a separate backtest on your out-of-sample date range and read the results in the backtest analyzer to compare performance metrics side by side.

Finally, run Monte Carlo simulation on the out-of-sample results to get a distribution of likely drawdowns. If the numbers hold up, you have done the work to give your strategy a fair chance in live markets.

The goal is not a perfect backtest. The goal is an honest one.

The backtesting section of the VolatiCloud docs walks through each step in detail. Start your free trial at console.volaticloud.com and build your first rigorously tested strategy.

What Mean Reversion Actually Assumes​

Mean reversion is the idea that prices tend to drift back toward a historical average after an extreme move. The assumption isn't that markets are efficient. It's almost the opposite: that short-term overreactions create predictable recovery opportunities.

RSI (Relative Strength Index) is a momentum oscillator developed by J. Welles Wilder Jr. in 1978. It measures the ratio of average gains to average losses over a lookback period, then normalizes that ratio to a 0–100 scale:

RSI = 100 - (100 / (1 + RS))
RS  = Average Gain / Average Loss (over N periods)

An RSI reading above 70 suggests recent gains significantly outpaced losses, a potential exhaustion signal. A reading below 30 suggests the opposite. The mean reversion hypothesis: when RSI drops to an extreme low, the selling pressure that caused it is likely temporary, and price should recover toward the mean.

The assumption holds in ranging markets and breaks down in trending markets. This is why entry conditions alone are never enough. You also need clear exit rules and a tested set of parameters.

The Problem with Standard RSI Rules​

The "buy below 30, sell above 70" rule is everywhere because it's easy to explain. The problem is that it tells you nothing about:

• How long to hold: RSI can stay below 30 for days in a real downtrend
• Where to cut losses: Mean reversion trades have a clear invalidation point
• Which timeframe to use: RSI(14) on the 1-hour chart and RSI(14) on the daily chart are completely different signals
• Which assets it works on: RSI mean reversion performs differently on BTC versus altcoins versus lower-liquidity pairs

These aren't theoretical concerns. If you run an unoptimized RSI strategy on BTC/USDT from early 2022 through mid-2022, you catch every "oversold" bounce during a sustained bear market and lose capital on each trade. The signal was never wrong about RSI being oversold. The market was genuinely oversold for months.

This is why parameter selection and backtesting matter before you fund a live bot.

Building the Strategy in VolatiCloud's Strategy Builder​

VolatiCloud's Visual Strategy Builder lets you construct entry and exit conditions using draggable nodes without Python. Here's how to translate RSI mean reversion logic into a working strategy.

Step 1: Create a New Strategy​

Navigate to console.volaticloud.com, open your organization, and create a new strategy. Give it a descriptive name like "RSI Mean Reversion — BTC/USDT 4H" that captures both the pair and timeframe you'll test first.

Step 2: Configure the Entry Condition​

In the Strategy Builder canvas, build a condition tree for your buy signal:

1. Add an RSI indicator node from the indicator palette
   • Set period to 14 (Wilder's original default — a reasonable starting point)
   • Set source to close
2. Add a COMPARE node
   • Left operand: the RSI node output
   • Operator: lt (less than)
   • Right operand: 30 (constant)
3. Connect the RSI node output to the COMPARE node

This encodes: enter when RSI(14) < 30.

For a more selective entry, wrap this in an AND node and add a second condition requiring that RSI was at or above 30 on the previous candle. This filters for a fresh cross below the threshold rather than catching a prolonged oversold condition:

AND
├── RSI(14) < 30          (current candle)
└── RSI(14, shift=1) >= 30   (previous candle — fresh cross)

This filters out cases where RSI has been sitting below 30 for multiple candles, which often signals a genuine trend rather than a recoverable dip.

Step 3: Configure the Exit Condition​

A mean reversion trade has two natural exits:

Profit target: Exit when RSI recovers to a neutral level (e.g., 55 or 60). This captures the snap-back move without overstaying.

Stop loss: This is where most beginners skip a step. Set a percentage-based stoploss in the bot configuration — something like 3–5% below entry. If price continues falling instead of recovering, you exit before the loss compounds.

The exit condition in the Strategy Builder handles the profit signal:

RSI(14) > 55    (profit signal: RSI recovered toward neutral)

The hard stoploss is configured separately at the bot level, not in the Strategy Builder's logic tree. Set it in your bot configuration as stoploss: -0.04 for a 4% hard stop.

Step 4: Set the Timeframe​

The timeframe has a bigger impact than most traders realize. RSI(14) on the 15-minute chart generates dozens of signals per week, many of them noise. RSI(14) on the 4-hour chart generates 2–5 signals per week and gives each trade room to develop.

Start with the 4-hour timeframe for mean reversion testing. It reduces noise while still capturing short-to-medium-term corrections. You can run parallel backtests across timeframes once you have a baseline to compare against.

Backtesting Your RSI Strategy​

Once your conditions are set, run a backtest. VolatiCloud's backtesting engine uses real historical OHLCV data to simulate how your strategy would have traded. See Backtesting: Validate Your Strategy Before Going Live for a full walkthrough of the backtest flow.

Choose a Representative Date Range​

Avoid testing only during favorable market conditions. For BTC/USDT, use at least 18 months that include both trending and ranging periods. A strategy that only works during sideways consolidation is not production-ready.

Metrics That Matter for Mean Reversion​

After the backtest completes, focus on these results in the analyzing results guide:

Tune the Parameters​

If initial results underperform, adjust parameters systematically rather than abandoning the strategy. VolatiCloud's Hyperparameter Optimization can search the parameter space automatically across configurable epochs:

• RSI period: Try 7, 10, 14, 20 — shorter periods are more reactive, longer periods smoother
• Entry threshold: Try 25, 30, 35 — lower thresholds give fewer but stronger signals
• Exit threshold: Try 50, 55, 60 — higher exits increase profit per trade but reduce win rate
• Stoploss percentage: Try 2%, 4%, 6% — tighter stops reduce individual losses but increase stop-out frequency

Run hyperopt with 50–100 epochs to find a promising configuration, then run a second backtest on a separate date range (out-of-sample) to verify the results aren't overfit to the training period.

Common Mistakes and How to Avoid Them​

Testing Only in Favorable Conditions​

If you backtest a mean reversion strategy exclusively during a sideways market, you'll get great numbers that don't hold in production. Always include at least one significant trend period, ideally both an uptrend and a downtrend, in your test range.

No Stoploss​

"Mean reversion will eventually work" is true in theory and catastrophic in practice. A currency can trend against you for months. Define when you're wrong and exit accordingly. The stoploss isn't an admission of defeat. It's what keeps a bad trade from becoming a portfolio-destroying trade.

Over-optimizing the RSI Threshold​

If you arrive at RSI < 23.7 because it performed best across 500 backtest runs, that specificity is almost certainly noise. Use round numbers and test across wider ranges. Parameter combinations that hold up across multiple nearby settings are more robust than the single peak-performing configuration.

Ignoring Trade Frequency​

A strategy with 80% win rate across 8 trades is not statistically meaningful. You need a minimum of 30–50 completed trades before the percentages carry real weight. If your backtest produces fewer trades than that, adjust the timeframe or relax the entry threshold.

Validating with Monte Carlo Simulation​

Even a well-backtested RSI strategy can underperform due to trade-sequence randomness. VolatiCloud's Monte Carlo simulation stress-tests your strategy by shuffling historical trades thousands of times and computing the distribution of possible outcomes.

For a mean reversion strategy, focus on:

• 95th percentile max drawdown: The worst-case scenario your strategy could realistically face, even if that exact sequence hasn't occurred historically
• Probability of positive return: If the simulation shows 25–30% of shuffled scenarios end negative, you have a high-variance strategy that requires appropriate position sizing before deployment

If Monte Carlo results show resilience across shuffled sequences, you have genuine confidence the signal is real rather than an artifact of historical data ordering. If results are fragile, either tighten the strategy or reduce position size to match actual risk.

Deploying a Live Bot​

Once you're satisfied with backtest and simulation results, deploying is straightforward:

1. Create a bot and attach your RSI mean reversion strategy
2. Choose a bot runner — start in paper trading mode to observe live signal generation without real capital
3. Connect an exchange account using VolatiCloud's exchange wizard, which guides you through API key setup with only the permissions your bot actually needs
4. Set max_open_trades: 1 for your first live run — don't run multiple concurrent RSI bots until you've confirmed the strategy behaves consistently with your backtest

Paper trade for at least 2–4 weeks. Compare the live signals to what your backtest predicted. If signal frequency, trade duration, and win rate look similar, you have a consistent strategy ready for live capital.

RSI Mean Reversion Checklist​

Before going live, verify:

• Backtested across both trending and ranging market conditions
• At least 30 completed trades in the backtest for statistical validity
• Stoploss is set and proportional to your entry threshold
• Out-of-sample validation on a date range not used during optimization
• Monte Carlo simulation shows resilience across shuffled trade sequences
• Paper traded for at least 2 weeks with consistent signal behavior
• Position sizing accounts for actual risk tolerance (see position sizing guide)

Start Building​

The RSI mean reversion strategy is one of the most well-studied approaches in algorithmic trading because the logic is sound, the signals are measurable, and the failure modes are predictable. The edge isn't in the indicator itself. It's in the discipline of testing it properly and deploying only when the data supports it.

VolatiCloud's Strategy Builder lets you express this logic visually and iterate quickly. Backtesting runs against real historical OHLCV data, and Monte Carlo simulation adds a layer of robustness validation that most traders skip entirely. When you're ready to go live, paper trading gives you a final check against real market conditions before any capital is at risk.

Start building your RSI strategy on VolatiCloud. The first backtest takes a few minutes to configure, and you'll have data-driven answers instead of guesses.

Why Real-Time Visibility Matters for Bot Trading​

Most trading dashboards refresh on a timer — every 30 seconds, every minute, maybe every five. For a bot running a 4-hour timeframe strategy, that lag is acceptable. For a strategy that fires multiple trades in a short window, or one you're actively validating before committing real capital, polling latency means you're always looking at stale data.

The difference matters more than it might seem:

• Debugging: If a trade fires at an unexpected price, you want to know immediately, not after the next poll cycle.
• Confidence: Watching a live trade open and close confirms your strategy is executing exactly as backtested.
• Incident response: If a bot enters an error state, real-time status updates let you react before the situation compounds.

VolatiCloud uses WebSocket subscriptions throughout the monitoring interface rather than periodic API polling. The connection stays open, and updates push to your browser as they happen.

What the Bot Monitoring Panel Shows​

Opening a bot's detail page in the VolatiCloud console presents a live monitoring panel with several concurrent data streams.

Trade Events Feed​

Every trade lifecycle event streams in real time:

The feed is ordered chronologically, so you can watch a trade move from entry through fills to close without refreshing the page. Each event includes a timestamp and raw message from the trading engine, which is useful when you need to confirm exactly when a position opened relative to a candle close.

Live Equity Curve​

The equity curve panel plots your bot's running profit over time. Each closed trade appends a new data point — a profitable close ticks the curve upward, a loss dips it. This is the same curve you see in backtesting results, drawn live from real execution.

Watching a live equity curve is one of the best early-warning signals for strategy drift. If your live curve starts diverging significantly from what backtesting predicted, something has changed — market regime, exchange latency, parameter sensitivity. The earlier you notice the divergence, the earlier you can investigate.

Bot Status and Health​

The status panel shows current bot state: running, stopped, error, or dry_run. State changes push immediately. If a bot transitions to error — due to an exchange API connectivity issue or an unexpected order response — the panel updates within seconds rather than on the next polling interval.

For bots running on self-hosted runners, you also see last-heartbeat timestamps and connection state. This tells you whether your runner is actively communicating with the VolatiCloud backend, which matters when diagnosing whether a "silent" bot is healthy or disconnected.

See Bot Monitoring in the documentation for the full list of status indicators and what each one means.

Paper Trading vs Live: Same Monitoring, Both Modes​

VolatiCloud supports dry run (paper trading with simulated orders) and live trading with real capital. The monitoring interface is identical for both — same trade feed, same equity curve, same status indicators.

This matters because it means your paper trading period is a genuine rehearsal for live operation. You're not switching to a different UI when you go live; you're reading the same data in the same format. The transition from testing to production is familiar, which reduces the chance of misreading what you're looking at when real money is involved.

During a paper trading period, the monitoring panel is where you validate that live execution matches your backtest expectations. Specifically, check:

• Average trade duration: Should fall within the range your backtest showed for the same timeframe.
• Trade frequency: If your strategy fires significantly more or fewer trades than expected, review your timeframe and entry condition configuration.
• Profit factor: Absolute PnL numbers will be small in dry-run with minimal stake, but the ratio of gains to losses should approximate your backtest results.

See the backtesting deep dive for the baseline metrics to use as comparison targets.

Monitoring Inside the Strategy Studio​

The VolatiCloud Strategy Studio integrates monitoring directly into the strategy workflow. When you open a strategy that has active bots attached, the detail page shows a live summary: how many bots are currently running, their aggregate PnL, and recent trade activity.

You don't need to navigate to a separate screen. Build a strategy, attach a bot, and watch live execution from the same interface where you defined the strategy logic. The strategy detail page shows which version of your strategy each bot is running, so if you've versioned a strategy after a parameter change, you can compare live performance across versions side by side.

This view is particularly useful when testing a strategy fork — a copy of an existing strategy with modified parameters — against the original. Both bots appear under their respective strategy versions, and both equity curves update in real time. See Never Overwrite a Working Strategy for how strategy versioning and forking work.

Monitoring While You're Not at the Console​

Real-time monitoring is useful when you're watching the console. But bots run continuously, and you won't always be there. That's where the alert system fills the gap.

VolatiCloud's alerts connect directly to the trade event stream. You can configure notifications for:

• A bot transitioning to error state
• A single trade loss exceeding a specified percentage of stake
• A trade opening outside expected hours
• Unusual trade frequency (more or fewer trades per hour than your strategy typically produces)

Alerts deliver via email or webhook, so your monitoring extends beyond the browser tab. The combination of real-time monitoring when you're watching and alerts when you're not gives you the responsiveness of manual oversight without requiring you to watch charts all day. The intelligent alerts guide covers alert configuration in detail.

Diagnosing Common Monitoring Signals​

Real-time visibility is only useful if you know what patterns to watch for. A few situations that warrant investigation:

Equity curve flattening: Your bot is running but not trading. Common causes include entry conditions that aren't triggering (market conditions don't match the strategy's logic), stake amount exceeding available balance, or the bot sitting in cooldown after a losing trade.

Repeated cancelled_order events: The bot is attempting to open positions but orders aren't filling. This often indicates order book conditions — price moved before the order could fill, or the order type isn't available for that pair on that exchange. Check your exchange connection configuration and the pair's liquidity during the affected time window.

Status cycling between running and error: Intermittent connectivity to the exchange API. Bots retry on transient errors, but repeated cycling suggests a persistent issue. Check your exchange API key permissions, rate limit status, and whether the exchange had reported downtime during that window.

Trade duration much longer than backtested: The strategy's exit conditions aren't triggering when they should. Compare live market conditions against the indicators your strategy relies on. The strategy detail page shows which version is running, so you can cross-reference with the exact parameters used in your backtest.

Monitoring a Multi-Bot Portfolio​

VolatiCloud supports running multiple bots simultaneously — on different pairs, different exchanges, or different strategy versions. The main bots list view shows all running bots with their current status and recent PnL, all updated in real time.

If you're running a portfolio of bots (a trend-following strategy on BTC/USDT, a mean-reversion approach on ETH/USDT, and several altcoin positions), the summary view gives you a single place to confirm everything is running without opening each bot's detail page.

Bots can also be organized under a Bot Runner — VolatiCloud's infrastructure layer that handles deployment and orchestration. Runner health (connectivity, resource state) is visible alongside bot-level monitoring, so when investigating an issue you can quickly determine whether it's a strategy problem or an infrastructure problem. See Bot Runners: cloud vs self-hosted for the full comparison, and Bot Runners overview for setup details.

Getting Started with Live Monitoring​

Real-time monitoring is available on all VolatiCloud plans, including the free trial. To activate it:

1. Create a strategy using the visual Strategy Builder or the code editor
2. Connect an exchange — or skip this step and use dry-run mode to start without live credentials
3. Create a bot linking your strategy, exchange, and runner
4. Start the bot — the monitoring panel activates immediately and begins streaming events

The WebSocket connection opens automatically when you navigate to a bot's detail page. There's no separate configuration for monitoring; it's on by default.

If you're starting with dry-run mode (which is recommended before trading with real capital), the monitoring experience is identical to live trading. Use the paper trading period to build familiarity with reading the event feed and equity curve, so that when you switch to live mode you're interpreting familiar signals rather than learning a new interface under pressure.

Start with a free trial at console.volaticloud.com. Dry-run mode requires no exchange connection. Create a bot, start it in paper trading mode, and the monitoring panel activates automatically.

Haven't connected MCP yet? Start with the MCP server setup guide — it covers installation, configuration for Claude Code / Claude Desktop / Cursor, and how the tool architecture works. Come back here once you're connected.

The VolatiCloud MCP server gives Claude access to every operation the dashboard exposes — queries, mutations, backtest runs, bot lifecycle commands. The assistant can fetch the data itself, reason over it, and take action, all within a single conversation. These are multi-step operations that previously required navigating multiple dashboard screens. With MCP, Claude can do them in sequence, show you the results, and wait for your confirmation before taking destructive actions.

Practical Workflows​

Backtesting from a Conversation​

With the MCP server active in Claude Code, you can run a full backtesting workflow without leaving your editor:

Me: What strategies do I have?
Claude: [calls listStrategies] You have 4 strategies: ...

Me: Run a backtest on "MACD Crossover v3" for BTC/USDT over the last 90 days
Claude: [calls createBacktest, then polls status] Backtest complete. 
        Win rate: 58%, profit factor: 1.41, max drawdown: 12.3%

Me: That drawdown looks high. What does Monte Carlo say?
Claude: [calls createSimulation] Worst-case drawdown at 95th percentile: 18.7%

Each step is a real API call against your account. The results are not generated — they are your actual backtest data.

Multi-Bot Status Reports​

Me: Give me a summary of all running bots and their unrealized P&L
Claude: [calls listBots with status filter] 
        3 bots running, 1 in dry-run mode:
        - ETH/USDT Trend Bot: +2.4% unrealized
        - BTC Grid: -0.8% unrealized  
        - SOL Momentum: +5.1% unrealized
        - XRP Test (dry-run): +1.2% simulated

This kind of report previously required opening each bot's detail page. The MCP server fetches it all in one query.

Strategy Iteration Loop​

The combination of the MCP server and strategy versioning makes iterating on strategies faster. Fork a strategy through the AI assistant, adjust indicator parameters, run a backtest, compare results, and promote the best version — all within a single conversation thread.

Pre-Weekend Portfolio Audit​

Say you want to review all your active bots before stepping away for the weekend. Without MCP, that means navigating to each bot manually. With Claude:

You: Summarize the 7-day performance of all my active bots. Flag anything 
     with a drawdown above 3% or that hasn't traded in 48 hours.

Claude: [calls listBots, then getBotPerformance for each]

Here's the summary:
- BTC Momentum (live, Binance): +3.2% / 7d, 14 trades, max drawdown 1.1% ✓
- ETH Mean Reversion (live, Kraken): -0.4% / 7d, 8 trades, max drawdown 4.2% ⚠ drawdown
- SOL Breakout (paper, Binance): +6.7% / 7d, 22 trades, max drawdown 2.3% ✓
- ADA Grid (live, Bybit): 0 trades in 72h ⚠ stalled

ETH Mean Reversion and ADA Grid need attention. Want me to pull their recent 
trade logs?

From there you can dig into the problem, run a comparison backtest, or stop the underperforming bot — all from the same conversation.

Incident Response​

When an alert fires, context-switching to the dashboard costs time. With MCP, you can stay in Claude and investigate:

You: My "ETH Scalper" alert just fired. What's happening?

Claude: [calls getBotTrades, getBotOpenPositions, getBotTradingConfig]

ETH Scalper has 1 open position: long ETH/USDT entered at $3,241 
(now at $3,189, -1.6% unrealized). The last 5 trades show increasing 
slippage — avg 0.18% vs expected 0.05%. The bot has been running 
continuously for 14 days without a restart.

Would you like me to stop the bot, or just monitor and alert you if 
the loss exceeds 2%?

The assistant chains the calls automatically, presents the relevant data, and defers the destructive action to you.

Example Prompts to Get You Started​

These are prompts you can paste directly into Claude once the MCP server is connected. Each one triggers one or more real API calls against your account.

Discovery:

• "What strategies do I have, and which ones have been backtested in the last 30 days?"
• "List all my exchanges and show which ones have active bots."

Backtesting:

• "Fork my RSI strategy, bump the RSI period from 14 to 21, and run a backtest on BTC/USDT over the last 6 months."
• "Compare the last two backtest runs on my MACD Crossover strategy. Which had better risk-adjusted returns?"

Bot management:

• "List all bots that have been stopped for more than 24 hours. For each one, show the profit factor from their last backtest."
• "Stop every bot on the Bybit exchange and confirm they've closed all open positions before you do."

Monitoring:

• "Show me the last 10 trades on my BTC Momentum bot. Is the average slippage within the expected 0.1% range?"
• "Which of my live bots has the highest unrealized P&L right now?"

Strategy creation:

• "Create a new strategy called 'EMA Crossover v1' using a 20/50 EMA crossover signal on the 1h timeframe. Deploy it as a dry-run bot on Binance with 100 USDT stake."

What Stays the Same​

The MCP server is an additional interface to VolatiCloud — it does not change how your bots run or how strategies are stored. All data lives in your account under normal authorization rules. The AI assistant can only do what your API client's scopes permit.

Bots deployed through the MCP server are identical to those created via the dashboard. They use the same bot runners, the same exchange connections, and produce the same monitoring data you can watch in real time on the dashboard.

Pros and Cons of LLM-Driven Trading Automation​

Using an AI assistant to manage trading bots is genuinely useful — and has real limits worth understanding.

Where it excels:

• Multi-step workflows that span multiple resources (list → analyze → act)
• Generating natural-language summaries of complex performance data
• Rapid iteration loops: fork strategy, tweak params, backtest, compare, repeat
• Incident triage when you need to understand a situation before acting

Where to be cautious:

• The assistant cannot make real-time decisions autonomously — each action requires your prompt
• Claude will not execute destructive mutations (stop bot, delete strategy) without explicit confirmation, but you should still review what it's about to do
• The MCP server operates within your API client's permission scopes — narrowly-scoped clients are safer for exploratory sessions
• Exchange API keys and credentials are never visible through MCP (protected by field-level encryption)

The MCP server is a control interface, not an autonomous trading agent. You remain in charge; Claude does the leg-work of fetching, formatting, and sequencing API calls.

Getting Connected​

If you haven't set up the MCP server yet, the MCP server setup guide walks through every step: creating an API client, configuring Claude Code / Claude Desktop / Cursor, and verifying the connection. It also covers the tool architecture in detail — useful reading if you want to understand what the assistant can and can't do.

Once you're connected, the prompts above are a good starting point. For the full list of available GraphQL operations, use search_schema in your assistant or browse the API documentation.

This post covers what MCP is, how the VolatiCloud server works under the hood, and exactly how to install and configure it in your editor. Once you're set up, see our companion post for practical AI trading workflows and example prompts.

What is the Model Context Protocol?​

The Model Context Protocol (MCP) is an open standard that lets AI assistants interact with external systems through a structured tool interface. Instead of describing your API to an AI and hoping it generates the right HTTP call, MCP gives the assistant a live connection to the system — it can discover available operations, execute them, and act on the results within a single conversation.

For developers who already use AI-assisted workflows, this changes how you can manage your automated trading infrastructure. Rather than switching between your editor, the VolatiCloud dashboard, and the API docs, you can stay in one place and let the assistant do the heavy lifting.

How the VolatiCloud MCP Server Works​

The @volaticloud/mcp-server package connects to your VolatiCloud account and generates tools automatically from the live GraphQL schema. At startup, it introspects the schema and creates an MCP tool for every available query and mutation — so as the platform evolves, the tools stay current without requiring package updates.

Core tools (always available)​

Operation tools (resolved on demand)​

Beyond the four core tools, the server exposes every named query and mutation in the schema as an individually-typed tool. The assistant calls search_schema first to discover relevant operations, then invokes the specific tool — for example listBots, createBacktest, or stopBot — with Zod-validated arguments. This lazy resolution keeps the initial tool list small while making the full API surface reachable.

Examples of what's available:

Authentication uses OAuth2 client_credentials with automatic token caching and refresh, so you authenticate once and the session stays alive throughout your conversation.

Install and Configure in Three Steps​

Step 1: Create an API Client​

Open the VolatiCloud dashboard and go to Organization Settings → API Clients. Create a new client and copy the client_id and client_secret. This is the same credential system used for programmatic access via the REST and GraphQL APIs.

Step 2: Add the MCP Server to Your Editor​

The MCP server runs via npx — no global install required:

npx -y @volaticloud/mcp-server

Add it to your editor's MCP configuration. VolatiCloud's dashboard provides ready-to-paste config snippets under Organization Settings → MCP for the three most common setups:

Claude Code (~/.claude/mcp_settings.json):

{
  "mcpServers": {
    "volaticloud": {
      "command": "npx",
      "args": ["-y", "@volaticloud/mcp-server"],
      "env": {
        "VOLATICLOUD_CLIENT_ID": "your-client-id",
        "VOLATICLOUD_CLIENT_SECRET": "your-client-secret"
      }
    }
  }
}

Claude Desktop uses the same format in its own config file. Cursor uses a similar JSON structure under its MCP settings panel. The dashboard tab shows the exact config for each — copy, paste, done.

Step 3: Verify the Connection​

Restart your editor. The VolatiCloud tools appear in the AI assistant's context automatically. Run a quick sanity check:

"List all my running bots and their current profit."

If the assistant returns live data, you're connected. The assistant calls the appropriate MCP tool, gets the live data, and responds in plain language — chaining multiple operations if the task requires it.

Schema Awareness and Type Safety​

The MCP server uses Zod schemas generated from the GraphQL schema at startup. This gives the AI assistant proper type information for every tool argument — required fields, enum values, nested object shapes. It's not guessing at argument formats from documentation; it has the actual schema.

The server also handles cycle detection for self-referential types (common in filter inputs like BotWhereInput, which can nest and/or predicates). Without this, schema introspection on complex GraphQL APIs tends to produce infinite loops or truncated type definitions. The VolatiCloud MCP server handles this automatically.

Security Considerations​

The MCP server authenticates as your API client — meaning it operates within the same permission boundaries you configured when creating the client. If you created a read-only client, the server can query but cannot mutate. For production use, create a dedicated API client with only the scopes your workflow actually needs.

API client credentials are passed via environment variables, not stored in code, which keeps them out of version control. The dashboard's copy-paste config snippets use the env field in the MCP config for exactly this reason.

For team environments, each team member should use their own API client credentials so that actions are attributed correctly in audit logs.

Get Started​

The MCP integration tab is available in Organization Settings under the MCP section. If you haven't created an API client yet, see the API reference documentation for an overview of authentication and available operations.

The MCP server works with any editor or agent runtime that supports the Model Context Protocol — the VolatiCloud dashboard provides configuration snippets for Claude Code, Claude Desktop, and Cursor, but the underlying npx -y @volaticloud/mcp-server command works anywhere the protocol is supported.

If you're already using API clients for programmatic access, MCP is the fastest way to make that access conversational.

Now that you're connected, the interesting part begins. See the companion post — AI Trading Workflows: What to Do Once Your MCP Server Is Running — for concrete recipes: backtesting from a conversation, multi-bot status reports, strategy iteration loops, and example prompts you can paste directly into Claude.

Why Version Control Matters for Trading Strategies​

Software developers take version control for granted — git means you never truly lose work. Traders using spreadsheets or plain Python files don't have the same safety net. A single overwrite can erase days of tuning, and there's no way to compare what changed between "the version that made money" and "the version that didn't."

For algorithmic trading specifically, versioning solves three concrete problems:

Backtest integrity. When you look at a backtest result six months from now, you need to know exactly which strategy configuration produced it. Without immutable versions, a saved result and the current code can silently diverge.

Bot stability. If you're running a live bot on Version 3 of your strategy and you edit the strategy to create Version 4, your bot should not change behavior mid-trade. It shouldn't even know Version 4 exists.

Safe experimentation. Fear of breaking something working often stops traders from experimenting at all. When you know every save is non-destructive, you can try things freely.

How Immutable Versioning Works in VolatiCloud​

Every time you click Save in the Strategy Studio, VolatiCloud:

1. Freezes the current code and configuration as an immutable new version
2. Increments the version number automatically (Version 1, 2, 3, ...)
3. Makes the new version the "latest" — shown in strategy lists and used when creating new bots
4. Leaves all existing bots running their configured version, untouched

The flow looks like this:

Version 1: RSI < 30 entry, RSI > 70 exit
    ↓ (save)
Version 2: Added EMA(200) trend filter
    ↓ (save)
Version 3 [LATEST]: Tuned RSI thresholds to 25/75

Versions 1 and 2 are locked. If you deploy a bot on Version 2, it will run Version 2 forever — even after you save Version 3, Version 4, or Version 10. To switch a bot to a newer version, you create a new bot (or explicitly update the bot's configuration). This is a deliberate design choice: a live bot's behavior should never change without a conscious decision.

What Version History Shows You​

From the strategy detail page, the Version History panel lists every version in reverse order (latest first). Clicking a version shows its full configuration — whether that's UI Builder logic nodes or raw Python code.

More useful is the aggregated backtest statistics per version. For each version that has backtests, you can see:

This lets you answer "which version performs best?" at a glance, without re-running backtests or hunting through notes. Version 2 might have a higher average profit but worse drawdown than Version 3 — that's exactly the kind of tradeoff this view surfaces.

Backtests Are Version-Specific​

A backtest is always tied to a specific strategy version — not just the strategy. If you run a backtest on Version 2, then save Version 3, the backtest still belongs to Version 2. The Version 3 entry in the version history starts with zero backtests until you run one.

This is intentional. The point is that you can look at any backtest result and know exactly what code produced it. If backtests floated freely between versions, that guarantee would break.

Practically, this means building a habit: save → backtest → compare → save again. See Running Backtests for the full workflow. Each cycle produces a clean paper trail of what you tried and what it produced.

When to Fork Instead of Iterate​

Versioning handles incremental iteration — you're refining the same strategy. But sometimes you want to rewrite the entry logic from scratch, or create a variant that will evolve independently. That's what forking is for.

A fork creates a completely new strategy with its own separate version chain. The fork starts as an exact copy of your current latest version, but from that point on, changes to the fork don't affect the original, and changes to the original don't affect the fork.

The key question is: are these two things the same strategy or different strategies? If you'd want to compare their backtest results in isolation and run separate bots on each, fork. If one is just a refined version of the other, save a new version.

Practical Workflow: Iterating on a Strategy​

Here's what a disciplined iteration cycle looks like:

1. Start from a working baseline. Before making any changes, confirm your current version has at least one backtest you trust. This is your control — the number to beat.

2. Make one change at a time. If you adjust the RSI period and the stoploss percentage simultaneously, and performance improves, you won't know which change drove it. Change one thing, save, backtest.

3. Use version history to compare. After a few versions, the version history panel gives you a comparative view. Version 4 might have better average profit but Version 3 might have lower drawdown. The right choice depends on your risk tolerance.

4. Fork for radical experiments. When you want to try something that might completely break the strategy — new indicator combination, different timeframe, entirely different exit logic — fork first. Your working version stays intact while you experiment freely on the fork.

5. Run hyperopt on your best version. Once you've identified a version with strong structural logic, use Hyperparameter Optimization to find optimal parameter values. Hyperopt runs backtests across a parameter search space — each run produces a new backtest result you can compare in the version history.

The Fork Lineage​

Every forked strategy maintains a reference to its source. On the strategy detail page, you can see:

• Which strategy it was forked from
• Which version it was forked from
• When the fork was created

This creates a traceable lineage. Six months from now, if you're looking at a strategy and wondering where the initial logic came from, the fork source tells you. This is particularly useful in team settings where multiple people are creating variants of shared strategies.

Strategy Versioning in Team Environments​

When multiple people work in the same organization, versioning and forking interact with team workflows in important ways.

If a teammate forks your strategy and makes improvements, they can share the fork back with the team (by setting it to public) without modifying the original. The original continues running in production while the fork goes through testing. See the team management post for more on how VolatiCloud handles shared resources and role-based access.

Version history is also useful for accountability: you can see when each version was saved, what the configuration looks like, and which backtests were run against it. This creates a natural audit trail for teams that need to document why trading decisions were made.

Starting a New Strategy​

For new users, the versioning system might feel like overhead. It isn't — you don't need to think about it at all for the first version. Build your strategy in the Visual Strategy Builder, save it, run a backtest. That's Version 1.

As your strategy evolves and you start to iterate, you'll naturally accumulate versions. The version history panel becomes useful when you have 3-4 versions to compare, not on day one.

The strategy docs at Strategies Overview walk through the full lifecycle: creating a strategy, saving versions, running backtests, and deploying a bot.

The Bigger Picture​

Immutable versioning is one of those features that feels like a small quality-of-life improvement until the day it saves you from a mistake. When you accidentally tune away a profitable configuration, when a bot behaves unexpectedly and you need to audit which strategy version was running, when you want to prove to yourself that Version 6 is genuinely better than Version 3 — versioning turns those moments from panic into straightforward lookups.

Combined with Monte Carlo simulation and hyperparameter optimization, versioning lets you build a rigorous, evidence-based approach to strategy development. Each version has its own backtest record. Each backtest result is locked to a specific configuration. The history is always there when you need it.

Ready to try it? Sign in to console.volaticloud.com and open any strategy — the Version History panel is on the detail page. If you haven't run backtests against multiple versions yet, now's the time to start building that track record.

What Are API Clients?​

An API client is a machine identity — a client ID and secret pair that your scripts, bots, or external services use to authenticate with VolatiCloud. Unlike user accounts, API clients are non-interactive: they authenticate using the OAuth 2.0 client_credentials flow, which exchanges a client ID and secret for a short-lived access token, no browser or human in the loop required.

This model is well-suited for:

• Automated pipelines that create and monitor backtests
• External dashboards or analytics tools that pull trading performance data
• CI/CD systems that validate strategy configurations before deployment
• Multi-bot orchestration scripts that manage dozens of bots programmatically

How the client_credentials Flow Works​

The OAuth 2.0 client_credentials grant is designed for server-to-server communication. Here's the sequence:

1. Your application sends a POST request to the token endpoint with its client_id, client_secret, and grant_type=client_credentials.
2. VolatiCloud's authorization server (Keycloak) validates the credentials and returns a signed JWT access token.
3. Your application includes that token in the Authorization: Bearer <token> header on subsequent API requests.
4. Tokens expire after a short window; your application requests a fresh token when needed.

# Request an access token
curl -X POST https://keycloak.volaticloud.com/realms/volaticloud/protocol/openid-connect/token \
  -d "grant_type=client_credentials" \
  -d "client_id=your-client-id" \
  -d "client_secret=your-client-secret"

The response includes an access_token field. Pass that token as a Bearer header on GraphQL requests to https://api.volaticloud.com/query.

Creating an API Client​

API clients are managed from the Organization Settings page in the VolatiCloud console. Only organization administrators with the manage-api-clients permission can create or revoke clients.

To create a new client:

1. Navigate to your organization in console.volaticloud.com.
2. Open Settings → API Clients.
3. Click New API Client, give it a descriptive name (e.g., backtest-pipeline, analytics-bot), and confirm.
4. Copy the generated client secret immediately — it won't be shown again.

Each client is scoped to your organization. It inherits the organization's resource visibility rules: it can access the same bots, strategies, and exchanges that an organization member would see, but cannot escalate privileges beyond what your organization plan allows.

Practical Example: Triggering a Backtest from a Script​

Here's a minimal Python example that authenticates and triggers a backtest via the GraphQL API:

import requests

TOKEN_URL = "https://keycloak.volaticloud.com/realms/volaticloud/protocol/openid-connect/token"
API_URL   = "https://api.volaticloud.com/query"

def get_token(client_id: str, client_secret: str) -> str:
    resp = requests.post(TOKEN_URL, data={
        "grant_type": "client_credentials",
        "client_id": client_id,
        "client_secret": client_secret,
    })
    resp.raise_for_status()
    return resp.json()["access_token"]

def run_backtest(token: str, strategy_id: str) -> dict:
    query = """
    mutation RunBacktest($strategyId: ID!, $config: BacktestConfigInput!) {
      createBacktest(strategyId: $strategyId, config: $config) {
        id
        status
      }
    }
    """
    variables = {
        "strategyId": strategy_id,
        "config": {
            "timeframe": "1h",
            "startDate": "2024-01-01",
            "endDate":   "2024-12-31",
            "pairs":     ["BTC/USDT"],
        },
    }
    resp = requests.post(
        API_URL,
        json={"query": query, "variables": variables},
        headers={"Authorization": f"Bearer {token}"},
    )
    resp.raise_for_status()
    return resp.json()

token = get_token("your-client-id", "your-client-secret")
result = run_backtest(token, strategy_id="abc123")
print(result)

This pattern works identically in Node.js, Go, or any language with an HTTP client. The GraphQL API surface is the same whether you're authenticated as a user or as an API client.

What Can API Clients Do?​

API clients have access to the full VolatiCloud GraphQL API, subject to your organization's plan limits. Common use cases include:

Sensitive fields — like exchange API keys stored in bot configs — are protected by the view-secrets scope, which API clients do not receive by default. This means scripts can read bot status and performance data without ever exposing credentials.

Security Model​

VolatiCloud API clients are backed by Keycloak's client_credentials grant, which provides:

• Short-lived tokens: Access tokens expire quickly, limiting exposure if a token is intercepted.
• Scope separation: API clients cannot access user-owned resources outside your organization.
• Revocation: Any organization admin can revoke a client immediately from the console, invalidating all tokens issued to it.
• Secret rotation: You can delete and recreate a client to rotate its secret without disrupting other clients.

If you need different permission levels for different automation tasks — for example, a read-only analytics script versus a script that can start bots — create separate API clients with descriptive names so you can revoke them independently.

Combining API Access with VolatiCloud's Other Features​

API clients work best when combined with the rest of the platform. A few patterns that fit together naturally:

Automated backtest validation in CI: After every strategy code change, your CI pipeline can run a backtest via API and fail the build if key metrics drop below a threshold — before you deploy to a live bot. See Backtesting: Validate Your Strategy Before Going Live for the metrics worth gating on.

Hyperopt loops without dashboard interaction: Use the API to submit hyperparameter optimization jobs on a schedule, then pull results and write them to a Slack message or internal dashboard. Strategy tuning becomes part of your regular data pipeline rather than a manual task. See Stop Guessing Your Parameters: Introducing Hyperparameter Optimization for details on what hyperopt exposes.

Multi-bot portfolio management: If you run bots across multiple pairs and want to rebalance or pause groups of bots based on market conditions, a script using API clients can query all bot statuses and issue start/stop commands in a loop — without logging into the console.

Getting Started​

API clients are available to all organization administrators on any VolatiCloud plan. Creating a client takes about 30 seconds from the console. If you're new to VolatiCloud, the Quick Start guide walks through setting up your first bot, which you can then manage programmatically once you're comfortable with the platform.

The full GraphQL schema — with all available queries, mutations, and types — is accessible via the API explorer at https://api.volaticloud.com/query once you have a valid token.

What Is a Bot Runner?​

A bot runner is the execution environment where your trading bot actually runs. It takes your strategy configuration, connects to your exchange, and executes trades. The runner handles:

• Starting and stopping bot containers
• Maintaining persistent state (open positions, trade history)
• Exposing the trading engine's API for monitoring
• Restarting bots after crashes or upgrades

In VolatiCloud, each bot is assigned to a runner when you create it. The runner manages the underlying container orchestration — whether that's Docker on a VPS or a Kubernetes pod in a managed cluster.

Cloud Runners vs Self-Hosted Runners​

VolatiCloud supports two deployment models:

Cloud runners are the fastest way to get started. VolatiCloud provisions and manages the underlying infrastructure, monitors runner health, and handles restarts automatically. When you create a bot, a public cloud runner is available by default — no configuration required.

Self-hosted runners put you in control. You run the runner agent on your own VPS, dedicated server, or Kubernetes cluster. This is the right choice if you:

• Need the bot to run closer to a specific exchange's matching engine (latency-sensitive strategies)
• Operate in a jurisdiction with data residency requirements
• Want to co-locate with other trading infrastructure
• Run a large number of bots and want to optimize compute costs
• Prefer not to share infrastructure with other traders

Setting Up a Self-Hosted Runner​

A self-hosted runner requires a machine running Docker (or a Kubernetes cluster with the VolatiCloud runner operator).

1. Create a runner in VolatiCloud — Navigate to the Runners section, click "Add Runner", and give it a name.
2. Copy your registration token — VolatiCloud generates a unique token that binds your runner to your organization.
3. Install the runner agent — On your server, run the agent with your token:

docker run -d \
  --name volaticloud-runner \
  --restart unless-stopped \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /data/volaticloud:/data \
  -e RUNNER_TOKEN=your-token-here \
  volaticloud/runner-agent:latest

1. Verify the connection — Your runner appears as "Online" in the VolatiCloud dashboard within a few seconds.

Once registered, any bot you assign to this runner will deploy its container on your machine. VolatiCloud handles strategy configuration and trade monitoring; you own the compute.

Kubernetes Deployments for Scale​

For teams running many bots simultaneously, Kubernetes provides better resource isolation, rolling upgrades, and automatic rescheduling if a node fails.

VolatiCloud's Kubernetes runner mode deploys each bot as a separate Pod with its own resource limits. The runner controller watches for new bot assignments and creates pod specs automatically:

resources:
  requests:
    memory: "512Mi"
    cpu: "250m"
  limits:
    memory: "1Gi"
    cpu: "500m"

Each bot pod gets its own persistent volume for the SQLite trade database, so a pod restart doesn't lose any open position data. VolatiCloud also supports bot database backups to S3, which makes disaster recovery straightforward if a node goes down permanently.

Namespace Sharding​

At high bot counts, VolatiCloud shards deployments across multiple Kubernetes namespaces to avoid hitting per-namespace resource limits. The platform handles this automatically based on the runner's capacity settings — you don't need to manage namespace assignment manually.

Persistent State and Trade Data​

One of the most important properties of a bot runner is how it handles state. Trading bots maintain an internal database that tracks:

• Open and closed trades
• Trade entry prices and fees paid
• Custom trade metadata (tags, notes)
• Internal strategy state

VolatiCloud persists this database as a SQLite file inside the container's mounted volume. Even if the container is stopped and restarted — during an upgrade, after a crash, or following a runner migration — the bot resumes with its full trade history intact.

When migrating a bot from one runner to another, always export the trade database first. VolatiCloud provides a one-click export from the bot's settings page. Importing this file on the new runner ensures the bot continues tracking positions correctly without manual reconciliation.

Monitoring Your Runner's Health​

Whether you're on a cloud runner or a self-hosted one, VolatiCloud surfaces runner health in the dashboard:

• Status indicator — Online, Offline, or Degraded
• Bot count — How many bots are currently running on the runner
• Last heartbeat — When the runner last reported to VolatiCloud

If a self-hosted runner goes offline, VolatiCloud sends you an alert and marks the affected bots as inactive. No trades are attempted while a runner is disconnected, preventing the bot from acting on stale market data.

VolatiCloud's WebSocket-based monitoring pipeline streams trade events in real time, so you can watch your bot's activity from the dashboard as it happens — no polling, no refresh required. Combine this with trade alerts to get notified on every fill, stop-loss trigger, or drawdown threshold breach.

Choosing the Right Setup​

Most traders should start with a cloud runner. It removes all infrastructure concerns and lets you focus on building and testing your strategy. The Visual Strategy Builder and backtesting tools are useful on any runner, but you'll get the fastest iteration loop when you're not managing servers.

Move to a self-hosted runner when:

• You've validated a strategy through backtesting and paper trading and are ready to go live with significant capital
• Latency to your exchange matters for your strategy's edge (scalping, arbitrage)
• You have an existing server or cloud account where adding a Docker container is simpler than adding a subscription
• You're building a multi-bot portfolio and want to control where and how each bot runs

There's no wrong answer — and you can run some bots on cloud runners and others on self-hosted runners simultaneously, assigning each bot to the runner that best fits its requirements.

Getting Started​

If you're ready to deploy your first bot, VolatiCloud makes it straightforward:

1. Build or import a strategy (the Visual Strategy Builder is a good starting point)
2. Run a backtest to validate the strategy's historical performance
3. Create a bot, connect your exchange, and assign it to a cloud runner
4. Start in paper trading mode to confirm execution is working before switching to live capital

For teams that need self-hosted runners or Kubernetes deployments, the VolatiCloud runner documentation covers registration, configuration, and troubleshooting in detail.

Start with a free trial at console.volaticloud.com — cloud runners are ready the moment you create your first bot.

Most algorithmic trading guides focus on finding the right entry and exit signals. That part is important, but it's only half the equation. A strategy with a 55% win rate and mediocre signal quality will outperform a strategy with a 70% win rate and reckless position sizing. Risk management is where strategies succeed or fail in production.

This guide covers the core risk parameters for automated crypto bots, how to think about each one, and how to validate your choices before committing real capital.

Why Position Sizing Outweighs Signal Quality​

Consider two strategies:

Strategy A looks better on paper. But five consecutive losses — not unusual even with a 70% win rate — wipes out two-thirds of the account. Strategy B survives and keeps compounding.

The math behind this is the Kelly Criterion, which states that the optimal bet size is a function of your edge (win rate × win amount minus loss rate × loss amount). Most practitioners use a fraction of Kelly to be conservative, typically 25–50% of the theoretical optimum.

The practical takeaway: smaller position sizes allow more trades before a catastrophic drawdown, giving your edge more opportunities to play out.

The Three Core Parameters Every Bot Needs​

Before tuning any indicator, configure these three parameters correctly:

stake_amount — how much capital each trade uses, either as a fixed dollar amount or a percentage of your current balance. Most bots support both modes. Percentage-based sizing compounds naturally as your account grows (or shrinks); fixed sizing is more predictable for accounting purposes.

stoploss — the maximum loss you'll accept on a single trade before the bot closes the position. Expressed as a negative percentage (e.g., -0.05 for -5%). This is your primary protection against large single-trade losses.

max_open_trades — how many positions the bot can hold simultaneously. Combined with stake amount, this caps your total exposure. A bot with stake_amount: 10% and max_open_trades: 5 can have at most 50% of the balance deployed at any time.

These three parameters interact. Tune them together, not independently.

Fixed vs. Percentage-Based Stake Amounts​

Both approaches are valid. The choice depends on your goals:

Fixed stake (e.g., $100 per trade):

• Predictable cost per trade regardless of account size
• Easier to track in accounting software
• Doesn't naturally adjust as account grows or shrinks
• Risk: after losses reduce your account, fixed stakes represent a larger percentage of remaining balance

Percentage of balance (e.g., 5% per trade):

• Automatically scales with account growth — a winning streak compounds more aggressively
• Naturally reduces position size after drawdowns, giving you a self-protective quality
• Makes it easier to reason about maximum possible loss sequences
• Risk: small percentages on large accounts may not be worth the transaction fees

For most automated strategies, percentage-based sizing is preferable because it adapts to account size changes and makes risk calculations consistent regardless of starting capital.

Stoploss Configuration: How Tight Is Too Tight​

The stoploss percentage is one of the most misunderstood parameters. Traders often set it too tight, thinking they're limiting risk — but a stoploss that's narrower than normal market noise causes frequent false stops.

Consider a coin that fluctuates ±2% intraday on quiet days. A stoploss of -1% will trigger constantly, not because your strategy is wrong, but because normal volatility hits the threshold. You end up paying fees on losing trades that would have recovered within hours.

A rough heuristic: the stoploss should be at least 1.5–2× the typical intraday volatility of your trading pair. The Average True Range (ATR) indicator measures this directly — a stoploss of 1–2× the daily ATR is a reasonable starting point.

On the other end, a stoploss that's too wide lets losing trades run too long. A -25% stoploss on a crypto position means you're accepting a quarter of your stake as a worst case — which requires a 33% gain just to recover.

The target zone for most medium-term bot strategies: somewhere between -3% and -10%, calibrated to the volatility of your specific trading pairs.

Validating Risk Parameters Before Going Live​

The danger with risk parameters is that they're easy to backtest-optimize into uselessness. If you run a backtest and tune stoploss to minimize drawdown on that specific dataset, you've overfit to historical noise. The next month's data will behave differently.

VolatiCloud's backtest suite lets you test different stake and stoploss combinations across historical data to see how each configuration performed. But the more powerful validation tool is Monte Carlo simulation.

Instead of treating your backtest result as a single definitive outcome, Monte Carlo randomly shuffles the sequence of your historical trades thousands of times and measures the distribution of outcomes. This answers the question: "What's my worst-case drawdown if the same trades happened in a different order?"

If your backtest shows a 15% max drawdown but Monte Carlo's 5th percentile shows a 40% drawdown, your strategy's real-world risk is closer to 40%. The historical sequence happened to be favorable; the shuffled runs reveal the underlying fragility.

From the Monte Carlo results, look at:

• 95th percentile drawdown — the worst outcome you should plan for
• Return distribution width — wide distributions signal fragile strategies that depend on favorable trade ordering
• Ruin probability — what percentage of simulations result in a drawdown exceeding your tolerance threshold

Similarly, VolatiCloud's hyperparameter optimization can search over ranges of stoploss and stake parameters to find combinations that perform well across multiple backtest periods — helping you distinguish genuine robustness from overfitting to a single date range.

Max Open Trades and Correlation Risk​

max_open_trades controls how many positions run simultaneously. Higher values spread risk across more trades; lower values concentrate it.

The catch: if you're trading multiple pairs on the same exchange (e.g., BTC/USDT and ETH/USDT), those positions are often correlated. When Bitcoin drops 10%, altcoins usually follow. Having 10 open trades across correlated pairs provides much less diversification than it appears.

For genuine diversification:

• Trade across multiple asset classes when possible (not just crypto)
• On crypto-only strategies, mixing BTC-dominated pairs with stablecoin pairs or DeFi tokens reduces correlation
• Or simply accept the correlation and size each position smaller to account for it

A practical setting for most single-exchange crypto bots: 3–8 max open trades, with position sizes set so the total deployed capital stays between 30–60% of balance. This leaves headroom for adding to positions and avoids being fully exposed during sudden market drops.

Walk-Forward Validation of Risk Settings​

Once you've settled on risk parameters, test them using walk-forward analysis:

1. Choose a 12-month historical period
2. Optimize your parameters on the first 8 months (in-sample)
3. Run your strategy with those parameters on the remaining 4 months (out-of-sample) — no adjustments
4. If performance degrades significantly on the out-of-sample period, your parameters are overfit

Repeat this with multiple rolling windows. If your risk parameters consistently produce similar results across different time windows, they're likely capturing something real rather than historical noise.

This is more work than a single backtest, but it's the minimum validation threshold before running a strategy live.

Common Risk Management Mistakes​

Using a fixed fraction of balance as a starting point, then not adjusting after losses. If you start with 10% per trade and take three consecutive -8% losses, your account is down ~23%. At that point, 10% of the reduced balance is still 10% — the self-adjusting property handles this naturally, but only if you're using percentage-based sizing.

Optimizing stoploss specifically to minimize backtest drawdown. This almost always overfit to the test period. A stoploss that made historical data look clean will get triggered repeatedly on live data.

Ignoring fees when calculating position sizes. On high-frequency strategies, fees can consume a significant portion of gains. If you're trading with a 0.1% maker/taker fee and targeting 0.5% gains, fees represent 40% of your profit. Factor this into position sizing.

Setting max_open_trades to unlimited. This removes a key safety ceiling. Always cap total simultaneous positions.

Skipping paper trading before going live. Your risk parameters may be correct in backtests but behave unexpectedly with live market data, order slippage, and exchange latency. VolatiCloud supports paper trading mode — run your configured bot against live market data without real orders for at least a week before switching to live execution.

Building Risk Into Your Strategy From the Start​

The cleanest approach: define your acceptable maximum drawdown first, then work backward to the position size and stoploss that can produce it.

If you can tolerate a 20% drawdown on your trading account:

• Use Monte Carlo to find the stoploss / stake combination whose 95th percentile drawdown stays under 20%
• Backtest to confirm the strategy is still profitable within those constraints
• Walk-forward validate to check robustness

This is the opposite of the common pattern (optimize for returns, hope the drawdown is acceptable). Starting from your risk tolerance and working backward leads to strategies that survive.

VolatiCloud's backtesting, Monte Carlo simulation, and hyperparameter optimization tools give you the quantitative foundation to validate risk parameters before committing real capital. Start your 7-day free Pro trial and run your first risk analysis.

For related reading, see Beyond the Single Backtest: Introducing Monte Carlo Simulation and Stop Guessing Your Parameters: Introducing Hyperparameter Optimization.

The Parameter Problem​

Build a strategy using RSI. What period do you use? 14 is the traditional default, but is it actually optimal for your specific pairs, timeframe, and trading style? What about your entry threshold — 30? 25? 35?

Now multiply that by every configurable value in your strategy. The combinations explode quickly, and testing them manually is:

1. Time-consuming — running a backtest for every combination takes hours or days
2. Biased — you naturally gravitate toward "reasonable" values and miss counter-intuitive optima
3. Incomplete — you can't manually explore the full parameter space

Hyperparameter optimization (hyperopt) solves all three problems.

How It Works​

Hyperopt uses intelligent search algorithms to systematically explore your parameter space:

1. You define the search bounds — RSI period: 5 to 50, entry threshold: 10 to 40
2. The optimizer samples combinations — using Bayesian optimization to focus on promising regions
3. Each combination runs a full backtest — measured against your chosen objective (e.g., Sharpe ratio)
4. The optimizer converges — toward the parameter set that best optimizes your objective
5. You get data-driven parameters — not a guess

VolatiCloud runs this on your selected Bot Runner, using the same Freqtrade engine that powers your standard backtests. The process is fully managed — no infrastructure setup required.

Setting Up Parameters for Optimization​

In the Strategy Studio, each numeric parameter (indicator periods, condition thresholds, constant values) has an Optimize toggle. When enabled:

• Set a min and max range for the parameter
• Assign it to an optimization space (Buy Signal, Sell Signal, ROI, Stoploss, Trailing)

The optimizer will search within those bounds across all the parameters you've toggled on.

Choosing Your Loss Function​

The loss function defines what "best" means. VolatiCloud supports six options:

Start with Sharpe Ratio. It balances returns against volatility, which generally produces more robust strategies than pure profit optimization. If the Sharpe-optimized parameters look good, you can compare against other loss functions to see if a different objective produces meaningfully different results.

Optimization Spaces​

Rather than optimizing everything at once, you can select which groups of parameters to search:

Each additional space multiplies the search space. Our recommendation: start with Buy Signal and Sell Signal, run the optimization, then use the best signal parameters as a fixed baseline while separately optimizing ROI and Stoploss. This staged approach is faster and reduces the risk of overfitting.

Reading the Results​

Overview Panel​

When your hyperopt completes, the overview shows:

• Best Epoch — Which iteration found the optimal parameter set
• Best Loss — The objective value achieved (lower is better for most functions)
• Best Parameters — The exact values to use
• Total Trades — Number of trades with the optimized parameters
• Profit & Max Drawdown — Performance summary for the best epoch

Epoch Table​

Every completed iteration is listed with its loss value, trade count, win rate, profit, drawdown, and Sharpe ratio. Sort by any column to explore near-optimal results — sometimes an epoch with a slightly worse loss value produces a more practical parameter set (e.g., more trades for statistical significance).

Applying Parameters​

Once you've identified the winning parameter set, click Apply to Strategy directly from the results page. This updates your strategy's parameter values in the Strategy Studio without modifying the strategy logic.

How Many Epochs?​

More epochs give the optimizer more opportunities to find the global optimum, but diminishing returns kick in after the search converges. For most strategies, 500 epochs covers the parameter space adequately.

Real-Time Monitoring​

While a hyperopt runs, you don't need to wait in the dark:

• Progress bar — Updates approximately every 30 seconds showing completion percentage
• Live epoch table — Populates as each epoch completes; you can see results building in real time
• Container logs — Stream raw Freqtrade output directly in the UI for debugging

Long-running optimizations (1,000+ epochs) can run for 30+ minutes depending on date range, number of pairs, and runner capacity. You can navigate away and come back — the hyperopt continues on your runner.

Avoiding Overfitting​

Overfitting is the central risk of hyperparameter optimization. An overfit strategy looks exceptional on historical data and disappoints in live trading. Here's how to guard against it:

Use out-of-sample validation. Split your historical data: optimize on years 1–2, then validate with a standard backtest on year 3. If performance drops significantly out-of-sample, the parameters are overfit.

Fewer optimizable parameters is better. Every parameter you optimize is a degree of freedom the optimizer can use to fit historical noise. Only toggle optimization on parameters that meaningfully affect strategy behavior.

Sanity-check extreme values. If the optimal RSI period is 47 and the threshold is 31.7, ask whether those values make practical trading sense. Conventional ranges (RSI period 10–20, threshold 25–35) are often more robust than precisely optimized edge values.

Run Monte Carlo afterward. Apply your optimized parameters, run a backtest, then put those results through Monte Carlo simulation. If the Monte Carlo confidence bands are wide or risk of ruin is non-trivial, the parameters may be overfit to a specific trade sequence.

Compare loss functions. If Sharpe Ratio optimization and Only Profit optimization produce wildly different parameter sets, the strategy is fragile. Robust strategies tend to produce similar parameters across different objectives.

A Practical Workflow​

Here's the workflow that produces reliable results:

1. Build your strategy with sensible default parameters
2. Run an initial backtest over 2+ years to establish a baseline
3. Enable optimization on 3–5 key parameters with focused ranges
4. Run hyperopt with 500 epochs, Sharpe Ratio loss function, on Buy/Sell Signal spaces
5. Validate out-of-sample — run a standard backtest on a date range not used in optimization
6. Run Monte Carlo simulation on the validated backtest to stress-test robustness
7. Apply parameters to your strategy if results hold up
8. Paper trade before committing real capital

This process turns parameter selection from a guessing game into a systematic, data-driven decision.

Plan Details​

Hyperparameter optimization is available on Pro and Enterprise plans:

Starter plan users can upgrade to Pro to access hyperparameter optimization.

Getting Started​

1. Open a strategy in the Strategy Studio
2. Enable the Optimize toggle on the parameters you want to tune
3. Set min/max ranges for each optimizable parameter
4. Navigate to Hyperopt in the sidebar
5. Select your strategy, runner, and configure the search settings
6. Click Run Hyperopt and watch results populate in real time

To get started, open a strategy in the VolatiCloud console, enable the Optimize toggle on a few key parameters, set their min/max ranges, and run your first hyperopt from the sidebar.

The Problem with a Single Backtest​

You run a backtest: 84% profit, 14% max drawdown, Sharpe ratio of 1.62. Looks great. But here's the uncomfortable question: how much of that result depended on the exact sequence of those trades?

What if your three best trades happened to occur right when your account was at peak size? What if your losing streak hit during month 2 instead of month 8? The profit/loss totals might be identical, but the equity curve — and your actual experience running that bot — could be completely different.

This is the limitation of a single backtest: it shows you one possible path, not the distribution of paths.

Enter Monte Carlo Simulation​

Monte Carlo simulation takes your completed backtest trades and runs them through thousands of randomized variations. For each iteration, it shuffles the order, resamples the trades, or generates synthetic trades based on your historical statistics. Then it calculates performance metrics for every iteration and shows you the distribution of outcomes.

Instead of:

"My strategy returned 45% profit"

You get:

"My strategy returns between 20% and 65% profit in 90% of scenarios, with a median of 43%"

That's a more complete and more honest picture of your strategy's risk profile.

Three Simulation Methods​

VolatiCloud supports three approaches, each designed to answer a different question.

Trade Shuffle (Recommended Default)​

Randomly reorders your historical trades and recalculates the equity curve for each permutation. The total P&L across all iterations is roughly the same, but the paths diverge significantly.

What it tells you: How much does trade ordering matter to your strategy? A strategy that produces tight equity curve bands regardless of order is genuinely robust. Wide bands reveal path dependency.

Bootstrap​

Samples trades with replacement — in each iteration, some trades appear multiple times while others are skipped entirely. This simulates what happens if certain trade types occur more or less frequently than they did historically.

What it tells you: Is your strategy's performance driven by a few big winning trades? If removing any single trade dramatically changes your results, bootstrap will expose this fragility.

Parametric​

Fits a statistical distribution to your trade returns and generates entirely synthetic trades drawn from that distribution. It makes more assumptions but works well when you have fewer than 30 historical trades.

What it tells you: How would your strategy perform under idealized statistical conditions? Useful for theoretical analysis when trade history is thin.

What You See After Running a Simulation​

Equity Curve Bands​

Five percentile bands show the range of possible equity curves:

The key insight: If p5 (the worst 5% of scenarios) is still profitable, your strategy has demonstrated robustness across the full range of plausible trade sequences.

Risk of Ruin​

The probability that your account balance drops below a configured threshold at any point during a simulation. With a 50% threshold and 1,000 iterations:

• If 3 iterations saw the balance dip below 50% of initial capital → Risk of Ruin = 0.3%

For a robust strategy, risk of ruin should be near zero. If it exceeds a few percent, consider reducing position sizes or adding stop-loss rules before going live.

Final Balance Distribution​

A histogram of ending account values across all iterations. If the mean is significantly higher than the median, a few extreme winning scenarios are pulling the average up — the median is the more reliable expectation.

Drawdown and Risk-Adjusted Metrics​

Distributions of maximum drawdown, Sharpe ratio, and Sortino ratio across all iterations. A Sharpe ratio that stays above 1.0 even at p5 indicates a consistently risk-efficient strategy.

A Practical Example​

Let's say your backtest produced these results:

Total Trades: 187
Total Profit: 54.2%
Max Drawdown: 12.8%
Sharpe Ratio: 1.71

You run a 5,000-iteration Trade Shuffle simulation and get:

Profit:        p5=22.4%  p50=51.8%  p95=78.3%
Max Drawdown:  p5=27.1%  p50=14.2%  p95=8.4%
Sharpe Ratio:  p5=0.91   p50=1.68   p95=2.31
Risk of Ruin (50% threshold): 0.1%

Analysis:

✅ Median profit (51.8%) is close to the single backtest (54.2%) — results are consistent ✅ Even in the worst 5% of scenarios, the strategy is profitable (22.4%) ✅ Risk of ruin is negligible (0.1%) ⚠️ Worst-case drawdown (27.1%) is significantly higher than the single backtest (12.8%) — worth factoring into position sizing decisions

This strategy has strong statistical evidence of robustness. The drawdown in worst-case scenarios is something to plan for, not ignore.

Detecting Overfitting​

Monte Carlo simulation is one of the most effective tools for identifying overfit strategies. If your single backtest looks excellent but:

• The p5/p95 confidence bands are extremely wide
• The median (p50) is significantly below your single backtest result
• Risk of ruin is non-trivial

...your strategy may be exploiting the specific trade sequence in your backtest rather than a genuine market edge. This is worth knowing before deploying capital.

Best Practices​

Lead with risk, not returns. Before celebrating the p95 scenario, understand the p5 scenario. If you can psychologically and financially handle the worst 5% of outcomes, the strategy is worth considering.

Use seeds for strategy comparison. When comparing two versions of a strategy, fix the random seed so differences in simulation results reflect strategy changes, not random variation.

More trades give better analysis. Monte Carlo works best with 50+ trades. With fewer than 30, the Parametric method or a longer backtest date range will give more reliable results.

Compare methods. Run both Trade Shuffle and Bootstrap. Significant differences between them indicate that your strategy is sensitive to both trade ordering and individual trade outcomes — a red flag for fragility.

Plan Details​

Monte Carlo simulation is available on Pro and Enterprise plans:

Starter plan users can upgrade to Pro to access Monte Carlo simulation.

Getting Started​

1. Complete a backtest on any strategy
2. Click Run Monte Carlo Simulation from the backtest results page
3. Choose Trade Shuffle as your starting method
4. Set iterations to 1,000 for a quick check (under 10 seconds)
5. Review equity curve bands, risk of ruin, and the final balance distribution

If you're new to backtesting, check out our backtesting guide first. Monte Carlo simulation is most valuable when you already have solid backtest results to stress-test.

Complete a backtest in the VolatiCloud console, then click Run Monte Carlo Simulation from the results page. Start with 1,000 iterations and Trade Shuffle to see your equity curve bands and risk-of-ruin figure.

Why Backtest?​

A backtest simulates how your strategy would have performed on historical price data. It answers critical questions:

• Would this strategy have been profitable over the last 2 years?
• What was the worst drawdown I would have experienced?
• How many trades per week/month does it generate?
• Does it perform better in bull markets, bear markets, or both?

Without backtesting, you're trading on intuition alone — you don't know if your strategy has a mathematical edge.

The VolatiCloud Backtesting Engine​

VolatiCloud uses Freqtrade's production-tested backtesting engine — the same engine used by thousands of algorithmic traders worldwide. It supports:

• Realistic simulation — Candle-by-candle simulation with OHLCV data
• Fee modeling — Exchange trading fees are calculated for every trade
• Slippage approximation — Realistic fill price modeling
• 15 timeframes — From 1-minute to monthly candles
• Any exchange — Historical data from Binance, Bybit, Kraken, OKX, and more
• Multi-pair backtests — Test across dozens of pairs simultaneously

Key Metrics Explained​

Sharpe Ratio​

The Sharpe ratio measures return relative to volatility. A strategy that makes 20% per year but swings wildly is less desirable than one making 15% with smooth, consistent returns.

Sharpe = (Annual Return - Risk-Free Rate) / Annual Volatility

Target: > 1.0 (excellent: > 2.0)

Sortino Ratio​

Like Sharpe, but only penalizes downside volatility. Large gains don't count against you — only losses do.

Target: > 1.5

Profit Factor​

Profit Factor = Gross Profit / Gross Loss

A profit factor > 1.0 means you made more on winning trades than you lost on losing trades.

Target: > 1.5 (excellent: > 2.0)

Max Drawdown​

The worst peak-to-trough decline in your portfolio value. A 30% max drawdown means at its worst point, your portfolio was down 30% from its peak.

Rule of thumb: Can you psychologically handle the worst-case drawdown? If a 20% drawdown would make you panic and stop the bot, set your expectation before going live.

Target: < 20% for most strategies

Win Rate vs Expectancy​

A high win rate doesn't automatically mean a profitable strategy. You also need to consider the average size of your wins vs losses.

Expectancy = (Win Rate × Average Win) - (Loss Rate × Average Loss)

A strategy with a 40% win rate can be highly profitable if winners are 3x larger than losers.

Running a Backtest​

1. Open your strategy
2. Click Run Backtest
3. Configure:
   • Exchange: Where the historical data comes from
   • Pairs: Which trading pairs to simulate (single or multiple)
   • Date Range: At least 12 months recommended; 2-3 years for high confidence
   • Stake Amount: Amount per trade
4. Click Run

Results are available within seconds to a few minutes depending on date range and number of pairs.

Interpreting Results: A Real Example​

Say a backtest returns:

Period: Jan 2024 – Jan 2026 (2 years)
Pairs: BTC/USDT, ETH/USDT, BNB/USDT

Total Profit: +84.2%
Win Rate: 61%
Profit Factor: 1.73
Max Drawdown: 14.3%
Sharpe Ratio: 1.62
Sortino Ratio: 2.11
Total Trades: 342
Avg Trade Duration: 8.2 hours

Analysis:

✅ Profitable over a 2-year period (bull + bear markets) ✅ Solid win rate (61%) and profit factor (1.73) ✅ Acceptable drawdown (14.3%) — most traders can handle this ✅ Good Sharpe ratio (1.62) — risk-adjusted return is strong ✅ Enough trades (342) for statistical significance (>30 is minimum)

This looks like a viable strategy worth deploying in Dry Run first.

Common Backtesting Mistakes​

1. Overfitting​

If your strategy was specifically tuned to perform well on one specific date range, it might not generalize to future market conditions. Always test on out-of-sample data — a period you didn't use when creating the strategy.

2. Too Few Trades​

Less than 30 trades makes statistical analysis unreliable. Extend your date range or add more pairs.

3. Ignoring Market Conditions​

A strategy that only performs well in bull markets will struggle in bear markets. Test across different market regimes.

4. Unrealistic Stop-Losses​

Very tight stop-losses (1-2%) look great in backtests but often trigger on normal market noise. Be conservative with stop-losses in backtesting.

From Backtest to Live​

1. Backtest shows theoretical performance ✓
2. Dry Run (paper trading) validates real-time performance
3. Live with small stake builds confidence
4. Scale up position size as you gain confidence

Never skip the dry run stage. Real-time execution has different characteristics than backtesting — market impact, API latency, and changing market conditions all affect live performance.

Open a strategy in the console, click Run Backtest, and choose at least 12 months of data to start. The results page breaks down every metric covered above.

Related guides​

• Backtesting Overview — Key concepts, metrics, and how the Freqtrade engine runs simulations.
• Running a Backtest — Step-by-step walkthrough for launching your first backtest.
• Blog: Avoiding Overfitting in Backtests — Practical techniques to build strategies that generalize.
• Blog: Monte Carlo Simulation — Stress-test your strategy with randomized trade sequences.

That's the specific scenario VolatiCloud's alerting system is built to catch. The goal is narrow: notify you immediately when something critical breaks, and stay quiet the rest of the time.

Severity-Based Delivery​

Critical events need instant delivery. Routine events batch into digests — so your inbox doesn't fill up every time a trade closes or a backtest finishes.

• Critical → Immediate email, always
• Warning → Batched digest, grouped intelligently
• Info → Batched digest, low frequency

Alert Types​

Bot Status Alerts​

The most important alert type. Know immediately when:

• A bot enters error state (maybe exchange API key expired, or the exchange is down)
• A bot stops unexpectedly (infrastructure issue on the runner)
• A bot becomes unhealthy (running but not functioning correctly)

Example configuration:

Alert Type: Bot Status Change
Status: error
Severity: Critical
Cooldown: 30 minutes
Recipients: admin@company.com, oncall@company.com

Trade Alerts​

Get notified when:

• Any trade closes — Know your bot's activity
• Large profit — Celebrate when a trade exceeds X% profit
• Large loss — Immediate awareness of significant losing trades

Alert Type: Large Loss
Threshold: -5% per trade
Severity: Warning

Drawdown Threshold​

One of the most valuable risk management tools. Get alerted before a drawdown becomes critical:

Alert Type: Drawdown Threshold
Threshold: 15%
Severity: Warning

When max drawdown exceeds 15%, you're notified to review the bot's performance and potentially intervene.

Daily Loss Limit​

Prevent runaway losses in a single day:

Alert Type: Daily Loss Limit
Threshold: 3%
Severity: Critical

This is particularly valuable during volatile market events when a strategy might experience unusual behavior.

Backtest Completion​

When a long-running backtest completes (or fails), get notified so you don't have to keep checking:

Alert Type: Backtest Completed
Severity: Info

Smart Cooldowns​

Alert storms are a real problem. Imagine a bot that errors, restarts, errors again — without cooldowns, you'd receive a flood of critical alerts.

Cooldowns prevent this:

Cooldown: 60 minutes

Even if an alert condition triggers 10 times in an hour, you receive only one notification during that period. The next alert won't fire until the cooldown expires.

For critical bot errors, a 30-60 minute cooldown is typically appropriate. For trade alerts, 0-15 minutes.

Default Bot Alerts​

Every bot you create automatically gets a set of default alert rules:

You'll get the alert even if you haven't set up any custom rules yet.

In-App Notifications​

Beyond email, VolatiCloud shows real-time alerts directly in the dashboard:

Notification Drawer Click the bell icon (🔔) in the top navigation to see all recent alerts with their severity, time, and details.

Toast Notifications Critical and warning alerts pop up as toast notifications while you're using the app — you'll see them immediately even if you're on a different page.

Alert History Navigate to Alerts → History to see a complete audit trail of all triggered alerts, their delivery status, and whether they were suppressed by cooldown.

Testing Your Alerts​

Before relying on alerts in production:

1. Configure your alert rule
2. Click Test Alert
3. Verify the email arrives with correct content
4. Check that recipients are correct

Never assume email delivery is working without testing it first.

Best Practices​

For solo traders:

• Enable critical bot error alerts for all bots
• Set a drawdown threshold at 20% as an early warning
• Keep email cooldowns at 30-60 minutes to avoid fatigue

For teams:

• Route critical alerts to a shared Slack/email (via email forwarding)
• Assign different alert recipients for different bots
• Use daily loss limit alerts for risk management

For production systems:

• Always have a secondary recipient for critical alerts
• Test alerts after any infrastructure change
• Review alert history weekly to catch patterns

Alerts are available on all plans. Navigate to your bot in the console, open the Alerts section, and start with the default rules before adding custom ones. The test button is there for a reason — use it before you rely on an alert in production.

Related guides​

• Alerts Overview — Introduction to notification channels and alert event history.
• Alert Rules — Create and configure alert rules, severity levels, and cooldowns.
• Bot Monitoring — Real-time metrics and log streaming for running bots.

VolatiCloud is a cloud-native algorithmic trading platform built on Freqtrade. This post walks through what it does and why it's built the way it is.

The Problem​

Running a trading bot reliably means solving a stack of infrastructure problems before you can touch the strategy itself:

• Standing up servers to run bots 24/7
• Managing exchange API connections securely
• Building backtesting infrastructure from scratch
• Monitoring positions across multiple bots in real time

Traders with strong strategy intuition often stall on the DevOps layer. Developers who can handle the infrastructure often spend weeks on it instead of iterating on strategies. VolatiCloud handles the infrastructure so you can focus on the strategy.

What's Here​

Visual Strategy Builder​

The visual condition editor lets you build trading strategies by connecting indicator nodes, comparison operators, and AND/OR/NOT logic trees — without Python. Select from 25+ built-in indicators (RSI, MACD, Bollinger Bands, EMA, and more), define entry and exit conditions, configure parameters. The builder generates optimized Freqtrade-compatible Python code automatically. When you need the full API, eject to Code Mode with one click.

Powered by Freqtrade​

VolatiCloud runs on Freqtrade — the production-tested open-source crypto trading bot with years of community development, rigorous testing, and support for 100+ exchanges via CCXT. You get the industry-standard backtesting engine, spot/margin/futures support, the full Python strategy API when you need it, and an active community behind the underlying engine.

Multi-Exchange Support​

Connect to 8+ major exchanges including Binance, Bybit, OKX, Kraken, KuCoin, Coinbase, and Bitfinex. Exchange API keys are encrypted with AES-256-GCM before storage — your credentials are protected.

Intelligent Backtesting​

Test your strategies against years of historical data. You get institutional-grade metrics including Sharpe ratio, Sortino ratio, Calmar ratio, max drawdown, profit factor, and 15+ more.

Real-Time Monitoring​

WebSocket-powered dashboards update in real time — no page refresh needed. Monitor P&L, open positions, CPU/memory usage, and trading activity across all your bots simultaneously.

Smart Alerting​

Configure email alerts for bot errors, trade results, drawdown breaches, and more. Severity-based delivery ensures critical alerts arrive immediately. A bot crash at 3AM sends you a notification — you're not finding out about it the next morning.

Who Uses It​

Solo traders who want to run systematic strategies without managing servers. Start with the visual condition editor, validate in paper trading mode, then move to live.

Developers who want the full Freqtrade API without the infrastructure overhead. Deploy to your own Docker or Kubernetes setup, or use VolatiCloud's managed runners.

Trading teams that need role-based access — shared exchange connections and strategies, without sharing API keys or billing credentials. See the team management guide for how that works.

Getting Started​

1. Sign up for free — no credit card required
2. Create your organization
3. Build your first strategy with the visual condition editor
4. Run a backtest
5. Deploy your first bot in Dry Run mode

If you want to understand specific parts of the platform before diving in, the documentation covers each feature in detail. Questions about whether VolatiCloud fits your use case? The team management, exchange support, and backtesting posts go deeper on those areas.

Supported Exchanges​

Trading Modes​

VolatiCloud supports all three major trading modes:

Spot Trading​

Buy and sell the underlying asset. Classic trading where you own what you buy.

• No leverage
• Risk limited to position size
• Available on all supported exchanges
• Best for beginners and conservative strategies

Margin Trading​

Trade with borrowed funds for amplified exposure.

• 2x–10x leverage depending on exchange
• Higher potential returns AND higher potential losses
• Requires sufficient collateral

Futures Trading​

Trade perpetual or quarterly futures contracts.

• High leverage (up to 100x on some exchanges)
• Can go long AND short easily
• Available on Binance, Bybit, OKX, Kraken, KuCoin
• Essential for short-selling strategies

Long and Short Strategies​

VolatiCloud's strategy builder supports bi-directional trading — go long when conditions are bullish, short when bearish:

# In Code Mode
can_short = True

def populate_entry_trend(self, dataframe, metadata):
    # Long when RSI oversold
    dataframe.loc[dataframe['rsi'] < 30, 'enter_long'] = 1
    # Short when RSI overbought
    dataframe.loc[dataframe['rsi'] > 70, 'enter_short'] = 1
    return dataframe

Or with the UI Builder's Mirror Mode — enable it and your long conditions are automatically inverted for shorts.

Security: AES-256-GCM Encryption​

Your exchange API keys are your most sensitive credentials on VolatiCloud. We protect them with AES-256-GCM field-level encryption:

1. When you save an API key, it's encrypted before being written to the database
2. The encryption key is stored separately from the encrypted data
3. Even database administrators cannot read your credentials in plaintext
4. Keys are only decrypted in memory at the moment they're needed (to construct a bot's config)

Additionally:

• API keys are never logged
• Sensitive fields require the view-secrets permission to access
• We never ask for or store withdrawal permissions

Choosing the Right Exchange for Your Strategy​

Different strategies suit different exchanges:

High-frequency strategies → Binance (deepest liquidity, lowest latency)

Futures/leverage strategies → Bybit or OKX (excellent perpetual futures markets)

Altcoin strategies → KuCoin (widest selection of smaller-cap pairs)

US regulatory compliance → Coinbase Advanced or BinanceUS

Historical data quality → Binance (best data coverage)

Running Bots on Multiple Exchanges​

You can run bots on multiple exchanges simultaneously:

Bot 1: BTC/USDT RSI Strategy → Binance
Bot 2: ETH/USDT EMA Strategy → Bybit
Bot 3: SOL/USDT MACD Strategy → OKX

Each bot is completely independent — different exchange, different strategy, different runner. Manage them all from a single VolatiCloud dashboard.

Exchange API Key Best Practices​

1. Use sub-accounts — Create a dedicated trading sub-account, separate from your main holdings
2. Minimum permissions — Only grant Read + Trade; never grant Withdraw
3. IP whitelist — Restrict API access to VolatiCloud's IP addresses
4. Regular rotation — Rotate API keys every 90 days
5. Monitor usage — Review API key activity logs on your exchange regularly

Setting Up Your First Exchange​

1. Generate API keys on your exchange (follow the exchange-specific guide)
2. Navigate to Exchanges → Add Exchange in VolatiCloud
3. Select your exchange and enter your credentials
4. Test with a Dry Run bot first before going live

To connect your first exchange, navigate to Exchanges → Add Exchange in the console and follow the wizard. Generate API keys on your exchange first — see the exchange-specific guide linked in the wizard for the exact permission set to request.

Related guides​

• Exchanges Overview — API key setup, permissions, and security best practices.
• Supported Exchanges — Full list of supported exchanges with setup instructions.
• Creating a Bot — Use your exchange connection to launch an automated trading bot.