Gate and GoPlus say AI is reshaping crypto security, and one-off audits are no longer enough

Gate and Web3 security provider GoPlus Security used the third edition of Gate’s special “Security Class” series to examine how AI is changing crypto security. The discussion centered on a few practical questions: why projects can still be hacked after passing an audit, how AI is changing the pace of attack and defense, and what tools ordinary users can use to reduce risk before they sign anything.

The article opens with a simple point: security is dynamic, not static. A project may have been audited by a large firm, but contracts get upgraded, permissions change, oracles and cross-chain bridges change, and new attack methods keep appearing. A report remains frozen at the moment it was delivered. In the article’s framing, AI has made that gap much larger. Attackers can now scan contracts in minutes and recheck old code deployed years ago and no longer maintained. If defenders still rely on a single pre-launch audit, the gap keeps widening.

How GoPlus and Gate describe their roles in security

Adam, a partner at GoPlus, is introduced as the head of the company’s security research institute. GoPlus Security says it is building what it calls the first decentralized security layer for Web3 and AI, using blockchain and AI-based security solutions to provide security products and services. According to the article, GoPlus has grown rapidly since 2022, with daily API calls reaching 30 million and with the company helping users avoid nearly $100 billion in potential losses.

Gate’s security team says it is responsible for the platform’s account, trading, and asset security systems, and that it also handles abnormal account appeals and investigation requests from users. Gate says it was founded in 2013, was the first exchange in the industry to launch 100% proof of reserves, and now serves more than 60 million users globally. The team says security is not an add-on feature but a condition for the business to exist.

Why audited projects still get hacked

On the question of why many projects still get hacked or see permission abuse after passing an audit, Adam says the problem comes from four structural failures in traditional audit work.

• Snapshot-based review. He says an audit is essentially a semi-manual review performed by engineers at a specific point in time, and the result depends on tool quality, individual skill, and working conditions. Contracts get upgraded, admin permissions change, and parameters are adjusted. From the moment a one-time audit report is delivered, it starts to age.
• It cannot predict the future. New vulnerability classes and new attack methods keep appearing, so historical audits cannot cover future risk.
• External dependencies move outside the audit boundary. Projects often depend on oracles, cross-chain bridges, and third-party protocols, and changes in those risks usually sit outside the scope of a traditional audit.
• Old contracts are blowing up in clusters. Adam says contracts deployed years ago and “audited” at the time are now being re-examined by AI at scale. He cites Balancer and Yearn as examples of projects where deep vulnerabilities can remain undiscovered for years after launch.

On permission abuse, Adam says the issue tends to emerge during operations rather than in the contract code itself. The article lists several causes: owner permissions that are too broad and allow arbitrary minting, blacklisting, or trading pauses; leaked admin private keys; poor multisig management; malicious proposals; and governance attacks. Even if an audit report flags permission risk, he says, the report does not answer who will keep watching afterward or whether later actions are safe and reasonable.

Gate’s security team adds a separate point from the exchange listing perspective: an audit can tell users what code can do, but not what a project team intends to do. The team says many incidents begin with intent. A contract may be technically compliant, and owner powers may fall within a normal design range, yet the project team can still choose to use those powers later to change trading rules, activate a blacklist, or mint more tokens. Those actions are legal at the code level and part of the design, so an audit report will not mark them as vulnerabilities.

Because of that, Gate says technical auditing needs another layer of constraint. Its approach is to apply strict project screening and review during the listing process, sign a non-malicious conduct declaration with project teams, and monitor whether those commitments are honored. In Gate’s view, this addresses the gap that audits cannot close: code without bugs does not mean a team will not make choices that hurt users.

Gate also says listing is only the beginning. The exchange conducts regular security audits on listed projects and continuously tracks contract status through on-chain event monitoring. Users can also check the current risk items of a contract at any time.

For users, Gate says it has added a contract audit function to Gate AI. When users encounter an unfamiliar contract, they can submit a contract address, source code file, or GitHub link and receive a structured risk report within minutes. The report covers more than 57 vulnerability types and highlights owner permissions, blacklist mechanisms, minting permissions, and transfer taxes, which the article describes as common design features used in malicious setups. Gate says the reason for building the feature is straightforward: audit reports are usually held by project teams, users often cannot access them, and many would not be able to read them anyway. What matters when someone is standing in front of a signing button is the contract’s current state.

AI is widening the cost gap, and the industry needs lifecycle security

Asked how the industry should respond to AI-driven threats, Adam says the first step is to admit that attack and defense costs are no longer balanced. In his view, hackers are already using AI to industrialize vulnerability discovery, turning attacks from expert manual research into automated pipelines. If defenders still rely on a single report before launch, or only call in a security firm after something goes wrong, he says the mismatch is like using bows and arrows against machine guns. The only workable path, he argues, is to use AI against AI.

At the industry level, Adam says the model needs to shift from one-off audits or post-incident expert intervention to continuous security across the full contract lifecycle. He uses GoPlus DeepScan’s “three-piece contract security toolkit” as an example of a practical loop:

• Before launch: token security self-checks that can quickly identify honeypots, malicious minting, blacklists, abnormal transaction taxes, and owner-permission backdoors in minutes.
• At launch: AI contract audits that analyze source code, permission management, and business logic, scan both syntax-level and business-logic vulnerabilities, and deliver a structured audit report.
• After launch: continuous security monitoring and periodic health checks that track new vulnerability intelligence, attack incidents, and risks in external dependencies such as oracles, cross-chain bridges, and third-party protocols. AI then keeps assessing whether a project is affected and issues routine alerts, while contracts are rechecked on a recurring basis.

He also lists four things that should be done now:

1. Recheck old contracts immediately. The article says contracts deployed years ago are the biggest current minefield, and AI audits have pushed review costs down to minutes or tens of minutes per scan, far below traditional manual audits.
2. Put live contracts on a regular scanning schedule. Adam says teams can scan daily or weekly and use the improving capabilities of LLMs and the constantly updated Security LLM Wiki knowledge base.
3. Add AI audits on top of traditional audits. He says the two are complementary rather than substitutes.
4. Embed tool-based review into exchange listing workflows. Without changing the original listing process, exchanges can use token security self-checks and AI contract audits to improve review efficiency, then use continuous monitoring as routine risk control after listing.

The article also points to a timing signal. In February 2026, OpenAI launched EVMbench, while GoPlus released DeepScan V1 and open-sourced AI Auditing Benchmark. Adam says AI auditing has moved from concept to industry standard-building.

Gate’s security team says AI has made attackers faster and easier to scale. Attackers can find vulnerabilities more quickly, run phishing campaigns at industrial scale, and use deepfakes to make social engineering harder to detect. The impact is especially strong in crypto, the team says, because much of the industry, especially DeFi, operates like modular finance. Platforms are built from shared components: contracts, software libraries, wallets, price oracles, cross-chain bridges, connectivity providers, web interfaces, and systems used to push updates.

That means teams need to ask not only whether their own contracts are safe, but whether every dependency is still trustworthy. If an upstream component fails, losses can travel down the chain. Gate says many major attacks begin earlier than protocol logic itself, in suppliers, development tools, the way software reaches users, or the process by which users approve transfers. AI has lowered the cost of finding those weak points and chaining them together.

Gate lays out three actions that should be taken now:

1. Map dependencies clearly. Maintain a live inventory of contracts, libraries, wallets, suppliers, cloud accounts, release systems, front ends, multisig wallets, admin keys, and validators, and review it regularly. The team says most organizations fail here because dependencies grow quietly: a temporary library, a cloud account opened to hit a deadline, or a key left behind by a former colleague may never be formally recorded and therefore never reviewed.
2. Limit the damage from any single failure. No individual, key, laptop, cloud login, or supplier should be able to bring down the whole system alone. Gate says control should be split across people and systems, proposal rights should be separated from execution rights, operational limits and waiting periods should be set, and emergency stop powers should be clearly defined. The team says the same principle is used in Gate’s own asset architecture, with hot and cold wallets separated, most assets stored in offline multisig cold wallets, and hot wallets using multisig plus multi-party computation, or MPC.
3. Treat websites and release processes as part of the vault. What users see and click is itself financial infrastructure. Gate says production builds should be reproducible and signed, and changes to websites, content delivery, domain settings, and the software supply chain should require two-person approval, time-limited access, and real-time alerts. The exchange says it has deployed Anycast and DNSSEC and uses encrypted transport-layer protocols for all data transmission so users reach Gate’s actual servers.

