Gate Security Course 04 | Gate & CertiK: How Do Institutions Safeguard Tens of Billions in Assets?

In the crypto world, protecting your assets may only require safeguarding a single set of mnemonic words. But if you are managing tens of billions in assets for an institution, the situation becomes far more complex.

Where should assets be stored? Which people need to confirm a transaction? Who has multi-sig authority to move assets? If an attacker exploits a vulnerability in some part of the process, can it be detected and the loss stopped in time? These are the real challenges institutional crypto asset security must confront.

In this edition of "Gate Security Course," we invite CertiK and the Gate security team to shift the perspective from personal wallets to institutional asset management, discussing from the viewpoints of a security audit firm and a trading platform how an institution can keep asset risk within manageable bounds while ensuring normal business operations.

Guest Introductions

CertiK: CertiK is the world's largest Web3 security company, trusted by regulators, financial institutions, and Web3 innovators worldwide. Since its founding in 2017, CertiK has served over 150 countries and regions, discovered more than 119,000 code vulnerabilities, and protected over $600 billion in digital assets from loss.

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

Founded in 2013, Gate is the industry's first mainstream trading platform to commit to 100% reserves, currently serving over 61 million users worldwide. Through the "Gate Security Course" series, we hope to clearly explain the common mechanisms behind the real risks users may encounter.

Q1. What is the biggest difference between institutional and personal wallet management? Where do institutional security problems typically arise? Compared with ordinary users, what different risks do institutions face?

CertiK: The most fundamental difference is how asset control is organized. Personal wallets focus mainly on how an individual safeguards keys, identifies risks, and confirms transactions; institutions need multiple roles, systems, and external service providers to jointly manage assets under clear authorization, and bear responsibility for asset custody, business continuity, and compliance. The scale of funds amplifies consequences, and the dependencies between organizations and systems increase the paths through which errors can occur.

Common risks for individual users include mnemonic leakage, phishing, and malicious approvals. Institutions face these threats too, but must also guard against excessive concentration of permissions, disconnect between approvals and actual transactions, compromise of endpoints or third-party software, and collusion and operational errors by personnel. When analyzing institutional incidents, one cannot stop at the outcome of "private key leakage" but must also trace how the attacker gained access to the keys, or how they induced the system to complete a signature without obtaining the keys.

A typical incident occurred in 2025: attackers tampered with the Safe wallet frontend so that signers saw normal transfer information but actually signed a malicious transaction that replaced the wallet implementation contract. Multiple signers completed valid signatures, yet the assets were still transferred away. This shows that what needs to be verified is not only "how many people signed" but also whether what they saw, approved, and ultimately signed was truly the same transaction.

Therefore, when assessing institutional security, one needs to check layer by layer along "who initiates the instruction, who confirms the content, who can sign, who can modify the rules," to determine whether these controls truly constrain one another.

Gate Security Team:

The security model of personal wallets is easier to control, with measures mainly centered on preventing mnemonic leakage.

But institutional security is more complex, involving multi-sig, multi-person permissions, and the frequency of operations. One needs to consider how people in different roles can use funds normally while preventing any single person from transferring the money without authorization. The difficulty of these two things is on a completely different order of magnitude.

From the public security incidents we have observed, incidents truly caused by the cracking of cryptographic technology itself are very rare; more problems arise in other areas, which can be roughly divided into three categories.

The first category is problems with the tools used. For example, if an open-source software, cloud service, or development tool used by the team has been tampered with, wallet risk may also be affected.

The second category is people problems. This includes someone impersonating another to obtain permissions, internal personnel abusing permissions, and permissions not being revoked in time after an employee leaves. We mentioned in the first episode: attackers do not necessarily need to directly breach the system; they can also find ways to get close to people with permissions. This view also applies in institutional scenarios—attackers may learn about a company's technical situation through job postings, look for relevant employees on code platforms, or build relationships with employees at industry events, with the entire preparation process possibly lasting months.

The third category is process problems. For example, skipping required approvals in emergencies, forgetting to revoke temporarily opened permissions, using real business data in test systems, or exposing internal tools that should not be publicly accessible directly to the internet for convenience.

These problems may not seem complex, but once they occur in an institution managing large amounts of assets, they can cause serious losses.

Q2. Institutions typically use multi-sig wallets, MPC custody, and approvals to protect assets. What problems do these methods solve respectively? What risks need attention?

CertiK: These three mechanisms answer different questions. Multi-sig requires multiple keys to jointly authorize, reducing the risk of a single key being compromised; MPC distributes signing capability across different key shares, reducing the risk of complete private keys being stored and used in a concentrated manner; internal approvals determine whether a transaction should occur from a business perspective. What institutions truly need to verify is whether these three layers of control can constrain each other in actual operation.

