Executive Summary
Today, we publicly release the draft proposal for VeritasChain Protocol version 1.2 — the most comprehensive update since VCP's inception. This proposal represents a fundamental shift in how we think about cryptographic audit trails: from proving "this data wasn't tampered with" to answering "what happens when things go wrong in the real world?"
VCP v1.2 introduces seven normative changes and three informative additions that collectively transform the protocol from an experimental standard into production-ready infrastructure capable of handling the messy realities of enterprise deployment: system failures, regulatory compliance conflicts, service provider outages, and the operational needs of organizations ranging from three-person prop trading firms to global financial institutions.
We Need Your Feedback
This is a draft proposal. We are actively seeking community feedback before finalization. Your input — whether you're an implementer, regulator, auditor, or skeptic — will shape the final specification. Deadline: February 28, 2026.
The Story Behind v1.2
From Cryptographic Proof to Operational Reality
When we released VCP v1.0 in 2024, our focus was singular: create a tamper-evident audit trail for algorithmic trading systems. Hash chains provide sequential integrity. Merkle trees enable efficient verification. Digital signatures prove authenticity. External anchoring to public blockchains makes the entire chain independently verifiable.
The cryptography worked. The architecture was sound. But as we engaged with potential adopters — prop trading firms recovering from the 2024-2025 industry trust crisis, brokers seeking regulatory differentiation, exchanges exploring transparency initiatives — we encountered a pattern of questions that our elegant cryptographic design couldn't answer.
The "What If" Questions
From a CTO at a mid-sized prop firm:
"Your hash chain is great, but what happens when our server crashes at 3 AM and we lose 47 events? Do we just... start a new chain? How do auditors know that's legitimate and not us hiding something?"
From a compliance officer at an EU broker:
"We're required to keep records for 5 years under MiFID II. But GDPR says customers can demand deletion. Your immutable audit trail makes that impossible. Which law do we break?"
From a three-person trading team:
"We love the concept, but we're running MT4 on a VPS. We don't have HSMs. We don't have 24/7 ops. Is VCP only for big institutions?"
These weren't edge cases. These were fundamental operational realities that any production deployment would face. VCP v1.0 and v1.1 had built the cryptographic foundation. VCP v1.2 needed to build the operational framework.
Design Philosophy
Protocol-Compatible, Certification-Stricter
VCP v1.2 follows a deliberate design philosophy that we call "Protocol-Compatible, Certification-Stricter":
| Aspect | v1.2 Approach |
|---|---|
| Data Format | Fully backward compatible. v1.0/v1.1 events work with v1.2 verifiers. |
| New Features | Additive only. New event types and fields are optional. |
| Certification | Stricter requirements for VC-Certified badge. Closes loopholes. |
| Breaking Changes | Zero. No existing implementation breaks. |
The "Thicker Trail" Principle
When operational necessity requires deviation from the ideal cryptographic flow, the deviation itself must be documented with equal or greater rigor than normal operations.
Examples:
- SKIP operations (skipping corrupted events) are allowed, but with strict limits and mandatory logging
- Emergency checkpoints (resetting the chain during crises) require multi-party approval and post-incident review
- Data erasure (GDPR compliance) becomes a cryptographically verifiable event
Major Changes in Detail
1. VCP-RECOVERY Constraint Strengthening
VCP v1.1's recovery operations came with almost no constraints, creating a potential escape hatch for bad actors. VCP v1.2 introduces hard limits calibrated to each compliance tier:
| Tier | Max Events | Max Duration | Anchor Boundary Rule |
|---|---|---|---|
| Platinum | 10 events | 1 second | Cannot cross 10-minute anchor |
| Gold | 100 events | 1 minute | Cannot cross 1-hour anchor |
| Silver | 1,000 events | 1 hour | Cannot cross 24-hour anchor |
Emergency Override: Genuine emergencies require immediate action. VCP v1.2 creates an Emergency Override mechanism with minimum 2 approvers, detailed justification, incident reference, and mandatory 72-hour post-incident review.
2. ERASURE Event Type: Solving the GDPR Paradox
GDPR Article 17 requires the right to erasure. MiFID II requires 5-year retention. VCP requires immutability. These seem fundamentally incompatible.
VCP v1.2 resolves this through crypto-shredding:
- During normal operation: Personal data is encrypted with per-subject keys
- When erasure is required: The encryption key is destroyed (HSM zeroization)
- The ERASURE event: A new event documents the erasure with cryptographic proof
This is VCP's unique value proposition for EU compliance. Traditional audit logs force a choice between GDPR and record-keeping. VCP allows both simultaneously.
3. External Anchor Blockchain Selection Criteria
VCP v1.2 introduces a formal classification system:
| Class | History | Tier Applicability | Examples |
|---|---|---|---|
| A | ≥10 years | All tiers | Bitcoin, Ethereum |
| B | 5-10 years | All tiers | Polygon, Arbitrum |
| C | 2-5 years | Gold/Silver only | Solana, Base, Avalanche |
| D | <2 years | Silver only | Requires documented justification |
4. Anchor Target Continuity Plan
VCP v1.2 defines Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for anchor failures:
| Tier | Anchor Frequency | Max Outage | Failover Deadline |
|---|---|---|---|
| Platinum | 10 min | 10 min | 30 min |
| Gold | 1 hour | 2 hours | 4 hours |
| Silver | 24 hours | 48 hours | 7 days |
5. IETF SCITT Alignment
VCP v1.2 adds optional SCITTAlignment fields for interoperability with the Supply Chain Integrity, Transparency and Trust (SCITT) framework:
| VCP Concept | SCITT Concept |
|---|---|
| VCP Event | Signed Statement |
| VCP Chain | Append-Only Log |
| Merkle Proof | COSE Receipt |
| External Anchor | Transparency Service |
6. Latency Budget Clarification
VCP v1.2 separates operations into critical path (synchronous) and non-critical path (asynchronous):
7. Multi-Actor Chain Linking
Real-world trading involves more than two parties. VCP v1.2 extends VCP-XREF with topology awareness:
| Topology | Pattern | Example |
|---|---|---|
| BILATERAL | A ↔ B | Trader-Broker |
| LINEAR | A → B → C | Routed order |
| FAN_OUT | A → [B, C, D] | SOR execution |
| FAN_IN | [A, B, C] → D | Aggregation |
Silver Tier: Making Compliance Accessible
VCP v1.2 commits to making Silver Tier compliance achievable through SDK defaults alone:
What Silver Does NOT Require
| Feature | Required? |
|---|---|
| HSM | ❌ Software signing acceptable |
| Real-time anchoring | ❌ 24h batch is compliant |
| Automatic failover | ❌ Manual acceptable |
| Sub-millisecond latency | ❌ <100ms is compliant |
| Dedicated infrastructure | ❌ Shared hosting acceptable |
The goal: No organization should be unable to adopt VCP due to resource constraints. The technology should adapt to you, not the other way around.
What's NOT Changing
| Aspect | v1.2 Status |
|---|---|
| Hash Chain Algorithm | SHA-256 (unchanged) |
| Signature Algorithm | Ed25519 default (unchanged) |
| Merkle Tree Structure | RFC 6962 compliant (unchanged) |
| Event Schema | Additive changes only |
| Tier Structure | Platinum/Gold/Silver (unchanged) |
| Existing Events | v1.0/v1.1 events work with v1.2 verifiers ✓ |
Implementation Roadmap
VCP-RECOVERY constraints, Blockchain classification, Basic anchor continuity
ERASURE event type, Advanced anchor continuity, VCP-Regulatory profile
SCITT alignment, Multi-Actor XREF, Advanced verification APIs
Post-quantum algorithm support, Performance optimizations
Effort Estimates
| Feature | Engineering Weeks | Dependencies |
|---|---|---|
| RECOVERY constraints | 2-3 | None |
| Blockchain classification | 1 | Ops runbook |
| ERASURE event | 4-6 | HSM/KMS |
| SCITT alignment | 2-4 | COSE library |
| Silver SDK updates | <1 | None |
Call for Feedback
Who We Want to Hear From
| Stakeholder | Questions We'd Like Answered |
|---|---|
| Implementers | Are requirements achievable? What's missing? |
| Regulators | Does ERASURE address GDPR adequately? |
| Auditors | Are CAB requirements for Emergency Override sufficient? |
| Small teams | Is Silver Tier simple enough? |
| HFT firms | Are latency budgets realistic? |
| Skeptics | What attack vectors are we missing? |
How to Provide Feedback
- GitHub Discussion: veritaschain/vcp-spec/discussions
- Email: standards@veritaschain.org
- IETF SCITT ML: For SCITT alignment comments
- Direct meeting: Request via enterprise@veritaschain.org
Conclusion
VCP v1.2 represents the maturation of VeritasChain Protocol from an experimental standard to production-ready infrastructure. It addresses the real-world questions that every enterprise deployment must answer:
- What happens when systems fail? → RECOVERY constraints with audit trails
- How do we comply with GDPR? → ERASURE with crypto-shredding
- What if our anchor goes down? → Continuity plans with tier-specific RTO/RPO
- Is this only for big institutions? → Silver Tier with one-line SDK compliance
- How does this fit international standards? → IETF SCITT alignment
The cryptographic foundation remains unchanged. The operational framework is now complete.
Because "trust me" isn't good enough. Verify.
Resources
- Full Specification: VCP v1.2 Change Proposal v3
- GitHub: github.com/veritaschain
- Website: veritaschain.org
- IETF Draft: draft-kamimura-scitt-vcp
Contact
- General inquiries: info@veritaschain.org
- Technical questions: technical@veritaschain.org
- Standards feedback: standards@veritaschain.org
- Enterprise partnerships: enterprise@veritaschain.org
Document ID: VSO-BLOG-2026-001 | Version: 1.0 | Status: DRAFT | License: CC BY 4.0