The crypto world experienced a series of security incidents spanning multiple areas in the month of June that just passed.
According to the latest monthly security report released by PeckShield, there were 40 significant hacking incidents in June, resulting in total losses of approximately $75.87 million. More alarmingly, these attacks were not concentrated on a single type of attack vector. Instead, they covered vulnerabilities across wallet signature implementation flaws, L2 protocol weaknesses, and third-party service supply chain attacks, with multiple lines of defense being breached within the same month.
As Web3 security risks expand from single entry points to the entire on-chain interaction path, every user is compelled to reconsider a question: Are my crypto assets still secure?
I. Beyond Private Keys: The Importance of Wallet Underlying Signature Implementation
The security incident that occurred on the Cardano ecosystem wallet SecondFi in June serves as the most direct example.
SecondFi is the successor to the Cardano ecosystem wallet Yoroi. Between June 21st and 23rd, attackers transferred approximately 16 million ADA from some SecondFi user addresses, involving about 374 wallets, valued at around $2.4 million at the time of the incident. SecondFi subsequently stated that emergency measures protected an additional approximately 129 million ADA potentially at risk.
The most unique aspect of this incident is that affected users did not actively hand over their seed phrases to the attackers. The problem lay in the wallet's underlying signature implementation. According to analysis by the security firm BlockSec, it incorrectly derived the signature nonce from the public transaction message, omitting the secret nonce prefix required by the standard implementation.
This meant that whenever users signed transactions using an affected version of the wallet, the public signature data posted to the chain would expose information sufficient to deduce the private key of the address. Therefore, attackers did not need to hack the user's phone or obtain the seed phrase; they only needed to analyze the public on-chain data to potentially recover the signing private key corresponding to the address.
From the user's perspective, the wallet was still functioning normally—after all, no pop-up leaked the seed phrase, passwords weren't cracked, and transactions were indeed initiated by the user. However, from a cryptographic standpoint, as long as the user's address had generated some valid signatures through the affected version, the public transaction and signature data could potentially help attackers deduce the address's signing private key.
Ultimately, wallet security also depends on whether private keys are generated correctly, whether signatures are performed strictly according to cryptographic standards, and whether these critical codes can be externally audited and verified. This is also the importance of keeping core wallet components open-source.
Of course, this is an implementation flaw specific to a particular wallet version, not a universal issue with all self-custody wallets. Taking imToken's TokenCore as an example, its core code repository is publicly hosted on GitHub, covering underlying wallet functions such as key management, address derivation, and transaction signing.
While open-source does not necessarily mean the code is entirely free of vulnerabilities, nor does it mean users can completely abandon vigilance, for the most sensitive cryptographic and signature components within a wallet, open-source at least provides an important premise: security researchers, developers, and the community can inspect the code, reproduce issues, and conduct continuous testing, rather than having to trust an unverifiable black box.
For ordinary users, this type of incident also corresponds to a few more practical security principles.
- First, wallets should always be downloaded through official websites or official app stores, and security updates should be applied promptly.
- Second, it's not advisable to keep all assets in the same wallet used for daily interactions. Large, long-term assets can be stored using hardware wallets or separate cold wallets, isolated from hot wallets frequently connected to DApps.
- More importantly, once a wallet officially confirms a vulnerability at the key generation or signature implementation level, simply importing the same seed phrase into another wallet typically does not solve the problem;
Because after importing the same set of seed words into another wallet, the addresses and private keys that were already exposed will not change. Affected assets need to be transferred to a new address that has never signed through the vulnerable version. For ordinary users, a more reliable approach is usually to follow the official emergency procedure to create an entirely new wallet and seed phrase, and then complete the asset migration, rather than repeatedly importing or manipulating the original address themselves.
II. L2 is Not Just "Cheaper Ethereum," It's Also a Complex Chain of Trust
Beyond wallets, multiple incidents in June also point risks towards increasingly complex L2 systems.
On June 14th and 18th, two legacy Rollup deployments related to Aztec were successively attacked, resulting in combined losses of approximately $4.35 million.
It is important to note that the attacks targeted legacy deployments of Aztec Connect that were already in a deprecated state; this is not equivalent to the current Aztec Network mainnet itself being attacked. However, the issues exposed by both incidents are highly instructive for the entire ZK Rollup field.
In one incident, the attacker exploited an inconsistency between the number of transactions and the actual processed data, causing the system to record a deposit internally within the proof while bypassing the corresponding balance deduction process on L1.
The other incident stemmed from a missing constraint in the zero-knowledge proof circuit. The system validated a proof that was formally valid but did not ensure that the private state tree used by the proof was completely consistent with the public state root on Ethereum used for actual settlement. The attacker could therefore generate proofs around a forged state tree and extract assets from the L1 contract.
Such problems are difficult to summarize with the traditional notion of "whether there is a specific line of vulnerable code in the contract." After all, zero-knowledge proofs can prove that a certain computation process conforms to established rules, but the premise is that the rules themselves are correct and complete. If developers forget to constrain a critical variable, the proof may still be mathematically valid but prove a result inconsistent with the actual settlement state.
The subsequent security incident involving Taiko exposed another type of L2 trust chain risk.
On June 22nd, Taiko's SGX-based proof verification process was exploited, causing losses of approximately $1.7 million. According to BlockSec's analysis, the attacker used an SGX enclave signing private key that had once been committed to a public GitHub repository, while also exploiting a flaw in the on-chain verification contract that did not reject DEBUG mode Enclaves, registering a malicious prover as a legitimate instance.
The attacker then forged L2 state proofs, causing the contract on Ethereum to accept a non-existent L2 state, ultimately extracting assets from the bridge funds. In essence, this happened because the key used to sign the trusted execution environment was made public, and the remote attestation rules did not fully check the runtime environment attributes, ultimately causing a proof that was "attested" to lose its originally intended meaning of trustworthiness.
Meanwhile, Base experienced consecutive halts in mainnet block production on June 25th and 26th. Base stated in a post-mortem analysis that both interruptions stemmed from the same block construction logic flaw: a failed transaction did not correctly clean up previously recorded state, causing subsequent transactions to have Gas incorrectly calculated and leading to the generation of a block containing invalid state transitions. As other nodes could not accept this block, the network ultimately stopped progressing. Base stated that chain integrity was not compromised during the incident, and user funds remained safe.
This was not an asset theft or external attack but a technical failure affecting network availability and recovery capability. However, from a broader security perspective, availability itself is part of the L2 security model.
Because for users, whether a chain is secure depends not only on whether hackers can forge assets, but also on whether blocks can be produced continuously, cross-chain bridges can function normally, nodes can recover quickly, and whether users still have a feasible exit path when the system fails.
Therefore, when using L2, users should not only compare fees and airdrop expectations. For L2s that are smaller, newly launched, or whose security mechanisms are still rapidly evolving, try to avoid storing large amounts of assets beyond actual usage needs for extended periods. Before bridging, confirm the use of the official bridge and understand withdrawal times, pause mechanisms, and emergency exit methods. If encountering network halts, bridging abnormalities, or official security warnings, do not repeatedly submit transactions or continue bridging assets.
A more prudent approach is to manage assets of different purposes and risk levels separately, rather than placing all liquidity on the same L2, the same cross-chain bridge, or the same exit mechanism.
III. Even If the Contract Isn't Hacked, Third-Party Services Can Bring Attacks to Users
If the issues with wallets and L2 still occur within relatively low-level technical components, then the Polymarket incident illustrates that the web frontend, closest to the user, can also become a fund entry point.
On June 25th, Polymarket stated that a third-party vendor they used was compromised. Attackers used this to inject malicious scripts into the Polymarket frontend accessed by some users.
According to statistics from security agencies and on-chain analysts, the incident resulted in approximately $3 million in user asset losses, involving about 11 wallets. The stolen funds were subsequently bridged from Polygon to Ethereum and exchanged for approximately 1,893 ETH. However, Polymarket later stated that it had removed the affected dependency and would fully reimburse affected users.
The key to this incident is that users might still be visiting the correct Polymarket domain name. Existing disclosures have not pointed to vulnerabilities in Polymarket's core smart contracts. The main problem lay in a third-party frontend dependency loaded by the webpage.
This also serves as a mirror. Today, most Web3 applications do not run entirely on-chain. The webpages users see, such as trading interfaces, still heavily rely on traditional internet infrastructure and third-party software packages. If any one of these dependencies is attacked, it could cause a legitimate website to display incorrect information to users, replace receiving addresses, or induce wallets to sign malicious transactions.
Therefore, "the URL is correct" does not necessarily equate to "all code loaded at this moment is secure." "The contract has been audited" also does not mean the entire interaction path between the user and the contract is risk-free. Faced with these types of frontend and supply chain attacks, ordinary users find it difficult to independently inspect every piece of code loaded by a webpage, but they can still limit potential losses by reducing single-interaction permissions:
- Use a dedicated DApp interaction wallet: Avoid directly connecting long-term savings wallets to various DeFi, NFT, prediction market, and airdrop websites. Keep only funds intended for recent use in the daily interaction wallet. Even if the frontend or authorizations have problems, the scope of impact is relatively limited.
- Pay attention to the actual operation before signing, not just the webpage button: The webpage may say "Login," "Claim," or "Confirm Order," but this does not mean the signature popping up in the wallet is for the same action.
- When anomalies appear on a webpage, do not rely on inertia to continue operations: If a page suddenly asks to re-import a seed phrase, download an additional plugin, or displays transaction content inconsistent with the webpage description, pause the interaction. Confirm the situation through the project's multiple official channels, and check or revoke historical authorizations no longer in use.
From the perspective of wallet products, this also means the role wallets undertake is changing.
It should not be just a tool for storing private keys and popping up signature windows. It also needs to help users understand transaction intent, identify abnormal authorizations, display asset changes as much as possible, and provide sufficiently clear warnings before high-risk interactions occur.
But wallets cannot eliminate all risks for users. A more realistic security model involves wallets, protocols, L2s, third-party service providers, and users working together to reduce the attack surface, rather than placing all responsibility on any single party.
Final Words
In the past, it was often said, "Whoever holds the private key holds the on-chain assets."
This statement still holds true, but it does not cover the entire process from "generating transaction intent" to "completing on-chain settlement" for user assets. Today, Web3 security is no longer just about protecting a set of seed words; it's about protecting the entire path from wallet key generation, transaction display, signature execution, to network verification and final settlement.
Of course, this does not mean users need to stay away from all on-chain interactions. For users, truly effective security habits mean separating asset purposes, risk levels, and interaction scenarios for management: long-term assets emphasize isolation, daily interactions use small amounts, unfamiliar DApps get low authorization, and high-risk operations require more verification.
After all, when security risks expand from a single point to an entire chain, a user's defense must also upgrade from simply protecting a private key to a comprehensive set of habits.
For us all to reflect upon.
