Creators Speak | The Biggest Risk in the Crypto Industry is Thinking It's Safe

"Creators Speak" is a dialogue column launched by Foresight News, where we ask outstanding creators selected each month about hot topics in the market and compile the collected results into articles, gathering diverse opinions to explore deeper thoughts.

Written by: Outstanding Content Creators of Foresight News, October 2026

Compiled by: Foresight News

There is no permanent safe haven, which is a common warning given by recent crypto security incidents. Risks are spreading across various platforms, from custodial services and on-chain applications to offline storage. AI has lowered the threshold for targeted scams, easily penetrating the protective systems that the public has relied on for a long time through subtle permission traps. Most people rely on brand reputation and mature designs to judge risks, subconsciously letting down their guard. Danger often arises from this certainty; the biggest risk in the crypto industry is thinking it is safe.

This issue of "Creators Speak" focuses on "Asset Security." We invited Beosin, Mankun Blockchain Legal Services, Fugui, Biteye researcher Jason, and specially invited Web3 security agency BlockSec, Bitget Wallet COO Alvin Kan, and KOL in the Chinese crypto circle, on-chain analyst Ai Yi to join this discussion.

We posed five questions: "Share your feelings and experiences regarding recent security incidents," "What are the causes of rising industry risks?" "Knowing the risks, why choose to authorize?" "How does AI phishing affect asset security?" and "What risk control suggestions do you have?" Below are the answers we collected.

1. What intuitive feelings have you gained from this round of intensive security incidents? If you have personally encountered related risks or witnessed friends experiencing theft or authorization incidents, feel free to share.

Beosin: My intuitive feeling from this round of security incidents is that the security boundaries of crypto assets are being reshaped. The focus of attacks has shifted from smart contract vulnerabilities to signatures/permissions/frontend hijacking, social engineering, and supply chain attacks, targeting multi-signature signers, operations personnel, administrators, frontend interfaces, or ordinary users, not just the code on the chain. In the past, users could mitigate risks by diversifying asset storage, but this year's round of security incidents has greatly shaken users' confidence; no matter where users store their crypto assets, they may have security concerns about the wallets, protocols, and platforms where the assets are stored.

Mankun Blockchain Legal Services: My feeling is that it is best not to understand security as simply "choosing the right platform/wallet" and thinking that is enough; we need to look at the process of how our custodial assets are used.

Binance's preliminary investigation indicated that it was due to the invasion of the developer's computer and the attackers gaining backend access. As a lawyer, I think it is important to ask some more critical questions: After an incident occurs, who can users turn to, and who will bear the losses? Do those who promise compensation have the actual ability to fulfill it? I believe these are questions users should consider when choosing services.

Therefore, we should more seriously distinguish different risks.

I once had a similar experience. While working on a project, a project party contacted me through a Telegram channel, and we discussed many project matters, eventually reaching an agreement. However, one strange thing was that their project delivery had to be done on their Trillium (similar to Notion or domestic collaboration software like Feishu). A few days into the project, my AI detected that this software was illegally reading my browser password keychain, especially targeting information related to wallets and exchanges. (I have a habit of regularly letting AI scan my backend for abnormal software operations.) I only realized there might be a problem when I confronted the "project party," and they had already disappeared. After some research, I discovered that the Trillium they required me to use had a backend vulnerability (the software is open-source) that could read my browser keychain. Fortunately, my important information, including keys, was isolated on another computer that is rarely connected to the internet; otherwise, I can't imagine what would have happened.

Fugui: Firstly, it is evident that the attack logic of this round of intensive security incidents has changed: the focus of attacks has shifted from contract code vulnerabilities to human factors, extending from on-chain to off-chain infrastructure, and from finding vulnerabilities to breaking trust relationships; combined with AI empowerment, attacks are characterized by scale and concentrated outbreaks.

In recent years, I have encountered many security incidents of varying sizes (some content cannot be disclosed due to lack of authorization, only publicly available content will be shared). What impressed me the most was a senior technical expert I respect. He was not originally in the crypto industry and had years of experience in network security operations. One night, he called me after drinking, and the news made my heart race.

