Fix-Cash Grid Bot — deploy and operate

On startup the bot calculates what position its formula implies, compares that to what your account actually holds, and then does nothing about the difference. It logs the gap and leaves the decision to you — deliberately, because automatic market orders on restart previously caused large unwanted trades.

Put plainly, the division of responsibility is this:

• You are responsible for: funding the account, deciding the grid boundaries and leverage, and establishing or adjusting any starting position you want the bot to work around.
• The bot is responsible for: placing limit orders at every grid level, cancelling and re-placing the grid after each fill, and pausing at the boundaries.
• Nobody is responsible for closing your position automatically — with one exception: if price falls below the lower boundary the bot closes the whole position at market and pauses.

1. A Deribit account with API key and secret, with trade and read permissions. Use test.deribit.com first.
2. A Redis instance the bot can reach. Redis holds the live configuration and the bot's order state, so it is not optional.
3. A licence: either a SUBSCRIPTION_UUID or a TBS_ACTIVATION_TOKEN. Setting both is a fatal error at startup. Internal fund deployments use DEPLOYMENT_MODE=k8s_fund instead, which skips licence enforcement.
4. Kubernetes access to the target namespace, if you are deploying to the cluster rather than running locally.
5. A decision about the starting position — see section 1. Deploying without having decided this is the most common way to waste a day.

Configuration comes from two places. Environment variables are fixed at startup and set identity and connections. The trading parameters live in Redis and are re-read while the bot runs, so they can be changed without a restart.

Environment variables — the ones that matter:

Trading parameters — stored in Redis under the key config:<BOT_ID>:grid:

Deployment runs through Jenkins pipelines held in the repository, split by environment. CI builds and pushes the image; CD deploys it.

.kubernetes/
├── pipeline/
│   ├── staging/      Jenkinsfile.ci  Jenkinsfile.cd
│   └── production/   Jenkinsfile.ci  Jenkinsfile.cd
│                     Jenkinsfile.onboard  Jenkinsfile.rollback
├── overlays/         staging/  production/
└── templates/        deployment.yaml  service.yaml  redis.yaml

The deployment is named grid-bot. Namespaces differ by environment and, in production, by client — confirm which namespace you are targeting before running anything.

# check what is actually running
kubectl get pods -n <namespace>
kubectl rollout status deployment/grid-bot -n <namespace>
kubectl logs -f deployment/grid-bot -n <namespace>

Check in this order. Each step rules out a different failure.

1. The pod is running and not restarting — kubectl get pods.
2. Trading is engaged — query /api/v1/status and read the engaged field. If it is false, not_engaged_reason tells you why: trade_disabled, exchange_auth_failed, or config_validation_failed.
3. The grid was placed — look for the log line “Initial grid orders placement complete”, which reports how many short and long orders were placed. This is the single best confirmation that the grid is live.
4. The orders exist on Deribit — confirm on the exchange or through fm-portal, not only in the logs. A log line says the bot tried; the order book says it succeeded.

Log lines that mean something is wrong, or at least worth understanding:

• “Price below lower boundary, waiting for price to enter grid zone” — the bot placed no orders at all and is waiting. Not a crash, but nothing is happening.
• “Skipping close orders — no existing short position to reduce” — expected on a flat account. The bot has placed sells only, which is exactly the behaviour described in section 1.
• “AUTO-STOP: next short order would push projected liq below upper boundary” — the liquidation guard stopped adding shorts. Investigate before overriding.
• “Position delta detected — manual adjustment may be needed” — the bot's target and your actual position disagree. It will not fix this for you.

Day-to-day observation happens in fm-portal, which shows the bot's status, config, grid orders and open position without needing cluster access. The portal is documented separately — see the fm-portal operator guide for the screen-by-screen walkthrough and for what each control does.

In a healthy bot the grid is not static. After each fill the bot cancels the grid and re-places it, logging “Grid refresh complete”. If the market has moved and the orders have not, that is your signal to investigate.

This is not an accident of configuration — the bot's shutdown path genuinely contains no order cancellation. On receiving a shutdown signal it stops its background work and disconnects the WebSocket. It never calls cancel-all, and Deribit's cancel-on-disconnect feature is not enabled. So stopping the process, deleting the pod, scaling to zero, or pressing stop in fm-portal all leave the same thing behind: live orders and live exposure.

To actually stop trading, do it in this order:

1. Pause the bot, so it stops re-placing the grid while you work.
2. Cancel the orders. Confirm on Deribit that the order book entries are gone — the request being accepted is not the same as the orders being cancelled.
3. Decide about the position. Closing it realises the profit or loss immediately. Keeping it means you now hold unmanaged exposure — that may be exactly what you want, but it must be a decision, not an oversight.
4. Only now stop or scale down the process.

• Check DERIBIT_TESTNET before every production deploy. It defaults to testnet, which is safe, but a copied config can flip it either way.
• Set the lower boundary knowing it triggers a market close of the entire position, not a pause.
• Do not raise leverage to make the numbers look better. Leverage is the variable that creates a liquidation price.
• Never assume a stopped bot is a flat account. Confirm on Deribit.
• For the live production fix-cash bot specifically: read-only inspection is fine, but any action requires explicit authorisation from the owner. Do not stop, scale, or reconfigure it on your own initiative.