Zero-Knowledge Architecture: How Signal-Push Trading Bots Work

In the world of crypto trading bots, there is a fundamental question about zero-knowledge security most traders never think to ask: "Where are my exchange credentials stored, and who has access to them?" The answer to this question determines whether your funds are protected by cryptographic guarantees or exposed to a single server breach.

Most trading bot platforms operate on a custodial model where your API keys are stored on their servers. If those servers are compromised, every user's keys are exposed. This is not a theoretical risk. It happened with 3Commas in 2022, resulting in millions of dollars in losses. Zero-knowledge security architecture eliminates this attack vector entirely.

This guide explains how zero-knowledge signal-push trading bots work, why they are fundamentally more secure, and what trade-offs are involved.

What Is Zero-Knowledge in Trading?

In cryptography, "zero-knowledge" refers to systems where one party can prove something to another without revealing the underlying information. In the context of trading bots, zero-knowledge means:

The bot platform never knows your exchange API keys.

It never stores them. It never transmits them. It never has access to them at any point. Your keys exist only on your local machine, encrypted at rest, and are only decrypted momentarily when executing a trade.

This is fundamentally different from the traditional model where you paste your API keys into a web dashboard and the platform stores them (hopefully encrypted) on their servers.

The Trust Problem

Traditional trading bot platforms ask you to trust:

1. Their server security (no breaches)
2. Their employee access controls (no insider threats)
3. Their encryption implementation (no vulnerabilities)
4. Their data handling practices (no logging of decrypted keys)
5. Their third-party dependencies (no supply chain attacks)

That is a lot of trust. A single failure in any of these layers can expose your keys. The history of crypto is littered with platforms that were trusted and then breached.

Zero-knowledge architecture removes points 1-5 entirely. There is nothing to breach because the platform never has your keys. For more context on why this matters, read about the 3Commas hack and what it revealed about custodial key storage.

Signal-Push vs Server-Side Execution

To understand zero-knowledge trading bots, you need to understand the two fundamental architectures for automated trading.

Server-Side Execution (Traditional)

In the server-side model:

1. You create API keys on your exchange
2. You paste them into the bot platform's web interface
3. The platform stores your keys on their servers
4. When a trade signal fires, the platform's server uses your keys to place orders directly on the exchange
5. All execution happens server-side; you just see the results

Advantages: Simple setup, no local software needed, works from any device.

Disadvantages: Your keys are a honeypot on someone else's server. One breach exposes all users.

Signal-Push Execution (Zero-Knowledge)

In the signal-push model used by Sentinel Bot:

1. You create API keys on your exchange
2. You enter them into the Sentinel client running on your machine (desktop app or self-hosted Docker node)
3. Keys are encrypted locally and never sent to Sentinel's servers
4. Sentinel's server generates trading signals based on your strategy
5. Signals are pushed to your local client via WebSocket
6. Your local client receives the signal, decrypts your keys, and executes the trade directly on the exchange
7. Sentinel's server never touches your exchange, never sees your keys, never places orders

Advantages: Keys never leave your control. Platform breach cannot compromise your funds.

Disadvantages: Requires running local software (desktop app or Docker container). Your local machine must be online for trades to execute.

Technical Deep Dive: How Signal-Push Works

Let us trace the complete lifecycle of a trade in a zero-knowledge signal-push system.

1. Strategy Evaluation (Server-Side)

Sentinel's server continuously evaluates your configured trading strategies against real-time market data:

• Price feeds from multiple exchanges via CCXT
• Indicator calculations (RSI, MACD, Bollinger Bands, etc.)
• Block-based strategy logic evaluation (AND/OR/N-of-M composites)
• Signal generation when entry or exit conditions are met

This happens entirely with market data. No user credentials are involved.

2. Signal Generation

When a strategy condition is met, the server generates a trading signal. The signal contains:

{
  "type": "signal",
  "data": {
    "bot_id": "bot_12345",
    "action": "BUY",
    "symbol": "BTC/USDT",
    "quantity": 0.05,
    "order_type": "LIMIT",
    "price": 62450.00,
    "leverage": 5,
    "stop_loss": 61000.00,
    "take_profit": 65000.00,
    "timestamp": "2026-03-10T14:30:00Z"
  },
  "signature": "<HMAC signature>"
}

Notice what the signal does NOT contain: API keys, exchange credentials, or any user secrets. It is purely an instruction: "Buy 0.05 BTC at $62,450."

3. WebSocket Delivery

The signal is delivered to your local client via a secure WebSocket connection:

• Connection authenticated with your Sentinel JWT (Firebase Auth)
• User-specific room: user:{uid}:signals
• TLS encrypted in transit
• Signal includes HMAC signature to prevent tampering

The client verifies the signal's authenticity by checking the HMAC signature and the timestamp (rejecting signals older than 60 seconds to prevent replay attacks).

4. Local Execution (Client-Side)

Your local Sentinel client (Electron desktop app or Docker Cloud Node) receives the signal and:

1. Validates the signal signature and timestamp
2. Checks circuit breaker status (safety limits)
3. Decrypts your locally stored API keys
4. Constructs the exchange API request
5. Signs the request with your API secret
6. Sends the order directly to the exchange
7. Reports execution result back to Sentinel (success/failure, fill price, etc.)

The exchange API request goes directly from your machine to the exchange. Sentinel's server is never in the data path between your keys and the exchange.

5. Execution Reporting

After the trade executes (or fails), the client reports the result back to Sentinel's server for tracking purposes. This report includes the fill price, quantity, and status but never includes your API credentials.

You can verify this by monitoring network traffic from the Sentinel client. The only outbound connections are:

