Foreword

In the first half of 2026, if we look solely at public losses, the cryptocurrency industry seems to be getting more secure compared to last year, with a nearly 60% reduction in losses. However, in reality, this decline in losses is almost entirely due to the absence of a massive event from the same period last year, rather than a weakening of hacker activities. In fact, the frequency of attacks is on the rise, techniques are evolving, and attackers are shifting their focus from "code" to "people."

In the past, many projects focused mainly on smart contract audits and on-chain activity monitoring. However, in the first half of this year, the real cause of substantial losses is often not the smart contract itself. It could be an improperly signed management transaction, a leaked cloud key, a developer's computer infected with malware, or even a seemingly authentic video conference.

For OKX, security is not just a slogan in a report but a real risk to be managed every day: malicious addresses, phishing domains, high-risk signatures, unusual authorizations, cross-chain risks, scam tokens, and social engineering attacks continue to emerge. This report aims to do two things: first, to clearly explain the significant changes in attacks to be wary of in the first half of the year, and second, to provide some insights into OKX's practices in wallet security, risk control, cross-chain security, and Agent security within the industry context.

Chapter 1 · Security Landscape in the First Half of 2026: Dispersed Events, Concentrated Losses

Decrease in Losses Does Not Mean a Reduction in Attacks

There was a phenomenon in the first half of this year that is easily misinterpreted: the total amount stolen decreased, but in reality, there were more security incidents. According to an incomplete statistical analysis from SlowMist's BlackHat archive, there were a total of 182 public security incidents in the first half of the year, resulting in approximately $956 million in losses. Compared to the same period in 2025, which had 121 incidents and around $2.373 billion in losses, the number of incidents increased by about 50%, while the financial losses decreased by about 60% year-on-year. The apparent decrease in losses is mainly due to the absence of a single massive event from the same period last year. The fact that an equivalent scale of extreme event did not occur this year does not mean that attackers have stopped. Excluding outliers, the actual comparable losses this year have increased rather than decreased. Attack activities have not weakened but have shifted to more frequent and dispersed attacks.

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

Three Most Notable Changes in the First Half

First, large losses are increasingly occurring outside of smart contract code. The most severe losses in the first half did not come from smart contract vulnerabilities such as reentrancy or precision loss, but from operational failures—induced blind-signed management transactions, compromised single validator nodes, and stolen cloud signature keys. In terms of the number of events, contract and logic bugs are still the primary attack vectors (85 incidents); however, in terms of loss amounts, supply chain attacks lead with around $298 million, followed by contract bugs (around $152 million) and private key leaks (around $130 million). This precisely indicates that for a project, a mere audit report is far from sufficient. Even if the contract has no apparent on-chain logic vulnerabilities, as long as there are single points of failure in the signing process, cloud-based keys, cross-chain validation, or operational systems, attackers can still bypass the contract itself and exploit the weakest links. The security perimeter has long expanded from "is the code secure" to "who can sign, where are the keys stored, does validation rely on single points, is operations trustworthy."

Second, ordinary users are becoming the primary targets of attacks. As the cost of attacking protocols rises, attackers turn to users. Phishing websites, malicious browser extensions, search ad poisoning, fake customer support, fake job postings, malicious conferencing software, clipboard hijacking, fake 2FA verifications were all recurring user-side attack methods in the first half. These attacks do not necessarily rely on sophisticated technology; what they truly exploit is users' habits and trust in their daily operations—believing the first search result, trusting high-rated apps on the app store, clicking links sent by friends' accounts, trusting the appearance of "real people" in video conferences, trusting a page labeled "security verification." AI makes all of this cheaper and more realistic: attackers can mass-produce phishing content, forge identities, clone voices, create deepfake videos, polishing rough scams enough to deceive experienced users. The success of attacks increasingly depends not on whether users "understand technology" but on whether attackers can accurately hit users' trust blind spots.

