"Creator's Say" is a dialogue column introduced by Foresight News, where we will ask the outstanding creators selected each month about hot market topics and compile the collected results into text, drawing on collective opinions to explore deeper insights.

Written by: Foresight News Outstanding Content Creators of October 2026

Compiled by: Foresight News

There is no permanent safe harbor, which is a common warning derived from recent crypto security incidents. From custodial platforms and on-chain applications to offline storage, risks are spreading across different mediums. AI has lowered the threshold for targeted scams, and many subtle permission traps can easily break through the protection systems that the public has relied on for a long time. Most people rely on brand reputation, word of mouth, and mature designs to judge risks, unconsciously letting their guard down. Danger often emerges from this sense of certainty; the greatest risk in the crypto industry is thinking that it is safe.

This issue of "Creator's Say" focuses on "Asset Security." We invited the outstanding creators of Foresight News for October 2026, including Beosin, Mankun Blockchain Legal Services, Fugui, Biteye researcher Jason, and especially invited Web3 security agency BlockSec, multi-chain self-custodial Web3 wallet Bitget Wallet COO Alvin Kan, as well as KOLs and on-chain analysts in the Chinese crypto circle, Ai Ayi, to join this discussion.

We posed five questions: "Share your feelings and experiences regarding recent security incidents," "What are the triggers for increasing industry risks?" "Knowing the risk, 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 direct feelings has this round of intensive security incidents left you with? If you have personally encountered related risks or witnessed friends experiencing theft or authorization incidents, feel free to share.

Beosin: My direct 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 signature/permissions/frontend hijacking, social engineering, and supply chains, with attack targets centered on multi-signature signers, operations staff, administrators, front-end interfaces, or ordinary users, not just the code on-chain. In the past, users could mitigate risks in certain links/platforms by dispersing assets, but this year's round of security incidents has dealt a significant blow to user confidence, as users may have concerns about the security of wallets, protocols, and platforms regardless of where they put their crypto assets.

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

Binance's initial investigation indicated that it was due to the intrusion of a developer's computer and the attacker gaining backend access. As a lawyer, I think in situations like this, we should be asking some more important questions: After an incident occurs, who can users turn to? Who will bear the losses? Do those who promise compensation actually have the ability to fulfill it? I believe these questions should be considered by users when choosing services.

Therefore, we should more seriously differentiate different risks.

I once actually had a similar experience. Once, 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, it was strange that their project delivery had to take place on their Trillium (similar to Notion or other collaboration software). A few days into the project, my AI identified that this software was illegally reading my browser’s password keychain, especially targeting information like wallets and exchanges. (I regularly have my AI scan my backend for abnormal running software.) It was then that I realized there might be a problem. When I went to confront the "project party" and verify the situation, they had already vanished. After research, I found that the "project party" wanted me to deliver using Trillium, which had a backend vulnerability (as it is open-source software), and was able to read my browser's keychain, etc. Fortunately, my important information, including keys, was isolated on another computer that was rarely connected to the internet; otherwise, I shudder to think what could have happened.

Fugui: First of all, it is quite evident that the logic of attacks in 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, turning from finding vulnerabilities to breaking trust relationships; coupled with AI empowerment, attacks are becoming more scaled and characterized by concentrated outbreaks.

In recent years, I have encountered numerous security incidents of varying sizes (some content cannot be elaborated upon due to lack of authorization, so I will share only publicly available information). What impressed me the most was a respected technical predecessor of mine. He was originally not in the crypto industry but had many years of experience in network security operations. One night, he called me after drinking, which set my heart racing.

A few weeks ago, he consulted me about deploying servers for hot wallets, configuring private keys, and implementing DeFi interactions. I only introduced him to industry-standard open-source paths, and with his technical capability, he could deploy it himself according to the documentation. At that time, I had a ready-made environment image plan and had considered sending it directly to him but thankfully did not do so.

The call was to inform me that his server had been breached, the private key leaked, and he had lost nearly one million dollars. He and his partner initially planned to do DEX quantitative trading; the fund did not wholly belong to him, but he was responsible for its security operations, and he would likely have to bear the loss. Besides asset loss, this incident severely damaged his personal reputation. Afterward, he traced the server and preserved on-chain evidence, but the funds were mostly unrecoverable. This kind of risk is truly unpredictable.

For developers, it is crucial to clarify boundaries of rights and responsibilities: If one cannot fully bear the risks, try to avoid touching sensitive core information like private keys.

Now, the degree of automation and response speed of attacks is increasing rapidly. Previously, to demonstrate a DApp Demo, I uploaded a batch of test private keys for testing on GitHub, where there were only test tokens, thinking there was no risk. As a result, in just two hours, the corresponding addresses on mainstream EVM chains got bulk-locked, and even after transferring assets later, holding the private keys could not mobilize it.

