VCP v1.2 — Public Review Draft Coming Soon: An Implementer's Preview

What v1.2 is — and what it is not

VCP v1.1 (specification dated 30 December 2025, public release 1 January 2026) repositioned the protocol from "tamper-evidence" to "third-party verifiability + completeness guarantees." Three commitments anchor it: a three-layer architecture (Event / Collection / External Integrity), all-tier external anchoring, and mandatory Policy Identification. Those commitments are inherited unchanged in v1.2.

To put a finer edge on this: a v1.1 event passing through a v1.2 verifier still verifies. A v1.2 event missing the new optional fields still verifies. The only category of v1.2 event that requires special handling is one carrying an ed25519+mldsa65 hybrid signature — and even that is positioned as MAY in v1.2.0.

Schema-level changes: a tour at the byte level

The CORE Module

CORE is the only module REQUIRED in every conformant deployment. The v1.2 extension adds five fields on top of the v1.1 schema, all optional at v1.2.0:

• regulatory_profile — Declares the rule-book against which the deployment intends to be readable
• agent_id — Broadly applicable to any AI agent; technical identifier, does not imply legal autonomy classification
• reference_database_id — Conditional Article 12(3)(b)
• use_session_start — Conditional Article 12(3)(a) start
• use_session_end — Conditional Article 12(3)(a) end

A minimal v1.2.0 event indistinguishable in semantics from a v1.1 event:

{
  "vcp_version": "1.2",
  "event_id":    "0196a98b-4980-7abc-8123-4567890def01",
  "event_type":  "trade.order",
  "issuer_id":   "did:web:example-firm.eu",
  "policy_id":   "example-policy-2026-01",
  "issued_at":   "2026-05-07T09:00:00.000Z",
  "payload_hash":"a1b2…",
  "hash_alg":    "sha-256",
  "sig_alg":     "ed25519",
  "signature":   "MEUCI…",
  "external_anchor": {
    "anchor_type":  "RFC3161",
    "anchor_value": "MIICk…",
    "anchor_time":  "2026-05-07T09:00:05Z"
  }
}

Existing v1.1 emitters that simply update the vcp_version constant from "1.1" to "1.2" produce conformant v1.2.0 events at the regulatory_profile = NONE profile. No further code change is required for the simplest migration path.

The Regulatory Profile selector

The Regulatory Profile is the central operational addition of v1.2. It declares the rule-book against which the deployment intends to be readable.

Value	Meaning	Triggered Obligations
NONE	No specific regulatory mapping	v1.1 baseline only
AI_ACT_HRAI	High-risk AI per Reg (EU) 2024/1689	Art. 12(1)–(2) MUST; Art. 12(3) conditional; PMM Manifest SHOULD; ClockEvidence SHOULD
MIFID_ALGO	Algorithmic trading per MiFID II Art. 4(1)(39)	RTS 6 GOV fields MUST; PTCSnapshot SHOULD; ClockEvidence MUST
MIFID_HFT	High-frequency algorithmic trading	All MIFID_ALGO plus: Platinum tier MUST; PTPv2 ClockEvidence MUST
MIXED_FINANCIAL_AI	Both AI Act high-risk and MiFID applicable	Union of the above

Provisional values (not for production attestations): US_BD_RECORDS, FINRA_MARGIN, CFTC_DCM, EIOPA_INSURANCE_AI, JFSA_AI_DP. These may be renamed, merged, or withdrawn before GA.

ClockEvidence structure

The clock_evidence object is the operationalisation of ESMA Q&A 2825 (1 April 2026) and the timestamping expectations of Commission Delegated Regulation (EU) 2025/1155, Annex IV.

{
  "clock_evidence": {
    "utc_source":     "PTP-grandmaster:dc1",
    "offset_us":      12.4,
    "max_error_us":   38.0,
    "holdover_state": "LOCKED",
    "sync_method":    "PTPv2_LOCKED",
    "last_sync_at":   "2026-05-07T08:59:55Z",
    "clock_state":    "NOMINAL",
    "attestation_ref":"https://example-firm.eu/clock/2026-05-07.json"
  }
}

Tier obligations:

• Silver: SHOULD (raised from MAY in the internal draft after review)
• Gold: SHOULD; MUST when regulatory_profile = MIFID_ALGO
• Platinum: MUST; MUST under any MIFID_* profile

The new evidence channels

Five evidence channels are where the operational difference between v1.1 and v1.2 actually shows up at audit time:

1. gov.change_event

Operationalises the ESMA Supervisory Briefing's six-category material-change taxonomy. Emitted before a change takes effect in production. Categories: logic_change, execution_behavior, risk_control_change, external_dependency_change, adaptive_retraining, scope_change.

2. trade.ptc_snapshot and trade.ptc_breach

Article 13 of RTS 6 requires investment firms engaged in algorithmic trading to maintain pre-trade controls. ptc_snapshot records the state of controls; ptc_breach records what happened when a control fired.

