Beyond Just Private Keys: From Wallets, L2s to Supply Chains, How to Safeguard the Security Boundaries of Web3?

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

PeckShield's latest monthly security report shows that June saw 40 major hacking incidents with total losses reaching $75.87 million. What's more concerning is that these attacks were not concentrated on a single attack vector, but rather covered 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: Are my crypto assets still safe?

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

The security incident on the Cardano ecosystem wallet SecondFi in June is the most telling example.

SecondFi was formerly known as the Cardano ecosystem wallet Yoroi. Between June 21 and 23, an attacker transferred approximately 16 million ADA from some SecondFi user addresses, involving about 374 wallets. At the time of the incident, this was valued at approximately $2.4 million. SecondFi subsequently 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 attacker. The problem lay in the wallet's underlying signature implementation. According to an analysis by security firm BlockSec, the implementation incorrectly derived signature nonces from public transaction messages, omitting the secret nonce prefix required by standard implementations.

This meant that every time a user signed a transaction using the affected wallet version, the public signature data posted on-chain would reveal enough information to derive the private key for that address. Therefore, the attacker did not need to compromise the user's phone or obtain their 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 was functioning normally. After all, the seed phrase wasn't leaked via a pop-up, the password wasn't cracked, and the transaction was indeed initiated by the user. However, from a cryptographic standpoint, if a user's address had generated valid signatures using the affected version, the public transaction and signature data could help the attacker derive that address's signing private key.

Ultimately, wallet security depends on whether private keys are generated correctly, 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 general problem for 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 code doesn't mean it's necessarily free of vulnerabilities, nor does it mean users can let their guard down entirely, for the most sensitive cryptographic and signature components within a wallet, open-sourcing provides at least one crucial prerequisite: security researchers, developers, and the community can inspect the code, reproduce issues, and continuously test it, rather than having to trust an unverifiable black box.

For ordinary users, this type of event also corresponds to several more practical security principles.

• First, wallets should always be downloaded from official websites or official app stores, and security updates should be applied promptly.
• Second, it's unwise to keep all assets in a single daily-use wallet. Large amounts of long-term assets should be stored using hardware wallets or separate cold wallets, isolated from hot wallets frequently used to connect to DApps.
• More importantly, once a wallet provider 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 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 used to sign transactions via the vulnerable version. For ordinary users, a safer approach is usually to follow the provider's emergency procedure: create a completely new set of wallet and seed phrases, and then migrate the assets, rather than repeatedly importing or operating on the original addresses themselves.

2. L2s: Not Just "Cheaper Ethereum," But a Complex Chain of Trust

Beyond wallets, several incidents in June also pointed the finger at increasingly complex L2 systems.

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's important to note that the attacks targeted legacy deployments like Aztec Connect, which are already in a deprecated state. This does not equate to a direct 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 space.

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

The other event stemmed from a missing constraint within the zero-knowledge proof circuit. The system verified a valid-looking proof without ensuring that the private state tree used in the proof was entirely consistent with the public state root on Ethereum used for actual settlement. This enabled the attacker to generate a proof based on a falsified state tree and drain assets from the L1 contract.

This type of problem is difficult to summarize with the traditional "is there a vulnerability in this line of contract code?" approach. After all, a zero-knowledge proof can attest that a computation followed defined rules, but only if the rules themselves are correct and complete. If a developer forgets to constrain a critical variable, the proof might still be mathematically valid, yet it proves a result inconsistent with the actual settlement state.

The subsequent security incident on 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 attacker used an SGX enclave signing private key that had been previously committed to a public GitHub repository. Simultaneously, they exploited a flaw in the on-chain verification contract that failed to reject enclaves running in DEBUG mode, 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 funds from the bridge. In essence, because the key used to sign the trusted execution environment was made public, and the remote attestation rules didn't fully check the runtime environment attributes, a "verified" proof lost its intended meaning of trustworthiness.

Meanwhile, 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 miscalculate gas and generate blocks containing invalid state transitions. As other nodes could not accept these blocks, the network eventually stopped advancing. Base confirmed that chain integrity was not compromised during the incident and user funds were always safe.

