OpenChainGraph · Explainer

What OpenChainGraph shares with a blockchain and what it leaves out

OpenChainGraph rebuilds the verification half of a public blockchain: hash links, Merkle roots, signatures and proofs that anyone can check offline. It leaves out the coordination half, meaning consensus, permissionless execution and independent operators, so it helps someone prove a number is right and does nothing for someone who needs a transaction nobody can stop.

The four scenes below take the comparison one piece at a time, and the table at the end puts it side by side.

Scene 1 · Where they look alike

Both link records by hash

A block names the hash of the block before it and commits its transactions under one Merkle root. An OpenChainGraph workflow step names its parent's execution hash (SPEC §21), and a session receipt folds many execution hashes into one Merkle root. Change one byte in the middle and every later link stops matching.

Hash links on both sidesLeft, a blockchain: blocks 100, 101 and 102, each naming the previous block's hash and holding a small Merkle tree of four transactions. One byte changes in block 101, its Merkle root changes, and block 102's previous-hash field no longer matches. Right, an OpenChainGraph workflow: steps 1 to 3 (art-590, art-591, art-592), each naming its parent's hash, all folded into a session receipt root. One input changes in step 2, step 3's parent no longer matches, and the session root changes. A blockchain An OpenChainGraph workflow block 100prev H99root R1004 transactions block 101prev H100root R1014 transactions block 102prev H101root R1024 transactions step 1art-590hash h1no parent step 2art-591hash h2parent h1 step 3art-592hash h3parent h2 session receiptMerkle root over h1 h2 h3 one byte changed changes prev no longer matches one input changed changes parent no longer matches root changes each block names the block before it a Merkle root commits each block's transactions each step names its parent a session receipt commits many runs at once
In both designs a change to one record breaks every link after it, so a verifier can spot the change without trusting whoever stored the records. The right side is the x402 spend-evidence workflow, drawn with labels instead of real hashes.
Scene 2 · Where they part

A blockchain agrees and OpenChainGraph recomputes

On a blockchain the next block is whatever the validators accept, and every full node keeps a copy of every transaction. OpenChainGraph has no shared ledger to agree on. Each result is its own artifact, and it holds if anyone with the inputs gets the same hash. The inputs stay with whoever ran the tool, and only hashes need to travel.

Agreement and recomputationLeft, seven validators in a ring send votes toward one shared ledger in the middle, and a coin stands for rewards and fees; every full node keeps every transaction. Right, a single browser tab takes its inputs through a kernel to a hash that matches the published one, and the network lane shows zero requests during the recompute. A blockchain An OpenChainGraph result one shared ledger rewards and fees validators agree on each new block every full node keeps every transaction your browser tabthe inputs hash matches the published hash network 0 requests anyone with the inputs recomputes the hash no ledger to agree on and no token
A blockchain spends its effort on agreement. OpenChainGraph spends it on recomputation, which needs one machine and the inputs. The OCG Explainer walks through the recompute itself, field by field.
Scene 3 · Where they meet

A blockchain can serve as one witness

OpenChainGraph can use a blockchain without becoming one. A session receipt's root can carry RFC 3161 timestamps from authorities such as Sigstore's TSA, DigiCert and FreeTSA, or an OpenTimestamps anchor whose proof verifies against a Bitcoin block header (SPEC §20). Nodes can also check signatures that belong to one chain: an x402 payment authorization is signed over an EIP-712 digest that names its chain, so it verifies on that chain and fails on every other.

Timestamps and chain-bound signaturesTop, a session receipt root sends hashes to four witnesses: Sigstore TSA, DigiCert and FreeTSA over RFC 3161, and OpenTimestamps calendars that lead to a Bitcoin block header, a blockchain acting as one more witness. Bottom, a USDC authorization whose EIP-712 digest names chain 8453 verifies on Base and is refused on Ethereum with DOMAIN_CHAIN_MISMATCH. Timestamps session receipt root Sigstore TSARFC 3161 DigiCertRFC 3161 FreeTSARFC 3161 OpenTimestampscalendars Bitcoin block header a blockchain as one more witness Chain-bound signatures USDC authorizationEIP-712 digest names chain 8453 Base · chain 8453 Ethereum · chain 1 verifies where it was signed refused elsewhere: DOMAIN_CHAIN_MISMATCH
Each timestamp or anchor is a separate witness to when the root existed, and a verifier can check any of them without asking AINumbers. In the lower half, art-590 recomputes the authorization's EIP-712 digest and art-592 refuses it on the wrong chain. The Evidence Estate explainer covers each anchor type in more depth.
Scene 4 · Common ground

