A SCITT Profile for Verifiable Audit Trails in Algorithmic Trading: The VeritasChain Protocol (VCP)

A SCITT Profile for Verifiable Audit Trails in Algorithmic Trading: The VeritasChain Protocol (VCP) VeritasChain Standards Organization

Japan kamimura@veritaschain.org https://veritaschain.org

Security Supply Chain Integrity, Transparency, and Trust SCITT audit trail algorithmic trading AI transparency financial services transparency service signed statement profile This document defines a profile of the SCITT (Supply Chain Integrity, Transparency, and Trust) architecture for creating tamper-evident audit trails of AI-driven algorithmic trading decisions and executions. The VeritasChain Protocol (VCP) applies the SCITT framework to address the specific requirements of financial markets, including high-precision timestamps, considerations arising from recordkeeping regimes such as the EU AI Act and MiFID II, and a crypto-shredding mechanism intended to support erasure obligations such as those under the GDPR. This profile specifies how VCP events are encoded as SCITT Signed Statements, registered with Transparency Services, and verified using COSE Receipts. It further defines SCITT conformance profiles for interoperability and an ERASURE event type that records crypto-shredding operations as append-only audit events. The profile makes trading records auditable and attributable after the fact; it does not prevent or block any trading activity, and it does not warrant the correctness of any recorded decision. About This Document The latest version of this document, along with implementation resources and test vectors, can be found at . Discussion of this document takes place on the SCITT Working Group mailing list (scitt@ietf.org). Changes from -04 are listed in , and changes from -03 in . The principal changes in -04 align this profile with the VCP v1.2 release (tag v1.2.0): external anchoring is REQUIRED at every tier, and ERASURE uses the released ErasureDetails encoding.

Introduction The SCITT (Supply Chain Integrity, Transparency, and Trust) architecture provides a framework for creating tamper-evident logs of digital artifacts through Transparency Services. While SCITT was initially designed for software supply chain use cases, its core primitives--Signed Statements, Receipts, and Transparency Services--are applicable to any domain requiring verifiable audit trails. This document specifies a SCITT profile for AI-driven algorithmic trading systems in financial markets. The VeritasChain Protocol (VCP) applies the SCITT architecture with domain-specific extensions:

A schema for encoding trading events as SCITT Signed Statements
Registration policies for financial audit trails
Conformance tiers (Silver, Gold, Platinum) with varying requirements for timing precision, anchoring frequency, and key protection
A crypto-shredding mechanism intended to support data erasure obligations
A completeness-aware design that enables omission detection through external anchoring

VCP serves as an "AI Flight Recorder" for algorithmic trading, supporting post-incident reconstruction of recorded system behavior with cryptographic evidence that the records were not altered after commitment. It cannot reconstruct events that were never recorded.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Relationship to SCITT This document is a profile of the SCITT architecture. It:

REQUIRES compliance with
REQUIRES use of SCRAPI for Transparency Service interactions
RECOMMENDS COSE Receipts for inclusion proofs
DEFINES domain-specific extensions for financial trading

This profile does not define a new SCITT protocol or new Transparency Service interactions; it specifies how existing SCITT primitives are applied to VCP events in the financial trading domain. The VCP event format and integrity layer are defined in .

Scope This document specifies:

VCP Event schema as SCITT Signed Statement payload
Registration Policy requirements for VCP Transparency Services
Mapping of VCP concepts to SCITT terminology
Three conformance tiers with specific requirements
Crypto-shredding mechanism to support erasure obligations
Three-layer integrity architecture

This document does not specify:

General SCITT architecture (see )
SCRAPI endpoints (see )
COSE Receipt format (see )
Specific regulatory mapping (covered in companion documents)
A particular anchoring service (the anchor target is deployment-specific; anchoring itself is REQUIRED)

Terminology This document uses terminology from . The following terms are specific to this profile:

