Beyond Private Keys: From Wallets and L2 to the Supply Chain – How to Safeguard Web3's ...

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

PeckShield's latest monthly security report revealed that June saw 40 major hacking incidents, with total losses reaching $75.87 million. More alarmingly, these attacks were not concentrated on a single attack vector. Instead, they targeted wallet signature implementation flaws, L2 protocol vulnerabilities, and third-party service supply chain attacks, with multiple defense lines breached within the same month.

As Web3 security risks expand from a single entry point to the entire on-chain interaction path, every user is forced to reconsider one question: Is my crypto assets still safe?

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

SecondFi, formerly known as the Cardano ecosystem wallet Yoroi. Between June 21 and 23, attackers transferred approximately 16 million ADA tokens (worth $2.4 million at the time of the incident) from some SecondFi user addresses, affecting roughly 374 wallets. SecondFi later stated that emergency measures protected an additional 129 million ADA that could have been affected.

The most unique aspect of this incident is that affected users did not actively hand over their seed phrases to the attackers. The problem stemmed from the wallet's underlying signature implementation. According to security firm BlockSec's analysis, the code erroneously derived the signature nonce from public transaction messages, omitting the secret nonce prefix required by standard implementation.

This meant that every time a user signed a transaction using the affected wallet version, the public signature data broadcast to the chain exposed information sufficient to derive the private key for that address. Therefore, attackers didn't need to compromise the user's phone or obtain the seed phrase; they only needed to analyze public on-chain data to potentially recover the signing private key for the corresponding address.

From the user's perspective, the wallet appeared to function normally. The seed phrase wasn't leaked via a pop-up, passwords weren't cracked, and the transaction was indeed initiated by the user. However, from a cryptographic standpoint, once a user address generated valid signatures using the affected version, the public transaction and signature data could potentially help attackers derive the address's signing private key.

Ultimately, wallet security hinges on whether private keys are correctly generated, whether signatures are completed strictly according to cryptographic standards, and whether these critical code components can be externally reviewed and verified. This underscores the importance of keeping core wallet components open-source.

Of course, this was an implementation flaw specific to a particular wallet version, not a universal problem for all self-custodial wallets. Take imToken's TokenCore, for example. Its core code repository is publicly hosted on GitHub, covering underlying wallet functions like key management, address derivation, and transaction signing.

While open-sourcing doesn't guarantee the code is free of vulnerabilities, nor does it mean users can let down their guard completely, for the most sensitive cryptographic and signature components in a wallet, open-sourcing provides a crucial prerequisite: security researchers, developers, and the community can inspect the code, reproduce issues, and continuously test, rather than having to trust an unverifiable black box.

For average users, this type of incident also translates into several practical security principles.

This is because importing the same set of seed phrases into another wallet does not change the already exposed addresses and their private keys. Affected assets need to be transferred to a new address that has never been signed using the vulnerable version. For average users, a safer approach is typically to follow the official emergency procedures to create a completely new set of wallets and seed phrases, then migrate assets, rather than repeatedly importing or manipulating the original addresses on their own.

Beyond wallets, multiple incidents in June also highlighted the risks inherent in increasingly complex L2 systems.

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

It's crucial to note that the attacked deployments were legacy instances like Aztec Connect, which have entered a sunset state. This does not equate to an attack on the current Aztec Network mainnet itself. However, the issues exposed by these two incidents serve as significant warnings for the entire ZK Rollup field.

In one incident, the attacker exploited an inconsistency between the transaction count and the actual processed data, allowing the system to record a deposit within the proof while bypassing the corresponding balance deduction process on L1.

The other incident originated from a constraint missing in the zero-knowledge proof circuit. The system verified a proof that was structurally valid but failed to ensure that the private state tree used in the proof perfectly matched the public state root actually used for settlement on Ethereum. This allowed the attacker to generate a proof based on a forged state tree and withdraw assets from the L1 contract.

This type of problem is difficult to summarize using the traditional concept of "finding a single line of vulnerable code in a contract." After all, zero-knowledge proofs can verify that a computation followed established rules, but only on the condition that the rules themselves are correct and complete. If a developer forgets to constrain a critical variable, the proof can still be mathematically valid, yet it proves a result inconsistent with the actual settlement state.

The subsequent security incident involving Taiko exposed a different 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 attacker used an SGX enclave signing private key that had been previously committed to a public GitHub repository. Simultaneously, they exploited a vulnerability in the on-chain verification contract that failed to reject DEBUG mode enclaves, registering a malicious prover as a legitimate instance.

