Purchasing Guides / Smart Contract Change Review

Smart Contract Change Review

A purchasing guide to buying a workflow that reviews smart contract changes before merge and lists possible security issues with code evidence for your engineers to confirm.

Yearly running cost

Assuming 2,400 pull requests a year

By hand: $64K / year; 800 hours of work
Hosted service: $19.2K – 48K+ / year
This workflow: $1K / year; Machine usage only; setup, hosting and review are extra.

What should it review?

Review smart contract changes for security issues before merge. Engineers check the findings instead of reading each change cold.

One pull request includes up to 1,000 changed lines of contract code.

Review an uploaded changeA diff or repository snapshot, with a findings page$1,008 – 2,880 setupReview each pull requestAdvisory checks on each pull request in your repository$1,656 – 4,680 setup

Findings are advisory. No deployments, signing keys, merges or claims that the code is safe.

What is included

Build the agreed repository, run static analysis and the test suite, review the changed contracts in context and return findings with code paths and severity reasons.

Start with a repository that builds, its existing tests, your review rules and past security findings. The pull request option adds a read-only repository app that comments; it never merges or deploys.

How good should the findings be?

A long list of warnings is not useful. Choose how many known issues it must find, how many findings must be real and how well each one is evidenced.

StandardUseful findings for engineers, with uncertain items marked for review.Known issues found: ≥70%Findings confirmed: ≥60%IncludedStrictA second verification pass and more seeded vulnerabilities in the tests.Known issues found: ≥80%Findings confirmed: ≥75%Setup +$360 – 960My own targetsAgree your own acceptance requirements with the provider.Quote separately

How these standards are measured

Test on held-out pull requests, including past changes with known fixed bugs and changes with seeded vulnerabilities. Measure issues found separately from findings confirmed; skipped files and failed builds must remain visible.

Targets for your selected standard
What is checked	Target
Known issues foundReported labelled issues divided by all labelled issues in held-out changes, including historical fixed bugs and seeded vulnerabilities; missing output counts as a miss.	≥70%
Findings confirmedFindings your reviewer confirms as real and actionable divided by all reported findings; duplicates and style notes count against it.	≥60%
Findings with evidenceA finding passes when the file, lines, affected code path and reasoning are correct and a reviewer can reproduce the concern.	≥95%
Changed files reviewedChanged contract files that were built and analysed divided by all changed contract files; skipped files must be listed, not hidden.	≥100%

Findings are a starting point for engineers and auditors. A clean result does not mean the contract is safe, and it does not replace an audit.

How quickly do you need the review?

Choose how quickly findings should be ready after a change is submitted. Your engineers' review time is separate.

Within 10 minutesIncludedWithin 5 minutesSetup +$144 – 480Within 2 minutesSetup +$360 – 960

Timing details

Time from accepting a change to stored findings, including checkout, build, static analysis, model passes, queueing and retries. Confirm the repository size and runner hardware with your provider.

The target applies to at least 95% of agreed test runs, with 3 in progress at a time.

How much do you want to spend per pull request?

Choose the machine budget for analysing a change. Tighter budgets may use smaller models or fewer review passes.

Up to $1.00IncludedUp to $0.60Setup +$144 – 480Up to $0.35Setup +$288 – 840

Cost details

Includes model calls, retries and shared runner and hosting allocation. Engineer review, auditor fees, repository subscriptions and the calling agent are separate. Failed and repeated runs also consume resources.

Reference machine cost: $0.53 – 0.73 per pull request at 200 pull requests a month. The selected cap is a target to test, not a replacement for this estimate.

Where do you want it to run?

Keep the review in your cloud or on your own server. Choose whether changed code may go to an approved AI service.

Run it onAI model access

Data and access details

Runs in a cloud account you control, with access controls and logs.

Only the changed code and agreed context go to the selected external model. Agree access and retention first.

Use read-only repository access and keep secrets, deployment keys and private configuration out of the reviewed snapshot. No external calls uses uploaded changes and private inference; it cannot use the hosted repository option.

How do you want to use it?

Use a review page, your current coding agent or a dedicated review agent. You can choose more than one.

A review web pageUpload a change, read findings and export the report.IncludedMy existing AI agentAsk your coding agent to submit a change and retrieve the findings.Setup +$72 – 240A dedicated agentUse a dedicated agent to run reviews and explain findings to engineers.Setup +$144 – 480

Anything else your provider should know?

Optional. Your choices are included automatically.

Pull requests per monthYour setup budget (USD)

Your contracts, tools or review rules

Common questions

Do I need this if we already use a hosted AI scanner?

Not necessarily. Keep the hosted scanner if it covers your contracts, rules and budget. Buy a separate workflow when you need your own review rules, private deployment or findings in your own tools.

Does it replace a security audit?

No. It gives engineers findings to check between audits. A clean result is not a safety claim, and releases that hold user funds still need your audit process.

Can it block a merge?

The pull request option posts a check result. Whether a failed check blocks merging is a setting in your repository that your team controls.

Can our code stay private?

Yes. Choose no external calls and supply your own hardware. Measure model quality and running cost during the pilot.

Which languages does it cover?

The guide assumes Solidity contracts with a working build. Other languages and chains can be agreed with the provider and may change the scope and price.