Crypto Security Audit Checklist: The Complete 2026 Guide

In 2026 alone, DeFi protocols lost $2.1 billion to exploits that could have been prevented with proper security audits. Yet according to DeFiLlama data, over 40% of protocols with total value locked (TVL) above $10 million have never undergone a professional security audit.

The signal in crypto security is clear: audited protocols experience 94% fewer critical exploits than unaudited ones, per CertiK’s 2025 Security Report. But the noise is deafening — marketing claims of “audited and safe” protocols that still get drained within weeks.

This comprehensive crypto security audit checklist breaks down exactly what to verify before investing in any DeFi protocol, smart contract, or blockchain project in 2026. We’ll cover what institutions look for, which red flags cost investors millions, and how to read security audits like a professional.

What Is a Crypto Security Audit?

A crypto security audit is a systematic review of a blockchain protocol’s code, infrastructure, and operational security to identify vulnerabilities before malicious actors can exploit them. Think of it as a comprehensive health check for smart contracts and DeFi protocols.

According to CertiK data, the average professional audit costs between $50,000 and $250,000 depending on code complexity. Yet a single critical vulnerability can drain tens of millions in minutes — the 2023 Euler Finance exploit resulted in $197 million in losses from a single reentrancy vulnerability that should have been caught in testing.

Types of security audits:

1. Smart contract audits — Code-level review of on-chain logic and vulnerabilities
2. Infrastructure audits — Server, wallet, and operational security assessment
3. Economic audits — Tokenomics, game theory, and incentive mechanism analysis
4. Penetration testing — Active exploitation attempts by white-hat hackers

The most comprehensive protocols undergo all four types before mainnet launch.

Why Security Audits Matter: The Data

The numbers tell a stark story about the importance of security audits in crypto:

Source: CertiK Security Report 2025, DeFiLlama exploit database

Case study: Compound vs Mango Markets

Compound Finance has undergone 6 professional audits since 2020 and maintains $3.2 billion in TVL with zero critical exploits. Mango Markets, which had only a single audit covering 40% of its codebase, lost $110 million to a price oracle manipulation attack in 2026.

The difference? Compound’s multi-auditor approach caught 23 medium-to-high severity issues before they could be exploited. Mango’s single audit missed the oracle vulnerability that eventually drained the protocol.

For traders evaluating protocols, security audit quality directly correlates with capital safety. As we discuss in our guide to best DeFi protocols 2026, audit history is one of the top three factors institutional investors evaluate.

The Complete Crypto Security Audit Checklist

Use this comprehensive checklist when evaluating any crypto project, DeFi protocol, or smart contract before investing:

1. Smart Contract Code Security

Core verification items:

• [ ] Multiple professional audits completed — At minimum 2 independent auditors from reputable firms
• [ ] Audit reports publicly accessible — Full reports, not just summaries
• [ ] All critical/high severity issues resolved — Check remediation status
• [ ] Code matches deployed contracts — Verify on Etherscan/block explorer
• [ ] Open-source and verified — Source code published and verified on-chain
• [ ] Formal verification performed — Mathematical proofs for critical functions
• [ ] Bug bounty program active — Minimum $100K+ rewards for critical bugs

Red flags to watch for:

• Audit completed but critical issues marked “acknowledged” rather than “fixed”
• Code deployed differs from audited version
• Audit performed by unknown firm with no track record
• Audit report dated more than 12 months before deployment
• Private or closed-source critical components

What the data shows:

According to Quantstamp’s 2025 audit database, the average professionally audited smart contract contains 3.7 medium-severity issues and 0.8 high-severity issues before remediation. Protocols that skip remediation have 12x higher exploit rates.

2. Auditor Reputation and Quality

Not all audit firms provide equal security assurance. The quality of the auditor matters as much as the audit itself.

Top-tier audit firms (2026 rankings by exploit prevention rate):