The attacker then forged L2 state proofs, causing the Ethereum contract to accept a non-existent L2 state, ultimately draining assets from the bridged funds. In essence, because the key used to sign the trusted execution environment was public, and the remote attestation rules did not fully verify the execution environment's properties, a "verified" proof lost its intended meaning of trust.

Simultaneously, Base experienced a halt in mainnet block production on June 25 and 26. In its post-mortem, Base stated that both interruptions stemmed from the same block construction logic flaw: a failed transaction execution did not properly clean up previously recorded state, causing subsequent transactions to be calculated with incorrect Gas and leading to the generation of a block containing an invalid state transition. As other nodes could not accept this block, the network stopped progressing. Base confirmed that chain integrity was not compromised during the incidents and user funds remained safe at all times.

This was not an asset theft or an external attack, but a technical failure impacting network availability and recovery capability. However, from a broader security perspective, availability itself is a 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, whether cross-chain bridges function correctly, whether nodes can recover quickly, and whether users have viable exit paths when the system fails.

Therefore, when using L2s, users should not only compare fees and airdrop expectations. For smaller, newly launched L2s, or those with rapidly changing security mechanisms, try to avoid storing large assets for the long term beyond what is needed for actual use. Before bridging, confirm you are using the official bridge and understand the withdrawal time, pause mechanisms, and emergency exit methods. If you encounter network block production halts, bridge anomalies, or official security warnings, do not repeatedly submit transactions or continue bridging assets.

A safer approach is to manage assets by diversifying them across different use cases and risk levels, rather than concentrating all liquidity on a single L2, a single cross-chain bridge, or a single exit mechanism.

If the issues with wallets and L2s still reside in relatively low-level technical components, the Polymarket incident demonstrates that the web frontend, the layer closest to the user, can equally become an entry point for fund theft.

On June 25, Polymarket reported that one of its third-party providers was compromised. The attacker used this access to inject malicious scripts into the Polymarket frontend accessed by some users.

According to statistics from security firms and on-chain analysts, the incident resulted in approximately $3 million in user asset losses, affecting around 11 wallets. The stolen funds were subsequently bridged from Polygon to Ethereum and exchanged for approximately 1,893 ETH. However, Polymarket later stated that the affected dependencies had been removed and that they would provide full refunds to affected users.

The critical point of this incident is that users might still have been accessing the correct Polymarket domain. Current disclosures do not point to a vulnerability in Polymarket's core smart contracts. The problem primarily stemmed from a third-party frontend dependency loaded by the webpage.

This serves as a mirror. Today, most Web3 applications do not run entirely on-chain. The web pages users see, like trading interfaces, still heavily rely on traditional internet infrastructure and third-party software packages. If any of these dependencies is compromised, it could allow a legitimate website to display incorrect information to users, replace receiving addresses, or trick wallets into signing malicious transactions.

Therefore, a "real URL" does not necessarily equal "all the code loaded right now is safe," and a "contract audited" does not mean the entire interaction path between the user and the contract is risk-free. Faced with such frontend and supply chain attacks, average users cannot independently inspect every line of code a webpage loads. However, they can still limit potential losses by reducing the permissions granted for individual interactions:

From a wallet product perspective, this also signifies that the role of the wallet is evolving.

It should be more than just a tool for storing private keys and popping up signature windows. It also needs to help users understand the intent of a transaction, identify anomalous authorizations, display asset changes, and provide sufficiently clear warnings before high-risk interactions occur.

However, a wallet cannot eliminate all risks for users. A more realistic security model involves wallets, protocols, L2s, third-party service providers, and users collectively reducing the attack surface, rather than pushing the entire responsibility onto any single party.

In the past, it was often said: Not your keys, not your crypto.

This statement remains true, but it does not cover the entire process between a user "forming the intent to transact" and "completing on-chain settlement." Today's Web3 security is no longer just protecting a set of seed phrases. It's protecting the entire path from key generation, transaction display, and signature execution by the wallet, to network verification and final settlement on-chain.

Of course, this doesn't mean users need to avoid all on-chain interactions. For users, truly effective security habits mean managing assets separately based on purpose, risk level, and interaction scenario: Isolate long-term assets strictly, use small amounts for daily interactions, grant minimal approvals for unfamiliar DApps, and apply extra verification for high-risk operations.

Ultimately, as security risks have expanded from a single point to an entire chain, a user's defense must also evolve from simply protecting the private key to a complete set of robust habits.

Let's all keep this in mind.