A few weeks ago, he consulted me about server deployment of hot wallets, private key configuration, and implementation plans for DeFi interactions. I only introduced him to the industry-standard open-source paths, and with his technical ability, he could deploy it himself by referring to the documentation. At that time, I had a ready-made environment image solution and considered sending it to him directly, but fortunately, I didn't.

That call was to inform me that his server had been breached, and his private keys were leaked, resulting in a loss of nearly one million dollars. He and his partner originally planned to do DEX quantitative trading, and the funds were not entirely his, but he was responsible for security operations, so he would likely bear the losses. In addition to the asset loss, this incident severely damaged his personal reputation. Afterward, he traced the server's source and preserved on-chain evidence, but the funds were basically unrecoverable. Such risks are indeed hard to guard against.

For developers, it is essential to clarify the boundaries of rights and responsibilities: if you cannot fully bear the risks, try not to come into contact with core sensitive information like private keys.

Now, the automation level and response speed of attacks are increasing rapidly. Previously, to demonstrate a DApp Demo, I uploaded a batch of test private keys used only for the test network on GitHub, containing only test tokens, thinking there was no risk. As a result, within just two hours, the corresponding addresses on mainstream EVM chains were locked in bulk, and even if assets were transferred later, the holder of the private keys could not mobilize them.

Biteye Researcher Jason: There are three main feelings: technically, AI has shifted the balance of offense and defense; in the market, security incidents are indifferent to bull and bear markets; and in terms of outcomes, the handling of stolen platforms is becoming increasingly transparent.

I almost fell victim to a phishing site through a fake Telegram account in my early years, and I also encountered a DEX's old contract being hacked because I didn't check the news and transferred coins as usual, resulting in them being stolen. The incidents of 2026 repeatedly remind us: just because you can't imagine it happening doesn't mean it won't.

BlockSec: My first feeling is that the scale and frequency of theft have reached unprecedented levels. This year, the amount stolen in the industry has set a new record, with Binance alone losing about $6.3 billion by the end of October, four times the previous $1.5 billion incident with Bybit. Our team has been tracking stolen funds on-chain for a long time, and almost every week, new cases come in, often before the previous one is resolved, the next one occurs.

What concerns me more is not the amount but that these attacks are becoming less reliant on so-called advanced vulnerabilities. In this case with Binance, the attackers did not touch the private keys but instead accessed the system through an engineer's compromised device, going all the way to the signing and withdrawal process, ultimately allowing the system to release the funds itself.

Moreover, this method has not only appeared in the crypto industry. This autumn, seven financial institutions in South Korea were consecutively breached, primarily by one person using a set of AI automated penetration tools, entering through side doors like loan intermediaries, leaking information of over 60,000 people. Traditional finance and crypto are facing the same type of adversaries; this wave of risk is not just a problem for one industry.

In the years of doing on-chain security, my most direct feeling from this round is that many people previously assumed that "top platforms and top teams are definitely safer"; now this premise is no longer reliable. The world's largest exchange and the oldest multi-signature solutions have all encountered issues during the same period. Security is shifting from a shortcoming of certain players to a common issue that the entire industry must face anew.

Bitget Wallet COO Alvin Kan: My most intuitive feeling is that we need to treat continuous attacks as a daily condition of system operation. The recent concentration of incidents has heightened everyone's awareness of risks, but the attacks themselves will not stop with this round of attention.

AI is changing the cost of attacks. Attackers can use fewer human resources while testing more systems and finding more vulnerabilities. For all products involving assets, a question needs to be considered: if a certain layer of protection is breached, can the subsequent mechanisms still protect the assets and limit the impact within a controllable range?

Ordinary users are also bearing more and more security judgments: Is the link real? What does the signature mean? How long will the authorization last? All of these constitute the implicit costs of using crypto products. The industry cannot place all the responsibility on "users need to be more vigilant." If using a product securely requires users to first understand complex contracts and permission mechanisms, then the product itself still has a lot of work to do.

Ai Yi: It’s unexpected yet within reason.

