This page comes out of a real correspondence about comparing provenance records. A practitioner asked which single workflow best shows how a result binds to its source inputs and anchored evidence, then asked for the exported run itself: the witness behind its committed inputs, and what the receipt establishes beyond the hash. Both replies are walked here as six steps against one published specimen, the default-waterfall workflow over a synthetic central-counterparty default. Every hash and figure was recomputed from the public kernels before publication, and the run is dated 7 October 2026. It is written for protocol designers weighing record formats against each other.
A useful provenance comparison separates four things: reproducibility, input commitments, parent and child linkage, and independently verifiable anchoring. Behind them sit three plain questions. What does each record prove? Who can verify it? What remains outside the recorded scope? The walkthrough answers all three for one workflow, with the receipts in hand.
The specimen is the default-waterfall workflow, chain-ccp-default-waterfall: it recomputes how a defaulting member's loss is absorbed, stage by stage, and then checks whether the default fund is sized to cover the two worst clearing-member stress losses. A practitioner reading this page can reproduce every number in it from the witness and the public kernels, and every number below was reproduced exactly that way before this page was written.
Pick one workflow from the catalog that best shows how a result links to its source inputs and anchored evidence. Show what each record proves, who can verify it, and what remains outside the recorded scope, using a concrete exported run.
Step 1 recomputes the sequential loss allocation at a defaulting-member event: the defaulter's initial margin, the defaulter's default-fund contribution, the central counterparty's own skin in the game, the surviving members' pool pro rata, then assessment powers. The stage order is declared by the caller per PFMI Principle 4 and the central counterparty's own published rulebook; nothing is hardcoded to one institution. Step 2 consumes the result and checks the declared default fund against the worst Cover-2 stress scenario across the declared members.
The synthetic run declares a loss of 500,000.00 against a stage order of five stages, and a default fund of 2,000,000.00 against three members and two stress scenarios. Both steps returned verdicts on 7 October 2026: WATERFALL_LOSS_FULLY_ABSORBED on step 1 and COVER2_FUND_ADEQUATE on step 2. The linkage between them is a hash citation, carried in the chain.parent_hashes field of the receipt, and the receipt's own hash anchors both steps at once. Read the stages top to bottom and the handoff explains itself: the loss enters, three stages absorb it, and the residual carried into the Cover-2 check is zero.
Run the chain-ccp-default-waterfall workflow end to end with a synthetic defaulting-member loss, and report each stage's absorption plus the Cover-2 verdict.
Every step emits an artifact whose execution hash is a deterministic function of exactly two members: the declared inputs and the output payload. The canonicalization is fixed (RFC 8785 / JCS), the kernel that computed the output is pinned by its own digest, and the run's telemetry carries that digest so a reader knows which bytes produced the answer. The same inputs return the identical hash on any machine, which converts the hash from a label into a proof of computation.
| Record from the run | What it is | sha-256 |
|---|---|---|
| step 1 artifact | the waterfall recompute over declared inputs | cd1503d3fb854f71aea4f1500e81d82f612d3c3301955ca659d9c34173f98f5c |
| step 2 artifact | the Cover-2 sizing check, built with step 1 as parent | 0ca6da06f32401f39e6fa2bc40332095c1c4904b0906b9736e5056a72ae04eea |
| composite receipt | anchors the run; parent_hashes names both steps | 36c64bd689b19b1c5f76cbcd088a41795fcbccd52e9e20e80a677fab95d95608 |
| input commitment | sha256 over salt and canonical figures (step 4) | sha256:ee2042618d9ac086aa04d40e6179a0edf9677df4fe81521d3cbde2e445686224 |
| verdicts | WATERFALL_LOSS_FULLY_ABSORBED · COVER2_FUND_ADEQUATE | run dated 2026-10-07 |
The proof is over the computation. Each artifact's own rationale states the boundary in plain sentences; step 1's reads, in part: “This is a sequential recompute over a caller-declared waterfall structure and a caller-declared loss amount, per PFMI Principle 4 and each CCP's own published rulebook order. It is not a determination that any CCP's actual default-fund sizing is adequate, and it performs no stress-scenario modelling of its own.” The record proves the arithmetic on the declared inputs; the declarations themselves are upstream.
Take the exported step 1 artifact, recompute its execution hash from its policy_parameters and output_payload using the public hash library, and compare it with the recorded hash character by character.
The exported run carries the synthetic witness alongside the artifacts, so the commitment check reproduces; then the receipt itself is read for what it attests, when, and what a verifier has to trust.
Three of the run's inputs are member-level figures: the defaulter's initial margin (20,000,000 in minor units), the defaulter's default-fund contribution (15,000,000), and the surviving members' pool (100,000,000,000). The workflow declares them under the standard's private-input scheme: they never enter the retained record in the clear. The record carries a salted commitment instead, and the published export includes the witness, the figures and a 256-bit salt, so the check reproduces for any reader.
The commitment binds the inputs; it does not encrypt the result. With this particular witness the declared loss exhausts the defaulter's stages, so the absorption profile in the output discloses those two capacities; sized differently, or shared as commitments and verdict flags alone, the capacities stay private. That distinction is worth a row in any record-format comparison, and the export states it rather than leaving it to be discovered.
Given the witness (the three member figures and the salt), recompute the commitment as sha256 over the salt followed by the JCS-canonical figures, and compare it with the commitment cited in the exported artifact.
Anyone holding the artifacts and the witness can verify, through three routes that end at the same hashes. The kernels are public files: rebuilding both artifacts locally with the pinned modules reproduced the step 1 and step 2 hashes bit for bit. The server accepts the same inputs again and returns the same hashes (the step 2 hash was byte identical across two server runs). And the compute mode can be delegated to the verifier's own browser, where the kernels run with zero network egress, removing the operator's execution from the trust picture entirely.
Rebuild both artifacts locally with the public kernels and the published witness, then compare all three hashes and the commitment with the exported run.
The receipt travels as a self-contained payload: the composite artifact itself, gzipped and base64url-encoded into the address after #a=. Decoding it needs no server. Verifying it needs no server either: the hash is recomputed from the artifact's own preimage and must match the address, or the content is rejected. Both halves of that design shape the answers to the questions a record comparison has to close.
| Question | Answer for this run |
|---|---|
| who attests it | No third party and no operator signature: the artifact's signature envelope ships empty on this run, and the estate's zk-proof queue has not attached a proof to it yet. The attestation is the artifact's own consistency plus public deterministic kernels. |
| time bound | None independently verifiable. The recorded timestamp is metadata outside the hash preimage (the artifacts rebuild identically with no clock input); there is no timestamping authority and no external anchor on this run. Anchoring infrastructure exists for other workflow families; two-party runs can carry mutual countersignatures. |
| what a verifier trusts | SHA-256 and JCS; that the pinned kernel digest names the public kernel source (plain files, re-hashable); and for a server-side run, that the operator actually executed that kernel. Re-running, or zero-egress browser execution, removes the last item. The ledger itself is trusted for availability; integrity never depends on it. |
| outside the record | Whether the declared inputs match real positions or margin systems; the witness behind the commitment (unless its holder shares it); publication time. |
The last row is the boundary the artifacts draw in their own words, and a comparison is more useful for starting there: the record proves the computation over the declared inputs, never the real-world inputs themselves. A field-by-field mapping against another protocol's records starts from exactly this split.
Decode the receipt: strip the version prefix after #a=, base64url-decode, gunzip, then recompute the execution hash over the artifact's preimage and compare it with the address.