Solana Smart Contract Best Practices (Audits)

Common Security Issues

• •Signer enforcement
• •Typed accounts
• •Ownership validation
• •PDA patterns
• •Checked arithmetic
• •Input validation
• •Error handling
• •Account space
• •CPI account reloading
• •Compute units
• •Upgradeability
• •Testing
• •Token-2022 extension security

Index

Reference Files

• •DEVELOPMENT_PATTERNS.md -- 14 practices with full vulnerable/secure code examples
• •COMMON_MISTAKES.md -- 31 vulnerability patterns + 4 case studies
• •TOKEN_2022_SECURITY.md -- Token-2022 extension security (9 patterns)
• •SECURITY_TESTING.md -- TDD-style exploit tests for each vulnerability class

14 Practice Areas

31 Vulnerability Patterns

Token-2022 Security (9 patterns)

Case Studies

When to Use

• •Writing new Solana/Anchor programs from scratch
• •Reviewing pull requests that add or modify program logic
• •Refactoring existing programs for security and maintainability
• •Preparing a program for mainnet deployment
• •Integrating Token-2022 tokens or extensions
• •Onboarding developers to Solana best practices
• •Post-audit remediation work

When NOT to Use

• •For vulnerability scanning of deployed programs (use anchor-sealevel-attacks instead)
• •For non-Solana blockchain code
• •For off-chain client/frontend code only
• •When the codebase is a Solana SDK library, not a program

Rationalizations to Reject

• •"Rust prevents overflow by default" -- Only in debug mode. Release builds wrap silently. Always use checked_*() arithmetic or set overflow-checks = true in Cargo.toml.
• •"Anchor handles everything" -- Only when you use the correct types. AccountInfo<'info> bypasses all checks. unwrap() panics your program.
• •"We'll add validation later" -- Validation is not a feature; it's structural. Missing it at write-time means missing it at audit-time.
• •"The space calculation is close enough" -- Off-by-one in account space causes silent data truncation or allocation failure. Calculate exactly.
• •"We don't need tests for constraints" -- Constraints are your security boundary. Every has_one, constraint, and seeds must have a negative test.
• •"The account data is fresh, we just wrote it" -- After CPI, Anchor's deserialized account structs are stale. Always call .reload().
• •"Token-2022 is just like SPL Token" -- Token-2022 extensions (transfer fees, permanent delegates, CPI guards) change fundamental assumptions. Check every extension.
• •"We only accept known tokens" -- Governance changes or new pools can introduce Token-2022 tokens. Code defensively.

How This Skill Works

When invoked, follow a two-phase approach: Discover, then Fix.

Phase 1: Discover (TDD Red)

1. •Scan for Solana programs in the codebase
2. •Check each practice area against the 14 development patterns
3. •Scan for vulnerability patterns across all 31 common mistakes
4. •Check Token-2022 compatibility if token operations are present
5. •Report findings grouped by severity (Block Deployment / Fix Before Mainnet / Improve)
6. •For each finding, write an exploit test that proves the vulnerability exists
   • •Use the test patterns from SECURITY_TESTING.md
   • •The exploit test should PASS when the vulnerability is present (red = vulnerable)
   • •This provides evidence and a regression test

Phase 2: Fix (TDD Green)

1. •Apply the fix using the secure code patterns from the reference files
2. •Run the exploit test again -- it should now FAIL (green = fixed)
3. •Write a verification test that confirms the correct behavior
4. •Run the full test suite to ensure no regressions

This TDD approach ensures:

• •Every vulnerability has proof (the exploit test)
• •Every fix has verification (the exploit test now fails)
• •No regressions in existing functionality

Quick Reference: 14 Practice Areas

Review Workflow

Step 1: Identify Programs

rg "#\[program\]" programs/
rg "anchor-lang" Cargo.toml

Step 2: Security Checks (Practices 1-5)

# Raw AccountInfo (Practice 2)
rg "AccountInfo<'info>" programs/

# Missing signer types (Practice 1)
rg "authority.*AccountInfo|admin.*AccountInfo|owner.*AccountInfo" programs/

# Missing constraints (Practice 3)
rg "#\[derive\(Accounts\)\]" programs/ -A 20

# PDA patterns (Practice 4)
rg "seeds\s*=" programs/
rg "bump\s*=" programs/