Gate says security resilience does not come from a one-time certification. AI has shortened the gap between finding and exploiting vulnerabilities, so exchanges, protocols, and infrastructure providers need to bring shared components into their protection scope and rehearse containment before the next cascading failure arrives.

Who benefits more from AI right now, attackers or defenders?

On whether attackers or defenders are gaining more from AI, Adam says attackers are ahead in the short term for three reasons.

1. AI has sharply lowered the barrier to finding vulnerabilities. Work that once took top security researchers weeks can now be run through an attack pipeline in minutes.
2. The chain holds a huge stock of old contracts that were “audited” years ago, which he describes as a large gold mine for attackers.
3. Attack is a one-way monetization game. Finding one exploitable flaw can be enough, while defenders have to protect against all of them.

Still, he says the window for defenders is opening quickly because the same AI capabilities can produce strong results on the defensive side. The article gives a set of review results from an AI audit engine on real 2026 attack cases:

• ZetaChain, with losses of about $300,000: detected within 5 minutes
• WhiteEagle: detected in 402 seconds
• HumaFinance: detected in 505 seconds
• BoostHook: detected in 20 minutes
• Token of Power, with losses of about $1.5 million and a 7-year-old contract: detected in 12 minutes
• JoeAgentToken: detected in 27 minutes

Adam’s point is that hackers used AI to steal that money in minutes, but defenders could also have found the same flaws in minutes. The difference is whether the project used AI correctly before the attacker did.

He also says defenders have three structural advantages that attackers do not:

1. First-mover advantage. Defenders can recheck contracts as many times as they want before launch and during operations. Attackers can only hope those checks never happened.
2. Cost advantage. AI audits can be priced per scan or by annual subscription, making routine and full-coverage use economically realistic.
3. Compounding knowledge. Security knowledge bases keep evolving with each new attack event, so defensive systems improve as they are used.

His conclusion is that AI itself does not favor either side. What matters is who adopts it first and who uses it more consistently and more effectively. Attackers may be half a step ahead for now, he says, but that gap can be closed quickly.

Gate’s security team says it agrees with that judgment and adds two observations from the exchange side. First, AI has changed output more than method. Attackers have always scanned open-source contracts for flaws, but what once required manual review can now be automated in bulk. A person who used to inspect dozens of contracts in a week can now scan thousands. The attack methods themselves have not changed as much as the scale. Smaller projects are hit especially hard because issues that once escaped attention are now found indiscriminately.

Second, defenders need to watch different signals. If teams only monitor abnormal transfers, Gate says, they will miss AI-era attacks because the attack often starts long before funds move. Teams also need to watch changes in key control, sudden upgrades, abnormal system behavior, unusual cloud logins, unexpected site launches, software version drift, and abnormal withdrawals. Limits, shutdown switches, and response plans only work if they have been rehearsed before a crisis. An emergency stop button that has never been pressed is often the one nobody dares to use when something actually goes wrong.

Gate also says bug bounty incentives should change. Most bounty programs still focus on single-point vulnerabilities, while AI is especially good at chaining together several weak points that look minor on their own. The team says compound-vulnerability bounties deserve support, rewarding researchers who can show how front ends, libraries, cloud services, signing flows, governance mechanisms, and contracts can fail together. Gate says it has long operated a bug bounty program and welcomes submissions from security researchers worldwide.

From another angle, Gate argues that the biggest beneficiary may be the defensive side, especially ordinary users. The old asymmetry, the team says, was that attackers were professionals and users were amateurs. A regular user preparing to join a new project had almost no tools to judge risk and had to rely on instinct or what others said. Professional audits, priced from thousands to tens of thousands of dollars per project, were effectively out of reach. Now that same user can get a structured risk report in minutes. That change means little to attackers, who already had the capability. It means a great deal to users, who previously had almost nothing.

What a complete audit report should contain

On what a complete audit report should include, Adam says a report that can guide action rather than sit in an archive should contain at least four elements.

