In the world of cryptocurrency, protecting your assets may only require managing a set of mnemonic phrases. But if you are managing hundreds of billions in assets for an institution, the situation becomes much more complicated.

Where should the assets be stored? Who needs to confirm the transactions? Who has multi-signature authority to access the assets? If a certain link is exploited by an attacker, can we detect it in time and prevent losses? These questions are the real tests that institutional crypto asset security needs to face.

In this issue of "Security Course," we invite the security teams from CertiK and Gate to shift focus from personal wallets to institutional asset management, discussing how an institution can safeguard its normal business operations while controlling asset risks within manageable limits from the perspectives of security auditing and trading platforms.

Guest Introduction

CertiK: CertiK is the world's largest Web3 security company, trusted by global regulatory bodies, financial institutions, and Web3 innovation enterprises. Since its establishment in 2017, CertiK has provided services to over 150 countries and regions, discovering over 119,000 code vulnerabilities and protecting more than $600 billion in digital assets from losses.

Gate Security Team: The Gate security department is responsible for the construction of the platform's account, trading, and asset security systems. It has also long provided support for institutional clients in permission management, API access, and asset custody.

Founded in 2013, Gate was the first mainstream trading platform in the industry to commit to 100% reserves and currently serves over 61 million users worldwide. Through this series of courses, we aim to clarify the common mechanisms behind the real risks that users might encounter.

Q1. What is the biggest difference between institutional managed wallets and personal managed wallets? Where do institutional security issues usually arise? How do the risks faced by institutions differ from those of ordinary users?

CertiK: The most fundamental difference is in how asset control is organized. Personal wallets primarily focus on how individuals manage their keys, identify risks, and confirm transactions; institutions need to involve multiple positions, systems, and external service providers to jointly manage assets according to clear authorizations while bearing responsibilities for asset custody, business continuity, and compliance. The scale of funds magnifies the consequences, and the dependencies between organizations and systems increase the paths for errors.

Common risks for individual users include mnemonic phrase leaks, phishing, and malicious authorizations. Institutions face these threats as well, but they must also guard against over-concentration of permissions, disconnects between approvals and actual transactions, terminal or third-party software being compromised, and collusion or operational errors among personnel. When analyzing institutional incidents, it’s essential not to stop at the outcome of "private key leak" but to investigate how the attacker accessed the key or how they induced the system to complete a signature without obtaining the key.

In 2025, there was a typical incident: attackers tampered with the front end of the Safe wallet so that the signers saw normal transfer information but actually signed a malicious transaction that replaced the wallet implementation contract. Multiple signers completed valid signatures, and the assets were still transferred away. This indicates that it is necessary to verify not just "how many people signed," but also whether what they saw, approved, and ultimately signed was the same transaction.

Therefore, when evaluating institutional security, it is necessary to check layer by layer along the lines of "who initiated the instruction, who confirmed the content, who can sign, and who can modify the rules" to determine whether these controls genuinely restrain each other.

Gate Security Team:

The security model of personal wallets allows for better control, with measures mainly focused on preventing the leak of mnemonic phrases.

However, security assurance for institutions is more complex, involving multi-signatures, multiple permissions, and the frequency of operations. It is necessary to consider how to allow different roles to use funds while ensuring that no one person can unilaterally transfer the money. The difficulty of managing these two aspects is not on the same level.

From the public security incidents we have seen, very few accidents have been caused directly by the cracking of cryptographic technology itself; most issues arise from other links, which can be roughly categorized into three types.

The first type is when the tools used encounter problems. For example, if a certain piece of open-source software, cloud service, or development tool used by the team is tampered with, the wallet's risk may be affected.

The second type is human-related issues. This includes someone impersonating another to gain permissions, internal staff misusing permissions, and former employees’ permissions not being reclaimed in a timely manner after they leave. As we mentioned in the first issue: attackers do not necessarily need to breach the system directly; they can also find ways to get close to authorized individuals. This perspective is equally applicable in institutional scenarios, where attackers may learn a company's technical situation through job postings, search for relevant employees on coding platforms, or establish contacts with employees at industry events, with the entire preparation process lasting several months.

The third type is process issues. For example, bypassing necessary approvals during emergencies, forgetting to reclaim temporarily opened permissions, using live business data in testing systems, or exposing internal tools that should not be publicly accessible on the internet for convenience.

These issues may not seem complex, but if they occur in an institution managing a large amount of assets, they could result in severe losses.

Q2. Institutions typically use multi-signature wallets, MPC custody, and approvals to protect assets. What problems do these methods each solve, and what risks should be cautious of?

CertiK: These three mechanisms answer different questions. Multi-signature requires multiple keys to grant authorization, reducing the risk of a single key being compromised; MPC distributes signing capabilities across different key shares, decreasing the risk of storing and using full private keys in a centralized manner; internal approvals determine whether a transaction should take place business-wise. Institutions must validate that these three layers of control can genuinely constrain each other in practice.

