Smart Contract Pentest: Crypto Project Security Audit

What Vulnerabilities Do We Look for in Smart Contracts?

We conduct multi-layer penetration testing of crypto projects that goes far beyond a standard web application pentest plus Slither. It covers smart contracts, infrastructure, frontend, bridges, backend APIs, and social engineering. The Ronin Bridge lost $625M not due to a contract vulnerability — but because 5 out of 9 validator keys were compromised via spear phishing. Our experience shows that an effective pentest must cover all attack vectors.

Pentesting a crypto project requires deep understanding of both Solidity and L2 rollup architecture, consensus mechanisms, and DeFi economics. Without a comprehensive approach, it's easy to miss critical vulnerabilities like oracle manipulation or transaction reorgs. Automated tools find about 30% of issues — the rest require manual analysis. That's why we combine Slither, Mythril, and Aderyn with many hours of code review. Each finding is classified by CVSS; for critical ones, we provide a PoC within hours of discovery. Our portfolio includes over 200 audited projects, including top-10 DeFi protocols by TVL. We test not only contracts but also infrastructure: RPC nodes, bridge relayers, validator key management, and dApp frontend for supply chain compromise. Every component can be an entry point.

Static Analysis of Contracts

The starting point of any contract pentest is automated tools:

# Slither — static analyzer from Trail of Bits
slither . --print human-summary
slither . --detect reentrancy-eth,reentrancy-no-eth,arbitrary-send-eth
slither . --triage-mode

# Mythril — symbolic execution
myth analyze contracts/Vault.sol --solv 0.8.20

# Aderyn — Rust-based analyzer, faster than Slither for large codebases
aderyn .

Automated tools catch low-hanging fruit: incorrect operation order, unused return values, obvious reentrancy. But they rarely find critical vulnerabilities. Manual review uncovers 3 times more issues, and for critical ones — 5 times more.

Manual Contract Analysis

Focus areas for manual review:

Access control: we verify who can call privileged functions, correctness of onlyOwner/AccessControl, absence of backdoors via constructor or initializer.

// Classic mistake: initializer can be called repeatedly
contract VulnerableProxy {
    bool private initialized;

    function initialize(address _admin) external {
        // VULNERABILITY: no check for !initialized
        admin = _admin;
    }
}

// Correct:
function initialize(address _admin) external {
    require(!initialized, "Already initialized");
    initialized = true;
    admin = _admin;
}

Price oracle manipulation: we check if spot prices are used instead of TWAP. A flash loan attack on the oracle can lead to total loss of funds.

// Vulnerable: spot price from AMM pool
function getPrice() external view returns (uint256) {
    (uint112 reserve0, uint112 reserve1,) = pair.getReserves();
    return uint256(reserve1) * 1e18 / uint256(reserve0);
}

// Correct: TWAP via Uniswap V3 oracle
function getTWAPPrice(uint32 twapInterval) external view returns (uint256) {
    uint32[] memory secondsAgo = new uint32[](2);
    secondsAgo[0] = twapInterval;
    secondsAgo[1] = 0;
    (int56[] memory tickCumulatives,) = pool.observe(secondsAgo);
    int56 tickDelta = tickCumulatives[1] - tickCumulatives[0];
    int24 tick = int24(tickDelta / int56(uint56(twapInterval)));
    return OracleLibrary.getQuoteAtTick(tick, 1e18, token0, token1);
}

Signature validation: correct verification of EIP-712 signatures, protection against replay attacks via nonce and chainId.

Economic Attacks

Flash loan attacks on AMM protocols require deep understanding of pool mechanics. We simulate them in Foundry:

// Simulate flash loan attack via Foundry
// forge test --match-test testFlashLoanAttack -vvv

function testFlashLoanAttack() public {
    uint256 flashAmount = 1000 ether;
    vm.deal(address(attacker), flashAmount);

    uint256 priceBefore = target.getPrice();
    attacker.manipulatePool(flashAmount);
    uint256 priceAfter = target.getPrice();
    console.log("Price manipulation:", priceBefore, "->", priceAfter);

    uint256 profit = attacker.exploit();
    attacker.repayFlash(flashAmount);

    assertGt(profit, 0, "Attack should be profitable");
}

Why Pentest of Crypto Project Is Harder Than Normal Web Audit?

We test not only APIs and frontend, but also blockchain node infrastructure, bridge contracts, and validator consensus mechanisms.

Frontend Security

