A decision-maker's playbook for modern Web3 pentesting: what’s new since 2024 (Dencun/EIP‑4844, ERC‑4337 v0.8/0.9, L2 fault proofs). We'll dive into how to effectively scope and carry out a true assessment across contracts, AA stacks, bridges, and ZK components, plus tips on how to set up monitoring and response.

Web3 Application Penetration Testing and Web3 Anwendungs-Penetrationstests: How to Pentest a Blockchain

Blockchain security really took off in 2024-2025! Ethereum's Dencun upgrade changed the game by shifting how data flows for rollups. Account abstraction got a nice boost too, thanks to EntryPoint v0.8/0.9 and EIP‑7702. Plus, major Layer 2 solutions started enabling permissionless fault proofs, which is pretty exciting.

Now, if you want to do effective penetration testing, you need to think of your dapp as a complex web of chains, contracts, off-chain services, and mempools--not just a bunch of Solidity files sitting around. You can dive deeper into this at (eip4844.com).

Executive view: What’s new that changes your pentest scope in 2026

• The recent Ethereum Dencun/EIP‑4844 update rolled out “blob” transactions that hang around on beacon nodes for about two weeks and then get pruned. This shakes up our usual data-availability expectations, alters fee dynamics, and affects the impact zones for Layer 2 incidents. Make sure your pentests confirm how your rollup and analytics are relying on this short-lived blob data compared to traditional calldata. (eip4844.com)
• OWASP just dropped the re-ranked Smart Contract Top 10 for 2025, and things are shifting! Access Control and Price Oracle Manipulation are now SC01 and SC02, while Flash Loans and Unchecked External Calls made it onto the list. This is a great opportunity to revisit your risk register and test plan. (scs.owasp.org)
• With ERC‑4337 EntryPoint v0.8, we’re seeing some cool new features like native EIP‑7702 support, EIP‑712-compatible UserOp hashing, and the removal of gas penalties below a certain threshold. Then, EntryPoint v0.9 brought in getCurrentUserOpHash and some updates on Paymaster ownership. Don’t forget that your pentests should check EntryPoint address selection, 7702 authorization handling, and how bundlers operate. (github.com)
• There have been real incidents and advisories related to Account Abstraction (AA), like the UserOperation packing/hash divergence and a trust issue with UniPass EntryPoint. It’s clear that having proper “AA threat models” is essential now. Make sure to verify canonical hashing, align events and indexers, and keep trusted EntryPoint pinning in mind. (alchemy.com)
• The security landscape for Layer 2 has changed quite a bit! Arbitrum’s BoLD went live on February 12, 2025, allowing for permissionless validation. This has updated finalize/exit timelines and fraud-proof assumptions. Your pentests should simulate withdrawal challenges and explore bridge failure scenarios based on these new dispute windows. (docs.arbitrum.io)
• There's been a shift in operations tooling, too. OpenZeppelin announced they’ll be phasing out Defender SaaS by July 1, 2026, putting more focus on open-source Relayer/Monitor solutions. It’s a good time to review your runbooks and prepare for monitoring migrations to stay secure. (blog.openzeppelin.com)

---

A practical Web3 pentest playbook for 2026

1) Scope: inventory the system, not just the contracts

Creating a Living Inventory with Trust Boundaries for:

Building a living inventory isn't just about listing assets; it’s about layering in trust boundaries for better security and management. Here’s how you can break it down.

Step 1: Identify Your Assets

First off, you need to know what you have. This could include anything from hardware and software to data and services. Take some time to jot down all the key components of your inventory. Consider:

• Hardware: Servers, computers, mobile devices
• Software: Applications, operating systems, licenses
• Data: Customer information, financial records, internal documents
• Services: Cloud services, third-party vendors, APIs

Step 2: Define Trust Boundaries

Next up, let’s talk about trust boundaries. These are the lines that delineate where your assets can be trusted and where they require additional safeguards. Think of them as the security zones in your inventory.

• Internal Trust Zone: This is where you have full control, like your internal network. Here, assets are assumed to be secure unless proven otherwise.
• External Trust Zone: This includes anything outside your direct control, like third-party services or public networks. Be wary! You’ll want stricter access controls here.
• High-Risk Assets: Some assets are riskier than others. For example, customer databases need extra protection compared to internal development tools.

Step 3: Map the Inventory

Now that you’ve got your assets and trust boundaries defined, it’s time to create a visual map. This helps everyone understand the landscape at a glance. Here’s a simple way to lay it out:

+-------------------------------------+
|          Internal Trust Zone        |
| +-------------------------------+   |
| |         Assets List          |   |
| | - Database Servers           |   |
| | - Internal Applications       |   |
| | - Employee Access Control    |   |
| +-------------------------------+   |
+-------------------------------------+

+-------------------------------------+
|         External Trust Zone         |
| +-------------------------------+   |
| |         Assets List          |   |
| | - Third-Party APIs           |   |
| | - Cloud Services             |   |
| | - Remote Access              |   |
| +-------------------------------+   |
+-------------------------------------+

+-------------------------------------+
|         High-Risk Assets            |
| +-------------------------------+   |
| |         Assets List          |   |
| | - Customer Database           |   |
| | - Financial Records           |   |
| | - Personal Data               |   |
| +-------------------------------+   |
+-------------------------------------+

Step 4: Review and Update Regularly

A living inventory isn’t a “set it and forget it” kind of deal. Make sure to review and update it regularly. Changes in your environment (new software, hardware updates, or changes in risks) mean you need to adapt your inventory.

Step 5: Communicate with Your Team

Last but definitely not least, share this inventory with your team. Everyone needs to be on the same page about what to secure and how to manage risk effectively. This can be done through:

• Team meetings
• Shared documents
• Regular training sessions

By keeping your living inventory up-to-date and making sure your team is informed, you’re building a stronger foundation for both trust and security. Don't forget to check out the NIST Cybersecurity Framework for more guidelines on managing your security posture!

• On-chain: Think of this as your go-to for deployed contracts, proxies or implementations, libraries, upgrade authorities, L2 bridge contracts, and on-chain governance. Don’t forget to include EntryPoint, paymasters, and any EIP-7702 accounts if you’re diving into Account Abstraction. Check it out here.
• Off-chain: This part covers everything happening off the chain, like bundlers, indexers, relayers, keepers, price oracles, and provers or sequencers. Also, keep an eye on any signer infrastructure.
• Cross-domain: Here, we’re looking at bridges and messaging options, including LayerZero DVN-AVS, CCIP, and those Wormhole-style guardians. Plus, we can't forget about rollup inboxes/outboxes and withdrawal paths. For more details, visit this link: dedaub.com.
• ZK stack: Dive into the world of circuits, zkVM guest programs, proving keys, verification contracts, and recursion or verifier routers. It's a good idea to keep track of specific versions and CVEs where they apply, like the RISC Zero zkVM fixes scheduled for 2025. You can check out the details here.

Map each boundary to specific assumptions that you're aiming to challenge (for example, “the price oracle might be tampered with if we don’t keep an eye on publishTime and confidence,” “if the bundler event hashes are off, it can throw off off-chain accounting,” or “the bridge validator quorum could either stall or misroute transactions”). Use OWASP SCSVS/SCSTG as your reference point for requirements and test coverage. (scs.owasp.org)

2) Threat modeling: align to today’s dominant exploit patterns

• Start by diving into the OWASP Smart Contract Top 10 (2025) to get some solid ideas for attack paths. Check out things like SC01 Access Control, SC02 Price Oracle Manipulation, SC05 Reentrancy, SC07 Flash Loans, and SC06 Unchecked External Calls. Make sure to link each of these to a specific test case in your backlog. You can find more details here: (scs.owasp.org).
• Don't forget to factor in chain-specific issues that come with Dencun blobs. These include blob data expiry, assumptions about data availability for off-chain processors, and fallback logic when blobs get pruned. More info on that can be found at (eip4844.com).
• When it comes to rollups, incorporate some dynamics around permissionless fraud proofs. Look into things like withdrawal challenge windows under BoLD, the costs of griefing, and the assumptions around censorship resistance. Check out the details here: (docs.arbitrum.io).
• For Account Abstraction (AA), make sure to model things like the EntryPoint version and address pinning, the lifecycle of EIP‑7702 delegation, how the bundler mempool behaves, and the verification of canonical UserOp hashing. You can dig deeper into this on their GitHub: (github.com).
• Lastly, for bridges, turn to some research-backed taxonomies. Look out for issues like validator key compromise, initialization/configuration errors, and message verification bugs. Lean on independent SoK and monitoring research to back up your scenarios. More on that here: (arxiv.org).

---

Smart contract assessment: the modern baseline that actually finds bugs

1. Static analysis using the latest rule sets

• Go ahead and run Slither ≥0.11 with the fresh domain-specific detectors (like Pyth/Chronicle feed checks and that snazzy Optimism deprecation tool) along with the upgraded upgradeability checks. Consider the findings as hypotheses that you can dig into and confirm with some tests. (github.com)

2) Property/Invariant Testing at Scale