Biteye researcher Jason: There are three main feelings: On the technical side, AI has shifted the balance of attack and defense; in the market, security incidents are indiscriminate of bull or bear; in terms of results, the handling of stolen platforms is becoming increasingly transparent.

I myself almost fell victim to a phishing site through a fake Telegram account a few years ago, and I have encountered a previous DEX contract being hacked because I did not check the news and proceeded to transfer tokens as usual, which resulted in a theft. The incidents of 2026 serve as a continuous reminder: the unexpected in the dark forest doesn’t mean it won’t happen.

BlockSec: My first feeling is that the scale and frequency of breaches have reached an unprecedented level. This year, the amount stolen in the industry broke records again; Binance alone was rolled up for about $6.3 billion at the end of October, which is four times the previous Bybit incident of $1.5 billion. Our team has been tracing stolen funds on-chain, with nearly new cases coming in every week, often before the previous one has been completed, another occurs.

What concerns me more is not the amount, but that these attacks increasingly do not rely on so-called complex vulnerabilities. In Binance's case, the attackers didn't touch the private keys but accessed the system from a compromised engineer's device, making their way into the signature and withdrawal processes, which eventually let the system itself release the funds.

Moreover, this approach has not only appeared within the crypto industry. This autumn, seven financial institutions in South Korea were hacked in succession, largely by one person using a set of AI automation penetration tools, penetrating through side doors like loan intermediaries, leaking information of over 60,000 individuals. Traditional finance and crypto are facing the same type of adversary; this wave of risks does not belong solely to one industry.

From my experience in on-chain security over the years, this round has given me the clearest feeling: many people previously assumed that "top platforms and top teams are definitely safer." Now, this premise can no longer be relied upon. The world's largest exchanges and oldest multi-signature solutions all experienced issues during the same period. Security is transitioning from a shortcoming of a certain type of player 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 ongoing attacks as a regular condition of system operation. The recent concentrated incidents have heightened risk awareness, but attacks themselves will not stop with this round of attention.

AI is changing the cost of attacks. Attackers can employ fewer personnel while testing more systems and finding more vulnerabilities. For all asset-related products, there needs to be a consideration of this problem: if one layer of defense is breached, can the subsequent mechanisms still protect the assets, and can the impact be limited to a controllable range?

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

Ai Ayi: Unforeseen yet within reason, I suppose.

From an on-chain perspective, the complexity of DeFi Legos has increased significantly over the past two years, and the more steps involved, the more likely errors become. Most innovative projects lack sufficient funding; once attacked, they come to an end. I have friends who pledged large sums of funds in DeFi projects, and after incidents occurred, their rights protection took over a year with no progress. On the exchange side, it is fortunate that Bybit, Bitget, Binance, and others have made sufficient rehearsals and have compensation capabilities. Therefore, even if funds were stored during theft, being rational does not lead to excessive panic.

2. With security incidents breaking out successively across centralized platforms, on-chain protocols, and hardware wallets, aside from the specific technical details of individual attacks, what factors do you think have collectively increased the overall risk in the industry? For example, product prioritization in refining experience, decreasing attack thresholds, insufficient user risk awareness, the popularization of new permission models, rapid industry expansion, etc., could all be discussed.

Beosin: First and foremost, the rapid improvement of AI model capabilities is a significant challenge for the security domain, greatly reducing the cost of phishing and social engineering, and accelerating the process of vulnerability discovery and exploitation. Hackers can utilize AI to quickly understand contract logic, generate exploitation code, and batch scan for similar vulnerabilities. Several suspected AI-assisted attack security incidents have occurred on-chain this year, and increasing attacks on non-open-source/discarded smart contracts also support this point.

Against this backdrop, most blockchain projects are actually facing issues of insufficient security budgets and professionals; they may only conduct a single security audit, unable to build a sustained, dynamic security defense system, making them extremely vulnerable to hacker attacks empowered by AI capabilities. For exchanges or centralized platforms, they are susceptible to internal operational and signature system oversights, where wallet signers may underestimate the impact of signatures and authorizations, thus being exploited by hackers.

Mankun Blockchain Legal Services: I believe a prominent problem is that user operations are becoming increasingly convenient, yet the subsequent operations and ecosystem of platforms are turning more complex. Users might only see a "confirm" button, while the actual process involves multiple steps including websites, wallets, third-party software, and more. Attackers may target common software or sites upon which everyone relies. The earlier Ledger Connect Kit incident is an example.

