How to Define Cryptographic Audit Scope

A cryptographic audit scope is a formal document that defines the specific components, functions, and security properties to be examined by security researchers. It acts as a contract between the project team and the auditing firm, ensuring both parties agree on what is—and crucially, what is not—covered. For a blockchain protocol, this typically includes the core smart contracts, cryptographic primitives (like signature schemes or zero-knowledge proof circuits), and the underlying mathematical assumptions. A poorly defined scope can lead to critical vulnerabilities being overlooked or inefficient use of audit resources.

The scoping process begins with a threat model. This involves identifying the system's assets (e.g., user funds, private keys), trust assumptions (e.g., trusted setup ceremonies, oracles), and potential adversaries. For a DeFi lending protocol, key threats might include oracle manipulation, interest rate calculation errors, or liquidation logic flaws. The scope should explicitly list the attack vectors it intends to test, such as reentrancy, front-running, or cryptographic implementation bugs in custom elliptic curve operations. This model directly informs which code modules require the deepest scrutiny.

A critical step is dependency mapping. Modern applications rarely exist in isolation; they rely on external libraries like OpenZeppelin for contract templates or cryptographic suites like libsodium. The scope must specify whether these dependencies are included in the review. Auditing a forked version of Uniswap V2, for example, requires deciding if the audit covers only the project's modifications or the entire forked codebase, including the well-audited Constant Product Market Maker logic. This clarity prevents assumptions about the security of imported code.

Finally, the scope document outlines the testing methodologies. A comprehensive cryptographic audit employs multiple techniques: manual code review by experts, static analysis using tools like Slither or Mythril, formal verification for critical invariants, and functional testing. For a novel zero-knowledge rollup, the scope would mandate a review of the zk-SNARK circuit code (often written in Circom or Halo2), the trusted setup implementation, and the verifier smart contract on-chain. Each methodology targets different vulnerability classes, from logical errors to mathematical soundness.

Defining the audit scope involves specifying the exact components of a system that will be examined for cryptographic and logical vulnerabilities. This includes identifying the smart contracts, libraries, and off-chain components (like front-end integrators or oracles) that are in scope, as well as explicitly stating what is out of scope. A precise scope prevents scope creep, manages auditor workload, and allows for a focused, deep analysis of the highest-risk areas. For example, an audit might focus solely on the core Vault.sol and Controller.sol contracts, excluding peripheral token contracts or user interface code.

The first step is to create a comprehensive code inventory. Gather all relevant repository links, commit hashes for the version to be audited, and documentation. For smart contracts, this means providing the Solidity compiler version (e.g., ^0.8.20), a list of all imported dependencies (like OpenZeppelin @4.9.3), and the deployment scripts. Auditors need this to accurately replicate the build environment. You should also document the system's architecture, including data flow diagrams and a description of privileged roles (e.g., owner, governor, keeper) and their capabilities, as these are critical attack vectors.

Next, establish the security objectives and threat model. What are the core value propositions of the protocol, and what are the worst-case failure scenarios? Objectives often include: - Funds Safety: User deposits cannot be stolen or frozen. - System Integrity: Logic functions as intended under all conditions. - Access Control: Privileged functions are properly restricted. The threat model should consider adversaries ranging from external attackers and malicious users to compromised oracles and insider threats. This focus guides auditors to prioritize checks for business logic flaws, reentrancy, and oracle manipulation.

Finally, formalize the scope in a Statement of Work (SOW) or audit agreement. This document should list the in-scope files, the testing methodologies (e.g., manual review, static analysis, fuzzing), and the deliverables (e.g., a report with severity classifications). Clearly state assumptions, such as the trust model for external dependencies or oracles. A well-defined SOW aligns client and auditor expectations, serves as a reference throughout the engagement, and is essential for a reproducible and accountable audit process. Tools like Slither or MythX can be used for preliminary automated analysis to help identify complex areas that require deeper manual scrutiny.

Defining the cryptographic audit scope begins with a threat model. You must identify what assets the system protects (e.g., user funds, private keys, voting power) and the potential adversaries (e.g., malicious users, network attackers, compromised oracles). This model dictates which cryptographic primitives are in-scope. For a DeFi lending protocol, the scope would include the signature verification for loan origination, the hash functions securing user positions, and the randomness source for liquidations. A poorly defined scope risks missing critical vulnerabilities in peripheral but essential components.

Next, catalog all cryptographic dependencies. This includes both the explicit primitives used in your codebase (like ecrecover, keccak256, or secp256k1 operations) and the implicit ones provided by external libraries or the underlying blockchain. For Ethereum smart contracts, you must audit the use of blockhash for randomness, the handling of msg.sender for authentication, and any custom elliptic curve operations. List every imported library, such as OpenZeppelin's ECDSA.sol or MerkleProof.sol, and specify the exact version to audit for known issues.

The scope must also define the trust boundaries. Determine where cryptographic assumptions break. For instance, is the audit limited to on-chain code, or does it include off-chain signers, relayers, or key generation ceremonies? A cross-chain bridge audit must scope the on-chain verifier contract, the off-chain guardians' multi-signature scheme, and the attestation protocol between them. Clearly document what is considered a trusted setup (e.g., a specific multi-sig) versus what must be cryptographically proven.

Finally, formalize the scope in a document that includes: the specific commit hashes of the code, the list of in-scope contracts and libraries, the excluded components (and justification), and the key properties to verify. These properties are not generic "security" but specific assertions like "signatures are non-malleable," "the Merkle root commits to all valid states," or "the random beacon cannot be influenced by a validator." This document aligns the audit team and the project developers, ensuring efficient and comprehensive analysis.

