OKX Web3 Security Team, SlowMist, and OtterSec Jointly Produced

Introduction

In the first half of 2026, if we only look at the publicly reported losses, they have decreased by nearly sixty percent compared to last year, and the cryptocurrency industry seems to be becoming safer. However, in reality, this reduction in losses is almost entirely due to the absence of a single massive incident that occurred during the same period last year, rather than a genuine decrease in hacker activity. In fact, the opposite is true: the frequency of attacks is rising, methods are evolving, and attackers are shifting their focus from "code" to "people".

In the past, many projects prioritized contract audits and on-chain activity monitoring. However, in the first half of this year, the significant losses often did not originate from the contracts themselves. They might stem from a blind-signed management transaction, a leaked cloud key, a developer's computer infected with malware, or even a video meeting that appeared very real.

For OKX, security is not a slogan in a report; it is a real risk that needs to be addressed daily: malicious addresses, phishing domains, high-risk signatures, abnormal authorizations, cross-chain risks, scam tokens, social engineering attacks are all still occurring. This report aims to accomplish two things: first, to explain the changes in attacks that are truly worth our vigilance in the first half of the year; and second, to provide some practices from OKX regarding wallet, risk control, cross-chain, and agent security in the context of the industry as a guide.

Chapter One · Security Situation in the First Half of 2026: Dispersed Incidents, Concentrated Losses

Decrease in Losses Does Not Mean a Reduction in Attacks

A phenomenon that might be misinterpreted in the first half of this year is that the total amount stolen has dropped, yet the number of security incidents has actually increased. According to incomplete statistics from SlowMist's Black Database, there were a total of 182 publicly reported security incidents in the first half of the year, resulting in approximately $956 million in losses; compared to 121 incidents and about $2.373 billion in losses during the same period in 2025, the number of incidents has risen by approximately 50%, while the amount lost has decreased by about 60%. The decrease in loss amounts seems to be primarily because there was no single extreme event of the same scale as last year's. Removing outliers, the comparable losses this year have actually increased. Attack activities have not diminished; instead, they have shifted towards more frequent and dispersed strikes.

For comparison, the largest publicly disclosed security incidents in the first half of 2025 were as follows:

[Table]

Firstly, large losses are increasingly occurring outside of contract code. The heaviest losses in the first half of the year did not arise from vulnerabilities such as reentrancy or precision loss in smart contracts, but rather from failures at the operational level—blind-signed management transactions, contaminated single validator nodes, stolen cloud signature keys. In terms of incident count, contract and logic vulnerabilities continue to be the primary reasons for attacks (85 incidents); however, in terms of loss amounts, supply chain attacks topped the list with approximately $298 million, followed by contract vulnerabilities (about $152 million) and private key leaks (about $130 million). This precisely indicates that for a project, having only an audit report is far from sufficient. Even if the contract has no obvious logical vulnerabilities on-chain, as long as the signing process, cloud keys, cross-chain verification, or operational systems have single point risks, attackers can bypass the contract itself and infiltrate through the weakest link. The boundaries of security have expanded from "is the code secure" to "who can sign, where the keys are stored, whether verification relies on a single point, and whether operations are trustworthy".

Secondly, regular users are becoming the main targets of attacks. As the cost of attacking protocols increases, attackers turn their focus to users. Phishing websites, malicious browser extensions, poisoned search ads, fake customer service, false job postings, malicious meeting software, clipboard hijacking, and fake 2FA verification are all user-side attack methods that repeatedly occurred in the first half of the year. These attacks do not necessarily rely on sophisticated technology; what they truly exploit is users’ habits and trust in their daily operations—trusting the first search result, believing high ratings in the app store, trusting links sent from friends’ accounts, believing in the "real person" appearing in video meetings, and believing a page labeled "security verification". AI has made all this cheaper and more realistic: attackers can bulk generate phishing content, forge identities, clone voices, and create deepfake videos, refining originally crude scams to the point where they can deceive even experienced users. The success of those attacks increasingly depends not on whether users "understand technology," but rather on whether attackers can accurately hit the trust blind spots of individuals.