Additionally, I think product design needs reflection. Reducing operational steps is undoubtedly valuable, but if users, in an effort to save confirmations, grant extensive permissions without being clear about the consequences, that convenience comes at a cost.

Another issue is that we cannot push all responsibility onto "users not being careful enough." If a product's authorization content is only comprehensible to security experts, I believe it has failed at securing ordinary users. The same goes for platforms; internal permission management and emergency response should not always lag behind without development.

Fugui: The security incidents in the crypto industry in 2026 may seem scattered, but behind them lies a common structural shift: the focus of attacks is shifting from "vulnerability economy" to "permission economy." 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 the number of incidents, yet caused about 76% of the financial losses; statistics from Hacken in the second quarter indicate that losses from breaches involving keys, signers, and infrastructure reached 88.3%, while losses from smart contract vulnerabilities were only about 11%. Although both datasets have different statistical cycles and classification criteria, they collectively indicate: code vulnerabilities still pose threats, but significant losses are increasingly occurring beyond the code—especially in areas like permission management, key custody, and operational processes.

The rise in industry risks is not due to a sudden leap in hacker technology (the Lazarus Group has been a scaled attack organization since before 2020), nor is it solely attributable to the threats posed by AI. The core issue lies in the severe imbalance among the speed of industry expansion, the complexity of permission systems, and the capacity for security governance.

• First, products prioritize both efficiency and user experience. Account abstraction, smart wallets, cross-chain bridges, low-latency multi-signing, and other solutions reduce usage barriers but often expand the authorization scope, compressing the space for verbal reviews and risk buffers.
• Second, the economic logic of attacks has changed. AI has significantly reduced the costs of phishing, identity forgery, vulnerability scanning, and social engineering attacks. Attackers no longer need to breach highly secure contracts; they just need to penetrate the weakest link in the trust chain: signers, developers’ host machines, RPC nodes, and supply chain dependencies can all be entry points.
• Third, there is a problem of "pseudo-decentralization" in the industry. Multi-signature does not equal security; if signers share cloud service providers, RPCs, front-end environments, even if it is mathematically distributed, there still exists a single point of failure at the infrastructure level.
• Fourth, user risk awareness and industry governance are not keeping pace with the speed of innovation. Auditing work generally focuses on contract code, while permission configuration, operational processes, and continuous monitoring are often neglected.

Biteye researcher Jason: The core factor is AI. First, product iterations are becoming faster, but vulnerabilities take time to expose. Second, the threshold for attacks has significantly decreased, with new models exerting a dimensional on old DeFi protocols. Third, many DeFi protocols lack the funds and personnel for maintenance but hold funds far exceeding their own security capability, making them a tempting target for hackers. There’s a humorous meme on X saying: if DeFi exists for another five years, by 2031, Pyongyang will become a bustling metropolis. LOL.

BlockSec: If I had to pick just one reason, I would say AI. It acts as an amplifier, magnifying the existing problems within the industry.

In the past, the capabilities of an attacker were limited by their technical skills and manpower, but now this line has been greatly flattened by AI. Finding vulnerabilities, writing exploits, lateral movement, and even post-funding transfers and money laundering can all be handled by automated tools, allowing one person paired with an AI to accomplish what used to require a team weeks of work. This autumn, the hacking of seven financial institutions in South Korea was mainly accomplished through a "one person and a set of automated penetration tools" model. Social engineering is similar; AI can craft messages using your public information, forge voices and videos, transforming phishing from a scattergun approach into precision strikes. The threshold for attacks is decreasing while the scale and accuracy are increasing; this is the fundamental change.

The reason AI is so lethal is that the industry has already buried several conditions that can easily be exploited by it. First, products generally prioritize experience over security; in pursuit of smoothness, many risks are defaulted off or hidden, which automated attacks can exploit. Second, funds are highly concentrated and can be moved across more than a dozen chains within minutes. Once automated tools gain access, the scale and speed are beyond human追的. Third, new permission models such as authorization, permit, and account abstraction are increasingly used, allowing a single signature to access a much larger amount of assets than before, making them highly susceptible to batch abuse by scripts. Fourth, the industry is expanding too quickly, with front-end, third-party services, and various tools relying on each other; if any one link is breached, it can affect the entire system, and AI makes finding and breaking through that weakest link faster and cheaper.

Thus, in my view, these factors are not merely lining up alongside AI; rather, AI has pushed the entire industry’s attack surface and single loss to new heights.

Bitget Wallet COO Alvin Kan: The core issue is that the returns and costs of attacks have changed. The more concentrated the assets, the higher the potential returns after a successful attack; AI has also lowered the costs of locating vulnerabilities, writing attack codes, and retesting. Defending parties must face more frequent and larger attempts.

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

