DEV Community: Anh Phan

Inside the Money Flow in Centralized Exchanges: MPC + TEE at Work

Anh Phan — Fri, 25 Jul 2025 08:12:11 +0000

Have you ever wondered:

Where do my tokens go when I deposit them to a CEX?
Why do I always receive tokens from a Binance Hot Wallet instead of the one I deposited to?
What exactly are hot, warm, and cold wallets?

Let’s unwrap the secret flow of money inside centralized exchanges. You’ll also learn how technologies like MPC (Multi-Party Computation) and TEE (Trusted Execution Environment) silently power these systems behind the scenes.

References:

What are hot, warm and cold wallets?

Hot, warm, and cold wallets describe how exposed your keys are to the internet. Hot wallets are always online, fast and automated, but riskier. Cold wallets are fully offline, ultra-secure but slow. Warm wallets sit in between: connected, but require human approvals before signing. A serious setup uses all three, hot for withdrawals, warm for ops, cold for long-term reserves.

In short:

The colder the wallet, the safer the funds.
The hotter the wallet, the closer it is to the internet

Figure 1 - Wallet layers in a CEX system

Feature	Hot Wallet	Warm Wallet	Cold Wallet
Accessibility	Fully online	Online/semi-online	Fully offline
Speed	Real-time	Delayed	Manual (hours-days)
Security	Medium (MPC)	High (MPC/Multisig)	Max (air-gapped)
Transaction Volume	High	Medium	Very low
Balance Size	Small	Medium-large	Very large (reserves)
Automation Level	Full auto	Semi-auto	Manual
MPC Use	✅ Yes	✅ Yes / Some	❌ No

When it comes to handling billions in customer funds, major centralized exchanges don’t rely on a single wallet type. Instead, they deploy a tiered wallet system: hot, warm, and cold with each serving a distinct role in balancing speed, security, and operational control. Hot wallets power real-time deposits and withdrawals. Warm wallets act as secure liquidity buffers. And cold wallets serve as deep storage vaults, often air-gapped and heavily restricted.

But hardware separation alone isn’t enough. Today’s top-tier CEXs layer in Multi-Party Computation (MPC) to split key control across distributed nodes, and Trusted Execution Environments (TEE) to guarantee secure signing inside isolated memory. This combination allows exchanges to automate flows like deposit crediting or hot wallet refills while maintaining strong safeguards against internal compromise, external exploits, or key leakage.

Now let’s walk through how funds actually move through this system from the second a deposit hits the chain to how withdrawals are routed securely.

Deposit Flow

Figure 2 - Deposit flow in a CEX system

The process works as follows:

Users deposit tokens onchain to the User Deposit Wallet, which is an HD (Hierarchical Deterministic) wallet derived from a single master seed securely stored in CloudHSM. This approach allows the CEX to manage millions of user addresses scalably and efficiently without exposing private keys. (user1DepositAddress = hdWallet.drivePath("m/44'/60'/0'/0/0"")
Sweep Engine monitors the blockchain in real time to detect a deposit transaction to that specific User Deposit Wallet, then initiates a signing request to the Signer to sweep the full balance.
Sweep Engine validates against multiple Decision Engines, including:

- Rule Engine: Enforces business logic and platform configuration — e.g., token paused status, minimum sweep size, whitelisted destination addresses, and deposit wallet-to-user mapping.

- Risk Engine: Identifies fraud or abuse patterns — e.g., flagged wallets (via Chainalysis/TRM), high-frequency or high-value deposits, interactions with mixers, or connections to known exploiters.

- Compliance / Sanctions Engine: Ensures compliance with global regulations — e.g., blocking OFAC-listed addresses, embargoed jurisdictions, or triggering AML thresholds.

- Balance Reconciliation Engine: Verifies state consistency — e.g., deposit properly recorded in internal DB, current hot wallet balance aligns with expectations, and prevents duplicate sweeps.

- Fee Estimator / Gas Oracle: Optimizes transaction fees — e.g., evaluating current base fee, fee spike protection, checking native token balance for gas sufficiency.

- Capacity & Health Engine: Ensures operational readiness — e.g., confirming the hot wallet is not overloaded, no stuck or pending transactions, and all underlying blockchain nodes are healthy.
Once all rule checks pass, the Sweep Engine sends a request to the Signer: “Hey Signer, I have a transaction from wallet 0x4eaf...g14d and it passed all validations. Please help me sign it."
Signer runs in a Trusted Execution Environment (TEE), securely loads the private key (via CloudHSM), and performs the signing operation within an isolated, tamper-proof enclave.
The signed transaction is returned to the Sweep Engine, which then broadcasts it to the blockchain network.
Funds are now swept into the Hot Wallet (MPC-powered). This wallet is connected to critical services but kept isolated via MPC to reduce exposure and avoid single-point key compromise.
If the Hot Wallet balance exceeds a defined threshold, the system automatically triggers a transfer to the Warm Wallet. The Warm Wallet uses MPC as well, but includes human approval gates, typically signers like the CEO, CTO, and CFO.
Once all designated human signers approve the transfer, funds are moved to the Cold Wallet (e.g., Ledger hardware wallet), which remains completely offline and air-gapped.

Withdraw flow

Figure 3 - Withdraw flow in a CEX system

User Request Flow

The user kicks off a withdrawal request from the frontend.
That request hits the CEX Backend, which immediately validates against Decision Engines (risk checks, velocity rules, balance logic, etc.).
If everything passes, the transaction goes into a TX queue, where it’s grouped with others for gas saving.
Once ready, the batch is submitted to the Hot Wallet (MPC).
The Hot Wallet signs and sends funds straight to the user’s Destination Wallet.

Hot Wallet Refill Flow

Behind the scenes, a balance watcher keeps an eye on hot wallet liquidity.
If the balance dips too low, the system automatically triggers a refill.
The Signer Group gets notified.
They review and sign the refill request.
Funds flow in from the Warm Wallet (MPC with human approvals) to top up the hot wallet.

Warm Wallet Refill Flow

Meanwhile, a separate process keeps monitoring the Warm Wallet’s balance.
When it gets low, an automated refill request is raised to the Operator Group.
This step is highly manual by design. A multi-person operation on a secure workstation approves the refill using hardware wallets.
Once cleared, the funds move from the Cold Wallet (Ledger) into the Warm Wallet.

Major exchanges rely on a multi-tier wallet setup: hot, warm, and cold to balance speed and security. At the heart of this system, MPC ensures no single party ever holds the full private key, while TEE secures signing operations in isolated hardware. Together, they protect billions in assets against both internal threats and external attacks.

💡

*About Us*

At *Fystack*, we provide a self-hosted MPC infrastructure designed for teams building secure, scalable Centralized Exchanges (CEXs) and stablecoin infrastructure. Plug it into your existing stack and stay in control, no vendor lock-in, no compromises.

👉 Contact us at *fystack.io* for self-hosted MPC wallet infrastructure or try Fystack for free now!

DEK-KEK the industry standard to protect highly sensitive data (Part 1)

Anh Phan — Wed, 23 Jul 2025 07:46:10 +0000

(Part 1 - Foundational concepts)
Read the original post over here Fystack Blog

DEK-KEK is a hybrid encryption approach designed to balance security, performance, and operational simplicity. It’s widely adopted by institutional enterprises, think banks, insurance companies, and crypto exchanges where centralized servers must store extremely sensitive data such as PII (Personally Identifiable Information), crypto private keys, or MPC keyshares.

References and industry examples:

Let's get started by some foundational concepts, industry standards for data protection and how Fystack makes technical decisions and apply them on Part 2 (coming soon)

Encryption Models in Play

1. Symmetric Encryption

A single private key is used for both encryption and decryption.

Pros:

Simple and fast.
Low computational cost.
Standardized algorithms (e.g., AES).

Cons:

Key sharing is risky.
Key compromise breaks security.
No non-repudiation.

Use Cases:

Data-at-rest encryption (e.g., database fields, file storage, backups).
Data-in-transit encryption when combined with key exchange protocols (e.g., TLS session keys).
Disk encryption (BitLocker, LUKS) or cloud storage encryption (AWS S3 SSE).
Bulk data transfer, due to its speed and efficiency.

Figure 1.1 - Symmetric encryption/decryption model

AES-GCM-256 is chosen as the core algorithm for symmetric encryption/decryption. It ensures both confidentiality (data is unreadable without the key) and integrity (detects any tampering with the ciphertext).

💡

Why AES-GCM-256?

AES (Advanced Encryption Standard) is a proven symmetric encryption algorithm trusted worldwide. The GCM (Galois/Counter Mode) variant adds authenticated encryption, meaning it not only encrypts data but also verifies its integrity. AES-GCM-256 is favored because it is:

- Fast and hardware-accelerated on most modern CPUs.

- Widely audited and trusted, meeting banking and government security standards.

- Resistant to common cryptographic attacks, making it the default choice for enterprise-grade encryption.

AES-GCM-256 Encryption Process

Input:

Plaintext ([]byte) – Raw data to be encrypted (e.g., JSON, string, binary).
DEK ([]byte) – 32-byte Data Encryption Key used by AES-256-GCM.

Output:

Nonce (string) – Base64-encoded 12-byte random nonce required for decryption.
Ciphertext (string) – Base64-encoded encrypted data, which includes the GCM authentication tag.

Figure 1.2 - AES-GCM-256 encryption architectural diagram

AES-GCM-256 Decryption Process

Input:

Ciphertext (string) – Base64-encoded ciphertext as stored in the database.
Nonce (string) – Base64-encoded nonce generated during encryption.
DEK ([]byte) – 32-byte Data Encryption Key used for decryption.

Output:

Plaintext ([]byte) – The original decrypted raw data (convert to string with string(plaintext) if needed).

Figure 1.3 - AES-GCM-256 decryption architectural diagram

2. Asymmetric Encryption

Uses a pair of keys:

A public key for encryption (or signature verification).
A private key for decryption (or signing).

Figure 1.4 Asymmetric encryption/decryption model

Pros:

No shared private keys.
Supports digital signatures.
Good for secure key exchange.

Cons:

Slower and resource-heavy.
Larger key sizes.
Complex key management.

Use cases:

Key exchange protocols (e.g., TLS handshake to establish symmetric session keys).
Digital signatures and certificate-based authentication (e.g., SSL certificates, JWT signing).
Cryptocurrency wallets (e.g., signing transactions with private keys).

Intuitive approach

Let's start from the most common table in every system User, the primary key is user_id and a sensitive otp_secret, others are omitted for the sake of simplicity.

Figure 1.5 - Intuitive approach to protect data at-rest

Imagine a disaster strikes when no engineers are around — say, during the holidays. The database gets compromised, and the attacker gains access to all users' OTP secrets in plaintext, effectively bypassing 2FA protection to launch further attacks.

A robust protection mechanism for data at rest is essential. Even in the worst-case scenario, the attacker should only see encrypted data, rendering it useless for further exploitation. To achieve this, an encryption key is introduced as the core defense.

Figure 1.6 - enhanced approach to protect data at-rest

The encryption key can be either a symmetric or asymmetric key and is often managed by cloud provider serverless services (AWS KMS, GCP KMS, Azure Key Vault). When a user query is made, the backend service will load encrypted fields from database, call to Key Management Service (KMS) to decrypt it then return result to client. However this approach still comes with some disadvantages:

The encryption key becomes the single point of compromise.
Huge operational efforts on rotating encryption key (including re-encrypt every row in database).

That is where DEK-KEK model was born and becomes the industry standard.

What are DEK and KEK?

DEK (Data Encryption Key): A symmetric key used directly to encrypt and decrypt data.
KEK (Key Encryption Key): A key (often asymmetric) used to encrypt DEKs, protecting them from being compromised while at rest.

By layering encryption like this, KEKs safeguard DEKs, while DEKs efficiently handle the encryption of large volumes of data.

💡

*DEK vs. KEK Lifecycle

DEK: stored at-rest with encryption, loaded into memory (plaintext) when the backend service boots up and is securely wiped from memory when the server shuts down.
KEK: managed by cloud providers, with backend access restricted by Role-Based Access Control (RBAC)*

Figure 1.7 - DEK-KEK practical implementation

The diagram illustrates how the DEK-KEK encryption model works in a real-world system. At the top of the hierarchy is the Key Encryption Key (KEK), usually stored and managed by a secure service such as AWS KMS, Azure Key Vault, or GCP Cloud KMS. The KEK never encrypts user data directly. Instead, it’s responsible for protecting another key — the Data Encryption Key (DEK) — which is used for actual data encryption and decryption.

The process works as follows:

A DEK (symmetric key) is generated and then immediately encrypted with the KEK. The encrypted version of the DEK is stored in the database, represented by the encrypted_dek column (base64-encoded).
When the application needs to perform encryption or decryption, it retrieves the encrypted DEK, has it decrypted by the KEK, and loads the plain DEK into memory.
The DEK, which is much faster for bulk operations, handles the encryption and decryption of sensitive data such as the otp_secret field.

This model provides a strong balance between security and performance:

The KEK remains protected in a hardened key management service or hardware security module. It follows the strict principle that the key's plaintext version never leaves the service, ensuring that no user, system or process can directly access or view it.
The DEK, while briefly present in memory, is never stored in plaintext at rest. The memory can be further protected at both the software and hardware layers, for example, using AWS Nitro Enclaves as the Trusted Execution Environment (TEE).
Symmetric encryption ensures fast operations without frequent, costly calls to KMS.

Moreover, this model significantly reduces operational effort required when it is time to rotate the KEK. The entire database remains unchanged. The DEK is re-encrypted in memory by the new KEK then stored back to the database. Simple, secure and efficient!

- To be continued -

In Part 2, we’ll share how Fystack adopted this model to strengthen our MPC wallet infrastructure, the challenges we faced, and the key technical decisions behind it. Stay tuned!

💡

At Fystack, we provide self-hosted MPC wallet infrastructure designed for teams that value security, control, and flexibility.

👉 Contact us at *fystack.io* for self-hosted MPC wallet infrastructure or try Fystack for free now!