On-chain activity has rarely been this quiet—but hackers are as active as ever.
According to SlowMist’s Hacked Archive, even as the market has cooled and on-chain activity has slowed, hackers have remained active across Web3. Cross-chain bridges, DeFi protocols, token approvals, private key management, and phishing attacks remain among their most common targets.
Based on SlowMist’s Hacked Archive categories, Web3 security incidents have caused more than $900 million in losses since the start of 2026. Cross-chain bridge-related incidents alone have exceeded 17 cases, with losses of around $330 million. Recent examples include:
Gravity Bridge was reportedly attacked due to issues related to contract keys or signature authorization, resulting in around $5.4 million in stolen assets. Alephium TokenBridge’s Ethereum bridge was also exploited, with around $815,000 stolen in a short period and a large amount of unbacked Wrapped ALPH minted.
These incidents are different from the “wallet was drained” cases most users often hear about. In many cases, the user’s mnemonic phrase was not exposed, and the wallet never signed a malicious transaction. But if the bridge’s verification mechanism, signing permissions, or operational infrastructure is compromised, assets on the bridge may still be affected.
This is also the most overlooked part of cross-chain bridge risk.
1. Why Do Cross-Chain Bridges Keep Getting Targeted?
When users try a cross-chain bridge for the first time, they often think of it as simply moving assets from chain A to chain B.
In reality, cross-chain transfers usually do not mean assets are literally “moved” from one chain to another. Instead, a bridge mechanism locks assets, maps them, and re-mints corresponding assets. In simple terms, a bridge is not just a “channel”; it is more like an asset verification and accounting system between two chains.
This is where the problem begins.
This means that if a bridge’s signing key is leaked, attackers may be able to forge valid authorization. If there are too few guardians, or if the verification mechanism is bypassed, malicious cross-chain messages may be executed as legitimate ones. If contract permissions are poorly designed, attackers may bypass the normal process to steal locked assets, or mint wrapped assets on the destination chain without real assets backing them.
To users, it may look like just one click. Behind that click, however, are contract permissions, signing mechanisms, message verification, asset custody, off-chain services, monitoring systems, and more. If any layer fails, assets may be exposed to risk.
Put simply, cross-chain bridges are often targeted not because the need for cross-chain transfers is wrong, but because bridges naturally centralize three critical risk vectors.
First, cross-chain bridges often hold large amounts of locked assets. Many bridged assets are backed by real assets locked on the source chain. If a bridge contract holds large amounts of USDC, USDT, ETH, or other highly liquid assets, it naturally becomes a key target for attackers.
Second, cross-chain bridges must solve the question of “what happened on another chain.” Since one blockchain cannot natively read the state of another, bridges must rely on verification mechanisms such as validator signatures or relay systems. The more complex these mechanisms are, the larger the attack surface becomes.
Third, ordinary users have little way to judge the real security status of a bridge. A bridge page being accessible does not mean the bridge is safe. Whether the signers are secure, whether contract permissions are properly designed, and whether backend services have been compromised are not things users can easily tell from the frontend interface.
The recent Kelp DAO security incident once again brought this issue into focus. Public postmortems show that such incidents do not necessarily come from vulnerabilities in smart contract code itself. They may also come from cross-chain verification settings, off-chain infrastructure, or operational security.
In other words, much of the so-called “interoperability” between today’s L1s, L2s, and multi-chain applications still depends on trusted relay, verification, and signing mechanisms. If these mechanisms are misconfigured or compromised, they may become the weakest link in the entire system.
This is why cross-chain security cannot rely only on users “being more careful,” nor can it rely only on a protocol “having been audited once.” It requires wallets, protocols, security teams, cross-chain infrastructure providers, and users to build a more complete system for risk identification and protection together.
2. Cross-Chain Bridges Can Be Used, but They Require Extra Judgment
Objectively speaking, this does not mean cross-chain bridges cannot be used.
The multi-chain ecosystem is already a reality in Web3. Users need to move assets across networks, use applications, participate in DeFi, and manage positions. Cross-chain bridges remain important infrastructure. The takeaway is not to avoid bridging altogether, but to stop treating cross-chain interactions like ordinary, single-chain transfers.
Before using a bridge, users should take a few extra steps.
First, make sure the bridge link comes from an official source. Avoid entering bridge pages through community private messages, search ads, unfamiliar tutorials, or comment-section links. This is especially important right after a security incident, when attackers often create phishing sites under names like “asset migration” or “emergency recovery” to trick users into connecting wallets, approving assets, or entering mnemonic phrases.
Second, check whether the project team has published any security alert or incident notice. If a bridge has just been attacked, do not rush to continue bridging assets, and do not blindly trade related wrapped assets. Based on past incidents, risks are often not fully cleared immediately after an attack. Attackers may still hold unbacked assets, or continue using market liquidity to extract real assets.
Third, test with a small amount first. Do not bridge a large amount all at once, especially when using an unfamiliar bridge, an unfamiliar chain, or a newly launched bridge. Start with a small amount to confirm the route, arrival time, and whether the asset on the destination chain is correct. A small test cannot eliminate all risks, but it can reduce large losses caused by wrong routes, fake entry points, or asset identification issues.
Fourth, avoid unlimited approvals whenever possible. Many cross-chain operations require users to approve tokens to a contract first. If you only want to bridge 100 USDT, try not to grant a long-term approval far above the amount you actually need. The larger the allowance, the greater the potential future exposure. Approvals for DApps that are no longer used, come from unclear sources, or whose security status may have changed should be checked and revoked regularly.
Fifth, read signature and transaction details carefully. Do not keep clicking “Confirm” just because you are in a hurry. If you see an unfamiliar website, an unexpected contract address, strange signature content, or a permission request that does not match what you intended to do, stop immediately.
Even after a bridge transfer is completed, the security check should not end right away. Many users may think the operation is over once the assets arrive. But from a security perspective, post-bridge checks are just as important.
After completing a bridge transfer, use block explorers to check the transaction status on both the source chain and the destination chain. Confirm that the assets were actually transferred instead of relying only on what the frontend page shows.
Also confirm that the asset received on the destination chain was issued by an official or trusted contract. Do not casually trade unknown tokens with the same name, and do not click related websites or claim pages just because a new asset suddenly appears in your wallet.
Finally, regularly check and revoke approvals that are no longer needed. Many approvals do not expire automatically. If you granted a high allowance to a cross-chain bridge, DApp, or contract in the past, that permission may continue to expose you to risk even if you no longer use it.
Ultimately, security is not limited to the moment you store your mnemonic phrase. It runs through the entire process of connecting to DApps, approving tokens, signing transactions, bridging assets, and cleaning up permissions afterward.
3. The More Hidden Risk: The Human Element
Cross-chain bridge incidents remind us that on-chain infrastructure itself may carry risks. But for ordinary users, another more common and harder-to-spot risk comes from social engineering attacks.
A social engineering attack does not necessarily rely on complex code vulnerabilities. At its core, it exploits people’s habits, trust, anxiety, and information gaps to get users to carry out risky actions themselves.
Over the past two years, phishing, private key theft, malicious approvals, and address spoofing targeting users have become frequent sources of Web3 asset losses. This shows that hackers are not always focused on breaking smart contracts themselves. Increasingly, they are turning to user behavior and off-chain systems.
Common social engineering attacks often revolve around one thing: deception.
For example, attackers may use dusting attacks, airdropped NFTs, fake points-claim pages, or fake campaign websites to trick users into clicking and granting approvals. Users may think they are only claiming a reward, when in fact they are giving a malicious contract permission to transfer their assets. Those assets may then be stolen later.
Attackers may also use Trojan malware, clipboard monitoring, malicious browser extensions, or disguised input pages to steal mnemonic phrases and transaction details. For users, the most dangerous part is that these attacks often do not happen on-chain. They happen on everyday devices and through everyday habits.
What makes these risks especially dangerous is that they do not attack code. They attack habits.
Many users do not fall victim because they lack all security awareness. They fall victim because the process has become too familiar: they click “Confirm” when they see it, copy a previous address when they need one, claim an airdrop when it appears, and follow instructions when “customer support” reaches out. Attackers use this sense of familiarity to hide risk inside the most routine operation paths.
Therefore, when performing on-chain actions, especially when using DeFi, cross-chain bridges, trading tools, or new project pages, approval management and transaction confirmation must become basic habits. Do not grant long-term, high-value approvals to unfamiliar DApps. Do not enter your mnemonic phrase on unfamiliar websites. Do not trust “customer support” in private messages. Do not copy addresses directly from history without checking them. Do not ignore risk warnings shown by your wallet.
Final Thoughts
Even in a market as quiet as this one, we still need to say this: cross-chain bridges can still be used, DeFi is not off-limits, and new chains and applications are not something users must avoid altogether.
What we need to understand is that the more varied on-chain activity becomes, the more complex the risk structure becomes.
In the past, when we talked about wallet security, the key reminder was often: “Do not leak your mnemonic phrase.” This is still absolutely correct. But in today’s real-world environment, it is no longer enough.
Today’s security issues have expanded beyond “who controls your private key” into many more dimensions. Security is not only about keeping your mnemonic phrase safe. It also includes what you do when connecting to DApps, approving contracts, signing transactions, bridging assets, and cleaning up historical approvals.
For ordinary users, the simplest security principle can be summarized in one sentence:
Never confirm what you do not understand. Never approve what you are not sure about. Never transfer before you verify.