Third, while AI Agents are thriving, they are also gradually becoming the new targets of hackers. As Agents transition from "being able to converse" to "being able to execute"—calling tools, reading context, controlling assets, initiating transactions—the greater their capabilities, the more severe the consequences of being compromised. In the past, prompt injection was more of a concept in the model security field where the worst outcome was making the model say something it shouldn't; but when an Agent can sign transactions, transfer funds, the same malicious command disguised as normal input could turn into a real on-chain loss. Attacks on its "cognition-execution" chain are becoming a threat as dangerous as attacking private keys.

Chapter 2 · Project Team Perspective: The Project Team's Greatest Losses, Many of Which Occurred Outside the Smart Contract

For project teams, the most memorable aspect of the first half of 2026 was this: operational failures had consequences as severe as, if not more severe than, smart contract vulnerabilities.

The following events represent major project security incidents in the first half of 2026, organized by loss amount as compiled by OtterSec. They cover several of the most common high-value attack surfaces: cross-chain bridges, validation infrastructure, signature flows, cloud keys, developer devices, oracles, and access control.

KelpDAO: Attacker Didn't Hit the Contract, but Took Down the Validation Path

KelpDAO suffered the largest single loss in the first half of the year. Its most alarming aspect was that the attacker did not directly target the contract logic but rather attacked the cross-chain message validation path. According to OtterSec's postmortem, the attacker polluted the LayerZero internal RPC node while launching a DDoS against honest external nodes. In the end, the primary view of the bridge's relied-upon single DVN mostly showed data forged by the attacker, allowing a withdrawal signature without a genuine burn backing. Approximately 116,500 rsETH were transferred out, of which around $75 million was later frozen.

A single DVN was always considered a high-risk configuration. However, in the past, this was more of a theoretical risk warning in architecture discussions. After the KelpDAO incident, it became a nearly $300 million real loss. This event provided a direct reminder to project teams: Do not let a single validator, RPC, price feed, or signature path determine whether funds can exit. As long as there is only one validation point on a critical path, attackers will focus on it.

Cross-chain bridges and oracles especially require multi-source validation, redundant nodes, withdrawal limits, anomaly monitoring, and emergency pause mechanisms. Otherwise, even if the contract itself has no obvious vulnerabilities, attackers can still siphon funds through off-chain infrastructure.

Drift: Attacker Waited Six Months for a Single Signature

If KelpDAO exposed the infrastructure's vulnerability, Drift exposed the vulnerability of the signature process. This was not a spur-of-the-moment phishing attack but a long-con social engineering attack. The attacker spent about half a year building relationships, waiting for a multisig signer to sign a key management transaction without fully understanding its implications. The most alarming aspect of this event was the abuse of the Solana durable-nonce mechanism. The attacker induced relevant individuals to pre-sign multisig authorization transactions. At the time of signing, these transactions seemed to have no immediate impact; however, after Drift adjusted the multisig threshold, the attacker broadcasted the pre-obtained signature transactions and swiftly drained over 50% of the TVL.

This type of attack reminds project teams that just because a signature seems to have "no impact" at the time of signing does not mean it won't be exploited in the future. Blind signatures, pre-signing, and opaque management transactions should all be considered high-risk operations. Key transactions must be able to be clearly understood, simulated, and audited. For multisig teams, the signature process itself should be treated as a core asset to protect.

OKX Practice: From Transaction Parsing to Signature Risk Protection

From OKX's practice, it is evident that protecting against signature risk should not only focus on whether the transaction was initiated by the user themselves. More importantly, it is crucial to assess whether the user truly understands the consequences of the transaction before signing. Surrounding high-risk scenarios such as Solana durable nonce, account ownership changes, nonce account initialization, OKX has established identification, prompting, interception, and isolation capabilities in multiple risk rules such as solana_assign_account_owner, solana_init_nonce_account, nonce_account_risk, and has accumulated over 4 million interceptions/warnings of high-risk operations in the first half of 2026, protecting an accumulated amount of approximately $526 million, helping users identify and steer clear of such risks before signing.

