How many auditors will be assigned, and who is the technical lead? Are they full-time employees or contractors engaged for this project? Will the people on the proposal be the people on the engagement?
Have the auditors assigned to me worked on this protocol category before, and can you point me at the reports?
How do you prevent a team from anchoring on each other's findings? This is a real and under-discussed failure mode: five auditors who compare notes on day one frequently produce the coverage of two.
What proportion of your high and critical findings are protocol-specific business logic rather than standard vulnerability classes? A firm that cannot answer is probably not measuring it.
What is explicitly out of scope, and what risk does that leave? Does the engagement cover the backend, the oracle infrastructure, the custody system, the upgrade path?
What would you recommend we review that we have not asked you to?
What does the re-test include, and is it in the price? Will you review the fixes against the original findings, or just confirm the diff?
If we are exploited after the audit, what do you do? Ask concretely: is there incident response capability, and is it available at 3am on a Sunday?
What does your methodology not cover, and what kind of bug would it be most likely to miss?
A firm that answers this well is telling you they understand their own limits. A firm that claims comprehensive coverage of everything is either not thinking carefully or is willing to tell you something untrue in a sales conversation — and either way, that is the firm writing your report.
LAST UPDATED
Everything above is easier to trust if you can verify it. The full engagement record, with per-engagement severity counts and links to published reports, is public.
We would rather answer the hard questions before the engagement than during it.