VCP Event: A single auditable record in the VeritasChain Protocol, encoded as a SCITT Signed Statement. Consists of Header, Payload, and Security metadata.
VCP Issuer: An algorithmic trading system, AI model, or human operator that generates VCP Events. Corresponds to SCITT Issuer.
VCP Transparency Service: A SCITT Transparency Service configured with VCP-specific Registration Policies. Operates a VCP-compliant append-only log.
VCP Receipt: A COSE Receipt issued by a VCP Transparency Service, proving inclusion of a VCP Event in the log.
Actor: An entity (algorithm, human operator, or system) identified by ActorID that generates VCP Events.
Crypto-Shredding: A privacy technique where encrypted payload data is rendered permanently unrecoverable by destroying the encryption key, while preserving the cryptographic integrity proofs (hashes and Receipts).
Conformance Tier: One of three implementation levels (Silver, Gold, Platinum) with increasing requirements for timing precision, anchoring frequency, and key protection.
External Anchor: A cryptographic commitment (typically a Merkle root) published to an external, independent system (e.g., public blockchain, timestamping authority). External anchoring makes omission of events from an anchored batch, after anchoring, detectable by third parties at batch granularity.
Policy Identification: A field within the VCP Event that explicitly identifies the applicable Registration Policy and conformance tier.

SCITT Terminology Mapping The following table maps VCP concepts to SCITT terminology: VCP to SCITT Terminology Mapping

VCP Concept	SCITT Equivalent	Notes
VCP Event	Signed Statement	VCP Event is the payload of a Signed Statement
VCP Issuer	Issuer	Trading system or AI model
VCP Transparency Service	Transparency Service	With VCP Registration Policy
VCP Receipt	Receipt	COSE Receipt with Merkle inclusion proof
Hash Chain (Optional)	Append-only Log	VCP optionally adds per-Actor chaining
External Anchor	Merkle Tree Root	Periodic commitment supporting completeness verification

Event Flow

Event Generation: VCP Issuer creates a VCP Event containing trading decision or execution data.
Signing: Event is signed using COSE_Sign1 with the Issuer's private key.
Registration: Signed Statement is submitted to VCP Transparency Service via SCRAPI POST /entries.
Validation: Transparency Service validates against VCP Registration Policy.
Logging: Valid statement is appended to the append-only log.
Receipt: COSE Receipt with Merkle inclusion proof is returned to Issuer.
External Anchoring: The Merkle root MUST be periodically anchored to an external system at the frequency of the applicable tier (), making post-anchor omission detectable by third parties.

Per-Actor Hash Chain (Optional) VCP MAY maintain per-Actor hash chains in addition to SCITT's global append-only log. When implemented, each VCP Event includes a PrevHash field containing the hash of the previous event from the same Actor. This enables efficient verification of a single Actor's event sequence without downloading the entire log. Note: Per-Actor hash chains are OPTIONAL. External anchoring of batch roots provides the primary mechanism for completeness verification at batch granularity. Hash chains serve as a complementary local integrity mechanism. Event_A2 --hash--> Event_A3 Actor B: Event_B1 --hash--> Event_B2 Global Log: [Event_A1, Event_B1, Event_A2, Event_B2, Event_A3, ...] ]]>

Three-Layer Integrity Architecture VCP defines a three-layer architecture that separates concerns and clarifies where each integrity property originates: VCP Three-Layer Architecture

Layer	Component	Property	Protocol Requirement
Layer 1	Event Integrity	Individual event authenticity via digital signature	REQUIRED
Layer 2	Collection Integrity	Merkle tree over event collection	REQUIRED
Layer 3	External Verifiability	Merkle root anchored to external system	REQUIRED

Note: Layer 3 (External Verifiability) is REQUIRED at every tier, as in VCP v1.2 . Revisions -02 and -03 of this document described it as OPTIONAL at the protocol level; that description did not match the VCP specification and is withdrawn. Lightweight or delegated anchoring mechanisms are acceptable at the Silver tier. External anchoring makes post-anchor omission detectable: without it, a log producer could rebuild a batch and publish a different Merkle root. Anchoring lets third parties check a presented root against an independently recorded commitment, supporting the "Verify, Don't Trust" principle. It does not reveal events that were never included in a batch.

VCP Event Schema A VCP Event is encoded as the payload of a SCITT Signed Statement. The payload MUST be a JSON object conforming to the following schema:

Header Object The Header contains metadata common to all VCP Events:

EventID: REQUIRED. UUID v7 providing time-sortable unique identification.
TimestampISO: REQUIRED. ISO 8601 timestamp with nanosecond precision.
TimestampInt: REQUIRED. Integer timestamp in nanoseconds since Unix epoch. Values exceed 2^53, so a parser that does not preserve 64-bit integer precision alters them. See regarding canonicalization.
EventType: REQUIRED. Registered event type code (see ).
ActorID: REQUIRED. Identifier of the entity generating this event.
ChainID: REQUIRED. Identifier of the per-Actor hash chain.
SequenceNum: REQUIRED. Monotonically increasing sequence number within the Actor's chain.
PolicyID: REQUIRED. Identifier of the Registration Policy under which the event is registered. Per VCP v1.2 , PolicyID SHOULD follow the Issuer Domain + Local ID convention (reverse_domain:local_identifier), for example "org.veritaschain.policy:gold-v1-2". Global uniqueness is achieved through domain ownership; no central PolicyID registry is operated.

Payload Object The Payload contains domain-specific data organized into modules:

VCP-TRADE: Trading data: orders, executions, modifications, cancellations.
VCP-RISK: Risk management data: exposure, limits, margin.
VCP-GOV: Governance data: algorithm parameters, decision factors, operator actions.
VCP-PRIVACY: Privacy metadata: encryption keys, retention policies.

Security Object The Security object contains integrity and chaining information:

EventHash: REQUIRED. SHA-256 hash of the canonicalized Header and Payload, computed using JSON Canonicalization Scheme .
PrevHash: OPTIONAL. Hash of the previous event in this Actor's chain. If present, MUST match the EventHash of the preceding event (except for INIT events where it is absent).
MerkleRoot: OPTIONAL in individual events. Included in anchor (ANC) events.
SignAlgo: REQUIRED. Signature algorithm identifier. MUST be "ED25519" (default) or "DILITHIUM2", the VCP v1.2 registry value for ML-DSA . DILITHIUM2 carries EXPERIMENTAL status in VCP v1.2 and is intended for testing and hybrid (classical plus post-quantum) deployments; it is not a certification requirement.
AnchorRef: OPTIONAL. Reference to the anchor location (e.g., blockchain transaction ID, TSA receipt ID), populated once the batch containing the event has been anchored. See on the corresponding field in .

SCITT Alignment Object VCP v1.2 defines an OPTIONAL SCITTAlignment object carried in the Header. It makes the binding between a VCP Event and its SCITT artifacts (Signed Statement, Transparency Service, Receipt) explicit and machine-readable. Field presence is governed by conformance profiles: SCITT Alignment Conformance Profiles

Profile	SCITTAlignment	Intended Use
VCP_BASE	OPTIONAL	Standard VCP deployment
VCP_SCITT	REQUIRED	SCITT Transparency Service interoperability
VCP_REGULATORY	RECOMMENDED	Regulatory reporting scenarios

Implementations claiming the VCP_SCITT profile MUST include the SCITTAlignment object in every registered event; this profile-based approach avoids partial-implementation ambiguity.

Version: REQUIRED when present. VCP specification version governing the alignment semantics ("1.2").
ConformanceProfile: REQUIRED when present. One of "VCP_BASE", "VCP_SCITT", or "VCP_REGULATORY".
StatementID: OPTIONAL. Identifier of the SCITT Signed Statement carrying this event.
TransparencyServiceID: OPTIONAL. Identifier of the Transparency Service with which the event is registered. REQUIRED under the VCP_SCITT profile.
ReceiptFormat: OPTIONAL. Receipt encoding in use; "COSE_RECEIPT" designates COSE Receipts as specified by the SCITT architecture .
RegistrationPolicy: OPTIONAL. Structured reference to the Registration Policy (PolicyID, Issuer, IssuedAt) mirroring the Header-level PolicyID.

Event Types VCP Event Types

