🌳 Advanced ⏱️ ongoing

Solodit — The Audit Report Database

Solodit is the most important research tool in Web3 security. It is an aggregated database of 50,000+ smart contract vulnerability findings from every major audit firm, contest platform, and security research team. Think of it as a search engine for known vulnerability patterns — one that you can query before auditing any protocol to see what similar protocols have been vulnerable to in the past.

What Is Solodit?

Solodit was built by the Cyfrin team to solve a real problem: audit findings were scattered across hundreds of GitHub repositories, PDF reports, and contest platforms. Researchers had to manually search dozens of sources to understand the vulnerability landscape for a specific protocol type. Solodit centralizes all of that.

📚 What Solodit Aggregates

Contest Platforms:
  ✓ Code4rena — All historical contest findings
  ✓ Sherlock — All Watson findings and contest results
  ✓ CodeHawks — Cyfrin's own contest platform
  ✓ Cantina — Competition findings

Audit Firms:
  ✓ Trail of Bits — Published audit reports
  ✓ OpenZeppelin — Audit reports
  ✓ Consensys Diligence — Published reports
  ✓ Spearbit — Public findings
  ✓ Guardian Audits — Public reports
  ✓ Sigma Prime — Published audits
  ✓ ChainSecurity — Public reports
  ✓ Halborn — Public findings

Total database (as of 2024):
  → 50,000+ individual vulnerability findings
  → 1,000+ audit reports
  → Dating back to 2020 (some to 2018)

Updated: Regularly (new findings added as contests complete)
URL: https://solodit.xyz/

The Solodit Interface — Feature by Feature

Keyword Search

🔍 Effective Keyword Search Strategies

Searching for vulnerability patterns:
  "reentrancy"     → All findings tagged as reentrancy
  "oracle"         → Price oracle manipulation bugs
  "flash loan"     → Flash loan attack findings
  "access control" → Missing or incorrect access control
  "integer overflow" → Arithmetic bugs

Searching for protocol-specific patterns:
  "Uniswap V3"    → Findings related to UV3 patterns
  "ERC-4626"      → Vault standard vulnerabilities
  "TWAP"          → Time-weighted average price oracle bugs
  "Merkle"        → Merkle proof vulnerabilities
  "signature"     → Signature validation bugs

Searching for specific code patterns:
  "delegatecall"  → All delegatecall-related findings
  "selfdestruct"  → Self-destruct vulnerabilities
  "block.timestamp" → Timestamp manipulation findings
  "approve"       → Approval-related token bugs

Tips for better search:
  → Start broad: "oracle", then narrow to "on-chain oracle"
  → Combine terms: "flash loan reentrancy"
  → Search function names from the contract you're auditing

Filter System

🗂️ Solodit Filter Options

Severity Filters:
  ● Critical    → Highest severity findings
  ● High        → Significant risk
  ● Medium      → Moderate risk
  ● Low/Info    → Minor issues, informational

Platform Filters:
  ● Code4rena   → C4 contest findings only
  ● Sherlock    → Sherlock findings only
  ● Trail of Bits → ToB audit findings
  ● All others

Protocol Type Filters:
  ● DEX (Decentralized Exchanges)
  ● Lending (Aave, Compound patterns)
  ● Bridge (Cross-chain bridges)
  ● Staking/Yield
  ● NFT
  ● Governance
  ● Stablecoin

Status Filters:
  ● Open
  ● Acknowledged
  ● Fixed

Combining filters for maximum value:
  Example: "reentrancy" + Critical + Lending
  → Shows all critical reentrancy findings in lending protocols
  → Perfect pre-audit research for a lending protocol review

Pre-Audit Research Workflow

The most powerful use of Solodit is not random exploration — it is systematic pre-audit research. Before starting any audit, use Solodit to build a targeted hypothesis list of what bugs are most likely to appear:

🧪 Pre-Audit Research Protocol

You're about to audit: a lending protocol with a custom yield strategy

Step 1: Search for the protocol type
  Query: "lending"
  Filter: High + Critical severity
  Result: Read 10-20 findings → identify the most common patterns

Step 2: Search for specific technology used
  Query: "ERC-4626" (the vault standard)
  Result: Known vault-specific vulnerabilities
  Query: "yield strategy"
  Result: Strategy-specific attack patterns

Step 3: Search for imported contracts
  Protocol imports Chainlink oracle → search "Chainlink"
  Protocol uses Uniswap for pricing → search "Uniswap price"
  
Step 4: Search for patterns you saw in the code
  You noticed a complex reward calculation
  → Search: "reward calculation rounding"
  → Search: "precision loss reward"
  → Read 5 findings → understand the pattern

