Docs · Concepts

The review

An auditor reads the source and signs what it sees. Why it exists next to the checks, what it is told, and why it never quotes code.

What it is

A language model reads the project's own source files (dependencies, tests and scripts are excluded), together with the eight answers, and writes a description: what the contract does, who holds which powers, what a holder is exposed to, what looks off. The auditor signs the text and it goes on the seal.

It is an opinion. It is not proven, it can be wrong, and it is labelled as an opinion everywhere it appears: on the site, in the API (review, separate from checks), and in the signed digest (its hash is a separate line).

Why it exists

The checks catch what machines catch: shapes in the code. They do not catch intent, unusual mechanisms, or the thing nobody thought to write a check for. A reader does. Leaving the review out would have made the seal purer and less useful. Keeping it, honestly labelled, is the better trade.

The review also covers the ground the checks cannot: it can say the owner can change the treasury address, fees are computed with a divisor that can be set to zero, the contract calls an external router at a fixed address. None of those are rule set one. All of them matter.

What it is told

The instructions to the model are short and fixed. In substance:

  • Describe what the contract does, who holds which powers, what a holder is exposed to, and anything that looks off. Name functions and variables.
  • Never quote source code. Not a line, not an expression. Describe behaviour in words.
  • Do not repeat the eight verdicts; add what they cannot see.
  • Be plain and short. Under 350 words. No headings, no lists, no praise, no disclaimers.
  • End with one sentence beginning "Bottom line:".

Why it never quotes

The review is public. The source is not. A review that quoted a function would leak that function, and a review that quoted enough would leak the contract. The rule is absolute and the auditor's stake is what it costs to break it: a review that quotes code is a failed seal.

Describing without quoting is also what makes the review readable by a holder who does not read Solidity. The owner can set the fee recipient is a sentence anyone can act on.

When there is no review

The seal is still written, with the reason in place of the text.

  • The source is larger than the limit (350 kB of the project's own files).
  • The model declined. Safety classifiers sometimes read "who can freeze, who can upgrade" as the other kind of request. The worker asks for a server-side fallback to another model in the same call; if the whole chain declines, the seal says so.
  • No review key is configured on the worker.

A seal without a review has its eight answers and its signature, and the score is the same. The badge on a launch page shows the count, not the review.

Which model

The seal records it in reviewModel. Today it is Claude Opus 5 with a server-side fallback. The field exists so that when the model changes, old seals still say what wrote them.