revolut-engineering/revolut-x-api/revx-strategy

Strategy: Grid Bot (revx strategy grid)

Backtest, optimize, and run automated grid trading strategies.

Auth required. Make sure revx is installed and configured before running these commands. If any command fails with an auth-related error — Auth not configured, No private key found, Authentication failed (401), Invalid signature, insecure permissions, or a missing key/config file at ~/.config/revolut-x/ — invoke the `revx-auth` skill immediately and apply the fix yourself. Do not interrupt the user to ask them to run setup. Only escalate to the user for steps only they can perform (pasting the API key, registering the public key in their Revolut X profile, choosing a passphrase). After the fix, retry the original command.

Symbols use BASE-QUOTE format with a dash: BTC-USD, ETH-EUR, SOL-USD.

Backtest

Test a grid strategy on historical data:

revx strategy grid backtest BTC-USD
revx strategy grid backtest BTC-USD --levels 10 --range 10 --investment 1000
revx strategy grid backtest ETH-USD --days 60 --interval 4h
revx strategy grid backtest BTC-USD --split
revx strategy grid backtest BTC-USD --trailing-up --stop-loss 85000
revx strategy grid backtest BTC-USD --json

Backtest engine assumptions : The engine runs on OHLC candles and has no access to intra-candle tick data. Order execution order within each candle is determined by the direction of the candle:

Limitation: real intra-candle price action may be more complex (e.g. multiple touches of high/low), which the backtest does not reproduce.

Backtests confirm trailing-up from a single qualifying candle high, once the grid holds no coins, and rebuild from that candle's close. Stop-loss also remains immediate because historical candles do not contain live tick sequences.

Not long-running — completes and returns results. Run normally via the Bash tool.

Always confirm these key parameters before running: pair, investment, levels, range, and split mode. These affect capital and strategy behavior — never assume them silently. Other parameters (days, interval) can use defaults unless the user specifies otherwise.

Optimize

Test multiple parameter combinations, ranked by return:

revx strategy grid optimize BTC-USD
revx strategy grid optimize BTC-USD --investment 5000 --days 60
revx strategy grid optimize BTC-USD --levels 5,10,15,20 --ranges 3,5,10 --top 5
revx strategy grid optimize BTC-USD --split
revx strategy grid optimize BTC-USD --trailing-up --stop-loss 85000

Max 200 parameter combinations. Every combination is validated before any backtest runs. If any combination violates pair constraints or stop-loss placement, the entire optimize command fails; invalid combinations are not skipped. Not long-running — completes and returns results.

Always confirm these key parameters before running: pair, investment, and split mode. These affect capital and strategy behavior — never assume them silently. Other parameters (levels list, ranges list, days, interval, top) can use defaults unless the user specifies otherwise.

Pair Constraints and Validation

Backtest, optimize, dry-run, and live run all build the same exchange-aware grid plan before execution:

• Grid prices are rounded to the pair's quote step and must remain strictly increasing and unique.
• Quote per level is floored to the quote step; base amounts are floored to the base step.
• Every order must satisfy the pair's minimum quote value and minimum/maximum base size.
• Split mode must fit the initial market buy and each allocated sell amount within the pair limits.
• Stop-loss must be strictly below the lowest aligned grid level, and its maximum liquidation size must not exceed the maximum base order size.

Invalid parameters fail before simulation or order placement. Optimize validates all requested combinations first and fails as a whole if any one is invalid. Increasing levels reduces capital per level, so a 100-level-per-side grid may require a larger investment than a smaller grid.

Run (Live Trading)

Human Confirmation Required

NEVER execute `revx strategy grid run` (without `--dry-run`) without explicit user confirmation. This command places real orders with real money.

Before running a live grid bot, present a confirmation summary to the user:

Grid bot to launch:

- Pair: BTC-USD

- Investment: $500

- Levels: 10 per side

- Range: +/-5%

- Mode: LIVE (real orders)

This will place real buy and sell orders. Shall I proceed?

Only execute after the user explicitly approves. --dry-run does not require confirmation (no real orders).

Always Suggest Dry Run First

When the user asks to run a live grid bot, always suggest starting with `--dry-run` before going live — unless the user has already completed a dry run in the current session or explicitly says they want to skip it.

Example response:

Before going live, I'd recommend a dry run first to verify the grid setup:

```bash

revx strategy grid run BTC-USD --investment 500 --levels 10 --range 5 --dry-run

```

This simulates the bot without placing real orders. Want to start with a dry run?

If the user confirms they want to skip the dry run, proceed to the live confirmation flow above.

Missing Parameters — Always Ask, Never Guess

The --investment flag is required by the CLI, but also confirm the user's intent for all key parameters:

1. Symbol — which pair?
2. Investment — how much capital?
3. Levels — how many grid levels per side? (default 5 if user says "use defaults")
4. Range — what percentage range? (default 5% if user says "use defaults")

If the user says "run a grid bot on BTC", ask for the investment amount at minimum.

Run a live grid bot with real-time dashboard:

revx strategy grid run BTC-USD --investment 500
revx strategy grid run BTC-USD --levels 10 --range 5 --investment 1000 --interval 15
revx strategy grid run BTC-USD --investment 500 --split
revx strategy grid run BTC-USD --investment 100 --dry-run
revx strategy grid run BTC-USD --investment 500 --reset
revx strategy grid run BTC-USD --investment 1000 --trailing-up --stop-loss 85000

Ctrl+C ends the grid: it cancels open orders, keeps the coins in the wallet and prints a summary. The next start begins a new grid. If an order isn't confirmed closed, the next start checks it first. A stop signal (kill, docker stop, a system shutdown) cancels the orders and keeps the grid while it holds coins or an order isn't confirmed. After that or a crash, the next start resumes it.

If an order can't be placed, for example because coins or cash were moved out of the account after a fill, the dashboard shows a line for it with the reason on every check until it goes out. Orders of one level waiting for the same reason share a line, and an order the bot sent but couldn't confirm shows as not confirmed yet. One that came back rejected shows as rejected or already placed while the bot looks for it. A sell the bot hasn't sent yet shows as not placed yet. A position still buying the rest of its amount shows as a buy with the amount left, before its sell. An order the exchange hasn't listed for a minute shows as not listed yet. The Open buy fills row shows what open buys have bought so far. Warnings about the current check, such as a rejected order, come first. Telegram gets one message for that order if it still isn't out at the end of the check, so a retry that works within the same check sends nothing. A sell is retried on every check unless its reply was lost. A buy is retried once a minute, as soon as there is cash for it. Neither sends further messages until that order was placed and later fails again. Buys skipped for lack of cash show as one line with how many wait, the free cash and the total they need. A level is refilled by the money it is missing, and the bot places what the free cash allows, starting with buys for the rest of a position. If the reply to a buy or sell is lost, the bot looks for its ID in the open orders on every check and in the order history once a minute, and tracks the order once it shows up. If two lookups miss it, the bot sends it again with the same ID. If the order already exists, the exchange answers that send as rejected or refuses it, and the bot keeps looking. If it turns out cancelled, the bot places it again at the same amount. One that only shows up as rejected is handled like a rejected grid order, described below. A rest too small to buy, described below, is not bought, and the position gets its sell. A buy for the rest that is cancelled, or that a stop signal cancels or keeps from being sent, is placed again for the same position. One whose reply was lost is looked up first, as above. With --split, the start-up size check counts the 0.09% fee the market buy pays in coins, so a grid at the exchange minimum is refused before it buys.