Areas of interest shared with Ethereum and Zcash

OpenChainGraph works on some of the same problems as Ethereum and Zcash without running a chain. Four areas overlap: independent implementations, succinct proofs, trusted setup, and the person who checks what a specification means.

Four areas OpenChainGraph shares with Ethereum and ZcashFour rows, each pairing a public fact about Ethereum or Zcash with the matching practice in OpenChainGraph. Independent implementations: Ethereum checks its execution clients against fixtures generated from an executable Python spec; a second, independently written JavaScript verifier agrees with the RISC Zero library on all 312 OpenChainGraph receipts. Succinct proofs: Zcash switched to Groth16 with the Sapling upgrade in October 2018; each OpenChainGraph compute receipt ends in a 256-byte Groth16 seal a browser can verify. Trusted setup: Zcash's Sapling pool rests on Groth16 parameters from a setup ceremony, and its Orchard pool dropped the ceremony by moving to Halo 2 in May 2022; the seal OpenChainGraph checks rests on RISC Zero's ceremony for its STARK verifier. A person at the spec: a Zcash setup flaw evaded years of expert review until Ariel Gabizon found it in March 2018; OpenChainGraph's formal specs pass mutation and vacuity checks before a person signs them off. Ethereum or Zcash Common area OpenChainGraph EthereumExecution clients are checked against fixturesgenerated from an executable Python spec Independent implementations Two receipt verifiersA second JS verifier agrees with the RISC Zerolibrary on all 312 estate receipts ZcashSwitched to the Groth16 proving systemwith the Sapling upgrade in October 2018 Succinct proofs Groth16 sealEach compute receipt ends in a 256-byteGroth16 seal that a browser can verify ZcashSapling's Groth16 rests on a setup ceremony;Orchard dropped it with Halo 2 in May 2022 Trusted setup RISC Zero ceremonyThe seal OpenChainGraph checks rests onRISC Zero's ceremony for its STARK verifier ZcashA setup flaw evaded years of expert reviewuntil Ariel Gabizon found it in March 2018 A person at the spec Spec sign-offFormal specs pass mutation and vacuity checksbefore a person signs them off
Each row pairs a public fact about Ethereum or Zcash with the matching practice in OpenChainGraph. Sources: the Ethereum Execution Layer Specifications, Electric Coin Co. on the counterfeiting flaw (5 February 2019), the Zebra book on Groth16 parameters, Electric Coin Co. on NU5 and Orchard (31 May 2022) and RISC Zero's trusted setup ceremony. The OpenChainGraph side is on the Artifact Verifier, which reports the 312-receipt sweep, the formal verification explainer and in SPEC §18.
Side by side

The comparison in one table

Rows marked with a check are shared by both designs.

PropertyA public blockchainOpenChainGraph
Hash linksEach block names the previous block's hash.Each workflow step names its parent's execution hash (SPEC §21).
Merkle rootsEach block commits its transactions under one root.A session receipt folds many execution hashes into one root.
SignaturesAccount keys sign transactions.Artifacts and Work Mandates can carry eddsa-jcs-2022 signatures (SPEC §16 and §22).
Shared ledgerOne ledger that every full node keeps.There is none. Each result is its own artifact.
AgreementValidators or miners agree on each new block.No agreement step. Anyone recomputes the hash.
TokenA native token rewards the validators.There is none.
Where inputs liveIn the ledger, on every full node.With whoever ran the tool. Only hashes need to leave.
Checking a resultValidate each block against the ledger's rules.Recompute the execution hash (SPEC §4) or check its 256-byte Groth16 seal (SPEC §18).
TimeBlock time, final after enough confirmations or votes.RFC 3161 timestamps from authorities you choose, or an OpenTimestamps anchor in Bitcoin (SPEC §20).
Global orderEvery transaction sits in one global order.Runs are ordered only by their parent hashes and timestamps.

Git's object model is the closer relative: content-addressed records where you trust a record by recomputing its hash yourself. In-toto and SLSA attestations apply the same idea to software builds, and OpenChainGraph applies it to financial decisions.

Related reading: OCG Explainer covers the artifact envelope field by field · The Evidence Estate covers the anchoring rails · Compute integrity covers the Groth16 receipts · The OpenChainGraph paper places the design among related work.

All content on this page is static and processed locally in your browser. No data is transmitted. Do not enter real personal data into any OpenChainGraph tool. Use synthetic or anonymised inputs only.