% RFC: SCP Canonical Data Model % Version 0.3.2 % 2026-02-26

RFC: SCP Canonical Data Model Specification v0.3.2

Status: Standards Track
Category: Core Protocol Layer

Normative keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY are interpreted as described in RFC 2119.

---

1. Abstract

This document defines the Canonical Data Model used in SCP v0.3.2.

The Canonical Model ensures:

• Deterministic data structure
• Cross-Vault semantic consistency
• Compatibility with Multi-Layer Registry
• Compatibility with OEV (Optimal Economic Verification)
• Commitment integrity for fraud detection

All Vault implementations MUST comply with this specification.

---

2. Design Principles

The Canonical Data Model MUST satisfy:

1. Deterministic serialization\
2. Stable attribute ordering\
3. Versioned schema definition\
4. Unit normalization\
5. Registry-bound attribute resolution\
6. Commitment reproducibility

Canonicalization MUST occur inside the Vault boundary.

---

3. Canonical Record Structure

struct CanonicalRecord { schema_version: string, vault_id: bytes, timestamp: u64, attributes: Vec<CanonicalAttributeValue>, }

Where:

struct CanonicalAttributeValue { attribute_id: u64, value_type: enum, value: bytes, }

---

4. Attribute Resolution

Raw fields MUST be mapped to Registry attributes using:

1. Rule-based mapping\
2. Semantic similarity matching\
3. Local attribute creation (if no match)

attribute_id MUST come from:

• Domain Registry OR
• Global Registry

Local attributes MUST NOT receive global attribute_id.

---

5. Data Normalization

5.1 Units

All numeric values MUST be converted to base unit defined by Registry.

5.2 Enumerations

String enumerations MUST be converted to integer enum codes.

5.3 Time

Time MUST be normalized to UTC Unix timestamp.

---

6. Attribute Ordering

attributes MUST be sorted in ascending order by attribute_id before serialization.

Failure to sort MUST invalidate commitment.

---

7. Deterministic Serialization

CanonicalRecord MUST be serialized using:

• UTF-8 encoding
• Fixed field ordering
• Deterministic binary format

JSON text format MAY be used for debugging but MUST NOT be used for commitment generation.

---

8. Commitment Generation

commitment = SHA256(deterministic_serialized_bytes)

Commitment MUST be immutable and reproducible across nodes.

---

9. Encryption Requirements

After commitment generation:

• CanonicalRecord MUST be encrypted using AEAD (e.g., AES-GCM)
• Commitment MUST reference plaintext canonical record

---

10. Interaction with OEV

Commitment is REQUIRED for:

• Random sampling verification
• Fraud proof submission
• Stake slashing validation

---

11. Interaction with Registry

Canonicalization MUST use current registry snapshot and semantic_version.

---

12. Hosted + TEE Mode

If Vault is hosted:

• Canonicalization MUST execute inside trusted boundary
• Commitment MUST be signed by Vault identity

TEE mode MAY provide remote attestation.

---

13. Error Handling

Canonicalization MUST fail if:

• Attribute cannot be resolved deterministically
• Unit conversion undefined
• Duplicate attribute_id present

---

14. Security Considerations

Threats addressed:

• Field tampering
• Ordering manipulation
• Unit inconsistency
• Commitment forgery

---

15. Versioning

schema_version MUST be included.

Breaking changes MUST increment major version.

---

16. Conclusion

All SCP-compliant Vault implementations MUST follow this Canonical Data Model.

End of RFC.