How to Choose a Security Harness

A traditional audit is a fixed team reviewing a frozen codebase for a fixed window. A security harness is the other half of the picture. It is a structured way to put your code in front of many independent researchers, either in a time-boxed competition or as a continuous bug bounty. Used together, the two give you depth from a dedicated team and breadth from a crowd that attacks from angles a single team would not think to try.

The two main models

Audit competitions open your frozen codebase to a crowd for a set period, with a prize pool paid out by the severity of what is found. You get many eyes in a short window and you pay mostly for results. They work well right before a launch or a major release, when the code is stable enough to freeze but you still want one more wave of scrutiny.

Bug bounties run continuously against live code and pay per valid report. They cover the long tail: the bugs introduced by upgrades, new integrations, and configuration changes that land after the audit is over. They protect code that is already shipped and still moving.

Most serious projects layer all three: a dedicated audit for depth, a competition around launch for breadth, and a standing bounty for ongoing coverage. The layers catch different things, which is the point.

When a harness is the right tool

• Before a high-stakes launch. A competition adds a burst of independent scrutiny on top of your audit, often surfacing the creative path that a structured review did not prioritize.
• For code that changes often. A continuous bounty catches the regression a point-in-time audit cannot, because the audit reviewed a commit that no longer matches production.
• When you want breadth of perspective. A crowd explores cross-cutting and economic attacks, the kind that combine three contracts and an oracle, that a single team’s mental model can miss.

A harness does not replace a focused expert review of novel cryptography. See choosing an auditor for that. It sits on top of one.

The specialization problem

This is what trips up cryptography-heavy projects. Most large crowds are made up of smart-contract generalists. Open a ZK circuit, a novel proving system, or an MPC protocol to a general audience and you tend to get strong coverage of the Solidity around it and thin coverage of the cryptography that actually carries the risk. The reason is structural, not about effort: finding an under-constrained signal or a soundness gap means rederiving the constraint system and reasoning about what a malicious prover could satisfy, and the number of people who can do that on demand is small. A crowd finds what the crowd knows.

So the question to ask is not only how big the crowd is. The better question is whether the platform can put researchers who can read your code in front of it. For ZK and applied-cryptography scope, a smaller pool of genuine specialists routinely beats a large pool of generalists on the bugs that decide whether the system is sound.

The platforms

Platforms differ in their model, in the makeup and depth of their researcher pool, and in how well they fit cryptography-heavy code. Match the platform to where your risk actually sits.

How to evaluate a platform

• Researcher fit for your scope. The deciding factor for ZK and crypto code. Ask who in the pool has shipped findings in your domain, and ask to see them.
• Model. A one-off competition, a continuous bounty, or both, and which one your situation calls for.
• Judging and triage. Who reads the submissions, how duplicates are merged, and how a borderline severity is settled. Good judging is the difference between a useful result and an argument. Ask how disputes are escalated and who has the final call.
• Incentive design. Researcher attention follows expected payout, which is the pot weighted by the chance of finding something and getting paid for it. A pot that looks large but is split many ways, or judged unpredictably, will not buy the attention the number suggests.
• Sybil and collusion resistance. Competitions create incentives to split findings across accounts or sit on a bug. Ask how the platform handles duplicate gaming and disclosure timing.
• Confidentiality and scope control. Whether the code is public during the engagement, how scope and out-of-bounds rules are enforced, and how leaks are handled.
• Track record on similar code. Past engagements on systems like yours, not just on the famous ones.

Putting it together

A solid security program for a high-value cryptography project usually looks like this.

1. Prepare the codebase. See the checklist.
2. Audit with a team whose specialization matches your scope. See how to choose.
3. Compete. Open a harness around launch, on a platform whose researcher pool fits your technology.
4. Bounty. Keep a standing program running against live, changing code.

No single layer is enough on its own. The combination is what turns a high-value target from worth attacking into not worth the trouble.