Smart Contract Audit Contest vs Private Audit: A Vendor-Neutral Decision Guide

How each model works

A smart contract audit contest is a time-boxed public review with a prize pool. The sponsor publishes a repository, a commit and a scope document, anyone who registers may submit findings inside a fixed window, a judge rules on validity and severity, then the pool is split by a formula the platform publishes in advance. Sherlock's documentation compresses that into one line: "a time-boxed public review program with clear incentives". Buying a private audit runs the other way around. You pay for named people for a named number of weeks, and what comes back is a report with a scope statement, a methodology section and a findings list attached to a firm that signed something.

One fact reorders everything below. On September 4, 2026 the Code4rena homepage carries the notice "Code4rena is winding down. After 5 years of securing DeFi, Code4rena is closing its doors", alongside the reassurance that "Active competitions and bounties are being seen through to completion." The most cited venue for this model is not taking new work. Every comparison guide that tells a founder to book a Code4rena competition was written before that sentence went up.

So the live shortlist for a buyer today is Sherlock, Cantina, Immunefi audit competitions and CodeHawks. Hats Finance belongs on the list of names worth checking, although our research on September 4, 2026 could not open a single page describing its competition rules and the two documentation URLs we tried returned HTTP 404. Code4rena still earns its place in this guide for a different reason: its public rulebook remains the clearest written account of how the model actually pays, so it works as the historical example rather than as a recommendation.

What the contest rulebook says

Code4rena's competition documentation puts the submission phase at "typically lasts 1-3 weeks". Once it closes, the judge rules on the severity, the validity and the quality of each finding, there is "a 48-hour QA period when the sponsor team and wardens may add comments", and "Awards are distributed in two batches". The document arrives at the end of all that: "The Audit report compiles valid findings from the competition".

Payment is where a contest stops resembling an audit. High severity findings draw on a slice worth 10 * (0.85 ^ (split - 1)) / split and mediums on 3 * (0.85 ^ (split - 1)) / split, where the split is the number of wardens who filed the same bug. Ten people who find one high do not each collect a tenth of the pot. They divide a pot that shrank by 15 percent for every extra finder. Whoever wrote the submission chosen for the report takes "a 30% slice bonus". Judges are paid out of the same money the researchers are, "by receiving a share of the prize pool themselves", and low severity plus centralization findings land in a QA bucket whose "allocation is capped".

The other four venues publish less, and what each one publishes differs in kind.

Sherlock

Sells a different shape and says so in writing: "the coordination of a staffed audit with the parallel discovery of a contest", with "80% of fees go directly to researchers" in many engagements and fix verification folded into the engagement. Judging runs in phases whose length is computed from the issue count, the first taking "(# of issues / 100) days (for example 500 issues would be 5 days), with a minimum of 2 days", the lead judge "(# of issues / 200) days" and the final phase "(# of controversial issues / 20) days". Noise costs you calendar, not just reading effort.

Immunefi

Calls its competitions "A time-bound code review by best-in-class security researchers" and says it handles triage for most of them.

Cantina

Publishes platform totals instead of a rulebook, reporting $65.2M in payouts on its competitions page on September 4, 2026.

CodeHawks

Documents a judging group whose members are "dedicated to reviewing Hawks submissions, deduplicating, validating, testing", yet publishes no fee, no minimum pool and no duration that we could read.

Decision table by scope, timeline and budget

Three inputs settle this, and the order they are applied in matters more than any single one of them: the size of what you are shipping, the number of weeks between today and the launch date you already announced, then the money.

Size comes first. A contest pays a crowd to find what is findable by reading a diff, which wants a scope small enough to read in a fortnight and self-contained enough to reason about. One contract or a few hundred LOC does not need a crowd, it needs two good people for a week. A protocol spread across several repositories with an off-chain half needs someone who will read all of it, and that is exactly what a staffed engagement buys.

Timeline comes second, and here is where teams misprice a contest. The submission window is not the engagement. Add the judging tail: the Code4rena sequence is a 48-hour sponsor comment period, then judging, then two award batches, while the four Sherlock phases each carry a floor of two days and grow with the issue count. Add the pieces up. At Sherlock the judging phase floors of two days apiece plus the 24 hour flag window put the shortest tail near a week, and a contest carrying 500 issues stretches the first phase alone to five days. At Code4rena a 48 hour comment period runs before judging, and awards then arrive in two separate batches. One to three weeks on top of the review window is where that arithmetic lands. We did that addition ourselves because neither platform publishes a combined figure. Put differently, a two-week private engagement with a fix review is finished and signed while a two-week contest is still being argued about.

