calldata

Purpose

Find and fix gas waste caused by unnecessary data copies at external function boundaries. When an external function parameter is declared memory, Solidity copies the entire calldata payload into a new memory allocation via CALLDATACOPY (3 gas + 3 gas/word + memory expansion overhead). Declaring it calldata eliminates this copy entirely — the EVM reads data directly from the immutable calldata region. For large arrays or structs, this is a one-word source change with measurable per-call savings.

When to Use

• Writing or reviewing any external function with array, bytes, string, or struct parameters
• Auditing a contract's function signatures for calldata efficiency
• After changing a function from public to external (VI-001) — calldata is now available
• Reviewing functions with 3 or more bool parameters (CD-004 candidate)

When NOT to Use

• public functions: calldata parameters are not permitted on public functions. Apply VI-001 (change to external) first, then apply calldata optimizations.
• internal and private functions: calldata is not available for internal calls.
• Functions that modify the array or struct: calldata is immutable. If the function writes to array elements (param[i] = x) or struct fields (param.field = y), memory is required.
• 1–2 bool parameters: bitmap encoding (CD-004) is not worth the readability cost for so few flags.
• Storage struct fields: CD-003 (prefer uint256) explicitly does NOT apply to storage struct fields — smaller types ARE the optimization there (SL-001).

Platform Detection

# Confirm Foundry project
test -f foundry.toml && echo "Foundry detected"

# Find external functions with memory arrays/structs — CD-001, CD-002 candidates
grep -rn "external" src/ | grep "memory"

# Find small-type parameters — CD-003 candidates
grep -rn "uint8\|uint16\|uint32\|uint64" src/

# Find functions with multiple bool parameters — CD-004 candidates
grep -rn "bool.*bool" src/