• When it comes to protocol-level assertions like “sum of liabilities ≤ reserves” and “no under-collateralized liquidation profits,” Foundry’s invariant fuzzing is the way to go. Make sure you tweak the depth and runs for some solid coverage--think depth≥100 and runs between 1,000 and 10,000 in your CI. Check out more about it here.
• You can specify properties using Scribble, with annotations like #invariant and #if_succeeds. This helps you instrument your contracts and run differential tests whenever upgrades happen. For more details, swing by the Scribble docs.

3) Economic and Oracle Manipulation Tests

• Set up “oracle adversary” harnesses to exploit Top 10 SC02: check those publishTime and confidence validations on data feeds. Slither’s latest detectors can help you catch any unvalidated oracle fields. Check it out here: (github.com)

1. Upgradeability and Storage Layout Safety

• When using OpenZeppelin Contracts 5.x, make sure to check the usage of ERC‑7201 namespaced storage. It's also a good idea to take advantage of OpenZeppelin's audits and security center recommendations. Don’t forget to run some differential tests to compare the invariants before and after your upgrade, and be sure to execute slither-check-upgradeability. Check it out at openzeppelin.com!

1. Reentrancy and Call-Graph Traps

• Dive into nested external calls using Slither’s call graph and Foundry invariant “handler” patterns. If you’re going for the transient storage options rolled out in OZ 5.1, don’t forget to throw in some ReentrancyGuardTransient tests too! Check out more about it here.

6) Formal Methods Where It Matters

When it comes to core invariants--like interest accounting and collateralization--it’s a good idea to layer in some tools like Certora or other formal verifiers. These tools help you encode your economic invariants as rules and then check them against actual deployments. Just make sure to pick a vendor or tool that fits well with your tech stack, and don't forget to cover both the proxy and implementation aspects. You can get some general tips by looking into practices from OZ and other formal methods. For more details, check out OpenZeppelin's announcement.

Quick Start Snippet (Illustrative)

Here's a simple snippet to help you get started:

# This code prints "Hello, World!" to the console
print("Hello, World!")

Make sure to run this in your Python environment and watch it work its magic! It's a classic way to dip your toes into coding. Enjoy!