1. Trail of Bits — 98.3% exploit prevention rate, average 6-8 week audit timeline
2. OpenZeppelin — 97.1% prevention rate, specializes in token standards
3. CertiK — 96.4% prevention rate, largest audit volume
4. Quantstamp — 95.8% prevention rate, strong DeFi focus
5. Consensys Diligence — 95.2% prevention rate, Ethereum ecosystem focus

Verification checklist:

• [ ] Auditor has 50+ completed audits — Check their public portfolio
• [ ] Auditor specializes in relevant technology — Ethereum, Solana, Layer 2, etc.
• [ ] Previous audits available for review — Public track record accessible
• [ ] No conflicts of interest — Auditor not invested in the project
• [ ] Follow-up audits after major upgrades — Ongoing security relationship

Case study: In 2026, a protocol promoted a “security audit” from an unknown firm with only 3 previous audits. The protocol was exploited for $8.2 million within 30 days of launch. The vulnerability was a basic reentrancy attack that any top-tier auditor would have caught.

Compare this to best smart contract auditors 2026, where we break down the track records and specializations of leading audit firms.

3. Code Architecture and Design Patterns

Even audited code can be insecure if it uses risky design patterns or outdated architecture.

Security architecture checklist:

• [ ] Follows established standards — ERC-20, ERC-721, ERC-4626 for applicable contracts
• [ ] Uses battle-tested libraries — OpenZeppelin, Solmate, or equivalent
• [ ] Implements access controls — Role-based permissions for admin functions
• [ ] Includes emergency pause mechanisms — Circuit breakers for detected attacks
• [ ] Upgradeable contracts use secure patterns — Transparent proxy or UUPS pattern
• [ ] External calls handled safely — Checks-Effects-Interactions pattern followed
• [ ] Oracles properly secured — Multiple data sources, manipulation resistant

Red flags in architecture:

• Custom implementations of standard token logic (unnecessary risk)
• Admin keys controlled by single wallet (centralization risk)
• No timelocks on critical parameter changes
• Reliance on single oracle without fallback
• Complex proxy patterns that obscure logic
• Excessive use of delegatecall or low-level calls

Oracle security example:

The Mango Markets exploit leveraged weak oracle design. The protocol relied on a single price feed that the attacker manipulated through large trades. Protocols like Aave use Chainlink’s decentralized oracle network with multiple data sources and deviation thresholds — a pattern that prevented similar attacks.

4. Economic and Game Theory Audits

Code security alone isn’t enough. Economic exploits don’t require code vulnerabilities — they exploit incentive misalignment and tokenomic design flaws.

Economic audit checklist:

• [ ] Tokenomics professionally reviewed — Economic security audit completed
• [ ] Inflation/deflation mechanics analyzed — Long-term sustainability verified
• [ ] Liquidation mechanisms stress-tested — Handles extreme market conditions
• [ ] Flash loan resistance verified — Attacks simulated and mitigated
• [ ] Game theory models built — Rational actor incentives aligned with protocol health
• [ ] Market manipulation scenarios tested — Price impact, sandwich attacks analyzed

Critical economic vulnerabilities:

According to Gauntlet’s 2025 DeFi Risk Report, 31% of DeFi exploits in 2026 were economic attacks rather than code vulnerabilities:

• Flash loan attacks: Borrow massive capital, manipulate prices, profit, repay — all in one block
• Oracle manipulation: Exploit price feed delays or thin liquidity
• Liquidation cascades: Trigger mass liquidations that drain protocol reserves
• Governance attacks: Accumulate voting power to change protocol parameters

Example: Beanstalk lost $182 million in 2026 to a governance attack. The attacker used a flash loan to buy enough voting tokens to pass a malicious proposal and drain the treasury. The code worked exactly as designed — the economic model was flawed.

For strategies on evaluating tokenomics, see our best governance tokens 2026 guide.

5. Infrastructure and Operational Security