# Unsafe arithmetic (Practice 5)
rg "\+\s*amount|\-\s*amount|\*\s*amount|/\s*amount" programs/
rg "checked_add|checked_sub|checked_mul|checked_div" programs/

# Unsafe casts (Vulnerability 17)
rg "\bas\s+(u8|u16|u32|u64|i8|i16|i32|i64)" programs/
rg "try_from" programs/

Step 3: Reliability Checks (Practice 6)

# unwrap/panic in production code
rg "\.unwrap\(\)|panic!\(" programs/

# Custom error types
rg "#\[error_code\]" programs/
rg "require!\(" programs/

# Unsafe blocks (Vulnerability 24)
rg "unsafe\s*\{" programs/

Step 4: Correctness Checks (Practices 7-8)

# Account space calculations
rg "space\s*=" programs/

# CPI followed by account reads (needs reload)
rg "invoke\(|invoke_signed\(|mint_to\(|transfer\(" programs/ -A 5
rg "\.reload\(\)" programs/

# Remaining accounts (Vulnerability 23)
rg "remaining_accounts" programs/

Step 5: Token-2022 Checks

# Check if using token operations
rg "token::|token_interface::|TokenInterface|TokenAccount" programs/

# Check for transfer_checked vs transfer
rg "token::transfer\b" programs/  # Should be transfer_checked

# Check for Interface vs Program types
rg "Program<'info,\s*Token>" programs/  # Should be Interface<TokenInterface>

# Token-2022 extension checks
rg "get_extension|StateWithExtensions" programs/

Step 6: Advanced Security Checks

# Authority transfer patterns (Vulnerability 18)
rg "authority|admin|owner" programs/ -A 3

# Slippage protection (Vulnerability 22)
rg "swap|trade|exchange" programs/
rg "minimum_amount|slippage|deadline" programs/

# Seed collision risk (Vulnerability 26)
rg "seeds\s*=" programs/ | sort

# Heap usage (Vulnerability 29)
rg "Vec::with_capacity|Vec::new|vec!\[" programs/

# Overflow checks in Cargo.toml
rg "overflow-checks" Cargo.toml

Step 7: Quality Checks (Practices 9-14)

# Documentation
rg "/// CHECK:" programs/
rg "///\s" programs/

# Test coverage
ls tests/
rg "#\[test\]|#\[should_panic\]|it\(" tests/

Reporting Format

## [CATEGORY] Practice #N: Practice Name

**Location**: `programs/my-program/src/lib.rs:45`

**Issue**: Description of what's wrong.

**Current Code**:
(vulnerable code block)

**Recommended Fix**:
(secure code block)

**Why**: Explanation of the risk and how the fix prevents it.

Priority Guidelines

Block Deployment (Critical)

• •Missing signer checks on authority operations (#1)
• •Raw AccountInfo where typed accounts are needed (#2)
• •No ownership validation on mutable operations (#3)
• •Unchecked arithmetic in financial calculations (#5)
• •unwrap() or panic! in production code (#6)
• •CPI signer forwarding to untrusted programs (V20)
• •Permanent delegate tokens accepted without checks (Token-2022)
• •No slippage protection on swaps (V22)

Fix Before Mainnet (High)

• •Incorrect account space calculations (#7)
• •Missing .reload() after CPI (#8)
• •No PDA seeds or non-deterministic accounts (#4)
• •No tests for security constraints (#11)
• •No professional audit (#12)
• •Unsafe as casts on user input (V17)
• •Single-step authority transfer (V18)
• •Unvalidated remaining accounts (V23)
• •Seed collisions between features (V26)
• •Transfer fees not accounted for (Token-2022)
• •Missing overflow-checks = true in Cargo.toml

Improve for Maintainability (Medium)

• •Missing documentation and /// CHECK: comments (#10)
• •Non-modular instruction handlers (#9)
• •No upgrade strategy (#13)
• •Unoptimized compute usage (#14)
• •No Token-2022 compatibility

Additional Resources

• •SlowMist Solana Security Best Practices (original source)
• •Solana Program Security Best Practices
• •Zealynx Solana Security Checklist
• •Helius Security Guide
• •Anchor Documentation
• •Solana Toolkit Best Practices
• •Anchor Account Constraints