The VeritasChain Protocol records what an algorithmic trading system decided and executed, in an append-only, hash-chained, externally anchored log. Our receipts record what a computation did, in a deterministic, browser-verifiable artifact chain. This page reads the two formats against the same questions: what does a record bind, how is completeness proven, who can verify it without trusting the producer, and where does each format stop. It was written for a live correspondence with a practitioner on the VCP side, and for anyone comparing record formats for audit or regulatory work.
Everything about VCP here is read from their published specification v1.2, marked Production Ready, dated 6 July 2026, retrieved 15 October 2026 at commit b23acb266f88 of github.com/veritaschain/vcp-spec. Everything about our side is live on this site today. No connector, bridge, or implementation exists between the two formats, and nothing on this page claims otherwise.
VCP separates integrity into three named layers. Our receipts bind one canonical hash per run and hang verification off determinism. The table in step 3 puts the two side by side row by row.
VCP is published by the VeritasChain Standards Organization in Tokyo as the financial-domain profile of their Verifiable AI Provenance framework. Version 1.2 reached GA on 6 July 2026. A producer records its trading events in an append-only log; the spec's own scope line says the log verifies integrity and attribution of recorded events and does not certify the correctness or safety of the underlying AI or trading decisions. That boundary is written by VSO themselves, and it rhymes with the boundary our own artifacts declare.
Anchoring is where VCP is strictest: every tier must anchor externally, on a clock budget that tightens from Silver's 24 hours to Platinum's 10 minutes. Acceptable targets include Bitcoin, OpenTimestamps, and RFC 3161 timestamp authorities. The spec sets expectations per tier plainly: Silver, in VSO's own words on their site, provides transparency rather than regulatory-grade evidence.
Fetch VCP-Specification-v1_2_en.md from github.com/veritaschain/vcp-spec and summarize the three integrity layers, one sentence per layer, quoting the REQUIRED components exactly.
An OpenChainGraph receipt binds one computation. Its execution hash is a SHA-256 over the canonical JSON of exactly the declared inputs and the output payload, produced through the shared hash library; the kernel that computed the output is pinned by its own digest. Workflows chain receipts by carrying each parent hash forward, and the public ledger stores the artifacts content-addressed so the hash is the address.
The full anatomy, including a synthetic run you can reproduce from its published witness, is the subject of our companion page Four hashes and a witness. The short version for this crosswalk: our format proves a computation by reconstruction rather than by attestation, keeps private figures out of the record as salted commitments, and publishes receipts to a ledger any browser can verify without a server.
Open the record-provenance walkthrough on this site and report the four hashes of its specimen run, then recompute the step 1 hash from the published witness.
Nine concerns cover what an audit-grade record format has to decide. The left column is VCP v1.2 with the section that decides it; the right column is the OpenChainGraph receipt as it ships today. Where the two agree, the row says so; where one of them does less, the row says that instead.
| Concern | VCP v1.2 (GA 2026-07-06) | OpenChainGraph receipt |
|---|---|---|
| per-event integrity | EventHash: SHA-256 over the canonical event (Layer 1, §6) | execution_hash: SHA-256 over JCS-canonical {policy_parameters, output_payload} (SPEC §4) |
| chain linkage | PrevHash optional since v1.1; Merkle batching preferred | parent_hashes required on chained workflows; composite hash anchors a whole run |
| completeness | Merkle tree + root + audit path per anchored batch (Layer 2, §6) | determinism: identical inputs rebuild identical hashes anywhere; completeness by reconstruction |
| producer signature | Ed25519 REQUIRED at every tier (PQC algorithms experimental) | signature envelope ships empty on standard runs; §27.12 countersigning covers two-party runs |
| external anchoring | REQUIRED, all tiers: 10 min (Platinum) to 24 h (Silver), targets incl. Bitcoin, OpenTimestamps, RFC 3161 | not attached to standard runs; Sigsum lineage checkpoint published (leaf 72845 at writing) and an anchor endpoint serves other workflow families |
| actor linking | VCP-XREF dual logging: trader-side and broker-side streams cross-referenced (§5.6) | work-mandate binding records which policy governed a run; countersigned receipts for the two-party case |
| erasure | ERASURE event + crypto-shredding: destroy the DEK, accept the §17a-4 reproducibility tension (Annex §3) | §25 salted commitments: private figures never enter the record at all, so there is nothing to shred |
| verification surface | supervision-node PoC, Explorer GUI live, Explorer API planned with no date | browser verification, public content-addressed ledger, live MCP endpoint, hash-swept receipts |
| declared boundary | “does not certify the correctness or safety of the underlying AI or trading decisions” (their site) | “proves the computation over the declared inputs, never the real-world inputs themselves” (each artifact's rationale) |
Both formats state their limits in their own voice, and the two limits are the same limit: a record binds the computation it witnessed, and the truth of the declarations feeding it lives somewhere else. A reader comparing the two formats for procurement or audit work can carry that single sentence across every row above.
Read section 6 of the VCP v1.2 specification and section 4 of the OpenChainGraph SPEC, then write the completeness row of this crosswalk in your own words with both citations.
Three differences survive the table because they are philosophy rather than mechanism. After them: the primitives both formats already share, and the connectors that do not exist yet, described without pretending otherwise.
Most of the table is mechanism, where either format could adopt the other's answer. Three rows are philosophy, and those are the ones a standards discussion should settle first.
The erasure row deserves one extra sentence. VCP's annex is candid that destroying the decryption key satisfies an erasure obligation only in some jurisdictions, and that it sits badly with reproducibility-style retention rules such as SEC Rule 17a-4. Our format's answer, holding private figures outside the record from the first byte, sidesteps that tension and pays for it elsewhere: a commitment without the witness is a claim nobody can bind to real figures. Which answer fits depends on what the auditor is allowed to ask for.
Read Annex 3 of the VCP v1.2 specification and OCG Standard section 25, then state which GDPR pressure each answers and what each gives up.
Everything above is a reading of two published specifications. It is not an integration, and neither side claims one. A code search across all 27 public repositories in the veritaschain GitHub organisation returns zero hits for Model Context Protocol, zero for OpenChainGraph, and zero for AINumbers, measured on 15 October 2026. VSO's own correction wave states that zero external implementations of VAP exist. Our estate contains no VCP bytes either. A reader should trust this page as a mapping on paper, and as nothing more.
The three sketches are one-sentence descriptions of work that would be small on both sides, listed because a reader comparing formats always asks what a bridge would take. None of them is announced, planned, or in progress by either organisation, and this page deliberately does not date them into existence.
Search GitHub code in the veritaschain organisation for Model Context Protocol, for OpenChainGraph, and for AINumbers, and report all three counts with the date you ran them.
Every claim about VCP on this page is checkable against two pinned sources: their specification file at commit b23acb266f88 in the vcp-spec repository, and their public site as it read on 15 October 2026. Every claim about our side is checkable against the live estate: the specimen run, its witness, the ledger, and the verifier are all public. A mapping page earns trust the same way a receipt does, by naming exactly what it read.
Three events would make this page stale, and each is easy to spot: a VCP v1.3 or a VAP draft beyond Draft 3 changes the left column; a deployed Explorer API changes the verification row; a connector repository appearing in either organisation changes the boundary row from step 6. The page is a dated observation, written to stay true as a record of what the two formats said on 15 October 2026.
Check for a VCP v1.3, a VAP draft newer than 3, and a live Explorer API deployment, then say whether this crosswalk is still current as of today.