Wallet drainer injection: the most common dApp attack is frontend compromise via supply chain. We check for Subresource Integrity (SRI) hashes, CSP headers, integrity in lockfile. Also look for clipboard hijacking via XSS.

Phishing via typosquatting: registering similar domains. Our audit includes checking monitoring of such domains and DNS alerting.

Infrastructure Audit

RPC endpoint security: we check if RPC is publicly exposed, whether authentication is required, and method whitelisting.

curl -X POST http://node-ip:8545 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_accounts","id":1}'

Private keys and secrets: audit of deploy-key management (HSM, AWS KMS), check .env files in git history, key rotation on offboarding.

Admin panel exposure: find unprotected admin interfaces (Grafana, Jenkins, Kibana), verify MFA and IP whitelist.

Bridge and Cross-Chain Specifics

Bridge contracts are the highest-risk component. Specific checks:

• Replay attack: signature must include chainId and a unique nonce.

// Vulnerable: no chainId in signature
bytes32 hash = keccak256(abi.encode(recipient, amount, nonce));

// Correct: EIP-712 with chainId
bytes32 hash = keccak256(abi.encode(
    BRIDGE_TYPEHASH,
    recipient,
    amount,
    nonce,
    block.chainid
));

• Validator key management: check how many keys need to be compromised. In Ronin Bridge, the effective threshold was 2/2 despite 9 validators. We model such scenarios.
• Finality assumptions: bridge must wait for block finality (for Ethereum: 12+ blocks, for BSC: more).

Audit Stages

What's Included in the Report

Structure of the final report:

For each finding: description, Proof of Concept (code), potential impact, recommendations, status after remediation. Additionally, we provide a checklist of checks and consulting on fixes.

Estimated Timelines

A full pentest takes from 2 to 6 weeks depending on project complexity. Cost is calculated individually — contact us for a project assessment. We guarantee confidentiality and sign an NDA.

Order an audit of your crypto project to uncover vulnerabilities that automated scanners miss. Get security consulting — our engineers with 10+ years of experience will help protect your funds.

How Do We Find What the Compiler Misses?

When a protocol loses $197M through a flash loan attack on a function that auditors reviewed live — it's not an accident. It's a systemic gap in methodology. Our experience shows: vulnerabilities live in a contract for over a year, while the compiler remains silent. We restructured the audit process to catch such cases before deployment.

What Static Analysis Won't Find?

Slither is the standard first tool. It finds reentrancy, integer overflow (in older Solidity versions), improper use of tx.origin, variable shadowing, uninitialized storage. On a real project, Slither produces dozens of warnings, of which critical ones are 0‑2. The rest is informational noise.

Slither won't find logical vulnerabilities. If withdraw correctly checks balance and correctly updates state, but business logic allows double deduction through two different code paths — Slither stays silent.

Mythril uses symbolic execution: builds a graph of all possible execution paths and searches for reachable states violating properties. Works well on isolated contracts. On a protocol of 20 contracts with cross‑contract calls — path explosion, analysis hangs or returns false positives.

Both tools are mandatory as a first pass. But they don't replace manual analysis.

Fuzzing: Where Echidna and Foundry Find Real Bugs

Echidna is a property‑based fuzzer from Trail of Bits. The idea: formulate contract invariants as Solidity functions (echidna_invariant), Echidna generates random call sequences and tries to break the invariant.

Example invariant for a lending protocol:

function echidna_total_assets_ge_liabilities() public view returns (bool) {
    return totalAssets() >= totalLiabilities();
}

Echidna will find a sequence deposit → borrow → liquidate → repay that violates this invariant. You can't build such a case manually — too many combinations.

Foundry fuzzing (forge test --fuzz-runs 100000) is easier to integrate if the team is already on Foundry. Supports stateful fuzzing via invariant tests. In a real project: auditing a vault contract, Foundry fuzzed for 40 minutes and found an edge case where maxWithdraw returned a value larger than actual balance at a specific shares/assets ratio after several donations. Hardhat unit tests missed it — they didn't have that combination of parameters.

Medusa (from Trail of Bits, newer than Echidna) supports corpus‑guided fuzzing and runs faster on large contracts. If the codebase exceeds 5000 lines of Solidity — we look at Medusa.

How Invariants Help Identify Critical Vulnerabilities

Formal verification proves that the contract satisfies specifications for all possible inputs — not for N random ones, but mathematically for all. Tools: Certora Prover, K Framework, Halmos.