Code	Name	Description
INIT	Initialization	Chain initialization, no PrevHash
SIG	Signal	Trading signal generated
ORD	Order	Order submitted
ACK	Acknowledgment	Order acknowledged by venue
EXE	Execution	Order executed (fill)
CXL	Cancellation	Order cancelled
MOD	Modification	Order modified
RSK	Risk	Risk event or limit breach
ERR	Error	System error
ERR_*	Error subtypes	ERR_CONN, ERR_AUTH, ERR_TIMEOUT, ERR_REJECT, ERR_PARSE, ERR_SYNC, ERR_RISK, ERR_SYSTEM, ERR_RECOVER
HBT	Heartbeat	Periodic liveness signal
CLS	Close	Position closed
ANC	Anchor	Merkle anchor event
ERASURE	Erasure	Crypto-shredding record (VCP v1.2, see )
SYS_RECOVERY_ANNOUNCE	Recovery announcement	Planned CHECKPOINT notice (Payload.VCP-RECOVERY.Announcement)
SYS_CHECKPOINT	Checkpoint	Recorded chain reset with authorized recovery action (Payload.VCP-RECOVERY)
SYS_AUDIT	Audit	Post-incident review (Payload.VCP-GOV.AuditDetails)
SYS_ANCHOR_MIGRATION	Anchor migration	Anchor transition and phase (Payload.VCP-ANCHOR.MigrationDetails)
SYS_ANCHOR_FAILOVER	Anchor failover	Anchor failover and queued-event inventory (Payload.VCP-ANCHOR.FailoverDetails)

The five SYS_* codes were registered by the VCP v1.2 release; their structured payload locations and runtime requirements are defined in the normative annex of . Validators written against pre-release v1.2 artifacts need updating to accept them.

Registration Policy A VCP Transparency Service MUST enforce a Registration Policy that validates incoming Signed Statements.

Policy Identification The PolicyID field MUST be explicitly included in the VCP Event Header. The Transparency Service MUST validate the registration request against the referenced Registration Policy and MUST NOT infer, select, or substitute a policy on its own. PolicyID values SHOULD follow the Issuer Domain + Local ID convention defined in VCP v1.2 : the reverse DNS notation of the Issuer's domain, a colon, and an issuer-defined local identifier. Examples:

org.veritaschain.policy:silver-v1-2
org.veritaschain.policy:gold-v1-2
org.veritaschain.policy:platinum-v1-2

Uniqueness derives from domain ownership; no central PolicyID registry is operated. Organizations without a domain MAY use a "local:" prefix at the cost of weaker uniqueness. Conformance tiers (Silver, Gold, Platinum) represent additional verification depth and operational requirements applied on top of the same core Registration Policy, and do not define separate or incompatible registration policies.

Validation Requirements The Registration Policy MUST verify:

Schema Compliance: Payload conforms to VCP Event schema.
PolicyID Present: Header contains a valid PolicyID field.
Signature Validity: COSE_Sign1 signature is valid for the registered Issuer public key.
Timestamp Validity: TimestampInt is within acceptable bounds (not in future, not too old).
Chain Integrity (if PrevHash present): PrevHash matches the hash of the most recent event from this Actor.
Sequence Monotonicity: SequenceNum is exactly one greater than the previous event's SequenceNum.

Tier-Specific Requirements This specification distinguishes timestamp resolution from clock accuracy. Nanosecond-resolution timestamps represent the storage format capability, while actual clock accuracy is explicitly recorded and enforced per tier. Conformance Tier Requirements

Requirement	Silver	Gold	Platinum
Timestamp Resolution	Millisecond	Microsecond	Nanosecond
Clock Synchronization	Best-effort	NTP (<1ms)	PTPv2 (<1 microsecond)
External Anchoring (REQUIRED)	Every 24 hours	Every hour	Every 10 minutes
Signature Algorithm	Ed25519	Ed25519	Ed25519 + Dilithium (OPTIONAL)
Key Storage	Software	Software/HSM	HSM Required
PrevHash Chain	OPTIONAL	OPTIONAL	RECOMMENDED

