Audit Methodology

How we actually audit your protocol.

A senior-led, four-stage process backed by industry-leading static, dynamic, fuzzing, and formal-verification tooling — and line-by-line manual review by engineers who have shipped production audits for protocols securing over $1B in TVL.

480+Audits Delivered
$1B+TVL Secured
22+Chains Supported
0Junior-Only Reviews

The four-stage process

No black boxes. Every Vibranium engagement follows the same disciplined workflow, with named senior auditors accountable from kick-off to final report.

1Day 0–2

Scoping & Kick-off

We read your repo, model the threat surface, and agree the audit scope in writing.

  • Repo walk-through with your CTO
  • Commit hash locked for review
  • Architecture & trust-boundary diagram
  • Threat model & risk register
  • Timeline & deliverables agreed
2Day 2–N

Manual Review + Tooling

Two senior engineers review every line. Static analysis, fuzzing and formal verification run in parallel.

  • Line-by-line manual review (2 auditors minimum)
  • Slither, Mythril, Aderyn static analysis
  • Echidna + Foundry invariant fuzzing
  • Halmos / Certora formal verification where applicable
  • Daily internal triage of findings
3~Day N+3

Preliminary Report

You receive a written preliminary report with every finding classified, ranked and reproducible.

  • All findings classified Critical → Informational
  • SWC + OWASP mapping per finding
  • Proof-of-concept code for each exploit
  • Concrete remediation guidance
  • 30-min walk-through call with the audit lead
4+5–10 days

Fix Review & Final Report

We review your fixes commit-by-commit and issue the publicly verifiable final report.

  • Commit-by-commit fix verification
  • Regression testing of patched code
  • Public PDF report + GitHub release
  • Security score badge for your site
  • 30 days of post-audit Q&A included

The tool stack we actually run

Tools find shallow bugs fast so our senior engineers can focus their time on the deep architectural ones machines miss. Here is the complete kit that ships with every engagement.

SL
Static Analysis

Slither

Industry-standard Solidity static analyzer. 90+ detectors for reentrancy, access-control, arithmetic, and inheritance bugs.

MY
Symbolic Execution

Mythril

Symbolic execution of EVM bytecode. Catches integer overflow, unchecked calls, and unprotected suicide patterns.

AD
Static Analysis

Aderyn

Rust-based static analyzer with rapid CI integration. Complements Slither with newer detector classes.

EC
Property Fuzzing

Echidna

Property-based fuzzer for Solidity invariants. We write protocol-specific properties and run millions of randomised transactions.

FO
Invariant Testing

Foundry Invariants

Stateful invariant fuzzing with custom handlers. Native to your repo, so findings ship as reproducible Forge tests.

HM
Formal Verification

Halmos

Symbolic testing for Foundry. Proves selected invariants hold across all possible inputs — not just the ones a fuzzer guesses.

CE
Formal Verification

Certora Prover

Industry-grade formal verification for safety-critical protocols. Used selectively where mathematical proofs add value over fuzzing.

MA
Senior Review

Manual Line-by-Line

Two senior engineers reading every line, every branch, every state transition. No tool replaces a human who has shipped production audits.

How we threat-model

Before a single line is reviewed, we build an explicit model of who can attack what. Findings without a credible attacker are noise.

External attacker

Any unauthenticated address calling public functions. We map every entry point, parameter constraint, and state-change side-effect.

Privileged role abuse

Owner, admin, governance, multisig, and time-locked roles. What can each role do today, and what could they do if compromised?

Cross-protocol composition

How the protocol behaves when called by other contracts: flash loans, callbacks, reentrancy across pools, oracle manipulation, MEV.

Economic & game-theoretic

Liquidation cascades, fee griefing, sandwich-resistance, donation attacks, share-inflation, just-in-time liquidity. Solidity-clean ≠ economically safe.

Upgrade & migration

Storage-slot collisions, initializer races, proxy-implementation drift, migration replay. Upgradeable systems get a dedicated review pass.

Off-chain dependencies

Oracles, keepers, relayers, signers, bridges. Anything off-chain is a trust assumption that must be made explicit in the report.

Severity rubric

Every finding is classified using a transparent rubric mapped to industry standards (SWC Registry, OWASP Smart Contract Top 10, CVSS-adapted impact scoring).