• WebSocket to Sentinel (receiving signals, sending execution reports)
• HTTPS to your exchange (executing trades)

Why Zero-Knowledge Matters for Security

The security benefits of zero-knowledge architecture are structural, not just procedural.

Server Breach Protection

If Sentinel's servers were compromised (hypothetically), an attacker would find:

• User accounts and strategy configurations
• Trading history and performance data
• No API keys, no exchange credentials, no ability to trade on behalf of users

Compare this to a custodial platform breach where attackers obtain API keys for every user and can immediately drain accounts.

Insider Threat Elimination

Even Sentinel's own engineers cannot access your exchange credentials because the credentials never exist on Sentinel's infrastructure. There is no database to query, no encryption key to misuse, no log file to grep. The keys simply are not there.

Supply Chain Attack Resistance

If a compromised dependency were injected into Sentinel's server-side code, it could not exfiltrate API keys because the server does not have them. The attack surface for key theft is limited to the client application on your local machine, which you control.

Regulatory Compliance

Zero-knowledge architecture simplifies regulatory compliance because the platform does not hold customer exchange credentials. This reduces the platform's custodial obligations and liability exposure.

How Sentinel Implements Zero-Knowledge

Sentinel Bot's zero-knowledge implementation has several key components:

Electron Desktop Client

The primary client is an Electron desktop application that runs on Windows. It stores your API keys encrypted on your local filesystem, connects to Sentinel's server via WebSocket for signals, and executes trades via direct exchange API calls.

Cloud Node (Docker)

For users who want 24/7 execution without keeping a desktop running, Sentinel offers a self-hosted Docker container (Cloud Node). You deploy it on your own VPS with your own API keys configured as environment variables. The keys never leave your VPS.

Leverage and Margin Support

The client handles leverage configuration locally, calling the exchange's setMarginMode and setLeverage APIs directly. Even margin mode and leverage settings are managed client-side.

Circuit Breaker

A server-side circuit breaker can emergency-pause trading if anomalies are detected. This is the one case where the server can influence trading behavior, but it can only stop trading, never initiate it. It sends a "stop" signal; it cannot place orders.

Limitations and Tradeoffs

Zero-knowledge architecture is not without trade-offs. Understanding these is important for making an informed decision.

Requires Local Software

You must run either the Electron desktop client or the Docker Cloud Node. Unlike purely web-based platforms, you cannot just log into a website and have trades execute. Your machine must be online and running the client.

Mitigation: The Cloud Node Docker container can run on a $5/month VPS with 24/7 uptime, effectively solving the availability problem.

Execution Latency

Signal-push adds a small latency compared to server-side execution. The signal must travel from Sentinel's server to your client, then your client must execute on the exchange. This adds approximately 50-200ms depending on network conditions.

Impact: For most strategies (swing trading, 1h+ timeframes), this latency is negligible. For high-frequency scalping on 1-minute candles, it could matter. Sentinel's strategies are designed for timeframes where this latency is not a factor.

Local Machine Security

While your keys are safe from server-side attacks, they are only as secure as your local machine. If your computer is compromised by malware, an attacker could potentially access your locally stored keys.

Mitigation: Use a dedicated machine or VPS for trading. Keep your OS updated. Use antivirus software. Enable disk encryption. These are the same precautions you should take for any financial application.

Offline Means No Trading

If your client goes offline (computer shuts down, internet outage, Docker container crashes), signals will be missed. Unlike server-side platforms that execute regardless of your local state, signal-push requires your client to be running.

Mitigation: Cloud Node on a VPS with auto-restart (restart: unless-stopped in Docker Compose). VPS providers offer 99.9%+ uptime SLAs.

Cannot Verify Execution Before It Happens

Since the server pushes signals and the client executes autonomously, you cannot manually approve each trade in real-time (unless you configure the client to require confirmation, which defeats the automation purpose).

Mitigation: Use comprehensive backtesting to validate your strategy before deploying it live. Set appropriate position sizes and stop-losses. Use the circuit breaker for emergency stops.

Frequently Asked Questions

How is zero-knowledge different from just using read-only API keys?

Read-only API keys prevent trading entirely. Zero-knowledge is about who has access to your trade-enabled keys. With zero-knowledge, you use full trade-enabled keys but they stay on your local machine. The bot platform never has access to them, yet trading still happens automatically through the signal-push mechanism.

Can Sentinel Bot place trades without my client running?

No. If your Sentinel client (desktop or Cloud Node) is offline, signals from the server are not executed. This is by design: the platform has no ability to interact with your exchange directly. It can only send signals to your running client. For 24/7 operation, use the Cloud Node on a VPS.

What happens if Sentinel's server goes down?

If Sentinel's server goes down, no new signals are generated or delivered. Your existing open positions remain on the exchange with their stop-loss and take-profit orders (which were placed as exchange orders, not dependent on Sentinel). You can always manage positions manually through your exchange's interface.

Is signal-push architecture truly zero-knowledge in the cryptographic sense?

Strictly speaking, "zero-knowledge" in cryptography refers to zero-knowledge proofs (ZKPs), which is a specific mathematical concept. Sentinel's use of "zero-knowledge" means the platform has zero knowledge of your exchange credentials. This is a practical security architecture, not a cryptographic proof system. The term is used in the industry to describe platforms that do not store user secrets.

Protect your crypto with architecture designed for security from the ground up. Create a free Sentinel Bot account and experience zero-knowledge trading where your API keys never leave your machine.

Disclaimer: This article is for educational purposes only and does not constitute financial advice. No security architecture eliminates all risk. Cryptocurrency trading involves significant risk of loss. Always do your own research and use appropriate security measures.