The pursuit of convenience in products also needs to progress alongside permission management. One-click trading, automated strategies, and session authorizations have practical value, but if the operational steps are reduced, the user's understanding of the authorization scope may also diminish, potentially leading to "an increasingly simple experience while the actual granted permissions become more complex." New permission models themselves may not be inherently more dangerous; the key lies in whether they clearly restrict the amount, duration, and executable actions, and whether users can easily revoke them.

Ai Ayi:

1. In recent years, the market value of crypto has skyrocketed, making the "big sheep" even fatter; the "cost-performance ratio" of attacking crypto has significantly increased;
2. The proliferation and development of AI indeed lower the cost of attacks, making hackers "smarter";
3. The DeFi Lego blocks are stacked ever higher, and innovations in gameplay and protocol complexity have, to some extent, reduced system stability;
4. Crypto particularly emphasizes trends and hot spots, whether it be Restaking or Perpetual DEX; when they are hot, a large number of new projects emerge, but the auditing and oversight have not kept pace, and the projects themselves may sacrifice some things to seize the opportunity.

3. When participating in on-chain activities, many people need to sign authorization for broader permissions for the sake of benefits, liquidity, or automated experiences. Have you ever clearly understood the risks yet still opted to sign authorization? What were your considerations at the time? Looking back, are there any latent risks that were not anticipated back then?

Beosin: I have not personally been involved in major authorization security incidents, but I have observed situations where users are unaware of the risks or know there may be risks but still choose to authorize. The considerations initially often include potential airdrop rewards or liquidity gains, "this project is famous, it should be reliable," or "so many people are using it, it should be fine." Such considerations often make users easily fall victim to phishing attacks.

Additionally, users tend to forget to revoke authorizations afterward or do not revoke them for convenience, leading to losses if the authorized contracts have vulnerabilities that hackers can exploit. This year, there have been numerous such cases on Ethereum and BNB Chain, where outdated contracts that had not been used for years were found to have vulnerabilities by hackers, and many users had not revoked the authorizations for these contracts, allowing hackers to exploit the vulnerabilities and transfer 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 raise transaction costs, and automated operations themselves have practical needs. However, I believe that "knowing there is a risk" and "understanding exactly what risk one bears" are two different things.

For me personally, determining whether the authorization is worth accepting requires clarification of the specific authorization amount and how it can be revoked. These questions cannot be overlooked. One easily ignored aspect is that the impact of authorization can continue longer than the single transaction. For example, unlimited authorizations for certain tokens may continue to apply to any such tokens transferred to the same address later.

Therefore, I prefer to first limit the potential loss range and then consider the gains. If the expected gain is only a few hundred yuan yet allows assets far exceeding the needs of that transaction to be exposed to broad authorization for a long time, I consider it unwise.

Fugui: Such scenarios are very common, and I have had blind-signing experiences before. Sometimes wallets only display a string of hexadecimal signature information, making it difficult for ordinary users to directly assess corresponding actions, granted permissions, and potential risks.

In DeFi, cross-chain, and liquidity mining scenarios, in an effort to simplify operations and improve capital efficiency, I have also signed unlimited Approve, Permit2, or authorized automated protocols to execute operations. The considerations back then were quite practical: on one hand, this is a long-established interaction model in DeFi; without authorization, one cannot use the service; for example, ERC-20 tokens need approval first before the contract can call transferFrom to move assets. On the other hand, the good reputation of mature protocols, their audit reports, and community consensus also easily put one at ease.

Often, it is not that one is unaware of the risks, but rather a weighing of convenience, capital efficiency, and security.

Upon reflection, I realized that what I underestimated back then was not the contract vulnerabilities but that authorization itself represents a continual accumulation of security liabilities. We trust protocols but may later face front-end hijacking, changes in administrative permissions, attacks on dependent contracts, and signature interception and delayed broadcasting risks, among others. Under models like Permit2, account abstraction, and EIP-7702, signing is no longer simply a one-time transaction confirmation; it may open up more complex asset operation permissions.

Now, I perform risk assessments for every authorization: clarifying the gains, the granting party, the validity period, the revocation method, and the worst-case loss. A common misconception on-chain is thinking that technical revocability equates to controlled risks.

My risk control method is address isolation: one private key, one address assigned preferably to a single service provider; only transfer funds to that address when needed for services.

Biteye researcher Jason: I have had such experiences but generally participate using new wallets, only putting in the funds needed for that instance. For example, to buy currency faster, I have signed automated authorizations from a certain exchange wallet. Although it had an IP whitelist and a 7-day auto-expiry limit, risks like browser session hijacking still exist. In the internet age, people say that individuals like to exchange privacy for convenience, but in the crypto space, what is sacrificed is security. Convenience is immediate; risk is lagging, making it difficult for ordinary people to weigh the two. Therefore, I now revoke authorizations after use, and many wallets support this functionality.