SeverityImpact + LikelihoodTypical Examples
CRITICALDirect loss of user or protocol funds. Exploitable by any external attacker without privileged access. High likelihood.Reentrancy draining vaults, signature replay, unauthorised mint, broken access control on privileged functions, oracle manipulation enabling free liquidations.
HIGHLoss of funds under realistic conditions, or full DoS of core protocol functionality. Requires specific but plausible state.Storage-slot collision in upgradeable proxy, share-inflation on first deposit, missing slippage protection, donation attacks on ERC-4626, broken pause guards.
MEDIUMPartial fund loss, predictable griefing, or loss of yield. Either bounded impact or requires a privileged actor to misbehave.Fee griefing, front-running of legitimate user actions, integer truncation rounding in user's favour, incorrect event emission breaking off-chain indexers.
LOWMinor deviation from spec with negligible direct user impact. Best practice failure.Missing zero-address checks, unused storage variables, gas-inefficient patterns, missing reentrancy guards on view-only externals.
INFORMATIONALCode quality, gas optimisation, NatSpec, naming. No security impact.Style inconsistencies, missing NatSpec, gas savings via custom errors, recommendations for upgrading Solidity version.

Sample finding format

Every finding in a Vibranium report follows this exact structure — so your engineers can reproduce, fix, and verify each issue with zero ambiguity.

Finding V-001

Reentrancy in withdraw() allows draining of vault CRITICAL

File: contracts/Vault.sol:142–168
SWC: SWC-107 (Reentrancy)
OWASP: SC02:2025 — Logic Errors
Status: Reported → Fixed in commit 7a2f8c1

Description:
The withdraw() function transfers ETH to the caller via .call{value:}("") before updating the user's share balance. A malicious contract receiving the transfer can reenter withdraw() and drain the vault by repeatedly withdrawing against the same accounted balance.

Proof of Concept:
A Foundry test (test/PoC_Reentrancy.t.sol) demonstrates the attack: deploy Attacker, deposit 1 ETH, trigger attack() which reenters 50× before the share balance is debited, draining 50 ETH from the vault.

Recommendation:
Apply checks-effects-interactions: debit the share balance before the external call. Additionally, add nonReentrant from OpenZeppelin's ReentrancyGuard to withdraw() and any sibling functions that touch user balances.

Vibranium verification:
Fix verified in commit 7a2f8c1. Re-ran PoC test against patched code — attack now reverts with "ReentrancyGuard: reentrant call". Regression test added to the protocol's CI suite.

What you receive

Exact deliverables — no surprises, no upsells.

📄

Preliminary Report

Written PDF after Stage 2, before any fixes. All findings classified.

📘

Final Report

Public PDF with fix verification status, hosted on our CDN and yours.

🏅

Security Badge

Embeddable badge with your security score, linking to the published report.

🧪

Foundry PoC Suite

Reproducible Forge tests for every Critical/High finding.

📞

Walk-through Call

30 minutes with the audit lead to talk you through every finding.

🔁

30-Day Q&A

Post-audit access to the audit team for follow-up questions, included.

Methodology FAQ

The questions protocol CTOs actually ask us before signing.

Who actually does the review?

Named senior engineers with 4+ years of Solidity audit experience. Every engagement is staffed with two senior auditors as primary reviewers. We never use unsupervised juniors and we never use offshore review mills.

How long does a typical audit take?

1,000–3,000 LOC: 1–2 weeks. 3,000–8,000 LOC: 2–4 weeks. 8,000+ LOC or complex DeFi primitives: 4–8 weeks. Emergency audits with 48-hour turnaround are available at a premium — contact us.

Do you use AI or LLMs?

We use LLMs as a triage layer on top of static analysis output to reduce noise, never as the primary reviewer. No finding ships in a report unless a named senior engineer has independently verified it with a reproducible PoC. AI is a force multiplier for our team, not a substitute.

What if you miss something?

No auditor — us, Trail of Bits, OpenZeppelin, Certora — can offer a zero-bug guarantee. What we offer is a transparent process, named-engineer accountability, 30 days of post-audit Q&A, and a discounted re-audit if a Critical issue is discovered in the audited scope within 90 days.

Will you publish the report?

Yes. By default every Vibranium report is published as a public PDF after fix verification — that public verifiability is the whole point. We accept NDA-only engagements at a premium, but we strongly recommend public reports because they compound your protocol's security reputation.

Do you do formal verification?

Yes, selectively. Halmos and Certora are excellent for safety-critical primitives (AMM math, lending accounting, share accounting in vaults) where mathematical proofs add real value over fuzzing. We don't pretend FV is appropriate for every contract — that would be expensive theatre.

Can you audit non-Solidity?

Yes — Rust (Solana, NEAR, CosmWasm, Substrate), Move (Aptos, Sui), Vyper, Cairo (StarkNet), and several Layer-1 native VMs. See our 22+ chains coverage in the homepage stats.

Ready to put your protocol through this process?

Senior-led audit. Public report. Named team. No black boxes.

Request Audit Book a Call