Thirdly, as AI Agents flourish, they are also gradually becoming new prey for hackers. As Agents evolve from being "able to converse" to being "able to execute"—calling tools, reading context, controlling assets, initiating transactions—their capabilities increase, and the consequences of being attacked also become more severe. In the past, prompt injection was more a concept within the domain of model security. The worst outcome was to make the model say something it shouldn’t; however, when an Agent can sign transactions and transfer funds, the same malicious command disguised as normal input can directly result in a real on-chain loss. There is now an increasing threat whereby attacks are targeting the "cognitive-execution" chain, equating to threats as dangerous as attacking private keys.

Chapter Two · Project Perspective: The Biggest Losses for Projects Often Occur Outside of Contracts

For project teams, the most significant takeaway from the first half of 2026 is that problems in operational processes can have consequences as severe as contract vulnerabilities, and in some cases, even more severe.

The following events are significant project security incidents in the first half of 2026, sorted by loss amount according to OtterSec. They cover some of the most common high-value attack surfaces: cross-chain bridges, verification infrastructure, signing processes, cloud keys, developer devices, oracles, and access control.

[Table]

KelpDAO: Attackers Did Not Target the Contract but Breached the Verification Path

KelpDAO suffered the largest single loss in the first half of the year. The most concerning aspect is that the attackers did not directly target the contract logic, but instead attacked the verification path of cross-chain messages. According to OtterSec's analysis, attackers contaminated LayerZero's internal RPC nodes while simultaneously DDoSing honest external nodes. Ultimately, the single DVN relied upon by the bridge mainly observed forged data from the attackers and approved a withdrawal without real burn support. Approximately 116,500 rsETH were transferred, of which around $75 million was later frozen.

The single DVN has always been considered a high-risk configuration. However, previously, this was mostly a theoretical risk identified in architectural discussions; after the KelpDAO incident, it became a real loss of nearly $300 million. This incident gives project teams a straightforward reminder: do not allow a single validator, a single RPC, a single price source, or a single signature path to determine whether funds can leave. As long as there is only one verification point on a critical path, attackers will prioritize studying it.

Cross-chain bridges and oracles particularly need multi-source verification, redundant nodes, outflow throttling, anomaly monitoring, and emergency pausing mechanisms. Otherwise, even if the contracts themselves have no obvious vulnerabilities, attackers may still take away funds through off-chain infrastructure.

Drift: Attackers Waited Half a Year for a Signature

If KelpDAO exposed the weaknesses of infrastructure, Drift exposed the frailty of the signing process. This was not a spontaneous phishing attempt but rather a long-term planned social engineering attack. Attackers spent about six months building a relationship, waiting for a multi-signature signer to approve a critical management transaction without fully comprehending the implications. The most concerning aspect of this incident was the misuse of the Solana durable-nonce mechanism. The attackers induced relevant personnel to pre-sign multi-signature authorization transactions. At the time of signing, these transactions appeared to have no immediate effect; however, after Drift adjusted the multi-signature threshold, attackers re-broadcast the transactions with the already obtained signatures, siphoning off over 50% of the TVL in a very short time.

This type of attack reminds project teams that just because a signing appears to have "no impact" doesn’t mean it won't be exploited in the future. Blind signing, pre-signing, and incomprehensible management transactions should all be viewed as high-risk operations. Critical transactions must be clearly interpretable, simulatable, and verifiable. For multi-signature teams, the signing process itself should be considered a core asset to protect.

OKX Practice: From Transaction Analysis to Signature Risk Protection

From OKX's practice, the protection of signature risks must not stop at the level of "did the transaction originate from the user." More importantly, it is whether the user truly understands the consequences of this transaction before signing. In high-risk scenarios such as Solana durable nonce, account ownership changes, nonce account initialization, etc., OKX has established identification, alerting, interception, and isolation capabilities in various risk rules like solana_assign_account_owner, solana_init_nonce_account, and nonce_account_risk, and in the first half of 2026, over 4 million high-risk operations were intercepted/alerted, with a cumulative protected amount of approximately $526 million, helping users identify and avoid such risks before signing.