BlockSec: I believe nearly everyone who deeply engages with on-chain activities has signed such authorizations. To utilize a particular protocol or seize a new opportunity, one ends up weighing efficiency against risk and ultimately clicks through.

However, this cannot solely be blamed on users. Many protocols aim to create a smoother experience and save on gas costs by defaulting to request unlimited permissions or requests far exceeding the actual needs of the transaction. When you wish to use it, that’s the authorization box that pops up; truly doing on-demand authorization is quite rare. Risks are subtly offloaded onto users: you think you’re only granting authorization for a one-time use, but in reality, you’re keeping that contract’s power to use your assets open indefinitely. The issuing protocol bears responsibility; leaving convenience for themselves while pushing risks onto users is fundamentally irresponsible.

Looking back, two types of risks that were not adequately anticipated at the time are: one type is the long tail of authorizations; forgetting to revoke after the quota is used up, leaving it hanging in the wallet, and when that protocol gets breached later, or your keys become compromised elsewhere, those old large authorizations become ready withdrawal channels. The other type is unintelligible signature content, where excessive or even malicious authorizations are hidden within what appears to be normal transactions, and without simulation or examining details, ordinary people cannot perceive what they have signed away.

I later developed two habits: first, regularly checking and revoking unneeded authorizations; second, before signing, using simulation tools to clarify what permissions this transaction will grant and what changes will occur in the account afterward. However, relying solely on user discipline is far from enough; the issuing protocol should default to only apply necessary quotas, making minimal authorization a trend in the industry rather than requiring unlimited authorizations from the start.

Bitget Wallet COO Alvin Kan: I understand the practical considerations behind such choices. While trading, managing liquidity, or engaging in automated strategies, confirming each individual transaction can indeed impact efficiency, and repeated authorizations can also increase costs. Users tend to weigh the opportunity for returns, operational convenience, and security risks, especially when dealing with familiar protocols, often thinking, "I’ve used it many times with no issues; this time should be fine."

But the most easily underestimated aspect is the sustainability of authorizations. Users believe they’ve completed a single operation, but the permissions left behind may still be valid after that operation ends; some off-chain signatures do not require gas but may still grant asset transfer permissions, and they might not be executed immediately.

The safety state at the time of authorization does not guarantee future safety. If the relevant contracts can be upgraded, or management permissions are later compromised, trusted entities could change. For certain asset authorizations that remain valid, assets of the same kind transferred to the same address later may still be exposed to risks.

Ai Ayi: Honestly, it’s quite hard to avoid this, especially in "time-sensitive" scenarios, like rushing to sell airdrops by clicking a fake link or opting for unlimited authorization to shorten the trading time—you end up suffering losses. It's a case of "understanding the rationale but still not managing to avoid it."

4. Hackers are now utilizing AI for precision phishing, impersonating identities, and customizing dialogues to conduct social engineering attacks. In your view, what new changes will this bring to crypto asset security, and how should ordinary users respond to such scams?

Beosin: The characteristics of AI-driven social engineering attacks are automation and scalability, with targets now more precise, often directed at whales, project participants, and KOLs for targeted phishing. For ordinary users, every authorization operation should carefully verify the contract address and permission scope, and one should not sign transaction requests without confirmed outcomes. Users can focus more on the latest threat risks shared by security companies or crypto communities, understand relevant attack forms, and pay attention to recognize AI-generated spoofed customer service, project parties, and KOL phishing messages or links.

Mankun Blockchain Legal Services: I think the most significant change is that scammers can create a more realistic scam with lower costs while targeting many people simultaneously. AI can help generate natural dialogues and fake identity materials, as well as imitate familiar voices and produce videos. My earlier experience is an example; "project parties" and I had several prolonged voice communications. While AI cannot yet perfectly mimic tone and pitch, they can manually imitate the voices of real people. My "project party" found someone with a similar accent from public YouTube interviews to engage in discussions, and content and replies could be generated using AI. I believe these scam teams' combination of AI and human efforts can significantly elevate their deceptive capabilities. When the other party confidently discusses various professional matters in a tone you are familiar with, the situation does not look promising. Especially in the future, as AI capabilities continue to enhance, it will become increasingly difficult for individuals to defend themselves without systematic multi-faceted verification. For exchanges and platforms, it’s a case of overlooking many details.

