Blockchain & Web3 Penetration Testing Services

Blockchain Penetration Testing — Blockchain penetration testing is offensive security testing of everything around your smart contracts — nodes, RPC endpoints, APIs, key custody, admin panels, bridges and the dApp front end — simulating a real attacker to find the path into your system that does not go through the contract at all.

What a blockchain penetration testing covers

Contracts are only part of the attack surface. Protocols lose funds through compromised deployer keys, an admin panel with no authentication, a validator node exposing an unauthenticated RPC method, a front end serving a swapped contract address, a CI pipeline that can push to production, or a Discord bot with a wallet attached. None of these appear in a contract audit, and all of them have caused nine-figure losses.

We test the way an attacker works: enumerate what is reachable, find the weakest identity boundary, chain low-severity issues into a real path, and prove the impact. Because the same team reviews your contracts, we look for the crossings a generalist firm misses — an API that can influence an on-chain parameter, an off-chain signer whose message format allows replay, a keeper bot whose failure is profitable to induce.

Vulnerability classes we look for

Exposed and unauthenticated RPC

Admin namespaces reachable from the internet, unauthenticated methods, missing rate limits, and node endpoints that leak mempool or key material.

Key custody and signing infrastructure

Hot wallet key handling, HSM and MPC configuration, multisig thresholds that do not match the stated policy, and signer machines with unnecessary reachability.

Front-end and supply chain

Dependency compromise, unpinned scripts, address substitution, DNS and hosting takeover, and wallet-connect flows that can be manipulated into signing a different payload than displayed.

API and backend authorisation

Broken object-level authorisation, JWT and session flaws, IDOR on user or position data, and endpoints that can move an on-chain parameter without on-chain authorisation.

Off-chain signer and relayer abuse

Signature replay across chains or contracts, missing nonce or domain separation, and permit or meta-transaction flows accepting messages they should reject.

Bridge and cross-chain operations

Validator set assumptions, message replay, proof verification gaps, and the operational path an attacker takes to influence relayers.

Bot, keeper and automation logic

Liquidation and rebalancing bots that can be starved, delayed or front-run, and automation credentials with more privilege than the task requires.

Cloud and CI/CD posture

Over-permissive IAM, secrets in build logs, artefacts deployable by anyone with repository write access, and unreviewed production deploy paths.

In scope

Not in scope unless agreed

How the engagement runs

  1. Scoping and threat modelling

    We fix a commit hash, agree the in-scope contracts and read your architecture docs, then build a threat model: who the actors are, what the trust boundaries are, and which invariants must never break. Nothing is reviewed against assumptions we have not written down.

  2. Manual review

    Line-by-line review by at least two auditors working independently, focused on authorisation, accounting, upgrade paths, external integrations and the gap between what the code does and what the documentation claims it does. Most critical findings come from this phase, not from tooling.

  3. Static and dynamic analysis

    Static analysers appropriate to the language, plus property-based fuzzing and invariant testing to push the system into states no unit test covers. Tooling is used to widen coverage, never to replace the manual pass.

  4. Exploit-path simulation

    Candidate findings are proven on a forked network with a working proof of concept. We report what an attacker can actually do and what it costs them, not a theoretical severity label.

  5. Reporting

    Every finding gets a severity rating, reproduction steps, the affected code, the impact in concrete terms and a specific remediation. You get a draft for discussion before anything is finalised.

  6. Fix review and re-test

    We re-test every remediation against the original proof of concept and check that the fix has not opened a new path. The final report is yours to publish.

What you receive

How we rate severity

SeverityWhat it means
CriticalDirect loss of funds or permanent freezing of assets, exploitable by any actor.
HighLoss of funds or protocol insolvency under realistic conditions, or requiring a privileged actor to misbehave.
MediumBroken protocol behaviour, denial of service, or value leakage that does not directly drain the contract.
LowEdge-case incorrectness with limited impact, or an issue requiring implausible preconditions.
InformationalCode quality, gas efficiency, documentation mismatch and defence-in-depth suggestions.

Pricing

Single token contract: starts from $999, report in 24–48 hours. dApp, GameFi or RWA project: starts from $2,999. DeFi protocol, L2 / rollup, Bridge, ZK circuit, AI agent / MCP: scoped per project after we have seen the code.

Blockchain Penetration Testing: frequently asked questions

How is Web3 penetration testing different from a smart contract audit?

An audit reviews on-chain code. A penetration test attacks everything else: nodes, APIs, keys, infrastructure and the front end. Most protocols need both, because most real incidents involve a component that no contract audit would have looked at.

Do you test against production?

Where possible we work against a staging environment that mirrors production, plus read-only reconnaissance of production. Anything intrusive against live systems happens only inside an agreed window with a rollback plan and a named contact on your side.

What methodology do you follow?

PTES and the OWASP Testing Guide for the web and API surface, OWASP API Security Top 10 for service authorisation, and our own Web3-specific checklist for node, key, bridge and signer surfaces. Findings map to CVSS with a plain-English impact statement.

What do we get at the end?

A report with each finding, its exploit path, evidence, business impact and remediation, ranked by exploitability rather than by scanner score — plus a re-test after you fix, and a debrief call with the testers.

Can you test our bridge?

Yes. Bridges get both halves: the contract and proof-verification review, and the operational review of relayers, validator sets and the keys that authorise messages. Bridge incidents are usually operational rather than cryptographic.

What do you need from us to start an audit?

A repository or contract address, a commit hash to freeze the scope, whatever architecture or spec documentation exists, and a point of contact who can answer design questions. If documentation is thin we will write our understanding of the system back to you and ask you to confirm it — that step alone catches design-level bugs.

How long does an audit take?

A single token contract is 24–48 hours. A typical dApp or mid-sized protocol runs one to two weeks. Large DeFi systems, L2s, bridges and ZK circuits are scoped per project after we have seen the code. We will give you a fixed timeline with the quote, not an estimate that moves.

Is a re-test included after we fix the issues?

Yes. Fix review is part of the engagement, not an upsell. We re-run the original proof of concept against your patched code and confirm the fix has not introduced a new path.

Related security services

Get a fixed quote in 24 hours

Send the repository and a commit hash through the contact form, message @bugtester25 on Telegram, or book a 30-minute scoping call. 200+ protocols audited · $4B+ secured · 0 hacks post-audit. Prefer email? info@safeedges.in.