Note: Silver tier is NOT intended for regulatory-grade algorithmic trading systems subject to MiFID II RTS 25, SEC Rule 17a-4, or equivalent clock synchronization requirements. Silver tier is appropriate for development, testing, backtesting analysis, and non-regulated trading scenarios.

Certification Policy Requirements This document does not mandate a specific external anchoring service; it requires anchoring at the frequency of each tier. Each AnchorRecord binds the batch Merkle root, event count, first and last event identifiers, and PolicyID (see on the scope of the AnchorRecord signature). Implementations retain local copies of all AnchorRecords and document an anchor continuity plan, as defined in . Certification programs may impose requirements beyond this profile, such as multiple independent anchors. Certification requirements are defined separately from this document and may evolve independently of it. Implementations may conform to this profile without obtaining certification. Acceptable anchor targets include:

Trusted timestamping authorities (TSA) per
SCITT Transparency Services, with COSE Receipts per
Public blockchains (e.g., Bitcoin, Ethereum)
Public timestamping services and attested databases, at the tiers where permits them

A time-stamping authority attests existence time; by itself it does not show that the same root was presented to every verifier.

Crypto-Shredding VCP supports crypto-shredding as a technical mechanism that can support erasure obligations while preserving audit trail integrity. It renders protected plaintext irrecoverable without invalidating cryptographic proofs. Whether it satisfies a specific legal obligation is not determined by this document.

Mechanism

Encryption: Sensitive payload fields are encrypted with a per-record or per-subject Data Encryption Key (DEK).
Key Storage: DEK is stored separately, indexed by SubjectID.
Hashing: EventHash is computed over the encrypted payload, preserving integrity.
Shredding: Upon erasure request, DEK is destroyed. Encrypted data becomes unrecoverable.
Verification: Receipt and hash chain remain valid--verifiers can confirm event existence and ordering without accessing decrypted content.

VCP-PRIVACY Module

ERASURE Event Type VCP v1.2 defines the ERASURE event type to reconcile erasure obligations (such as GDPR Article 17) with append-only, tamper-evident audit trails. An ERASURE event does not delete or rewrite any prior event. It records, as a new append-only event, that the plaintext of specified protected fields has been rendered irrecoverable through crypto-shredding (destruction of the Data Encryption Key), while the EventHash, Merkle inclusion, and external anchor of the target events remain verifiable. In the VCP v1.2 release, an ERASURE event MUST carry its details in Payload.VCP-PRIVACY.ErasureDetails, with the seven REQUIRED members below. ErasureDetails at the event root or directly under Payload is invalid. The flat ERASURE fields described in -03 of this document (ErasureTargetEventIDs, ErasureReason, KeyDestructionProof, RetentionExemption, OperatorID) reflected pre-release artifacts and are not a v1.2 encoding. Historical signed data is not rewritten. The normative annex of states how pre-release records are handled; it defines no lossless automatic conversion to the v1.2 encoding. ErasureDetails Members (all REQUIRED)

Member	Content
Version	The literal "1.2"
TargetIdentifier	Type (ACCOUNT, SESSION or EVENT_RANGE), salted SHA-256 Hash, and Salt
Scope	AffectedEventCount, FirstAffectedEventID, LastAffectedEventID and AffectedFields; EventIDs MAY enumerate the exact affected set
Reason	Code, Description, LegalBasis and a SHA-256 RequestReferenceHash
Authorization	Authorizing role, signature, nanosecond timestamp and DPO notification
CryptoShredding	SHA-256 hash of the key identifier, key algorithm, destruction method and nanosecond destruction timestamp
Verification	PreErasureEventHash and PostErasureChainHash

