To compare smart contract quotes, first bring them to a common basis: the same scope and code version, the same effort measured in person-days, the same deliverables and the same terms for re-audit, payment and exclusions. Only then does the price become comparable. Two quotes that differ by a factor of three often describe two different jobs, not the same job at two prices. This guide lists the elements to normalize, gives a checklist table, and explains how to decide.
Why smart contract quotes are hard to compare
Quotes are hard to compare because each vendor describes the work in its own format, with its own assumptions about scope, effort and what is included. One audit quote covers every contract in the repository, another only the core contracts. One development quote includes tests and deployment scripts, another stops at the contracts. One includes a re-audit, another will bill it separately.
The underlying cause is usually the request itself. When the brief is vague, each vendor fills the gaps with its own guesses, and the quotes diverge. A precise request, written once and sent to everyone, is the most effective way to get comparable answers. The guide on how to write a smart contract brief covers this step, and the brief generator helps you structure it.
The elements to normalize
For each quote, extract the same elements and write them side by side before looking at the total price.
Scope and commit
For an audit, the scope must name the files or contracts reviewed and the exact commit hash. A quote without a commit is a quote on code that may change. For development, the scope lists the features, contracts, tests, integrations and chains covered.
Size of the code (nSLOC)
For an audit, check that every vendor priced the same volume of code, expressed in nSLOC (normalized source lines of code, excluding comments and blank lines). A vendor who counted 900 lines and another who counted 2,000 did not quote the same work.
Team and days
Ask how many people work on the project, with what seniority, and for how many days each. Divide the price by the total person-days to get an effective day rate. This single figure often explains most of the gap between two quotes.
Duration and start date
Compare the calendar duration and the earliest start date. A shorter duration with the same effort means more people in parallel. A much shorter duration with less effort means a lighter job.
Deliverables
For an audit: preliminary report, final report, severity scale, proofs of concept, publication rights. For development: source code, unit tests and their coverage, documentation, deployment scripts, handover.
Re-audit included or not
Check whether verification of fixes is included, how many rounds, and within what time window. In the site's indicative model, a re-audit costs about 20% of the first audit price when it is billed separately, so an apparently cheaper quote without it may end up costing more.
Payment terms
Compare the schedule (deposit, milestones, balance), the currency, taxes, and what happens if the start date slips or the scope changes. Project payments are agreed directly between client and vendor.
What is excluded
Read the exclusions as carefully as the inclusions: front end, back end, third-party integrations, oracles, additional chains, economic or governance review, support after launch. An exclusion you did not notice is a future change request.
A comparison checklist
Fill in one column per vendor. Any empty cell is a question to send before deciding.
| Element | What to check | Vendor A | Vendor B | Vendor C |
|---|---|---|---|---|
| Scope | Files or features listed, commit hash (audit) | |||
| Code size | nSLOC counted, same for all vendors | |||
| Team | Number of people, seniority, names | |||
| Effort | Total person-days | |||
| Effective day rate | Price divided by person-days | |||
| Duration | Calendar weeks, start date | |||
| Deliverables | Reports, tests, documentation, scripts | |||
| Re-audit | Included, number of rounds, time window | |||
| Payment terms | Deposit, milestones, currency, taxes | |||
| Exclusions | What is explicitly not covered | |||
| Total price | Amount and currency, taxes included or not |
Once the table is complete, the ranking by price often changes. A useful sanity check is to compare the effort with an indicative model: for example, the site's audit model estimates about 6 auditor-days for a 1,500 nSLOC DeFi codebase in Solidity reviewed by an independent auditor, which gives an indicative 4,800 to 8,400 EUR. These are indicative ranges, real quotes depend on the scope, and an audit should always be budgeted on top of development. You can run your own estimate with the audit cost calculator.
Red flags in a quote
Some features of a quote should prompt a question, or a refusal.
- No scope or no commit: the vendor can later argue that a part was not included.
- A price far below the others with no explanation: check the effort, the team and the exclusions.
- Effort that does not match the size of the code or the complexity of the project.
- Unnamed team or a senior profile announced without any commitment on who does the work.
- Vague deliverables, such as "a report" or "the code", with no detail.
- Promises of security or "bug-free" code. No development or audit can guarantee it.
- Full payment upfront for a long engagement, without milestones.
- A developer offering to audit its own work, or proposing a "friendly" auditor. The audit must be independent of the development.
How an imposed quote format helps
An imposed quote format makes quotes comparable by construction: every vendor fills in the same fields, in the same units, for the same scope. You no longer have to rebuild the comparison table by hand, and vendors cannot hide key choices in the fine print.
A good format requires at least the price and currency, the duration, the team and person-days, the detailed scope, the deliverables, whether the re-audit is included, the payment terms and the exclusions. On smart-contract.com, quotes are submitted in such a format for this reason. Whatever channel you use, you can apply the same principle: send your checklist with the request and ask vendors to answer in that structure.
Making the decision
Decide on value for your project, not on the lowest total. Once quotes are normalized, eliminate those with red flags that the vendor could not clear up in writing. Then rank the remaining ones on relevant experience, the named team and the quality of the deliverables, and only then on price and timing.
If two quotes remain close, a short call with the person who will lead the work usually settles it. Before signing, confirm the final terms in writing: scope and commit, team, dates, deliverables, re-audit, payment schedule and exclusions. For development, also plan the audit from the start, with an auditor who has no link to your developer.
Key takeaways
- Normalize before comparing: same scope, same commit, same code size, same deliverables.
- Convert every quote into person-days and an effective day rate; this explains most price gaps.
- Check whether the re-audit is included and read the exclusions as carefully as the inclusions.
- Use a single imposed format for all vendors, starting with a precise brief sent to everyone.
- Choose on value and fit, then confirm every key term in writing before signing.