Gate Security Course 03 | Gate & GoPlus: How to Read Audit Reports and Identify Contract Vulnerabilities

Security is a dynamic state, not a piece of paper certification. Many of the projects that got hacked this year had been audited, some of them multiple times. This doesn't mean audits are worthless—it just means that what an audit can answer is far narrower than most people assume.

An audit report describes a specific version that a specific team reviewed on a specific day. But contracts get upgraded, permissions get changed, the oracles and cross-chain bridges a project relies on change, and new attack techniques emerge every week. The moment a report is delivered, it begins to expire. Even trickier are the old contracts deployed years ago that passed audits back then—they're now being re-scanned in bulk, and a contract that's been live for years can have its deep vulnerabilities uncovered in a matter of minutes.

This is the third installment of Gate's special series "The Gate Security Course." We invited Web3 security service provider GoPlus Security and the Gate security team to discuss audits and vulnerability hunting from two perspectives—that of a security service provider and that of a trading platform: why audited projects still get into trouble, how to read a report, what checks a platform performs before and after listing, and how ordinary users can do a round of self-checks before signing.

Guest Introductions

Adam, Partner at GoPlus: 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, leveraging blockchain and cutting-edge AI security solutions to provide 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: Gate's 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 on an ongoing basis.

Founded in 2013, Gate was the industry's first trading platform to introduce 100% reserve proof and currently serves more than 60 million users worldwide. Security is the precondition for this business to exist, and through "The Gate Security Course," we hope to clearly explain the common mechanisms behind these real risks.

Q1. Why do many projects still get hacked or suffer permission abuse after passing an audit?

Adam, Partner at GoPlus: "A one-time audit" does not equal "permanently secure." Traditional contract audit services now suffer from four structural failures:

1) Snapshot-style inspection. An audit is essentially a semi-manual review by audit engineers at a certain point in time, and its effectiveness depends on tool quality, individual skill, and work conditions. But contract code gets upgraded, admin 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) Out-of-control external dependencies. Projects commonly rely on oracles, cross-chain bridges, and third-party protocols, and changes in the risk of these dependencies fall outside the scope of traditional audits.

4) Concentrated blowups of old contracts. Contracts deployed years ago that were "audited" back then are being re-mined for vulnerabilities in bulk by automated tools—for example, deep vulnerabilities in Balancer and Yearn that went undiscovered for years after they officially launched.

As for permission abuse, it mostly happens at the operational stage rather than in the contract code itself. Causes include: excessive Owner permissions (able to arbitrarily mint, blacklist, or pause trading), leakage of admin private keys, improper multisig management, malicious proposals, and governance attacks... These are all security issues that tend to arise at the operational stage. Even if an audit report flags permission risks, who watches them afterward? Whether operations are secure and reasonable cannot be answered.

Launching after a contract audit is only the starting point of security work, not the end. What projects need is continuous security covering the entire lifecycle of the contract, not a one-time audit report.

Gate Security Team: An audit can tell users what the code can do, but it cannot tell users what the project team intends to do.

This is the point we've felt most deeply over the years of doing listing reviews. The root cause of many incidents lies in the project team's intent. A contract can be technically fully compliant, and the owner permission design can be within normal range, but the project team can still pick a moment to put those permissions to use: changing trading rules, enabling blacklists, minting tokens. At the code level, all of these actions are perfectly legal, and audit reports won't flag them as vulnerabilities, because they are part of the design in the first place.

So beyond technical audits, there needs to be another layer of constraint. Gate's approach is to conduct strict project screening and review at the listing stage, while also signing non-maleficence declarations with project teams and supervising compliance. This layer addresses exactly what audits cannot: the absence of code vulnerabilities does not mean the team won't make choices that harm users.

For listed projects, we conduct regular security audits and use on-chain event monitoring to track contract status, and users can check the current risk items of any contract at any time.

Q2. Since a one-time audit doesn't equal permanent security, how should project teams and the industry as a whole adjust?

Gate Security Team: The crypto industry has a structural characteristic: a large portion 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 providers, web interfaces, and the systems used to push updates.

So beyond whether your own contract is secure, the more important question is whether every link you depend on is still reliable. When a component upstream fails, losses propagate down the chain. Looking back at major attacks, the problems often arise earlier than the protocol logic: suppliers, development tools, the way software reaches users, or the process by which users approve transfers.

Adam, Partner at GoPlus: The attack paradigm in which hackers use automated tools to efficiently mine vulnerabilities has taken shape and is spreading rapidly. Attacks have gone from "expert manual research" to "assembly line." If the industry's thinking remains stuck on "hire an audit firm to produce a report before launch," or "find a security firm to mend the fold after a risk is discovered," it's like fighting machine guns with bows and arrows. Using equally efficient tools to counter attacks is the only effective path.

The direction for industry-level adjustment 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—a workable closed loop:

Before launch, Token security self-check: a few minutes for a quick self-check of backdoor risks such as honeypots/scam tokens, malicious minting (Mint), blacklists, abnormal transaction taxes, and Owner permissions;

At launch, AI contract audit: in-depth analysis of source code, permission management, and business logic, scanning for vulnerabilities at the syntax level and business logic level, and delivering a structured audit report;