At the same time, OKX is continuously promoting the construction of transaction parsing capabilities. Our goal is to make on-chain transactions more transparent and readable, achieving "what you sign is what you get" as much as possible: what users see should not be an incomprehensible string of calldata or instructions, but rather a clear understanding of what this transaction intends to achieve, which assets it will impact, what permissions it will grant, and whether there are any abnormal risks. To date, OKX has parsed and matched over 50,000 on-chain methods, helping users better understand the transactions they are signing.

Chapter Three · User Perspective: Trust Has Become the Sharpest Weapon

User-side risks continued to rise in the first half of the year. Many attacks no longer start with unfamiliar links but rather from familiar entry points where users are prone to lower their guard: app stores, search results, friend accounts, meeting software, recruitment processes, customer service emails.

Phishing Begins to Borrow the Shell of Real Platforms

Phishing remains the primary method for users’ assets being stolen, but its forms are evolving.

A common method is malicious browser extensions. Attackers often impersonate well-known wallet tools, copying brand names, icons, and page copy, while enhancing the extension's appearance through inflated ratings and download numbers, making it seem like a legitimate product in the official app store. Users encountering it in official stores are likely to let their guards down, believing it to be the plugin they know. Such extensions often employ a “local shell, cloud poisoning” strategy, making them not directly contain malicious logic, and thus easier to pass static reviews from stores. The truly dangerous phishing pages are delivered in real-time from remote servers, allowing attackers to change pages, switch domain names at will, or even display different content to different users. Once you input your mnemonic phrase or private key, the control of your assets is already surrendered.

Another type is search engine ad phishing. Attackers purchase ad slots for popular keywords, placing counterfeit official sites at the top of search results. In a typical case from the first half of the year, a user searched for development tools after purchasing a new computer and clicked on a pinned advertisement, subsequently running an "install command" as prompted by the page. This command actually deployed a clipboard hijacking trojan, allowing the attacker to modify the user's page. Later, when the user transferred approximately $20,000, the receiving address was automatically replaced, causing the funds to be sent to the wrong place. The difficulty in defending against this type of attack lies in that the user is not engaging in anything obviously dangerous. They are merely searching for the official site, downloading tools, and copying commands, all of which are part of their routine tasks.

Social Engineering: The Most Active and Destructive

Social engineering's key is not technology, but getting the victim to lower their guard at a critical moment.

The most common method is impersonating someone the victim has already recognized. In a real case, the victim received an activity invitation from a long-trusted friend. The other party insisted on downloading specific meeting software; though the victim hesitated, they ultimately installed it due to their trust in that friend. A few hours later, their wallet was emptied. It was discovered afterward that the friend's account had long been compromised by attackers. High-profile KOLs are also major targets, with attackers creating highly imitated accounts that use the credibility of public figures to lure fans into fake events, fake airdrops, and fake investment groups. For ordinary users, the challenge is not to judge whether a stranger is trustworthy, but rather to determine whether an account that "looks like an acquaintance or celebrity" has been hacked or faked.

Recruitment and interview scams are also becoming more targeted. Attackers may first interact with victims through "technical interviews," "operational interviews," or "volunteer interviews," asking them to share their screens, open wallets, or demonstrate DeFi experience. On the surface, this appears to be a part of an interview process; however, attackers are recording wallet addresses, holdings, commonly used protocols, and operating habits. In one true case we observed, attackers learned about the victim's recent interaction protocols and preferences through the interview process, subsequently crafting fake airdrop pages and sending highly customized phishing messages targeting the protocols the victim had actually used, ultimately scamming approximately $88,000.

Two New Methods to Watch Out For

The first type is the fake "2FA security verification" scam.

Attackers send emails disguised as official wallet communications, using a fake domain name that differs by only one character, creating a sense of urgency with a countdown to lead users to input their mnemonic phrases to "complete verification". It is essential to repeatedly emphasize: any page asking for the input of a mnemonic phrase for verification, certification, recovery, or upgrades is a scam. The mnemonic phrase is not a verification code; it is the control of assets, and no legitimate wallet would ever request it from a user through a webpage.

