OKX Web3 Security Report: H1 2026
Jointly produced by the OKX Web3 Security Team, SlowMist, and OtterSec
Foreword
In the first half of 2026, if you looked only at publicly disclosed losses, down nearly 60% year over year, the crypto industry might appear to be getting safer. In reality, that decline came almost entirely from the absence of a single catastrophic event comparable to the same period last year, not from any weakening of attacker activity. If anything, the opposite is true: attacks are growing more frequently, techniques are evolving, and the target is shifting from "code" to "people."
In the past, many projects placed the greatest emphasis on contract audits and onchain activity monitoring. But in the first half of this year, the source of the largest losses was often not the contract itself. It might be a blind-signed admin transaction, a leaked cloud key, a developer's laptop implanted with malware, or even a video call that looked entirely genuine.
For OKX, security is not a slogan in a report but a real risk we handle every day: malicious addresses, phishing domains, high-risk signatures, abnormal approvals, cross-chain risks, scam tokens, and social engineering attacks appear continuously. This report sets out to do two things: first, to clearly explain the attack shifts of the past half-year that truly warrant attention; and second, to place some of OKX's practices in wallet security, risk control, cross-chain, and agent security into an industry context, as a starting point for broader discussion.
Chapter 1 · The H1 2026 Security Landscape: Dispersed Incidents, Concentrated Losses
Falling losses do not mean fewer attacks
There is a phenomenon in the first half of this year that is easily misread: the total amount stolen fell, yet the number of security incidents actually rose. According to incomplete statistics from the SlowMist Hacked archive, there were 182 publicly disclosed security incidents in H1, causing approximately $956 million in losses.
Compared with the same period in 2025 (121 incidents, approximately $2.373 billion in losses), the number of incidents rose about 50% year over year, while financial losses fell about 60% year over year. The apparent drop in loss value is mainly because the same period last year contained a single ultra-large incident. The absence of an equally extreme event this year does not mean attackers have stopped. Once the outlier is stripped out, this year's comparable losses actually rose rather than fell. Attack activity has not weakened, it has shifted toward higher-frequency, more dispersed strikes.
For comparison, the largest publicly disclosed incidents of 2025 H1 are listed below:
# | Project | Date | Loss | Type | Key details |
|---|---|---|---|---|---|
1 | Bybit | 2025/02/21 | ~$1.5B | Supply chain attack | Attackers compromised the laptop of a developer at Safe{Wallet}, Bybit's signing tool, then tampered with the JavaScript on the Safe web interface, injecting malicious code aimed specifically at Bybit's cold wallet. |
2 | Cetus | 2025/05/22 | ~$223M | Contract vulnerability | Attackers exploited an arithmetic overflow flaw in the liquidity market-making module, using tiny inputs to leverage huge positions, forge liquidity proofs, and drain assets from multiple pools. |
3 | Nobitex | 2025/06/18 | ~$90M | Private key compromise | Hot wallet private keys were stolen; assets were sent to burn addresses. |
4 | Phemex | 2025/01/23 | ~$85M | Private key compromise | Hot wallet private keys were stolen; assets were drained in bulk across 16 chains. |
5 | Infini | 2025/02/24 | ~$50M | Private key compromise | The private key controlling project funds was stolen, and funds were transferred out in a single transaction. |
6 | GMX | 2025/07/09 | ~$41M | Contract vulnerability | Attackers exploited missing input validation in the GLP trading logic, crafting illegal parameters to manipulate pricing and redeem assets at inflated value. |
7 | MIM_Spell | 2025/03/25 | ~$13.41M | Contract vulnerability | Attackers exploited a flaw in the lending/liquidation logic to borrow and drain assets without equivalent collateral, with a single attacker address running dozens of operations in a short span. |
8 | Cork Protocol | 2025/05/28 | ~$11.98M | Access Control Issue | A contract function that should have been permission-protected lacked access control and could be called by any address, letting the attacker execute sensitive operations meant to be admin-only. |
9 | Resupply | 2025/06/26 | ~$10M | Contract vulnerability | Attackers exploited a precision-loss flaw in the contract's calculations, accumulating arbitrage through repeated operations of specific amounts to amplify the gap and drain assets. |
10 | zkLend | 2025/02/11 | ~$9.5M | Contract vulnerability | Attackers manipulated rounding errors in the interest/exchange-rate calculation, gradually inflating book balances before emptying the pool. |
(Data source: OKX; loss amounts estimated at token prices at the time of each incident.)
Three shifts in H1 that deserve the most attention
First, large losses are increasingly occurring outside contract code. The most severe losses of the half-year did not come from vulnerabilities like smart-contract reentrancy or precision loss, but from operational-level failures: blind-signed admin transactions, a poisoned single verifier node, a stolen cloud signing key. By incident count, contract and logic vulnerabilities remained the leading attack cause (85 incidents); but by loss amount, supply chain attacks ranked first at about $298 million, followed by contract vulnerabilities (about US$152 million) and private key compromise (about US$130 million). This illustrates that an audit report alone is not enough for a project. Even if a contract has no obvious flaw in its onchain logic, as long as there is single-point risk in the signing process, cloud keys, cross-chain verification, or operations systems, attackers can still bypass the contract and strike through other weak links. The boundary of security has long since expanded from "is the code safe" to "who can sign, where the keys are stored, whether verification relies on a single point, and whether operations can be trusted."
Second, ordinary users are becoming the primary targets. As the cost of attacking protocols rises, attackers turn to users. Recurring user-side attack methods in H1 included phishing sites, malicious browser extensions, search-ad poisoning, fake support agents, fake recruiters, malicious meeting software, clipboard hijacking, and fake 2FA verification. These attacks do not necessarily rely on sophisticated technology; what they truly exploit are users' habits and trust in daily operations: trusting the first search result, trusting app-store ratings, trusting a link sent from a friend's account, trusting the "real person" who appears in a video call, trusting a page that says "security verification." And AI makes all of this cheaper and more convincing. Attackers can mass-produce phishing content, forge identities, clone voices, and create deepfake videos, polishing once-crude scams until they can fool even experienced users. Whether an attack succeeds depends less and less on whether the user "understands the technology," and more on whether the attacker can hit the blind spots in human trust.
Third, as AI Agents flourish, they are also becoming hackers' new prey. As Agents move from "able to converse" to "able to execute," calling tools, reading context, controlling assets, and initiating transactions, the greater their capabilities, the more severe the consequences once they are attacked. In the past, prompt injection was largely a concept within model safety, where the worst outcome was making a model say something it shouldn't; but when an Agent can sign transactions and move funds, a single malicious input, disguised as normal content, can turn directly into a real onchain loss. Attacks against an Agent's "cognition-to-execution" chain, such as prompt injection, context poisoning, and tool-permission abuse, are becoming a threat as dangerous as attacks on private keys.
Chapter 2 · The Project Perspective: The Biggest Losses Often Happen Outside the Contract
For projects, the point most worth remembering about H1 2026 is this: a failure at the operational level can be just as severe as a contract vulnerability – sometimes more so.
The incidents below are the major project security events of H1 2026, compiled by OtterSec by loss amount. They span several of the most common high-value attack surfaces: cross-chain bridges, verification infrastructure, signing processes, cloud keys, developer devices, oracles, and access control.
# | Project | Date | Loss | Type | Key details |
|---|---|---|---|---|---|
1 | KelpDAO / LayerZero | 2026/04/18 | ~$292M | Bridge / infrastructure compromise | Poisoned LayerZero's internal RPC and DDoS'd external nodes, forcing the single DVN to accept forged data |
2 | Drift Protocol | 2026/04/01 | ~$285M | Social engineering + admin abuse | A six-month in-person social engineering campaign induced blind-signing of a Solana durable-nonce admin transaction |
3 | Step Finance | 2026/01/31 | ~$40M | Private key compromise | An executive's device was compromised; the keys were used to drain the treasury |
4 | Humanity Protocol | 2026/06/09 | ~$36M | Private key compromise | A developer's machine was infected with malware; the H token crashed over 80% |
5 | Truebit | 2026/01 | ~$26M | Contract vulnerability | Deployed with an older compiler lacking overflow protection, the contract let an oversized purchase request wrap the price to near zero. The attacker minted tokens for almost nothing and sold them back to drain reserves. |
6 | Resolv Labs | 2026/03/22 | ~$23M | Cloud key compromise | An AWS KMS key was stolen and used to mint ~80M unbacked USR |
7 | Rhea Finance | 2026/04/16 | ~$18.4M | Oracle manipulation | The attacker used fake tokens and self-created liquidity pools to distort price feeds and fool the oracle, then over-borrowed real assets against inflated fake collateral. |
8 | Blend Protocol | 2026/02 | ~$10M | Oracle manipulation | Price manipulation of a low-liquidity asset enabling over-borrowing |
9 | SagaEVM | 2026/01 | ~$7M | Validation logic error | A crafted payload bypassed validation to mint without backing |
10 | TrustedVolumes | 2026/05 | ~$6.7M | Access Control Issue | An unprotected contract function was abused to authorize malicious orders |
(Data source: OtterSec; loss amounts estimated at token prices at the time of each incident.)
KelpDAO: The attacker didn't hit the contract—they broke through the verification path
KelpDAO was the single largest loss of the half-year. What makes it most alarming is that the attacker did not directly attack the contract logic, but rather the verification path for cross-chain messages. According to OtterSec's post-mortem, attackers poisoned LayerZero's internal RPC nodes while simultaneously launching DDoS attacks against honest external nodes. In the end, the single DVN the bridge relied on saw mostly forged data and signed off on a withdrawal with no real burn behind it. About 116,500 rsETH were transferred out, of which roughly US$75 million was later frozen.
A single DVN had long been considered a high-risk configuration. But in the past, this was mostly a theoretical risk flagged in architecture discussions; after the KelpDAO incident, it became a real loss of nearly US$300 million. The lesson for projects is direct: do not let one verifier, one RPC, one price source, or one signing path determine whether funds can leave. As long as there is only a single verification point on a critical path, attackers will study it first.
Cross-chain bridges and oracles especially need multi-source verification, redundant nodes, withdrawal rate-limiting, anomaly monitoring, and emergency pause mechanisms. Otherwise, even if the contract itself has no obvious flaw, attackers can still take the funds through off-chain infrastructure.
Drift: The attacker spent half a year waiting for one signature
If KelpDAO exposed the fragility of infrastructure, Drift exposed the fragility of the signing process. This was not an impromptu phishing attempt, but a long-cultivated social engineering attack. The attacker spent about six months building relationships, waiting for a moment when a multisig signer would sign a critical admin transaction without fully understanding its impact. The most alarming aspect of this incident was the abuse of Solana's durable-nonce mechanism. The attacker induced the relevant personnel to pre-sign multisig authorization transactions. At the moment of signing, these transactions appeared to have no immediate effect; but after Drift subsequently adjusted its multisig threshold, the attacker broadcast the already-obtained signed transactions and drained over 50% of TVL in a very short time.
This kind of attack reminds projects: something that looks "harmless" at the moment of signing does not mean it cannot be exploited in the future. Blind signing, pre-signing, and unparseable admin transactions should all be treated as high-risk operations. Critical transactions must be clearly parseable, simulatable, and subject to review. For multisig teams, the signing process itself should be treated as a core asset to protect.
OKX in practice: From transaction parsing to signing-risk protection
From OKX's practice, protecting against signing risk cannot stop at the level of "this transaction was initiated by the user themselves." What matters more is whether the user truly understands the consequences of a transaction before signing it. Around high-risk scenarios such as Solana durable nonce, account-ownership changes, and nonce-account initialization, OKX has built detection, alerting, interception, and isolation capabilities across multiple risk rules including solana_assign_account_owner, solana_init_nonce_account, and nonce_account_risk, and in H1 2026 intercepted/alerted on such high-risk operations a cumulative over 4 million times, helping users recognize and steer clear of these risks before signing.
At the same time, OKX continues to invest in transaction-parsing capabilities. Our goal is to make onchain transactions more transparent and readable, achieving "what you sign is what you get" as much as possible: what the user sees should not be a string of incomprehensible calldata or instructions, but rather what the transaction actually intends to do, which assets it will affect, what permissions it will grant, and whether any abnormal risk exists. To date, OKX has parsed and matched over 50,000 onchain methods, helping users more clearly understand the transactions they are signing.
Chapter 3 · The User Perspective: Trust Became the Sharpest Weapon
User-side risk continued to rise in H1. Many attacks no longer begin with a strange link, but from entry points users are familiar with and inclined to let their guard down around: app stores, search results, friends' accounts, meeting software, recruitment processes, support emails.
Phishing now borrows the shell of real platforms
Phishing remains the leading method behind user asset theft, but its form is evolving.
One common approach is malicious browser extensions. Attackers often imitate well-known wallet tools, copying brand names, icons, and page copy, then use fake ratings and download counts to make the extension look like a legitimate product. When users see it in an official app store, they easily lower their guard, assuming it is the plugin they already know. These extensions often adopt a "local shell, cloud poisoning" strategy. This means the extension itself contains no malicious logic directly, making it easier to pass the store's static review. The truly dangerous phishing pages are delivered in real time by a remote server, and attackers can swap out pages, change domains, or even display different content to different users at any time. Once you enter your seed phrase or private key, control of your assets has already been handed over.
Another type is search-engine ad phishing. Attackers buy ad slots for popular keywords, placing a spoofed official site at the top of search results. In a typical case in H1, a user searching for a development tool after buying a new computer clicked the top ad, then followed the page's prompt to run an "install command" in the terminal. That command actually deployed a clipboard-hijacking trojan, allowing the attacker to alter what the user's page showed. Later, when the user transferred about US$20,000, the receiving address was automatically replaced, sending the funds to the wrong destination. What makes this kind of attack hard to defend is that the user is not doing anything obviously dangerous. They are merely searching for an official site, downloading a tool, copying a command – actions that are part of ordinary daily work.
Social engineering: The most active and destructive vector
The key to social engineering is not technology, but getting the victim to drop their guard at a critical step.
The most common method is impersonating someone the victim already knows. In one real case, a victim received an event invitation from a long-trusted friend. The other party insisted the victim download a specific meeting app; although the victim hesitated, they installed it anyway because they trusted the friend. A few hours later, the wallet was drained. Only afterward did they discover the friend's account had long been under the attacker's control. High-profile KOLs are equally hard hit, with attackers creating near-identical fake accounts and using the public figure's credibility to lure followers into fake events, fake airdrops, and fake investment groups. For ordinary users, the difficulty is not judging whether a stranger is trustworthy, but judging whether an account that "looks like a friend or a celebrity" has already been compromised or impersonated.
Recruitment and interview scams have also become more targeted. Attackers first approach victims through "technical interviews," "operations interviews," or "volunteer interviews," asking them to share their screen, open their wallet, and demonstrate DeFi experience. On the surface, this is an interview process; in reality, the attacker records wallet addresses, holdings, frequently used protocols, and operating habits. In one real case we observed, the attacker learned through the interview about the victim's recent protocol interactions and preferences, then forged an airdrop page for a protocol the victim had actually used and sent a highly customized phishing message, ultimately defrauding about US$88,000.
Two new methods worth watching
The first is the fake "2FA security verification" scam. Attackers send an email disguised as a wallet's official communication, using a spoofed domain that differs by just one character, then add a countdown to create urgency, guiding users to enter their seed phrase to "complete verification." One thing must be stressed repeatedly here: any page that asks you to enter your seed phrase for verification, authentication, recovery, or upgrade is a scam. A seed phrase is not a verification code. It is control of your assets, and no legitimate wallet will ever ask users for it through a web page for any reason.
The second is business-process fraud. This kind of attack does not look like phishing, it looks like normal work. Attackers use business scenarios such as "confirming a company's legal name," "external audit," "token vesting confirmation," or "supplementing partnership materials" as bait, delivering malicious attachments disguised as Word, PDF, or collaboration documents. Once opened, the malware disguises itself as a system update, prompts the user to enter their system password, and requests permissions such as camera, screen recording, and keylogging. The target of this kind of attack is not necessarily just a personal wallet. Often, what the attacker really wants is the office endpoint, browser sessions, password manager, cloud service permissions, and access to the project's internal systems.
OKX in practice: Moving user protection forward to the device and accessing entry points
Judging from the changes in user-side attacks, protection at the onchain layer alone is no longer enough. Many losses do not begin with an onchain transaction, but earlier: the user downloaded a malicious app, installed a disguised plugin, clicked a phishing site, or continued to sign and transfer on a compromised device. Therefore, OKX is moving user protection forward from the onchain transaction to the device, application, and access entry points. OKX has launched a security scanning assistant that helps users identify risky apps hidden on their devices, reducing the risk of asset loss from malware, disguised apps, remote-control tools, or clipboard-hijacking programs. As of the date of publication, OKX has completed over 200,000 risk scans, identified over 60,000 high-risk apps, and guided users to uninstall or handle them.
At the same time, for phishing sites and malicious DApps, OKX performs risk detection and alerting in critical scenarios such as when users visit suspected risky URLs, connect wallets, or initiate interactions. As of the date of publication, OKX has cumulatively intercepted over 10 million risky website visits, helping users avoid phishing risks before entering a seed phrase, connecting a wallet, or signing a transaction. For users, the best security reminder is not a notification after a loss occurs, but one extra step of interception before the risk actually lands onchain. Through device risk detection, URL risk identification, DApp risk warnings, and onchain transaction parsing, OKX aims to stop more attacks before signing and transfer.
Chapter 4 · How AI Is Reshaping Attacks: From Content Forgery to "Synthetic Reality"
AI's transformation of the security landscape is the most profound structural change of the half-year. Its impact is not singular. On one hand, AI makes it easier for attackers to generate phishing emails, fake websites, fake support scripts, and malicious code; on the other, it makes voices, videos, identities, and community environments easier to forge. Furthermore, as AI Agents begin to hold funds or call transaction tools, they themselves become new attack targets.
A new battlefield: When Agents begin approaching funds and transaction execution
In OKX's view, AI Agents are not only a new source of risk, they may also become an important gateway for Web3 to reach more users. OKX is advancing the Agentic Wallet, allowing users to understand strategies, manage onchain operations through an Agent, and complete more complex DeFi interactions under the premise of authorization and confirmation.
By integrating vetted DeFi project plugins, the Agentic Wallet can consolidate onchain operations that once required multiple steps, such as swaps, lending, yield management, cross-chain, and more, into a more natural interaction flow. For many ordinary users, this can lower the barrier to understanding and using onchain finance, and bring Web3 services closer to the product experiences they are familiar with. But precisely because the Agent begins to approach assets, permissions, and transaction execution, its security requirements are higher than those of ordinary applications. An agent that helps users complete DeFi operations cannot focus only on "can it execute," but must also answer "should it execute," "does the user truly understand the consequences of execution," and "are tool calls confined to a safe scope."
The recent Bankr incident made AI Agent risk very concrete. According to disclosures from SlowMist and others, after activating a certain Agent membership, the attacker sent xAI's Grok a prompt-injection message encoded in Morse code. Grok decoded the content and relayed it to the onchain bot @bankrbot, which treated the instruction as trusted input and executed it, ultimately transferring about US$150,000–200,000 on the Base chain.
Although about 80% of the lost funds were later recovered, it is enough to show that prompt injection is no longer merely a concept within model-safety discussions. When an Agent can call wallets, trading, transfers, or other sensitive tools, a single malicious input can become a real transaction.
What is truly thought-provoking is not just what instruction the Agent executed, but how we should govern the Agent's execution permissions. For any Agent capable of holding funds or initiating onchain operations, input filtering, tool-call sandboxing, permission tiering, secondary confirmation of sensitive operations, and pre-execution verification should all be baseline requirements; and how to make all of this transparent and frictionless is the top priority the next generation of Agent products must consider.
Industrialization: The assembly-line-ization of the attack process
AI has dramatically lowered the cost of content production and identity forgery, making it easier for phishers to mass-produce web pages, emails, chat scripts, and fake identities; in high-complexity attacks, AI is embedded in key stages of social engineering, code generation, and environment forgery.
A typical example is HexagonalRodent, a subgroup of North Korea's Lazarus: they approach developers using bait such as high-paying remote positions and recruitment for well-known projects, luring them into running backdoored code. Investigations show the group made extensive use of ChatGPT and Cursor to assist in generating code and social engineering scripts, used AI website builders to fake corporate sites and fabricate executive identities, and even used AI to "self-check" their own malicious code to evade detection. In Q1 2026 alone, the group stole wallet data from over 2,700 developer systems.
AI-generated code itself has also introduced new problems. As cited by OtterSec, Georgia Tech attributed 35 of the 74 CVEs in March to AI-generated code; a scan of about 1,400 "vibe-coded" applications found 2,038 critical vulnerabilities, over 400 exposed secrets, and 175 instances of personal data leakage.
These figures also reveal that AI-generated code cannot enter production simply because it is "functional." Code audits, secret scanning, permission checks, and test coverage should, if anything, be more rigorous.
The endgame: From "content forgery" to "synthetic reality"
AI's biggest change to phishing scenarios is the upgrade of fraud from the forgery of a single piece of content to a complete, self-consistent, continuously operating fake environment –"Synthetic Reality."
In the "Truman Show" operation disclosed by Check Point, attackers drew victims into a private investment group. The group contained AI-generated "investment experts" as well as a large number of AI-played "investors." These characters continuously posted analyses, showed off profits, and interacted in real time based on the victim's language. What the victim faced was not a single scammer, but a complete environment where people appeared to be chatting, making money, endorsing, and following up.
A case disclosed by the Singapore police was even more extreme: a fraud ring impersonated senior government officials and drew the victim into a meticulously designed Zoom meeting, in which AI-generated virtual likenesses of the Prime Minister, President, and a monetary authority representative appeared simultaneously. Combined with a confidentiality agreement and subsequent fund arrangements, they constructed a highly authoritative, complete scenario that ultimately caused the victim to lose about S$4.9 million.
This marks a fundamental shift in the target of attack: what the attacker seeks to deceive is no longer your judgment of a single piece of information, but your perception of the authenticity of the entire environment. In such an era, traditional "identify the suspicious message" defenses are failing.
OKX in practice: Doing Agent security before plugin admission and transaction execution
Take the recent Bankr incident as an example: the attacker used a prompt-injection message encoded in Morse code to fool the Agent's judgment and ultimately drive it to initiate a real onchain transfer. Incidents like this reveal a hard truth: an agent's "brain" can be deceived. It may be misled by prompt injection, it may call a compromised plugin, or its logic may simply not be rigorous enough. That is precisely why OKX does not place the entire burden of security on the Agent's own judgment. No matter how an onchain transaction is generated, OKX runs an independent risk check before it is signed and broadcast, so that even if the Agent's judgment is hijacked by prompt injection or a malicious plugin, the transaction still cannot move assets without the user's knowledge. The last line of defense against risk should not depend on whether the Agent is smart enough; it should be backstopped at the point where the transaction actually reaches the chain.
To make this backstop reusable, OKX is also further modularizing its accumulated onchain risk-identification capabilities. Around the most critical questions, when an agent executes onchain operations – "which assets will this transaction change," "do the target contract and token carry risk," "is the authorization scope abnormal," "does the simulated execution result match the user's intent". OKX aggregates underlying capabilities such as asset-change parsing, transaction security simulation, token risk analysis, and address risk identification into reusable security skills, and opens them to all developers. When any of these checks flags a risk, OKX will prompt the user for a second confirmation, or block the transaction outright.
At the same time, we understand that Agentic Wallet security cannot happen only at the final step of transaction execution. As long as an agent can integrate plugins, read context, call tools, and organize onchain transactions, it may face risks such as prompt injection, context poisoning, malicious plugins, over-privileged tool calls, and supply chain attacks. If any single link is poisoned, it can be amplified into a real asset loss. Therefore, OKX has established admission review and periodic inspection mechanisms for plugin integration in the Agentic Wallet. For DeFi plugins integrated into the Agentic Wallet, OKX checks across multiple dimensions, including code security, permission scope, tool-call boundaries and external dependencies, to reduce the risks of malicious code, abnormal permissions and supply chain poisoning. After a plugin goes live, OKX also conducts ongoing inspection and risk monitoring to prevent plugins from introducing new security issues in subsequent version updates.
We hope more developers building Agent applications will not have to build onchain security capabilities from scratch. An agent can organize transactions more intelligently, but it must also execute transactions more cautiously. Only when plugin admission, tool calls, transaction simulation, risk analysis, and user confirmation form a complete closed loop can the Agentic Wallet truly bring complex DeFi operations to more users, rather than bringing complex risks along with them.
Chapter 5 · Security Recommendations
Reviewing the attacks of H1 2026, you will find that many losses took different paths but ultimately came down to a few critical moments: someone signed a transaction they did not understand, a system granted excessive permissions, a team trusted the wrong data source, a user believed a person disguised convincingly enough.
So security advice should not be just the words "stay vigilant." For projects and users, what is more useful is to move the line of defense forward: add one more layer of verification before signing, before authorizing, before executing, before trusting the other party.
OKX suggests distilling the lessons of the half-year into three phrases:
Understand before you sign; avoid single points of failure; verify before you trust.
First: Understand before you sign
Many attacks succeed not because the signer was absent, but because the signer did not truly understand what they were signing. The Drift incident is a classic case. The attacker did not directly steal the private key, but induced the signing of an admin transaction that could be exploited later. Appearing to have no immediate effect at the moment of signing does not mean it will not cause a loss in the future. Especially for durable nonce, pre-signed transactions, multisig authorizations, contract upgrades, owner changes, minter permissions, and delegate operation – once mis-signed, the consequences can far exceed those of an ordinary transfer.
For projects, critical transactions cannot be judged only by "who signed," but also by "whether the signer understood." Multisig, admin operations, contract upgrades, cross-chain configurations, and oracle modifications should all have clear transaction parsing, simulation results, and review processes. For operations such as large asset outflows, permission changes, and threshold adjustments, timelocks, secondary confirmation, and anomaly alerts should be set. For users, develop a habit too: if you don't understand it, don't sign it. If the wallet page cannot explain which assets this transaction will move, what permissions it will grant, which contract it calls, or whether there is unlimited approval or abnormal risk, you should stop. A truly secure signature should not be just a string of hashes or incomprehensible calldata – it should let the user know what they are doing.
This is why OKX continues to invest in transaction parsing. We want users to see not just a "Confirm" button, but the real intent behind the transaction.
Second: Avoid single points of failure; defend in layers
Many large losses in H1 were, at their core, not about a single bug being exploited, but about a single link being too powerful, too concentrated, and too easily abused.
KelpDAO exposed single-point risk in the verification path. Resolv Labs exposed cloud-key risk. Multiple private-key leaks and device-intrusion incidents show that as long as critical permissions are concentrated in a few accounts, a few devices, or a few services, an attacker only needs to break through one of them to take away large amounts of funds. For projects, critical paths should default to conservative: no single link should be able to decide, on its own, whether funds can leave. Do not let one RPC, one DVN, one price source, one cloud key, or one admin address determine whether funds can leave. Critical operations such as cross-chain bridges, oracles, minting, withdrawals, upgrades, and pauses should all have split permissions, thresholds, rate-limiting, and anomaly monitoring, so that any anomaly has to clear several independent checkpoints. Cloud keys, CI/CD credentials, deployment scripts, MPC nodes, and hot wallets should all be managed according to their fund-control power, not treated as ordinary technical configuration.
For users, the same logic matters just as much. Do not use a single wallet to store all your assets and frequently interact with DApps. Large assets and daily-interaction wallets should be separated; infrequently used approvals should be revoked periodically; and be especially cautious with operations such as unlimited-amount approvals, full NFT approvals, Permit / Permit2, and Delegate. Many attacks do not transfer assets at the outset, but first obtain authorization and transfer funds later, once the user has let their guard down.
The fewer single points there are, the smaller the blast radius after an attacker succeeds. This is not security perfectionism, but the most basic risk control in Web3.
Third: Verify before you trust
In H1 2026, attackers relied less and less on "crude fake links" and increasingly exploited what users already trust: friends' accounts, search results, app stores, meeting software, recruitment processes, KOL identities, even the "real person" in a video.
AI makes this more dangerous. Voices can be cloned, videos can be forged, chat tone can be mimicked, and entire investment groups, meeting rooms, and support flows can be built out. In the future, many scams will not look like scams, they will look like a normal interview, a partnership discussion, a security verification, a friend's invitation, or a project meeting.
For projects, any request involving funds, permissions, code execution, or deployment processes should never be confirmed through a single channel alone. A video meeting is not proof of identity, and neither is an acquaintance's account. Critical operations must be reviewed through trusted out-of-band channels, such as a known phone number, internal systems, a hardware signing process, or a multi-person confirmation mechanism, rather than trusting only the person who appears in a chat window.
For users, remember a few bottom lines too. Any page that asks you to enter your seed phrase is a scam. Any request for remote control, screen sharing, installing unfamiliar meeting software, or running terminal commands should make you stop first. Any operation involving transfers, authorization, airdrop claims, account recovery, or security verification should be re-confirmed through official channels, rather than continuing down a link the other party provided.
In the AI era, security is no longer just about recognizing "does this message look fake," but about first confirming "is this person, this entry point, this process actually real."
Practice Security Before Incurring Losses
Behind these three recommendations lies a single direction: don't wait until the funds are already gone to start doing security.
Projects need to move risk control forward into the signing, permission, deployment, cross-chain, and key-management processes. Users need to exercise their judgement before connecting a wallet, entering a seed phrase, installing software, or signing an authorization. Wallets, platforms, and security products should also take on more responsibility, translating complex onchain risks into warnings users can understand, and adding one more step of interception before the risk actually lands onchain.
OKX will continue to invest in this direction: through transaction parsing, letting users understand the risk before signing; through device security protection and URL risk identification, stopping phishing and malware before onchain interaction; through KYS risk capabilities, identifying abnormal addresses, malicious tokens, high-risk approvals, and suspicious transactions; and through the Agentic Wallet's plugin admission, tool-call sandboxing, and transaction simulation, helping Agents complete complex operations for users without bringing the complex risks along too.
Security does not require every user to become a security expert. A truly good security product should, at the step where users are most likely to make a mistake, explain the risk clearly, block the danger, and return the choice to the user.
Acknowledgments and Data Sources
The industry data and cases in this report were supported by the following partners: SlowMist and OtterSec.
Disclaimer: This report is for industry reference only and does not constitute any investment, legal, or compliance advice. Cited loss figures are estimated based on asset prices at the time of each incident; due to factors such as incomplete disclosure, actual losses may be different from the figures listed.