Certora works with CVL (Certora Verification Language): write rules and invariants, the Prover translates them into SMT formulas and checks via Z3/CVC5. MakerDAO, Aave, Uniswap use Certora in CI/CD pipeline — every PR is automatically verified.

Limitations: doesn't work with unbounded loops, struggles with hash functions and signature verification. For contracts with simple math (AMM, lending) — excellent. For contracts with arbitrary external calls — difficult to write sufficiently complete specifications.

Formal verification makes sense for contracts that: manage over $50M, are rarely updated, have clearly formalizable invariants. For fast‑iterating products — the cost‑benefit ratio doesn't favor verification.

What Attack Vectors Do Junior Auditors Miss?

Storage collision in proxy pattern. Transparent proxy and UUPS use specific slots for implementation address (EIP‑1967). If an implementation accidentally declares a variable in slot 0 that overlaps with proxy storage — we get silent override. Slither won't catch this if proxy and implementation are in different files.

Read‑only reentrancy. Classic reentrancy guard protects against state changes during recursive calls. But if an external contract reads state via a view function mid‑transaction — guard doesn't help. Years ago, Curve pools became an attack vector precisely through this: an external protocol read get_virtual_price during a reentrancy‑vulnerable state of Curve.

Oracle manipulation via TWAP. Spot price is a standard target for flash loan attack. TWAP is harder to manipulate, but not impossible: on low‑liquidity Uniswap v2 pairs, TWAP can be shifted over several blocks with enough capital. Proper protection: use Chainlink as primary oracle with TWAP as fallback, with deviation threshold check.

Gas griefing on unbounded loop. A function iterates over an array of users. Attacker adds thousands of addresses with zero balances — the function's gas cost rises to the gas limit, making it inaccessible. Protection: pull pattern instead of push, limit array lengths, batch processing with position tracking.

Front‑running on MEV. Transaction is visible in mempool before inclusion in block. MEV bot sees addLiquidity for a significant amount, inserts its own swap before it (sandwich attack). For AMM this is part of the model. For protocols with price functions — require minAmountOut / deadline parameter and its mandatory verification.

Structure of a Full Audit

1. Scope definition and automated analysis (1‑2 days). Fix commit hash, compiler version, list of out‑of‑scope items. Run Slither, Mythril, Aderyn. Triage: separate real critical bugs from false positives. Build contract dependency map.

2. Manual analysis (5‑15 days). Each contract line by line. Special attention: all external and public functions, all transfer/call/delegatecall, all places where state changes before a check or after an external call, all math operations with user inputs. On average, 95% of found vulnerabilities are logical, not technical.

3. Fuzzing and testing (2‑5 days). Echidna or Foundry invariant tests for critical invariants. Fork mainnet tests — verify behavior in real environment with real oracles. For example, in 4 days fuzzing finds on average 3 edge cases not covered by unit tests.

4. Report and mitigation. Report with severity (Critical/High/Medium/Low/Informational), attack vector description, PoC code for Critical/High. Developers fix, auditors perform re‑audit of fixes.

Audit in CI/CD

Common practice for mature protocols: Slither and Aderyn run in GitHub Actions on every PR. Certora Prover — on merge to main. This doesn't replace a full audit before deployment, but catches regressions.

# .github/workflows/audit.yml
- name: Run Slither
  uses: crytic/[email protected]
  with:
    target: 'src/'
    slither-args: '--filter-paths "test|mock|script"'

Audit Tools Comparison

Deliverables

• Full report in PDF with CVSS scores for each vulnerability
• PoC code for all Critical and High (reproducible in test environment)
• Remediation recommendations with code examples
• Re‑audit after fixes (up to two iterations)
• Brief guide for developers on ongoing operation
• Post‑deployment support for 30 days (consultations and incident analysis)

Timeline

Audit of a simple token or NFT contract — 3‑5 business days. DeFi protocol with lending/AMM — 2‑4 weeks. Full stack with multiple protocols, cross‑chain, proxy upgrades — 4‑8 weeks. Re‑audit of fixes — 3‑7 days separately.

Our team has 7+ years of experience in smart contract security, having audited over 100 projects. We guarantee we won't miss any known attack vectors — we use licensed versions of Slither and best fuzzer configurations. Assess your project — we will analyze your code for free and provide a commercial offer within 2 days. Order an audit with quality guarantee and get a discount on re‑audit for repeat customers.