Therefore, ordinary users cannot rely solely on spotting flaws to protect themselves. My advice is to establish fixed verification steps for transactions, receipt addresses, and sensitive information, especially paying attention to independently verifying identities.

The most crucial aspect of countering AI fraud is requiring key operations to undergo verification. The more the other party emphasizes "prompt handling" or "missing out will be too late," the more one should pause.

Fugui: I check public business emails weekly and generally receive several phishing emails, making it hard to guard against. In my view, AI has not changed the underlying logic of social engineering attacks; phishing, impersonating identities, information collection, and exploiting trust relationships are well-established attack methods. However, AI has significantly reduced the cost of attacks and increased efficiency, enabling widespread attacks. In the past, attackers needed to collect information and customize dialogues manually; now, many aspects can be automated. AI has not created new attack models; it has simply made traditional scams more precise, cheaper, and harder to distinguish.

This year, I encountered a typical case: a colleague in a project received an email in the public business inbox, claiming to be from a small venture capital firm interested in our公益Demo project and offering funding assistance. This project itself had no investment credibility; I verified the VC’s official website, social accounts, investment cases, and activity levels—multiple inconsistencies made me judge it to have very low credibility. Out of politeness, we kept the communication brief; however, the other party repeatedly proposed online meetings and created communication groups, specifically naming project leaders and core individuals to join. This raised my suspicion, indicating serious information leaks. After joining the group, they sent a link under the pretense of process verification, whereupon clicking, it demanded downloading identity verification scripts. I tested it using an isolated virtual machine equipped with monitoring and confirmed it was a rebound trojan, later uploading the sample to Virustotal.

To ordinary users, the response principle would be: Do not trust links, channels, or scripts sent by others; do not rush to act under their pressure; all information should be cross-verified. To protect privacy, users can prepare dummy accounts and bury fabricated information marked for tracking leakage sources. Verification of information must go through independently trustworthy channels for second confirmation; open unfamiliar links or QR codes in isolated environments; and any demands for downloading scripts or installing unfamiliar software should immediately be deemed high-risk.

Biteye researcher Jason: Phishing will shift from "broadcasting" to "precise customization," increasing the potential for confusion. Funds may concentrate towards leading platforms but some may choose to exit directly. I advise ordinary users to reorganize their wallets, grouping scattered small wallets into categories such as cold wallets, exchanges, hot wallets, and new wallets. Prioritize using the category with the lowest risk for decision-making; for transfer and signing requests, first verify through another channel, and feel free to consult AI.

BlockSec: AI changes in social engineering primarily make it cheaper, more realistic, and capable of targeting individuals. Past phishing attempts were broadly cast and roughly executed; those with even a bit of experience could easily recognize them as fake. Now, attackers can use your public identity and social information to craft tailored dialogues and forge voices and videos, impersonating customer service, colleagues, project parties, or even known individuals—making the line between real and fake significantly blurrier.

For ordinary users, my advice is not overly complicated, but the key is to make it a habit. Any information that carries the words "urgent," and requires you to sign, transfer, or provide mnemonic phrases, should be treated as suspicious by default; confirm it through a known official channel through a method such as returning a call, not by clicking links provided by others. Never input or screenshot mnemonic phrases and private keys. Keep large assets as much as possible in independent wallets and separate addresses, distinct from regularly used hot wallets. Before signing, ensure you clearly understand the content, and regularly revoke old authorizations.

Moreover, it is crucial to mentally accept that voices and videos could also be forged. The past practice of believing familiar voices is no longer safe today.

Bitget Wallet COO Alvin Kan: The change brought by AI makes scams appear more credible and easier to produce in bulk. In the past, we could identify scammers through grammatical errors and awkward dialogues, but now they can generate fluent communication content, even forging voices and videos. Generative AI is scaling and increasing the credibility of financial fraud. In the crypto industry, scenarios invented around conference invitations, project collaborations, wallet upgrades, or asset abnormalities may prove to be even more misleading than simple lottery scams.

I suggest ordinary users establish fixed verification processes. For transfers, authorizations, software installations, or sharing sensitive information, confirm with the contact information you have saved; for platform account issues, open the official app or a saved website link and do not follow links provided by others. Even if the other party’s identity is legitimate, sensitive operations should always maintain limits, require reviews, and allow for waiting times.

Ai Ayi: The truth is it is hard to avoid, especially in situations where "time is of the essence," such as rushing to claim an airdrop, clicking a fake link to sell, or choosing unlimited authorization to shorten meme trading times. There are losses incurred—this belongs to the category of "understanding the principles but still not being able to avoid problems."

5. In the past, many assumed that the security guarantees from top platforms would be more reliable, but this series of events has changed many people’s perceptions. As a user, what visible security measures would you expect from custodial platforms, and what asset management and daily risk control advice would you give to ordinary participants?

