Freeze the scope
Choose the exact commit that should be audited. If the team continues changing code, use a clear branch strategy so auditors know which version is authoritative.
Write the threat model
Document assets at risk, privileged roles, external integrations, expected invariants, emergency actions, oracle assumptions, and areas where the team already has concerns.
Make tests useful
Include unit tests, invariant tests, integration tests, deployment scripts, and known failing cases. Tests do not replace manual review, but they help auditors reproduce and validate findings.
Share operational details
Auditors need to understand multisigs, timelocks, deployment ownership, upgrade procedures, monitoring, and incident response because those choices affect real-world risk.
Make a clean checkout reproducible
Provide exact compiler and dependency versions, setup instructions, and test commands that work without private production secrets. Include mock addresses and local fixtures for external integrations. Run those instructions from a fresh checkout before the review starts. Missing environment assumptions consume time that would otherwise go toward security analysis.
State exclusions and deployment assumptions
List contracts and services that are not being reviewed, including the assumptions your code makes about them. Record proxy implementations, initial roles, oracle configuration, and intended ownership transfers. Where a dependency cannot be tested locally, explain how its behavior is modeled and which production conditions the model does not cover.
Discuss Your Audit Scope
Start with your email and a short project description. Technical details can follow. Request a smart contract audit quote or review public CTDSEC audit examples.