How We Encrypt Your Exchange API Keys: Envelope Encryption Explained

Before you connect any automation tool to your exchange account, it's worth asking a question most vendors hope you won't: how do trading bots store API keys? The honest answer across the industry ranges from a plain-text column in a database to hardware-backed envelope encryption — and from the outside, both look identical. Your key works either way. The difference only shows up on the worst day, when a server is breached or a database backup leaks. This post explains how envelope encryption works, why it's the standard we chose at SignalToExchange, and what to ask any tool that wants your keys.

Why key storage is the real risk

An exchange API key lets software act on your account. Even a properly scoped trade-only key — one that can place orders but never withdraw — is a credential worth protecting: if it leaks, someone can fire unwanted orders against your balance until you revoke it.

Most coverage of API key safety focuses on permissions, and that's the right first step. But permissions only bound the damage of a leak. Storage determines how likely a leak is in the first place. A tool that holds thousands of users' keys in plain text is a single breach away from exposing every one of them at once. That concentration of risk is exactly what good encryption design exists to break up.

What envelope encryption is

Envelope encryption uses two layers of keys instead of one:

• A data encryption key (DEK) — a unique key that encrypts one piece of data, in our case a single exchange credential.
• A key encryption key (KEK) — a master key, held inside a cloud Key Management Service (KMS), whose only job is to encrypt and decrypt DEKs.

The crucial property: the KEK never leaves the KMS. It lives inside hardened, audited infrastructure (often a hardware security module), and the application can only ask the KMS to wrap or unwrap a DEK — it can never read the master key itself.

The flow, step by step

1. When you add an exchange credential, a fresh DEK is generated for it.
2. Your API key and secret are encrypted with that DEK using authenticated encryption (AES-256-GCM).
3. The DEK is sent to the KMS, which encrypts ("wraps") it with the KEK.
4. The encrypted credential and the wrapped DEK are stored together; the plain-text DEK is discarded immediately.
5. When an order needs signing, the worker asks the KMS to unwrap the DEK, decrypts the credential in memory, signs the request, and discards the plain-text material again.

At rest, the database holds only ciphertext and wrapped keys. Nothing in it can be read without the KMS agreeing to participate.

Why this beats a single master key

A simpler design — one encryption key in the application's configuration — is better than plain text, but it has a fatal flaw: anyone who obtains both the database and that one key can decrypt everything. Keys in config files get copied into backups, CI logs, and developer laptops.

Envelope encryption changes the math in three ways:

• Per-credential keys. Every credential has its own DEK, so there is no single key that unlocks the whole table.
• The master key is unstealable in the ordinary sense. The KEK can't be copied out of the KMS — an attacker would need ongoing, authenticated access to the KMS itself, which is exactly what IAM policies and audit logs are built to detect and cut off.
• Every decryption leaves a trail. KMS access is logged, so unusual unwrap activity is visible, and the KEK can be rotated or disabled instantly — a kill switch on the provider side that complements the one you hold at the exchange.

How SignalToExchange applies it

When you connect an exchange to SignalToExchange, your credential is envelope-encrypted exactly as described above: a unique DEK per credential, wrapped by a KEK in a cloud KMS. Decryption happens only in the memory of the order-dispatch worker, at the moment a signal becomes an order that needs signing. Keys are never written to logs, never sent to your browser, and never stored in plain text anywhere.

Encryption is one layer of a deliberately non-custodial design. Your funds never leave your exchange — we connect with trade-only keys, so the platform places orders and can never withdraw. Even in a worst-case scenario, the blast radius is bounded by the permissions you granted, and you can revoke the key from your exchange dashboard at any time. For the fuller picture of what can and can't go wrong, see our guide on whether it's safe to give a trading bot your API keys.

What to ask any tool before you connect

• How are keys stored at rest? The answer you want is envelope encryption with a KMS-managed master key — not "encrypted" with no specifics, and never plain text.
• Where does decryption happen? In server memory at the moment of use, not in the browser or in logs.
• Does the tool accept trade-only keys? If it insists on withdrawal permission, walk away.
• Can you restrict the key by IP? Use your exchange's allow-list if the tool publishes its outbound IPs.
• Use one key per tool and rotate periodically so revoking one service never disrupts another.

Security you can verify, not just trust

You shouldn't have to take a vendor's word for it. Scoped permissions are enforced by your exchange; encryption design is something a serious provider should be willing to explain in detail — which is exactly why this post exists. If you want a non-custodial execution layer that treats your API keys as the critical secrets they are, Request access / start your free trial →

Automated trading involves risk. SignalToExchange is execution infrastructure and does not provide financial advice, trading signals, or guarantees of any kind.