Chapter 6 Technical Development Roadmap

December 13, 2025

6.1 Introduction: From Architecture to Implementation

Chapter 5 defined the architecture needed to transform sleep data into a verifiable, permissioned, and tradable asset. The purpose of this chapter is to convert that architecture into a detailed, executable, and interdependent development roadmap, with clear atomic tasks, responsibilities, and dependencies.

The roadmap respects the realities established in:

Chapter 2 — the four structural barriers
Chapter 3 — the system requirements needed to solve them
Chapter 4 — Matrix’s role as the infrastructure
Chapter 5 — the five-layer architecture

The development is divided into four sequential phases:

Foundation (Layers 1–2) — Attestation, preprocessing, encryption, metadata
Consent & Storage (Layers 3–4) — Permission tokens, key management, fragmented storage
Assetisation & Marketplace (Layer 5) — NFT minting, settlement, licensing
Scale & Governance — Multi-device, decentralisation, regulatory interfaces

Each phase is written in atomic granularity, with justification and dependency mapping. Again, we use Hypnus as the pilot for this architecture implementation.

6.2 Phase 1 — FOUNDATION (Months 1–3)

Layers Covered: Origination, Attestation, Processing, Metadata

Barrier Solved: Provenance + Quality

Objective: Build the complete pipeline that proves sleep data is real, encrypts it locally, processes it correctly, attaches verifiable metadata, and anchors its integrity on Matrix. Without this phase, no dataset can be trusted, priced, or used. It is the backbone that all later phases depend on.

Milestone 1.1 — Device Attestation Framework (Hardware & Software)

Purpose: Create the first building block of provenance—proof the data came from a real device.

Task

Description

Why Required

1.1.1 Secure Enclave Signature Spec

Define required fields for device-side signatures (timestamp, firmware, serial, hashed signal segment).

Prevents spoofed or simulated data from entering the system.

1.1.2 Firmware Plugin for Hypnus Band

Add secure hashing & signing capabilities within device firmware.

Ensures data is signed at capture, not later.

1.1.3 Software Attestation Module

If hardware signing unavailable, build anomaly detection (synthetic pattern detection, duplication fingerprinting).

Protects the system from forgery in mixed-device environments.

1.1.4 Attestation Verification Library

Build library running on Matrix validators to verify signatures on-chain.

Allows validators to independently confirm device origin.

Deliverables:

Device attestation spec
Firmware module
Validator verification functions

Milestone 1.2 — Local Encryption & Preprocessing Pipeline

Purpose: Ensure raw signals never leave the device unencrypted and are processed consistently.

Task

Description

Why Required

1.2.1 Client-Side AES-256 Encryption

Implement encryption in Hypnus App before upload.

Enforces privacy by design; required for liability protection.

1.2.2 Noise & Integrity Filters

Preprocessing: remove invalid segments, detect missing windows, correct sampling jitter.

Buyers must not receive corrupted signals.

1.2.3 Standardized File Format

Convert signals into a uniform schema (sampling rate, channel list, time windows).

Enables interoperability for research buyers.

1.2.4 Data Hashing (Merkle Root)

Generate hash for long recordings; anchor for NFT metadata.

Supports tamper detection at any point later.

Deliverables:

Encrypted, standardized signal package
Preprocessing logs
Dataset hash

Milestone 1.3 — Metadata Schema & Quality Engine

Purpose: Create machine-readable descriptions that support price discovery and research suitability evaluation.

Task

Description

Why Required

1.3.1 Metadata Field Definition

Define fields: fidelity score, completeness %, noise index, signal type, duration.

Buyers base purchase decisions on these fields.

1.3.2 Quality Scoring Algorithm

Create reproducible scoring model (0–100).

Data must be priced fairly; poor-quality data must not pollute the market.

1.3.3 Metadata Embedding

Bind metadata to encrypted file using CID references.

Metadata must always travel with the dataset.

1.3.4 Validator Metadata Cross-Check

Validators verify metadata correctness vs. hashed data.

Ensures metadata cannot be manipulated.

Deliverables:

MAN-compatible metadata package
Quality scoring engine

Milestone 1.4 — IPFS + Filecoin Uplink & Anchoring

Purpose: Enable secure upload of encrypted files to decentralized storage.

Task

Description

Why Required

1.4.1 Regional Pinning Nodes

Deploy IPFS in HK + SEA for stable latency.

Required for real research workflows.

1.4.2 Filecoin Backup Integration

Long-term redundancy using deals.

Prevents data loss & supports audit trails.

