This past June, the crypto world experienced a wave of security incidents spanning multiple parts of the ecosystem.
According to PeckShield’s latest monthly security report, 40 major hacks occurred in June, causing total losses of $75.87 million. More concerningly, the attacks were not limited to a single vector. They spanned flaws in wallet signing implementations, vulnerabilities in L2 protocols, and supply chain attacks involving third-party services, with multiple layers of defense failing in the same month.
As Web3 security risks expand from isolated attack vectors to the entire on-chain interaction journey, every user must reconsider one fundamental question: Are my crypto assets truly secure?
1. Beyond Private Keys: Why a Wallet’s Signing Implementation Matters
The security incident involving SecondFi, a wallet in the Cardano ecosystem, is one of the clearest examples.
SecondFi evolved from Yoroi, another wallet in the Cardano ecosystem. Between June 21 and 23, attackers moved approximately 16 million ADA out of addresses belonging to some SecondFi users. Around 374 wallets were affected, representing roughly $2.4 million at the time. SecondFi later said that emergency measures had secured another 129 million ADA that might otherwise have been at risk.
What makes this incident particularly notable is that the affected users never handed their mnemonic phrases to the attackers. The problem lay in the wallet’s underlying signing implementation.
According to BlockSec, it incorrectly derived the signing nonce from public transaction messages and omitted the secret nonce prefix required by the relevant cryptographic standard.
As a result, whenever a user signed a transaction with an affected wallet version, the public signature data posted on-chain could expose enough information to derive the private key corresponding to that address. Attackers did not need to compromise the user’s phone or obtain the mnemonic phrase; analyzing public on-chain data alone could be enough to recover the key.
From the user’s perspective, the wallet still appeared to function normally: no pop-up had exposed the mnemonic phrase, the password had not been cracked, and the transactions had genuinely been initiated by the user.
Cryptographically, however, once an address had generated valid signatures using an affected wallet version, the public transaction and signature data could help an attacker derive the corresponding private key.
Ultimately, wallet security also depends on whether private keys are generated correctly, whether signatures strictly follow cryptographic standards, and whether the critical code can be independently reviewed and verified. This is precisely why open-sourcing core wallet components matters.
Of course, this was an implementation flaw in a specific version of a particular wallet, not a problem common to all self-custodial wallets.
For example, the repositories for imToken’s TokenCore are publicly available on GitHub and cover foundational wallet functions such as key management, address derivation, and transaction signing.
Open-source code does not guarantee the absence of vulnerabilities, nor does it mean users can stop being vigilant. For a wallet’s most sensitive cryptographic and signing components, however, open source provides an essential foundation: researchers, developers, and community members can inspect the code, reproduce issues, and test it continuously instead of having to trust an unverifiable black box.
For users, incidents like this also highlight several practical security principles.
- First, always download wallet apps from official websites or official app stores, and install security updates promptly.
- Second, avoid keeping all your assets in a single wallet used for everyday interactions. Large, long-term holdings can be stored in a hardware wallet or a separate cold wallet and kept apart from the hot wallet you regularly connect to DApps.
- More importantly, once a wallet provider confirms a flaw in how keys are generated or transactions are signed, simply importing the original mnemonic phrase into another wallet does not solve the problem.
Importing the same mnemonic phrase into another wallet does not change any addresses or private keys that may already have been exposed. The affected assets need to be moved to a new address that has never signed a transaction with the vulnerable wallet version.
For most users, the safer approach is to follow the provider’s official incident-response instructions, create an entirely new wallet with a new mnemonic phrase, and migrate the assets there, rather than repeatedly importing or continuing to use the affected addresses.
2. L2s Are More Than “Cheaper Ethereum”—They Rely on Complex Chains of Trust
Beyond wallets, several incidents in June also highlighted the risks within increasingly complex L2 systems.
On June 14 and 18, two legacy rollup deployments associated with Aztec were attacked, resulting in combined losses of approximately $4.35 million.
It is important to clarify that the affected systems were legacy deployments such as Aztec Connect, not the Aztec Network mainnet itself. Even so, the flaws exposed by the two incidents serve as an important warning for the broader ZK rollup ecosystem.
In one incident, the attacker exploited a mismatch between the declared transaction count and the data actually processed. This caused the proof to record a deposit without the corresponding balance being deducted on L1.
The other incident stemmed from missing constraints in a zero-knowledge proof circuit. The system accepted a formally valid proof without ensuring that the private state tree used in the proof matched the public state root used for settlement on Ethereum.
The attacker could therefore generate a proof based on a fabricated state tree and withdraw assets from the L1 contract.
Problems like these cannot be reduced to the traditional question of whether one particular line of smart contract code is vulnerable. A zero-knowledge proof can show that a computation followed a predefined set of rules, but only if those rules are themselves correct and complete.
If a critical variable is left unconstrained, the proof may remain mathematically valid while proving a result that does not match the actual settlement state.
A subsequent security incident involving Taiko exposed another form of risk in the L2 trust chain.
On June 22, Taiko’s SGX-based proof-verification process was exploited, causing approximately $1.7 million in losses. According to BlockSec, the attacker used an SGX enclave signing key that had previously been checked into a public GitHub repository.
The attacker also took advantage of an on-chain verification flaw that failed to reject enclaves running in DEBUG mode, allowing a malicious prover to register as a legitimate instance.
The attacker then forged an L2 state proof, causing an Ethereum contract to accept an L2 state that did not actually exist and ultimately enabling unauthorized withdrawals from the bridge.
At its core, the incident occurred because the key used to sign the trusted enclave had been publicly exposed, while the remote-attestation rules did not fully verify the environment’s runtime properties. A proof that had technically “passed attestation” therefore no longer carried the trust that the attestation was meant to provide.
Meanwhile, Base experienced two mainnet block-production stalls on June 25 and 26.
In its post-incident review, Base said both outages stemmed from the same flaw in its block-building logic: a transaction that failed during execution did not properly clear previously recorded state, causing gas for subsequent transactions to be calculated incorrectly and producing a block with an invalid state transition.
Because other nodes could not accept the block, the network stopped progressing. Base said chain integrity was not compromised and user funds remained safe throughout the incidents.
This was not an asset theft or an external attack, but a technical failure affecting network availability and recoverability. From a broader security perspective, availability is itself part of an L2’s security model.
For users, a network’s security depends not only on whether attackers can forge assets or state, but also on whether blocks continue to be produced, bridges remain operational, nodes recover quickly, and users retain a viable exit path when the system fails.
Users should therefore look beyond fees and potential airdrops when evaluating an L2.
On smaller or newly launched L2s, or networks whose security mechanisms are still changing rapidly, avoid leaving more assets on-chain than you actually need.
Before bridging, confirm that you are using the official bridge and understand the withdrawal period, pause mechanisms, and emergency exit options.
If block production stops, bridge transactions behave unexpectedly, or the project issues a security alert, do not repeatedly resubmit transactions or continue moving assets across the bridge.
A safer approach is to manage assets separately according to their purpose and risk level, rather than concentrating all your liquidity on a single L2, bridge, or exit mechanism.
3. Even If the Contract Is Secure, Third-Party Services Can Still Expose Users to Attacks
While the wallet and L2 incidents involved relatively low-level technical components, the Polymarket incident showed that the web front end closest to users can also become an attack vector targeting their funds.
On June 25, Polymarket said that one of its third-party service providers had been compromised, allowing the attacker to inject malicious scripts into the version of the Polymarket front end served to some users.
According to estimates from security firms and on-chain analysts, the incident caused approximately $3 million in user losses and affected around 11 wallets.
The stolen funds were later bridged from Polygon to Ethereum and swapped for approximately 1,893 ETH. Polymarket subsequently said it had removed the affected dependency and would fully reimburse affected users.
The key point is that affected users may still have been visiting the legitimate Polymarket domain,while public disclosures did not indicate any vulnerability in Polymarket’s core smart contracts. The problem lay primarily in a third-party front-end dependency loaded by the website.
This incident reflects a broader reality: most Web3 applications do not operate entirely on-chain.
The websites users interact with, including trading interfaces, still rely heavily on traditional internet infrastructure and third-party software packages. If any of these dependencies is compromised, a legitimate website may display false information, replace recipient addresses, or trick users into signing malicious transactions through their wallets.
A legitimate URL does not necessarily mean that every piece of code currently loaded by the page is safe. Likewise, an audited smart contract does not mean that the entire interaction path between the user and the contract is risk-free.
Users cannot realistically inspect every piece of code a webpage loads, but they can limit potential losses by reducing the permissions granted in each interaction and limiting the assets exposed to it.
Use a separate wallet for DApp interactions. Avoid connecting wallets that hold long-term assets directly to DeFi, NFT, prediction-market, or airdrop websites. Keep only the funds you expect to use in the near term in your everyday interaction wallet. This limits the potential impact if a front end is compromised or a malicious approval is granted.
Verify the action shown in your wallet, not just the button displayed on the webpage. A webpage may say “Log in,” “Claim,” or “Confirm Order,” but the signature request in your wallet may authorize something entirely different.
Stop when a webpage behaves unexpectedly instead of continuing out of habit. If a page suddenly asks you to import your mnemonic phrase again, install an additional extension, or sign a transaction whose details do not match the action described on the website, stop interacting. Check the project’s status through multiple official channels, and review or revoke any old token approvals you no longer use.
From a product perspective, this also means the role of wallets is changing.
A wallet should do more than store private keys and display signature prompts. It should help users understand transaction intent, identify suspicious approvals, show expected asset changes, and provide clear warnings before high-risk interactions occur.
However, wallets cannot eliminate every risk for users.
A more realistic security model requires wallets, protocols, L2s, third-party service providers, and users to work together to reduce the attack surface, rather than placing all responsibility on any one party.
Final Thoughts
People often say that whoever controls the private keys controls the on-chain assets.
That remains true, but it does not cover the entire journey from initiating an on-chain action to reaching final settlement.
Web3 security today is no longer just about protecting a mnemonic phrase. It means protecting the full path—from how a wallet generates keys and presents transaction details to how signatures are executed, networks verify state, and transactions reach final settlement.
This does not mean users need to avoid all on-chain interactions. Effective security habits mean managing assets separately based on their purpose, risk level, and how they are used: keep long-term holdings isolated, limit the funds kept in everyday interaction wallets, grant minimal permissions to unfamiliar DApps, and double-check high-risk actions.
After all, when security risks expand from a single point to an entire chain, users’ defenses must also evolve—from protecting private keys alone to building a complete set of security practices.