Honest positioning

Why OpenChainGraph, and why now

OpenChainGraph is a novel synthesis of borrowed parts, not a new primitive. Every ingredient already exists in an adjacent domain: software supply-chain attestation, data lineage, agentic-payment receipts. What no one else does is fuse them for fintech decision artifacts that recompute in the browser and are callable by agents over MCP.

This page is written straight: the real prior art, what's genuinely new, and the timeline that made it possible. If you're doing technical due diligence, start here.

536Live browser tools
362Verifiable chains
644Agent-callable over MCP

Not a slide claim: every count is derived from the live catalog, each tool recomputes client-side, and the surface is published on the MCP registry ↗. The defensibility argument below rests on this shipped coverage, not a roadmap.

01 · Prior art

What already exists, and why OCG isn't it

The resemblance to existing systems is real and worth naming. Each row is a genuine influence; the last column is the real distinction.

IngredientWhere it already existsWhy OpenChainGraph ≠ it
Hash-anchored provenance DAG, recompute-to-verify in-toto / SLSA (software builds); Git's content-addressed object model OCG applies the same pattern to financial decision artifacts, not software build artifacts.
"Chained verifiable computations" as a framework Academic: Trusted Compute Units (2025); non-repudiable provenance for clinical decision support (2020) Those are TEE / hardware-attestation or healthcare, not deterministic-recompute, not fintech, not browser-native.
Lineage DAG (node / job / run / dataset) OpenLineage (Airflow, Spark, dbt; LF standard) Lineage tracks data movement for observability, not recomputable decision receipts with an execution hash.
Signed receipts / mandates, cross-vendor via agents AP2 (W3C Verifiable-Credential mandates, signed; A2A hops) AP2 is payments authorization and key-trust (signed). OCG is computation-trust: recompute the hash, no key, no signer required.
Verifiable-AI / cryptographic provenance Chainlink, Lagrange, 0G, C2PA Content Credentials Blockchain / ZK or media-watermarking, not browser-deterministic fintech decisions.

None of these is wrong to compare against. OpenChainGraph deliberately borrows the in-toto/SLSA pattern and the W3C PROV / SLSA buildType vocabulary. See the integration guides linked in the footer.

02 · What's actually new

The combination none of them do

The novelty isn't any single ingredient; it's that OpenChainGraph is the only thing that does all five at once:

Search the field for any one of these and you'll find mature work. Search for the intersection and, as of 2026, you find OpenChainGraph. That's a genuine first-mover position. It is not a new cryptographic primitive, and we don't claim it is.

  Recompute to verify Fintech decisions Runs in the browser Agent-callable (MCP) Cross-vendor chains
in-toto / SLSAYesnononono
OpenLineagenonononono
AP2 (VC mandates)noYesnoYesYes
C2PAnonononono
OpenChainGraphYesYesYesYesYes

AP2 is the nearest neighbour (fintech, agentic, cross-vendor) but trusts a signature rather than a recompute, and doesn't run client-side. Only the last row has every column.

See it recompute

The proof isn't a claim, it's a hash you re-run

Below is a real decision artifact: a DORA major-incident classification. Its integrity is not a signature you have to trust. Click Recompute and your browser runs the same canonical SHA-256 over the inputs and outputs, with zero network, and returns the byte-identical value stored in the artifact.

Artifact: policy_parameters + output_payload
loading...
Stored execution_hash
Recomputed in your browser
not yet run

Now the cross-vendor part. Each artifact records the hash of the artifacts it consumed as a parent_hash, so a workflow that crosses organizational boundaries recomputes end to end from a single receipt, with no shared database and no coordinating authority.

Cross-vendor provenance chain Three decision artifacts at different vendors, each citing the previous by parent_hash across a vendor boundary. VENDOR A VENDOR B Risk score hash a1b2 · depth 0 AML screen hash c3d4 · depth 1 Payment decision hash e5f6 · depth 2 parent_hash parent_hash the whole chain recomputes from one artifact
03 · Why now

The pieces only converged in the last ~18 months

The real reason no one built this earlier: until recently you couldn't. The enabling parts sat in separate silos and the agent layer that ties them together didn't exist.

Before this convergence there was no protocol to call the nodes, no cross-vendor agent-trust standard to chain across, and provenance wasn't a mainstream expectation. The ingredients existed; nobody had a reason (or the connective tissue) to fuse them for fintech decisions until agents needed verifiable tool outputs.

04 · Terminology

The vocabulary, and one naming collision

The individual words (node, kernel, artifact, chain, DAG, pipeline) are used everywhere in data engineering, ML, and supply-chain security. What's specific to OpenChainGraph is the coherent mapping:

tool = the app  ·  node = the API surface  ·  kernel = the function  ·  artifact = the receipt  ·  chain (workflow) = the pipeline  ·  pack = the deployable workflow  ·  OCG = the spec  ·  MCP = the doorway
The naming collision: in MCP, the agent-callable thing is itself called a "tool." OpenChainGraph re-layers that: it calls the human page a "tool" and the agent surface a "node." MCP-native developers may expect "tool" to mean the callable. It's a deliberate distinction (human vs. machine face of the same capability), but it's bespoke, and worth knowing if you live in MCP's vocabulary.
Sources

References

  1. in-toto / SLSA software attestation
  2. SLSA provenance spec
  3. Trusted Compute Units: chained verifiable computations (arXiv 2025)
  4. OpenLineage standard
  5. MCP in 2026: architecture & adoption
  6. AP2 Agent Payments Protocol
  7. RegTech 2026 outlook (A-Team Insight)
  8. Verifiable-AI landscape