For example, if multiple keys are controlled by the same team with the same set of administrator permissions, the threshold is dispersed in form but the risk remains concentrated. When MPC shares are stored separately, one must also check whether device registration, identity authentication, and recovery permissions could be controlled by the same person. The same applies to approval processes: if what is approved is what is displayed on the page while the signing system receives a different transaction, approvals cannot constrain asset transfers.

In CertiK's technical analysis of the Gnosis Pay incident, a flaw in the authorization verification module caused unauthorized transactions to be incorrectly accepted. This shows that assessment cannot stop at keys and signing algorithms but must also cover identity authentication, transaction verification, permission changes, and recovery processes.

Gate Security Team: The issues CertiK mentioned are also key considerations in our design of institutional asset security solutions.

In Gate's own asset management, the vast majority of assets are placed in multi-sig cold wallets with offline management and physical isolation; hot wallets use multi-sig plus multi-party computation, with distributed private key management, and quota policies are set so that once limits are exceeded, assets are immediately transferred to cold wallets.

For users, we also offer different security solutions. For institutional clients, for example, we launched Gate Vault. Gate Vault uses MPC plus a 2-of-3 signature structure. Simply put, Gate Vault splits the key into three shares, held respectively by the user's device, Gate, and an independent third party. Completing a transaction requires meeting the specified authorization conditions, and no single party can control the user's assets alone.

In addition, Gate Vault has a 48-hour transfer delay period. All outbound transfers initiated from the Vault must go through a 48-hour delay, during which users can proactively freeze the transaction. Because in institutional scenarios, operational errors and coerced signing are also real situations, the value of delayed settlement lies in leaving a window for these cases.

Q3. How should institutions establish a complete security management system? Which links are most easily overlooked?

CertiK: Institutions should establish continuous controls around a transaction: at initiation, verify the business purpose, counterparty, address, and limits; at approval, let relevant personnel clearly see the actual meaning of the transaction and ensure the approval result corresponds to the final content to be signed; at the signing and custody stage, protect keys, devices, and operational permissions; after execution, monitor abnormal transactions and complete reconciliation between on-chain records and internal accounts. Each step requires clear responsibility assignment and records that can correspond to one another.

The most easily overlooked are operations that do not directly transfer funds but change control over assets, such as modifying recipient address whitelists, raising limits, changing signers, or updating wallet software. Recovery processes also need separate design and drills: when key personnel leave, devices are damaged, or service providers are interrupted, institutions must be able to restore control while retaining necessary multi-person authorization, and backup paths must not become vulnerabilities in daily permission management.

Gate Security Team: At Gate, institutions can typically manage funds through main accounts and sub-accounts, and then set different operational permissions for employees in different roles. For example, some can only view accounts, some can trade, and others are responsible for approvals. This meets daily work needs while reducing unnecessary fund risk.

For asset management institutions, we also provide dedicated custody sub-accounts. It mainly solves one problem: investors want to entrust funds to a professional team to operate but do not want the other party to take the funds. Specifically, after an investor creates a custody sub-account, they cannot create API Keys for programmatic operations themselves; the trading team can execute trading strategies as agreed but has no withdrawal permission. At the same time, during the cooperation period, the investor also cannot view the trading team's positions, open orders, and history, preventing trading strategies from being leaked.

For more specific API security settings, because most institutional operations are completed programmatically, with manual orders accounting for only a small portion. Therefore, our API Keys support fine-grained permission configuration, with read, trade, and withdraw able to be set separately.

Q4. When regulators evaluate a platform or project, what security and compliance issues do they focus on most?

CertiK: Regulators first need to determine whether the platform can continuously control assets, keep critical services running, and explain how problems were discovered and handled when risks occur. For trading platforms, this involves client asset custody, account reconciliation, permission management, anti-money laundering, and incident response; for central bank digital currency systems, the integrity of issuance and ledgers, payment continuity, and accurate recovery after failures are more critical. The two types of systems have different businesses, but both require testable and reviewable evidence.

This is also the practical issue involved in CertiK's recent cooperation with the Kyrgyz central bank. The memorandum signed by both parties is intended to conduct exchanges and exploration around digital som security assessment, 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 concrete results: who holds key permissions, whether high-risk issues have been remediated, how abnormal transactions are handled, and whether services and accounts can be restored after failure drills.

Gate Security Team:

The issues CertiK mentioned are also what we have experienced firsthand when applying for and maintaining relevant licenses in different countries and regions.

When people usually talk about platform security, they tend to focus more on whether the technology is advanced. But from a regulatory perspective, there is another very important question: are user funds and the platform's own funds truly managed separately? Once a problem occurs, can it be clearly determined who each asset belongs to?

This is also the important significance of proof of reserves. For ordinary users, it helps confirm whether the platform has sufficient assets to repay user balances; for regulators, it is also an important basis for examining a platform's asset management.

