Security is a dynamic state, not a piece of paper certification. Many of the projects hacked this year had been audited, and some had been audited multiple times. This does not mean audits have no value; it only means that the questions audits can answer are far narrower than most people assume.
An audit report describes a certain version that a certain team looked at on a certain day. But contracts get upgraded, permissions get changed, the oracles and cross-chain bridges that projects depend on change, and new attack techniques emerge every week. The moment the report is delivered, it begins to expire. What is even more troublesome is that old contracts deployed years ago that passed audits smoothly back then are now being re-scanned in batches, and deep vulnerabilities in a contract that has been live for years can be found in just over ten minutes.
This is the third installment of Gate's special feature "Gate Security Course." We invited Web3 security service provider GoPlus Security and the Gate security team to discuss audits and vulnerability screening from the perspectives of a security service provider and a trading platform: why audited projects still get into trouble, how to read a report, what checks the platform performs before and after listing, and how ordinary users can do a round of self-checks before signing.
Guest Profiles
GoPlus Partner Adam: Adam is a partner at GoPlus and head of its security research institute.
GoPlus Security is building the first decentralized security layer for Web3 and AI. By leveraging blockchain and cutting-edge AI security solutions, it provides users with intelligent, efficient, and decentralized security products and services. Since 2022, GoPlus has achieved exponential growth, reaching 30 million daily API calls and preventing nearly $100 billion in potential losses for users.
Gate Security Team: The Gate security department is responsible for building the platform's account, trading, and asset security systems, and also handles user appeals and assistance requests regarding abnormal accounts over the long term.
Founded in 2013, Gate is the industry's first trading platform to launch 100% proof of reserves and currently serves more than 60 million users worldwide. Security is the prerequisite for this business to be viable, and through "Gate Security Course," we hope to clearly explain the common mechanisms behind these real risks.
Q1. Why do many projects still get hacked and still suffer permission abuse after passing audits?
GoPlus Partner Adam: "A one-time audit" does not equal "always secure." Traditional contract audit services now suffer from four structural failures:
1) Snapshot-style inspection. An audit is essentially a semi-manual inspection by audit engineers at a certain point in time, and its effectiveness depends on tool quality, individual skill, and work status. But contract code gets upgraded, administrative permissions get changed, and parameter configurations get adjusted. From the moment a one-time audit report is delivered, it is "expiring."
2) Inability to predict the future. New vulnerability types and new attack techniques keep emerging, and historical audits cannot cover future risks.
3) Uncontrolled external dependencies. Projects commonly depend on oracles, cross-chain bridges, and third-party protocols, and risk changes in these dependencies are outside the scope of traditional audits.
4) Concentrated blowups of old contracts. Contracts deployed years ago that were "audited" back then are being rediscovered in batches by automated tools, such as deep vulnerabilities in Balancer, Yearn, and similar projects that went undiscovered for years after going live.
As for permission abuse, it occurs more in the operational phase than in the contract code itself. Reasons include: excessive Owner permissions (ability to arbitrarily mint, blacklist, or pause trading), leakage of administrator private keys, improper multisig management, malicious proposals, and governance attacks... These are all security issues that easily arise in the operational phase. Even if an audit report flags permission risks, who will keep watching afterward? Whether operations are secure and reasonable cannot be answered.
Going live after a contract audit is only the starting point of security work, not the end. What projects need is continuous security covering the entire contract lifecycle, not a one-time audit report.
Gate Security Team: Audits can tell users what the code can do, but they cannot tell users what the project team intends to do.
This is the point we have felt most deeply in our years of doing listing reviews. The root cause of many incidents lies in the project team's intentions. A contract can be technically fully compliant, and the design of owner permissions can be within the normal range, but the project team can still pick a moment to use those permissions: changing trading rules, enabling blacklists, or minting additional tokens. These actions are all legal at the code level, and audit reports will not flag them as vulnerabilities because they are part of the design in the first place.
So beyond technical audits, there must be another layer of constraint. Gate's approach is to conduct strict project screening and review during the listing process, while also signing non-maleficence declarations with project teams and supervising compliance. This layer is meant to solve the part that audits cannot solve: the absence of code vulnerabilities does not mean the team will not make choices that harm users.
For listed projects, we conduct regular security audits and use on-chain event monitoring to track contract status. Users can also check the current risk items of a given contract at any time.
Q2. Since a one-time audit does not equal continuous security, how should project teams and the industry as a whole adjust?
Gate Security Team: The crypto industry has a structural characteristic: a large part of its business, especially DeFi, operates in a mode close to modular finance. Various platforms are built from shared components: contracts, software libraries, wallets, price oracles, cross-chain bridges, connectivity service providers, web interfaces, and systems used to push updates.
So beyond whether your own contracts are secure, the more important question is whether every link you depend on remains reliable. If a component upstream fails, losses propagate down the chain. Looking back at major attacks, the problem often lies in links earlier than the protocol logic: vendors, development tools, the way software reaches users, or the process by which users approve transfers.
GoPlus Partner Adam: The attack paradigm in which hackers use automated tools to efficiently mine vulnerabilities has already taken shape and is spreading rapidly. Attacks have shifted from "expert manual research" to an "assembly line." If the industry's thinking is still stuck on "find an audit firm to issue a report before launch," or "find a security company to fix things after a risk is discovered," it is like using bows and arrows against machine guns. Using equally efficient tools to counter attacks is the only effective path.
The direction of adjustment at the industry level is to upgrade from "one-time audits" or "finding experts after problems arise" to "continuous security across the full lifecycle." Take GoPlus DeepScan's "contract security trio" as an example; this is a closed loop that can be implemented:
Before launch, token security self-check: quickly self-check in minutes for backdoor risks such as honeypots, malicious minting, blacklists, abnormal transaction taxes, and Owner permissions;
At launch, AI contract audit: deeply analyze source code, permission management, and business logic, scan for vulnerabilities at the syntax layer and business logic layer, and deliver a structured audit report;
After launch, continuous security monitoring and regular health checks: track new vulnerability intelligence, attack incidents, and risks from external dependencies (oracles, cross-chain bridges, third-party protocols) in real time, continuously determine whether the project is affected, and provide routine alerts. Conduct regular security health checks and continuous audits of contracts.
Q3. How have vulnerability discovery methods changed over the past two years? For the same asset, what is the difference in security model between holding it on-chain and holding it on an exchange?
GoPlus Partner Adam: Frankly speaking, in the short term, attackers' methods of finding vulnerabilities have become more diverse. There are three reasons:
1) Automated tools have greatly lowered the threshold for finding vulnerabilities. Work that once required top security researchers weeks to complete can now be run through an attack pipeline in minutes;
2) A massive number of old contracts that were "audited back then" have accumulated on-chain, making them a "gold mine" with huge reserves for attackers;
3) Attacks are one-way monetization: finding "one" vulnerability is enough, while defenders must guard against "all" vulnerabilities.
It takes hackers only a few minutes to extract this money, and it actually takes defenders only a few minutes to find the same vulnerability. The only difference is whether the project team has correctly put the tools to use before the hackers do.
More critically, defenders have three structural advantages that attackers do not:
1) First-mover advantage: defenders can recheck unlimited times before launch and during operations, while attackers can only bet that defenders have not done the recheck;
2) Cost advantage: AI audits are charged per use or annually, with costs low enough to be routine and full-scale;
3) Knowledge compounding: the security knowledge base continues to evolve with each new attack incident, and the defense system becomes stronger the more it is used.
In the two models, on-chain and off-chain, "who is protecting your assets" and "the types of risks you face" are completely different.
On-chain self-custody: Security = private key security + contract security. You are the sole party responsible for security—if your private key is lost or stolen, there is no "customer service" to appeal to; every interaction carries on-chain risk (approval vulnerabilities, phishing signatures, honeypot scams); the advantage is that your assets do not depend on any platform's creditworthiness.
Exchange custody: Security = platform security + account security. Private keys are managed by the platform (hot/cold wallet separation, multisig, risk controls), which is equivalent to outsourcing "technical security" to the exchange; but you also need to properly protect your own exchange account security (password, 2FA, phishing, API Key, etc.), and at the same time be sure to choose an exchange with reliable platform creditworthiness.
Overall, on-chain is "private key protection + self-operation risk," while exchanges are "platform creditworthiness + security infrastructure risk." The former tests your Web3 security awareness, while the latter tests the exchange platform's infrastructure and your account security habits.
Q4. As a trading platform, what security improvements has Gate made?
Gate Security Team: First, we conduct regular security audits of listed projects, while continuously tracking contract status through on-chain event monitoring. Whether a contract has been upgraded, whether permissions have changed, and whether abnormal large-value operations have occurred—these all need continuous monitoring, because a check conclusion at the time of listing, like the audit reports Adam mentioned, also has a shelf life. Users can also check the current risk items of a given contract at any time.
Now regarding the platform itself. Gate's security vulnerability bounty program has always been open, and security researchers worldwide can submit issues they find to us through three channels: [email protected], support tickets, and the HackenProof platform. We require project teams to undergo inspection, and we must undergo inspection ourselves as well—this should not be a one-way requirement.
Having covered coins and the platform, now let's talk about accounts.
Our advice is not to look for that "safest place," but rather to split your money by usage frequency, which is more practical: keep funds you trade frequently in your spot account for随时 access; put funds you won't touch for six months to a year into Gate Vault.
The Vault uses MPC plus 2-of-3 signatures. The private key is split into three shards, held respectively by the user's device, Gate, and an independent third party. The complete private key is never assembled at any point, and neither Gate nor that third party can initiate a transaction alone. All withdrawals also require a 48-hour waiting period before funds arrive—these 48 hours serve as a security buffer for users, during which the withdrawal can be frozen at any time. In most theft cases, users notice something is wrong later than the attacker, and once an on-chain transfer goes out it cannot be reversed—but during these 48 hours in Gate Vault, users can freeze it at any time. Even if something does go wrong, the 48-hour delay gives you time to discover and freeze it.
Now the second point: Gate's Account Security Protection Program.
Gate's Account Security Protection Program is based on a security score. Account security settings were originally scattered across various pages—login verification, authenticator, two-factor verification, passkeys, trading limits, withdrawal limits—and it was hard for users to tell exactly which steps they had completed. The security score converts these items into a score from 0 to 100, so you can see at a glance which ones are enabled and which are still missing; when the score changes, the system also reminds users to complete them.
Once the security score reaches 80 and the account is in normal status, you can activate the protection program. After activation, it means that after users have done their own protection properly, there is an additional layer of fallback: during the protection period, if assets in the account are transferred out without authorization, users can apply for compensation if the rules are met, with the current maximum per-incident amount being USD 200,000. This limit will be increased going forward, tiered by VIP level up to a maximum of USD 1 million. Applications must be submitted within 45 days of the incident through "My Protection" by contacting security customer service, with materials including police report records and asset transfer records.
Q5. What should a complete audit report contain? How should the security score, key findings, and remediation recommendations each be used?
Adam, Partner at GoPlus: An audit report that can guide action (rather than just be filed away) should contain at least four elements:
1) Security score (quantifiable rating), used for "quick screening," not for "final conclusions." Project teams can use the score as a quantitative anchor for internal security assessments, comparing changes after each iteration; exchanges can use it for initial listing screening to keep obviously substandard projects out at the first gate; ordinary users can treat the score as an "entry point"—avoid low scores outright, and for high scores, look further at the key findings.
2) Key findings (high-risk issues and core conclusions), used for "decision-making." This is the report's "executive summary": which issues are blocking-level and must be fixed before launch. For managers with non-technical backgrounds and listing review teams, understanding the key findings is enough.
3) Issue details (vulnerability evidence and impact description), used to "locate problems." This is the part for the technical team, including vulnerability location (precise to contract, function, and line of code), vulnerability type, severity level, attack path description, and root cause analysis. Good issue details should provide a reproducible execution path and trigger conditions, not just a list of issues.
4) Remediation recommendations (actionable rectification plans), used to "close the loop." Remediation recommendations must be specific to the code level, actionable, and after remediation a re-scan regression verification must be performed, forming a complete loop of "score, key findings, issue details, remediation, re-scan."
Gate Security Team: We would like to add three points from our practice of building contract audit features.
First, what is most easily omitted is precisely the first two items: audit objectives and limitations, and scope description. We defined eight dimensions for reports—audit objectives and limitations, scope description, severity matrix, priority determination, vulnerability details, risk paths, threat model, key function analysis, and remediation recommendations—and what determines whether readers will misread the entire report is precisely the first two items. If limitations are not clearly stated, readers will assume it covers everything; if scope is not clearly stated, readers cannot tell whether it audited only the main contract or also the liquidity pool, strategy contracts, oracles, and external dependencies. Many promotional claims only say "audited" without saying what was audited—such statements basically carry no information.
Second, when looking at key findings, risks that individually do not count as vulnerabilities should be viewed together. Take a common combination in reports: the contract owner can blacklist addresses to freeze assets, the trading pair can be reset causing ordinary users to be unable to transfer, a minimum holding requirement prevents users from fully selling, and a single owner can change multiple key rules at any time. Viewed separately, all four are normal design; taken together, they mean control of this contract is highly concentrated in one person's hands.
Third, you need to know how the report is generated, because this determines its reliability boundary. Our contract audit proceeds in three steps: first, static analysis to check basic risks such as permission control, reentrancy, price manipulation, flash loans, and logical consistency; then business scenario modeling, extracting the core interaction scenarios of the contract, verifying business paths and boundary conditions, and finding issues that rule-based scanning cannot cover; finally, semantic verification, checking key business paths item by item to confirm whether the risks identified in the first two steps actually hold. The third step is mainly to reduce the false positive rate. A report full of false positives will quickly lose users' patience, and they will eventually skip the entire inspection step altogether—so the false positive rate directly determines whether this tool will actually be used.
Q6. For ordinary users, what hardening actions can be done right now?
Adam, Partner at GoPlus:
1) Check Token security before trading. Before buying a new coin, check the Token's own security, and watch for backdoor risks such as honeypot scams, malicious minting, blacklists, abnormal transaction taxes, and excessive Owner permissions.
2) Regularly clean up contract approvals. Revoke Approvals for DApps you no longer use, especially unlimited approvals—many thefts stem from "contracts you once approved" having problems.
3) Harden at the account level. Use strong passwords and enable 2FA; manage API Keys with least privilege, and never grant withdrawal permissions to untrusted tools.
4) Make anti-phishing a muscle memory. Verify the domain before signing, do not click links in private messages, and by default distrust "airdrops/customer service/high-yield staking"; phishing content is increasingly convincing, so always stay rational.
5) Store assets in layers by purpose. Keep only a small amount of funds you need to use in hot wallets; for large assets, use hardware wallets—don't put all your eggs in one basket.
6) Focus on a project's "security attitude" rather than its "audit report." Whether there is continuous auditing and a security monitoring mechanism is more important than an audit report from years ago; prioritize projects that value security and are willing to publicly disclose their security construction mechanisms.
Gate Security Team: Adam's six points are already quite complete. We would like to combine them with Gate's tools to turn several of them into operations you can do right away.
1) Check Token before trading—here you can directly use Gate AI's contract audit feature. Submit the contract address and get a report in minutes; focus on four items: owner permissions, blacklist and trading restrictions, minting permissions, and transfer tax. If any one of these four is flagged red, you should stop—no need to look further.
2) Harden your account—first get your security score above 80. Fund password, authenticator, two-factor verification, anti-phishing code, passkeys, daily withdrawal limit, withdrawal method management—these protection items are all on the checklist; just follow the prompts and complete them one by one. The greatest value of the security score is turning settings scattered everywhere into an ordered checklist, so you don't have to decide which one to do first. Reaching 80 or above also lets you activate the Account Security Protection Program, which means an extra layer of fallback after you have hardened your own account properly.
3) There are two ready-made tools for anti-phishing. If you receive a message claiming to be from Gate, first check the official verification channel to see whether the domain or email is ours; all emails sent by Gate will include the anti-phishing code you set yourself—any without this code is fake.
4) Before signing, check the approval amount clearly. The contract itself being fine does not mean the transaction the page asks you to sign is fine. A normal DApp can absolutely request only the amount needed for this transaction; asking for unlimited approval right away is itself worth pausing over. If the popup contains only a string of incomprehensible characters, refusing is always safer than signing first and asking questions later.
Finally, we want to say that security is dynamic, not static.
Going live after an audit is only the starting point of security work. For project teams, this means that continuous monitoring after launch is more important than the report itself; for trading platforms, it means that listing is only the beginning of review; and for ordinary users, those few minutes of self-check before signing are the lowest-cost step, and also the one most easily skipped.
Security has never been a one-and-done certification. If all parties take one more step, the balance between attack and defense will tip in favor of us "gatekeepers."
Let's meet at the fourth session of "Gate Security Course" together!
