Blockchain and smart contract pentesting: Web3 audit 2026

A smart contract audit is an offensive and defensive exercise on code that, once deployed to a public blockchain, cannot be patched the way a normal web application can. That is the fundamental difference with traditional web pentesting: when a Solidity contract reaches mainnet, the bytecode becomes immutable, anyone in the world can invoke it, the adversaries are automated bots scanning every block for opportunities, and every operation has a gas cost that the attacker is also willing to pay to force certain behaviour. There is no WAF protecting you, no rate limiting you can bolt on afterwards, no free rollback.

This guide covers what Web3 pentesting is, what typical stack it audits, the most exploited vulnerabilities in smart contracts and DeFi, the historical cases any auditor should know, the methodology, the usual tooling and how it fits the emerging European regulatory framework with MiCA and DORA.

Smart contract audit versus web pentesting

A classic web pentest evaluates an application running on servers you control. If a bug is found and exploited, in the worst case you restore backup, rotate credentials and ship a patch within hours. In Web3 the rules change:

• Post-deployment immutability. Bytecode deployed to mainnet cannot be modified. Upgradeable proxy patterns exist, but they introduce their own attack surface. A critical bug in a non-upgradeable contract is only mitigated by abandoning the contract and migrating state to a new one, with all the complications of user communication and potential attacks during the migration.
• Gas economics. Every operation costs gas, and the attacker also pays it. That introduces unique vectors: griefing through gas consumption, DoS by blocking functions with expensive loops, race conditions where the attacker can pay more gas to execute first (front-running, MEV).
• Automated 24/7 adversaries. As soon as a transaction enters the mempool, bots analyse it within milliseconds looking for value extraction opportunities or vulnerabilities. The window between discovering a bug and mass exploitation is measured in seconds, not days.
• Composability as an attack vector. Your contract interacts with other third-party contracts that can change behaviour, integrate in unforeseen ways, get compromised, or be specifically built to attack you. The attack surface includes protocols that did not even exist on deployment day.
• Total transparency. All bytecode, all storage, all transactions are public. The attacker has complete access to your logic from the first block, while you cannot see who is studying your contract until they strike.

A smart contract on mainnet is code running hostile by default: every account in the world can invoke it, every bot is reading it, every bug is an open invoice until you migrate state. The audit is not optional, it is the only defence before deployment.

Typical Web3 stack under audit

The Web3 ecosystem is not a single blockchain. When we talk about Web3 pentesting, the usual platforms and components are:

• EVM-compatible blockchains. Ethereum is the reference, but most audits also cover EVM chains like Polygon, BNB Smart Chain, Arbitrum, Optimism, Base, Avalanche C-Chain. They share language and tooling, but they differ in gas costs, finality and validator assumptions.
• Solidity as the dominant language. The recommended version in 2026 is Solidity 0.8.x or above, which includes native overflow checks. Legacy contracts in 0.6 or 0.7 still appear and need special treatment. Vyper shows up in protocols like Curve, with its own bug set.
• Wallets as user entry point. MetaMask, Rabby, hardware wallets like Ledger or Trezor, multisig wallets like Safe (formerly Gnosis Safe). Any audit affecting signing UX touches this stack.
• Oracles. Chainlink is the reference for price feeds, but alternatives exist (Pyth, RedStone, API3) and protocol-specific oracles that each project can implement poorly. Almost every recent serious DeFi attack has involved oracle manipulation.
• DEXs and AMMs. Uniswap V2 and V3, Curve, Balancer, PancakeSwap. The AMM maths becomes an attack vector when a protocol derives prices directly from spot.
• Cross-chain bridges. Wormhole, LayerZero, Axelar, Hop, Stargate. They concentrate enormous TVL and have been protagonists of the sector's largest hacks.
• DeFi application layer. Lending protocols (Aave, Compound), stablecoins (DAI, frax, crvUSD), perpetual derivatives, liquid staking, restaking.
• Frontends. React/Next webapps that sign transactions against the wallet. Compromising the frontend (DNS hijack, malicious npm dependency) is a documented real vector.