1. Security score. This is a quantifiable rating used for quick screening, not a final conclusion. Project teams can use it as an internal benchmark and compare changes after each iteration. Exchanges can use it for early listing review. Ordinary users can use it as an entry point: avoid low scores, then read the key findings on higher-scoring reports.
2. Key findings. These are the high-risk issues and core conclusions used for decision-making. Adam describes this as the report’s executive summary, showing which issues are blocking and must be fixed before launch. For non-technical managers and listing review teams, he says, understanding the key findings is often enough.
3. Issue details. This section helps technical teams locate the problem. It should include the vulnerability location down to the contract, function, and line of code, along with the vulnerability type, severity, attack path, and root cause analysis. A good issue-detail section should provide a reproducible execution path and trigger conditions, not just a list of problems.
4. Remediation advice. This closes the loop. Fix recommendations should be specific, executable at the code level, and followed by rescanning and regression verification, creating a full cycle of score, key findings, issue details, fixes, and rescans.

Gate’s security team adds three points from the design of Gate AI contract audits.

First, the two items most often omitted are the ones at the front: audit objectives and limitations, and scope description. Gate says its AI reports are built around eight dimensions, including audit objectives and limitations, scope description, severity matrix, priority judgment, vulnerability details, risk paths, threat model, key function analysis, and remediation advice. The first two determine whether readers misunderstand the report. If limitations are not stated clearly, readers assume everything was covered. If scope is not stated clearly, readers cannot tell whether the audit covered only the main contract or also the liquidity pool, strategy contracts, oracles, and external dependencies. Gate says many promotional materials simply say a project “passed an audit” without saying what was audited, which leaves the statement with almost no information value.

Second, key findings should be read in combination. Gate gives an example of a common set of items in a report: the contract owner can blacklist addresses and freeze assets, the trading pair can be reset so ordinary users cannot transfer, a minimum holding requirement can prevent users from fully selling, and a single owner can instantly change multiple key rules. Each item on its own may look like a normal design choice. Taken together, they show that control is highly concentrated in one person. That returns to the earlier point in the article: intent is not written into code, but code can leave room for intent.

Third, users need to know how the report was generated because that defines the boundary of its reliability. Gate says its AI contract audit has three stages. Static analysis checks basic risks such as permission control, reentrancy, price manipulation, flash loans, and logical consistency. Business scenario modeling extracts the contract’s core interaction scenarios, verifies business paths and boundary conditions, and identifies issues that rule-based scanning may miss. Semantic verification then checks key business paths one by one to confirm whether the risk patterns identified in the first two stages are actually valid. Gate says the third stage is mainly there to reduce false positives. If a report is full of false alarms, users quickly lose patience and skip the whole review step.

Gate says the same warning appears on its product page and in every report: “AI auditing may contain omissions, misjudgments, or outdated information. It is for risk identification reference only and does not constitute investment advice, a security commitment, or project endorsement.” In practice, the team says, such reports are best used to reject, not approve. If a report flags high risk, there is probably a real issue and the user should stop. If a report does not flag a problem, that only means no issue was found within the tool’s capability range. It does not prove the contract is safe.

The team adds one more counterintuitive standard: a report that says “no issues found” is not necessarily more credible than one that found four risks and confirmed they were fixed. At least the latter shows the audit was actually checking. And because old contracts can blow up years later, every report has a shelf life. Gate says one question is always worth asking: after the report was issued, is this still the same contract?

How on-chain custody and exchange custody differ

On the question of how the security model differs when the same asset is held on-chain versus on an exchange, Adam says the answer depends on who is protecting the asset and what kind of risk the user faces.

For on-chain self-custody, he describes the model as private-key security plus contract security. The user is the only party responsible for safety. If a private key is lost or stolen, there is no customer service path to reverse it. Every interaction carries on-chain risk, including approval flaws, phishing signatures, and honeypot-style traps. The advantage is that the asset does not depend on any platform’s credit.

For exchange custody, he describes the model as platform security plus account security. The platform manages the private keys, usually through hot-cold wallet separation, multisig, and risk controls, which means the user is outsourcing technical security to the exchange. But the user still has to protect the exchange account itself, including passwords, 2FA, phishing exposure, and API keys, and still needs to choose a platform with credible safeguards.

Gate’s security team says an on-chain signature can move assets within seconds, with no middle layer able to intervene. Each person is directly responsible for the safety of their funds. On a trading platform, by contrast, there are several checkpoints between someone obtaining login credentials and assets actually leaving the account. Gate lists examples including a fund password, platform risk controls, Passkey, and verification that requires a fingerprint or face scan.