Beosin: For custodial or other centralized platforms, it is necessary to adequately manage the four aspects of platform, wallet, personnel, and processes. Ensure that multi-signature platforms are deployed on internal or secure networks, wallet private keys are held in HSMs, signing personnel undergo security training to recognize suspicious transactions and verify signature information, and clear operational processes for cold and hot wallets are established. For large or abnormal transactions, platforms should implement delayed approvals and maintain comprehensive audit records, conduct regular vulnerability scans and security drills, utilizing AI to help build a dynamic and efficient security defense system.

Practical advice for ordinary participants is not to consolidate all assets under a single trust assumption. In daily interactions, users should hold a small amount of readily usable assets in their hot wallets (mobile or browser plugins) to facilitate participation in on-chain interactions. For assets intended for long-term holding, consider opting for self-custody or custodial services, using hardware wallets or leading custodial platforms purchased through official channels. Regardless of the choice, the core principle is whether it can achieve risk diversification and isolation.

Mankun Blockchain Legal Services: I hope platforms can articulate security in more specific terms. For instance, identifying which independent verifications are conducted for large withdrawals, whether abnormal transactions can be intercepted in time, how employee permissions are limited, and how quickly users are notified of incidents—these should all be clearly arranged.

From a legal perspective, I particularly hope the platform clarifies how customer assets are safeguarded, whether they could be lent out or used for other business purposes, and delineates the boundaries of liability. For ordinary users already holding crypto assets, I recommend managing them based on their usage rather than seeking a single place where they can drop everything and never revisit it. However, I would not generally advise everyone to immediately switch to full self-custody. If choosing self-custody, it requires serious attention to hardware sourcing, mnemonic phrase backup, and signature verification; if choosing custodial, one must carefully review the platform and its responsibility arrangements. Which method is more suitable depends on whether the user can genuinely manage it.

Additionally, we must understand that with the development of AI technology, more unpredictable risks will emerge; hence my core suggestion is to control the potential losses from a single error within an affordable range. Even if a certain platform or operation encounters issues, try to avoid having all assets affected together.

Fugui: I never presume that the top brands or large-scale platforms equate to safety; many projects in the industry reveal numerous hidden dangers upon closer inspection.

For custodial platforms, first, clarify safety responsibility boundaries, assigning accountability to specific positions and individuals, creating mechanisms that are traceable and accountable; it may even be effective to deeply link the personal assets, professional reputation, and safety responsibilities of platform managers. Frankly speaking, as a practitioner and developer, I have concerns regarding this mechanism: technological innovations inherently carry uncertainty; if the accountability mechanism is overly burdensome, it may lead practitioners to avoid risks instead of actively identifying and solving problems. We have also been working to clarify rights and responsibilities through institutional efforts to avoid infinite accountability. However, the reality is that once one initiates or participates in a project, it is already deeply tied to the project’s long-term operations and potential risks. What we can do is maintain respect for technology, restraint regarding permissions, and awareness concerning responsibilities.

Second, implement transparency in security. Platforms should regularly disclose third-party security audit reports covering smart contracts, infrastructure, business processes, and internal permission management modules; simultaneously, they should routinely publish proof of reserves (PoR) so that users can verify the status of platform assets on their own, rather than relying solely on brand endorsement. From a technical perspective, prioritize shrinking the attack surface: streamline external service layers, reduce unnecessary interfaces and open permissions; construct independent安全testing environments, deploy honeypots, and monitor anomalous behavior, continuously carry out penetration tests; launch transparent and long-lasting bug bounty programs to involve external security researchers and build a proactive risk discovery security ecosystem.

Finally, enhance the risk compensation mechanisms. Platforms should not transfer all security risks to users; introducing third-party insurance, platform security funds, and other multi-layered protections is necessary, with clear disclosures on compensation coverage, terms, and fund pool status, allowing users to understand the asset limits guaranteed after security incidents, instead of just seeing verbal commitments.

Advice for ordinary users: custodial platforms are merely a means of custody, not a safe box for assets. Do not concentrate all your assets in one or a few platforms; do not relinquish asset control for interest or convenience; ensure asset diversification. For assets held long-term, they should ideally be placed in multi-signature wallets where you control the private keys; plan to regularly transfer assets and change independently derived private keys, avoiding using the same mnemonic phrases across platforms. Daily trading addresses should retain only small amounts of turnover funds; regularly clear and inspect authorizations, and adhere to the principle that one address corresponds to one set of service authorizations. The most critical risk control understanding: Do not blindly trust the platform's size; do not entrust asset security solely to a single institution.

