Certifying something on-chain without revealing it: privacy attestation on Midnight

I built Grid Audit, a tool that reviews Midnight code and then lets you certify that review on-chain. The thought behind this was to help assist people with reviewing what code they have created. But then my original thought grew: how do you record on a public ledger that an audit happened, by an authorized auditor, over a specific report, without publishing the report and without exposing the auditor's key?

That turns out to be a general Midnight pattern, and this post walks through the small contract that does it.

The problem

You want a public, tamper-evident receipt that says "this exact thing was reviewed and signed off." But:

• The report itself is private. It should never touch the chain.
• Only the real auditor should be able to publish a receipt. No impersonation.
• Anyone should be able to verify a receipt later, without learning the report or the auditor's secret.

On a transparent chain you would have to publish the report or trust an off-chain server. On Midnight you can do it with two primitives: witnesses and commitments.

The contract

Here is the whole registry. It is small, which is the point.

pragma language_version >= 0.23;
import CompactStandardLibrary;

// Public ledger state.
export ledger ownerCommitment: Bytes<32>;            // H(auditorSecret), set once at deploy
export ledger receipts: Map<Bytes<32>, Bytes<32>>;   // receiptId -> H(reportFingerprint)
export ledger published: Counter;

// Private inputs (witnesses). Supplied by the prover, never written to the ledger in the clear.
witness auditorSecret(): Bytes<32>;
witness reportFingerprint(): Bytes<32>;

// Bind the registry to the auditor's secret at deploy. Stores only the commitment, never the secret.
constructor() {
  ownerCommitment = disclose(persistentHash<Bytes<32>>(auditorSecret()));
}

export circuit publishReceipt(receiptId: Bytes<32>): [] {
  // Access control: re-derive H(secret) in-circuit and require it to match the commitment.
  assert(persistentHash<Bytes<32>>(auditorSecret()) == ownerCommitment, "not the auditor");

  assert(!receipts.member(disclose(receiptId)), "receipt already exists");

  // Only the commitment to the private report fingerprint is stored.
  receipts.insert(disclose(receiptId), disclose(persistentHash<Bytes<32>>(reportFingerprint())));
  published.increment(1);
}

Pattern 1: in-circuit secret-knowledge auth (not ownPublicKey())

The access control here is the important bit. At deploy, the constructor stores ownerCommitment = H(auditorSecret). The secret stays in the auditor's wallet. To publish, publishReceipt re-derives H(auditorSecret()) from the witness inside the circuit and asserts it equals the stored commitment.

The proof convinces the chain that the caller knows the secret, without the secret ever being disclosed. An observer sees only the commitment and the proof, never the secret, so nobody can impersonate the auditor.

This matters because the obvious habit from other chains, gating on the caller's public key, does not work on Midnight. ownPublicKey() is witness-sourced, so it is not a trusted caller identity and can be spoofed. The correct pattern is exactly this: make the caller prove knowledge of a secret in-circuit against an on-chain commitment.

Pattern 2: a commitment to a private value

The report never goes on-chain. The auditor computes a reportFingerprint (a hash of the report) locally, and the circuit stores only H(reportFingerprint) as the receipt value. Later, anyone holding the report can recompute the fingerprint, hash it, and check it against the stored commitment, proving the receipt matches that exact report. The chain learns that a report was certified, not what it said.

The one assumption that makes this safe

persistentHash only hides inputs that are hard to guess. This contract is safe because auditorSecret and reportFingerprint are high-entropy: a random 32-byte secret and a hash. If you tried this same pattern with a low-entropy input, say a four-digit code or a yes/no value, the published hash would be brute-forceable and the privacy would evaporate. For low-entropy values you need a commitment with a fresh secret salt instead of a bare hash. Here the inputs are already high-entropy, so a plain hash is fine. Knowing which case you are in is the whole game.

What you end up with

A public registry where:

• Only the holder of the auditor secret can publish, proven in zero knowledge.
• Each receipt commits to a private report without revealing it.
• Anyone can verify a receipt against a report they hold.
• The auditor's secret and the report contents never touch the chain.

Wrapping up

This is a small contract, but it is a reusable shape: prove authorization by secret knowledge, and publish commitments instead of data. Any time you want an on-chain record of something private, this is the pattern to reach for.

The full project is here: Grid Audit on GitHub. It pairs this registry with a reviewer that flags Midnight-specific privacy and security traps, so you can review your Compact code and then certify the result on-chain, privately.