Trusted by 100s of Web3 teams
Penetration Tests Secure More Than Your Code
An audit reads the code. A penetration test attacks the system the code runs in.
$250M+ secured
2-5 week turnaround
Starting at $10k
$250M+ Secured
Exchanges
Perp Dexs
Audits Last 40% Longer
Blockchain penetration testing
A blockchain penetration test is an authorised attack on your running system. Testers take the position of an adversary who wants your users’ funds, and work through whatever route is cheapest: a contract, a signing flow, a frontend dependency, a leaked deploy key, a member of your team.
An audit reads the code. A penetration test attacks the system the code runs in.
Both matter, and they are not substitutes. A protocol that has been audited and never pen tested has proved its contracts behave as written. It has not proved that an attacker cannot reach them.
Why the audit is no longer the whole test
A bank does not test its vault by reading the specification. It hires people to walk in wearing high-vis jackets and see how far they get before someone asks a question. They almost never touch the vault. They are let in through a door that was not on the drawings.
Web3 risk has moved the same way. In 2024, private key compromise was the single largest cause of stolen crypto funds, at 43.8% of the total, ahead of every category of contract exploit (Chainalysis, 2025 Crypto Crime Report). A line-by-line review of a contract cannot see any of that. The contract was fine. The signer was not.
How a penetration test differs from a smart contract audit
Smart contract audit | Penetration test | |
|---|---|---|
| Question it answers | Does this code do what it is supposed to do? | Can someone reach the funds, and how? |
| Target | Source code, on-chain logic, economic design | The whole running system, on-chain and off |
| Method | Line-by-line review plus deterministic static and AST analysis | Adversarial testing against a live or staged environment |
| Evidence | Findings with severity and remediation guidance | A working exploit path, with proof of impact |
| Off-chain surface | Out of scope | The point |
| Output | Public report, badge and on-chain attestation | Report for internal stakeholders, retest on request |
| When | Before a launch, and after material code changes | Before a launch, and periodically while live |
Start with the audit: contract logic is where a single mistake is irreversible, and Fidesium’s manual smart contract audits start at $5,000. Add a penetration test once there is a running system in front of that contract, which by mainnet there always is.
What a blockchain penetration test covers
Scope is agreed in writing before anything is touched.
| Layer | How an attacker reaches it | What testing looks like there |
|---|---|---|
| Deployed contracts | Directly, on-chain, from any address | Live bytecode, upgrade paths, admin functions, emergency controls |
| Wallets and key custody | Signer devices, seed handling, recovery flows | Multisig policy, threshold and signer set, custody and recovery assumptions |
| Signing flows | What a user is actually asked to approve | Blind signing, permit and approval abuse, domain separator and replay handling |
| dApp frontend | The browser, and everything it loads | Dependency and supply chain review, wallet connection, transaction construction |
| APIs and backends | Public and admin endpoints | Authentication, authorisation, rate limits, business logic abuse |
| RPC, nodes and infrastructure | Network reachability | Exposed endpoints, node configuration, key material on hosts |
| Oracles, bridges and integrations | Third-party trust relationships | Price feed manipulation, bridge message handling, dependency failure behaviour |
| Cloud and CI/CD | Repository access, deploy keys, secrets | Pipeline permissions, secret handling, who can push code that reaches production |
| Governance | Proposals, quorum, timelocks | Takeover paths, timelock bypass, delegation and voting power concentration |
The vulnerability classes we test for
The classes that produce real losses, not a checklist of theoretical issues. The on-chain ones map to the publicly maintained OWASP Smart Contract Top 10, so a reviewer can check that themselves.
- Reentrancy: including cross-function and cross-contract variants
- Access control failures: unguarded admin functions, missing role checks, privilege escalation
- Oracle price manipulation: including thin-liquidity and single-source feeds
- Flash loan driven economic attacks: against pricing, collateral and liquidation logic
- Proxy and upgrade flaws: storage collision, uninitialised implementations, unguarded upgrades
- Signature handling: replay, missing nonces, malleability, weak domain separation
- Rounding and share inflation: in vaults and yield accounting
- Front-running and MEV exposure: where ordering changes who gets paid
- Griefing and loss socialisation: patterns that harm users without enriching the attacker
- Governance capture: through delegation, quorum or timelock weaknesses
- Off-chain classes: exposed secrets, weak authentication, supply chain compromise, misconfigured cloud permissions
How the engagement runs
Fidesium is happy to work with teams where they work, email and Telegram friendly to lower friction and speed delivery.
- Scoping call. Within 24-48 hours of your enquiry. We agree the environment, the layers in scope and what is explicitly out.
- Rules of engagement, in writing. Environment, permitted techniques, blackout windows, escalation contacts, stop condition. Nobody tests before this is signed.
- Reconnaissance and threat modelling. We map the real attack surface, usually larger than the one on the architecture diagram.
- Testing. Manual, adversarial, supported by tooling we built ourselves. Deterministic static and AST analysis, not a third party running scans on your code.
- Proof of impact. Every finding arrives with the path that produced it. A finding you cannot reproduce is a finding your engineers will argue with.
- Report and walkthrough. Findings prioritised by exploitability and impact, with remediation guidance written for the people implementing it.
- Retest. Re-run against the fixes.
How a penetration test is scoped and quoted
A pen test is not priced by lines of code. Audit scoping works that way, and we cover it in the smart contract audit pricing and scoping reference. A pen test is priced by surface and time, and four things move the number:
Driver | What increases the quote |
|---|---|
| Layers in scope | Contracts only is the floor. Each added layer (frontend, cloud, wallet custody, governance) adds testing time |
| Environment | A staging environment that mirrors production is cheapest. Testing against production needs tighter rules and more care |
| Depth | A scoped assessment against a named threat model, versus an open-ended red team exercise |
| Retest | Whether re-running against your fixes is inside the engagement or quoted separately |
You get a written scope and a fixed quote before anything starts. No hourly overrun, no scope creep invoice.
When protocols run one
Before mainnet
Founders treat this as a launch-blocking dependency, and they are right to. Bring the scoping call forward rather than the test itself: scope is what determines whether the work fits your window.
Why trust us with this access
A pen test asks for more trust than an audit does. You are granting access to a running system, so who actually does the work is not a detail.
A pen test asks for more trust than an audit does. You are granting access to a running system, so who actually does the work is not a detail.
The core team does the work
When you hire Fidesium you get the engineers who built the tooling, not a subcontractor running someone else’s scanner over your code.
Deterministic tooling, built in house
Static and AST analysis returns the same result on the same input. Not a probabilistic guess presented as a finding.
The work is public
Our audit portfolio names real protocols and publishes the reports: Adrena, Sumvin, Fore Protocol, BlockAsset, Banana Zone, PB&J and SafeDrop. Read one before you speak to us.
A permanent record
Every Fidesium audit is minted as an on-chain NFT, so the record is machine readable, verifiable and cannot be quietly edited later.
$250M+ secured across 110+ contracts audited
We do not sell security as an outcome, and you should be wary of anyone who does. No test proves a system cannot be broken. It tells you what an attacker with a defined budget and window could reach, and what to fix first.
Frequently Asked Questions
What is blockchain penetration testing?
An authorised, adversarial test of a running blockchain system. Testers attempt to reach funds or control through any available route: deployed contracts, wallets and signing flows, the dApp frontend, APIs, RPC endpoints, cloud and governance. Findings come with a reproducible exploit path, not a theoretical risk rating.
How is a penetration test different from a smart contract audit?
An audit reviews contract code line by line and answers whether it does what it is supposed to do. A penetration test attacks the whole running system and answers whether an attacker can reach the funds. An audit is code-facing, a pen test is adversary-facing. Most protocols need both.
Do I need a pen test if my contracts are already audited?
if there is anything in front of the contracts, which by mainnet there always is. In 2024, private key compromise caused 43.8% of all stolen crypto funds, more than any contract exploit category. An audit does not scope keys, signers, frontends or cloud.
How much does a blockchain penetration test cost?
It is quoted from scope rather than sold at a list price, because a contracts-only assessment and a full-stack test are different pieces of work. The drivers are the layers in scope, the environment, the depth of testing and whether a retest is included. Fidesium manual smart contract audits start at $5,000, and a pen test starting at $10,000 is quoted alongside them.
How long does a web3 penetration test take?
The timeline is agreed with the scope, on the scoping call, before the engagement starts. Bring that call forward if you have a launch date, because scope is what determines whether the work fits your window. The average is 3-4 weeks depending on depth of testing.
Do you test on production or staging?
Either. A staging environment that mirrors production is the safer and cheaper default. Production testing runs under tighter rules of engagement, agreed in writing, with a stop condition and named escalation contacts.
Which chains do you cover?
EVM chains are our specialism, and we cover Solana and other major chains. Penetration testing is largely chain agnostic as it deals with your infrastructure and other related non smart contract code. On-chain testing works against deployed bytecode, so repository access is not a prerequisite for the contract layer.
Is the report public?
Your choice. Audit reports are commonly published as a trust signal and ours are. Pen test reports are usually kept internal because they describe live infrastructure, so we can produce a public summary alongside the internal report.