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

1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.2. Relationship to SCITT

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

• REQUIRES compliance with [RFC9943]¶
• REQUIRES use of SCRAPI [I-D.ietf-scitt-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 [VCP-SPEC].¶

1.3. 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 [RFC9943])¶
• SCRAPI endpoints (see [I-D.ietf-scitt-scrapi])¶
• COSE Receipt format (see [RFC9942])¶
• Specific regulatory mapping (covered in companion documents)¶
• A particular anchoring service (the anchor target is deployment-specific; anchoring itself is REQUIRED)¶

2.1. SCITT Terminology Mapping

The following table maps VCP concepts to SCITT terminology:¶

3.1. 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 [RFC9052] 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.¶
7. External Anchoring: The Merkle root MUST be periodically anchored to an external system at the frequency of the applicable tier (Section 5.3), making post-anchor omission detectable by third parties.¶

3.2. 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.¶

  Actor A:  Event_A1 --hash--> Event_A2 --hash--> Event_A3

  Actor B:  Event_B1 --hash--> Event_B2

  Global Log: [Event_A1, Event_B1, Event_A2, Event_B2, Event_A3, ...]

3.3. Three-Layer Integrity Architecture

VCP defines a three-layer architecture that separates concerns and clarifies where each integrity property originates:¶

Note: Layer 3 (External Verifiability) is REQUIRED at every tier, as in VCP v1.2 [VCP-SPEC]. 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.¶

  Layer 1: Event Integrity
  +--------+    +--------+    +--------+
  | Event1 |    | Event2 |    | Event3 |
  | (sig)  |    | (sig)  |    | (sig)  |
  +---+----+    +---+----+    +---+----+
      |            |            |
      v            v            v
  Layer 2: Collection Integrity (Merkle Tree)
  +------------------------------------------+
  |              Merkle Root                 |
  +---------------------+--------------------+
                        |
                        v (REQUIRED)
  Layer 3: External Verifiability
  +------------------------------------------+
  | External Anchor (Blockchain/TSA/etc.)    |
  +------------------------------------------+

4.1. Header Object

The Header contains metadata common to all VCP Events:¶

{
  "Header": {
    "EventID": "01961e5f-5c0d-7000-8000-123456789abc",
    "TimestampISO": "2026-03-15T09:30:00.123456789Z",
    "TimestampInt": 1742034600123456789,
    "EventType": "ORD",
    "ActorID": "algo-momentum-001",
    "ChainID": "chain-actor-001",
    "SequenceNum": 42,
    "PolicyID": "org.veritaschain.policy:silver-v1-2"
  }
}

EventID

REQUIRED. UUID v7 [RFC9562] 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 Section 9 regarding canonicalization.¶

EventType

REQUIRED. Registered event type code (see Section 4.5).¶

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 [VCP-SPEC], 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.¶

4.2. 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.¶

{
  "Payload": {
    "VCP-TRADE": {
      "OrderID": "ord-2026-001",
      "Symbol": "AAPL",
      "Side": "BUY",
      "Quantity": "100",
      "Price": "185.50",
      "OrderType": "LIMIT"
    },
    "VCP-GOV": {
      "AlgoID": "momentum-v2.3",
      "DecisionFactors": ["RSI_oversold", "volume_spike"],
      "ConfidenceScore": "0.87"
    }
  }
}

4.3. Security Object

The Security object contains integrity and chaining information:¶

{
  "Security": {
    "EventHash": "sha256:a1b2c3d4...",
    "PrevHash": "sha256:f6e5d4c3...",
    "MerkleRoot": "sha256:1234abcd...",
    "SignAlgo": "ED25519",
    "AnchorRef": "eth:0x1234...@12345678"
  }
}

EventHash

REQUIRED. SHA-256 hash of the canonicalized Header and Payload, computed using JSON Canonicalization Scheme [RFC8785].¶

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 [FIPS-204]. 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 Section 9 on the corresponding field in [VCP-SPEC].¶

4.4. SCITT Alignment Object

VCP v1.2 [VCP-SPEC] 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:¶

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

{
  "Header": {
    "SCITTAlignment": {
      "Version": "1.2",
      "ConformanceProfile": "VCP_SCITT",
      "StatementID": "stmt-01961e5f-5c0d-7000",
      "TransparencyServiceID": "ts.veritaschain.example",
      "ReceiptFormat": "COSE_RECEIPT",
      "RegistrationPolicy": {
        "PolicyID": "org.veritaschain.policy:gold-v1-2",
        "Issuer": "org.veritaschain",
        "IssuedAt": 1767225600000000000
      }
    }
  }
}

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 [RFC9943].¶