The second type is business process fraud.

This type of attack may not appear to be phishing, but rather looks like normal work. Attackers bait victims with business scenarios like "confirming the company's legal name," "external audits," "confirming token ownership," or "supplementing collaboration materials," delivering malicious attachments masquerading as Word, PDF, or collaborative documents. Once opened, malicious programs disguise themselves as system updates, coaxing users to input system passwords and request permissions for cameras, screen recording, keyboard monitoring, etc. The targets of these attacks are not necessarily just individual wallets. Oftentimes, what attackers really want is access to office terminals, browser sessions, password managers, cloud service permissions, and project internal system access.

OKX Practice: User Protection Preceding Device and Access Entry

Looking at the changes in user-side attacks, performing defenses only on-chain is no longer sufficient. Many losses don’t start from a single on-chain transaction but from earlier actions: users downloading malicious apps, installing disguised plugins, clicking phishing websites, or continuing to sign and transfer on compromised devices. Therefore, OKX is shifting user protection from the point of on-chain transactions to devices, applications, and access points. OKX has launched a security scanning assistant that helps users identify risky applications hidden on their devices, reducing the risk of asset losses from malware, disguised applications, remote control tools, or clipboard hijacking. As of the report date, OKX has completed over 200,000 risk detections, identifying over 60,000 high-risk applications and guiding users on uninstallation or remediation. So far, it has covered Windows and Android systems, with a MacOS version set to launch soon.

Additionally, regarding phishing websites and malicious DApps, OKX is also conducting risk identification and alerts in key scenarios where users access suspected risky URLs, connect wallets, or initiate interactions. As of the report date, OKX has intercepted over 7 million visits to risky websites, helping users avoid phishing risks before entering mnemonic phrases, connecting wallets, or signing transactions. For users, the best security alert is not the notification after a loss has occurred, but instead preventing the risk before it is truly on-chain. OKX aims to intercept more attacks before signing and transferring through device risk detection, website risk identification, DApp risk alerts, and on-chain transaction parsing.

Chapter Four · How AI is Reshaping Attacks: From Content Forgery to "Synthetic Reality"

AI's impact on the security landscape represents the most profound structural change in the first half of the year. Its effects are not singular. On the one hand, AI makes it easier for attackers to generate phishing emails, fake websites, fraudulent customer service scripts, and malicious code; on the other hand, it also makes voices, videos, identities, and community environments easier to forge. Further, as AI Agents start having access to funds or transactional tools, they themselves become new targets for attacks.

New Battleground: When Agents Start Approaching Funds and Transaction Execution

At OKX, we view AI Agents not merely as new sources of risk, but also potentially as vital access points for Web3 to attract more users. OKX is advancing the Agentic Wallet, allowing users to understand strategies, manage on-chain operations, and complete more complex DeFi interactions under conditions of authorization and confirmation.

By integrating vetted DeFi project plugins, the Agentic Wallet can consolidate originally multi-step on-chain operations such as swapping, lending, yield management, and cross-chain into more natural interactive processes. For many ordinary users, this can lower the threshold for understanding and utilizing on-chain finance, bringing Web3 services closer to familiar product experiences. However, because Agents are beginning to approach assets, permissions, and transaction execution, their security requirements are higher than those of ordinary applications. An Agent that assists users in completing DeFi operations must not only focus on "can it execute," but also address "should it execute," "does the user truly understand the consequences of execution," and "are tool calls restricted to a safe range."

The recent Bankr incident has made AI Agent risks very concrete. According to disclosures from institutions like SlowMist, attackers sent a prompt injection message encoded in Morse code to xAI's Grok after activating some Agent membership privileges. Grok decoded and forwarded the content to the on-chain bot @bankrbot, which executed the instruction as trusted input, ultimately transferring around $150,000 to $200,000 on the Base chain.

