How a review runs
From a read-only GitHub grant to a signed seal, in eight steps, with what leaves the auditor at each one.
A zk review is a pipeline. Every step is deterministic except the review text, and every step either produces a public fact or is discarded.
1. The grant
You connect GitHub through the zkCheck app. The app asks for one permission, Contents: read-only, and you install it on the repository to review, and no other. The token lives in an encrypted cookie in your browser for one hour and is used for exactly two calls by the worker.
2. The commit
The worker resolves the branch or ref you named to a commit hash. That hash is what the seal will record. Not the repository, not the branch: the commit.
3. The tree
The repository at that commit is downloaded as a tarball, never cloned with history. Git submodules, which Foundry uses for dependencies, are fetched at the commits the parent pins, from GitHub, three levels deep.
4. The build
Foundry compiles the tree. If there is no foundry.toml, a minimal one is generated so that Hardhat and Remix projects still compile, with node_modules and lib as import roots. The build runs offline: no network, no scripts, nothing but the compiler.
5. The match
Every compiled contract's runtime bytecode is compared to the code on Robinhood Chain at the address you gave, or to the bytecode you pasted if it is not deployed yet. Two things are set aside on both sides before comparing: the CBOR metadata the compiler appends (it encodes the source path, so it differs between machines) and the immutable slots (the artifact has zeros there, the chain has the constructor's values). Everything else must be identical, byte for byte.
No match, no seal. This is the step that ties the source to the chain. Why bytecode does not match lists the usual reasons.
6. The checks
The eight checks run on the matched contract. Seven read the compiled AST and the opcodes. The eighth sends tokens in and out of a fresh address on a fork of the chain. Each returns pass, fail or not run, with one sentence of evidence: which function, through which path. The eight checks describes each one.
7. The review
A model reads the project's own source (dependencies, tests and scripts are left out) together with the eight answers, and writes what it sees: what the contract does, who holds which keys, what looks off. It is told never to quote code. The auditor signs the text.
If the source is too large, or the model declines, the seal says so in place of the review, and the seal is still written.
8. The seal
The auditor signs a digest of the code hash, the rule set, the eight answers and the review text with its key. The seal is stored with the commit hash, the contract name, the compiler version, the answers, the review, the auditor's address and the signature. The source tree is deleted. If all eight passed, a post goes out on X with a card.
What is public afterwards
| Public | Private, then deleted |
|---|---|
| Code hash | The source |
| Commit hash | The repository name and its history |
| Contract name and compiler version | Your GitHub identity |
| Eight answers with evidence | The tree the worker built |
| The review text | |
| The auditor's address and signature |
The repository name is stored by the auditor and never returned by the API. The commit hash is meaningless without it, which is the point: it lets the auditor prove later what it read, and lets nobody else find it.