3. gov.provider_dependency

Records the operator's diligence on third-party dependencies. dependency_kind: MARKET_DATA, EXECUTION_ALGO, RISK_ENGINE, MODEL_HOSTING, CLOUD_INFRA, MCP_TOOL_PROVIDER.

4. gov.pmm_manifest

Article 72 of the AI Act requires post-market monitoring of high-risk AI systems. The PMM Manifest is a pointer-and-hash bundle letting a supervisor verify what evidence the operator believed they had at the time of review.

5. recovery.* event types

Five standardised recovery events: recovery.policy, recovery.outage_public_notice, recovery.outage_ctp_notice, recovery.clock_degraded, recovery.data_feed_switch, recovery.model_retrained, recovery.integrity_test.

The post-quantum signature path

The cryptographic addition in v1.2 is the reservation of ed25519+mldsa65 as the canonical hybrid SignAlgo identifier. The wire format follows draft-ietf-lamps-pq-composite-sigs-06: classical Ed25519 (RFC 8032) and ML-DSA-65 (FIPS 204 Level 3).

Version	Verify Hybrid	Emit Hybrid
v1.2.0 (this PRD)	MAY at all tiers	MAY at all tiers; registry reserves ed25519+mldsa65
v1.2.1 (target Q1 2027)	MUST at Platinum, SHOULD at Gold	SHOULD at Platinum, MAY at Gold and Silver
v1.3.0	MUST at Platinum, MUST at Gold	MUST at Platinum, SHOULD at Gold

What this means for implementers today:

• v1.2.0: continue emitting sig_alg: "ed25519". Verify is unchanged.
• Provision dual-stack issuer keys in your SCITT issuer-keys endpoint.
• Begin tracking ML-DSA-65 library availability in your stack.
• Plan hardware. ML-DSA-65 signatures are ~3.3 KB.

The Regulatory Evidence Bundle

The structural innovation of v1.2 is the Regulatory Evidence Bundle (REB) — a packaging contract that lets an operator deliver, on demand, a self-contained set of artefacts that an auditor or supervisor can verify independently.

Migration: v1.1 to v1.2

For most v1.1 deployments, migration to v1.2.0 is a single-line change.

1. Step 1 — Bump the protocol version constant. Change "vcp_version": "1.1" to "vcp_version": "1.2".
2. Step 2 — Choose a Regulatory Profile. If you do not know which profile applies, set regulatory_profile: "NONE".
3. Step 3 — Populate clock_evidence if your tier or profile requires it.
4. Step 4 — Emit the new evidence channels as your operations require them.
5. Step 5 — Assemble REBs on demand.

Honest scoping: what VCP v1.2 still does not do

• VCP v1.2 is not a harmonised standard. It is published under the auspices of VeritasChain Standards Organization. It does not confer presumption of conformity with the EU AI Act, with MiFID II, or with any other law.
• VCP v1.2 supports evidence generation, not compliance. An operator that emits VCP events without the underlying governance, risk management, human oversight, and post-market monitoring will produce trustworthy evidence that they are non-compliant.
• VCP is not a blockchain. It anchors externally to RFC 3161 / eIDAS-qualified TSAs or to SCITT Receipts. There is no token, no consensus protocol.
• The two v1.1 hard deadlines remain unchanged. Policy Identification mandatory by 25 March 2026, and Silver-tier external anchoring mandatory by 25 June 2026.

How to engage with Public Review

Public Review opens with the PRD publication this week and runs for 45 days.

Where to submit comments: GitHub Issues at github.com/veritaschain/vcp-spec, using the Public Review Comment template.

What we are looking for from implementers:

• Does clock_evidence as defined cover what your time infrastructure actually produces?
• Does trade.ptc_snapshot capture every pre-trade control your venue or jurisdiction requires?
• Does the gov.change_event taxonomy cover every change you would actually emit one for?
• Does the REB minimum-content matrix match what your supervisors actually request?
• Does the requirements.txt install cleanly on your CI image?

Security findings: Report privately to security@veritaschain.org. 90-day responsible-disclosure timeline.

Resources

Once the PRD opens (this week):

• Specification and reference implementation: github.com/veritaschain/vcp-spec
• Specification document: VCP-Specification-v1_2-PRD.md
• JSON Schemas: schemas/
• Reference verifier: tools/vcp_verify.py
• Conformance test suite: tests/silver/, tests/gold/
• PQC reference vectors: pqc-vectors/

Regulatory references cited:

• Regulation (EU) 2024/1689 (AI Act), Articles 12, 19, 26, 72
• Directive 2014/65/EU (MiFID II), Article 4(1)(39)
• Commission Delegated Regulation (EU) 2017/589 (RTS 6)
• Commission Delegated Regulation (EU) 2025/1155 (RTS 25 successor), Annex IV
• ESMA Supervisory Briefing on Algorithmic Trading, 26 February 2026
• ESMA Q&A 2825 and Q&A 2826, 1 April 2026