Choose an auditor whose relevant work you can verify and whose proposal makes the review boundaries clear. Compare the same scope and deliverables, not just company rankings or the lowest headline price.
Start with your protocol, not a ranking
A token factory, lending market, Solana program and cross-chain application expose different risks. Describe the assets at risk, target runtime, privileged roles and integrations before making a shortlist. CTDSEC provides audit services, so this guide reflects a provider's perspective rather than an independent ranking. The criteria apply equally when evaluating us or another firm.
Ask for relevant, verifiable work
Read an original report that resembles your architecture. Check the reviewed repository or archive, commit, exclusions and finding status. A large client list is not proof that the people assigned to your engagement understand your specific system. Ask which comparable work supports the proposed team's experience, and distinguish public reports from marketing summaries.
Compare the people and the review process
Ask who is responsible for the review, how findings are challenged before delivery, and how your engineers can discuss uncertain behavior. Clarify which methods are planned for the agreed scope: manual analysis, targeted tests, static analysis, fuzzing or other techniques. A tool list alone does not explain how economic assumptions, privileged operations or integration failures will be examined.
Make proposals comparable
Use the same code revision, file list, dependencies and architecture description for each quote. Ask providers to identify review coverage, exclusions, scheduling assumptions, deliverables and how changes are handled. A quote covering a token contract alone is not directly comparable with one covering its factory, deployment scripts and integrations. Compare the work and responsibility before comparing the total.
Read a finding from impact through resolution
A useful finding should let engineers understand the affected behavior, impact and proposed remediation. Check whether the final report differentiates fixed, acknowledged and unresolved issues. In CTDSEC's public examples, acknowledged findings can remain in a final report. Treat that as a status to evaluate in context, not as a synonym for fixed or as evidence that every later version is safe.
Agree on remediation and changed code
Ask whether fix verification is included, what changes are eligible, and whether new functionality requires additional review. Define the revised commit and the remaining limitations in the final report. A brief patch check and a fresh review of a redesigned accounting system are different scopes. Plan time for your team's fixes as well as the auditor's review.
Separate assurance from promises
An audit is a bounded review, not a guarantee against all exploits. Claims about assets secured, rankings, certifications or past incidents need context and verifiable sources. Code review also does not establish the safety of every signing device, front end, operator process or off-chain asset. Discuss those boundaries when they affect your launch.
Begin with a small, clear scope conversation
Share your project type, chain, code readiness and target launch or upgrade window. Request a private-code sharing process before supplying sensitive material; never send credentials, private keys or seed phrases. You can start a CTDSEC enquiry with an email and a short description, then clarify technical access and scope together.
Review Checklist
- Relevant report and exact reviewed version
- Reviewer responsibility and communication
- Contracts, dependencies and exclusions
- Planned review methods and deliverables
- Scheduling and code-change assumptions
- Fix-verification inclusions and limits
- Public or private report requirements
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.