How It Works

plutarc is split into three layers: the dashboard (where you configure strategies and monitor performance), the backend (which stores your data, manages billing, and coordinates deployments), and the bot (a dedicated compute instance that connects to your exchange and executes trades).

When you deploy a bot, the backend provisions a dedicated instance in your chosen region. The bot process starts, decrypts your API key, connects to the exchange via WebSocket and REST, and begins evaluating your strategy on every new candle.

The platform follows a continuous loop from market data to trade execution to performance tracking:

1. Market data ingestion — The bot subscribes to real-time candlestick, orderbook, and trade streams from the exchange via WebSocket. It also polls REST endpoints for account state (balances, positions, open orders).
2. Signal evaluation — On each new candle close, the bot evaluates all enabled strategy components. Indicators are computed from the candle history, and each component produces its output (signal score, filter pass/fail, guard check, or exit trigger).
3. Combination & decision — Signal scores are combined according to the template's combination mode. Filters and entry guards must pass. If the combined score exceeds the threshold and the current time falls within an active trading session, the bot proceeds to entry.
4. Order execution — The bot places orders on the exchange via REST API. It tracks fills, manages position state, and applies exit rules on every subsequent candle until the position is closed.
5. Reporting — Completed trades, equity snapshots, signal states, and bot events are written back to the backend. The dashboard queries this data in real time to display KPIs, analytics, and activity feeds.

Each bot maintains two types of connections to the exchange:

The bot maintains an internal model of all open positions, synchronised with the exchange through both WebSocket updates and periodic REST reconciliation. This dual approach ensures accuracy even if individual WebSocket messages are missed during network interruptions.

Position data — including side, size, entry price, unrealised PnL, and leverage — is written to the backend and displayed in the dashboard's Open Positions table. When a position is closed, the bot records the complete trade with entry/exit prices, fees, hold duration, signal state at entry, and MFE/MAE excursion metrics.

When deploying a bot, you choose a deployment region and provider. Regions closer to the exchange's matching engine result in lower order latency. Vultr and AWS regions in Tokyo and Singapore offer the lowest latency to major exchange matching engines.

Exchange Matching Engine Locations

Supported exchanges host their matching engines in different regions:

• BitMEX — Tokyo
• Bybit — Singapore
• Binance — Tokyo
• Kraken — London

Datacenter locations are based on publicly available information and may change without notice.

Live Region Latency

Approximate round-trip time from each deployment region to exchange API servers, measured periodically by probes in each datacenter.

Green (<50ms) = same geographic area as matching engine. Amber (50–150ms) = adjacent region. Red (>150ms) = cross-continental.

For strategies that operate on longer timeframes (1h, 4h, 1d), region choice has minimal impact. For shorter timeframes (1m, 5m), deploying closer to the exchange can reduce slippage on entries and exits.

Bots follow a defined lifecycle from deployment to teardown:

1. Provisioning — A dedicated compute instance is created in the selected region.
2. Deploying — The bot process is installed and configured with your strategy template and encrypted API key.
3. Online — The bot connects to the exchange and begins evaluating your strategy. It sends periodic heartbeats to confirm it is operational.
4. Paused (optional) — The bot stops opening new positions but continues receiving market data and managing existing positions. Exit rules remain active.
5. Stopped — The compute instance has been deprovisioned. No residual data remains on the instance. Your configuration, trades, and analytics are preserved in the backend.

The dashboard shows the current lifecycle state for each bot along with connection status, uptime, and the full deployment history.

Bots are inherently stateless. They hold no persistent local state and cannot function without a configuration supplied by the backend. All strategy templates, risk limits, API key references, and runtime parameters live exclusively in the plutarc backend — the bot is a pure execution layer.

Real-Time Configuration Subscription

On startup, each bot subscribes to its own configuration via a real-time reactive query over a persistent WebSocket connection to the backend. When you change a setting in the dashboard — pause the bot, adjust a risk limit, or swap the strategy template — the update propagates to the running bot within milliseconds, with no restart or redeployment required.

Local Cache for Resilience

The bot maintains a local cache of its last-known configuration. If the WebSocket connection to the backend is briefly interrupted — due to a network hiccup or transient backend maintenance — the bot continues operating against the cached configuration until connectivity is restored and the subscription resumes.

What This Means in Practice

• No orphaned state — stopping a bot leaves nothing behind on the instance. Your configuration, trade history, and analytics are safe in the backend.
• Instant config updates — changes made in the dashboard reach the bot in real time without downtime.
• Network resilience — transient connectivity issues do not halt trading; the bot falls back to its cached configuration until the connection recovers.