At the same time, OKX is continuously advancing transaction parsing capabilities. Our goal is to make on-chain transactions more transparent and readable, aiming for "sign what you see": users should not see a string of incomprehensible calldata or instructions but rather understand what the transaction truly aims to do, which assets it will affect, 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 to help users have a clearer understanding of the transactions they are signing.

Chapter Three · User Perspective: Trust, Now the Sharpest Weapon

User-side risks continued to rise in the first half of the year. Many attacks no longer start from unfamiliar links but from familiar, easily relaxed entry points for users: app stores, search results, friend accounts, meeting software, recruitment processes, customer service emails.

Phishing Evolves to Leverage the Outer Shell of Legitimate Platforms

Phishing remains the top method for stealing user assets, but its form is evolving.

One common way is through malicious browser extensions. Attackers often impersonate well-known wallet tools, copying the brand name, icon, and page content. They then use tactics such as fake reviews and inflated download numbers to make the extension appear like a legitimate product. When users see it in the official app store, they easily lower their guard, thinking it is the same plugin they are familiar with. These extensions often use a "local shell, cloud-based poisoning" strategy. This strategy allows them to not directly include malicious logic, making it easier to pass through the store's static review. The actual phishing page is dynamically delivered from a remote server, allowing attackers to constantly change the page and domain, even displaying different content to different users. Once you enter your mnemonic phrase or private key, you have already given up control of your assets.

Another type is search engine ad phishing. Attackers buy ad space for popular keywords and place counterfeit websites at the top of the search results. In a typical case from earlier this year, a user who had purchased a new computer searched for development tools, clicked on the top ad, then followed instructions on the page to execute an "installation command" in the terminal. This command actually deployed a clipboard hijacking trojan, allowing the attacker to manipulate the user's clipboard. When the user tried to transfer around $20,000, the receiving address was automatically replaced, resulting in the funds being sent to the wrong place. The challenge with these attacks is that users are not engaging in obviously risky behavior. They are simply searching for the official website, downloading a tool, and copying a command, all of which are part of their daily workflow.

Social Engineering: Most Active and Destructive

The key to social engineering is not technology but getting the victim to lower their guard at a critical moment.

The most common way is to impersonate someone the victim already knows. In a real case, a victim received an event invitation from a long-trusted friend. The friend insisted on downloading a specific meeting software. Although the victim was somewhat hesitant, they ultimately installed it because of their trust in the friend. A few hours later, their wallet was emptied. It was later discovered that the friend's account had long been under the control of the attacker. High-profile KOLs are also prime targets, with attackers creating highly convincing accounts to exploit the reputations of public figures and lure fans into fake events, airdrops, or investment groups. For ordinary users, the challenge is not to determine if a stranger is trustworthy, but to assess whether an account that "looks like a familiar person or celebrity" has been compromised or impersonated.

Recruitment and interview scams are also becoming more targeted. Attackers may first contact victims through "technical interviews," "operational interviews," or "volunteer interviews," asking them to share their screen, open their wallet, and demonstrate DeFi usage experience. While on the surface, this appears to be part of the interview process, in reality, the attackers are recording wallet addresses, holdings, preferred protocols, and operating habits. In a real case we observed, an attacker gained insight into the victim's recent interaction with protocols and preferences through an interview. Subsequently, the attacker fabricated an airdrop page for the genuine protocol the victim had used, sent highly customized phishing messages, and ultimately swindled about $88,000.

Two Worrying New Scams

The first type is the fake "2FA Security Verification" scam

Attackers send emails disguised as wallet official emails, using a spoofed domain name that is one character different, along with a countdown timer to create a sense of urgency, guiding users to enter their recovery phrase to "complete verification." It is crucial to repeatedly emphasize one thing here: any page that requests a recovery phrase for verification, authentication, recovery, or upgrade is a scam. A recovery phrase is not a verification code; it is ownership of assets, and any legitimate wallet will never ask users to enter it via a webpage for any reason.