On how users should assess exchange credibility, Gate says proof of reserves matters, and so do backstop mechanisms beyond reserves. The exchange says it is the first mainstream trading platform to commit to 100% reserves, that its reserve code is open-sourced on GitHub, and that any user can download the verification program and confirm that their balance is included in the proof-of-reserves system. Beyond reserves, Gate says it has established the SAFU user security asset fund, which can act as an additional reserve in uncontrollable medium- to large-scale incidents.

Gate also says users do not always choose strictly between “on-chain” and “off-chain” modes, because they have different trading needs in each. The exchange says it has built options intended to meet those needs while improving security.

One example is Gate Vault, aimed at users who want to keep control of their assets but do not want to bear all private-key risk alone. Gate says the product uses MPC and a 2-of-3 signing structure. Key shards are held separately by the user’s device, Gate, and an independent third party. The full private key never appears in any form, and neither Gate nor the third party can initiate a transaction alone. All outgoing transfers have a 48-hour delayed arrival period during which the user can actively freeze the transfer.

Another example is Gate’s newly launched Trenches tool, aimed at users who want exposure to on-chain trending assets but worry about contract and signing risk. Gate says the tool shortens the path of on-chain trading. Users can trade on-chain assets directly with USDT in their Gate accounts, without bridging, connecting a wallet, or signing approvals. The tool also filters or flags some high-risk tokens and displays chip structure, address distribution, and related risk information on the same page, combined with AI analysis. Gate says risk identification cannot be 100% accurate and filtering standards need constant balancing between being too loose and too strict, but for users who simply want access to hot assets, one less signature means one less point of exposure.

What ordinary users can do right now

In the final section, both sides list practical steps for ordinary users.

Adam gives six suggestions:

1. Check token security before trading. Before buying a new token, look for honeypots, malicious minting, blacklists, abnormal transaction taxes, and overly broad owner permissions.
2. Clean up contract approvals regularly. Revoke approvals for dApps you no longer use, especially unlimited approvals. Many theft cases begin with a contract the user approved long ago.
3. Harden the account layer. Use strong passwords and enable 2FA. Apply least-privilege management to API keys and never grant withdrawal permissions to untrusted tools.
4. Make anti-phishing behavior automatic. Check the domain before signing, do not click links in direct messages, and default to skepticism toward “airdrops,” “customer service,” or “high-yield staking” pitches. The article says AI-generated phishing content is becoming much more convincing.
5. Separate assets by purpose. Keep only small working balances in hot wallets, and use hardware wallets for larger holdings.
6. Watch a project’s security attitude, not just its audit report. Ongoing audits and monitoring matter more than a report issued years ago.

Gate’s security team says those six points are already comprehensive and then turns several of them into immediate actions using Gate’s own tools.

1. Check tokens before trading. Users can submit a contract address to Gate AI and get a report in minutes. Gate says the four items to focus on are owner permissions, blacklists and trading restrictions, minting permissions, and transfer taxes. If any of those is marked in red, the user should stop.
2. Harden the account and get the security score above 80. Gate says fund passwords, authenticators, two-factor verification, anti-phishing codes, Passkey, daily withdrawal limits, and withdrawal method management are all listed in a checklist that users can complete step by step. The value of the score, the team says, is that it turns scattered settings into an ordered list. Users who get above 80 can also join the account security protection plan.
3. Use existing anti-phishing tools. If users receive any message claiming to be from Gate, they should first use official verification channels to check whether the domain or contact email really belongs to Gate. All emails sent by Gate carry the user’s own anti-phishing code, and any message without that code should be treated as fake. Gate says that as AI makes phishing content more realistic, mechanisms that do not depend on human judgment become more reliable.
4. Check approval amounts before signing. A contract may be fine while the page asking for a signature is not. Gate says a normal dApp can request only the amount needed for the current transaction. If it asks for unlimited approval, that alone is a reason to stop. If the pop-up shows only a string of unreadable characters, refusing is safer than signing first and asking questions later.

The article closes by repeating the same core point: AI does not favor either side on its own. What matters is who uses it first and who uses it more consistently. For project teams, that means post-audit monitoring matters more than the report itself. For trading platforms, listing is only the start of review. For ordinary users, more verification tools are now available than before.

The article also includes a disclaimer saying the content does not constitute any solicitation, invitation, or recommendation, and that users should always seek independent professional advice before making investment decisions. It also notes that Gate may restrict or prohibit some or all services in restricted regions and directs readers to the user agreement for more information.