Contains: - 1m-brag - tem - VaultMesh_Catalog_v1 - VAULTMESH-ETERNAL-PATTERN 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
387 lines
20 KiB
Markdown
387 lines
20 KiB
Markdown
# Section 1 · Excellence
|
|
|
|
**Proposal:** PQC Integration for EU Critical Infrastructure
|
|
**Call:** HORIZON-CL3-2025-CS-ECCC-06
|
|
**Section:** Part B Section 1 (30% of evaluation score)
|
|
**Page Limit:** ~15 pages (subsections 1.1-1.4 combined)
|
|
|
|
---
|
|
|
|
## 1.1 Objectives
|
|
|
|
**Specific, Measurable Objectives Aligned with Horizon Europe Call CL3-ECCC-06:**
|
|
|
|
### Overall Objective
|
|
Develop and validate a **hybrid post-quantum cryptographic (PQC) transition framework** for EU critical infrastructure, achieving **TRL 6** through operational pilot deployments across 3 member states (France, Czech Republic, Greece), demonstrating **30% audit cost reduction** and **50% faster incident detection** while ensuring **100% backward compatibility** with existing classical cryptography systems.
|
|
|
|
### Specific Objectives (SO1-SO7)
|
|
|
|
**SO1: Post-Quantum Algorithm Integration (M1-M14)**
|
|
- Integrate 3 NIST-standardized PQC algorithms (CRYSTALS-Kyber FIPS 203, CRYSTALS-Dilithium FIPS 204, SPHINCS+ FIPS 205) into VaultMesh receipt engine
|
|
- Achieve **10,000 receipts/day throughput** with PQC signing (baseline: 1,000/day classical)
|
|
- **Deliverables:** D2.1 (Sealer Implementation, M8), D2.2 (Verifier CLI, M11), D2.3 (RFC-3161 TSA Integration, M14)
|
|
- **Verification:** Benchmark tests showing <5ms signing latency per receipt
|
|
|
|
**SO2: Hybrid Cryptographic Transition (M1-M12)**
|
|
- Develop **dual signature mode** (classical Ed25519 + PQC Dilithium in parallel)
|
|
- Design **hybrid key exchange** (X25519 + CRYSTALS-Kyber for backward compatibility)
|
|
- Create **composite X.509 certificates** following draft-ietf-lamps-pq-composite-certs
|
|
- **Deliverables:** D1.2 (Architecture Specification, M6), D2.1 (Sealer Implementation, M8)
|
|
- **Verification:** Interoperability tests with legacy systems (100% compatibility target)
|
|
|
|
**SO3: LAWCHAIN Tamper-Evident Audit Spine (M1-M18)**
|
|
- Implement **Merkle tree compaction** for receipt batching (target: 256 manifests, up from 36)
|
|
- Integrate **external timestamping** via RFC-3161 TSA providers (FreeTSA, DigiStamp, GlobalSign)
|
|
- Deploy **blockchain anchoring** (Ethereum mainnet + Bitcoin OP_RETURN fallback)
|
|
- **Deliverables:** D2.3 (TSA Integration, M14), D4.1 (Federation Router, M12)
|
|
- **Verification:** 99%+ audit trail completeness (baseline: 85%)
|
|
|
|
**SO4: Ψ-Field Anomaly Detection (M4-M16)**
|
|
- Develop **collective intelligence service** for cross-organizational anomaly detection
|
|
- Achieve **<10% false positive rate** and **>80% true positive rate** via tunable thresholds
|
|
- Deploy **human-in-the-loop review dashboard** for high-risk alerts
|
|
- **Deliverables:** D3.1 (Ψ-Field Service v1.0, M10), D3.2 (Observability Dashboard, M14), D3.3 (Anomaly Detection Module, M16)
|
|
- **Verification:** Pilot feedback + precision/recall metrics
|
|
|
|
**SO5: Federation Router for Sovereign Data Exchange (M6-M18)**
|
|
- Implement **mTLS peer-to-peer federation** with quantum-safe key exchange
|
|
- Deploy **testbed with 15+ nodes** across 3 countries (France, Czech Republic, Greece)
|
|
- Develop **trust profile specification** for cross-organizational interoperability
|
|
- **Deliverables:** D4.1 (Federation Router v1.0, M12), D4.2 (Testbed Deployment, M16), D4.3 (Trust Profiles, M18)
|
|
- **Verification:** 100% peer-to-peer exchange (no third-party intermediaries)
|
|
|
|
**SO6: Operational Pilot Validation (M12-M24) — TRL 4→6**
|
|
- Deploy across **3 pilot sites** (France Public Digital Services, Czech Research Network, Greece Critical Infrastructure)
|
|
- Validate **30% audit cost reduction** vs. manual log review (measured in audit hours/incident)
|
|
- Demonstrate **50% faster incident detection** vs. current monitoring systems
|
|
- Collect **feedback from 15+ organizational peers** (5 per pilot site)
|
|
- **Deliverables:** D5.1 (Pilot Deployment Reports, M20), D5.2 (Standards Contributions, M22), D5.3 (Impact Assessment, M24)
|
|
- **Verification:** Independent TRL audit by external evaluator (M24)
|
|
|
|
**SO7: Standards Contributions & Open-Source Dissemination (M1-M24)**
|
|
- Submit **5+ standards drafts** (ETSI TC CYBER, IETF CFRG, ISO/IEC JTC 1/SC 27)
|
|
- Publish **10+ peer-reviewed papers** in top-tier venues (IEEE S&P, ACM CCS, USENIX Security)
|
|
- Achieve **500+ open-source downloads** post-M24 (GitHub, Docker Hub)
|
|
- Conduct **3+ training workshops** (1 per pilot region)
|
|
- **Deliverables:** D5.2 (Standards Contributions, M22), D5.3 (Impact Assessment, M24)
|
|
- **Verification:** DOI links, GitHub Insights, attendance lists
|
|
|
|
---
|
|
|
|
### Alignment with Call Topic ECCC-06
|
|
|
|
**Expected Outcome 1: "Quantum-safe cryptographic solutions for critical infrastructure"**
|
|
→ **Addressed by SO1-SO2:** Integration of NIST-standardized PQC algorithms with hybrid transition ensuring backward compatibility
|
|
|
|
**Expected Outcome 2: "TRL 6 validation in operational environments"**
|
|
→ **Addressed by SO6:** 3 pilot deployments across France, Czech Republic, Greece with independent TRL audit
|
|
|
|
**Expected Outcome 3: "Contribution to EU digital sovereignty and cybersecurity policy (NIS2, DORA)"**
|
|
→ **Addressed by SO3, SO5, SO7:** LAWCHAIN audit spine for NIS2 Art. 21-23 compliance, federation for sovereign data exchange, standards contributions to ETSI/IETF
|
|
|
|
**Expected Outcome 4: "Open science and standardization"**
|
|
→ **Addressed by SO7:** All outputs under Apache 2.0, 5+ standards drafts, 10+ publications in open access
|
|
|
|
---
|
|
|
|
### TRL Progression Strategy (4→6)
|
|
|
|
**Current State (TRL 4 — Lab Validation):**
|
|
- VaultMesh node operational with 3,600+ classical cryptographic receipts
|
|
- Merkle compaction (36 manifests), Ed25519 signatures, AES-256-GCM encryption
|
|
- No PQC integration, no external anchoring (TSA/blockchain), no federation
|
|
|
|
**Project Target (TRL 6 — Pilot Validation):**
|
|
- PQC algorithms integrated (Kyber, Dilithium, SPHINCS+) with hybrid mode
|
|
- LAWCHAIN audit spine with RFC-3161 TSA + blockchain anchors (99%+ completeness)
|
|
- Ψ-Field anomaly detection (<10% false positive rate)
|
|
- Federation router operational (15+ nodes across 3 countries)
|
|
- **Validated across 3 operational pilot environments**
|
|
|
|
**TRL Milestones:**
|
|
- **M6:** TRL 4 → TRL 5 (integration complete, lab testing with synthetic data)
|
|
- **M12:** TRL 5 maintained (testbed deployment, first pilot preparations)
|
|
- **M18:** TRL 5 → TRL 6 (pilots operational, real-world data collection)
|
|
- **M24:** TRL 6 validated (independent audit confirms operational readiness)
|
|
|
|
---
|
|
|
|
### Link to EU Strategic Autonomy
|
|
|
|
**Digital Sovereignty:**
|
|
- VaultMesh federation enables **peer-to-peer data exchange** without reliance on third-party cloud providers (US, CN)
|
|
- **100% EU-hosted infrastructure** (Ireland, Czech Republic, Greece, France)
|
|
- **Open-source** under Apache 2.0 (no vendor lock-in)
|
|
|
|
**Quantum Threat Preparedness:**
|
|
- Hybrid PQC transition allows **gradual migration** (no forced infrastructure replacement)
|
|
- **Backward compatibility** ensures continuity of operations during transition
|
|
- **NIST-standardized algorithms** align with EU Cybersecurity Act requirements
|
|
|
|
**Critical Infrastructure Protection:**
|
|
- **NIS2 compliance** (Art. 21: cybersecurity measures, Art. 23: incident notification)
|
|
- **DORA compliance** (Art. 5-6: ICT risk management, Art. 17: incident reporting)
|
|
- **AI Act compliance** (Art. 17: record-keeping for high-risk AI systems — relevant for Ψ-Field)
|
|
|
|
---
|
|
|
|
## 1.2 Relation to the Work Programme
|
|
|
|
**Call Topic Text (ECCC-06): "Proposals should address quantum-safe cryptographic transition for European critical infrastructure sectors, demonstrating TRL 6 validation across at least 2 EU member states, with contributions to European standardization bodies (ETSI, IETF) and alignment with NIS2, DORA, and Cybersecurity Act requirements."**
|
|
|
|
### How VaultMesh Addresses Call Requirements
|
|
|
|
**Quantum-Safe Cryptographic Transition:**
|
|
→ WP2 (Proof & Anchoring) integrates NIST FIPS 203, 204, 205 algorithms
|
|
→ Hybrid mode (SO2) ensures gradual, backward-compatible migration
|
|
|
|
**Critical Infrastructure Sectors:**
|
|
→ Pilot sites cover **3 sectors**: public administration (France), research networks (Czech Republic), critical infrastructure operators (Greece)
|
|
→ Cross-sector applicability: energy, finance, healthcare (future extensions)
|
|
|
|
**TRL 6 Validation Across ≥2 Member States:**
|
|
→ **3 member states** (France, Czech Republic, Greece) — exceeds minimum requirement
|
|
→ Independent TRL audit at M24 (external evaluator)
|
|
|
|
**Contributions to European Standardization Bodies:**
|
|
→ WP5 (Pilots & Assessment) targets 5+ standards drafts:
|
|
- ETSI TC CYBER: PQC migration guidelines for critical infrastructure
|
|
- IETF CFRG: Hybrid key exchange mechanisms (X25519 + Kyber)
|
|
- ISO/IEC JTC 1/SC 27: Interoperability profiles for quantum-safe audit trails
|
|
|
|
**Alignment with NIS2:**
|
|
→ LAWCHAIN audit spine (SO3) provides tamper-evident logs for NIS2 Art. 23 (incident notification)
|
|
→ Ψ-Field anomaly detection (SO4) supports NIS2 Art. 21 (cybersecurity risk management)
|
|
|
|
**Alignment with DORA:**
|
|
→ LAWCHAIN (SO3) enables DORA Art. 17 compliance (ICT-related incident reporting)
|
|
→ Receipt-based audit trails provide non-repudiable evidence for financial sector regulators
|
|
|
|
**Alignment with Cybersecurity Act:**
|
|
→ PQC integration (SO1-SO2) addresses Annex II cybersecurity requirements (protection against known exploitable vulnerabilities)
|
|
→ Open-source approach (SO7) enables transparency and security-by-design
|
|
|
|
---
|
|
|
|
### How VaultMesh Supports Hybrid-PQC Migration for EU Cybersecurity and Trustworthy AI
|
|
|
|
**Gradual Migration Path (No "Forklift Upgrades"):**
|
|
- Dual signature mode (classical + PQC) allows organizations to validate PQC before full transition
|
|
- Hybrid key exchange maintains interoperability with legacy systems
|
|
- Estimated migration timeline: **2-3 years** for typical organization (vs. 5-7 years for full replacement)
|
|
|
|
**Trustworthy AI (Ψ-Field as Human-in-the-Loop Governance):**
|
|
- Ψ-Field anomaly detection includes **human review dashboard** for high-risk alerts
|
|
- Aligns with AI Act Art. 14 (human oversight for high-risk AI systems)
|
|
- **Explainability layer** (SHAP/LIME) ensures transparency of detection logic
|
|
|
|
**Economic Impact:**
|
|
- **€100K+ cost savings** per organization via cryptographic governance (eliminates third-party certification)
|
|
- **30% audit cost reduction** (measured in pilot benchmarks)
|
|
- **50% faster incident response** (Ψ-Field early detection)
|
|
|
|
---
|
|
|
|
## 1.3 Concept and Methodology
|
|
|
|
### Technical Architecture Overview
|
|
|
|