Step 5: Build your audit hypothesis list
  Based on research: these patterns are most likely present:
  1. Rounding in reward calculation (5 previous findings)
  2. Oracle manipulation via flash loan (8 previous findings)
  3. Missing access control on vault initialization (3 previous findings)
  
  → These become your priority areas during the actual audit

The Audit Checklist Feature

Solodit's audit checklist is a community-maintained list of 380+ security checks. It covers every vulnerability category and is organized by contract type. This is one of the most valuable freely available resources in Web3 security.

✅ Solodit Checklist — How to Use It

Checklist URL: https://solodit.xyz/checklist

Categories covered (sample):
  Access Control:
    ☐ Functions that should be owner-only are not restricted
    ☐ initialize() function can be called by anyone
    ☐ Roles can be granted by unauthorized users
    ☐ Two-step ownership transfer is missing

  Reentrancy:
    ☐ External calls before state updates
    ☐ Missing nonReentrant modifier
    ☐ Cross-function reentrancy via shared state
    ☐ Read-only reentrancy (view functions used in state-changing context)

  Arithmetic:
    ☐ Division before multiplication
    ☐ Unchecked arithmetic with user inputs
    ☐ Type downcast without bounds check
    ☐ Incorrect rounding direction in fee calculations

  Oracle:
    ☐ Price oracle can be manipulated in a single block
    ☐ No staleness check on Chainlink price feeds
    ☐ Oracle returns 0 price not handled
    ☐ Round completeness not verified

  Flash Loans:
    ☐ Invariant can be broken by borrowing and repaying in same tx
    ☐ Token balance used as oracle is manipulable via flash loan
    ☐ Governance vote manipulable via flash loan

How to use during an audit:
  1. Go through checklist item by item
  2. For each item: search the codebase (ctrl+F)
  3. Mark: Not applicable / Checked / Potential issue
  4. Investigate all "Potential issue" items further

Top 10 Most Common Vulnerability Categories

Rank	Category	Approx. Count (Solodit)	Severity Typical
1	Access Control	8,000+	High-Critical
2	Reentrancy	5,000+	Critical-High
3	Integer Overflow / Precision Loss	4,500+	Medium-High
4	Price Oracle Manipulation	3,000+	Critical-High
5	Flash Loan Attacks	2,500+	Critical
6	Incorrect Input Validation	4,000+	Medium-High
7	Logic Errors	6,000+	High
8	Denial of Service	2,000+	Medium-High
9	Signature Replay / Validation	1,500+	High-Critical
10	Front-Running / MEV	1,200+	Medium

Building Your Personal Finding Database

Reading Solodit findings is useful. Actively cataloging and reviewing them is transformative. Here is how to build a personal database that compounds over time:

📝 Personal Finding Database — Setup Guide

Tool: Obsidian (recommended) or Notion

File structure:
/vulnerability-patterns/
  reentrancy/
    simple-reentrancy.md
    cross-function-reentrancy.md
    read-only-reentrancy.md
  access-control/
    missing-onlyowner.md
    unprotected-initializer.md
  oracle/
    spot-price-manipulation.md
    stale-price-feed.md
  ...

For each finding you add, record:
  1. Source: [Solodit URL or report name]
  2. Protocol type: [lending / DEX / bridge / etc.]
  3. Severity: [Critical / High / Medium]
  4. Root cause: [One clear sentence]
  5. Code pattern: [The vulnerable code snippet]
  6. Fix: [The corrected code]
  7. Detection: [What grep/search would find similar patterns?]

Weekly routine:
  Monday-Friday: Read 10 Solodit findings
  Saturday: Add 3-5 best ones to your database
  Sunday: Review 20 old entries (flashcard style)

After 6 months: 500+ patterns catalogued
After 12 months: Pattern recognition becomes automatic

Using Solodit to Improve Your Report Writing

📋 Learning From High-Quality Findings

How to use Solodit to become a better report writer:

Step 1: Find a Critical finding in your target category
  → Filter: Critical + Reentrancy + Lending

Step 2: Read the report carefully, analyzing:
  → How concisely is the root cause stated?
  → How is the impact quantified? (exact amount, percentage)
  → How detailed is the PoC? (pseudocode vs working test)
  → What is the recommended fix?

Step 3: Grade the report quality (1-5 stars)
  5 stars: Clear, concise, has working PoC, quantified impact, fix included
  3 stars: Describes bug but lacks PoC or impact quantification
  1 star: Vague, no evidence, unclear impact