Reason codes are GDPR_ART_17_1A, GDPR_ART_17_1B, GDPR_ART_17_1C, GDPR_ART_17_1D, RETENTION_EXPIRED, SUBJECT_REQUEST, COURT_ORDER and ERROR_CORRECTION. Destruction methods are HSM_ZEROIZE, SECURE_DELETE and CLOUD_KMS_DESTROY. Authorization MUST precede or equal destruction, which MUST precede or equal the ERASURE event timestamp. The ERASURE event's own Merkle inclusion proof is detached (Evidence Pack or Receipt), not embedded in its hashed payload. Schema validation checks the structure of this evidence, not the truth of the destruction. The following abbreviated example follows the structure of the release fixture; hashes, signatures and certificates are placeholders: ERASURE provides a technical mechanism that supports erasure obligations; it is not a legal determination. Whether crypto-shredding qualifies as erasure under a given regime is jurisdiction- and case-dependent. Deployments subject to reproduction-oriented recordkeeping rules (such as SEC Rule 17a-4 audit-trail controls) should note that once a DEK is destroyed the original plaintext is, by design, not re-creatable. Where a retention duty prevents deletion, a successful ERASURE event is not emitted for data that remains decryptable. The legal basis and any retention override recorded with an erasure require verification outside the event schema .

SCRAPI Integration VCP Transparency Services MUST implement SCRAPI with the following VCP-specific considerations:

Registration (POST /entries) VCP Events are submitted as COSE_Sign1 Signed Statements: ]]> The Transparency Service validates the VCP Registration Policy and returns a COSE Receipt on success.

Retrieval (GET /entries/{entry_id}) Retrieve a specific VCP Event by its entry ID (derived from EventID).

Receipt (GET /entries/{entry_id}/receipt) Retrieve the COSE Receipt for a registered VCP Event, containing the Merkle inclusion proof.

Anchor Status (GET /anchors/{anchor_id}) Retrieve the anchor status for a Merkle root, including the external reference (e.g., blockchain transaction ID or TSA token).

Security Considerations

Integrity Architecture VCP's three-layer architecture provides defense in depth:

Layer 1 (Event Integrity): Digital signatures on individual events make forgery without the signing key detectable.
Layer 2 (Collection Integrity): Merkle trees enable efficient proof of inclusion.
Layer 3 (External Verifiability): External anchoring makes post-anchor omission detectable by enabling third parties to check presented Merkle roots against independent records.

The optional per-Actor hash chain provides additional local integrity checks but is not required for external verifiability. Mitigations against key compromise:

Frequent Merkle anchoring to external append-only stores
HSM-based key storage (Platinum tier requirement)
Key rotation with explicit ROTATE events

Quantum Resistance Ed25519 signatures are vulnerable to attacks by cryptographically relevant quantum computers. VCP provides crypto-agility to address future threats:

SignAlgo field enables algorithm negotiation and migration
The DILITHIUM2 registry value (ML-DSA ) holds EXPERIMENTAL status in VCP v1.2: available for testing and hybrid (classical plus post-quantum) deployments, with Ed25519 remaining the default and no certification requirement attached
Hash chain integrity based on SHA-256 provides approximately 128-bit post-quantum security against Grover's algorithm

Implementers requiring post-quantum assurance SHOULD monitor CFRG and PQUIP working group outputs for updated guidance on algorithm selection and migration timelines.

Timing Attacks Clock manipulation can enable backdating of events. Mitigations:

UUID v7 provides embedded timestamp that must match TimestampInt
Transparency Service enforces timestamp bounds
Platinum tier requires PTPv2 synchronization
External anchoring provides independent timestamp attestation

Privacy Considerations VCP Events may contain sensitive trading information. Operators SHOULD:

Use crypto-shredding for personal data subject to GDPR
Implement access controls on Transparency Service queries
Consider encrypted payloads for highly sensitive data

Completeness Considerations SCITT provides inclusion proofs but does not by itself establish completeness (i.e., that no events have been omitted). VCP adds the following:

Sequence numbers enable detection of gaps within an Actor's chain
External anchoring of batch roots, with AnchorRecords binding event count, first and last event identifiers and PolicyID, enables third-party detection of omission after anchoring
Heartbeat events (HBT) provide liveness signals that support detection of extended omission periods

These mechanisms make omission detectable at batch granularity and within the anchoring window; they do not establish that every event that occurred was recorded. An event that was never recorded is detectable only through another record that implies it, such as an order without a corresponding acknowledgment or a counterparty record. The completeness window implied by the tier's anchoring frequency should be disclosed when records are presented.