Although about 80% of the lost funds were later recovered, it underscores that prompt injection is no longer merely a concept within model security discussions. When Agents can call wallets, perform transactions, transfer funds, or access other sensitive tools, a malicious input can easily transform into a real transaction.

What is particularly thought-provoking is not just what the Agent executed, but how we should control the execution permissions of Agents. For any Agent capable of holding funds or initiating on-chain operations, input filtering, tool call sandboxes, permission tiering, secondary confirmations for sensitive operations, and pre-execution validations should be basic requirements; and how to make all this transparent and seamless is a critical focus for next-generation Agent products.

Industrialization: Streamlining Attack Processes

AI has significantly reduced the costs of content production and identity forgery, making it easier for phishers to batch generate webpages, emails, chat scripts, and fake identities; in high-complexity attacks, AI is embedded into key phases of social engineering, code generation, and environment camouflage.

A typical case involves North Korea’s Lazarus sub-organization HexagonalRodent: they contact developers using high-paying remote jobs and well-known project recruitment as bait, inducing them to run code with backdoors. Investigations revealed that this organization extensively utilized ChatGPT and Cursor to assist in code generation and social engineering scripts, created counterfeit official sites with AI website building tools, and even conducted "self-checks" on their malicious code using AI to evade detection. In just the first quarter of 2026, this organization stole wallet data from over 2,700 developer systems.

AI-generated code also presents new problems. According to OtterSec, Georgia Tech attributed 35 out of 74 CVEs in March to AI-generated code; a scan of about 1400 "vibe-coded" applications found 2038 serious vulnerabilities, over 400 exposed keys, and 175 individual information leaks.

These figures reveal that AI-generated code cannot be deployed into production environments merely because it is "functionally viable." Code auditing, key scanning, permission checks, and testing coverage should be even stricter.

Endgame: From "Content Forgery" to "Synthetic Reality"

AI's greatest change in phishing scenarios is that scams have evolved from singular content forgery to a complete, coherent, and sustainable false environment—"Synthetic Reality".

In the "Truman Show" operation disclosed by Check Point, attackers lured victims into a private investment group. The group featured AI-generated "investment experts" and a plethora of AI-portrayed "investors". These roles continuously published analyses, showcased profits, and interacted in real-time based on the victims' language. What victims faced was not just a scammer, but a complete environment that appeared to have real conversations, real profits, authentic endorsements, and engagement.

In an extreme case disclosed by Singapore police, a fraud gang impersonated high-ranking government officials, luring victims into a carefully designed Zoom meeting where multiple AI-generated avatars of the prime minister, president, and monetary authority representatives appeared, coupled with confidentiality agreements and subsequent funding arrangements, creating an incredibly authoritative complete scene which ultimately led to about 4.9 million Singapore dollars in losses for the victims.

This marks a fundamental shift in attack objectives: attackers aim not just to deceive a judgement about a particular piece of information, but rather to manipulate the perception of the truthfulness of an entire environment. In this era, traditional "identifying suspicious information" defenses are becoming ineffective.

OKX Practice: Ensuring Agent Safety Before Plugin Integration and Transaction Execution

Using the recent Bankr incident as an example, attackers used a prompt injection message encoded in Morse code to deceive the Agent's judgment, ultimately prompting it to initiate a real on-chain transfer. Such incidents reveal a reality: the "brain" of the Agent can be deceived. It can be misled by prompt injection, call problematic plugins, or simply lack rigorous logic itself. For this reason, OKX does not place the entire burden of security on the Agent's own judgment. Regardless of how an on-chain transaction is generated, OKX will conduct independent risk detection before it is signed and broadcast, ensuring that even if the Agent's judgment is manipulated by prompt injection or malicious plugin hijacking, the transaction cannot transfer assets without the user's knowledge. The final line of defense against risks should not depend on whether the Agent is smart enough, but should be guaranteed at the moment the transaction actually goes on-chain.