Step 4: Identify what you'd do differently
  → Would you have found this bug?
  → Would your report have been clearer?
  → Is the severity rating justified?

Step 5: Write a "mock report" for a finding you find
  → Before submitting to a contest, write your report in Solodit-quality format
  → Compare your draft to the best reports you've studied

The best auditors write reports that are immediately actionable:
  → Developer reads it and knows exactly what to fix
  → No ambiguity about the severity or the scope of the fix

Alternative Data Sources to Complement Solodit

Source	What It Has	Best For	URL
Rekt.news	Post-mortems of real hacks	Understanding real exploits, not just bug reports	rekt.news
Code4rena GitHub	All historical contest reports	Reading full report context, judge comments	github.com/code-423n4
Sherlock GitHub	All historical contest reports	Same as C4 — different protocol coverage	github.com/sherlock-audit
SWC Registry	Categorized vulnerability types	Academic/reference understanding of categories	swcregistry.io
Spearbit Reports	Elite private firm reports	Seeing what top-tier auditing looks like	reports.spearbit.com
BlockThreat Newsletter	Weekly security incidents	Staying current on emerging threats	substack

The Daily Reading Habit

💡 10 Findings Per Day = Expert-Level Pattern Recognition in 1 Year

The single most effective habit for becoming a better auditor: read 10 Solodit findings every day. It takes 30-45 minutes. Do it for 200 days and you'll have actively analyzed 2,000 real vulnerabilities. After 365 days, 3,650 findings. No CTF, no course, and no single audit can give you this breadth of pattern exposure.

📅 Daily Reading Protocol

10-finding daily routine (30-45 minutes):

Day setup (2 min):
  → Pick a theme: "Today is reentrancy day" or "Oracle day"
  → Filter Solodit to that category + High/Critical

Per finding (3-4 min):
  1. Read the title → predict the bug before reading details
  2. Read the root cause section
  3. Read the code snippet
  4. Read the fix
  5. Ask: "How would I have found this?"

Weekly (15 min Saturday):
  → Add your 3 best findings to your personal database
  → Tag with: category, protocol type, detection method

Monthly (30 min):
  → Review: what new patterns did you learn this month?
  → Which categories do you feel least confident in?
  → Adjust next month's theme schedule

What to RECORD (even for findings you don't add to full database):
  → Just a single note: "Rounding error in borrow rate calculation,
    C4 Compound fork, 2023-11" is enough
  → 200+ of these become a searchable personal index

Common Mistakes Section

⚠️ Mistake #1: Passive Reading Without Active Recall

Reading 10 findings and immediately forgetting them produces almost no learning. After reading a finding, close the page and try to describe the bug from memory. What was vulnerable? What was the exploit? What was the fix? If you can't recall after 30 seconds, reread and try again. This active recall dramatically increases retention.

⚠️ Mistake #2: Only Reading Critical Findings

Critical findings are the most dramatic — but Medium findings are often more instructive. Many Medium findings involve subtle logic errors, precision loss, or edge cases that require deep protocol understanding to spot. These are often the types of bugs you'll actually find in audit contests. Balance your reading across severity levels.

⚠️ Mistake #3: Not Cross-Referencing With Actual Code

When Solodit links to a finding, click through to the original audit report or GitHub issue. Read the full context — the code, the protocol documentation, the judge's reasoning. Findings without context are just trivia. Findings with full context are lessons that transfer to real auditing work.

Summary / Key Takeaways

Feature	How to Use	Value
Keyword Search	Search patterns before auditing	Builds targeted hypothesis list
Severity Filter	Study Critical for impact; Medium for subtlety	Calibrates severity assessment
Protocol Type Filter	Match to protocol you're auditing	Finds relevant analogues quickly
Audit Checklist	Go through 380+ checks systematically	Never miss category of bug
Daily Reading	10 findings/day, active recall	Expert pattern recognition in 1 year
Personal DB	Record findings in Obsidian/Notion	Compounding knowledge base
Report quality	Grade good reports, emulate them	Better contest submissions

🔍

Research Tool

Solodit — Smart Contract Vulnerability Database

→

✅

Checklist

Solodit Audit Checklist — 380+ Security Checks

→

📰

Post-Mortems

Rekt.news — DeFi Hack Analysis

→

💻

GitHub Archive

Code4rena GitHub — All Historical Audit Reports

→

📋

Elite Reports

Spearbit Public Audit Reports

→

📚

Reference

SWC Registry — Smart Contract Weakness Classification

→

← Bug Bounty Platforms Overview Your First Audit: A Step-by-Step Guide →