From an on-chain perspective, the complexity of DeFi Lego has increased significantly over the past two years, and with more links, it naturally becomes easier to make mistakes. Most innovative projects do not have sufficient funds, and once attacked, they are finished. I have friends who staked a large amount of funds in DeFi projects, and after incidents, their rights protection efforts have lasted over a year with no progress. Fortunately, exchanges like Bybit, Bitget, and Binance have done sufficient rehearsals and have compensation capabilities, so even if funds were stored during theft, rationally, there is not too much panic.

2. Currently, centralized platforms, on-chain protocols, and hardware wallets are continuously experiencing security incidents. Aside from the specific technical details of individual attacks, what factors do you think have collectively raised the overall risk in the industry? For example, product prioritization of user experience, continuously decreasing attack thresholds, insufficient user risk awareness, the proliferation of new permission models, and rapid industry expansion can all be discussed.

Beosin: Firstly, the rapid improvement of AI model capabilities poses a significant challenge to the security field, greatly reducing the costs of phishing and social engineering, and accelerating the process of vulnerability discovery and exploitation. Hackers can use AI to quickly understand contract logic, generate exploit code, and batch scan similar vulnerabilities to complete attacks. This year, several suspected AI-assisted attacks have occurred on-chain, and the increasing number of unopen-sourced/abandoned smart contracts being attacked can also support this point.

In this context, most blockchain projects are actually facing issues of insufficient security budgets and professionals. They may only complete one security audit and cannot build a continuous, dynamic security defense system, making them highly susceptible to security incidents when facing AI-powered hacker attacks. For exchanges or centralized platforms, they are prone to errors in internal operations and signing systems, and wallet signers may underestimate the impact of signatures and authorizations, making them vulnerable to hackers.

Mankun Blockchain Legal Services: I think a prominent issue is that user operations are becoming increasingly convenient, but the subsequent operations and ecosystems of platforms are becoming increasingly complex. Users may only see a "confirm" button, but it actually involves multiple links such as websites, wallets, and third-party software. Attackers may start from software or websites that everyone relies on. The previous Ledger Connect Kit incident is an example.

Additionally, I believe that product design needs reflection. Reducing operational steps is certainly valuable, but if users grant permissions with a wide range without understanding the consequences just to skip a few confirmations, this convenience comes at a cost.

Another issue is that we cannot place all the blame on "users not being careful enough." If a product can only be understood by security experts, I think it has not adequately ensured the safety of ordinary users. The same applies internally within the platform; permission management and emergency response cannot lag behind and fail to evolve.

Fugui: The security incidents in the crypto industry in 2026 may seem scattered, but they reflect a structural shift: the focus of attacks is shifting from "vulnerability economics" to "permission economics". I previously analyzed this trend in an article for Foresight News. Data from TRM Labs in the first half of the year shows that infrastructure and operational attacks accounted for only about 15% of incidents but caused approximately 76% of financial losses; Hacken's second-quarter statistics indicate that losses from compromised keys, signers, and infrastructure accounted for as much as 88.3%, while losses from smart contract vulnerabilities were only about 11%. Although the two reports differ in their statistical periods and classification criteria, they both indicate that code vulnerabilities still pose a threat, and significant losses are increasingly occurring outside of code—specifically in areas such as permission management, key custody, and operational processes.

The rising industry risks are not due to a sudden leap in hacker technology (the Lazarus Group has been a large-scale attack organization since before 2020), nor is it solely the threat posed by AI; the core contradiction lies in the severe imbalance among the speed of industry expansion, the complexity of permission systems, and the capability for security governance.

• First, products prioritize both efficiency and user experience. Solutions like account abstraction, smart wallets, cross-chain bridges, and low-latency multi-signatures lower the usage threshold but often expand the scope of authorization, compressing manual review and risk buffer space.
• Second, the economic logic of attacks has changed. AI has significantly reduced the costs of phishing, identity spoofing, vulnerability scanning, and social engineering attacks. Attackers no longer need to breach high-security contracts; they only need to penetrate the weakest link in the trust chain: signers, developer hosts, RPC nodes, and supply chain dependencies can all become entry points.
• Third, the industry faces a problem of "pseudo-decentralization." Multi-signatures do not equal security; if signers share cloud service providers, RPCs, and front-end environments, even if mathematically distributed, there are still single points of failure at the infrastructure level.
• Fourth, user risk awareness and industry governance cannot keep pace with the rhythm of innovation. Audit work mostly focuses on contract code, while permission configurations, operational processes, and continuous monitoring are often overlooked.