To make this defense reusable, OKX is also modularizing its accumulated on-chain risk identification capabilities. Surrounding the key questions when an Agent executes on-chain operations—"what assets will this transaction impact," "are there risks in the target contract and token," "is the authorization scope abnormal," and "does the simulated execution result align with user intentions"—OKX aggregates its fundamental capabilities like asset movement analysis, transaction security simulation, token risk analysis, and address risk identification into reusable security skills and opens them to developers. If any of these checks identify a risk, OKX will require user secondary confirmation or directly intercept the transaction.

At the same time, we also understand that the security of the Agentic Wallet cannot only occur at the last step of transaction execution. As long as the Agent can connect plugins, read context, call tools, and organize on-chain transactions, it may face risks from prompt injection, context poisoning, malicious plugins, overreaching tool calls, and supply chain attacks. Any single step being compromised can be magnified into a real asset loss. Therefore, OKX has established access review and regular inspection mechanisms for the plugins integrated with the Agentic Wallet. For the DeFi plugins integrated into the Agentic Wallet, OKX will check them across multiple dimensions, including code security, scope of permissions, tool call boundaries, and external dependencies, in order to minimize risks from malicious code, abnormal permissions, and supply chain poisoning. Even after a plugin goes live, OKX will continue to conduct inspections and monitor risks to prevent new security issues from emerging in subsequent versions.

We hope more developers building Agent applications will not have to start from scratch in establishing on-chain security capabilities. Agents can organize transactions more intelligently, but they must also execute transactions more cautiously. Only when plugin access, tool calls, transaction simulations, risk analyses, and user confirmations form a complete closed loop can the Agentic Wallet truly bring complex DeFi operations to more users without also delivering complex risks.

Chapter Five · Security Recommendations

Reviewing the attack incidents from the first half of 2026, we can see that many losses seem to arise from different paths but ultimately land at a few key moments: someone signed a transaction they did not understand, a system granted excessive permissions, a team trusted incorrect data sources, or a user trusted someone disguised well enough.

Thus, security advice should not just be a call to "stay vigilant." For project teams and users alike, it is more useful to push defenses forward: verifying before signing, authorization before execution, and believing the other party before proceeding.

OKX suggests condensing the lessons of the first half of the year into three sentences:

Understand before signing, avoid single point risks, verify before trusting.

First, Understand Before Signing

Many attacks do not occur because the signer was uninvolved, but rather because the signer did not truly comprehend what they signed. The Drift incident is a typical example. The attackers did not directly steal the private key but induced the signing of management transactions that could be exploited in the future. Just because a signing appears to have no immediate effect does not mean it won’t lead to losses later. Especially for durable nonce, pre-signed transactions, multi-signature authorizations, contract upgrades, owner changes, minter permissions, and delegate operations, if these transactions are signed incorrectly, the consequences can far exceed those of an ordinary transfer.

For project teams, critical transactions should not just consider "who signed" but also assess "whether the signing person understands." Multi-signatures, admin operations, contract upgrades, cross-chain configurations, and oracle modifications should have clear transaction interpretations, simulation results, and verification processes. For significant asset outflows, permission changes, or threshold adjustments, options should include time locks, secondary confirmations, and anomaly alerts. For users, a habit should develop: if you don’t understand, don’t sign. If the wallet interface cannot explain what assets this transaction will transfer, what permissions it will grant, which contract it will invoke, or whether there are infinite authorizations or abnormal risks, one should pause. A truly secure signature should not just be a hash or an incomprehensible calldata, but should inform users about what they are doing.

This is also why OKX continuously invests in transaction parsing. We hope what users see goes beyond just a “confirm” button to the actual intention behind the transaction.

Second, Avoid Single Point Risks

Many significant losses in the first half of the year were not driven by some specific bug being exploited, but rather due to excessive and centralized permissions at a given stage, meaning that if breached, it could entirely dictate the direction of funds.