A Web3 pentest can be limited to contracts, or also cover frontend, oracles, node infrastructure, admin keys and upgrade operations. Define scope before starting.

Top 10 smart contract vulnerabilities

These are the categories any professional auditor covers by default in Solidity. Documented by SWC Registry, OWASP Smart Contract Top 10 and bases like Code4rena findings.

1. Reentrancy

The DAO foundational bug in 2016. A contract calls externally before updating its internal state, and the called contract invokes the original function again, draining funds in a loop. The Checks-Effects-Interactions (CEI) pattern and OpenZeppelin's ReentrancyGuard are the standard mitigation. Cross-function and cross-contract variants still appear.

2. Integer overflow and underflow

Mitigated by default in Solidity 0.8.x, which reverts on overflow. Legacy contracts in 0.6 or 0.7 without SafeMath remain vulnerable. It also applies when unchecked is used explicitly for gas optimisation, where the auditor must manually validate that the assumption holds.

3. Oracle manipulation

When a contract derives price from a spot AMM or a single-block manipulable source, an attacker with a flash loan can move the price temporarily, execute the affected logic (unfair liquidation, mint at inflated price) and revert the movement. Mitigation is using robust TWAPs, aggregated oracles like Chainlink with heartbeat and deviation thresholds, and never assuming a spot price is safe.

4. Front-running and MEV

The mempool is public. An attacker observes a profitable transaction, copies parameters, pays more gas and executes first. Variants: sandwich attack on DEXs, competitive liquidations, NFT sniping. Partial mitigation uses commit-reveal schemes, batched auctions, or private relays like Flashbots Protect.

5. Signature replay

A message signed off-chain (EIP-712 typed data, meta-transactions) that executes on-chain. If the signature does not include nonce, chainId or domain separator, it can be replayed on another chain or in the same contract. Critical in bridges, gasless transactions, ERC-20 permits.

6. Broken access control

Administrative functions without onlyOwner modifier, badly defined roles, tx.origin used instead of msg.sender, transferable ownership without verification, contracts that fail to implement the checks their documentation promises. One of the most frequent findings in audits.

7. Delegatecall abuse

delegatecall executes code from another contract in the caller's context. If the called contract can be controlled by an attacker, that attacker can arbitrarily modify the storage of the origin contract. Cause of the second Parity hack in 2017. Critical in poorly implemented upgradeable proxies.

8. Timestamp manipulation

block.timestamp can be adjusted by validators within a margin. Using timestamps as entropy source or as exact time measure in financial logic opens the door to manipulation by the block producer.

9. DoS and gas griefing

Functions that iterate over user-controlled arrays can stall when the array grows. Paying multiple recipients in a loop can deadlock the contract if one of them rejects the transfer. Push payments versus pull payments.

10. Flash loan attacks

Atomic uncollateralised loans that allow the attacker to move massive capital in a single transaction. They are not an attack on their own, they are an enabler. Combined with oracle manipulation, token-voted governance, or AMM maths errors, they have caused losses of hundreds of millions.

Historical cases without glamourising

The sector carries public incidents that any auditor studies to recognise patterns. We do not review them for spectacle, we review them because the same bug families keep appearing:

• The DAO (June 2016). Reentrancy in a decentralised investment fund. Estimated losses around 60 million USD at the price of the moment. Triggered the hard fork that split Ethereum and Ethereum Classic.
• Parity Multisig (July and November 2017). Two separate incidents. The first, theft via bug in initWallet. The second, accidental fund freezing when a user invoked suicide() on the shared library. Combined losses in hundreds of millions USD at the valuation of that time.
• Ronin Bridge (March 2022). Compromise of validator private keys. Reported losses around 600 million USD. It was not a smart contract bug, it was key operations, a reminder that audit scope must cover more than code.
• Nomad Bridge (August 2022). Bug in message verification function that allowed anyone to copy and modify legitimate transactions. The hack became mass looting when other users copied the technique observed in the mempool.
• Curve Finance (July 2023). Bug in specific Vyper compiler versions that broke reentrancy protection. Affected pools with reported losses around 70 million USD. A reminder that the toolchain is also attack surface.

Always verify figures and dates against primary sources (Rekt News, official protocol post-mortems) before citing them in reports.

Web3 audit tooling

The ecosystem has mature tools for static, symbolic and fuzzing analysis. Combining them is standard practice.

• Slither. Solidity static analysis developed by Trail of Bits. Detects known vulnerability patterns. Fast, CI-integrable, mandatory baseline.
• Mythril. Symbolic analysis that explores execution paths and looks for property violations. Slower than Slither but finds different bugs.
• Echidna. Property-based fuzzer, also from Trail of Bits. You define invariants the contract must always satisfy and Echidna tries to break them.
• Foundry. Rust testing framework, a modern replacement for Truffle/Hardhat for many auditors. Allows native fuzzing in tests (forge test with random arguments) and mainnet forking to reproduce real contexts.
• Manticore. Another symbolic execution tool, useful when Mythril falls short.
• Halmos. More recent symbolic testing, integrates with Foundry and is practical for property verification without writing everything in Coq or similar.
• Tenderly. Simulation and transaction debugging platform, useful for reproducing exploits step by step.
• MythX and SaaS services. They exist, contrast results with open source tooling.

No single tool replaces manual code review. The typical process combines at least Slither, Foundry tests with fuzzing, and expert human review.

Audit methodology

A serious audit follows a recognisable structure, regardless of the firm:

1. Reconnaissance. Reading documentation, whitepapers, architecture diagram, threat model if it exists. Identifying protocol invariants (what must always hold).
2. Manual code review. Line-by-line reading of in-scope contracts. Annotation of suspicious areas. This phase finds most logical bugs that tooling misses.
3. Automated static analysis. Full Slither run, findings review, false positive triage.
4. Symbolic analysis. Mythril or Manticore on critical functions.
5. Property-based fuzzing. Echidna and/or Foundry fuzz tests over defined invariants. Reasonable minimum coverage (millions of executions per invariant).
6. Economic analysis. For DeFi protocols, model incentives. What if an actor controls X% of governance token, what if an attacker can manipulate the oracle by X bps, what if liquidators do not show up.
7. Formal verification when risk justifies it. Certora, Halmos, writing specs in TLA+. Expensive in time but indispensable for critical components like bridges or sizeable stablecoins.
8. Report. Findings classified by severity (critical, high, medium, low, informational), with reproducible PoC and concrete recommendation.
9. Re-audit after fixes. The team applies fixes, the auditor verifies they introduce no new bugs.

DeFi specifics

DeFi protocols add their own vectors on top of the generic Solidity bugs.

• AMM maths. Curve, constant product, stableswap formulas have edge cases with low liquidity, extreme slippage or fee-on-transfer tokens. Audit must mathematically model invariants.
• Oracle TWAP. Time-weighted averages mitigate spot manipulation but can be tricked in long windows with enough capital. Verify the window used and the manipulation cost.
• Liquidation logic. Who can liquidate, under what conditions, with what incentive, what if nobody liquidates. Cancelled or front-run liquidations are a documented vector.
• Governance attacks. Whoever accumulates enough tokens can pass malicious proposals. Timelocks, minimum quorum, emergency multisig mitigate but do not eliminate the risk. Cases like Beanstalk 2022 showed governance attacked via flash loan.

Bridges and cross-chain

Bridges concentrate extremely high TVL and are responsible for the sector's largest hacks. Amplified risks:

• Distributed trust. Almost all current bridges depend on an external validator set or on a cryptographic puzzle that validates proofs across chains. Compromising that set compromises the funds.
• Messages and signatures. Cross-chain message verification is a frequent place for bugs (Nomad).
• Key management. The keys that sign transactions on one chain to release funds on another are a direct target (Ronin).
• Finality assumptions. If the source chain reverts after sending a message, the destination chain has already released. Attacks exploiting block reorganisations are documented.

A serious bridge audit covers code, key operations, monitoring and response plan.

Hardening

Good practices for production protocols:

• OpenZeppelin contracts as a base. They standardise ERC-20, ERC-721, AccessControl, Ownable, ReentrancyGuard. Reusing audited components reduces surface.
• Checks-Effects-Interactions (CEI) pattern. Validate everything, change state, call out. In that order.
• ReentrancyGuard on functions that call externally and modify state.
• Multisig for administrative functions. Safe (Gnosis Safe) is the de facto standard. Recommended threshold of 3 of 5 minimum for serious protocols.
• Timelocks for upgrades and parameter changes. Gives users a window to exit if a proposal is malicious.
• Upgradeable proxy patterns carefully. UUPS, transparent proxy, beacon. Each has its risks: storage collision, initializer abuse, unprotected upgradeTo function.
• Circuit breakers and pause. Ability to pause critical functions in emergency, with multisig holding the power and with limits on abuse (no indefinite pause that freezes funds).
• Exposure limits. Caps per user, per block, per day. Limit the maximum loss of an exploit before detection.
• Bug bounty programmes. Immunefi as the standard platform, with bounties proportional to TVL at risk.

Regulatory fit

The European framework for digital assets and crypto services is consolidating:

• MiCA (Markets in Crypto-Assets Regulation). EU regulation now in force, regulates the issuance of crypto assets, stablecoins (ART and EMT) and crypto-asset service providers (CASP). It does not directly regulate DeFi smart contracts, but it does impose obligations on entities that custody, exchange or advise on crypto assets in the EU.
• DORA applicable to CASP. Crypto-asset service providers authorised under MiCA can fall within DORA scope, with obligations on ICT risk management, digital operational resilience testing and notification of serious incidents. For relevant CASPs, pentests of the smart contracts they operate are required evidence.

If your protocol operates in the EU or has EU users, review the specific fit with legal counsel before mainnet.

Frequently asked questions

Is it safe to upgrade a smart contract once deployed?

Only if you deployed it under a properly implemented upgradeable pattern (UUPS, transparent proxy, beacon) and the upgrade is governed by multisig with timelock. The upgrade process is attack surface in itself: storage collisions, initializer abuse, unprotected admin functions. A serious protocol audits both the implementation contract and the upgrade flow.

How much does a smart contract audit cost in the market?

It varies a lot with scope and complexity. Indicative audits can range from five-digit USD figures for simple contracts to six or seven-digit USD figures for large DeFi protocols with formal verification. Platforms like Code4rena offer a competitive audit model with public budgets. Request several proposals and compare methodology, not just price.

Is formal verification mandatory?

It is not mandatory by general regulation, but it is highly recommended for critical components like bridges, sizeable stablecoins, liquidation logic or governance modules. It is expensive in time, requires specialised personnel and is most effective when the protocol spec is well defined from design.

Do you need a bug bounty after mainnet?

Yes, and it should be permanent. Platforms like Immunefi manage bounties with scale proportional to TVL. A serious bug bounty pays for critical findings in six USD digits or higher, which makes it economically rational for a researcher to report rather than exploit.

Is there insurance for DeFi protocols?

Yes, platforms like Nexus Mutual, Sherlock or InsurAce offer cover. Policies have exclusions, prior audit requirements and usually do not cover economic or oracle errors. They do not replace the audit, they complement it.

Will MiCA change the sector?

MiCA is already in force and is changing the sector in the EU, especially on stablecoins and service providers. The pure DeFi part remains in a regulatory grey zone. Expect new ESMA guidelines and possible extensions of the regulation over the coming years. Keep active legal monitoring if you operate in the EU.

Related resources

• Web application penetration testing: complete guide
• API penetration testing for REST and GraphQL
• Banking cybersecurity and DORA for financial entities
• Top 10 pentesting tools 2026
• What is PKI: Public Key Infrastructure

Web3 audit with Secra

At Secra we cover Solidity smart contract audits, DeFi architecture review, protocol economic analysis and pentesting of the frontends and oracles surrounding your contract. We combine manual code review with Slither, Foundry fuzzing and Mythril, and we escalate to formal verification when risk justifies it. We deliver a report with reproducible findings, concrete recommendations and re-audit after fixes.

If your protocol is going to mainnet or it is already in production and needs review, write to contacto@secra.es or schedule a call from the contact page. We review scope, timelines and proposal without commitment.