Money comes last, because the first two inputs usually settle it already.

2026 price bands

Published comparisons of this market still quote figures from February 1, 2024. We went to the two platforms that expose public JSON and read them on September 4, 2026, taking the 20 most recently finished contests from each. That is 40 real engagements with real dates rather than a range somebody remembered.

Code4rena, across its 20 most recently finished audits, ran pools from $4,000 to $183,500 with a median of $38,750 and a median length of 9.5 days. Nine of those 20 sat under $25,000. Sherlock, across its 20 most recently finished public contests, ran from $104,000 to $1,388,500 with a median of $152,608 and a median length of 21.5 days. Sixteen of the Sherlock 20 fell between $100,000 and $250,000 and four went above. To keep the comparison honest we filtered the Sherlock feed to the type label "Public" and dropped everything marked Private, Private Best Efforts, Public Best Efforts or Public Bug Bounty, because a bounty's headline number is a maximum liability and not a price anybody paid.

One caveat belongs next to every Sherlock figure above. Each contest object in that feed carries two amounts, rewards and prize_pool, and they disagree. MakerDAO Endgame lists rewards of $1,388,500 against a prize pool of $415,000. Across the same 20 contests the prize pool field runs from $47,500 to $700,000 with a median of $112,858, against the rewards median of $152,608. Nothing in the public feed documents what separates the two, so we print both medians and decline to call either one the price.

The two platforms are not selling the same product at two prices. They are selling to different buyers. Nine sub-$25,000 Code4rena pools against zero at Sherlock is the clearest single line in the whole survey.

The number we could not measure

Our plan was to divide each pool by its confirmed high and medium findings and publish dollars per finding, which is the figure a buyer actually wants. It could not be produced. Five of the 20 Code4rena entries are mitigation reviews carrying no findings repository at all, and every one of the remaining 15 repositories answered HTTP 404 on September 4, 2026. Public evidence for the platform's most recent year of work is already unreachable while the wind-down proceeds. Anyone holding a link to a Code4rena findings repository in a data room should assume it will stop resolving, and should archive the contents now.

Old anchors and the private side

The prices still circulating for this decision come from a Cyfrin post dated February 1, 2024: "around $2K per day for a solo audit", "A two-week audit from an auditing firm can range anywhere from $40K to $60K", and an average competitive pool of "$60k to $100k". Cite those with the date attached, because our 2026 reading moves the contest floor down rather than up. Real 2026 pools of $18,000 and $22,000 sit well below that stated average.

For the private side we use a directory member that publishes its prices rather than a market average. DeFi Security Alliance runs no contest platform and sells no audits, so it has no side of this trade to price. Pharos Production is a directory member, and its bands are used here because they are published on the firm's own site, where anyone can check them against what we print. Pharos Production lists a single contract audit from $8,000, a DeFi protocol audit at $25,000 to $60,000 and a lead time of 2 to 3 weeks, recorded in our profile on September 3, 2026. Most firms quote privately, which is why an audit RFP that fixes the scope is the only way to compare two quotes. Beyond price, the directory's guide to choosing among smart contract auditors covers what else separates one firm from the next. Browse the member directory for firms that publish bands at all.

Failure modes of each model

Where contests break

1. Platform risk. It is no longer theoretical. The venue that ran 512 audits and paid out on 26,898 unique findings by its own count is closing, and with it goes the archive that made those numbers checkable. Nothing in the model prevents the same thing happening to the next platform.
2. Duplicate economics. Because a high severity slice decays by 15 percent for every extra finder, the eighth person to file an obvious bug earns very little, which pushes competent researchers toward differentiated issues nobody else is looking at. That is the argument for the model working well. Read it the other way and the same incentive says an obvious bug gets reported forty times while a subtle one may be reported zero times, and the prize pool cannot tell you which case you are in. That reading is ours. The formula is theirs.
3. Scope rules. They are stricter than most sponsors expect. Code4rena's severity documentation puts whole classes of bug outside the contest: "All non-standard/weird ERC-20 token and fee-on-transfer token findings are considered out of scope, unless they're explicitly listed as supported tokens". Root cause matters more than blast radius, since "If the root cause exists within the OOS contract itself, the finding is to be treated as OOS". Anything not exploitable inside the window counts as "speculating on future code", and issues that need a careless user are "QA at best". An integration bug originating in a dependency you left out of scope is invisible to a contest and is precisely what a firm reading your whole system would raise.
4. Schedule risk. Judging is adversarial by design at both platforms, so a contested severity call is a normal outcome rather than an incident, and it lands on your launch calendar. We looked for a documented case of a named contest missing a bug that was later exploited and found no primary source for one, so we make no claim in either direction.

