This thesis studies asset security on centralized exchanges (CEXs)
Is a centralized exchange (CEX) truly secure if breaching one layer of security could compromise the entire system? Asset security isn't simply about protecting private keys, cold wallets, or multi-signatures; it must be designed to survive an attack.
INSIGHTS
10/5/202611 min read
This thesis studies asset security on centralized exchanges (CEXs)
Is a centralized exchange (CEX) truly secure if breaching one layer of security could compromise the entire system? Asset security isn't simply about protecting private keys, cold wallets, or multi-signatures; it must be designed to survive an attack.
Research • October 5, 2026
Is a centralized exchange (CEX) truly secure if breaching one layer of security can compromise the entire system? Asset security isn't simply about protecting private keys, cold wallets, or multi-layer signatures; it must be designed to survive an attack. This research proposes a CEX Survivability Architecture model with nine pillars, incorporating Artificial Intelligence (AI), Multi-Layer Processing (MPC), Zero Key Protection (ZK-Proof), Dynamic Time Locking, Persistent Authentication, Threat Hunting, and automated isolation mechanisms, all geared towards one goal: not to never be attacked, but to survive even when attacked.
Therefore, following the two major incidents at Bybit in 2025 and Bitget in 2026, the security of centralized exchanges is no longer just a matter of "how to protect private keys?". These recent incidents highlight a more crucial reality: a CEX may maintain multi-layer signatures, cold wallets, HSMs, hot/warm/cold wallet separation, and risk control systems, but assets can still be stolen if an attacker controls a link preceding or alongside the transaction signing layer. These two incidents employed different attack methods, but they both point to the same structural weakness: the security boundary of a centralized exchange (CEX) no longer lies solely in the digital wallet. That boundary stretches from the development environment → third-party vendors → cloud infrastructure → identity and authentication information → APIs/backend software → risk assessment tools → transaction signing → e-wallets → blockchain. If just one link is compromised, an attacker can attempt to transform illegal activity into a transaction recognized as valid by the system.
This is why the "shot down" problem is particularly important to CEX's security architecture. In Abraham Wald's study of the survival bias, analysis of returning aircraft showed that armor should be reinforced in areas where the aircraft survived being hit, rather than simply reinforcing the areas that were hit the most. Applied to CEX, the question shouldn't be "where do hackers typically attack?", but rather "if hackers have breached one layer of security, what next layer of security is likely to prevent the complete loss of assets?". This is CEX's new security problem.
The traditional security architecture of CEX is primarily built on a preventative security mindset: preventing attacker intrusions, protecting private keys, using multiple signatures, distributed accounts, HSM, firewalls, MFA, KYC, monitoring, and anomaly detection systems. These remain essential layers of security, but Bybit and Bitget demonstrate that none can be considered completely secure.
The key difference lies in the word "survival." A secure CEX system isn't necessarily one that's never compromised. A truly resilient system must be designed so that even if one or more layers are breached, the attacker cannot immediately translate that access into complete control of the exchange's assets. A nine-pillar model of CEX survivability and multi-dimensional defense is proposed to model the entire process from operation to security:
Minh Huy
Founder HCCVenture
The nine-pillar model is built on one core principle: don't assume any security layer is absolutely secure. Following incidents like Bybit and Bitget, risks to CEX assets no longer stem solely from stolen private keys but can originate from transaction signing interfaces, internal credentials, third-party software, software supply chains, CI/CD systems, administrative privileges, or even the withdrawal approval logic itself. Therefore, security architecture needs to shift from a "prevent all attacks" mindset to "limit the potential for a local intrusion to become a system-wide asset loss incident." The proposed model comprises three main layers: the Runtime Plane, directly protecting the withdrawal and asset flow processes; the Platform Plane, protecting software, identity, and technology supply chains; and the Response Plane, ensuring the ability to detect, isolate, investigate, and recover when incidents occur.
Pillar 1 - Wallet Tiering: Asset stratification and Blast Radius limits
The first pillar lays the foundation by separating assets into Hot Wallet - Warm Wallet - Vault/Cold Wallet layers, instead of concentrating liquidity in a single custody system. Hot wallets only maintain the amount of assets necessary for immediate payment needs and are subject to a clear exposure limit; warm wallets act as an intermediary layer with HSMs and additional approval mechanisms; while long-term assets are placed in cold storage, prioritizing an air-gapped environment and potentially incorporating a time-lock vault. The most important goal of this pillar is not simply "keeping most assets offline," but controlling Blast Radius: if a hot or warm wallet is compromised, an attacker is not allowed direct access to the exchange's entire treasury. This approach shifts the security standard from "no money can be lost" to a more quantifiable metric: Maximum Loss Per Incident, the maximum amount of assets that can be lost in a single incident.
Pillar 2 – Signing Layer: Separating asset control from a single key.
The signing layer is where transactions transition from a "requested" state to an "authorized" state. The proposed architecture combines TSS-MPC, threshold signing, Passkey/WebAuthn, and Account Abstraction to create multiple independent control layers. A notable upgrade in the model is the integration of MPC with smart accounts such as ERC-4337, where MPC protects the key layer while the smart contract enforces policies such as amount limits, whitelists, and daily spending caps. According to the research documents, if a portion of the MPC is compromised, possessing the key fragment does not mean an attacker can freely transfer the entire asset, as the on-chain policy layer can still reject inappropriate transactions. This represents a shift from "key-based security" to "policy-based security."
Pillar 3 - Fund Segregation: Separating client assets from operating assets.
The third pillar focuses on preventing operational system failures from escalating into failures affecting all client assets. The proposed architecture separates client funds, exchange operating funds, and settlement liquidity into distinct asset domains, while utilizing Proof of Reserves and Merkle-based structures to enhance verification capabilities. Another development direction is to use non-custodial clearing networks and automated netting to reduce the amount of assets that must be permanently maintained in the exchange's wallets. Instead of having the CEX hold a large amount of liquidity for 24/7 settlement, transactions could be periodically cleared through escrow and smart contracts. According to the proposed model, this could reduce the attack surface in terms of assets because the actual balance within the area potentially accessible to attackers is narrowed.
Pillar 4 – AI Monitoring: Transforming Abnormal Behavior into Security Signals
This is one of the most important layers of the model and also where AI-driven security thinking is most clearly demonstrated. The system doesn't just evaluate withdrawals based on amount, whitelist, or rule-based threshold, but builds a behavioral fingerprint for each user, operator, signer, and wallet. Signals can include operation speed, IP/ASN, network latency, execution time, transaction history, destination address, withdrawal frequency, and market context. The goal is to detect transactions that are "rule-valid but behaviorally unusual," which are the types of risks that traditional rule engines might overlook.
Another upgrade is Federated Learning, which allows multiple CEXs or custodians to collaboratively improve fraud detection models without directly sharing user data. Each organization trains its model on internal data and only shares model updates or necessary parameters. Furthermore, the Multi-Agent/LLM architecture can be used as a contextual analysis layer on top of the ML system: when a quantitative model detects an unusual withdrawal, the AI agent can consider market conditions, behavioral history, and related signals before deciding to raise or lower the risk score. This is how the model aims to reduce False Positives without lowering safety standards.
Pillar 5 - Policy & Timelock: Turning time into a layer of security
One of the most important ideas of the model is Dynamic Timelock. Instead of applying a fixed timeout to all withdrawals, the system determines the delay time based on transaction value, destination risk, behavioral risk, and historical pattern. For example, a small withdrawal to a frequently transacted address might be processed almost instantly; while a multi-million dollar transaction or a transfer to a new address might be delayed for 6–48 hours and require further verification.
More importantly, the timelock in the model is not just intended to “slow down hackers,” but to create a reaction window for the system. During that time, AI monitoring, human operators, and blockchain intelligence can verify transactions. The model also proposes a Breaker Switch using HSM and a Dead Man's Switch mechanism, where a pending transaction can be canceled or frozen upon detecting a compromise. This transforms “time” from an operational factor into a quantifiable security control.
Pillar 6 – Secure CI/CD: Protecting software before it becomes part of the asset system.
Bybit shows that a CEX cannot protect the wallet if the software preceding the wallet has been compromised. Therefore, the sixth pillar brings security down to the software supply chain. The proposed model uses SBOM, SCA, SAST, DAST, fuzzing, reproducible builds, and artifact signing in CI/CD. SBOM allows the CEX to know exactly which libraries the wallet system depends on; SCA searches for dependencies with CVEs or signs of supply-chain compromise; SAST examines the source code; and DAST examines the system's behavior in a sandbox environment.
One particularly noteworthy aspect is Reproducible/Deterministic Build. The idea is that the same source code should produce the same binary/hash when built by independent environments. If the source code has been checked but the final binary differs from the expected result, the pipeline must consider this a compromise signal and reject deployment. Combined with Artifact Signing and Separation of Duties, only artifacts generated from a trusted pipeline are allowed to run in production.
Pillar 7 – Secrets & Identity: Eliminating the “Master Credential”
The seventh pillar addresses one of CEX's most dangerous attack surfaces: identity and secret management. Instead of allowing services or employees with static credentials to have long-term access, the proposed architecture shifts to workload identity, SPIFFE/SVID, mTLS, and dynamic credentials with short TTLs. This means that a leaked credential no longer means an attacker has a "master key" that exists indefinitely.
On the human side, the model also proposes Passkey-linked MPC, where hardware authentication devices and WebAuthn/Passkey become components of the signing process. This approach reduces reliance on email or cloud accounts as the sole recovery element. Furthermore, dMPC is proposed to distribute MPC components across multiple independent nodes instead of concentrating all trust in a single cloud or custodian. This research direction aims to reduce single organizational dependency, although it should be noted that these mechanisms still require in-depth evaluation of governance, availability, cryptographic assumptions, and practical implementation before being considered production-ready.
Pillar 8 – SOAR Response: When a compromise is detected, the system must know how to "close the door" automatically.
The eighth pillar shifts security from detection to automated response. A traditional SIEM/SOC system might detect an unusual withdrawal and send alerts to staff. However, in a digital asset attack, minutes or even seconds can determine millions of dollars. Therefore, the proposed SOAR model is capable of automatically performing actions such as pausing the warm tier, revoking service identity, canceling pending transactions, rotating key shares, and activating an emergency breaker.
The key point is that automation must be designed according to the fail-safe principle: the system must not automatically perform actions that could cause more damage than the attack itself. Actions such as freezing withdrawals, revoking credentials, or increasing timelocks can be highly automated; while recovery or movement of the entire treasury requires a separate authentication layer. The model also requires 24/7 alert paging to transmit critical signals to humans immediately.
Pillar 9 - Forensics: Transform each attack into data for the next defense.
The final pillar is Forensics, because a system cannot become more secure without a thorough understanding of how it was attacked. All activities related to withdrawal, signing, policy decision, identity, deployment, and blockchain transactions need to be stored in immutable logs, WORM storage, or hash-chain structures to limit the attacker's ability to erase traces. When an incident occurs, the system needs to combine internal logs with on-chain tracing, graph clustering, and blockchain intelligence to identify the attack path, destination, and flow of funds after they leave the exchange.
Architecture from defense to survival for a process
A key feature of the 9-pillar model is that the layers do not operate independently. Pillars 1-3 protect and limit the scope of assets that may be affected; Pillars 4-5 control behavior and transaction decisions; Pillars 6-7 protect the software supply chain and identity; while Pillars 8-9 ensure the system can react and relearn after an incident.
Accordingly, a withdrawal can go through the following sequence:
Withdrawal Request → AI Monitoring → Policy & Dynamic Timelock → Signing Layer → Wallet Tiering → Fund Segregation → Blockchain Settlement
Behind this operational chain exists a Platform Security Layer comprising Secure CI/CD and Secrets & Identity, along with a Response Layer consisting of SOAR and Forensics. This forms a deep-seated defense system where a compromise of one layer does not mean the entire system loses control of its assets. The goal is not to assume every layer is impenetrable, but to identify the points at which breaches would render the entire system unsustainable. Therefore, the standard for a secure CEX is no longer simply "whether it has multisig," "whether it has a cold wallet," or "how much insurance it has," but rather:
If an attacker has bypassed the first layer, how many layers does the system have left to prevent them from accessing the asset? If a portion of the asset has been transferred, how much time does the system have to detect and reverse the process? And if an entire trust domain is compromised, which independent trust domains still retain control?
Copyright, Intellectual Property, and Disclaimer
Copyright © 2026 Minh Huy (HCCVENTURE). All rights reserved. First published October 2026, Version 1.0.
Ownership Rights. This article is the author's original work. All content, images, diagrams, and tables, as well as the original wording of the proposed theoretical frameworks, including the “9 Pillars of CEX Security” model, the CEX Survivability Architecture, and the ZK-PoR, TEE Wallet, CEX-DeFi Hybrid Insurance, dCustody Hybrid Insurance, Continuity Assurance, AI Threat Hunting Tools, Cryptographic Insurance, and Economic Game Theory models, are protected by copyright law under the Vietnamese Intellectual Property Law and the Berne Convention for the Protection of Literary and Artistic Works.
Rights reserved. Except as otherwise stated below, no part of this article may be copied, translated, adapted, distributed, published, or used commercially in any form or by any means without the prior written permission of the author. The author retains all moral rights, including the right to be identified as the author of this work, and all other intellectual property rights not expressly granted herein.
Use is permitted. Short excerpts may be quoted for educational, research, teaching, critical, evaluative, or news purposes, provided that the source is fully credited as in the suggested quotation below and the excerpt is not modified in a way that distorts the author's meaning. Permission requests: Huyminhtruong23@hccventure.com .
Source code. Code snippets titled “SPDX-License-Identifier: MIT” are licensed under the MIT License. That license applies only to those code snippets, not to the surrounding text, images, or tables. All code is an unaudited, illustrative reference implementation and is provided “as is,” without any warranties.
Third-Party Works and Trademarks. Facts, figures, and quotations from third parties are clearly stated in the References section and remain the property of their respective owners. The names, trademarks, and logos of the companies, exchanges, products, and standards mentioned in this article (including Binance, Bybit, Bitget, Coinbase, Kraken, Safe, Intel, AMD, AWS, HashiCorp, Chainlink, and Starknet) are the property of their respective owners. Mentioning them does not imply any affiliation or endorsement from those owners.
Disclaimer. This article is an independent research proposal. The architectures described herein have not been validated in a production environment. Nothing contained herein constitutes legal, financial, investment, or security endorsement advice. Descriptions of past incidents are based on publicly cited sources and may be revised as investigations continue.
Suggested citation: Minh Huy, “The Supreme Article on Secured Assets on Centralized Exchanges (CEXs)”, HCCVENTURE, Version 1.0, October 2026. [Online]. Available at: https://hccventure.com
Explore HCCVenture group
HCCVENTURE QUANT JSCO
© 2026 HCCVENTURE. ALL COPYRIGHTS RESERVED.
Connect with us
Popular content
Contact to us
Address: 8th Floor, Bach Dang Complex Building, 50 Bach Dang Street, Hai Chau Ward, Da Nang City, Vietnam.
Phone: 1900 1509
Gmail : sp_contact@hccventure.com
Disclaimer: The information on this website is for informational purposes only and should not be considered investment advice. We are not responsible for any risks or losses arising from investment decisions based on the content here.
TERMS AND CONDITIONS • CUSTOMER PROTECTION POLICY
ANALYTICAL AND NEWS CONTENT IS COMPILED AND PROVIDED BY EXPERTS IN THE FIELD OF DIGITAL FINANCE AND BLOCKCHAIN BELONGING TO HCCVENTURE ORGANIZATION, INCLUDING OWNERSHIP OF THE CONTENT.
RESPONSIBLE FOR MANAGING ALL CONTENT AND ANALYSIS: HCCVENTURE FOUNDER - TRUONG MINH HUY
Read warnings about scams and phishing emails — REPORT A PROBLEM WITH OUR SITE.
