Direct answer: A web3 penetration test covers the infrastructure around your contracts: key management, the bridge and oracle integrations, the APIs, the admin surfaces and the wallet handling. It is a different exercise from a smart contract audit, which reviews the contract code itself. Most real losses come from the first category, not the second.
Where the money actually goes
The headline exploits get described as smart contract hacks, but a large share of blockchain losses trace back to ordinary security failures: a compromised deployer key, an admin function with weak access control, a bridge validator set that could be outvoted, an oracle that could be manipulated, or an exchange employee phished into approving a withdrawal.
Those are penetration testing findings, not contract logic bugs. A contract can be formally verified and still sit behind an upgrade key held in one engineer's password manager.
What a web3 penetration test covers
Key and signer management. Where deployer, upgrade, treasury and validator keys live, who can use them, whether multisig thresholds are meaningful, and what happens when a signer leaves the company.
Admin and privileged functions. Pause, upgrade, mint, fee and parameter functions, and whether the access control on them survives contact with a determined attacker or a compromised account.
Bridges and oracles. The trust assumptions between chains and the price or data feeds contracts depend on. This is where the largest single incidents in the sector have come from.
The off-chain application. The API, the indexer, the front end, and the wallet connection flow. Signature phishing and transaction spoofing happen in the interface, not the chain.
Cloud and CI/CD. Deployment pipelines that can push contract changes, secrets in build systems, and the infrastructure the whole thing runs on.
How this differs from a smart contract audit
A smart contract audit is a line-by-line review of the contract code by specialists in Solidity, Move or whichever language you use, often with formal verification. If your risk is reentrancy, arithmetic or logic flaws in the contract itself, that is what you need and you should hire a firm that does only that.
We are not a smart contract audit shop and will say so. What we test is everything the contract touches and everything that can reach the contract, which is where compliance frameworks and enterprise buyers focus too. Most serious projects end up buying both, from different firms, and that separation is healthy.
Scoping by what you run
An exchange or custodian: key custody, withdrawal approval flows, internal admin tooling, and the insider threat model. Regulators and auditors will care about the same things.
A wallet: key generation and storage on device, the recovery flow, transaction signing and display, and the phishing resistance of what the user is shown before they approve.
A bridge: validator or relayer trust assumptions, message verification, replay protection, and the operational security of whoever holds the keys.
A DeFi protocol: oracle dependencies, admin key control, upgrade paths, and the front end that users actually interact with.
Where compliance comes in
If you are a crypto business selling to institutions, custodying assets, or dealing with a Canadian regulator, testing usually has to produce evidence as well as findings. Scope it so the report can be handed to an auditor or an institutional counterparty, and time it so it sits inside the period a SOC 2 covers.
We deliver testing with our offensive-security partner and scope it to double as evidence. See compliance penetration testing, penetration testing for crypto, and SOC 2 for crypto companies if the institutional side is what is driving this.
How the engagement is actually run
The first hour of scoping is spent on rules of engagement, because this is the one class of testing where a careless action moves real money. Testers need to know which contracts are live on mainnet, which addresses hold value, whether a forked environment exists, and which actions are explicitly forbidden. A responsible engagement does destructive and state-changing work against a fork or a staging deployment, and limits mainnet activity to read-only observation and clearly bounded interaction from an address you provision.
The practical setup we ask for is a mainnet fork pinned to a recent block, a staging deployment of the off-chain stack that mirrors production configuration, test accounts at each privilege tier including one admin-equivalent, and documentation of the role model. Teams that cannot produce a fork usually cannot reproduce their own incidents either, which is itself a finding worth writing up.
From there the work runs in four passes. Reconnaissance builds the map: every deployed address, every proxy and its implementation, every role holder, every externally owned account with privileges, every subdomain, every API endpoint, every RPC provider and every third-party service in the path. Enumeration establishes what each privileged identity can actually do, on chain and off. Exploitation attempts the chains of actions that turn one weakness into control of funds. Reporting ties each finding to the value at risk, not to a generic severity label.
The findings that recur
Across this kind of work, the same issues appear often enough to be worth listing plainly.
Key material in the build system. A deployer private key sitting in a CI environment variable, readable by anyone who can open a pull request that prints the environment. This is the single most direct path from a low-privilege developer account to full control of a protocol, and it is common because deployment scripts were written on day one and never revisited.
Multisig that is not multi anything. A three-of-five configuration where three of the signer keys live in browser extensions on machines administered by the same person, or where two signers are hardware wallets in the same drawer in the same office. The threshold is a number in a contract; the independence is an organisational property, and only one of those gets checked.
Emergency roles that bypass the timelock. Governance is timelocked, everyone can see the delay, and there is a guardian or pauser role that can act instantly and was granted to a single hot key eighteen months ago for an incident nobody remembers.
Orphaned role grants. Enumerate role holders on chain and you routinely find an address belonging to a former contractor, a deprecated relayer, or a deployment script's throwaway account that was never revoked. Nobody removed it because nothing in the deployment process tracks revocation.
RPC and node exposure. A self-hosted node with administrative or unsafe methods reachable, an unauthenticated tracing endpoint, or an internal RPC that trusts network position in a network where anything in the cluster can reach it.
The indexer and its database. The subgraph, the indexer and the analytics database are usually built by a different team under time pressure and end up with weaker authentication than anything else. They frequently hold user address mappings, which is a privacy and targeting problem even when no funds move.
DNS, registrar and front-end hosting. A domain without registrar lock, a hosting account without enforced multi-factor authentication, a stale subdomain pointing at a decommissioned service, or a deploy pipeline that anyone with repository write access can trigger. Users approve whatever the interface tells them to approve, so control of the interface is control of the users. Several of the largest user-facing losses in this sector came through this path rather than through any contract.
Blind signing and approval hygiene. The interface asks for an unlimited token approval by default, or presents a transaction the user cannot meaningfully verify. That is a design finding, and it is the difference between one phished user losing one transaction and losing a wallet balance.
Webhooks and off-chain triggers. Payment confirmations, deposit crediting and withdrawal initiation driven by webhooks with no signature verification or no replay protection. For an exchange or a custodial product this is a direct route to crediting funds that never arrived.
Severity, when the asset is money
Standard severity scoring was built for enterprise software where impact is data exposure or service loss. It maps poorly here. A vulnerability that a generic scoring model calls medium can be catastrophic if it reaches a treasury, and a technically elegant finding can be irrelevant if the contract it affects holds nothing.
Ask for severity expressed with three components: what an attacker gains, what it costs them to attempt it, and the value currently reachable. A report that says "high" without naming the addresses and balances at risk is not giving your engineering team what they need to prioritise. It also matters for the exercise afterwards, because the fix for a finding worth eight figures might be an architecture change while the fix for the same class of finding on an empty contract is a backlog ticket.
The same logic applies to the retest. A finding is not closed because a pull request merged. It is closed when someone re-runs the original attack path against the deployed environment and it fails. Any firm that does not include a retest in the fee is selling you half an engagement, and we cover why in how to vet a penetration testing firm.
What drives the price
Cost tracks surface area and privilege complexity rather than lines of code. The variables that move a quote are the number of chains you are deployed on, the number of distinct applications in front of the contracts, whether you custody keys, the number of privileged roles and signers, whether there is a bridge or an oracle dependency, whether the cloud environment is in scope, and whether you need the report structured as audit evidence.
Custody is the biggest single multiplier. Testing a non-custodial interface is a bounded exercise. Testing a custodial withdrawal path means covering the approval workflow, the segregation of duties between the people who can initiate and the people who can approve, the internal admin tooling, and the insider scenarios, which is a materially larger piece of work. Our penetration testing starts at $1,000 for narrow scopes, and a custodial platform across two chains with cloud infrastructure in scope sits a long way above that. The published starting point exists so you can tell whether a conversation is worth having, not so you can assume a number.
One efficiency worth knowing: if you also need a SOC 2 or an ISO 27001 report, scope the test once so the same engagement satisfies the security requirement, the institutional counterparty and the auditor. Buying three separate tests for three audiences is the most common avoidable spend we see in this sector.
Testing is not the whole programme
A test is a snapshot. The things that decide whether a snapshot stays accurate are operational, and they are worth building whether or not you hire anyone.
A signer lifecycle. Written record of who holds which key, on what device, with what backup, and a documented procedure for rotation when someone leaves. Run it as a drill once a year. Most teams discover during the drill that rotation was never actually possible without a governance vote they cannot pass quickly.
An emergency pause runbook. Who is authorised to call it, how they reach the signers out of hours, how long a quorum realistically takes at 3am on a Sunday, what gets communicated and by whom. Time the quorum. If it takes four hours, that is your true worst-case exposure window and it belongs in your risk register.
Monitoring that watches privileged actions. Alerts on role grants, upgrades, ownership transfers, large withdrawals and unusual oracle deviation, delivered somewhere a human is actually paged. Contract events are the highest-signal log source you have and most teams do not ingest them.
Front-end integrity checks. Registrar lock, enforced multi-factor on hosting and DNS, monitoring for changes to the deployed bundle, and a documented path to take the interface down.
If those need to exist before the pager goes off rather than after, that is what a retainer covers, and how a retainer works sets out the shape of it.
A record of what is deployed. Ask three engineers to list every contract address your organisation controls, on every chain, including test deployments that were never decommissioned. If the lists differ, and they usually do, that gap is your real attack surface. Forgotten deployments are dangerous precisely because nobody monitors them and nobody remembers which keys still hold rights over them. A maintained inventory of addresses, their implementations, their role holders and their current balances takes an afternoon to build and makes every future test cheaper, because the recon phase you would otherwise pay for is already done.
Bug bounty, audit and penetration test are three different purchases
These get conflated in budget conversations and they buy different things. A smart contract audit is deep, time-boxed review of specific code by language specialists, appropriate before a launch or a significant upgrade. A penetration test is breadth across the systems and people around the code, appropriate on a schedule and before a compliance report. A bug bounty is continuous, pays on results, and is excellent at finding what a fixed-window engagement missed, but it will not give you an assurance artefact, it will not test your insider scenarios, and an auditor will not accept it as evidence of a required control.
The order you buy them in matters. A bounty opened before you have done the basics becomes an expensive way to receive findings you already knew about. Testing done immediately before a launch leaves no time to fix anything structural. The useful order is to fix what you already know is broken, test, remediate, retest, then open a bounty and keep it open.
When you should not buy this from us, or from anyone
If you are pre-launch, unfunded, with contracts on a testnet and no infrastructure beyond a repository, a penetration test is premature. Nothing holds value, the architecture will change, and the findings will be obsolete before you deploy. Spend the money on a contract audit closer to launch and on getting key management right from the start, which costs nothing but discipline.
If your real exposure is contract logic, reentrancy, accounting errors or economic design, buy a smart contract audit from a specialist firm and do not let anyone talk you into infrastructure testing as a substitute. We say this to prospects regularly, because we do not do contract audits and pretending otherwise would produce a report that misses the thing that actually kills you.
If a counterparty has simply asked whether you test, and you have never done a single internal review, start cheaper. Enumerate your privileged addresses, revoke what should not exist, put registrar lock and enforced multi-factor on the accounts that control your domain and your hosting, get every key off shared storage, and write down who can move funds. That list costs a week of internal effort and removes a meaningful share of what a first test would have found. Come back for the test once it is done, and you will pay for depth rather than for someone to tell you the obvious.
Where an external test genuinely earns its price is when real value is live, when an institution or a regulator is asking for independent assurance, or when you have changed something structural and need to know what the change reached. If that is where you are, tell us what you run and who is asking, and we will scope it against the audience rather than against a template. If it is not, the honest advice is to wait.
Need the testing done? Penetration testing and vulnerability management, with the retest that proves a finding is actually closed.
Penetration testingOr talk about a retainer