Beyond Private Keys: From Wallets and L2 to Supply Chains – How to Guard the Security Boundaries of Web3?

The past June saw a wave of security incidents spanning multiple attack vectors across the crypto world.

PeckShield’s latest monthly security report shows that 40 major hacker attacks occurred in June, with total losses reaching $75.87 million. More worryingly, these attacks were not concentrated on a single attack path; instead, they covered wallet signature implementation flaws, L2 protocol vulnerabilities, and third-party service supply chain attacks. Multiple defense lines fell successively in the same month.

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

I. Beyond Private Keys: The Importance of Underlying Wallet Signature Implementation

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

SecondFi evolved from the Cardano ecosystem wallet Yoroi. From June 21 to 23, the attacker transferred approximately 16 million ADA from some SecondFi user addresses, affecting about 374 wallets. At the then-current price, this amounted to around $2.4 million. SecondFi later stated that it had additionally protected approximately 129 million ADA that might have been affected through emergency measures.

What makes this incident unique is that the affected users did not actively hand over their seed phrases to the attacker. The problem lay in the wallet’s underlying signature implementation. According to security firm BlockSec’s analysis, the implementation incorrectly derived the signature nonce from public transaction messages, omitting the secret nonce prefix required by the standard implementation.

This meant that whenever users signed transactions with the affected wallet version, the public signature data posted on-chain would expose enough information to derive the private key of that address. Therefore, the attacker did not need to break into 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 of the corresponding address.

From the user’s perspective, the wallet appeared to be running normally. After all, the seed phrase was not leaked via a pop-up, the password was not cracked, and the transactions were indeed initiated by the user. However, from a cryptographic standpoint, as long as the user’s address had generated valid signatures using the affected version, the public transaction and signature data could help the attacker derive the private key for that address.

Ultimately, wallet security depends on whether the private key is correctly generated, whether signatures are strictly completed according to cryptographic standards, and whether these critical codes can be externally reviewed and verified. This is also why it is important for core wallet components to remain open source.

Of course, this is an implementation flaw specific to a particular wallet version, not a universal issue with all self-custodial wallets. Take 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 sourcing does not mean the code is necessarily free of vulnerabilities, nor does it mean users can let their guard down completely, for the most sensitive cryptographic and signature components in a wallet, open source at least provides an important prerequisite: security researchers, developers, and the community can examine the code, reproduce issues, and continuously test it, rather than having to trust an unverifiable black box.

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

First, wallets should always be downloaded from the official website or official app store, and updated to secure versions in a timely manner.

Second, it is advisable not to put all assets in a single daily-use wallet. Large long-term holdings can be stored in hardware wallets or separate cold wallets, isolated from hot wallets that frequently connect to DApps.

More importantly, once a wallet official confirms a vulnerability at the key generation or signature implementation level, simply importing the original seed phrase into another wallet usually does not solve the problem. This is because importing the same seed phrase into another wallet does not change the previously exposed addresses and private keys. Affected assets need to be transferred to a new address that has never been signed by the vulnerable version. For ordinary users, the safer approach is usually to follow the official emergency procedure to create a completely new set of wallets and seed phrases, and then complete asset migration, rather than repeatedly importing or operating the original addresses on their own.

II. L2 Is Not Just a "Cheaper Ethereum" — It’s a Complex Chain of Trust

In addition to wallets, several incidents in June also pointed to the increasingly complex L2 systems.

On June 14 and 18, two old Rollup deployments related to Aztec were attacked, with total losses of approximately $4.35 million.

It is important to note that the attacked deployments were legacy versions like Aztec Connect, which does not mean the current Aztec Network mainnet itself was attacked. However, the issues exposed in the two incidents carry significant warnings for the entire ZK Rollup space.

In one incident, the attacker exploited an inconsistency between the number of transactions and the actual processed data, allowing the system to record a deposit inside 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 verified a proof that was formally valid, but failed to ensure that the private state tree used in the proof was completely consistent with the public state root on Ethereum used for settlement. The attacker was then able to generate a proof based on a fake state tree and withdraw assets from the L1 contract.

Such issues are difficult to summarize with the traditional "Is there a single line of vulnerability in the contract?" approach. After all, zero-knowledge proofs can prove that a certain computation process follows established rules, but only if the rules themselves are correct and complete. If the developer forgets to constrain a key variable, the proof may still be mathematically valid, but it proves a result that does not match the actual settlement state.

The subsequent security incident involving Taiko exposed another type of L2 trust chain risk.

On June 22, 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 been submitted to a public GitHub repository, and exploited the fact that the on-chain verification contract did not reject DEBUG mode enclaves, registering a malicious prover as a legitimate instance.

