When security risks expand from a single point into a chain, users' defenses must also upgrade from just protecting their private keys to a comprehensive set of habits.

Written by: imToken

In June, the crypto world experienced a series of security incidents spanning multiple phases.

PeckShield's latest monthly security report shows that there were 40 major hacking incidents in June, with total losses reaching up to $75.87 million. More concerning is that these attacks were not concentrated on a single attack vector, instead, they covered wallet signature implementation flaws, L2 protocol vulnerabilities, and third-party service supply chain attacks, with multiple defenses failing in the same month.

As Web3 security risks expand from a single entry point to the entire chain of interaction paths, every user must reconsider a crucial question: Are my Crypto assets still safe?

1. The Importance of Wallet Signature Implementation Beyond Private Keys

The security incident in June involving SecondFi, a wallet in the Cardano ecosystem, is the most direct example.

SecondFi is the successor to the Cardano ecosystem wallet Yoroi. From June 21 to 23, attackers transferred approximately 16 million ADA from some SecondFi user addresses, involving around 374 wallets, resulting in a loss of about $2.4 million based on the market price at the time. SecondFi later stated that it had taken emergency measures to additionally protect around 129 million potentially affected ADA.

The most unique aspect of this incident is that affected users did not actively give their recovery phrases to the attackers; the issue lay in the underlying signature implementation of the wallet, where a faulty derivation of the signature nonce from public trading messages omitted the secret nonce prefix required by the standard implementation, according to analysis by security agency BlockSec.

This meant that every time a user signed a transaction using the affected version of the wallet, the publicly posted signature data on the chain would expose enough information to derive the private key of the wallet address, so attackers did not need to breach the user's phone or obtain the recovery phrase; they only needed to analyze publicly available on-chain data to potentially recover the corresponding address's signing private key.

From a user's perspective, the wallet was still operating normally, as no recovery phrase pop-ups occurred, passwords had not been compromised, and transactions were indeed initiated by the user. However, from a cryptographic perspective, as long as the user's address had generated some valid signatures through the affected version, the public transaction and signature data could help attackers deduce the signing private key for that address.

Ultimately, wallet security hinges on whether private keys are generated correctly, whether signatures are completed strictly following cryptographic standards, and whether those core codes can be externally audited and verified, which underscores the importance of keeping core wallet components open source.

Of course, this is a specific implementation flaw of a specific wallet version, not a universal issue for all self-custody wallets. Taking imToken’s TokenCore as an example, its core code repository is openly hosted on GitHub and covers the underlying wallet functionalities such as key management, address derivation, and transaction signatures.

While open-source does not guarantee that the code is free from vulnerabilities, nor does it mean users can completely relinquish vigilance, at least for the most sensitive cryptographic and signature components within wallets, open source provides an important premise: security researchers, developers, and the community can inspect the code, reproduce issues, and perform ongoing testing, rather than blindly trusting an unverifiable black box.

For ordinary users, such incidents correspond to several more practical security principles.

• First, wallets should always be downloaded from official websites or official app stores, and kept updated with the latest security versions;
• Second, it is advisable not to place all assets in the same everyday interaction wallet; significant long-term assets should be stored using hardware wallets or independent cold wallets, isolated from the hot wallet that frequently connects to DApps;
• More importantly, once wallet officials confirm vulnerabilities in key generation or signature implementation, simply importing the original recovery phrase into another wallet usually does not solve the problem;

Because importing the same recovery phrase into other wallets will not change the addresses and private keys that have already been exposed. Affected assets need to be transferred to a new address that has never signed through the vulnerable version. For ordinary users, a more prudent approach is usually to recreate a new wallet and recovery phrase according to official emergency procedures before moving assets, instead of repeatedly importing or operating the original address.

2. L2 is not just "a cheaper Ethereum," but an entire complex trust chain

In addition to wallets, multiple incidents in June pointed to increasingly complex L2 systems as a risk.

On June 14 and 18, two legacy Rollup deployments related to Aztec were attacked, resulting in a combined loss of approximately $4.35 million.

It should be clarified that the targets of the attack were legacy deployments such as Aztec Connect, which had already entered a legacy state, and do not equate to an attack on the current Aztec Network mainnet. However, the problems exposed by both incidents have significant warning implications for the entire ZK Rollup domain.

In one of the incidents, the attacker exploited inconsistencies between the number of transactions and the actual processed data, allowing the system to claim a deposit while bypassing the corresponding balance deduction process on L1.

The other incident was due to a missing constraint within the zero-knowledge proof circuit, where the system verified a formally valid proof but failed to ensure that the private state tree used in that proof matched the public state root used for settlement on Ethereum. Consequently, the attacker was able to generate a proof around a fabricated state tree and extract assets from the L1 contract.

Such issues are difficult to summarize with the conventional "does the contract contain a line of vulnerable code" perspective. After all, zero-knowledge proofs can attest that a certain computation process conforms to established rules; however, this presumes that the rules themselves are correct and complete. If a developer forgets to constrain a key variable, the proof might mathematically hold, yet affirm an outcome inconsistent with the true settlement state.

The security incident that later occurred with Taiko exposed another type of L2 trust chain risk.

On June 22, Taiko's SGX-based proof verification process was exploited, resulting in a loss of approximately $1.7 million. According to BlockSec's analysis, the attackers used a signature private key from an SGX enclave that had been submitted to a public GitHub repository, while also utilizing the flaw in the on-chain verification contract that failed to reject DEBUG mode Enclaves, allowing them to register a malicious prover as a legitimate instance.

