Security Overview

Overview

DMTR's security model is built around three implemented pillars: an immutable audit trail, role-based access control, and data isolation by participant. This page describes what exists in code today and what is planned.

Audit Hash Chain

Every mutation in the DMTR registry is recorded in a SHA-256 hash chain. Each event includes the hash of the previous event, creating a tamper-evident, append-only log designed for SEC Rule 17a-4 compliance.

The implementation lives in packages/core/src/audit/hash-chain.ts and is covered by 14 tests verifying genesis events, chain integrity, tamper detection, and sequence validation.

Key properties:

• Immutable: Events cannot be modified after recording without breaking the chain
• Verifiable: Any party can verify chain integrity by recomputing hashes
• Deterministic: Same event payload always produces the same hash
• Legally grounded: Authority citations on every check result link verdicts to specific regulations

Role-Based Access Control

The RBAC module (packages/core/src/security/rbac.ts) implements evaluateAccess() with a role-based permission matrix covering:

• Roles: admin, gp, lp, transfer_agent, counsel, auditor, lender, borrower
• Actions: read, write, evaluate, settle, consent, audit
• Scoping: Cross-participant access control, collateral pool scoping for lenders, broker-dealer handling

The API enforces RBAC via middleware on all /v1/ routes. For the current sandbox, the default role is admin (permissive). In production, role will be derived from the API key's associated participant record.

Data Isolation

The data isolation module (packages/core/src/security/data-isolation.ts) enforces visibility tiers:

• Position filtering: filterPositions() restricts which positions a participant can see based on their role and issuer relationship
• Event filtering: filterEvents() restricts audit trail visibility
• Transfer filtering: filterTransfers() scopes transfer history
• Collateral pool filtering: Role-aware filtering for lender/borrower access patterns

Encryption

All API traffic uses TLS 1.2+. The sandbox uses in-memory SQLite; production will use PostgreSQL with encryption at rest.

Authentication

API key-based authentication is implemented. See Authentication & Authorization for details on key management, scoping, and the authorization model.

Roadmap

For the full feature roadmap, see Roadmap.