The attacker then forged an L2 state proof, causing the contract on Ethereum to accept a non-existent L2 state, ultimately extracting assets from bridged funds. In essence, 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 "certified" proof to lose its intended trust meaning.

Meanwhile, Base experienced mainnet block production stalls from June 25 to 26. In a post-mortem, Base stated that the two outages originated from the same block construction logic flaw: a failed transaction did not properly clean up previously recorded state, causing subsequent transactions to be incorrectly calculated for gas and generating blocks containing invalid state transitions. Since other nodes could not accept such blocks, the network eventually stopped making progress. Base stated that the chain’s integrity was not compromised during the incident and user funds were always 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, whether the cross-chain bridge works normally, whether nodes can recover quickly, and whether users still have a viable exit path when the system fails.

Therefore, when using L2, users should not only compare fees and airdrop expectations. For L2s that are small, newly launched, or whose security mechanisms are still rapidly changing, try to avoid storing large amounts of assets beyond actual usage needs for long periods. Before cross-chaining, confirm that you are using the official bridge and understand the withdrawal time, pause mechanism, and emergency exit methods. If the network stops producing blocks, cross-chain anomalies occur, or official security warnings are issued, do not repeatedly submit transactions or continue bridging assets.

A safer approach is to manage assets with different purposes and risk levels separately, rather than putting all liquidity in the same L2, the same cross-chain bridge, or the same exit mechanism.

III. Contract Not Compromised, But Third-Party Services Can Still Bring Attacks to Users

If the issues with wallets and L2 still occur in more underlying technical components, the Polymarket incident shows that the web frontend closest to users can also become an entry point for funds.

On June 25, Polymarket stated that one of its third-party vendors had been compromised, and the attacker injected 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, involving about 11 wallets. The stolen funds were subsequently cross-chained from Polygon to Ethereum and exchanged for approximately 1,893 ETH. However, Polymarket later stated that it had removed the affected dependencies and would fully reimburse affected users.

The key point of this incident is that users may have still accessed the correct Polymarket domain, and the existing disclosures do not point to a vulnerability in Polymarket’s core smart contracts. The problem mainly lay in the third-party frontend dependencies loaded by the webpage.

This incident 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 of these dependencies is attacked, it could cause legitimate websites to display wrong information, replace withdrawal addresses, or trick wallets into signing malicious transactions.

Therefore, "the URL is real" does not necessarily mean "all code loaded right now is safe," and "the contract passed an audit" does not mean the entire interaction path between the user and the contract is risk-free. Faced with such frontend and supply chain attacks, ordinary users find it difficult to independently inspect every piece of code loaded by the webpage. However, they can still limit potential losses by reducing the permissions granted in a single interaction:

• Use a separate wallet for DApp interactions: Try not to connect long-term savings wallets directly to various DeFi, NFT, prediction market, and airdrop sites. The daily interaction wallet should only hold funds intended for near-term use. Even if the frontend or authorization is compromised, the impact is relatively limited.

• Pay attention to the actual operation before signing, not just the webpage buttons: The webpage may say "Login," "Claim," or "Confirm Order," but that does not mean the signature popping up in the wallet is the same thing.

• When the webpage behaves abnormally, do not rely on habit to continue operating: If the page suddenly asks to re-import the seed phrase, download an additional plugin, or shows transaction content inconsistent with the webpage description, pause the interaction, confirm the situation through multiple official channels of the project, and check or revoke historical authorizations that are no longer in use.

From a wallet product perspective, this also means the role of the wallet is changing. It should not only be a tool for storing private keys and popping up signature windows, but also help users understand transaction intent, identify abnormal authorizations, display asset changes, and provide sufficiently clear warnings before high-risk interactions occur.

However, wallets cannot eliminate all risks for users. A more realistic security model is for wallets, protocols, L2s, third-party service providers, and users to jointly reduce the attack surface, rather than shifting all responsibility to any single party.

Final Thoughts

In the past, people 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 when a user "forms a transaction intent" to when "on-chain settlement is completed." Today’s Web3 security is no longer just about protecting a set of seed phrases; it is 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 should stay away from all on-chain interactions. For users, truly effective security habits mean managing asset usage, risk levels, and interaction scenarios separately: isolate long-term assets, keep small amounts for daily interactions, grant low permissions in unfamiliar DApps, and verify carefully for high-risk operations.

After all, when security risks expand from a single point to a chain, users’ defenses must also evolve from simply protecting private keys to a complete set of habits.

Let us all take this to heart.