Open Issues A comparison of the VCP v1.2 integrity layer with the VAP v1.2 framework requirements, published as an unadopted research observation record , identified the following discrepancies. They are not resolved by this revision.

Local batch Merkle construction. requires Merkle tree construction to follow RFC 6962, but its reference code duplicates an odd node, which yields roots that differ from those of for batch sizes that are not a power of two, and its audit path generation omits that node. Which construction governs, and how roots already computed with the reference code are treated, is not decided by this revision. The question concerns local batch trees only: inclusion in a SCITT Transparency Service's log is shown by COSE Receipts under the verifiable data structure that the Transparency Service uses.
AnchorRecord signature scope. The reference signing procedure signs the Merkle root bytes only, so the event count, endpoints and PolicyID carried in the AnchorRecord are not covered by that signature. The signed bytes of the AnchorRecord remain to be defined.
Integer timestamps. TimestampInt and other nanosecond values are JSON integers that can exceed 2^53, whereas requires numbers to be expressible as IEEE 754 doubles and recommends encoding larger integers as strings. Values that are not exactly representable as a double, such as the TimestampInt 1742034600123456789 in , cannot be canonicalized by RFC 8785 without changing them.
EventHash notation. Examples and fixtures write EventHash with a "sha256:" prefix, while the reference computation yields a bare hexadecimal digest.
Security object fields. This document names the anchor reference AnchorRef, lists MerkleRoot as OPTIONAL in individual events, and has no MerkleIndex. In , the specification text names the field AnchorReference and lists AnchorReference, MerkleRoot and MerkleIndex as REQUIRED from VCP v1.1, whereas the v1.2 JSON schema accepts both AnchorRef and AnchorReference and treats the three fields as VC-Certified requirements enforced by Registration Policy rather than as protocol-level requirements. The canonical name and the requirement level are not decided by this revision, and the fields here are unchanged.

Implementation Status Note to the RFC Editor: please remove this section before publication. This section records the status of known implementations at the time of posting, following . The listing of any individual implementation here does not imply endorsement by the IETF, and the information presented here has not been verified by the IETF. Other implementations may exist.

There are no known external implementations of this profile or of VCP.
VSO publishes first-party implementations: VCP-RTA, a reference implementation of VCP v1.1 event logging at the Silver tier, and proof-of-concept repositories for cTrader, FIX, Interactive Brokers, Nasdaq and Cloudflare. VCP-RTA does not produce COSE_Sign1 Signed Statements or register them with a Transparency Service, and it does not implement VCP v1.2. The proof-of-concept repositories have not been assessed against this profile.
No Evidence Pack produced under VCP has been accepted in any regulatory, judicial, or audit proceeding.

IANA Considerations This document has no IANA actions at this time. Future versions of this specification may request:

Registration of media type "application/vcp+json"
Establishment of a VCP Event Type registry
COSE algorithm identifiers for VCP-specific extensions

References Normative References Key words for use in RFCs to Indicate Requirement Levels Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words JSON Canonicalization Scheme (JCS) CBOR Object Signing and Encryption (COSE) Universally Unique IDentifiers (UUIDs) VeritasChain Protocol (VCP) Specification, Version 1.2, with normative annex VSO-SPEC-CHANGE-001 VeritasChain Standards Organization Release tag v1.2.0 (GA consistency correction of 2026-10-09). Informative References Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) Certificate Transparency VCP v1.2 / VAP v1.2 integrity-layer observations (research observation, unadopted) VeritasChain Standards Organization Module-Lattice-Based Digital Signature Standard (ML-DSA) National Institute of Standards and Technology

Complete VCP Event Example The following is a complete VCP v1.2 Event encoded as JSON, ready to be wrapped in a COSE_Sign1 Signed Statement: Note: PrevHash is OPTIONAL. AnchorRef is populated once the batch containing the event has been anchored. Numeric values other than the integer Header fields are encoded as strings.

JSON Schema Reference The complete JSON Schema for VCP Events is available at:

Changes from draft-kamimura-scitt-vcp-04

