Back to Blog Announcements

VCP v1.1: Strengthening External Verifiability with Three-Layer Architecture

Announcing VCP v1.1 with mandatory External Anchoring for all tiers, clear three-layer architecture, and Policy Identification for multi-tenant deployments.

December 26, 2025 12 min read VeritasChain Standards Organization

VCP Specification v1.1 Draft Released

Protocol-compatible with v1.0 • Finalization planned Q1 2026

Table of Contents

Executive Summary

Today, we are pleased to announce the draft release of VeritasChain Protocol (VCP) Specification v1.1. This update introduces a clear three-layer architecture for cryptographic integrity, makes External Anchoring mandatory for all tiers, and adds Policy Identification for multi-tenant deployments.

Key Changes at a Glance

Change Impact
Three-Layer Architecture Clearer separation of integrity mechanisms
External Anchor → REQUIRED for all tiers Silver tier now requires daily anchoring
PrevHash → OPTIONAL Simplifies implementation without sacrificing verifiability
Policy Identification → REQUIRED Enables multi-tier, multi-policy deployments

VCP v1.1 is protocol-compatible with v1.0. Existing implementations will continue to work, though some may need updates to achieve v1.1 VC-Certified status.

Why v1.1? The Story Behind the Update

When we released VCP v1.0 in November 2025, our primary goal was to establish a robust foundation for algorithmic trading audit trails. The specification was well-received, with early adopters successfully implementing VCP across Silver, Gold, and Platinum tiers.

However, as we engaged with the community—including feedback from IETF SCITT Working Group participants, regulatory consultants, and implementation teams—a structural issue emerged.

The Logical Inconsistency in v1.0

In v1.0, the specification stated:

This created a gap in VCP's core principle of "Verify, Don't Trust."

Here's the problem: A Merkle Tree is only as trustworthy as its root. If the Merkle Root is never externally anchored, the log producer could theoretically reconstruct the entire tree after the fact. Without external anchoring, the "immutability" guarantee relied on trusting the producer—exactly what VCP was designed to eliminate.

The Solution: Mandatory External Anchoring

v1.1 resolves this by making External Anchoring REQUIRED for all tiers, with tier-appropriate frequencies and lightweight options for Silver tier implementations.

This isn't about adding burden—it's about ensuring that even the simplest VCP deployment provides what regulators and auditors actually need: externally verifiable proof of integrity.

The Three-Layer Architecture

One of the most significant changes in v1.1 is the introduction of a clear three-layer architecture for integrity and security. This structure clarifies how different cryptographic mechanisms work together and where each layer's guarantees originate.

┌─────────────────────────────────────────────────────────────────────┐ │ │ │ LAYER 3: External Verifiability │ │ ───────────────────────────────── │ │ Purpose: Third-party verification without trusting the producer │ │ │ │ Components: │ │ ├─ Digital Signature (Ed25519/Dilithium): REQUIRED │ │ ├─ Timestamp (dual format ISO+int64): REQUIRED │ │ └─ External Anchor (Blockchain/TSA): REQUIRED │ │ │ │ Frequency: Tier-dependent (10min / 1hr / 24hr) │ │ │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ LAYER 2: Collection Integrity ← Core for external verifiability│ │ ──────────────────────────────── │ │ Purpose: Prove completeness of event batches │ │ │ │ Components: │ │ ├─ Merkle Tree (RFC 6962): REQUIRED │ │ ├─ Merkle Root: REQUIRED │ │ └─ Audit Path (for verification): REQUIRED │ │ │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ LAYER 1: Event Integrity │ │ ──────────────────────── │ │ Purpose: Individual event completeness │ │ │ │ Components: │ │ ├─ EventHash (SHA-256 of canonical event): REQUIRED │ │ └─ PrevHash (link to previous event): OPTIONAL │ │ │ └─────────────────────────────────────────────────────────────────────┘

Why This Structure Matters

Layer 1 (Event Integrity) ensures each individual event is complete and unmodified. The EventHash provides a fingerprint of the event's contents.

Layer 2 (Collection Integrity) proves that a batch of events is complete—no events were added, removed, or reordered after the fact. The Merkle Tree structure enables efficient verification of any single event's inclusion in the batch.

Layer 3 (External Verifiability) is where VCP delivers its core value proposition. By anchoring the Merkle Root to an external, immutable target (blockchain, RFC 3161 TSA, or attested database), we create proof that cannot be retroactively modified by the log producer.

This is what makes "Verify, Don't Trust" possible. A third party can independently verify the integrity of your audit trail without trusting you.

PrevHash: From REQUIRED to OPTIONAL

One question we've received frequently: "Why make hash chains optional? Doesn't that weaken security?"

The short answer: No. Here's why.

What Hash Chains Provide