# Static + invariants + mutation smoke:
slither . --exclude-dependencies --print human-summary
forge test -vv --ffi
FOUNDRY_INVARIANT_RUNS=5000 FOUNDRY_INVARIANT_DEPTH=200 forge test --match-path test/invariants/**
slither . --detect solc-version,unused-import --solc-remaps @openzeppelin=node_modules/@openzeppelin

References for Configurations and Detectors

You can find detailed information about configurations and detectors here.

---

Account Abstraction (ERC‑4337) pentesting: concrete checks that catch real issues

• Check EntryPoint version and address: Make sure you’re working with the v0.8 singleton address on the Ethereum mainnet as outlined in the AA reference repo. Double-check that your deployment is locking in the expected codehash and that it reverts if there are any mismatches. Also, take a look at the changes in v0.9 (like getCurrentUserOpHash and the owner in the Paymaster constructor). You can find more info here.
• Canonical hashing and event divergence: Recreate the “UserOperation packing/hash divergence” situation and make sure your indexers and bundlers are accurately recalculating hashes using EntryPoint.getUserOpHash with decoded calldata, rather than relying just on events. Check this out for more details: Alchemy.
• EIP‑7702 authorization safety: Test that delegated targets are properly validated, and confirm that the 7702 authorizations within the UserOp hash are being enforced. It’s a good idea to simulate replay/abuse scenarios across multiple chains where your stack supports 7702. More info can be found here.
• Trusted EntryPoint assumption: Be sure that wallets and paymasters can’t switch the EntryPoint on the sly. You’ll want to regression-test for the UniPass vulnerability related to EntryPoint substitution. Consider putting together runbooks to help you safely switch to new EntryPoint versions. For more insight, check out this link: RootData.
• Shared mempool and bundlers: It's important to validate that your bundler (like Skandha) is compatible with EntryPoint v0.8 and up. Don’t forget to think about MEV-safe processes for UserOps. Document which networks and environments you’re compatible with. For more on this, visit Etherspot.

---

L2 and cross‑chain: from “train­ing wheels” to permissionless challenges

• Arbitrum BoLD: Go ahead and test the complete withdrawal process under that default challenge period of about 6.4 days, and throw in some adversarial delays just for fun. Make sure your bridge UIs and backends are showing the right finality windows after BoLD and that they’re taking into account that extra challenge period when you’re doing upgrades. (docs.arbitrum.io)
• Operationalize “Stage 1” Rollup Assumptions: If you’re planning to integrate multiple OP-Stack/Arbitrum chains, double-check each chain’s proof status and governance model rather than assuming they’re all the same. It’s a good idea to document the exit SLAs for each chain too. (therelaymag.com)
• Cross-chain Bridges/Messaging:
  • Take a close look at validator/minisig trust, the DVN/AVS parameters, and the slashing and pause controls. Don’t forget to check out the LayerZero DVN-AVS audit notes for more on centralization and trust assumptions. (dedaub.com)
  • Use the SoK and detection research to prioritize your tests for message verification, quorum manipulation, and replay across different domains. Also, run through some scenarios like “what if a validator key gets compromised?” to keep your team on their toes. (arxiv.org)
  • Keep in mind that bridges are still a major target; recent data points to ongoing large losses even with improvements happening overall--so make sure you’re budgeting for some incident drills. (theblock.co)

Example Cross-Domain Test Ideas:

• Dive deep into exhaustive fuzzing of message encoders and decoders to catch any chain-ID mixups.
• Try replay attacks across testnets and mainnets that have similar chain configurations.
• Test out downgrade attacks by simulating older verifier contracts that are still accessible through routers.

---

ZK components: circuits and zkVM guest programs need their own pentest track

• Think of circuits like you're reviewing critical code: make sure you check for things like missing range checks and over/under-constrained relationships. Also, double-check that all your public inputs and witness elements are being used properly. You can find helpful open checklists for circuit audits here. (github.com)
• Keep an eye on specific issues for 2025: for instance, the division/under-constraint vulnerability CVE-2025-54873 in RISC Zero was resolved in versions 2.2.0 and 3.0.0. Make sure your zkVM and verifier contracts are up to date with the patched versions, and don’t forget to regenerate your proofs. (nvd.nist.gov)
• Check on recursion and verifier routers: ensure that you’re running “is_complete” checks--or something similar--and keep track of ordering constraints for recursive proofs in your tech stack. Also, document your plans for emergency router freezes and upgrade paths. (This was highlighted in industry advisories for 2025 across various stacks.) (reports.zksecurity.xyz)

Pentest Tactics for ZK

• Differential Proof Tests: Make sure that when you use the same public inputs but switch up the witnesses, it should fail unless it’s supposed to pass. Don't forget to test those edge cases on field sizes and bit decomposition--this can really help spot issues!
• Gas-Aware Verifier Testing: Keep an eye on those tricky verifier edge cases. You want to avoid any denial-of-service (DoS) attacks that could come from unbounded pairing or multi-proof paths.

---

MEV and mempool exposure: test your transaction path, not only your code

• If your users really care about getting a fair deal with swaps and liquidations, make sure to include private-routing tests and protective measures. It’s a good idea to check your integrations with MEV protection providers that keep things visible and allow for multi-endpoint private RPC routing. You can find more about it here.
• Keep an eye on changes happening in the ecosystem, like what's going on with relayer and relay market consolidation. It’s super important to test your failover paths regularly and make sure your operations can quickly switch providers without putting user protections at risk. You can read more about this here.

---

Monitoring, response, and runbooks: make it measurable

• Real-time anomaly detection: Get on board with the Forta Attack Detector to keep an eye on all the important phases like funding, prepping, exploiting, and laundering. Plus, make sure to tweak your bot subscriptions to fit your protocol addresses. Check out the details here.
• Defender migration: If you’re using Defender Sentinels or Autotasks, it’s time to start planning your move to OpenZeppelin’s open-source Monitor and Relayer before July 1, 2026. Consider this a necessary change for security control in your audits. More info can be found here.
• Alternative monitoring: Set up Tenderly Monitoring for those on-chain event alerts, webhooks, and automated Web3 Actions. This way, you can easily manage responses like “pause” or rate limits. Get started here.

Operational drills will cover the following:

• “Pause-and-patch” tabletop: We'll run through a scenario where we simulate a price-oracle exploit. This will help us check our multisig timelock, the upgrade steps we need to follow, and our timelines for public communications.
• Cross-chain incident: We’ll practice how to stop bridge routes while allowing L1 exits, and we're going to make sure we can publish detailed post-mortems with proof IDs.

---

Sample deliverables 7Block Labs recommends

• We've got a threat model set up that uses SCSVS mapping along with chain‑by‑chain assumptions, like those Arbitrum BoLD exit windows and the dependencies from EntryPoint v0.8 and v0.9. Check it out here.
• Our findings are backed by solid evidence and include clear steps for reproduction. You’ll find things like Foundry invariant seeds, Scribble properties, Slither traces, and AA hash divergence reproductions. Dive into the details here.
• Don't miss our runbooks! They cover everything from an emergency upgrade plan and EntryPoint rotation procedure to a bridge incident SOP and a monitoring migration checklist. Look at all this useful info here.

---

Best emerging practices we see working in 2026

• Make sure you’re using OpenZeppelin Contracts 5.x patterns, like AccessManager, ERC‑7201 namespaced storage, and ReentrancyGuardTransient. It’s important to have audits and tests tied to their security center releases. Check it out here.
• Bring in some oracle correctness into your CI: make sure to enforce checks for publishTime/confidence and set those deviation thresholds. If Slither flags detectors linked to specific oracle ecosystems, it’s a fail for your builds. More info can be found here.
• Treat Account Abstraction (AA) like it really matters: lock down your EntryPoint codehash, verify those 7702 auths during testing, and ensure that bundlers are re-hashing UserOps in a consistent way. Plus, use a bundler stack that supports v0.8+. You can learn more here.
• Keep track of per-rollup finality and proof status: this is key for your app’s user experience and risk disclosures. Make sure they reflect BoLD or any other fault-proof details along with the real exit SLAs. Check out the details at this link.
• Align your work with public standards: map out your findings to OWASP SCSVS and the Smart Contract Top 10 for 2025. Also, don’t forget to keep an eye on EEA EthTrust updates (v3 is expected) to help guide your code quality gates. Get the scoop here.

---

Web3 Anwendungs‑Penetrationstests: Kurzanleitung (für deutschsprachige Entscheider)

• Umfang definieren: Wir schauen uns Smart Contracts an (inklusive Upgrades und Proxies), den AA-Stack (EntryPoint, Paymaster, 7702), Off-Chain-Dienste (Bundler, Relayer), Bridges und Messaging sowie ZK-Komponenten (Circuits, zkVM). Hier gibt's mehr Infos auf GitHub!
• Methodik: Als Grundlage benutzen wir die OWASP SCSVS und die Top 10 von 2025. Für die statischen Analysen setzen wir Slither ≥0.11 ein, zusammen mit Foundry-Invariants und Scribble-Properties. Außerdem gibt's spezielle AA-Tests wie UserOp-Hashing und 7702-Autorisierungen. Wir decken auch L2-Exit und BoLD-Szenarien ab und führen ZK-Sicherheitsprüfungen durch, inklusive der bekannten Fixes von 2025. Mehr Details dazu auf OWASP!
• Betrieb: Wir setzen auf Realtime-Monitoring mit Forta und Tenderly, haben Runbooks für Pausen oder Upgrades vorbereitet und planen die Migration weg von Defender-SaaS bis spätestens 01.07.2026. Hier kannst du mehr darüber lesen!

---

Closing note for decision‑makers

Penetration testing Web3 apps in 2026 is all about questioning your assumptions at every level--whether it’s AA, L2 proofs, bridges, or ZK circuits. It’s way more than just running a scan on your Solidity code. To create a testing scope that really takes today’s risks into account, you’ll want to align with the OWASP SCSVS/Top 10 (2025). Don’t forget to consider changes from Dencun, BoLD, and AA. Plus, make sure to include runbooks and monitoring migrations as part of what “done” looks like. This approach will help you reduce incidents and speed up recovery times. Check out more details here: (scs.owasp.org).

---

Sources and further reading

• Check out the OWASP Smart Contract Top 10 (2025) along with SCSVS/SCSTG. You can dive into it here: (scs.owasp.org)
• Curious about EIP‑4844 (Dencun)? Get the scoop on the blob design and its operational properties over at: (eip4844.com)
• Don’t miss the updates on ERC‑4337 EntryPoint versions 0.8 and 0.9, plus some important notes on AA vulnerabilities. All the details are on: (github.com)
• If you're looking for info on Arbitrum BoLD, including activation dates and documentation, head over to: (docs.arbitrum.io)
• Keep up with the latest in Slither releases, detectors, and references for Foundry invariant testing, as well as Scribble annotations. Get everything you need here: (github.com)
• For insights on LayerZero DVN‑AVS, check out the audit notes, bridge SoK and monitoring research, plus some macro loss trends at: (dedaub.com)
• Discover the highlights from OpenZeppelin Contracts 5.x and learn about the Defender sunset and related docs here: (openzeppelin.com)
• Lastly, if you're interested in the Forta Attack Detector, Tenderly Monitoring, and MEV protection docs, you can check them out at: (docs.forta.network)

If you're looking for a customized proposal that fits your protocol--whether it's an AA wallet, DeFi project, bridge, or zk rollup--7Block Labs has got you covered. We can whip up a detailed test plan in less than a week, complete with clear KPIs and CI integration.