1.4.3 Upload API

App → IPFS pathway with automatic retries and checksum validation.

Guarantees integrity of stored data.

1.4.4 Matrix Anchoring Function

On-chain hash + CID recording.

Establishes verifiable linkage between asset & stored data.

Deliverables:

Regional IPFS clusters
Filecoin redundancy
Anchoring smart contract

Milestone 1.5 — Prototype NFT Minting (Internal)

Purpose: Demonstrate the complete pipeline works end-to-end.

Task

Description

Why Required

1.5.1 MAN-721 Contract Draft

Define NFT structure: metadata pointer, CID, attestation status, quality score.

Creates the asset in the assetisation layer.

1.5.2 Minting API

Connect Hypnus backend to Matrix minting logic.

Enables creating sleep-data NFTs.

1.5.3 Internal Wallet (Test Only)

Simple wallet to view minted NFTs.

Internal test environment for validation.

Deliverables:

Functional prototype NFT
50–200 internal test datasets minted

Phase 1 Exit Criteria

5,000 datasets processed, encrypted, uploaded, and NFT-minted
99.9% IPFS uptime
Attestation & metadata verified by validators
No raw data touches servers in unencrypted form

Layers Covered: Permissioning, Key Management, Decentralised Storage

Barrier Solved: Consent + Liability

Objective: Implement enforceable consent, revocation, key splitting, and fragmented storage. Without this phase, no institution can legally or safely access the data.

Milestone 2.1 — Permission Token System (Purpose, Duration, Recipient)

Purpose: Encode consent directly into cryptographic objects.

Task

Description

Why Required

2.1.1 Permission Token Spec

Define fields: purpose, timeframe, identity, revocation state.

Replaces PDF agreements with enforceable cryptographic policy.

2.1.2 Contract Implementation

Smart contract for issuing, updating, revoking tokens.

Central mechanism of user control.

2.1.3 User Dashboard Prototype

Visual interface for permission review.

Users must understand and control data access.

2.1.4 Validator Enforcement Logic

Validators deny access without valid token.

Ensures consent is a gating mechanism.

Milestone 2.2 — Threshold KMS & Key Fragmentation

Purpose: Eliminate single points of failure in key storage.

Task

Description

Why Required

2.2.1 M-of-N Scheme Setup

Define recovery threshold and distribution.

Prevents key loss and prevents operator control.

2.2.2 Client-Side Key Generation

Keys created on user device, never server.

Required for liability reduction.

2.2.3 Proxy Re-Encryption

Re-encrypt key fragment for buyer without exposing full key.

Allows temporary, revocable access.

2.2.4 Fragments Distributed Across Nodes

Each node receives one fragment only.

Breach of one node reveals nothing.

Milestone 2.3 — Fragmented Decentralized Storage (Full Deployment)

Purpose: Remove catastrophic liability scenarios.

Task

Description

Why Required

2.3.1 Sharding Logic

Split encrypted data into independent fragments.

Prevents full dataset exposure.

2.3.2 Storage Operator Onboarding

Independent operators in HK, SG, DE, AU.

Regulatory diversification.

2.3.3 Indexing Contract

Tracks which node holds which fragment.

Necessary for controlled reconstruction.

2.3.4 Outage & Breach Simulation

Verify that node failure does not affect availability.

Ensures durability and audit readiness.

Milestone 2.4 — Consent Revocation Engine

Purpose: Make revocation operational, not symbolic.

Task

Description

Why Required

2.4.1 Token Invalidator

Revoke permissions on-chain.

Removes access immediately.

2.4.2 Key Rotation

Generate new key fragments after revocation.

Prevents old tokens from being reused.

2.4.3 Audit Trail

Log revocations immutably.

Required by regulators.

2.4.4 Access Block Test

Verify that revoked buyers lose access.

Demonstrates enforceable consent.

Phase 2 Exit Criteria

Permission tokens fully functional
Revocation works instantly
Fragmented storage live in ≥4 jurisdictions
Validators enforce consent rules autonomously

6.4 Phase 3 — ASSETISATION & MARKETPLACE (Months 7–9)

Layers Covered: Tokenization, Marketplace, Settlement

Barrier Solved: Economic viability

Objective: Allow institutions to browse, filter, license, and pay for datasets—without ever accessing raw personal data directly.

Milestone 3.1 — Assetisation Engine (Dynamic NFT)

Purpose: Represent datasets as traceable, licensable assets.

Task

Description

Why Required

3.1.1 Dynamic NFT Upgrade