The second type is business process fraud.

These attacks do not look like phishing but rather like normal business operations. Attackers, using bait such as "confirming the company's legal name," "external audit," "token ownership confirmation," "cooperation information supplement," deliver malicious attachments disguised as Word, PDF, or collaborative documents. Once opened, the malware masquerades as a system update, prompting users to enter their system password and request permissions such as the camera, screen recording, and keyboard monitoring. The target of these attacks is not necessarily just individual wallets. Many times, attackers are actually trying to gain access to office terminals, browser sessions, password managers, cloud service permissions, and internal project system access.

OKX Practice: Putting User Protection First at the Device and Access Points

Considering the evolving nature of user-side attacks, protecting only on-chain is no longer sufficient. Many losses do not start with an on-chain transaction but much earlier: the user downloads a malicious app, installs a fake plugin, clicks on a phishing website, or continues to sign and transfer on a compromised device. Therefore, OKX is shifting user protection from on-chain transactions to devices, applications, and access points. OKX has launched a Security Scan Assistant to help users identify risks hidden in their devices, reducing the risk of asset loss from malware, fake apps, remote control tools, or clipboard hijacking. As of the publication date, OKX has completed over 200,000 risk detections, found over 60,000 high-risk apps, and guided users to uninstall or deal with them. It currently covers Windows and Android systems, with the MacOS version set to be released.

Furthermore, regarding phishing websites and malicious dApps, OKX also conducts risk identification and alerts users in key scenarios such as suspected risky website visits, wallet connection, or interaction initiation. As of the publication date, OKX has intercepted over 7 million risky website visits, helping users avoid phishing risks before entering their recovery phrases, connecting wallets, or signing transactions. For users, the best security reminder is not a notification after a loss occurs but an early additional step before the risk actually reaches the chain. OKX hopes to intercept more attacks before signing and transferring by detecting device risks, identifying website risks, warning about dApp risks, and analyzing on-chain transactions.

Chapter 4 · How AI is Reshaping Attacks: From Content Forgery to "Deepfakes"

The transformation of the threat landscape by AI was the most profound structural change in the first half of the year. Its impact is not singular. AI has made it easier for attackers to generate phishing emails, fake websites, bogus customer service scripts, and malicious code on one hand, and has also made it easier to forge voices, videos, identities, and social environments on the other. Furthermore, when an AI Agent begins to have funds or access to transaction tools, it becomes a new target of attacks itself.

New Battlefield: When Agents Approach Funds and Transaction Execution

For OKX, the AI Agent is not just a new source of risk but could also become a critical gateway for Web3 to reach more users. OKX is advancing the Agentic Wallet, allowing users to understand strategies through an Agent, manage on-chain operations, and engage in more complex DeFi interactions under authorization and confirmation.

By integrating curated DeFi project plugins, the Agentic Wallet can streamline on-chain operations such as swapping, lending, yield farming, cross-chain activities, which originally required multiple steps, into a more seamless interaction flow. For many ordinary users, this can lower the barrier to understanding and using on-chain finance, bringing Web3 services closer to their familiar product experiences. However, precisely because Agents are starting to approach assets, permissions, and transaction execution, their security requirements are higher than regular applications. An Agent that helps users perform DeFi operations should not only focus on "can it be done," but also address "should it be done," whether the user genuinely understands the consequences of execution, and if tool invocation is restricted within a secure boundary.

The recent Bankr incident has made the risk of AI Agents very tangible. According to disclosures by institutions such as SlowMist, after the attacker activated a certain Agent membership privilege, they sent a Morse code-encoded prompt word injection message to Grok, xAI's AI. Grok decoded and forwarded the content to the on-chain bot @bankrbot, which treated this instruction as trusted input and ultimately transferred around $150,000 to $200,000 on the Base chain.

Although approximately 80% of the lost funds were later recovered, it is enough to illustrate that prompt word injection is no longer just a concept in model security discussions. When an Agent can invoke wallets, transactions, transfers, or other sensitive tools, a malicious input could easily transform into a real transaction.

