The privacy line
Exactly what stays private, exactly what becomes public, and who sees what in between.
The whole idea is that a security check should not cost the developer their privacy. For that to mean anything, the line has to be drawn exactly, and kept.
Stays private
| What | How |
|---|---|
| The source | Read by one auditor, from a read-only GitHub grant to one repository. Held only while the review runs, on the worker's disk, then deleted. Never stored, never returned by any endpoint, never quoted in the review. |
| The repository | Its name, its history, its other branches. The auditor keeps the name and the commit so it can prove later what it read. The API never returns the name; the seal shows the commit hash alone, which identifies nothing without the repository. |
| You | No account on zkCheck. The GitHub identity is used for the grant and forgotten with the cookie. When the registry exists, the wallet that pays the fee is the only identity, and it can be a fresh one. |
| The compiled artifacts | The ABI, the AST, the build output. Deleted with the tree. |
Becomes public
| What | Why |
|---|---|
| The code hash | keccak256 of the runtime bytecode. Anyone can recompute it from the chain; publishing it reveals nothing that eth_getCode does not. |
| The deployment address, if given | It is on the chain already. |
| Eight answers, with evidence | The evidence names functions and paths: mint → _mint. That is the price of a fail being useful, and it is far less than the code. A pass names nothing. |
| The review | Describes, never quotes. Names functions and variables. |
| Contract name, compiler version | Both are in the bytecode metadata already. |
| The commit hash | Meaningless alone. |
| The auditor, the signature, the stake | That is what a seal is. |
| Name and symbol | As submitted. |
The auditor's position
The auditor sees everything and is trusted not to leak. That trust is backed by two things: the stake, which a leaked review would forfeit, and the design, which never asks the auditor to store what it does not need. The worker deletes the tree in a finally block: even a failed review leaves nothing on disk.
When the checks run inside a zkVM, the auditor still sees the source; the proof is for the public, not a way to hide the code from the one who checks it. Removing the auditor from the loop entirely, with the developer proving locally, is a longer road and a real one.
What a fail reveals
A pass reveals nothing. A fail reveals a function name and a path: Supply can grow after deployment: mint → _mint. A developer who does not want even that public can fix and resubmit before sharing the seal. Seals are public as soon as they are written, though, and the site lists them; the way to keep a fail private is not to submit until the code passes locally, which the Passing the checks page makes possible.
The GitHub grant, precisely
The zkCheck GitHub App asks for Contents: read-only, plus Metadata: read-only which GitHub requires. Nothing else: no issues, no pull requests, no webhooks, no write of any kind. You install it on the repositories you choose, and you can revoke it from your GitHub settings at any moment. The user token the worker uses expires with the cookie, one hour after connecting.