Biteye researcher Jason: The core factor is AI. First, product iterations are accelerating, but vulnerabilities only reveal themselves over time. Second, the threshold for attacks has dropped significantly; new models can almost deliver a dimensionality reduction attack on old DeFi protocols. Third, many DeFi protocols lack the funds and personnel for maintenance, yet they hold assets far exceeding their security capabilities, making them targets for hackers. I saw a meme on X saying: if DeFi exists for another five years, by 2031, Pyongyang will be a prosperous metropolis, LOL.

BlockSec: If I had to pick one reason, I would say it is AI. It acts more like an amplifier, magnifying the existing problems in the industry all at once.

In the past, the extent of what an attacker could do was determined by their technical level and manpower; now, this line has been significantly leveled by AI. Finding vulnerabilities, writing exploits, moving laterally, and even subsequent fund transfers and laundering can all be handled by automated tools. One person equipped with a set of AI can accomplish what used to take a team weeks. This autumn, seven financial institutions in South Korea were breached, and the underlying model was essentially this "one person plus a set of automated penetration tools" approach. Social engineering is the same; AI can customize scripts, forge voices and videos using your publicly available information, turning phishing from a broad net into a precise strike. The threshold for attacks is decreasing, while the scale and precision are increasing; this is the fundamental change.

AI is so lethal because the industry itself has long buried several conditions that can be easily exploited by it. First, products generally prioritize experience over security; to ensure smoothness, many risks are turned off or hidden by default, and automated attacks take advantage of this gap. Second, funds are highly concentrated and can be transferred across dozens of chains in minutes on-chain; once automated tools gain access, the scale and speed are beyond what manual efforts can keep up with. Third, new permission models like authorization, Permit, and account abstraction are increasingly used, allowing a single signature to access much larger assets than in the past, making them suitable for batch abuse by scripts. Fourth, the industry is expanding too quickly; front-end, third-party services, and various tools are interdependent, and if any link is breached, it can compromise the entire system, while AI makes it faster and cheaper to find and penetrate the weakest link.

Therefore, in my view, these factors are not simply parallel to AI; rather, AI has pushed the entire industry's attack surface and single-instance losses to a new height.

Bitget Wallet COO Alvin Kan: The core issue is still the change in the benefits and costs of attacks. The more concentrated the assets, the higher the returns after a successful attack; AI has also lowered the costs of finding vulnerabilities, writing attack code, and repeated testing. Defenders need to face more frequent and larger-scale attempts.

At the same time, the systems behind products are becoming increasingly complex. A user's single action may involve wallets, front-ends, contracts, cross-chain bridges, and third-party services. Each link may have security measures when viewed individually, but that does not mean that the entire process is secure when connected. How permissions are transferred, how identities are verified, and what happens when a service fails all need to be checked within the complete business process.

The pursuit of convenience in products also needs to advance in sync with permission management. One-click trading, automated strategies, and session authorizations have practical value, but if operational steps are reduced, users' understanding of the scope of authorization also diminishes, which can lead to a situation where "the experience becomes simpler, but the actual permissions granted become more complex." New permission models themselves are not necessarily more dangerous; the key is whether they clearly limit the amount, duration, and executable actions, as well as whether users can conveniently revoke them.

Ai Yi:

1. In recent years, the market value of cryptocurrencies has skyrocketed, and the "fat sheep" has become even fatter; the "cost-effectiveness" of attacking cryptocurrencies has significantly increased;
2. The popularization and development of AI have indeed lowered the cost of attacks, making hackers "smarter";
3. The DeFi Lego blocks are stacking higher and higher, and the innovation in gameplay and complexity of protocols have, to some extent, reduced the stability of the system;
4. Cryptocurrencies especially emphasize trends and hot spots; whether it's Restaking or Perp DEX, when they are hot, a large number of new projects will emerge, but audits and oversight have not kept pace, and the projects themselves may sacrifice some aspects to catch up.