|
|
**Figure 1: VaultMesh PQC Integration Architecture — TRL 4→6 Transition**
|
|
|
|
**Key Components (Left to Right in Diagram):**
|
|
|
|
1. **Current State (TRL 4):** Classical cryptography (Ed25519, ECDSA, AES), existing VaultMesh node with 3,600+ receipts
|
|
2. **Hybrid Transition Layer (TRL 5):** Dual signatures, hybrid KEMs, composite certificates
|
|
3. **Post-Quantum Target (TRL 6):** CRYSTALS-Kyber, CRYSTALS-Dilithium, SPHINCS+
|
|
4. **VaultMesh Core Organs:** Receipt Engine, LAWCHAIN, Ψ-Field, Federation Router
|
|
5. **External Trust Anchors:** RFC-3161 TSA, Ethereum, Bitcoin
|
|
6. **3 Pilot Sites:** France (public services), Czech Republic (research network), Greece (critical infrastructure)
|
|
|
|
---
|
|
|
|
### Methodology: Five Work Packages
|
|
|
|
**WP1: Governance Framework (M1-M6) — VaultMesh Lead**
|
|
- **Objective:** Define requirements, architecture, proof schemas
|
|
- **Tasks:**
|
|
- T1.1: Stakeholder requirements gathering (pilot sites, partners)
|
|
- T1.2: Architecture specification (hybrid PQC transition design)
|
|
- T1.3: Proof schema definitions (receipt formats, Merkle tree structures)
|
|
- T1.4: LAWCHAIN design (audit spine, external anchoring)
|
|
- T1.5: Ψ-Field specifications (anomaly detection rules, thresholds)
|
|
- **Deliverables:** D1.1 (Requirements & Use Cases, M3), D1.2 (Architecture Specification, M6)
|
|
- **Milestone:** M1 Requirements Review (M6) — steering committee approval
|
|
|
|
**WP2: Proof & Anchoring (M1-M12) — Univ Brno Lead**
|
|
- **Objective:** Implement PQC sealer, verifier, and external anchoring
|
|
- **Tasks:**
|
|
- T2.1: CRYSTALS-Kyber KEM integration (key encapsulation for federation)
|
|
- T2.2: CRYSTALS-Dilithium signature integration (receipt signing)
|
|
- T2.3: SPHINCS+ integration (stateless hash signatures for backups)
|
|
- T2.4: Sealer CLI tool (generate PQC-signed receipts)
|
|
- T2.5: Verifier CLI tool (verify receipt Merkle proofs)
|
|
- T2.6: RFC-3161 TSA integration (timestamp authority anchoring)
|
|
- T2.7: Blockchain anchoring (Ethereum mainnet, Bitcoin OP_RETURN)
|
|
- **Deliverables:** D2.1 (Sealer Implementation, M8), D2.2 (Verifier CLI, M11), D2.3 (RFC-3161 TSA Integration, M14)
|
|
- **Milestone:** M2 Proof Engine Demo (M12) — functional demonstration
|
|
|
|
**WP3: Ψ-Field & Observability (M4-M16) — Cyber Trust Lead**
|
|
- **Objective:** Develop anomaly detection service and observability dashboard
|
|
- **Tasks:**
|
|
- T3.1: Ψ-Field service architecture (collective sensing across federation)
|
|
- T3.2: Anomaly detection algorithms (statistical, ML-based)
|
|
- T3.3: Tunable threshold system (reduce false positives)
|
|
- T3.4: Human-in-the-loop review dashboard (web UI for alerts)
|
|
- T3.5: Observability dashboard (metrics, logs, receipt queries)
|
|
- **Deliverables:** D3.1 (Ψ-Field Service v1.0, M10), D3.2 (Observability Dashboard, M14), D3.3 (Anomaly Detection Module, M16)
|
|
- **Milestone:** M3 Ψ-Field Operational (M16) — deployed in testbed
|
|
|
|
**WP4: Federation & Trust (M6-M18) — VaultMesh Lead**
|
|
- **Objective:** Implement federation router and deploy multi-node testbed
|
|
- **Tasks:**
|
|
- T4.1: mTLS federation router (peer-to-peer secure channels)
|
|
- T4.2: Hybrid key exchange (X25519 + CRYSTALS-Kyber for handshakes)
|
|
- T4.3: Capability snapshots (node metadata exchange)
|
|
- T4.4: Testbed deployment (15+ nodes across 3 countries)
|
|
- T4.5: Trust profile specification (interoperability standards)
|
|
- **Deliverables:** D4.1 (Federation Router v1.0, M12), D4.2 (Testbed Deployment, M16), D4.3 (Trust Profile Specification, M18)
|
|
- **Milestone:** M4 Federation Live (M18) — 15+ nodes operational
|
|
|
|
**WP5: Pilots & Assessment (M12-M24) — France Public Lead**
|
|
- **Objective:** Deploy pilots, validate TRL 6, assess impact, contribute to standards
|
|
- **Tasks:**
|
|
- T5.1: Pilot site infrastructure preparation (M12-M14)
|
|
- T5.2: Pilot deployments (France, Czech Republic, Greece) (M14-M20)
|
|
- T5.3: Benchmarking (audit cost reduction, incident detection speed)
|
|
- T5.4: Standards drafts (ETSI, IETF, ISO)
|
|
- T5.5: Impact assessment & roadmap (exploitation plan)
|
|
- **Deliverables:** D5.1 (Pilot Deployment Reports, M20), D5.2 (Standards Contributions, M22), D5.3 (Impact Assessment & Roadmap, M24)
|
|
- **Milestone:** M5 Final Review (M24) — EU project completion
|
|
|
|
---
|
|
|
|
### Risk Management Approach
|
|
|
|
**15 identified risks across technical, organizational, financial, external categories (see Annex B: Risk Register for full details)**
|
|
|
|
**Top 3 Risks Requiring Active Management:**
|
|
|
|
1. **R01: NIST PQC Standards Change (Likelihood: M, Impact: M, Score: 4)**
|
|
- Mitigation: Monitor NIST monthly, design modular crypto layer, budget 2 PM for updates
|
|
|
|
2. **R04: Pilot Site Deployment Delays (Likelihood: M, Impact: M, Score: 4)**
|
|
- Mitigation: Early pilot engagement (M1), infrastructure assessment (M6), sandbox fallback
|
|
|
|
3. **R08: Ψ-Field False Positives (Likelihood: M, Impact: M, Score: 4)**
|
|
- Mitigation: Tunable thresholds, human-in-the-loop review, pilot feedback loop
|
|
|
|
**Overall Risk Profile:** MODERATE (weighted average score: 2.9/9)
|
|
**Contingency Budget:** €280K (10% of €2.8M total)
|
|
**Review Process:** Monthly risk register updates in steering committee
|
|
|
|
---
|
|
|
|
## 1.4 Ambition
|
|
|
|
### Novelty Beyond State-of-the-Art
|
|
|
|
**Current State-of-the-Art (PQC Research):**
|
|
- NIST PQC finalists standardized (2024): Kyber, Dilithium, SPHINCS+
|
|
- Academic prototypes: LibOQS, Open Quantum Safe project
|
|
- Limited real-world deployments: mostly theoretical or isolated lab tests
|
|
|
|
**VaultMesh Innovation (5 Novel Contributions):**
|
|
|
|
**1. Quantum-Resistant Federation Protocol**
|
|
- **Gap:** Existing PQC implementations focus on single-node encryption; no production-ready federation protocols
|
|
- **VaultMesh:** Hybrid mTLS with X25519 + CRYSTALS-Kyber for peer-to-peer sovereign data exchange
|
|
- **Impact:** Enables cross-organizational PQC without centralized key management
|
|
|
|
**2. Proof-Driven Audit Spine (LAWCHAIN)**
|
|
- **Gap:** Current audit systems lack cryptographic tamper-evidence; rely on centralized logs (mutable)
|
|
- **VaultMesh:** Merkle-rooted receipts + RFC-3161 TSA + blockchain anchors = non-repudiable audit trail
|
|
- **Impact:** 99%+ audit trail completeness (baseline: 85% for traditional systems)
|
|
|
|
**3. Ψ-Field Collective Intelligence**
|
|
- **Gap:** Anomaly detection is organization-siloed; no cross-organizational threat intelligence sharing with privacy
|
|
- **VaultMesh:** Federated anomaly detection across multiple organizations (collective sensing without raw data exposure)
|
|
- **Impact:** Faster threat detection (50%+ improvement) via cross-org pattern recognition
|
|
|
|
**4. Measurable Audit Cost Reduction (-30%)**
|
|
- **Gap:** PQC research focuses on cryptographic performance; no studies quantify operational cost savings
|
|
- **VaultMesh:** Pilot benchmarks measure audit hours/incident before vs. after LAWCHAIN deployment
|
|
- **Impact:** €100K+ cost savings per organization (eliminates third-party certification)
|
|
|
|
**5. Hybrid Transition Playbook for EU Critical Infrastructure**
|
|
- **Gap:** NIST provides algorithm specs; no practical migration guides for operational systems
|
|
- **VaultMesh:** Dual signature mode + backward compatibility + pilot validation = replicable blueprint
|
|
- **Impact:** Reduces migration timeline from 5-7 years to 2-3 years for typical organization
|
|
|
|
---
|
|
|
|
### Measurable Ambition (18 Quantitative KPIs)
|
|
|
|
**Reference:** KPI Dashboard (PQC_KPI_Dashboard.md) — full table in Part B Section 2.1
|
|
|
|
**Key Targets:**
|
|
- **Excellence:** TRL 4→6 (external audit), 10+ top-tier publications, 5+ standards drafts (ETSI/IETF/ISO)
|
|
- **Impact:** 30% audit cost reduction, 50% faster incident detection, 500+ open-source downloads post-M24, 15+ federation nodes across 3 countries
|
|
- **Implementation:** 100% deliverable on-time (13/13), ≤10% budget variance, ≥90% steering attendance
|
|
|
|
**Verification Methods:**
|
|
- Independent TRL audit (M24)
|
|
- Pilot benchmarks (D5.1): audit hours/incident, incident detection time
|
|
- GitHub Insights (downloads, stars, forks)
|
|
- Standards body submission confirmations (ETSI, IETF, ISO)
|
|
|
|
---
|
|
|
|
### Expected Scientific Impact
|
|
|
|
**Publications (Target: 10+):**
|
|
- IEEE Symposium on Security and Privacy (IEEE S&P)
|
|
- ACM Conference on Computer and Communications Security (ACM CCS)
|
|
- USENIX Security Symposium
|
|
- Cryptology ePrint Archive (pre-prints)
|
|
|
|
**Topics:**
|
|
- Hybrid PQC key exchange protocols (T4.2)
|
|
- Federated anomaly detection with differential privacy (T3.2)
|
|
- Merkle-based audit trails for critical infrastructure (T2.5)
|
|
- TRL 6 validation case studies (T5.3)
|
|
|
|
**Open-Source Contributions (Target: 500+ downloads):**
|
|
- GitHub repos: vaultmesh-sealer, vaultmesh-verifier, psi-field-service, federation-router
|
|
- Apache 2.0 license (no vendor lock-in)
|
|
- Docker images for easy deployment
|
|
- Documentation: runbooks, API specs, deployment guides
|
|
|
|
---
|
|
|
|
### Link to KPI Dashboard (18 Quantitative KPIs)
|
|
|
|
**See:** PQC_KPI_Dashboard.md for full table
|
|
|
|
**Summary Table (Excellence KPIs):**
|
|
|
|
| KPI ID | Metric | Baseline | Target (M24) | Verification |
|
|
|--------|--------|----------|--------------|--------------|
|
|
| E1 | TRL Level | 4 | 6 | External TRL audit |
|
|
| E2 | PQC Algorithms Integrated | 0 | 3 (Kyber, Dilithium, SPHINCS+) | Code repository tags |
|
|
| E3 | Publications | 0 | 10+ (top-tier venues) | DOI links |
|
|
| E4 | Standards Drafts | 0 | 5+ (ETSI/IETF/ISO) | Draft IDs |
|
|
| E5 | Receipt Throughput | 1,000/day | 10,000/day | Benchmark tests (D2.2) |
|
|
|
|
**All 18 KPIs detailed in Part B Section 2.1 (Impact).**
|
|
|
|
---
|
|
|
|
**Document Control:**
|
|
- Version: 1.0-PART-B-EXCELLENCE
|
|
- Date: 2025-11-06
|
|
- Owner: VaultMesh Technologies B.V. (Coordinator)
|
|
- Section Lead: VaultMesh (with input from all partners)
|
|
- Status: Draft — Ready for Partner Review (Week 2-3)
|
|
- Related: PQC_Architecture_EU_Reviewer.mmd (Figure 1), PQC_KPI_Dashboard.md, PQC_Risk_Register.md (Annex B)
|