cortiq

Technology

What a run receipt on Base proves, and what it does not

27 Oct 2026 · 4-minute read

Two hashes, two counts and a block number. Small on purpose.

When a run finishes, Verify turns it into one JSON file: the plan, every step's inputs and outputs, and your decisions. From that file it computes two fingerprints with keccak-256: one of the plan, one of the log. The JSON is written in a canonical form, with keys sorted and no spaces, so the same content always produces the same fingerprints.

Anchoring sends those two fingerprints, the number of steps and the number of approved actions to the CortiqRunReceipt contract on Base. The contract adds the block, the time and the address that sent it. That is the whole receipt. No plan text, no outputs and no personal data reach the chain.

Later, anyone holding the file can paste it into Verify. The page recomputes both fingerprints in the browser and looks up the log fingerprint on Base. If they match, the file is exactly what was anchored, at that block, by that address. Change one character in an output and the match fails.

A receipt does not prove that a step's result is true, that a data source was right, or that the plan was wise. It proves that this record existed unchanged at a point in time. That is a narrow promise, and it is one a blockchain is good at keeping.

The contract has no owner, no fee and no upgrade path, and it is live on Base: anyone can read its receipts and match its bytecode with the verify-deployment script.

All articles