In v1.0, PrevHash (the link to the previous event's hash) was REQUIRED. This creates a hash chain—if any event is modified, all subsequent hashes become invalid, providing real-time tamper detection.

Hash chains are valuable for:

What Hash Chains Don't Provide

However, hash chains have a limitation: they can be reconstructed by anyone who controls all the data.

If a malicious log producer wants to modify an event and update all subsequent hashes, they can do so—as long as they haven't externally anchored the Merkle Root yet.

This is why External Anchoring is the critical integrity mechanism, not hash chaining.

The v1.1 Approach

In v1.1, we've made PrevHash OPTIONAL because:

  1. Merkle Tree + External Anchor provides the essential guarantee of external verifiability
  2. Hash chains complement but don't replace external anchoring
  3. Simplifying Silver tier implementations reduces adoption barriers

Recommendation for Regulatory Use Cases

For implementations targeting regulatory use cases (MiFID II RTS 25, SEC CAT Rule 613), we RECOMMEND enabling hash chains. Gold and Platinum tier implementations should consider PrevHash a best practice.

Policy Identification: Supporting Multi-Tenant Deployments

v1.1 introduces Policy Identification as a REQUIRED field. This seemingly small addition has significant implications for enterprise deployments.

The Problem

In real-world deployments, organizations often need to:

Without explicit policy declaration, verifiers must guess which rules apply to a given event stream.

The Solution

Every VCP event now explicitly declares its conformance tier and registration policy:

{
  "PolicyIdentification": {
    "Version": "1.1",
    "PolicyID": "org.veritaschain.prod:hft-system-001",
    "ConformanceTier": "PLATINUM",
    "RegistrationPolicy": {
      "Issuer": "VeritasChain Inc.",
      "PolicyURI": "https://veritaschain.org/policies/prod-hft",
      "EffectiveDate": 1735084800000
    },
    "VerificationDepth": {
      "HashChainValidation": true,
      "MerkleProofRequired": true,
      "ExternalAnchorRequired": true
    }
  }
}

PolicyID Naming Convention

To ensure global uniqueness without requiring a central registry, we recommend the Issuer Domain + Local ID format:

PolicyID = <reverse_domain>:<local_identifier>

Examples:
  org.veritaschain.prod:hft-system-001
  com.acme.trading:gold-algo-v2
  jp.co.broker:silver-mt5-bridge

External Anchoring: Now Required for All Tiers

The most impactful change in v1.1 is making External Anchoring REQUIRED for all tiers.

Tier-Specific Requirements

Tier Frequency Anchor Target Proof Type
Platinum Every 10 minutes Blockchain or RFC 3161 TSA Full Merkle proof
Gold Every 1 hour RFC 3161 TSA or attested database Merkle root + audit path
Silver Every 24 hours Public timestamping service or attested database Merkle root only

Silver Tier: Lightweight Options

We recognize that Silver tier serves development, testing, and non-regulated trading scenarios. Requiring blockchain anchoring would be overkill.

That's why we've explicitly permitted lightweight anchoring mechanisms for Silver:

Attested Database: What Qualifies?

For Gold and Silver tiers, "Attested Database" is an acceptable anchor target. But what makes a database "attested"?

Criterion Requirement
Third-Party Audit Annual audit by independent party
Tamper Detection Cryptographic integrity checks
Access Controls SOC 2 Type II or equivalent
Retention Policy ≥ 7 years
Availability SLA ≥ 99.9% uptime

Testing and Certification Updates

New Critical Tests

v1.1 introduces new critical tests that implementations must pass for certification:

Test ID Description
MKL-001 Merkle tree construction
MKL-002 Merkle proof verification
ANC-001 External anchor presence
POL-001 Policy Identification

Certification Governance Reminder

VC-Certified certification is issued by VSO-accredited Conformity Assessment Bodies (CABs), not by VSO directly. VSO functions as the Scheme Owner, responsible for standard development and CAB accreditation.

This structure ensures independence between standard-setting and certification, following the model established by PCI-DSS, ISO, and other mature certification schemes.

Migration Guide

For Existing v1.0 Implementations

VCP v1.1 is protocol-compatible with v1.0. Your existing implementation will continue to work. However, to achieve v1.1 VC-Certified status, you may need to add:

Your Tier Required Changes
Silver Add External Anchoring (daily), Add Policy Identification
Gold Add Policy Identification, Verify anchoring meets requirements
Platinum Add Policy Identification, Verify anchoring meets requirements

Grace Period

Requirement Grace Period Hard Deadline
External Anchor (Silver) 6 months June 25, 2026
Policy Identification 3 months March 25, 2026

After the hard deadline, v1.0-only implementations will not receive VC-Certified status for new certifications.

Looking Ahead: Post-Quantum Cryptography

While not a normative requirement in v1.1, we've added Appendix E: Post-Quantum Cryptography Migration Guidance to help implementations prepare for the quantum era.

Recommended Approach: Dual Signatures

During the PQC transition period, implementations can use dual signatures:

{
  "Security": {
    "Signature": "base64(Ed25519_signature)",
    "SignAlgo": "ED25519",
    "PQCSignature": "base64(Dilithium2_signature)",
    "PQCSignAlgo": "DILITHIUM2"
  }
}

Migration Timeline (Advisory)

Phase Timeline Action
Preparation 2025-2026 Implement dual-signature capability
Hybrid 2027-2029 Deploy dual signatures in production
Transition 2030+ Phase out classical-only signatures

Conclusion: Verify, Don't Trust

VCP v1.1 strengthens our commitment to the principle of "Verify, Don't Trust."

By making External Anchoring mandatory for all tiers, we ensure that every VCP deployment—from a developer's MT5 backtesting environment to a high-frequency trading firm's production systems—provides the same fundamental guarantee:

A third party can verify the integrity of your audit trail without trusting you.

This is what algorithmic trading needs. This is what regulators are asking for.
And this is what VCP v1.1 delivers.

Resources

Get Involved

We welcome feedback on the v1.1 draft specification. Here's how to participate:

The v1.1 specification is in draft status. We plan to finalize and release the production version in Q1 2026 after incorporating community feedback.

"A civilization that can learn before accidents occur."

This article is provided by the VeritasChain Standards Organization (VSO) for technical educational purposes.

Contact: info@veritaschain.org

Share this article:

Explore VCP Resources

Learn more about VCP and how it addresses regulatory requirements.

Read the Spec Try Explorer Back to Blog