Corrected Open Issue 5: -04 stated that VCP-SPEC makes AnchorReference, MerkleRoot and MerkleIndex REQUIRED. The specification text does so, but the VCP v1.2 JSON schema accepts AnchorRef as well and treats the three fields as certification requirements
Editorial: removed the submissionType attribute (the existing versions have no stream on the Datatracker), stated the document date, and replaced non-ASCII characters

Changes from draft-kamimura-scitt-vcp-03

External anchoring is REQUIRED at every tier, matching VCP v1.2; the -02/-03 description of anchoring as OPTIONAL at the protocol level is withdrawn
Tier table aligned with VCP v1.2: anchoring every 24 hours, hour and 10 minutes; clock synchronization best-effort, NTP (<1ms) and PTPv2 (<1 microsecond)
ERASURE rewritten to the released Payload.VCP-PRIVACY.ErasureDetails encoding with seven REQUIRED members, reason codes and destruction methods; the pre-release flat fields are identified as not a v1.2 encoding
Added the ERR_* subtypes and the five SYS_* event types registered by the VCP v1.2 release
Replaced draft-ietf-scitt-architecture with RFC 9943; updated the SCRAPI reference; added RFC 9942 and RFC 9162
Added Open Issues (Merkle construction, AnchorRecord signature scope, integer timestamps, EventHash notation) and an Implementation Status section (RFC 7942)
Replaced "immutable" with "append-only" and qualified completeness and integrity statements; numeric example values encoded as strings
VCP-SPEC reference pinned to the v1.2.0 release tag and moved to the normative references
Removed the VC-Certified tier list of -03, whose anchoring frequencies (including per-minute anchoring at Platinum) did not match VCP v1.2. This also removes the -03 statement that Platinum certification REQUIRES multiple independent anchors with geographic distribution, and the statement that implementations MAY be protocol-compliant without certification; the latter is restated without BCP 14 keywords
The AnchorRef requirement level (OPTIONAL) is unchanged; the difference from the VCP-SPEC field name and level is recorded as an open issue
Removed statements that the profile is compatible with GDPR or provides privacy compliance; whether crypto-shredding satisfies a legal obligation is not determined by this document

Changes from draft-kamimura-scitt-vcp-02 This section summarizes the changes from version -02 to -03. All changes align this profile with VCP Specification v1.2 .

Added the SCITT Alignment Object as an OPTIONAL Header extension, together with the VCP_BASE, VCP_SCITT, and VCP_REGULATORY conformance profiles (Section 4.4)
Added the ERASURE event type, which records crypto-shredding operations as audit events (Section 6.3), and registered it in the event type table
Corrected the post-quantum SignAlgo value: -02 listed "DILITHIUM3", which does not exist in the VCP SignAlgo registry; the registry value is "DILITHIUM2" (ML-DSA, FIPS 204), holding EXPERIMENTAL status in v1.2
Migrated PolicyID examples from the provisional "urn:vcp:policy" form to the Issuer Domain + Local ID convention defined in VCP v1.2, and removed the corresponding URN-namespace item from IANA Considerations
Updated the complete event example (Appendix A) and the JSON Schema reference (Appendix B) to v1.2

Changes from draft-kamimura-scitt-vcp-01 This section summarizes the changes from version -01 to -02:

Updated title to explicitly indicate this is a SCITT profile
Updated to align with VCP Specification v1.1
Clarified that external anchoring is a certification policy requirement, not a protocol-level mandate (new Section 5.4)
PrevHash changed from REQUIRED to OPTIONAL
Added Three-Layer Architecture section (Section 3.3)
Added PolicyID as a REQUIRED field in the Header
Added Completeness Considerations section (Section 8.5)
Clarified that this profile does not define a new protocol
Removed unused informative references

Acknowledgements The authors thank the members of the VeritasChain Standards Organization Technical Committee for their contributions to this specification. This work builds upon the SCITT architecture developed by the IETF SCITT Working Group, and the Certificate Transparency work in . Special thanks to the SCITT WG participants who provided feedback on draft-kamimura-scitt-vcp-01, which informed the improvements in this version.