Smart contracts are only part of the security equation. Infrastructure vulnerabilities can be just as catastrophic.

Infrastructure security checklist:

• [ ] Admin keys use multi-signature wallets — Minimum 3-of-5 or higher threshold
• [ ] Hardware security modules (HSM) protect keys — Not stored on cloud servers
• [ ] Timelocks on critical functions — 24-48 hour minimum for parameter changes
• [ ] Monitoring and alerting systems active — Real-time anomaly detection
• [ ] Incident response plan documented — Clear procedures for exploit scenarios
• [ ] Insurance coverage in place — Protocol-level or integrated coverage
• [ ] Regular penetration testing — Quarterly minimum for high-TVL protocols

Multi-signature wallet standards:

Top protocols use the following multisig configurations:

• Gnosis Safe on Ethereum/EVM chains
• Squads on Solana
• Minimum 4-of-7 signers for protocols with >$100M TVL
• Geographic distribution of signers across jurisdictions
• Hardware wallet requirements for all signers

Case study: Ronin Bridge (Axie Infinity) lost $625 million in 2026 because only 5 of 9 validator keys were compromised. A properly configured 6-of-9 multisig with geographic distribution would have prevented the attack.

Compare with our crypto self custody guide for individual security best practices.

6. Testing and Formal Verification

Comprehensive testing catches vulnerabilities audits might miss.

Testing requirements checklist:

• [ ] Unit test coverage >95% — All functions tested independently
• [ ] Integration tests cover cross-contract interactions — Real-world scenarios simulated
• [ ] Fuzz testing performed — Random input generation to find edge cases
• [ ] Formal verification for critical logic — Mathematical proofs of correctness
• [ ] Mainnet fork testing — Simulations on production state
• [ ] Continuous integration/deployment (CI/CD) — Automated testing on every change

Formal verification explained:

Formal verification uses mathematical proofs to guarantee smart contract behavior under all possible inputs. While expensive and time-consuming, it provides the highest security assurance.

Protocols using formal verification (2026):

• Maker DAO: Formal verification on core vault logic
• Uniswap V3: Invariant testing and formal proofs on concentrated liquidity math
• Compound III: Formal verification on interest rate calculations

According to Runtime Verification data, formally verified contracts have a 99.7% lower exploit rate than audited-only contracts.

7. Oracle and External Dependency Security

Many DeFi exploits target the weakest link: external data feeds and dependencies.

Oracle security checklist:

• [ ] Multiple independent oracles used — No single point of failure
• [ ] Price deviation thresholds set — Circuit breakers for abnormal price moves
• [ ] Heartbeat monitoring active — Stale data detection
• [ ] Fallback oracles configured — Automatic switchover capability
• [ ] TWAP (Time-Weighted Average Price) implemented — Manipulation resistance
• [ ] Oracle-free alternatives considered — On-chain AMM pricing where appropriate

Chainlink integration best practices:

The leading oracle provider Chainlink recommends:

• Use multiple price feeds for correlated assets
• Implement freshness checks (data age limits)
• Set deviation thresholds appropriate to asset volatility
• Monitor oracle reputation scores on-chain
• Have emergency pause for oracle failures

Data dependency risks:

Beyond price oracles, protocols depend on external contracts and APIs:

• External protocol risk: Integration with protocols that haven’t been audited
• API dependencies: Off-chain data sources that could fail or be manipulated
• Cross-chain bridges: Message passing between chains introduces new attack vectors

The 2022 Nomad Bridge exploit ($190M loss) resulted from a verification bug in cross-chain message passing. The code was audited, but the complexity of cross-chain communication introduced edge cases.

8. Access Controls and Permissions

Centralization and admin privileges are often the most overlooked security risks.

Permission audit checklist:

• [ ] Role-based access control (RBAC) implemented — Clear separation of privileges
• [ ] Privilege escalation impossible — Lower roles can’t gain admin access
• [ ] Admin functions time-locked — 24-48 hours for critical changes
• [ ] Multi-signature required for all privileged actions — No single points of control
• [ ] Emergency pause limited in scope — Can’t be used to steal funds
• [ ] Renounce ownership considered — Protocols trending toward full decentralization

Common permission vulnerabilities:

• Owner can rug pull: Admin functions allow draining user funds
• Upgradeable without notice: Code can be changed instantly
• Emergency pause abuse: Pause feature could prevent withdrawals indefinitely
• Hidden admin keys: Undisclosed multisig or timelock parameters

Transparency standards:

Leading protocols publish:

• Real-time multisig signer identities (where legal)
• Timelock queue visibility (pending governance actions)
• Admin transaction history (all privileged actions logged)
• Governance voting records (who voted for what)

MakerDAO sets the standard with fully transparent on-chain governance, published multisig signer identities, and 48-hour timelocks on all critical changes.

9. Upgrade Mechanisms and Immutability

Upgradeable contracts provide flexibility but introduce security risks.

Upgrade security checklist:

• [ ] Transparent or UUPS proxy pattern used — Industry-standard upgrade mechanism
• [ ] Storage collision risks eliminated — Variable layout carefully managed
• [ ] Upgrade process time-locked — Minimum 48 hours for users to react
• [ ] Upgrade governance clearly defined — Who can upgrade and how
• [ ] Upgrade history publicly accessible — All past upgrades documented
• [ ] Immutability considered for core logic — Critical components shouldn’t be upgradeable

Proxy pattern risks:

Upgradeable contracts using proxy patterns face specific vulnerabilities:

• Storage layout changes can corrupt data
• Initialization logic might be callable multiple times
• Delegatecall introduces reentrancy risks
• Upgrade keys become central points of failure

Case study: SUSHI’s Miso platform lost $3M in 2026 when an anonymous developer included a backdoor in an upgradeable contract. The code was audited, but the upgrade mechanism itself wasn’t properly secured.

Leading protocols increasingly adopt immutability for core logic while keeping only peripheral components upgradeable.

10. Community and Ecosystem Due Diligence

Technical audits miss social and organizational red flags that often precede exploits.

Community audit checklist:

• [ ] Founding team publicly identified — No fully anonymous teams for high-TVL protocols
• [ ] Team background verifiable — LinkedIn, GitHub, previous projects
• [ ] Active development on GitHub — Regular commits, not just marketing
• [ ] Transparent communication channels — Discord, Twitter, forum activity
• [ ] Responsive to security reports — Bug bounty claims handled promptly
• [ ] No history of abandoned projects — Team track record matters
• [ ] Aligned incentives — Team tokens vested long-term (2-4 years minimum)

Red flags in community/team:

• Anonymous team with no verifiable track record
• Previous failed/abandoned projects from same team
• Unrealistic APY promises (>100% sustainable yields)
• Aggressive marketing with little substance
• Locked social media comments (hiding criticism)
• No active development despite claiming “in development”
• Team tokens unlocked immediately at launch

On-chain reputation signals:

Check these on-chain indicators before investing:

• GitHub commit history: Active development or dead project?
• Smart contract deployment history: Any previous exploits or rugs?
• Multisig signer identities: Reputable entities or anonymous EOAs?
• Token distribution: Fair launch or heavy insider allocation?

For more on evaluating crypto communities, see our crypto community building guide.

How to Read a Security Audit Report

Professional audit reports follow a standard structure. Here’s how to extract the critical information:

Report Structure

1. Executive Summary

• Total issues found by severity
• Critical issues and remediation status
• Overall security assessment

2. Scope

• Contracts audited
• Audit methodology
• Limitations and exclusions

3. Findings

• Each issue categorized by severity
• Technical description
• Remediation recommendation
• Current status (fixed, acknowledged, mitigated)

4. Code Quality Assessment

• Architecture review
• Best practice adherence
• Gas optimization suggestions