What is more thought-provoking is not just what commands the Agent executed, but how we should control the Agent's execution authority. For any Agent capable of holding funds or initiating on-chain operations, input filtering, tool invocation sandboxing, permission stratification, sensitive operation secondary confirmation, and pre-execution validation should be basic requirements. And how to make all of this transparent and seamless is something that next-generation Agent products need to focus on.

Industrialization: The Assembly Line of Attacks

AI has significantly reduced the cost of content production and identity spoofing, making it easier for phishers to mass-produce web pages, emails, chat scripts, and fake identities. In high-complexity attacks, AI is embedded in crucial steps involving social engineering, code generation, and environmental deception.

A notable example is the North Korean Lazarus subgroup HexagonalRodent: they use high-paying remote positions and recruitment for prominent projects as bait to contact developers, tricking them into running code with backdoors. Investigations have shown that this organization extensively employs ChatGPT, Cursor-assisted code and social engineering script generation, AI-based website building tools to fake company portals and fabricate executive identities, and even uses AI to "self-audit" their malicious code to evade detection. In just the first quarter of 2026, this group stole wallet data from over 2700 developer systems.

The generation of AI code itself has also brought new challenges. According to OtterSec, Georgia Tech attributed 35 out of 74 CVEs in March to AI-generated code; a scan of around 1400 "vibe-coded" applications revealed 2038 severe vulnerabilities, over 400 exposed keys, and 175 cases of personal information leakage.

These numbers also reveal that AI-generated code should not enter production environments simply because it is "functionally feasible." Instead, code audits, key scans, permission checks, and test coverage should be even more stringent.

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

For the phishing landscape, the most significant change AI has brought is that scams have evolved from forging single pieces of content to creating an entire, coherent, and sustainable false environment—known as "Synthetic Reality."

In the "Truman Show" operation disclosed by Check Point, attackers led victims into a private investment group. The group contained AI-generated "investment experts" and a plethora of AI-played "investors." These roles continuously provided analyses, showcased profits, and interacted with victims in real-time based on their language. Victims were not dealing with just a scammer but a complete environment where people seemed to chat, make money, endorse, and follow up.

A case revealed by the Singaporean police was even more extreme: a fraud syndicate impersonated government officials, guiding victims into a carefully orchestrated Zoom meeting where AI-generated virtual figures of the Prime Minister, President, MAS representatives, and other authority figures appeared simultaneously. Through confidentiality agreements and subsequent fund arrangements, they constructed an extremely authoritative full-fledged scenario that ultimately led victims to lose around 4.9 million Singapore dollars.

This marks a fundamental shift in the target of attacks: attackers aim to deceive not your judgment of a particular piece of information, but your perception of the entire environment's reality. In such times, the traditional "identify suspicious information" defense is becoming ineffective.

OKX Practice: Prioritizing Agent Security Before Plugin Integration and Transaction Execution

Take the recent Bankr incident as an example, where the attacker injected a Morse code-encoded passphrase into a message, tricking the Agent's assessment and ultimately prompting it to initiate a genuine on-chain transfer. Such events reveal a harsh reality: the Agent's "brain" is susceptible to deception. It could be misled by a passphrase injection, could invoke problematic plugins, or could simply have insufficiently rigorous logic. For this reason, OKX does not place the full burden of security on the Agent's judgment alone. Regardless of how an on-chain transaction is generated, OKX conducts an independent risk assessment before it is signed and broadcasted, so even if the Agent's judgment is compromised by passphrase injection or malicious plugin hijacking, assets cannot be transferred without the user's knowledge. The final line of defense against risk should not rely on whether the Agent is intelligent enough but should be secured at the moment the transaction is actually confirmed on the chain.