After launch, continuous security monitoring and regular health checks: real-time tracking of new vulnerability intelligence, attack incidents, and external dependency risks (oracles, cross-chain bridges, third-party protocols), continuously determining whether the project is affected and providing routine alerts. Regular security health checks and continuous audits of contracts.

Q3. How has the way vulnerabilities are discovered changed over the past two years? For the same asset, how does the security model differ between holding it on-chain versus on an exchange?

Adam, Partner at GoPlus: Frankly speaking, in the short term, attackers' methods of finding vulnerabilities have become more diverse. There are three reasons:

1) Automated tools have drastically lowered the barrier to finding vulnerabilities. What used to take top security researchers weeks can now be run through an attack pipeline in minutes;

2) A massive number of old contracts "audited back then" have accumulated on-chain, forming 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 took hackers only minutes to extract this money, and it actually only takes defenders a few minutes to find the same vulnerabilities. The only difference is whether the project team has correctly put the tools to use before the hackers do.

More importantly, defenders have three structural advantages that attackers don't:

1) First-mover advantage: defenders can re-check unlimited times before launch and during operations, while attackers can only bet that the defenders haven't done the re-check;

2) Cost advantage: AI audits are charged per session or annually, and the cost is low enough to be routine and full-scale;

3) Knowledge compounding: the security knowledge base continuously evolves with each new attack incident, and the defense system grows stronger the more it's used.

Between the on-chain and off-chain models, "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's no "customer service" to appeal to; every interaction carries on-chain risk (approval vulnerabilities, phishing signatures, honeypots); the advantage is that your assets don't depend on any platform's credit.

Exchange custody: security = platform security + account security. Private keys are managed by the platform (cold/hot wallet separation, multisig, risk controls), which amounts to outsourcing "technical security" to the exchange; but you also need to properly protect your exchange account security (passwords, 2FA, phishing, API Keys, etc.), and you must be sure to choose an exchange with reliable platform credit.

Overall, on-chain is "private key protection + self-operation risk," while exchanges are "platform credit + security infrastructure risk." The former tests your Web3 security awareness, while the latter tests the exchange's platform 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 and continuously track contract status through on-chain event monitoring. Whether contracts have been upgraded, whether permissions have changed, and whether abnormal large transactions have occurred—these all need ongoing attention, because a check conclusion made at listing time, like the audit reports Adam mentioned, also has a shelf life. Users can also check the current risk items of any contract at any time.

Now for 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: sec@gate.com, support tickets, and the HackenProof platform. We require project teams to undergo checks, and we must undergo checks ourselves too—this shouldn't be a one-way requirement.

Having covered coins and the platform, let's talk about accounts.

Our advice is not to look for that "safest place," but rather to divide your money by frequency of use—that's more practical: keep funds you trade frequently in your spot account for easy access; put funds you won't touch for six months to a year into the Gate Safe.

The Safe 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 the third party can initiate a transaction alone. All outgoing transfers also require a 48-hour waiting period before funds arrive. These 48 hours are a safety buffer for users, during which the transfer can be frozen at any time. In most theft cases, users notice something is wrong later than the attackers, and once an on-chain transfer goes out, it can't be reversed—but during these 48 hours in the Gate Safe, 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.

Next, the second point: Gate's account security protection program.

The Gate 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 say 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, the protection program can be activated. Activation means that after users have done their part in protection, there's an additional safety net: 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 cap per incident currently at up to $200,000. This cap will be increased going forward, tiered by VIP level up to $1 million. Applications must be submitted within 45 days of the incident through "My Protection" by contacting security customer service, with materials including police reports 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 sit in an archive) should contain at least four elements:

1) Security score (a 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 clearly 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 the 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 remediation plans), used to "close the loop." Remediation recommendations must be specific to the code level and actionable, and after remediation, a re-scan and regression verification must be performed, forming a complete loop of "score, key findings, issue details, remediation, re-scan."

Gate Security Team: We'd like to add three points from our practice of building the contract audit feature.

First, what's 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 judgment, vulnerability details, risk paths, threat model, key function analysis, and remediation recommendations. What determines whether readers will misread the entire report is the first two items. If limitations aren't clearly stated, readers will assume it covers everything; if scope isn't clearly stated, readers can't tell whether it audited only the main contract or also the fund pool, strategy contracts, oracles, and external dependencies. Much of the promotion just says "audited," without saying what was audited—such statements carry basically no information.

Second, when looking at key findings, consider together those risks that wouldn't count as vulnerabilities individually. Take a common combination in reports: the contract owner can blacklist addresses and freeze assets, trading pairs can be reset, preventing ordinary users from transferring funds, minimum holding requirements can prevent users from fully selling, and a single owner can change multiple key rules at any time. Viewed separately, all four are normal design; combined, they mean control of this contract is highly concentrated in one person's hands.

Third, you need to know how the report was generated, because that determines its reliability boundary. Our contract audit has 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 contract's core interaction scenarios to validate business paths and boundary conditions and find issues that rule-based scanning can't 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 eventually they'll skip the entire check process—so the false positive rate directly determines whether the 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 token, verify the token's own security, and watch for backdoor risks such as honeypots/scam tokens, 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 problems with "contracts you once approved."

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 domains before signing, don't click links