3. When participating in on-chain activities, many people need to sign for a wide range of permissions for benefits, liquidity, or automated experiences. Have you ever clearly understood the risks but still chosen to sign the authorization? What considerations did you have at the time? Looking back, are there any hidden risks that you did not foresee at the time?

Beosin: I have not personally experienced a major security incident due to authorization, but I have observed that users either do not know the risks or are aware that there may be risks but still choose to sign the authorization. The initial considerations are often the potential for airdrop rewards or liquidity benefits, such as "this project is well-known and should be reliable" or "so many people are using it, it should be fine." Such considerations often make users easy targets for phishing attacks.

Additionally, users often forget to revoke authorizations after granting them or do not revoke them for the sake of convenience; if the contract that received the authorization has vulnerabilities and is exploited by hackers, they will suffer losses. This year, there have been many such cases on Ethereum and BNB Chain, where contracts that had been abandoned for years were found to have vulnerabilities, and many users had not revoked the authorizations for these contracts, leading to hackers exploiting the vulnerabilities and transferring the corresponding users' crypto assets.

Mankun Blockchain Legal Services: I can understand why some people would accept such trade-offs. Repeated authorizations are indeed cumbersome and may increase transaction costs, and automated operations have practical needs. However, I believe that "knowing there are risks" and "knowing exactly what risks you are taking" are two different things.

For me personally, determining whether an authorization is worth accepting requires clarifying the specific authorization to whom and the amount, as well as how to revoke it; these questions cannot be overlooked. What is often neglected is that the impact of authorization may last longer than the transaction itself. For example, some unlimited token authorizations may continue to cover future transfers of that type of token to the same address.

Therefore, I prefer to first limit the potential range of losses before considering the benefits. If the expected benefit is only a few hundred dollars, but it exposes assets far exceeding what is needed for that transaction to a certain permission for a long time, I think it is not worth it.

Fugui: Such scenarios are very common, and I have also had experiences of blind signing. Wallets sometimes only pop up a string of hexadecimal signature information, making it difficult for ordinary users to directly assess the corresponding operations, granted permissions, and potential risks.

In scenarios like DeFi, cross-chain, and liquidity mining, I have also signed unlimited Approve, Permit2, or authorized automated protocols to execute operations to simplify operations and improve capital efficiency. The considerations at the time were very practical: on one hand, this is an interaction model that has long formed in DeFi; without authorization, services cannot be used; for example, ERC-20 tokens need to be approved first for the contract to call transferFrom to transfer assets. On the other hand, the reputation of mature protocols, audit reports, and community consensus also make it easy for people to let their guard down.

Often, it is not that users do not know the risks, but rather that they are weighing convenience, capital efficiency, and security.

In retrospect, I realize that what I underestimated was not the contract vulnerabilities, but that authorization itself is a continuously accumulating security liability. We trust the protocols, but we may later encounter risks such as front-end hijacking, changes in administrator permissions, dependent contracts being attacked, and signatures being intercepted and delayed in broadcasting. Under new permission models like Permit2, account abstraction, and EIP-7702, signatures are no longer just confirmations of single transactions; they may open up more complex asset operation permissions.

Now, I assess the risks of each authorization: clarifying the benefits, the authorizing party, the validity period, the revocation method, and the worst-case losses. A common misconception on-chain is that just because it can be technically revoked, it means the risks are controllable.

My personal risk control method is address isolation: one private key, one address should ideally only authorize a single service provider; when needing to use the service, funds are transferred to that address separately.

Biteye researcher Jason: I have done so, but generally, I participate using a new wallet and only put in the funds needed for that occasion. For example, to buy coins faster, I have signed an automated authorization for a certain exchange wallet. Although it has an IP whitelist and a 7-day automatic expiration limit, risks such as browser session hijacking still exist. In the internet age, some say people like to trade privacy for convenience, but in the crypto world, what is traded away is security. Convenience is immediate, while risks are delayed, making it difficult for ordinary people to weigh them. So now I revoke authorizations after use, and many wallets support this feature.