To make this line of defense reusable, OKX is further modularizing its accumulated on-chain risk identification capabilities. Around the Agent's execution of key on-chain operations — "which assets will this transaction alter," "are the target contract and tokens risky," "is the authorization scope abnormal," "does the simulated execution result align with the user's intent" — OKX aggregates core capabilities such as underlying asset movement parsing, transaction security simulation, token risk analysis, and address risk identification into reusable security skills, which are open to developers. If any of these checks determine a risk, OKX will prompt for user confirmation or directly intercept the transaction.

Furthermore, we understand that the security of the Agentic Wallet cannot solely occur in the final step of transaction execution. As long as the Agent can integrate plugins, read contexts, call tools, and orchestrate on-chain transactions, it may face risks such as passphrase injection, context poisoning, malicious plugins, unauthorized tool invocation, and supply chain attacks. Contamination at any stage could be magnified into actual asset losses. Therefore, OKX has established admission reviews and regular inspection mechanisms for plugin integration into the Agentic Wallet. For DeFi plugins accessing the Agentic Wallet, OKX examines them from multiple dimensions such as code security, permission scopes, tool call boundaries, and external dependencies to mitigate risks posed by malicious code, abnormal permissions, and supply chain poisoning. After a plugin is launched, OKX continuously conducts inspections and risk monitoring to prevent the introduction of new security issues in subsequent updates.

We hope more developers building Agent applications will not need to build on-chain security capabilities from scratch. The Agent can organize transactions more intelligently, but it must also execute transactions more cautiously. Only when plugin admission, tool invocation, transaction simulation, risk analysis, and user confirmation form a complete loop, can the Agentic Wallet truly bring complex DeFi operations to more users, without also bringing along complex risks.

Chapter 5 · Security Recommendations

Reviewing the attacks in the first half of 2026, many losses seemed to take different paths but ultimately converged at a few key moments: someone signed a transaction they didn't understand, a system granted excessive permissions, a team trusted the wrong data source, a user believed someone disguised convincingly enough.

Therefore, security recommendations should not be just the four words "increase vigilance." For both project teams and users, it is more useful to move the defense line forward: before signing, before authorizing, before executing, and before trusting the other party, add an extra verification step.

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

Understand before signing, avoid single points of failure, verify before trusting.

First, Understand Before Signing

Many attacks occur not because the signer was not involved but because the signer did not truly understand what they signed. The Drift incident is a typical case. The attacker did not directly steal the private key but induced the signing of a maintenance transaction that could be exploited in the future. The immediate impact may not be apparent at the time of signing, but that does not mean there will be no future loss. Especially with durable nonces, presigned transactions, multisig authorizations, contract upgrades, Owner changes, Minter permissions, Delegate operations, once these transactions are mistakenly signed, the consequences may far exceed a normal transfer.

For project teams, critical transactions should not only consider "who signed" but also whether the "signer understood." Multisig, admin operations, contract upgrades, cross-chain configurations, oracle modifications should all have clear transaction parsing, simulation results, and review processes. For significant asset outflows, permission changes, threshold adjustments, timelocks, two-factor confirmations, and anomaly alerts should be set up. For users, it is also essential to develop a habit: if you don't understand, don't sign. If the wallet interface cannot explain which assets will be transferred, what permissions will be granted, which contract will be called, or if there is unlimited authorization or abnormal risk, you should pause. A truly secure signature should not just be a hash or an incomprehensible calldata but should let users know what they are doing.

This is also why OKX continues to invest in transaction analysis. We want users to see not just the "Confirm" button, but the true intention behind the transaction.

Second, Avoid Single Point of Failure

Many large losses in the first half of the year were essentially not due to the exploitation of a bug, but to the fact that a certain permission level was too high and too centralized. Once breached, it was enough to individually determine the destination of the funds.

