Web3 Penetration Testing: A Guide for Protocols and Security Researchers (2026)

Web3 penetration testing is an adversarial security assessment in which we attack a live blockchain system the way a real attacker would, then prove each weakness with a working exploit. It covers smart contracts and everything around them: wallets, dApp frontends, signing flows, key custody, infrastructure, and third-party integrations.

At Sherlock, we’ve spent years securing leading Web3 protocols across development, auditing, and live operation, and over that time we've watched penetration testing move from a nice-to-have to a core part of how serious teams ship. The reason is a shift we see firsthand in nearly every engagement: the largest losses in crypto no longer come from the smart contract alone.

Key takeaways

• A penetration test is whole-system and adversarial. It attacks the wallets, frontends, signing flows, keys, and infrastructure a contract audit never scopes.
• It complements a standard smart contract audit rather than replacing it. We recommend both for most protocols depending on the infrastructure.
• Penetration tests matter because risk has shifted off-chain. Private key compromise was the single largest cause of crypto theft in 2024, at 43.8% of all stolen funds.
• We tell protocols to pen test before launch and after any change that adds a new trust relationship.
• Researchers earn their reputation through audit contests and bug bounties, by learning the trust graph and proving findings with real exploits.

The Shift We're Seeing in 2026

When Sherlock started securing the Web3 space in 2021, securing a protocol mostly meant securing its contract. That is no longer the system we are asked to defend. The protocols we work with today ship with key custody, off-chain services, third-party integrations, and a deep dependency chain, and each of those carries its own trust assumptions. As that surface expanded, the attacks followed it, and our engagements shifted with them.

The loss data matches what we see on the ground. In 2024, private key compromise accounted for 43.8% of all crypto stolen, the single largest root cause that year by Chainalysis's count, ahead of any on-chain bug class. The 2026 OWASP Smart Contract Top 10 still ranks access control as the most critical on-chain risk, and we agree it belongs there. But the pattern that defines 2026 for us is clear: the biggest losses increasingly originate off-chain, in keys, signers, frontends, and operational systems a contract audit was never built to examine.

Penetration Testing vs. Smart Contract Auditing

In our work, an audit and a pen test answer different questions. A smart contract audit reviews on-chain code line by line, combining manual expert review with static analysis and fuzzing to find logic flaws before deployment. We treat it as the foundation of any serious security program.

A penetration test is broader and adversarial. We take the protocol as one running system and probe the trust relationships between its parts, including the off-chain components an audit does not scope. The feature we insist on is proof. Every finding we report ships as a reproducible exploit run against the real system, paired with the fix that closes it. Where an audit asks whether the code is correct, our pen test asks what an attacker can actually make the system do. An audit certifies the on-chain logic; a pen test stress-tests everything that logic quietly trusts.

What We Test in a Web3 Pen Test

The value of penetration testing shows most clearly in the surfaces a contract review cannot reach. When we run an engagement, we go after:

Wallets and browser extensions. The provider, signing UI, and message passing between page, content script, and background process, where a co-resident script can try to speak for the wallet.

dApp frontends and the supply chain. The interface and its dependency tree, where a compromised script or poisoned package can drain users while the audited contracts stay untouched.

Signing flows. The gap between what a user is shown and what they actually sign. Standards like EIP-712 exist because structured-data signing fails when the rendered message and the signed bytes diverge, and we test that gap on every approval surface.

Access control and key custody. Admin paths, upgrade mechanisms, multisig quorums, and the signing infrastructure behind them, where a phished key or an exposed route undoes otherwise-sound cryptography.

Infrastructure and integrations. Oracles, bridges, RPC endpoints, and deployment pipelines, where the danger lives in how components compose under real conditions.

How We Run a Web3 Pen Test

A Web3 penetration test starts with the system as it actually operates, not with a repository in isolation.

We map the assets an attacker would want, the identities and keys that control them, the services that can move or authorize value, and every trust boundary connecting the application, frontend, APIs, cloud infrastructure, signers, wallets, oracles, bridges, and smart contracts. That produces an attack map of the full system and shows where a weakness in one layer could become a loss somewhere else.

Our process follows the disciplined structure described in NIST SP 800-115: planning, discovery, attack, and reporting. In practice, that means:

1. Define the attack surface. We document exposed services, privileged paths, external dependencies, authentication flows, signing authority, and the assumptions each component makes about the others.
2. Model realistic attack paths. We work backward from the outcomes that matter most, such as unauthorized signing, key exposure, manipulated transactions, account takeover, compromised infrastructure, or the movement of protocol funds.
3. Test those paths adversarially. Researchers attempt to break the boundaries protecting those outcomes using the techniques available to a real attacker, including application exploitation, authorization bypasses, message forgery, dependency compromise, cloud misconfiguration, and abuse of operational workflows.
4. Prove impact. Where it can be done safely, we reproduce the issue in a controlled environment and provide the exact conditions, steps, and evidence needed to demonstrate the result. A working proof removes ambiguity and gives the engineering team a concrete target for remediation.
5. Verify the fix. Every remediation is retested against the original attack path. We confirm that the issue is closed, that the trust boundary now holds, and that the fix has not introduced another route to the same outcome.

