Timeline drivers
Audit duration depends on code size, protocol complexity, network model, documentation quality, tests, external dependencies, upgradeability, and whether remediation review is included.
Why simple line counts are not enough
A small contract can be risky when it controls funds, signatures, bridges, governance, or oracle reads. A larger codebase can be easier to review when architecture and tests are clear.
Remediation time
Teams should reserve time after findings are delivered. Some fixes are direct, while business-logic changes may require design decisions, new tests, and a second review pass.
How to speed up review
Provide a frozen commit, concise architecture notes, existing tests, deployment instructions, threat model, and a list of known assumptions before the audit begins.
Separate review time from the launch calendar
An engagement can include scoping, initial review, a findings discussion, engineering fixes, verification, and final reporting. Ask which milestones are included in the proposed schedule and which depend on your team's availability. A review finishing on a certain day does not mean every finding will be remediated or the deployment ready on that same day.
Manage changes during the engagement
Define what happens when the code changes after the agreed freeze. A narrow fix can be verified against an existing finding, while a new feature or integration may require additional review. Keep a change summary that connects each commit to its purpose. This lets both teams distinguish planned remediation from an expansion of scope.
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.