KelpDAO exposed the single point risk of the verification path, and Resolv Labs revealed the single point risk associated with the cloud key; numerous private key leak and device invasion incidents further demonstrate that as long as critical permissions are concentrated in a few accounts, devices, or services, attackers often only need to penetrate a weak link to withdraw substantial funds. For project teams, the design of critical paths should default to conservatism, with the core principle being: do not let any single step independently determine whether funds can leave. Do not allow a single RPC, a single DVN, a single price source, a single cloud key, or a single admin address to become the only switch determining the flow of funds. For key operations like permission changes, minting, withdrawals, and upgrades, permissions should be segmented, thresholds set, throttling and anomaly monitoring added, making any irregularity require crossing multiple independent levels, rather than allowing a smooth passage. Cloud keys, CI/CD credentials, MPC nodes, and hot wallets should also be managed in tiers according to their asset control rights instead of being treated as ordinary technical configurations.

For users, the same logic applies. Do not store all assets in one wallet while frequently engaging in various DApp interactions—large assets should be kept separate from daily interaction wallets, isolating mistakes to minimal impact. Unused authorizations should be revoked periodically; be especially cautious with operations involving infinite authorizations, NFT full authorizations, Permit/Permit2, delegation, etc. Many attacks do not initially transfer assets but rather first obtain authorizations and then strike when users have lowered their guard.

The key is not to allow the collapse of any single step to directly dictate the fate of all your funds. The more independent checkpoints an attacker must overcome to succeed, the smaller the damage will be in the event of a single point breach. This is not security paranoia but rather the most fundamental risk control in Web3.

Third, Verify Before Trusting

In the first half of 2026, attackers increasingly relied less on "crude fake links" and began exploiting things users already trusted: friend accounts, search results, app stores, meeting software, recruitment processes, KOL identities, or even "real people" in videos.

AI has made this even more dangerous. Voices can be cloned, videos can be fabricated, chat tones can be mimicked; entire investment groups, meeting rooms, customer service processes can be staged. Many future scams may not resemble scams but rather look like a normal interview, a collaboration discussion, a security verification, a friend’s invitation, or a project meeting.

For project teams, any requests involving funds, permissions, code execution, and deployment processes should not be confirmed through a single channel. Video conferences are not identity proofs, and familiar accounts are not identity proofs either. Critical actions must be verified through credible out-of-band channels, such as known phone numbers, internal systems, hardware signing procedures, or multi-person confirmation mechanisms, rather than solely believing individuals appearing in chat windows.

For users, there are several bottom lines to remember. Any page asking for mnemonic phrase input is a scam. Any requests for remote control, screen sharing, installing unfamiliar meeting software, or executing terminal commands should be paused. Any operations involving transfers, authorizations, airdrop receipts, account recoveries, or security verifications should be reconfirmed through official channels, rather than continuing along links provided by others.

In the age of AI, security is no longer just about identifying "whether this information looks fake," but also confirming "whether this person, this entry point, this process is real."

Implementing Security Before Losses Occur

These three recommendations share the same direction: do not wait until funds have already been transferred to start paying attention to security.

Project teams need to move risk control upstream to signing, permission, deployment, cross-chain, and key management processes. Users need to implement their judgment before connecting wallets, inputting mnemonic phrases, installing software, and granting signature authorizations. Wallets, platforms, and security products should also assume greater responsibility, translating complex on-chain risks into reminders users can understand, intercepting risks before they truly impact the chain.

OKX will continue to invest in this direction: through transaction parsing to ensure users understand risks before signing; through device security protections and website risk identification to intercept phishing and malware before on-chain interactions; through KYS risk capabilities to identify abnormal addresses, malicious tokens, high-risk authorizations, and suspicious transactions; and through the plugin access reviews, tool calling sandbox, and transaction simulations of the Agentic Wallet, we aim to enable the Agent to assist users in completing complex operations without also transferring complex risks to them.

Security does not require every user to become a security expert. Truly good security products should articulate risks clearly at the steps where users are most prone to error, shield them from danger, and return the choice to the users.

Acknowledgments and Data Sources

The industry data and cases in this report received support from the following partners: SlowMist, OtterSec.

Disclaimer: This report is for industry reference only and does not constitute any investment, legal, or compliance advice. The loss data cited is based on estimated asset prices at the time of incidents; actual losses may differ from the figures listed due to incomplete disclosures and other factors.

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