Add states: Licensed, Expired, Revoked.

Supports real-world licensing.

3.1.2 Royalty Logic

Define protocol fee, validator fee, user share.

Supports economic sustainability.

3.1.3 On-chain Metadata Pointer

Bind NFT to stored dataset & permission state.

Guarantees auditability.

3.1.4 NFT Lifecycle Tests

Mint → License → Expire → Revoke → Remint.

Prevents broken economics.

Milestone 3.2 — Marketplace Backend & Buyer Tools

Purpose: Allow institutional buyers to search and license data efficiently.

Task

Description

Why Required

3.2.1 Search Index

Filter by fidelity, duration, demographics, device type.

Researchers require precise matching.

3.2.2 Dataset Preview

Show metadata only; no signal exposure.

Buyers need to evaluate quality without compromising privacy.

3.2.3 Licensing Flow

Contract triggers token issuance + re-encryption.

Core revenue mechanism.

3.2.4 Institution Onboarding

KYC + whitelisting of permitted buyers.

Compliance necessity.

Milestone 3.3 — Stablecoin Settlement Integration

Purpose: Enable compliant, frictionless payment for licenses.

Task

Description

Why Required

3.3.1 Stablecoin Adapter

Connect to regulated issuer (HK, SG, EU or other).

Avoid speculative assets.

3.3.2 Escrow Contract

Hold funds until permission token issues.

Protects buyers from failed mints.

3.3.3 Auto-Distribution Logic

Split revenue 70% user, 20% validators, 10% protocol.

Aligns incentives.

3.3.4 Settlement Tests

Simulate high-volume licensing.

Ensure predictable operation.

Phase 3 Exit Criteria

Marketplace operational
First external institution licenses data
Stablecoin payments settle automatically
NFT lifecycle functioning correctly

6.5 Phase 4 — SCALE, GOVERNANCE, MULTI-DEVICE (Months 10–12)

Objective: Grow the system from working prototype to complete ecosystem infrastructure.

Milestone 4.1 — Multi-Device Integration

Task

Description

Why Required

4.1.1 SDK for Apple/Samsung/Oura

Expand device compatibility.

Increases data diversity & market size.

4.1.2 Attestation Mapping

Map device-specific signatures to attestation layer.

Preserves provenance.

4.1.3 Format Normalisation

Convert different device formats to unified schema.

Keeps metadata consistent.

4.1.4 Validation Rules

Device-specific quality scoring.

Required for price accuracy.

Milestone 4.2 — Governance Module

Task

Description

Why Required

4.2.1 Validator Council

Multi-entity validator group.

Distributes trust.

4.2.2 Proposal Framework

Add protocol-change proposals.

Ensures long-term neutrality.

4.2.3 Voting Contract

Weighted voting mechanism.

Practical governance.

4.2.4 Operational Rules

Minimum uptime, penalty rules.

Keeps validators honest.

Milestone 4.3 — Compliance Interface for Regulators

Task

Description

Why Required

4.3.1 Read-Only Audit API

Shows consent history, minting history, validator signatures.

Enables regulator inspection without data exposure.

4.3.2 Export Function

Provide structured compliance reports.

Required for audits.

4.3.3 Marketplace Transparency Dashboard

Real-time KPIs.

Regulatory clarity.

4.3.4 Data Flow Diagrams (Static)

Required documentation.

Needed for approvals.

Milestone 4.4 — Secondary Market

Task

Description

Why Required

4.4.1 Transfer Logic

Allow secondary trades while preserving consent.

Enables liquidity.

4.4.2 Royalty Enforcement

On secondary transfers.

Economic sustainability.

4.4.3 Permission Renewal

Buyer must request new token from user.

Prevents accidental access.

4.4.4 Market Risk Controls

Limits for institutional buyers.

Prevents abuse.

Phase 4 Exit Criteria

Multi-device support live
DAO governance operational
Regulatory audit passed
≥ 50,000 live NFTs
Marketplace revenue flowing

6.6 Summary

This chapter converts the architectural design from Chapter 5 into a complete, technically justified development roadmap.

At completion of Phase 4, Matrix and Hypnus will have:

A fully verifiable provenance chain
Enforceable consent with cryptographic revocation
Distributed storage that eliminates catastrophic breaches
Tokenized biodata assets that institutions can license safely
A compliant, stablecoin-based settlement system
Governance structured for long-term neutrality

With this roadmap, Hypnus becomes the first proof-of-concept for Matrix’s broader biodata economy vision, and the infrastructure becomes extensible to any biometric domain.