Take Gate as an example. The platform is the first to use Merkle trees and zero-knowledge proof technology to let users verify whether their assets are included while also protecting user information. The latest data shows that Gate's total reserves are $8.688 billion, with an overall reserve ratio of 118.49%. Among them, Bitcoin reserves are 25,727 BTC, with a reserve ratio of 121.60%; Ethereum reserves are 449,042 ETH, with a reserve ratio of 123.78%.

Simply put, a reserve ratio above 100% means that the corresponding asset reserves disclosed by the platform exceed users' related asset balances.

Q5. When institutions choose an asset trading platform, how should they judge whether the platform is secure? What information can they check and verify themselves?

CertiK: When choosing a platform, institutions should first clarify whether the security evidence covers the services, systems, and versions they actually use. Which components did the audit report evaluate? Have the issues found been remediated? Who can transfer assets or modify key permissions? If custody is involved, they should also understand how key control, asset reconciliation, backup recovery, and third-party dependencies operate.

At CertiK, through Skynet, we organize complex on-chain and off-chain signals into more intuitive, continuously updated ratings. Taking Web3 projects as an example, the rating presents information across six dimensions: code security, fundamental health, operational resilience, community trust, market stability, and governance capability, helping institutions quickly identify risk points worthy of further verification. Institutions can also view a project's publicly disclosed CertiK audit reports, specific findings, and remediation status on Skynet, and then check whether the report scope matches the currently deployed version. Exchanges and wallets have their own applicable assessment information; for internal permissions and custody arrangements that cannot be explained on public pages, institutions should still require the platform to provide materials and verify them through due diligence or controlled testing.

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

First, look at reserves. Take Gate as an example. The platform has open-sourced the source code of its reserve verification program, which users can view and download on GitHub. Combined with their own corresponding verification data, they can locally check whether their account balance is correctly included.

Second is the bug bounty program. Simply put, it is whether the platform is willing to pay external security researchers to help find system vulnerabilities for regular optimization. You can pay attention to whether the program runs long-term, whether the rewards are reasonable, and whether the platform responds promptly after problems are found. For example, Gate has long run a security vulnerability bounty program and welcomes security researchers worldwide to submit findings.

Third is licenses. Institutions need to confirm in which countries and regions the platform has obtained relevant permits, which company the license corresponds to, and whether it is still valid. It should be noted that holding a license does not mean the platform is absolutely secure, but it means the platform needs to meet the regulatory requirements of the corresponding region.

Q6. For an institution just beginning to allocate crypto assets, what should be prioritized first?

CertiK: First determine the allocation purpose and risk boundaries: which assets to hold, through which platforms, chains, and counterparties to conduct business, and what range single-transaction and overall exposure should be controlled within. Then clarify who is responsible for initiation, approval, signing, reconciliation, and incident handling, and decide what permissions each party holds when choosing self-custody, third-party custody, or a combination of both.

Before the first transfer, the recipient and address should also be verified. In CertiK's research on institutional digital asset counterparties, we emphasized that an on-chain address itself cannot prove who is behind it or who controls it; address control, risk history, and counterparty information need to be checked together. After completing platform due diligence, institutions can use small pilots to run through trading, withdrawal, and reconciliation, and drill handling of device failures or service interruptions, then gradually expand scale based on the results.

Gate Security Team: For institutions just beginning to allocate crypto assets, we have four suggestions.

First, do not put all your eggs in one basket. Funds needed for daily trading, medium-term reserves, and funds not intended to be touched for the long term should be managed separately and assigned different usage limits. This is best planned before opening an account; otherwise, once business is already running, adjusting the fund management approach will be much more difficult. For assets not needed for the long term, you can also consider custody solutions with a 48-hour delayed transfer mechanism—an extra layer of checking time that leaves room for handling abnormal situations.

Second, assign different operations to different people. Initiating transfers, approving transfers, and actually executing transfers should preferably not all be completed by the same person. Through sub-accounts and employee permission settings, basic segregation of duties can be achieved without necessarily developing additional systems.

Third, strictly manage keys used for programmatic operations. By default, do not enable withdrawal permissions; every key should have a clear purpose and responsible person, and rules should be set in advance for when it needs to be revoked or deleted.

Fourth, conduct background checks before choosing a platform. For example, whether the reserves mentioned earlier can be verified, who holds the funds, whether there is a bug bounty program, and whether relevant licenses are valid—all of these should be understood clearly in advance.

From personal wallets to institutional assets, the more funds managed and the more people involved, the more complex the risks that need to be considered. But no matter what scenario we face, the core of security is always to discover risks in advance and avoid losses from actually occurring as much as possible.

This is also the philosophy the "Gate Security Course" hopes to convey: security should not be valued only after problems occur, but should become a habit in every operation and every decision.

Thank you to CertiK and the Gate security team for sharing. See you in the next edition of "Gate Security Course"!

Disclaimer

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