VeritasChain Standards Organization

Tokyo 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 This document defines a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for creating tamper-evident audit trails of AI-driven algorithmic trading decisions and executions. The VeritasChain Protocol (VCP) extends the SCITT architecture to address the specific requirements of financial markets, including nanosecond-precision timestamps, regulatory compliance with EU AI Act and MiFID II, and privacy-preserving mechanisms (crypto-shredding) for GDPR compliance. This profile defines how VCP events are encoded as SCITT Signed Statements, registered with Transparency Services, and verified using COSE Receipts. 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).

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 how SCITT can be applied to the domain of AI-driven algorithmic trading systems in financial markets. The VeritasChain Protocol (VCP) defines:

• 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 and cryptographic guarantees
• Privacy mechanisms compatible with GDPR data erasure requirements

VCP serves as an "AI Flight Recorder" for algorithmic trading, enabling post-incident reconstruction of system behavior with cryptographic proof of integrity.

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

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 for privacy compliance

This document does not specify:

• General SCITT architecture (see )
• SCRAPI endpoints (see )
• COSE Receipt format (see )
• Specific regulatory mapping (covered in companion documents)

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 cryptographic guarantees.

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	Append-only Log	VCP adds per-Actor chaining
Merkle Anchor	Merkle Tree Root	Periodic commitment

Architecture VCP builds upon the SCITT architecture with domain-specific extensions for financial trading: | | (via SCRAPI) | | | 3. Validate against | | Registration Policy | | | | 4. Append to Log | | |<-------- VCP Receipt --------+ | (COSE Receipt) | | | +--------+---------+ +------------+------------+ | Verifier | | External Anchor | | (Auditor/Regul.) | | (Timestamp/Blockchain) | +------------------+ +-------------------------+ ]]>

Event Flow

1. Event Generation: VCP Issuer creates a VCP Event containing trading decision or execution data.
2. Signing: Event is signed using COSE_Sign1 with the Issuer's private key.
3. Registration: Signed Statement is submitted to VCP Transparency Service via SCRAPI POST /entries.
4. Validation: Transparency Service validates against VCP Registration Policy.
5. Logging: Valid statement is appended to the append-only log.
6. Receipt: COSE Receipt with Merkle inclusion proof is returned to Issuer.

Per-Actor Hash Chain In addition to SCITT's global append-only log, VCP maintains per-Actor hash chains. 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. Event_A2 --hash--> Event_A3 Actor B: Event_B1 --hash--> Event_B2 Global Log: [Event_A1, Event_B1, Event_A2, Event_B2, Event_A3, ...] ]]>

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.

EventType

REQUIRED. Three-letter code identifying the event type (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.

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

REQUIRED (except for INIT events). Hash of the previous event in this Actor's chain.

MerkleRoot

OPTIONAL. Merkle root of the current batch (Gold/Platinum tiers).

SignAlgo

REQUIRED. Signature algorithm identifier. MUST be "ED25519" or "DILITHIUM3" (for post-quantum).

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
HBT	Heartbeat	Periodic liveness signal
CLS	Close	Position closed
ANC	Anchor	Merkle anchor event

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

Policy Identification The Registration Policy identifier MUST be explicitly included in the Signed Statement payload or associated metadata. 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. Conformance tiers (e.g., 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:

1. Schema Compliance: Payload conforms to VCP Event schema.
2. Signature Validity: COSE_Sign1 signature is valid for the registered Issuer public key.
3. Timestamp Validity: TimestampInt is within acceptable bounds (not in future, not too old).
4. Chain Integrity: PrevHash matches the hash of the most recent event from this Actor (if not INIT).
5. 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 Accuracy	NTP (~10ms)	NTP + drift (~1ms)	PTPv2 (<1μs)
Merkle Anchoring	Daily	Hourly	Per-minute
Signature Algorithm	Ed25519	Ed25519	Ed25519 + Dilithium (OPTIONAL)
Key Storage	Software	Software/HSM	HSM Required
External Anchor	Optional	Recommended	Required

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.

Crypto-Shredding for Privacy Compliance VCP supports crypto-shredding to enable GDPR-compliant data erasure while preserving audit trail integrity. This mechanism allows deletion of personal data without invalidating cryptographic proofs.

Mechanism

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

VCP-PRIVACY Module

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.

Security Considerations

Chain Integrity The per-Actor hash chain construction provides tamper evidence: modification of any event invalidates all subsequent hashes in that Actor's chain. Combined with SCITT's global append-only log and Merkle tree, this provides defense in depth. Mitigations against key compromise:

• Frequent Merkle anchoring to external immutable 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
• Post-quantum signature algorithms (e.g., ML-DSA/Dilithium) are OPTIONAL and intended for experimental or high-assurance deployments
• Hash chain integrity based on SHA-256 provides approximately 128-bit post-quantum security against Grover's algorithm

Implementers requiring post-quantum guarantees 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

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 Informative References European Parliament and Council European Parliament and Council NIST

Complete VCP Event Example The following is a complete VCP Event encoded as JSON, ready to be wrapped in a COSE_Sign1 Signed Statement:

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

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 .