BlockSec: I believe that almost everyone deeply involved on-chain has signed before. To use a certain protocol or to seize a new opportunity, I still clicked after weighing efficiency and risk.

However, this issue cannot be entirely blamed on users. Many protocols, in order to enhance user experience and save on gas fees for authorization, default to requesting unlimited limits or authorizations that far exceed the actual needs of the transaction. When you want to use it, you are presented with such an authorization box, and very few truly implement authorization based on actual needs. The risk is quietly shifted onto the users: you think you are only authorizing a one-time use, but in reality, you are leaving the contract with the power to access your assets in the future. The protocol parties bear responsibility here; keeping convenience for themselves while shifting risks to users is inherently irresponsible.

Looking back now, there are two types of risks that were not fully anticipated at the time. One type is the long tail of authorizations, where users forget to revoke limits after they are used up, leaving them hanging in their wallets. If that protocol is later compromised, or if their keys have issues elsewhere, these old large authorizations become ready-made withdrawal points. The other type is incomprehensible signature content; many excessive or even malicious authorizations are hidden within seemingly normal transactions. Without simulation or item-by-item review, ordinary users cannot detect what they have actually signed away.

I later developed two habits: first, regularly checking and revoking unnecessary authorizations; second, using simulation tools to clearly see what permissions this transaction will grant before signing, and what the account will look like after execution. However, relying solely on user discipline is far from enough; protocol parties should default to only requesting necessary limits and make minimal authorization an industry standard, rather than demanding unlimited authorization from the outset.

Alvin Kan, COO of Bitget Wallet: I understand the practical considerations behind this choice. When participating in trading, liquidity management, or automated strategies, confirming each transaction does indeed affect efficiency, and repeated authorizations may increase costs. Users often weigh the balance between profit opportunities, operational convenience, and security risks, especially when dealing with familiar protocols, making it easy to think, "I’ve used it many times without issue before, so it should be fine this time."

But the continuity of authorization is often underestimated. Users think they have only completed one operation, but the permissions left behind may still be valid after this operation ends. Some off-chain signatures do not require gas fees but may still grant asset transfer permissions, which may not be executed immediately.

The security state at the time of authorization does not guarantee future safety. If the relevant contract can be upgraded, or if management permissions are later compromised, the originally trusted entities may also change. For certain token authorizations that remain valid, transferring similar assets to the same address later may continue to expose them to risks.

Ai Yi: Honestly, it’s quite hard to avoid, especially in situations where "time is of the essence". For example, rushing to sell an airdrop and clicking on a fake link, or choosing unlimited authorization to shorten Meme trading time, many have suffered losses; it’s a case of "I understand the reasoning, but still can’t avoid it".

4. Hackers are now starting to use AI for precise phishing, identity impersonation, and customized scripts to conduct social engineering attacks. In your view, what new changes will this bring to the security of crypto assets, and how should ordinary users respond to such scams?

Beosin: AI-driven social engineering attacks are characterized by automation and scalability, while the targets are more precise, often focusing on whales, project participants, and KOLs for targeted phishing. For ordinary users, any authorization operation should carefully verify the contract address and scope of permissions, and avoid signing transaction requests whose results cannot be confirmed. In daily life, users can pay more attention to the latest risk threats shared by security companies or crypto communities, understand related attack forms, and be cautious in identifying AI-generated phishing messages or links impersonating customer service, project parties, or KOLs.

Mankun Blockchain Legal Services: I think the biggest change is that scammers can create a scam that looks more real at a lower cost, and they can target many people at once. AI can help generate natural scripts, fake identity materials, and can also mimic familiar voices and create videos. My experience above is one such example; I had several long voice communications with the "project party". Although AI cannot yet perfectly match accents and tones, they can indeed manually imitate the voices of real people.

This content is provided for general informational purposes only and doesn't constitute financial, investment, legal, or tax advice. Any events, rewards, online promotions, or related information mentioned herein should not be considered a recommendation, solicitation, or invitation to purchase, sell, trade, or otherwise deal in any crypto assets. Crypto assets are highly volatile and may result in loss. The availability of WEEX services, products, and related events may vary by region. You are responsible for ensuring that your participation is in accordance with applicable local laws and regulations.