Defining a cryptographic audit scope for a zero-knowledge proof (ZKP) system requires a layered approach, moving from the abstract protocol down to concrete implementation. The first step is to identify the core cryptographic primitives in use, such as Groth16, PLONK, or STARKs. Each protocol has distinct trust assumptions, setup requirements (trusted vs. transparent), and potential vulnerabilities. The scope must explicitly state which components are under review: the high-level protocol specification, the arithmetic circuit representation of the computation, or the specific prover/verifier implementations in languages like Rust, C++, or Circom. A clear boundary prevents scope creep and ensures focused testing.

The audit must then dissect the trusted setup ceremony for SNARKs, if applicable. This involves reviewing the participant structure, the secure multi-party computation (MPC) protocol used (e.g., Perpetual Powers of Tau), and the procedures for toxic waste disposal. For transparent systems like STARKs, the focus shifts to the soundness of the cryptographic hash function (often a rescue prime or SHA-256) and the FRI (Fast Reed-Solomon IOPP) protocol parameters. The scope document should list all external dependencies, such as elliptic curve libraries (e.g., arkworks, libsnark) and their versions, as these are frequent sources of critical bugs.

At the circuit layer, the scope defines which constraint systems or R1CS (Rank-1 Constraint Systems) representations will be analyzed. Auditors examine the circuit logic for semantic correctness—does it accurately encode the intended statement?—and for cryptographic soundness, checking for constraints that could allow a malicious prover to forge proofs. This includes analyzing custom gates, look-up tables, and non-native field arithmetic. Tools like ECne for Circom or manual review are used to identify under-constrained signals, which can lead to severe vulnerabilities where invalid states are proven valid.

Finally, the scope must encompass the integration points and oracle dependencies. ZKPs often rely on external data feeds (oracles) for inputs like Merkle roots or price data. The security of these data ingestion mechanisms, the serialization formats, and the public input validation are critical. The deliverable is a comprehensive report detailing findings across these layers, with severity ratings and actionable recommendations for mitigating risks in the system's specific deployment context, whether it's a private zk-rollup or an identity protocol.

The audit scope is a formal document that defines the boundaries of the security review. It specifies what will be audited and, just as importantly, what will not. A precise scope prevents scope creep, aligns client and auditor expectations, and ensures efficient resource allocation. Key components include the target repository commit hash (e.g., v1.2.3), specific files or modules, and the audit's primary objectives, such as verifying the correctness of a zero-knowledge proof circuit or the security of a novel signature scheme.

Deliverables are the tangible outputs of the audit. These typically include a technical report detailing findings with severity levels (Critical, High, Medium, Low), a list of code fixes or recommendations, and often a remediation review to verify that issues were properly addressed. Success criteria should be agreed upon upfront. For a cryptographic component, this might mean "No vulnerabilities exist that could lead to a loss of funds or a compromise of the protocol's cryptographic guarantees," or "The implementation correctly adheres to the formal specification described in the whitepaper."

To define the scope, start by mapping the system's trust boundaries and attack surfaces. For a smart contract, this includes all public and external functions, state variables, and dependencies. For a cryptographic library like libsecp256k1, focus on the core algorithms for signing, verification, and key generation. Exclude areas like front-end interfaces, off-chain infrastructure, or already-audited library dependencies, unless they are explicitly in scope. Documenting these exclusions is crucial for clarity.

Use a structured approach to prioritize. Conduct a threat modeling session to identify high-value targets, such as the vault logic in a DeFi protocol or the proof verification in a zk-rollup. The scope should reflect these priorities, dedicating more time to critical paths. For example, an audit of a novel consensus mechanism would deeply review the cryptographic signatures and leader election logic, while giving less focus to ancillary utility functions. This risk-based scoping ensures the audit effort is proportional to the potential impact.

Finally, the scope must be actionable for auditors. It should reference specific GitHub repositories, commit IDs, and technical specifications. Include any assumptions, such as the security of underlying primitives (e.g., assuming the Keccak hash function is secure). A well-crafted scope, agreed upon by both the client and the auditing firm before work begins, is the single most important factor in conducting a focused, efficient, and valuable security assessment.

A well-defined audit scope acts as a contract between the project team and the security researchers. It establishes clear boundaries, preventing scope creep and ensuring both parties focus on the highest-risk areas. The core components—smart contracts, access controls, oracle integrations, and economic mechanisms—should be explicitly listed. For example, specifying contracts/core/Vault.sol and contracts/token/ERC4626Staking.sol is more actionable than a vague directive to "review the protocol." This precision allows auditors to allocate time effectively and provides a verifiable deliverable.

The next step is to operationalize your defined scope. Begin by freezing the codebase under review using a specific Git commit hash or release tag to prevent moving targets. Compile a comprehensive technical specification or architecture diagram that maps data flows and privilege escalation paths. Share all relevant documentation, including previous audit reports and a list of known issues. For complex DeFi protocols, consider creating a dedicated test environment or mainnet fork where auditors can execute transactions without real financial risk, simulating attacks like flash loan manipulations or oracle price manipulations.

After the audit concludes, the scope document becomes the foundation for remediation and verification. Each finding should be mapped back to the scoped components, allowing for targeted fixes. The final step is a re-audit of the patched code, focusing solely on the modified functions and the new attack vectors they may introduce. This iterative process, grounded in a clear initial scope, is what transforms a security review from a checklist exercise into a robust defense layer. For ongoing projects, establish a continuous audit cadence, scoping incremental updates and new module integrations to maintain security as the protocol evolves.