For example, if multiple keys are controlled by the same team or the same set of administrative permissions, the threshold may be dispersed in form but remains concentrated in risk. The division of MPC shares must also consider whether device registration, identity authentication, and recovery permissions can potentially be controlled by the same person. Similarly for the approval process: if the approval is for what is displayed on the page, but the signing system receives a different transaction, the approval cannot constrain the asset transfer.

In CertiK's technical analysis of the Gnosis Pay incident, a flaw in the authorization verification module led to unauthorized transactions being incorrectly accepted. This indicates that evaluation must not only cover key and signing algorithms but also include identity authentication, transaction verification, permission changes, and recovery processes.

Gate Security Team: The issues mentioned by CertiK are also key considerations for us when designing institutional asset security solutions.

In Gate's own asset management, the vast majority of assets are stored in multi-signature cold wallets, managed offline and with physical isolation; hot wallets utilize multi-signatures combined with multi-party secure computation, ensuring distributed management of private keys and also implementing limit strategies so that any assets exceeding the limit will be immediately transferred to cold wallets.

For users, we also have different security proposals. For institutional clients, we have introduced Gate Vault. Gate Vault uses an MPC plus 2-of-3 signature structure, simply put, Gate Vault splits the keys into three parts, each stored by the user's device, Gate, and an independent third party. Completing a transaction requires the fulfilment of specified authorization conditions, preventing any party from unilaterally controlling the user's assets.

Additionally, Gate Vault has set a 48-hour transfer delay period. All transfers initiated from the Vault go through a 48-hour delay period during which users can actively freeze the transaction. In institutional scenarios, the possibilities of erroneous operations and coerced signatures are real, hence the value of delayed transactions creates a window for these situations.

Q3. How should an institution establish a complete security management system? Which links are most likely to be overlooked?

CertiK: Institutions should establish continuous controls around each transaction: verifying business purpose, counterparties, addresses, and limits at the initiation stage; ensuring that relevant personnel clearly understand the actual meaning of transactions during approval, and ensuring that approval results correspond to the final content for signing; protecting keys, devices, and operational permissions in signing and custody phases; and monitoring abnormal transactions after execution, completing on-chain records and internal account checks. Each step requires designated accountable persons while leaving corresponding records that can relate to each other.

What is most often overlooked are those operations that do not directly involve transferring funds but change asset control rights, such as modifying the recipient address whitelist, increasing limits, changing signers, or updating wallet software. Recovery processes also require separate design and rehearsal: when key personnel leave, devices fail, or service providers are interrupted, institutions must be able to regain control while retaining the necessary multi-signature authorizations, ensuring that backup paths do not become vulnerabilities in daily permissions management.

Gate Security Team: At Gate, institutions usually manage funds through master and sub-accounts, setting different operational permissions for employees in various positions. For example, some may only view the account, others can execute trades, and others are responsible for approvals. This setup meets daily workflow needs while minimizing unnecessary financial risks.

For asset management institutions, we also provide dedicated custody sub-accounts. This primarily addresses one issue: investors want to entrust their funds to a professional team but do not wish for the team to have direct access to the funds. Specifically, once investors create a custody sub-account, they cannot create an API Key for program operations; the trading team can execute trading strategies as agreed but does not have withdrawal permissions. Meanwhile, during the cooperation period, investors cannot view the trading team's positions, orders, and historical records, preventing leaks of trading strategies.

In more specific API security settings, most operations are completed programmatically, with manual orders accounting for a very small portion. Thus, our API keys support fine-grained permission configurations, allowing for separate settings for reading, trading, and withdrawals.

Q4. What security and compliance issues do regulatory agencies focus on when evaluating a platform or project?

CertiK: Regulatory agencies first need to determine whether the platform can continuously control assets, maintain critical services, and explain how problems were discovered and managed when risks occur. For trading platforms, this involves client asset custody, account reconciliation, permission management, anti-money laundering, and incident handling; for central bank digital currency systems, the integrity of issuance and ledgers, payment continuity, and accurate recovery after failures are even more critical. Although these two types of systems have different business, they both require testable and verifiable evidence.

This is also the practical issue involved in CertiK's recent cooperation with the Central Bank of Kyrgyzstan. The memorandum signed by both parties plans to focus on security assessments of the digital som, formal verification, cybersecurity and operational resilience, as well as digital asset regulation, anti-money laundering, and custody. When it comes to assessment, regulators need to see specific results: who holds key permissions, whether high-risk issues have been rectified, how abnormal transactions are handled, and whether services and accounts can be restored after fault drills.

Gate Security Team:

The issues mentioned by CertiK are also our firsthand experiences as we apply for and maintain related licenses in various countries and regions.

When people usually discuss platform security, they often focus more on whether the technology is advanced. However, from a regulatory perspective, there is another very important question: Are users' funds and the platform's own funds genuinely managed separately? If a problem occurs, can it be clearly determined to whom each asset belongs?

This is also the significant meaning behind reserve proof. For ordinary users, it helps confirm whether the platform has sufficient assets to repay user balances; for regulatory agencies, it is also an important basis for checking the platform's asset management situation.