The final deliverable is more than a list of vulnerabilities. It explains how the attack works, what an attacker needs, what they can achieve, which systems are affected, and how the underlying assumption should be corrected.

When We Tell Protocols to Pen Test

Our answer is straightforward: run a penetration test whenever the system introduces a trust relationship that its previous reviews did not cover.

That includes a new frontend, wallet, bridge, signer set, oracle, API, cloud deployment, admin workflow, authentication system, third-party dependency, or offchain service with authority over onchain assets. Each one adds assumptions about identity, permissions, data integrity, or message origin that may never appear inside the smart contracts themselves.

The highest-leverage moments are:

• Before launch, when the complete system is assembled and real value is about to rely on it.
• After a major integration, especially one that can influence pricing, signing, upgrades, withdrawals, or transaction construction.
• After meaningful frontend or infrastructure changes, even when the contracts remain untouched.
• Before increasing operational authority or TVL, when an existing weakness would carry materially greater impact.
• After an incident or near miss, when the goal is to determine whether the observed issue was isolated or part of a broader attack path.

Penetration testing is strongest as one layer of a wider security program: specialist review for the architecture’s hardest areas, broader adversarial coverage across the codebase, and continued protection after deployment.

The Motion wallet assessment shows that model in practice. Sherlock tested the extension as a complete operating system of browser contexts, provider messages, approval surfaces, signing flows, and locally held keys. The most serious findings appeared between those components, where each piece behaved as designed but trusted information the attacker could manipulate. Those issues were reproduced in a live browser, fixed before launch, and retested against the original exploit path.

For Security Researchers: A 1–2–3 Playbook

The researchers we trust with high-stakes penetration testing usually follow the same path:

1. Pick one surface and learn how it breaks.
Start narrow. Choose wallets, frontends, bridges, signing flows, custody systems, or protocol infrastructure and learn the full attack surface around it. Read past reports, reproduce known exploits, and build small test environments until you understand where trust crosses between components.

2. Prove your skill on real systems.
Enter public audit contests and work live bug bounties. We pay attention to researchers who consistently submit valid findings, demonstrate impact clearly, and provide proofs that an engineering team can reproduce. One strong exploit with clean reasoning is more valuable than a long list of speculative issues.

3. Build range and earn harder scopes.
Once you have a track record, move into adjacent surfaces and learn to follow attack paths across them. The researchers we bring into senior and invite-only engagements can connect a weakness in a frontend, signer, API, or wallet to its eventual onchain impact. That ability to reason across the whole system is what separates a strong auditor from a strong penetration tester.

Frequently Asked Questions

How is Web3 penetration testing different from a smart contract audit? An audit reviews on-chain code for correctness. A penetration test adversarially attacks the whole running system, including the wallets, frontends, signing flows, and infrastructure an audit does not scope, and proves each issue with a working exploit. We recommend both for most protocols.

When should a protocol get a penetration test? We tell teams to test before launch, when real value is about to back code that has only seen friendly traffic, and after any change that adds a new trust relationship: a new bridge, signer set, oracle, frontend dependency, or admin path.

Can penetration testing prevent every hack? No assessment can promise that, and we don't. What we can do is find and fix exploitable weaknesses before attackers do, especially in the off-chain and operational areas where most recent losses originate.

What does a Web3 penetration test cover? We test smart contracts plus wallets and extensions, dApp frontends and their dependencies, signing and approval flows, access control and key custody, and infrastructure such as oracles, bridges, and RPC endpoints.

What skills do Web3 penetration testers need? The researchers we work with share a whole-system, adversarial mindset, fluency in the relevant standards such as EIP-712 and the OWASP Smart Contract Top 10, and the ability to turn a suspected weakness into a reproducible exploit. Audit contests and bug bounties are the usual proving ground.

Conclusion

We have watched the economics of Web3 attacks move off-chain, and in 2026 the security process has to follow. Audits remain necessary, and penetration testing closes the gap by testing the wallets, frontends, signing flows, access control, and infrastructure a contract review cannot reach, proving each finding with a real exploit.

For protocols, that means testing the whole surface before value flows and after every meaningful change. For researchers, it means building the adversarial instinct and the track record to find what others miss. If you want the full surface tested before you ship, contact our security team and we'll help scope the right review.

‍