Where private audits break

Blind spots are the structural weakness. One team brings one set of habits, and the bands above show the shape of the constraint: a fixed price buys a fixed review window, the member profile quoting 2 to 3 weeks against its $8,000 and $25,000 to $60,000 bands, with re-audit rounds priced as their own line rather than as more of the same review. That comes from one published price list, so read it as the shape of a fixed-fee engagement rather than as an industry rule. A crowd of a few hundred is a genuinely different search, which is the honest case for spending money on a contest at all.

Deliverable quality is the second weakness, and it varies far more than price does. Two firms can label the same bug two tiers apart, and a report with no methodology section tells you nothing about coverage. Our guide to reading an audit report walks a real document field by field, and the companion piece on spotting a fake audit report covers what to do when the PDF does not match the deployed contracts. Comparing firms on public output rather than on a sales call is what our analysis of audit companies is for.

Splitting a fixed security budget between audit and bounty

A useful split falls out of one structural difference rather than a percentage rule. Review money is committed: a contest pool and a firm's fee are both spent whether the reviewers find three highs or none. Bounty money is contingent, since it is a ceiling on what you would owe if somebody reports something after launch. Those two things should therefore be sized against different quantities.

Review budget

Sized against the code, which means scope, complexity and how much of it is new.

Bounty budget

Sized against the loss, which means against the TVL you expect to be holding three months after launch, and not against whatever is left in the security line.

Sherlock's own writing gives the shape of that trade, describing a $25,000 white hat payout set against a $25 million potential loss, and naming $16,000,000 as its largest bounty program.

Vendor figures deserve their labels. Immunefi claims $190B or more protected across web3 and 60,000 or more security researchers on its platform, which is marketing from the seller rather than independent measurement. Sherlock states that contests typically run 7 to 30 days with 200 to 400 security experts taking part, again its own account of its own product. Both numbers are useful for sizing expectations and neither should appear in a board deck without the attribution.

Worth knowing before you shop: Sherlock lists bug bounties in the same public feed as its contests, under the type label "Public Bug Bounty". One platform sells you both, which is convenient and also the reason a headline number on a listing page may not be a contest price at all. How to write the program itself is covered separately in our note on running a crypto bug bounty program, and the public rules that make a report reach you at all belong in a security disclosure policy.

Combining contest, private audit and bounty

Every party holding comparative data on this question sells one side of it. Cyfrin, which runs both a private practice and a competitive platform, concludes that teams should run "multiple audit rounds involving both private and competitive audits to strike a balance". Sherlock has gone further and packaged the combination as a single product, describing its engagement as staffed coordination running alongside contest discovery. Both conclusions may well be right. Neither is neutral, and a directory that ranks no vendor is a better place to read them than a vendor blog. The order that wastes the least money runs like this.

1. Staffed review first. A firm reads the whole system, including the off-chain parts and the dependencies a contest would rule out of scope, and hands you findings with a scope statement.
2. Fix what it found.
3. Contest over the corrected code. Every finding is genuinely new rather than a duplicate of something your firm already told you, so the duplicate decay does less damage to the pool.
4. Bounty on what you deployed. It stays open for as long as value sits in the contracts.

Fix verification is the joint between the two halves and is easy to forget when budgeting. Code4rena ran these as standalone short contests with their own pools, such as the four-day Intuition Mitigation Review at $4,000 starting April 2, 2026 and the two-day Swafe Mitigation Review Round 2 at $12,000 starting March 30, 2026. Sherlock instead folds fix verification into the engagement it already sold you. Ask which arrangement applies before you sign, because an unverified fix is the most expensive line item in this entire guide.

Sequencing all of this against a real launch date is its own problem, and we treat it separately in the smart contract audit timeline. If you are still deciding how many reviews the protocol needs before mainnet, the audit builder walks through scope and stage together.