RegistrationPolicy

OPTIONAL. Structured reference to the Registration Policy (PolicyID, Issuer, IssuedAt) mirroring the Header-level PolicyID.¶

4.5. Event Types

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 [VCP-SPEC]. Validators written against pre-release v1.2 artifacts need updating to accept them.¶

5.1. 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 [VCP-SPEC]: 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.¶

5.2. Validation Requirements

The Registration Policy MUST verify:¶

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

5.3. 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.¶

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.¶

5.4. 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 Section 9 on the scope of the AnchorRecord signature). Implementations retain local copies of all AnchorRecords and document an anchor continuity plan, as defined in [VCP-SPEC].¶

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 [RFC3161]¶
• SCITT Transparency Services, with COSE Receipts per [RFC9942]¶
• Public blockchains (e.g., Bitcoin, Ethereum)¶
• Public timestamping services and attested databases, at the tiers where [VCP-SPEC] permits them¶

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

6.1. 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.¶

6.2. VCP-PRIVACY Module

{
  "VCP-PRIVACY": {
    "EncryptedFields": ["VCP-TRADE.ClientID", "VCP-TRADE.AccountID"],
    "KeyID": "dek-2026-001-subject-12345",
    "Algorithm": "AES-256-GCM",
    "RetentionPolicy": "GDPR-5Y"
  }
}

6.3. ERASURE Event Type

VCP v1.2 [VCP-SPEC] 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 [VCP-SPEC] states how pre-release records are handled; it defines no lossless automatic conversion to the v1.2 encoding.¶

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:¶

{
  "Header": {
    "EventID": "019eaf10-0000-7000-8000-000000000001",
    "TimestampISO": "2026-10-09T00:00:00Z",
    "TimestampInt": 1791504000000000000,
    "EventType": "ERASURE",
    "ActorID": "operator-example",
    "ChainID": "chain-example",
    "SequenceNum": 1,
    "PolicyID": "org.example:fixture"
  },
  "Payload": {
    "VCP-PRIVACY": {
      "ErasureDetails": {
        "Version": "1.2",
        "TargetIdentifier": {
          "Type": "ACCOUNT",
          "Hash": "bbbb...",
          "Salt": "example-salt"
        },
        "Scope": {
          "AffectedEventCount": 1,
          "FirstAffectedEventID":
            "019eaf10-0000-7000-8000-000000000002",
          "LastAffectedEventID":
            "019eaf10-0000-7000-8000-000000000002",
          "AffectedFields": ["ClientID"]
        },
        "Reason": {
          "Code": "SUBJECT_REQUEST",
          "Description": "Data subject request",
          "LegalBasis": "Applicable erasure obligation",
          "RequestReferenceHash": "cccc..."
        },
        "Authorization": {
          "AuthorizedByRoleID": "privacy-role",
          "AuthorizerSignature": "...",
          "AuthorizationTimestamp": 1791503999999998000,
          "DPONotified": true
        },
        "CryptoShredding": {
          "KeyIDHash": "dddd...",
          "KeyAlgorithm": "AES-256-GCM",
          "DestructionMethod": "CLOUD_KMS_DESTROY",
          "DestructionTimestamp": 1791503999999999000,
          "DestructionCertificate": "..."
        },
        "Verification": {
          "PreErasureEventHash": "sha256:eeee...",
          "PostErasureChainHash": "sha256:ffff..."
        }
      }
    }
  },
  "Security": {
    "EventHash": "sha256:aaaa...",
    "SignAlgo": "ED25519"
  }
}

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 [VCP-SPEC].¶

7.1. Registration (POST /entries)

VCP Events are submitted as COSE_Sign1 Signed Statements:¶

POST /entries HTTP/1.1
Host: vcp-ts.example.com
Content-Type: application/cose

<COSE_Sign1 containing VCP Event payload>

The Transparency Service validates the VCP Registration Policy and returns a COSE Receipt on success.¶

7.2. Retrieval (GET /entries/{entry_id})

Retrieve a specific VCP Event by its entry ID (derived from EventID).¶

7.3. Receipt (GET /entries/{entry_id}/receipt)

Retrieve the COSE Receipt for a registered VCP Event, containing the Merkle inclusion proof.¶

7.4. 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).¶

8.1. 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¶

8.2. 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 [FIPS-204]) 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.¶

8.3. 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¶

8.4. 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¶

8.5. 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.¶