The attackers subsequently forged L2 state proofs, causing the Ethereum contract to accept a non-existent L2 state, ultimately extracting assets from bridge funds. In essence, this happened because the keys used to sign trusted execution environments were made public, and remote authentication rules did not fully check the environment attributes, rendering a "certified" proof devoid of its intended trustworthiness.

Simultaneously, Base experienced mainnet block production stalling on June 25 and 26. In the aftermath, Base stated that the two interruptions stemmed from a defect in the block construction logic: a failed transaction did not correctly clean up the previously recorded state, leading to incorrect Gas calculations for subsequent transactions and blocks containing invalid state transitions. When other nodes could not accept that block, the network eventually stopped progressing. Base indicated that the chain's integrity was not compromised during the incident, and user funds remained secure.

This was not an act of asset theft or external attack but rather a technical failure affecting network availability and recovery capabilities. However, from a broader security perspective, availability itself is also a part of the L2 security model.

For users, whether a chain is secure depends not only on whether hackers can forge assets, but also on whether blocks can be continuously produced, cross-chain bridges can operate normally, nodes can recover quickly, and whether users still have viable exit paths when the system encounters failures.

Thus, when using L2, users should not only compare transaction fees and airdrop expectations. For smaller-scale, newly launched, or rapidly changing security mechanisms in L2, it is advisable to avoid storing large sums of assets exceeding actual usage needs; confirm the use of the official bridge before cross-chain interactions, and understand withdrawal times, pause mechanisms, and emergency exit methods; when the network halts block production, cross-chain anomalies arise, or officials issue security alerts, refrain from repeatedly submitting transactions or continuing to bridge assets.

A more prudent approach is to diversify the management of assets of varying purposes and risk levels, rather than placing all liquidity on the same L2, same cross-chain bridge, or same exit mechanism.

3. Contracts may not be breached, but third-party services can also bring attacks to users

If issues with wallets and L2 still arise within relatively low-level technical components, then the incident involving Polymarket illustrates that even the web front-end closest to users can also serve as an entry point for funds.

On June 25, Polymarket reported that one of its third-party providers had been compromised, allowing attackers to inject malicious scripts into the Polymarket front-end accessed by certain users.

According to statistics from security agencies and on-chain analysts, this incident resulted in approximately $3 million in user asset losses, affecting around 11 wallets. Stolen funds were subsequently bridged from Polygon to Ethereum and converted into about 1,893 ETH; however, Polymarket later stated that it had removed the affected dependencies and would issue full refunds to the impacted users.

The key aspect of this incident is that users were still accessing the correct Polymarket domain, and current disclosures did not point to vulnerabilities in Polymarket’s core smart contract; the issue mainly lay in the third-party front-end dependencies loaded on the webpage.

This serves as a mirror; today, most Web3 applications do not run entirely on-chain. The webpages users see, like trading interfaces, still heavily rely on traditional internet infrastructure and third-party software packages. Any compromise of one of these dependencies could cause a legitimate website to display incorrect information, replace receiving addresses, or induce wallets to sign malicious transactions.

Therefore, "the URL is real" does not necessarily mean "all loaded code at this moment is safe," and "the contract has passed auditing" does not equate to having no risks across the entire interaction path between the user and the contract. In the face of such front-end and supply chain attacks, ordinary users find it challenging to independently check every piece of code loaded on the webpage, but they can still limit potential losses by reducing single interaction permissions:

• Use independent DApp interaction wallets: Avoid connecting long-term savings wallets directly to various DeFi, NFT, prediction market, and airdrop websites. Daily interaction wallets should only store funds intended for immediate use, so in case of front-end or authorization issues, the impact remains relatively limited;
• Focus on actual operations before signing, rather than just looking at webpage buttons: Just because the webpage says "login," "claim," or "confirm order" does not mean the signature prompt in the wallet corresponds to the same action;
• When abnormalities occur on the webpage, do not rely on inertia to continue operations: If the page suddenly requests re-importing the recovery phrase, downloading additional plugins, or shows transaction content inconsistent with the webpage description, pause interactions, confirm the situation through multiple official channels of the project, and check or revoke outdated authorizations;

From the perspective of wallet products, this also means that the role of wallets is changing.

They should not just be a tool for storing private keys and popping up signature windows; they need to help users understand transaction intent, recognize abnormal authorizations, display asset changes, and provide sufficiently clear warnings prior to high-risk interactions.

Nevertheless, wallets cannot eliminate all risks for users. A more realistic security model involves wallets, protocols, L2, third-party service providers, and users collectively reducing the attack surface, rather than pushing all responsibility onto any one party.

Final Thoughts

In the past, people often said, whoever holds the private key controls the on-chain assets.

This statement still holds true, but it does not encompass the entire process of a user’s assets from "generating transaction intent" to "completing on-chain settlement." Today's Web3 security is not just about protecting a set of recovery phrases, but about safeguarding the entire path from wallet key generation, transaction display, execution of signatures, to network verification and final settlement.

Of course, this does not mean that users need to stay away from all on-chain interactions. For users, genuinely effective security habits imply managing asset purposes, risk levels, and interaction scenarios separately: long-term assets well-isolated, small amounts for daily interactions, low authorizations for unfamiliar DApps, and multiple verifications for high-risk operations.

After all, when security risks expand from a single point to a chain, users' defenses must also transition from merely securing private keys to adopting a complete set of habits.

Let’s encourage each other.