Biteye researcher Jason: After every major incident, platforms are pushed to catch up, for example, all exchanges introduced proof of reserves after FTX. This time, the response from top platforms has been relatively timely, ensuring funding security; currently, it appears not to have triggered significant panic. After the events, I hope to observe for a period of time, then leverage this to promote regular audits of proof of reserves, transparency of protection fund rules, and ensure security functions such as withdrawal whitelists are enabled by default. My advice for ordinary users remains: practice asset classification management, regularly clear authorizations, and avoid unfamiliar links.

BlockSec: This round of incidents has truly shattered the default assumption that size and reputation equate to safety. The ones that faced issues were precisely the largest exchange globally and the oldest multi-signature solution. The reasoning is not difficult to understand; the larger the platform and the more funds are concentrated, the higher the potential returns for attackers, no matter how strong a team is, the probability of being breached can never be reduced to zero. Therefore, over the years, when assessing a custodial platform, my focus has long shifted from its promise of "I won't be breached" to how it performs on its worst day: how quickly it can detect incidents, whether it can freeze and halt losses right away, how effectively it can compensate users afterward, and whether the entire process is transparent.

Specifically, I prioritize several visible measures. First, real-time on-chain monitoring and quick freezing and response capabilities must be in place, able to handle anomalies within minutes rather than waiting until assets are lost to issue announcements. Second, operational discipline is crucial; the issues Binance faced this time had more to do with procedural failures than cryptography—one engineer's device and a flawed signature process, so the seemingly insignificant areas like privileged accounts, key management, third-party dependencies, and supply chain risks can reveal a platform's true foundations. Third, asset and reserve transparency is essential; proof of funds is just the starting point. Ideally, it should be independently and real-time verifiable, not merely relying on periodic reports generated by the platform.

For ordinary participants, my suggestions can be boiled down to a single concept. First, do not regard "self-custody" as an inherently safer option; self-custody merely shifts the risks of key management, signing, and phishing from the platform onto yourself. The majority of people may not manage this better than a reliable platform; the key is to match the custodial method with your own capabilities. Second, whether custodial or self-custody, always implement layering and diversification: For large and long-term assets, store them in cold wallets or more trustworthy custodians; use small hot wallets for daily operations, keeping the two entirely separate, paired with regular authorizations revocation, clear understanding before signing, and maxing out identity verification.

Bitget Wallet COO Alvin Kan: We are advancing on two levels: first, ensuring the security of the product and the business system itself; second, enhancing risk protection for users during each operation.

At the system level, we emphasize "completeness of security logic." The business processes involving assets need to use layered protection, permission restrictions, and environmental isolation to prevent any single point of failure from affecting the whole system. Third-party services should also be incorporated into this management strategy, limiting their permissions and access to user information, while continuously evaluating risks.

AI is also a direction we are investing in. We are pushing for AI code scanning prior to launches and exploring involving AI agents in attack recognition and emergency response. Here, we must simultaneously address permission issues: which actions can be executed automatically and which must require human confirmation, as well as how to limit the impacts of misjudgments—these should be gradually verified through testing and emergency exercises.

At the level of user operations, we assist users in identifying risks through DApp monitoring, token detection, on-chain risk monitoring, and authorization management capabilities. Moving forward, we also need to refine prompts and confirm mechanisms under different risk levels according to specific scenarios, so users can be clearer about the consequences of a single signature or authorization.

Self-custody means that the final control over assets lies in the user’s hands. Wallets need to respect this by bearing the responsibility for risk detection, explanations, and alerts. What we should be doing is to ensure most security protections can occur in the background; when a user needs to make decisions, prompts should be specific and clear enough to assist in judgement.

For ordinary users, I suggest arranging assets according to their purposes: minimize interactions for assets held long-term, keep daily trading accounts to retain only the necessary funds, and use independent small accounts when trying new protocols or automated strategies. At the same time, ensure offline backups of mnemonic phrases, regularly check authorizations, and reduce the potential scope of impact from a single misoperation.

Ai Ayi: This question, honestly, I don't have an answer for myself. For asset management/trading platforms, security is only a difference in 0 or 1—being able to compensate is one aspect, but if leading platforms get breached, it affects users' underlying confidence; if no platform is secure, both decentralized wallets and centralized exchanges can potentially be attacked, then "putting money in multiple baskets" loses its significance, and users in such events are always in a disadvantaged position.

For platforms, visible measures include publicly verifiable compensation funds, providing authoritative security audit reports, and consistently reminding users to strengthen password protections—these are all practical steps. However, more importantly, it rests on the invisible parts, meaning consistently treating security as the primary goal of the product.