# Chapter 6 Technical Development Roadmap

#### 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: 1. Foundation (Layers 1–2) — Attestation, preprocessing, encryption, metadata 2. Consent & Storage (Layers 3–4) — Permission tokens, key management, fragmented storage 3. Assetisation & Marketplace (Layer 5) — NFT minting, settlement, licensing 4. 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 #### 6.3 Phase 2 — CONSENT & STORAGE (Months 4–6) ***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. {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %}