Your own review,
built around what you actually ship

A review shaped to your codebase

Every finding verified before it reaches you, and rules written for your protocol rather than a generic checklist — the same engine behind our EVM and DAML reviews, shaped to your codebase.Every finding verified, and rules written for your protocol — our engine, shaped to your code.

A custom workspace keeps the engine and replaces the contents — what it looks for, the rules and the severity bar all become yours.A custom workspace keeps our engine and makes what it looks for, its rules and its severity bar yours.

Rules written around your protocol’s own invariants

A generic checklist asks whether your code contains known bad patterns. It cannot ask whether your code still holds the properties you depend on, because nothing in a generic checklist knows what those properties are.A generic checklist finds known bad patterns. It cannot check the properties your protocol depends on, because it does not know them.

Custom rules start from the invariants you can already state about your protocol — the thing that must never be true, the accounting identity that must balance, the role that must never be assumable, the sequence that must never interleave. Those become rules the review actively looks for violations of.Custom rules start from your invariants — what must never happen, what must always balance — and the review actively tests them.

• Properties you can already articulate, written down as checkable rules
• The failure modes you have seen before in your own system, or in protocols you fork from
• The assumptions your contracts make about callers, oracles, and upstream protocols

Tuned to your protocol, not a generic checklist

For a custom build we tune the review around your code and your risks, and we keep the one rule that makes it worth having: a finding is never confirmed without independent verification.Tuned around your code and risks, and no finding is confirmed without independent verification.

• Focused on the kinds of failure your protocol is exposed to
• Independent verification on every finding
• Kept current as the state of the art moves, without changing your rules

Your risk axes and severity bar, not ours

Severity is not a property of a bug; it is a property of a bug in your system. A rounding error that is noise in one protocol is the whole exploit in another, and a centralisation finding that matters enormously to one team is a documented, deliberate design decision to the next.Severity depends on your system: a rounding error that is noise in one protocol is the whole exploit in another.

So the axes a finding is scored on, and the bar it has to clear before it is worth your attention, are set for your build rather than inherited from ours. In practice that is the difference between a report you act on and a report you spend a week triaging.So scoring and the bar a finding must clear are set for your build — the difference between a report you act on and one you spend a week triaging.

• The axes you actually track, with your own weighting between them
• Your threshold for what counts as reportable, so the noise floor is yours
• Classes of finding you have already accepted, recorded as accepted rather than raised again every run

Runs against your pipeline, on your schedule

A review that only happens when someone remembers to upload a file is a review that happens rarely. A custom workspace is built to run where your code already moves — against the branch, on the cadence, and into the place your team already looks.A custom workspace runs where your code already moves: against the branch, on your cadence, into the place your team looks.

• Triggered on your schedule, or on the events that matter in your repository
• Reads the branches and repositories you point it at, including private ones
• Reports in the formats the workspace already produces — Markdown, PDF, DOCX
• Re-check rounds tracked as engagements, so a fix is verified against the finding it closes

How a build starts

It starts with a conversation, not a form. Ask for a callback and a person gets in touch to work out what you are building, what you need caught, and whether a custom workspace is actually the right answer — for a lot of teams the standard review already is, and we would rather tell you so.It starts with a conversation. A person calls to understand what you need — and if the standard review is enough, we will tell you so.