KelpDAO exposed the single point of failure of the validation path, while Resolv Labs exposed the single point of failure of cloud keys. Multiple incidents of private key leaks and device intrusions further illustrate that as long as critical permissions are concentrated in a few accounts, devices, or services, attackers often only need to breach a weak link to take away a large amount of funds. For project teams, the design of critical paths should default to conservatism, with the core principle being: don't let any single link independently decide whether funds can leave. Do not let an RPC, a DVN, a price feed, a cloud key, or an admin address be the sole switch determining the flow of funds. Critical operations such as permission changes, minting, withdrawals, upgrades, etc., should split permissions, set thresholds, implement rate limiting, and add anomaly monitoring, so that any anomaly requires crossing multiple independent checkpoints, rather than a clear path. Cloud keys, CI/CD credentials, MPC nodes, hot wallets should also be managed in a tiered manner based on their fund control rights, rather than treated as regular technical configurations.

For users, the same logic applies. Do not use the same wallet to store all assets while frequently engaging in various DApp interactions—large assets and daily interaction wallets should be kept separate to minimize the impact of a single mistake. Infrequently used authorizations should be regularly revoked; exercise particular caution when encountering operations such as unlimited allowance, full NFT approval, Permit/Permit2, delegation, etc. Many attacks do not immediately transfer assets but first obtain authorization, waiting for the user to lower their guard before taking action.

The key is not to allow the breach of a single link to directly determine the fate of all your funds. The more independent checkpoints an attacker needs to cross to succeed, the smaller the impact of a breach of a single point. This is not about security obsession but the most basic risk control in Web3.

Third, Verify Before Trusting

In the first half of 2026, attackers increasingly relied less on "rough fake links" and began to exploit things that users already trust: friend accounts, search results, app stores, conference software, recruitment processes, KOL identities, and even the "real people" in videos.

AI makes this even more dangerous. Voices can be cloned, videos can be manipulated, chat tones can be mimicked, entire investment groups, meeting rooms, customer service processes can be staged. Many future scams will not look like scams; they will resemble a normal interview, a cooperation communication, a security verification, a friend invitation, or a project meeting.

For project teams, any request involving funds, permission, code execution, and deployment process should not be confirmed through a single channel. A video call is not proof of identity, and a familiar online account is not proof of identity either. Key operations must be independently verified through a trusted out-of-band channel, such as a known phone call, internal system, hardware signature process, multi-party confirmation mechanism, rather than solely relying on the identity displayed in a chat window.

For users, it is also essential to remember a few bottom lines. Any page that requests input of a recovery phrase is a scam. Any requests for remote control, screen sharing, installation of unfamiliar conferencing software, or execution of terminal commands should be halted immediately. Any operations involving transfers, authorizations, airdrop claims, account recovery, or security verification should be reconfirmed through official channels, rather than following links provided by the other party.

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

Implementing Security Before Loss Occurs

Behind these three pieces of advice is essentially the same directive: do not wait until funds have already been transferred to begin prioritizing security.

Project teams need to front-load risk control into the signature, permission, deployment, cross-chain, and key management processes. Users need to front-load judgment into connecting wallets, entering recovery phrases, installing software, and granting signatures. Wallets, platforms, and security products should also take on more responsibility, translating complex on-chain risks into user-friendly reminders, intercepting one step ahead before the risk truly materializes on the chain.

OKX will also continue to invest in this direction: leveraging transaction analysis to help users understand risks before signing; employing device security protection and URL risk identification to block phishing and malicious software before on-chain interaction; utilizing KYC risk capabilities to identify abnormal addresses, malicious tokens, high-risk authorizations, and suspicious transactions; and through Agentic Wallet's plugin access, tool invocation sandbox, and transaction simulation, enabling Agents to assist users in completing complex operations without exposing users to complex risks.

Security does not require every user to become a security expert. A genuinely good security product should clearly explain risks at the point where users are most likely to make mistakes, block dangers, and return decision-making power to users.

Acknowledgments and Data Sources

The industry data and cases in this report have been supported by the following partners: SlowMist, OtterSec.

Disclaimer: This report is for industry reference only and does not constitute any investment, legal, or compliance advice. The cited loss data is based on asset price estimates at the time of the event and may differ from the listed figures due to factors such as incomplete disclosure.

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia