Web3 Application Testing
Smart contract auditing plus everything around it
On-chain code is public, immutable once deployed, and directly custodies value. That combination means a logic flaw isn't a data breach, it's a withdrawal. We audit the contracts themselves, then test the layers people forget: the RPC and backend infrastructure, and the frontend that constructs the transactions users actually sign. Active testing stays on testnets.
What we cover.
- Smart contracts in Solidity and Vyper
- Deployments across Ethereum, Solana, and Polygon
- Backend APIs and RPC infrastructure
- Frontend interfaces, tested against the OWASP Top 10
- Static and dynamic contract analysis, with active testing confined to testnets
How the engagement runs.
Introduction
A Web3 penetration test is a hybrid assessment of a decentralized application across all three of its layers. The focus usually falls hardest on the contracts, where a flaw leads to irreversible financial loss rather than a recoverable incident. Testing simulates malicious users, external attackers, and network-level actors such as validators.
Frontend
The web or mobile interface users actually interact with and sign from.
Backend (off-chain)
Traditional APIs, servers, and RPC node infrastructure supporting the application.
Smart contracts (on-chain)
The immutable business logic deployed to the chain — Ethereum, Solana, Polygon.
The methodology follows the OWASP Top 10 for the frontend and off-chain components, and smart contract weakness classification for the on-chain code.
Test phases
Planning and scoping
- Objectives — stated as concrete adversary goals: drain the treasury, mint unauthorized tokens, take over governance, or impersonate an administrator.
- Scope.
- Smart contracts — the exact commit hashes to be audited, and the deployed addresses on both testnet and mainnet
- Frontend — the in-scope application URLs
- Backend — API endpoints, and self-hosted RPC nodes where applicable
- Out of scope — the underlying blockchain itself, third-party wallets, and third-party protocols, unless the integration with one of them is specifically the focus.
- Rules of engagement — this is the critical constraint.
- All active exploitation happens on a testnet or a local fork
- Mainnet is off-limits to any exploitative testing, without exception
- Test accounts with testnet funds provided for every user role
- A direct line to the development team for critical findings
Reconnaissance
- Frontend and backend — standard web reconnaissance to map the application, find unlinked paths, and fingerprint the stack; plus OSINT across repositories, whitepapers, developer documentation, and community channels.
- On-chain reconnaissance.
- Block explorers — reading verified deployed source, analysing transaction history and who interacts with the contracts, and identifying every contract in the ecosystem: token, staking, governance
- Automated tooling — an initial static pass over the source to clear the low-hanging findings before manual review begins
Vulnerability analysis
The core execution phase, broken down by component.
- Frontend — the standard web classes, plus Web3-specific failures.
- UI redressing — can the interface be manipulated into getting a user to sign a malicious transaction?
- Insecure wallet interaction — is the app requesting dangerous blanket approvals?
- Data verification — is on-chain event data displayed without being verified first?
- Front-running exposure — does the interface broadcast transactions predictably enough to be exploited?
- Backend — API endpoints tested for the usual classes, RPC node exposure checked (is it public, are administrative modules enabled?), and key management reviewed for private keys or provider API keys committed into code.
- Smart contracts — static analysis, reading every line of the contract source.
- Reentrancy — historically the single most damaging class
- Integer overflow and underflow in older compiler versions
- Access control flaws — missing owner modifiers, wrong visibility
- Insecure delegatecall, where an attacker can hijack the contract's logic
- Business logic — does the maths actually do what the whitepaper claims?
- Oracle manipulation — a safe aggregated price feed, or a single exchange pair that can be moved?
- Transaction order dependency — can someone profit by seeing a pending transaction and front-running it?
- Insecure randomness — deriving randomness from block properties
- Smart contracts — dynamic analysis on a testnet or fork.
- Fuzz testing — thousands of simulated transactions with random inputs, trying to break contract state
- Proof-of-concept scripting — exploit scripts that confirm what static analysis found
- Gas and denial-of-service analysis — loops that could run out of gas and brick the contract
Exploitation
The deliverable here is not a reverse shell — it is a runnable script that proves the exploit.
- Flash loan chain — a single transaction that borrows a large sum, uses it to move an insecure price oracle, exploits the resulting price to drain the protocol, and repays the loan.
- Reentrancy proof of concept — a malicious contract that calls the target's withdraw function, which calls back into it before state settles, draining funds.
Reporting
- Impact quantified financially — the maximum extractable loss stated in concrete terms rather than as a severity label.
- Governance risk — where applicable, whether enough voting power could be minted to unilaterally pass a proposal.
- Systemic risk — whether a flaw could cascade, for instance triggering protocol-wide liquidations.
- Executive summary on business and financial risk, plus a tactical technical report with prioritized findings, the proof-of-concept script as primary evidence, and code-specific remediation.
Remediation and re-testing
- Findings presented to your development team.
- Once fixes are implemented and a new commit hash is provided, we re-audit to validate the vulnerabilities are genuinely gone — before mainnet deployment.
What you get at the end.
Who it's for
Protocol teams and dApp operators preparing for mainnet launch, or securing a protocol already holding value.
Need a scope for this engagement?
Tell us what's in your environment and we'll come back with a scoped plan.