A cryptocurrency exchange is critical infrastructure that connects digital asset trading, asset custody, and blockchain networks. For users of centralized exchanges, the platform must not only provide trade matching and liquidity services, but also securely manage the private keys used to transfer assets, process daily deposits and withdrawals, and maintain accurate asset records across different blockchain networks.
Unlike traditional financial accounts, blockchain transactions are generally irreversible. Once assets have been transferred with a valid signature, recovering them often depends on the recipient's cooperation, restrictions imposed by a stablecoin issuer, or intervention by law enforcement. Therefore, controlling asset transfer permissions, verifying transaction authenticity, and promptly identifying abnormal activity are core concerns in an exchange's security framework.
In recent years, several security incidents in the crypto industry have further highlighted the importance of wallet software, key custody, and transaction approval processes. This article examines how exchanges build multilayered asset security systems through hot and cold wallets, multisignature technology, MPC, private key lifecycle management, and risk monitoring. It also explains the practical significance of these mechanisms through representative incidents.
What Components Make Up a Cryptocurrency Exchange's Asset Security Framework?
Centralized cryptocurrency exchanges generally use a custodial asset management model. After users deposit digital assets on the platform, the exchange records their balances through an internal account system and uses wallets under its management to receive and send funds on-chain. When users conduct spot trades on the platform, each transaction typically does not need to be settled individually on the blockchain. However, deposits, withdrawals, and asset transfers between platform wallets still involve actual on-chain transactions.
Therefore, exchanges need to manage two interconnected systems at the same time: an internal ledger that records users' asset entitlements and trading activity, and wallet infrastructure responsible for actually holding and transferring on-chain assets. Only when the two remain consistently aligned can the exchange support normal fund settlement, asset reconciliation, and risk control.
From a technical and operational perspective, exchange asset security generally involves the following layers:
| Security Layer |
Core Mechanisms |
Primary Purpose |
| Asset Storage |
Hot wallets, cold wallets, wallet tiers |
Control the level of online exposure for different assets |
| Key Management |
HSM, MPC, key backups, and rotation |
Reduce the risks of key leaks and single points of failure |
| Transaction Authorization |
Multisignature, approval permissions, and transaction verification |
Prevent unauthorized asset transfers |
| Risk Monitoring |
Suspicious address identification, limits, and real-time alerts |
Detect and limit abnormal transaction activity |
| Asset Reconciliation |
Internal ledgers, on-chain balance reconciliation, and proof of reserves |
Improve the accuracy and transparency of asset records |
| Incident Response |
Withdrawal suspensions, wallet migrations, and incident investigations |
Contain the spread of risk and support business recovery |
These mechanisms do not operate independently. Even if wallet private keys are properly protected, defects in the transaction approval process may still result in improper authorization. Conversely, even if transaction approvals are highly stringent, inadequate key backup management may make assets inaccessible or expose keys to leakage.
Therefore, a mature asset security framework emphasizes defense in depth, segregation of duties, and continuous verification rather than relying on any single technology to provide absolute protection.
What Is the Difference Between Hot and Cold Wallets? Why Do Exchanges Use Both?
A hot wallet is a wallet whose signing environment or key-use process is connected to an online system. It can generally process deposit sweeps, user withdrawals, and daily fund transfers quickly, making it suitable for business scenarios that require frequent operations.
A cold wallet, by contrast, is designed to isolate critical signing materials from internet-connected environments, reducing the opportunity for remote attackers to directly access private keys. Cold wallets are generally used to hold large amounts of assets that do not need to be moved frequently. However, their operating procedures may be more complex, and funds may be transferred more slowly.
The main differences between the two types of wallets involve their connectivity, frequency of use, and scope of risk exposure.
| Comparison Dimension |
Hot Wallet |
Cold Wallet |
| Network Connection |
The signing environment is generally connected to online systems |
The critical signing environment is generally isolated offline |
| Primary Uses |
Daily deposits, withdrawals, and fund transfers |
Large-asset reserves and long-term custody |
| Transaction Efficiency |
Higher; suitable for automated processing |
Generally requires more manual or offline operations |
| Primary Risks |
Online system compromise, key leakage, and malicious signing |
Device damage, operational errors, supply chain risks, and signing process risks |
| Common Controls |
Limits, address whitelists, and anomaly monitoring |
Multiple-person approval, offline verification, and physical security management |
For an exchange, keeping all assets in hot wallets may improve withdrawal efficiency, but it could also expand the potential impact of an online attack. Keeping all assets in cold wallets, on the other hand, could affect users' ability to withdraw funds normally.
Therefore, exchanges generally allocate funds across different wallet tiers based on liquidity requirements and risk management strategies. For example, an exchange may retain a certain amount of online liquidity to process daily withdrawals while managing the remaining assets through stricter custody procedures and conducting approved fund transfers when necessary.
It is important to note that a cold wallet does not mean absolute security. Cold storage can reduce the risk of private keys being exposed online, but it cannot automatically determine whether a signed transaction reflects the actual business intent. Transaction review and authorization procedures remain essential.
How Does Multisignature Prevent a Single Private Key From Controlling Large Amounts of Assets?
Multisignature, commonly abbreviated as multisig, is a control mechanism that requires multiple independent authorizations to complete a transaction. Its core purpose is to prevent a single key holder from independently deciding to transfer important assets.
Using a common 2-of-3 multisig arrangement as an example, the system establishes three independent signing permissions, and a transaction requires at least two valid authorizations to be executed. Even if one key is compromised, an attacker generally cannot complete a transfer using that key alone.
In exchange asset management, multisig can be combined with the segregation of duties within an organization. For example, different personnel or systems can be responsible for initiating, reviewing, and finally approving a transaction, requiring large asset transfers to pass through multiple control stages.
However, multisig does not mean that every signer can automatically identify a malicious transaction. If multiple signers rely on the same compromised interface, or fail to independently verify the destination address, transaction amount, and smart contract call details, they may approve a transaction that does not reflect the original intent even when the required number of signatures has been reached.
Therefore, the security of multisig depends not only on the signing threshold, but also on the independence of the signers, the completeness of the transaction information displayed, and whether critical operations are verified through trusted channels.
For wallets involving smart contracts, the approval process should also review contract permission changes, proxy contract upgrades, and complex transaction calls. Some transactions may not appear to be direct transfers but could change asset control permissions. They therefore require more stringent technical verification.
How Does MPC Differ From Traditional Multisignature?
Multi-Party Computation (MPC) is a category of cryptographic technology that enables multiple participants to jointly perform computations without directly exposing their respective secret information. In digital asset custody, MPC is often combined with threshold signature technology to distribute control of a key.
Unlike traditional multisignature, an MPC threshold signature scheme can distribute signing capabilities across multiple participants or devices. Each party uses an independent key share to participate in the signing process, without reconstructing the complete private key during normal operations.
For example, a threshold-signature wallet may require any two of three participants to jointly complete a signature. Even if one participant's key share is exposed, it may not be sufficient to generate a valid signature independently.
Both mechanisms can reduce the risk of a single point of failure, but their technical implementations differ.
| Comparison Dimension |
Multisignature |
MPC Threshold Signature |
| Basic Principle |
Multiple independent authorizations jointly approve a transaction |
Multiple key shares collaborate to generate a signature |
| On-Chain Representation |
Depends on the chain and wallet implementation and may involve a multisig contract |
Can generate signatures compatible with standard signature formats |
| Permission Control |
Governed by multisig rules and wallet logic |
Controlled by threshold protocols and supporting policies |
| Primary Advantage |
Clear authorization rules that are easy to audit |
Distributed signing capabilities that support various custody architectures |
| Primary Limitation |
Depends on signers and the transaction verification process |
Depends on protocol implementation, share management, and participant security |
MPC is not necessarily more secure than every multisig solution. A common challenge for both mechanisms is ensuring that participants approve the correct transaction and preventing attacks against identity credentials, endpoint devices, and administrative permissions.
In practice, exchanges can also combine HSM, independent device verification, role-based permission controls, and operational log audits to improve the reliability of the overall signing process.
Why Is Private Key Management at the Core of Exchange Asset Security?
Private keys are critical cryptographic materials in blockchain asset control systems. On blockchains that use common account models, a party with the corresponding signing authority can initiate asset transfers that comply with the protocol rules. Therefore, protecting private keys is not merely a matter of preventing data leaks; it directly concerns control over assets.
Comprehensive private key management generally covers multiple stages, including key generation, storage, use, backup, rotation, and decommissioning.
-
Key generation should use reliable sources of randomness and validated cryptographic implementations. If there is a flaw in the key generation process, even a highly secure storage environment may not prevent the resulting risks.
-
Private keys and related key shares should be stored in controlled environments with restricted access permissions. An HSM can perform certain cryptographic operations in a protected hardware environment, reducing the opportunity for key materials to be directly exposed to ordinary applications. However, its effectiveness still depends on the specific deployment and permission settings.
-
Exchanges need to establish strict key-use policies, including which personnel or systems may initiate signatures, which asset transfers require additional approval, and how operations should be blocked when abnormal activity is detected.
-
Backup and recovery mechanisms are equally important. A lack of backups may make assets inaccessible after device damage, while excessive backups, dispersed custody, or insufficient access controls may increase the risk of exposure.
Key rotation also needs to account for the practical characteristics of blockchains. For some address systems, rotation is not as simple as replacing a password. It may require generating new wallet addresses and migrating assets through secure procedures.
As a result, private key security is not simply a matter of having the technology team store a password. It is a comprehensive management issue involving cryptography, infrastructure, personnel permissions, and business processes.
What Lessons Have Recent Exchange Security Incidents Provided?
Since 2025, crypto asset custody and trading infrastructure have experienced several notable security incidents. These cases involved different technical architectures and business environments. They cannot be simply attributed to defects in a particular wallet technology, nor is it appropriate to judge a platform's overall security solely because an incident occurred.
From a security research perspective, the value of these incidents lies in helping the industry understand different attack paths and observe how exchanges handle anomaly monitoring, asset isolation, and incident recovery.
Bybit: February 2025 Multisig Wallet Security Incident
On February 21, 2025, Bybit experienced a security incident involving approximately $1.5 billion in digital assets. Subsequent investigations focused on the signing environment and related software supply chain. Attackers exploited the affected transaction display and authorization process, causing the signing operation to fail to accurately reflect the transaction that was actually executed. The FBI later attributed the attack to North Korea-linked threat activity.
This case shows that multisig and cold wallets can provide important asset protection, but exchanges also need to independently verify transaction details, control the trustworthiness of signing interfaces, and strengthen the security management of third-party software and critical dependencies.
Phemex: January 2025 Hot Wallet Anomalous Activity
On January 23, 2025, Phemex detected anomalous activity involving its hot wallets. It then initiated an incident response, suspended related deposit and withdrawal functions, isolated affected devices, and worked with external security firms on the investigation. After completing inspections and system adjustments, the platform gradually restored withdrawal services for different networks.
This incident highlights two key aspects of hot wallet risk management: controlling the risk exposure of online wallets and promptly isolating affected systems, suspending related operations, and conducting security reviews when abnormal activity is detected.
CoinDCX: July 2025 Operational Account Security Incident
On July 19, 2025, CoinDCX disclosed that an internal operational account used to provide liquidity services to partner exchanges had been compromised, involving approximately $44 million in assets. The platform stated that the affected account was isolated from customer asset wallets, that the related losses would be covered by the company's own reserves, and that customer wallets were not directly affected.
This case shows that, in addition to protecting wallet keys, isolating business accounts from customer custody assets is equally important. Restricting the funds that different business systems can access can reduce the impact of a security incident in a single operational environment.
Upbit: November 2025 Unauthorized Transfer of Solana Assets
On November 27, 2025, Upbit discovered unauthorized transfers involving certain assets on the Solana network. Initial disclosures indicated that the incident involved approximately KRW 5.4 trillion. The platform subsequently suspended related deposits and withdrawals, transferred assets to cold wallets, and conducted a security review. A later review identified a potential key security issue in the wallet system, but the issue had not been confirmed at the time as the direct cause of the incident.
This case further shows that wallet security involves more than key storage. It also depends on the correct implementation of signing algorithms, software testing, and continuous security audits. Conducting a systematic review after detecting abnormal activity can help identify other potential risks.
2026 Security Incident Investigations and Industry Coordination
On October 29, 2026, large-scale abnormal fund transfers involving Binance-related hot wallets drew attention to exchange asset security. Estimates from on-chain analytics firms and researchers varied, with some estimates reaching several billion dollars. Because different calculation methods may involve multiple wallet addresses and subsequent fund transfers, these figures do not represent confirmed final asset losses. The specific impact remains subject to further verification.
After the incident, Binance stated that it was investigating potential security issues and emphasized the safety of user funds. The platform temporarily suspended deposits and withdrawals to conduct security checks, trace abnormal funds, and cooperate with relevant investigations. At the same time, stablecoin issuers Tether and Circle froze approximately $1.57 billion in USDT and more than $800 million in USDC, respectively. Other relevant institutions also participated in asset tracing and risk control. As of October 30, Binance disclosed that the amount of frozen assets it had verified had reached several billion dollars. However, the final loss amount and specific attack path still require further investigation.
This incident illustrates the complexity of emergency response for exchange security. In addition to protecting private keys and identifying abnormal transactions, trading platforms need to coordinate with blockchain analytics firms, stablecoin issuers, other trading service providers, and law enforcement agencies. Fund tracing, asset freezes, system inspections, and business recovery can all help reduce potential risks.
Taken together, recent security incidents show that modern exchange asset protection is no longer limited to hot and cold wallets and private key management. Instead, it is developing into a multilayered protection framework covering signature verification, business system isolation, anomaly monitoring, and cross-institution incident response.
How Can Exchanges Reduce Asset Losses Through Anomaly Monitoring and Risk Controls?
Even when an exchange uses hot and cold wallet segregation, multisig, and MPC, it still needs to continuously monitor actual fund flows. This is because the goal of a security system is not only to prevent unauthorized access, but also to promptly identify and limit risk after abnormal activity occurs.
-
Exchanges can set transaction limits based on different assets, wallets, and business scenarios. For example, a daily withdrawal wallet can be configured with balances and transfer thresholds based on normal funding needs. When the amount or frequency of transactions significantly deviates from historical patterns, the system can trigger additional verification or manual review.
-
On-chain address monitoring can help identify high-risk fund flows. By analyzing address history, transaction paths, and relevant risk labels, platforms can conduct additional reviews of suspicious transactions. However, on-chain analysis has limitations. A connection between addresses does not necessarily mean that they are controlled by the same person or entity.
-
Platforms need to establish cross-system anomaly detection capabilities. If a transaction appears normal on-chain but is inconsistent with the corresponding internal business request, approval record, or user account activity, this may still indicate an abnormality in the transaction process.
When a major security incident occurs, an exchange can take measures based on the scope of the risk, such as suspending some withdrawals, restricting operations involving affected wallets, migrating unaffected assets, and redeploying wallet infrastructure. For certain tokens that support issuer-controlled functions, the exchange may also coordinate asset freezes through compliance procedures.
These measures need to balance asset security, normal user access, and business continuity. Suspending withdrawals can provide time for investigation and risk control, but it also affects users' access to their funds. Clear triggering conditions, disclosures, and recovery procedures are therefore necessary.
Can Proof of Reserves and Risk Reserves Ensure User Asset Security?
Proof of Reserves (PoR) is a verification mechanism designed to improve the transparency of trading platform assets. It generally uses publicly disclosed wallet asset information, cryptographic proofs, third-party verification, or other methods to help external observers understand the assets held by a platform at a specific point in time and their relationship to user balances.
In solutions that use technologies such as Merkle Trees, users can verify whether their account balances have been included in a specific asset and liability data set. However, the scope of verification depends on the platform's technical implementation and disclosure practices. Proof of reserves is not equivalent to a complete financial audit.
Gate, for example, uses a proof of reserves verification mechanism that combines Merkle Trees with zero-knowledge proofs (zk-SNARKs). It incorporates user account balances into a cryptographic verification framework and provides an independent verification channel. Users can view the reserves of different assets on the proof of reserves page, verify whether their account balances were included in the corresponding data snapshot, and reduce the exposure of other users' private information.
As of October 18, 2026, Gate disclosed total reserves of approximately $8.688 billion and net user asset balances of approximately $7.332 billion, resulting in an overall reserve ratio of 118.49% and covering approximately 500 crypto assets. The reserve ratios for BTC and ETH were 121.60% and 123.78%, respectively. These figures reflect the platform's asset coverage in that snapshot and provide users with reference information for evaluating the platform's asset transparency.
It is important to emphasize that proof of reserves primarily reflects asset coverage within a specific disclosure scope and at a specific point in time. It cannot independently prove that a platform has no other liabilities, restrictions on asset rights, or operational risks. Therefore, PoR is better used as a transparency tool alongside liability verification, independent audits, and continuous risk disclosures.
Risk reserves serve a different purpose. Some exchanges establish dedicated risk funds to provide financial support in qualifying security incidents or other extreme situations. However, their coverage, fund size, and usage conditions depend on the platform's specific arrangements. Risk reserves are not equivalent to deposit insurance with statutory protection.
Overall, proof of reserves focuses on asset transparency and verifiability, while risk reserves focus on financial support after certain risks occur. Hot and cold wallet segregation, multisignature, and private key management primarily provide preventive protection. These mechanisms complement one another and together form important components of an exchange's asset security management.
How Can Ordinary Users Improve the Security of Their Exchange Account Assets?
Exchanges manage platform-level wallets and custody infrastructure, but user accounts may still face risks such as phishing, credential leaks, malicious authorization, and device compromise. Users therefore also need to establish account security practices suited to their circumstances.
-
Users should enable passkeys, security keys, or other strong authentication methods whenever possible and set a unique password for their exchange account. Compared with relying solely on SMS verification codes, phishing-resistant authentication mechanisms generally provide stronger protection.
-
Users should verify login domains and the sources of official applications, and avoid entering passwords, verification codes, or other sensitive information through unfamiliar links. Messages claiming that users must urgently transfer assets, remove risk controls, or reverify their identities should be verified through an independent channel.
-
Withdrawal address whitelists, withdrawal confirmations, and account activity notifications can reduce the potential impact of unauthorized account use. If the platform supports a waiting period after a new withdrawal address is added, users can enable it based on their needs.
Users who use APIs for automated trading should follow the principle of least privilege. They should avoid granting asset transfer permissions to programs that do not need withdrawal functionality and promptly delete API keys that are no longer in use.
Users should also choose between centralized custody and self-custody based on their trading frequency, intended use of funds, and ability to manage their own keys. Self-custody can reduce reliance on third-party platforms, but it also means that users are responsible for securing their seed phrases, protecting their devices, and managing the risk of lost keys.
There is no single asset security solution that applies to everyone. Understanding the risk boundaries of different custody methods is more important than simply choosing one type of wallet.
Conclusion
The core of user asset protection at a cryptocurrency exchange is a multilayered security framework covering asset storage, key management, transaction authorization, anomaly monitoring, and incident recovery. Hot wallets provide day-to-day liquidity, cold wallets reduce online exposure, multisig and MPC distribute control over assets, and independent transaction verification and permission management help ensure that asset transfers reflect actual business intent.
Security incidents at exchanges since 2025 show that as the scale of asset custody and system complexity increase, security risks are no longer limited to whether private keys are stored online. Software supply chains, signing interfaces, business account isolation, and cross-institution incident response can all affect actual security outcomes.
For trading platforms, continuous audits, stronger internal controls, and greater asset transparency are important foundations for establishing long-term trust. For users, understanding wallet architecture and asset custody mechanisms and taking necessary account protection measures can help them more comprehensively assess and manage digital asset risks.
FAQ
Is a hot wallet always less secure than a cold wallet?
Hot wallets generally have greater exposure to online attack risks, but their actual security also depends on key management, transaction limits, and monitoring mechanisms. Cold wallets reduce online exposure, but they may still face operational, device, and supply chain risks.
Can assets still be stolen after an exchange adopts multisignature?
Yes. Multisignature reduces the risk of a single key controlling assets, but unauthorized or unintended asset transfers may still occur if signers are misled, transaction details are altered, or multiple authorization stages are compromised simultaneously.
Can MPC completely prevent private key leaks?
No. MPC threshold signatures can distribute signing capabilities and reduce the risk of a single key leak, but they cannot automatically prevent malicious transaction authorization, participant device compromise, or abuse of business permissions.
Can proof of reserves prove that an exchange is completely secure?
No. Proof of reserves can improve asset transparency within a specific scope, but it cannot independently prove that a platform has no other liabilities. It also cannot replace wallet security audits or internal risk management.
Will users' assets necessarily be affected after an exchange experiences a security incident?
Not necessarily. The actual impact depends on the scope of the affected assets, wallet isolation measures, the platform's reserves, asset recovery efforts, and subsequent response arrangements. Some incidents may affect only specific operational accounts. Whether user assets have suffered losses must be determined based on the specific facts.