This wasn't a case of asset theft or an external attack, but a technical failure affecting network availability and recovery capabilities. From a broader security perspective, however, availability is itself 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, whether cross-chain bridges function correctly, whether nodes can recover quickly, and whether users have viable exit paths when the system fails.

Therefore, when choosing an L2, users shouldn't just compare fees and airdrop expectations. For smaller, recently launched L2s, or those with rapidly changing security mechanisms, avoid storing large sums of assets beyond immediate needs for long periods. Before bridging assets, confirm the use of the official bridge and understand withdrawal times, pause mechanisms, and emergency exit procedures. If the network stops producing blocks, cross-chain transactions are abnormal, or the project issues a security warning, do not repeatedly submit transactions or continue bridging assets.

A safer approach is to distribute assets with different purposes and risk levels across different layers, rather than concentrating all liquidity on a single L2, a single bridge, or a single exit mechanism.

3. Even If the Contract Isn't Breached, Third-Party Services Can Bring Attacks to Users

If wallet and L2 issues still occur within relatively low-level technical components, the Polymarket incident shows that the web frontend, the part closest to the user, can also become an entry point for fund loss.

On June 25, Polymarket stated that one of its third-party vendors was compromised, allowing an attacker 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 the loss of approximately $3 million in user assets, involving about 11 wallets. The stolen funds were subsequently bridged from Polygon to Ethereum and swapped for approximately 1893 ETH. However, Polymarket later stated they had removed the affected dependency and would provide full refunds to affected users.

The key point of this incident is that users might have still been visiting the correct Polymarket domain. Existing disclosures do not point to a vulnerability in Polymarket's core smart contracts; the problem primarily lay in the 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, such as trading interfaces, still rely heavily on traditional internet infrastructure and third-party software packages. If any one of these dependencies is compromised, it could allow a legitimate website to display incorrect information to users, substitute payment addresses, or trick wallets into signing malicious transactions.

Therefore, "the URL is correct" does not necessarily equal "all code currently loaded 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 these types of frontend and supply chain attacks, ordinary users can hardly independently inspect every piece of code loaded by a webpage. However, they can limit potential losses by reducing permissions for single interactions:

• Use a dedicated wallet for DApp interactions: Avoid connecting long-term savings wallets directly to various DeFi, NFT, prediction market, and airdrop websites. Keep only funds needed for near-term use in daily interaction wallets. Even if the frontend or an approval is compromised, the impact scope is relatively limited.
• Focus on the actual operation before signing, not just the button on the webpage: Just because the webpage says "Login," "Claim," or "Confirm Order" doesn't mean the signature request popping up in your wallet is for the same action.
• When the webpage behaves abnormally, don't rely on inertia to continue: If the page suddenly asks you to re-import your seed phrase, download an additional plugin, or displays transaction content inconsistent with the webpage description, pause the interaction. Confirm the situation through multiple official channels of the project, and check or revoke any unused historical token approvals.

From a wallet product perspective, this also means the role of the wallet is changing.

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

However, a wallet cannot eliminate all risks for the user. A more realistic security model involves wallets, protocols, L2s, third-party service providers, and users working together to shrink the attack surface, rather than placing all responsibility on any single party.

Final Thoughts

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

This statement remains true, but it doesn't cover the entire journey of user assets from "forming a transaction intent" to "completing on-chain settlement." Today's Web3 security is no longer just about protecting a set of seed phrases. It's about protecting the entire path: from wallet key generation, transaction display, and signature execution, to network validation and final settlement.

Of course, this doesn't mean users should avoid all on-chain interactions. For users, truly effective security habits mean managing assets based on their purpose, risk level, and interaction scenario: isolate long-term assets, keep small amounts for daily interactions, grant minimal approvals for unfamiliar DApps, and double-check high-risk operations.

After all, when security risks expand from a single point to an entire chain, a user's defense must also evolve from simply protecting their private keys to adopting a comprehensive set of habits.

Let's all keep this in mind.