Taking Gate as an example, it was the first platform to use Merkle trees and zero-knowledge proof technology, allowing users to verify whether their assets have been accounted for while also protecting user information. The latest data shows that Gate's total reserves amount to $8.688 billion, with an overall reserve rate of 118.49%. Among them, Bitcoin reserves are 25,727 coins, with a reserve rate of 121.60%; Ethereum reserves are 449,042 coins, with a reserve rate of 123.78%.

Simply put, a reserve rate exceeding 100% means that the corresponding asset reserves disclosed by the platform exceed the related asset balances of users.

Q5. When institutions choose an asset trading platform, how should they assess the platform's security? What information can they check and verify themselves?

CertiK: When institutions choose a platform, they first need to clarify whether the security evidence covers the services, systems, and versions they actually use. What components have been assessed in the audit report? Have the identified issues been rectified? Who can transfer assets or modify critical permissions? If custodianship is involved, they should also understand how key control, asset reconciliation, backup recovery, and third-party dependencies operate.

At CertiK, we organize complex on-chain and off-chain signals into a more intuitive, continuously updated scoring system through Skynet. For example, for Web3 projects, the scoring presents information across six dimensions: code security, fundamental health, operational resilience, community trust, market stability, and governance capability, helping institutions quickly find risk points worthy of further investigation. Institutions can also check publicly available CertiK audit reports for projects on Skynet, along with specific findings and handling statuses, and verify whether the report's scope aligns with the currently deployed version. Exchanges and wallets have their applicable evaluation information; for internal permissions and custodial arrangements not explained on publicly available pages, institutions should still require the platform to provide materials and validate them through due diligence or controlled testing.

Gate Security Team: We believe that institutions can check a platform's security situation from the following aspects.

First, check the reserves. For instance, Gate has made the source code of its reserve verification procedures publicly available, allowing users to view and download it on GitHub. By combining it with their corresponding verification data, users can check locally whether their account balances have been correctly included.

The second is the bug bounty program. In simple terms, it’s whether the platform is willing to pay outside security researchers to help identify system vulnerabilities for regular optimization. It’s important to focus on whether the program operates long-term, whether the rewards are reasonable, and whether the platform responds promptly after issues have been discovered. For example, Gate has long operated a security bug bounty program and welcomes security researchers worldwide to submit their discovered issues.

The third is the licenses. Institutions need to confirm in which countries and regions the platform has obtained relevant licenses, which company corresponds to the licenses, and whether they are still valid. It's important to note that having a license does not mean the platform is absolutely secure but indicates that the platform must meet the regulatory requirements of the relevant region.

Q6. For an institution just beginning to configure cryptocurrency assets, what should they prioritize doing first?

CertiK: First, establish the purpose of the configuration and risk boundaries: what assets are held, through which platforms, chains, and counterparties business is conducted, and what the single-transaction and overall exposure controls are. Then clarify who is responsible for initiating, approving, signing, reconciling, and handling anomalies, and decide what permissions each party holds when opting for self-custody, third-party custody, or a combination of both.

Before the first transfer, the receiving party and address should also be verified. CertiK emphasizes in its research on institutional digital asset trading counterparts that a blockchain address does not itself prove who or what controls it; the control of addresses, risk history, and counterparties need to be verified together. After completing platform due diligence, institutions might pilot small transactions to process transfers, withdrawals, and reconciliations, and rehearse the handling of device failures or service interruptions, gradually scaling up based on the results.

Gate Security Team: For institutions just starting to configure cryptocurrency assets, we have four suggestions.

First, do not put all your eggs in one basket. Funds needed for daily transactions, mid-term reserves, and long-term inactive funds should be managed separately and allocated different usage limits. It is best to plan this out before signing up; otherwise, adjusting financial management methods after business operations have commenced will be much more difficult. For assets that do not need to be activated long-term, consider using custodial solutions with a 48-hour transfer delay mechanism, allowing for extra time for checks and providing room for handling anomalies.

Second, delegate different operations to different people. Initiating transfers, approving transfers, and executing transfers should ideally not all be done by the same person. With sub-accounts and employee permission settings, basic division of labor can be achieved without the need for additional system development.

Third, strictly manage keys used for programmatic operations. By default, do not grant withdrawal permissions, and each key should have a clear purpose and owner, with pre-established conditions for when it needs to be revoked or deleted.

Fourth, conduct background checks before choosing a platform. For instance, confirming whether reserves can be verified, who manages the funds, if there is a bug bounty program, and whether related licenses are valid should all be understood in advance.

As management of funds transitions from personal to institutional, the more funds involved and the more people participating, the more complex the risks to consider. However, regardless of the scenario faced, the core of security remains about identifying risks in advance and avoiding actual losses wherever possible.

This is also the concept that "Security Course" aims to convey: security should not only be emphasized after problems occur but should become a habit in every operation and every decision.

Thanks to CertiK and the Gate security team for their contributions. See you in the next "Security Course"!

Disclaimer

This content does not constitute any solicitation, recruitment, or advice. You should always seek independent professional advice before making any investment decisions. Please note that Gate may restrict or prohibit all or part of its services from restricted areas. Please read the User Agreement for more information.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到[email protected]，本平台相关工作人员将会进行核查。