Severity Classifications

Audit firms use different terminology, but severity levels generally map as follows:

Key principle: Any critical or high-severity findings should be fixed, not merely “acknowledged.” A finding marked as “acknowledged” means the team knows about it but chose not to fix it — a major red flag.

What to Look For in Audit Reports

Green flags:

• All critical/high findings marked “Fixed”
• Follow-up verification performed
• Comprehensive test coverage documented
• Multiple auditors reached similar conclusions
• Economic/game theory analysis included
• Formal verification on critical components

Red flags:

• Critical findings marked “Acknowledged” or “Risk accepted”
• Large gaps in audit scope (components excluded)
• No follow-up verification of fixes
• Very short audit timeline (under 2 weeks for complex protocols)
• Generic findings copied from other audits
• No mention of testing or methodology

Example analysis:

Here’s an excerpt from a real audit report (anonymized):

> Finding: Reentrancy vulnerability in withdraw() function > Severity: Critical > Status: Fixed > Description: The withdraw() function updates user balance after sending ETH, allowing reentrancy attacks. > Recommendation: Implement checks-effects-interactions pattern or use OpenZeppelin’s ReentrancyGuard. > Team Response: Fixed in commit abc123. Added ReentrancyGuard modifier. > Auditor Verification: Confirmed fixed. No further reentrancy risk detected.

This demonstrates proper remediation: Critical issue → Clear fix → Verification.

Compare this to a red flag example:

> Finding: Owner can drain all user funds > Severity: Critical > Status: Acknowledged > Team Response: Feature required for emergency scenarios. Will decentralize over time.

Never invest in a protocol with acknowledged critical findings.

On-Chain Verification: Don’t Trust, Verify

Audit reports can be faked or misrepresented. Always verify on-chain.

Verification Checklist

• [ ] Contract source code verified on block explorer (Etherscan, BscScan, etc.)
• [ ] Deployed bytecode matches audited code (hash comparison)
• [ ] Audit report publicly accessible (official project website or auditor site)
• [ ] Deployment date after audit completion (code deployed after audit, not before)
• [ ] No major changes post-audit (GitHub commits between audit and deployment)

How to Verify on Etherscan

1. Navigate to the contract address on Etherscan
2. Check the “Contract” tab for verified source code (green checkmark)
3. Review “Read Contract” and “Write Contract” tabs for admin functions
4. Click “Similar Contracts” to check for known patterns or clones
5. Review transaction history for unusual activity

Block explorer tools:

• Etherscan Contract Diffchecker — Compare deployed code to GitHub
• Sourcify — Decentralized contract verification
• Tenderly — Visual contract debugging and simulation

For more on reading blockchain data, see our guide to how to use block explorers.

Reading Deployed Contract Code

Even without deep Solidity knowledge, you can spot major red flags:

What to check:

• Owner/admin addresses: Are they multisigs or EOAs? (Multisig is safer)
• Timelock contracts: Are critical functions time-locked?
• Token minting: Can new tokens be minted freely?
• Fee mechanisms: Can fees be changed to 100%?
• Emergency functions: Can the contract be paused indefinitely?

Example on Etherscan:

function setFee(uint256 newFee) external onlyOwner { fee = newFee; // RED FLAG: No maximum limit }

vs

function setFee(uint256 newFee) external onlyOwner { require(newFee <= MAX_FEE, "Fee too high"); // Safe: Hard cap enforced fee = newFee; }

The second example includes a safety check preventing the owner from setting exploitative fees.

Advanced Security Analysis: On-Chain Signals

Professional traders don’t just read audit reports — they monitor on-chain security signals continuously.

Real-Time Monitoring Tools

Best on-chain security monitoring platforms:

1. Forta Network — Decentralized threat detection, real-time alerts
2. OpenZeppelin Defender — Automated security monitoring and incident response
3. Tenderly — Smart contract monitoring and debugging
4. Blocknative — Mempool monitoring for sandwich attacks
5. PeckShield Alert — Free Twitter bot for major exploits

These platforms monitor for:

• Unusual admin transactions
• Large token transfers
• Oracle price anomalies
• Governance proposal activity
• Exploit patterns and signatures

Free monitoring setup:

1. Set up Forta alerts on Etherscan (free)
2. Follow @PeckShieldAlert on Twitter
3. Join protocol Discord/Telegram for official updates
4. Use DeFiLlama to track TVL changes (sudden drops indicate problems)

Key On-Chain Metrics to Track

Beyond monitoring, track these security-related metrics:

TVL (Total Value Locked):

• Rapid TVL growth (>50% week-over-week) can indicate unsustainable yields
• Sudden TVL drops (>20% in 24 hours) may signal exploit or loss of confidence
• TVL concentration (single whale >20% of total) increases risk

Contract Activity Patterns:

• Admin transaction frequency — More activity = higher centralization risk
• Failed transaction spikes — Could indicate ongoing attack attempts
• Large liquidation events — Stress test of protocol mechanics

Token Distribution:

• Team/insider holdings — Over 30% concentration is concerning
• Whale concentration — Top 10 holders controlling >60% increases manipulation risk
• Unlocked vs locked tokens — Sudden unlocks can crash prices

Tools like our best on-chain analytics tools guide can help you track these metrics effectively.

Smart Contract Auditors: Who to Trust

Not all audits provide equal security assurance. Here’s how the top firms rank in 2026.

Top 10 Audit Firms by Exploit Prevention Rate

Based on CertiK Skynet data tracking post-audit exploit rates:

1. Trail of Bits — 98.3% prevention rate, 847 audits completed
2. OpenZeppelin — 97.1% prevention rate, 1,203 audits
3. CertiK — 96.4% prevention rate, 2,314 audits
4. Quantstamp — 95.8% prevention rate, 531 audits
5. Consensys Diligence — 95.2% prevention rate, 389 audits
6. ChainSecurity — 94.7% prevention rate, 298 audits
7. Slowmist — 93.9% prevention rate, 412 audits
8. PeckShield — 93.1% prevention rate, 894 audits
9. Hacken — 91.8% prevention rate, 673 audits
10. Halborn — 90.4% prevention rate, 234 audits

Cost ranges (2026 estimates):

• Tier 1 firms (Trail of Bits, OpenZeppelin): $100K-$250K per audit
• Tier 2 firms (CertiK, Quantstamp): $50K-$150K per audit
• Tier 3 firms (Regional specialists): $20K-$75K per audit

Timeline considerations:

• Comprehensive audit: 4-8 weeks for complex DeFi protocols
• Token audit: 1-2 weeks for standard ERC-20
• Follow-up audit: 1-2 weeks to verify fixes

For a complete comparison, see our best smart contract auditors 2026 analysis.

Multiple Audits: When and Why

Leading protocols don’t rely on a single audit. Here’s the multi-auditor strategy:

Why multiple audits matter:

According to Quantstamp research, different auditors find different issues:

• Auditor A finds 100% of critical issues
• Auditor B finds 75% of critical issues, plus 3 unique issues A missed
• Combined coverage: 100% + 3 additional critical issues

Recommended approach:

• 2 audits minimum for protocols with TVL >$10M
• 3+ audits for protocols with TVL >$100M
• Specialized audits for unique components (zk-proofs, cross-chain bridges, etc.)

Example: Aave V3 security process:

1. OpenZeppelin — Core lending logic
2. Trail of Bits — Cross-chain functionality
3. ABDK — Mathematical/economic modeling
4. Certora — Formal verification
5. Sigma Prime — Infrastructure security
6. Community bug bounty ($250K rewards)

Result: Zero critical exploits despite billions in TVL over 2+ years.

Red Flags: When to Avoid a Protocol

Certain warning signs should immediately disqualify a protocol from consideration, regardless of audit status.

Critical Red Flags (Automatic Disqualification)

• No audit for protocols claiming TVL >$1M
• Anonymous team for protocols with TVL >$10M
• Closed-source contracts (unless privacy is core to product, like Tornado Cash)
• Acknowledged critical vulnerabilities in audit reports
• Recent forks of exploited protocols without addressing root causes
• Unrealistic yields (>200% APY on non-stablecoin pairs)
• Admin keys held by EOAs (externally owned accounts, not multisigs)
• No bug bounty program for protocols with TVL >$50M

Major Red Flags (Proceed with Extreme Caution)

• Single audit from unknown firm
• Audit older than 12 months without follow-up reviews
• Major code changes post-audit
• Governance token weighted to insiders (>40% of supply)
• Rapid TVL growth without organic demand (often fake liquidity)
• Locked Telegram/Discord (hiding criticism)
• Stale GitHub activity (no commits in 90+ days)
• Heavy marketing, light documentation

Medium Red Flags (Research Thoroughly)

• Forked code from other protocols
• Complex tokenomics without economic audit
• Cross-chain bridges without specialized security review
• Oracle reliance on single provider
• High protocol fee changes (>50% adjustable range)

Case study: The Wonderland TIME disaster

Wonderland ($TIME) had several red flags that savvy investors caught:

• Founder “Dani” had previous failed projects
• Treasury management by “0xSifu,” later revealed as convicted fraudster
• Unsustainable (3,000%+) APY promises
• Complex rebase mechanics with no economic audit
• Concentrated token ownership among insiders

Despite these warnings, Wonderland reached $2 billion TVL before collapsing. Early red flag detection could have saved investors hundreds of millions.

How to Evaluate DeFi Protocol Security: Step-by-Step

Here’s a practical workflow for evaluating any DeFi protocol’s security before investing.

Step 1: Initial Triage (5 minutes)

Quick disqualification checks:

1. Search “[Protocol Name] exploit” on Twitter/Google
2. Check DeFiLlama for TVL trends (sudden drops = problems)
3. Verify audit exists (project website or auditor database)
4. Check if team is publicly identified
5. Review tokenomics (inflation rate, emission schedule)

Pass criteria:

• No recent exploits or rugs
• Stable or growing TVL
• At least 1 professional audit
• Public team or reputable builders
• Reasonable tokenomics

Fail = Skip to next protocol

Step 2: Audit Review (15 minutes)

If the protocol passes initial triage:

1. Download full audit report (not just summary)
2. Review severity distribution (any critical/high acknowledged?)
3. Check audit date vs deployment date
4. Verify all critical issues marked “Fixed”
5. Look for follow-up verification section
6. Cross-reference auditor reputation

Pass criteria:

• All critical/high findings fixed
• Audit within 12 months of current code
• Reputable auditor with track record
• Follow-up verification completed

Step 3: On-Chain Verification (10 minutes)

Verify the deployed contracts match audit claims:

1. Find contract address on block explorer
2. Confirm source code verified
3. Review admin functions in “Write Contract” tab
4. Check if admin address is multisig (view on Gnosis Safe)
5. Look for timelock contract linked to admin
6. Review recent transactions for suspicious activity

Pass criteria:

• Code verified and matches audit scope
• Admin controls are multisig
• Timelocks present on critical functions
• No suspicious recent transactions

Step 4: Economic and Operational Review (15 minutes)

Assess the sustainability and operational security:

1. Review tokenomics and emission schedule
2. Check if economic audit was performed
3. Analyze revenue vs expenses (sustainable?)
4. Review insurance coverage (Nexus Mutual, etc.)
5. Check bug bounty program details
6. Monitor community sentiment (Discord, Twitter)

Pass criteria:

• Sustainable tokenomics (not purely inflationary)
• Economic model makes sense
• Active bug bounty ($50K+ for high TV