- Overview
- Why it matters
- Core Architecture
- Architecture Diagrams
- Receipt Flow
- Offline Sync Model
- Adaptive Communications Layer
- Test Harness
- Standards Governance
- Conformance & Certification
- Testing & Verification
- Target Sectors
- Licensing
- Reference Implementation
- Financial Sector Integration
-->
Repository Status: This is the authoritative standard for the XIP Protocol (Luma Core OS). For the reference demo implementation, see: https://github.com/verimesh/luma-core-demo
Version: 1.5.0 Status: Stable Maintainer: Maintained by VERIMESH / Luma Core Protocol Authority Contact: https://verimesh.net | info@verimesh.net
XIP (Cross-Hub Integrity Protocol) is the foundational standard powering LumaCore OS — a sovereign, offline-first operating environment built for government, emergency services, utilities, healthcare, and any regulated environment where cloud dependency is unacceptable.
In plain terms: every field action taken on a LumaCore OS device is automatically recorded as a cryptographically signed, hash-chained receipt — tamper-proof, auditable, and legally defensible — with zero cloud dependency at any point.
XIP defines exactly how those receipts are structured, verified, merged across devices, and optionally exported to regulated systems.
Modern field operations technology breaks when:
- Cloud services fail
- Connectivity is lost
- Systems cannot verify what happened offline
- Centralised authority is unavailable
XIP solves this by making the device the authority, not the server.
This enables:
- Emergency services to operate during network outages
- Government field operations to record legally defensible actions offline
- Utilities to maintain tamper-proof maintenance logs in remote locations
- Healthcare to run disconnected without losing audit continuity
XIP consists of five interacting layers:
┌─────────────────────────────────────────────────┐
│ EXPORT LAYER (ISO 20022 / Regulatory) │
├─────────────────────────────────────────────────┤
│ ADAPTIVE COMMUNICATIONS LAYER (Patent Pending)│
├─────────────────────────────────────────────────┤
│ SYNC ENGINE │
├─────────────────────────────────────────────────┤
│ HUB FRAMEWORK │
│ Gov · Finance · Health · Utilities · Justice │
├─────────────────────────────────────────────────┤
│ RECEIPT LAYER │
│ Hash-Chain · Signature · Timestamp · Device ID │
└─────────────────────────────────────────────────┘
The XIP Protocol defines a universal audit-receipt and offline-continuity layer used across LumaCore OS's modular hub ecosystem (Government, Finance, Health, Utilities, Justice, Rescue). It guarantees deterministic receipts, verifiable sync, and audit-ready records under all network conditions — including complete offline operation.
- Event: Any state-changing action emitted by a hub.
- Receipt: A signed, hash-chained representation of an event.
- Chain: Ordered sequence of receipts.
- Hub: A functional module (Finance, Government, Utilities, etc.).
- Device: Any endpoint capable of storing, emitting, or syncing receipts.
- Sync: Deterministic merge of offline and online receipt chains.
XIP consists of:
- Receipt Layer – Deterministic, hash-chained, signature-verified.
- Sync Engine – Cross-device conflict resolution and re-merge.
- Hub Framework – Standardised event types per hub.
- Adaptive Comms Layer – Mesh, Wi-Fi, LTE/5G, and satellite-ready path selection. (Patent Pending)
- Export Layer – ISO 20022 aligned structures for regulatory export.
Every LumaCore hub uses the same receipt foundation:
- Unified event schema
- Cross-hub signature validation
- Offline-first guarantees
- Zero-knowledge minimisation
- Cross-border compatibility
This prevents fragmentation and ensures receipts are portable across jurisdictions and departments.
This layer selects the best available transport automatically — with no server dependency:
- Local mesh
- Direct P2P
- Cell network (3G/4G/5G)
- Wi-Fi
- Satellite-grade fallback
All communication paths are optional. Devices operate indefinitely offline.
Each receipt contains:
- Event metadata
- Zero-knowledge payload
- Previous hash
- Signature block
- Device ID (non-personal)
- Hub ID
- Optional regulatory reference
This creates tamper-proof, permanently verifiable audit trails suitable for regulated environments.
XIP defines deterministic conflict rules:
- Longest valid chain wins
- Conflicts resolved via event timestamp + hub-priority
- Divergent chains re-merge without data loss
- Cross-hub events remain verifiable
- No server authority required
This model allows field teams, regions, or entire departments to operate offline and sync when back online.
XIP provides:
- Zero-knowledge receipts
- GDPR-aligned data minimisation
- Replay protection
- Multi-device signing
- Immutable audit trails
- No biometric identifiers — pseudonymous device IDs only
- No surveillance, profiling, or automated decision-making
Fig.1 — XIP-0001 System Architecture: five-layer stack
Fig.2 — XIP-0001 receipt creation, hash-chaining, and signing flow
Fig.3 — XIP-0001 offline chain divergence and deterministic re-merge
Fig.4 — XIP-0001 Adaptive Communications Layer path selection (Patent Pending)
Fig.5 — XIP-0001 test harness and validation coverage
The XIP Protocol specification is maintained by the VERIMESH Protocol Authority.
Specification updates follow a versioned release process and are published as numbered protocol documents.
- XIP-0001 — Core Protocol Specification (current stable standard)
- XIP-0002+ — Future protocol extensions and improvement proposals
All official releases are versioned and published through the repository release system.
Current stable version: XIP Protocol v1.5.0
Implementations of the XIP Protocol may be validated against the official specification through deterministic test harness verification.
Conformance testing evaluates whether a system correctly implements the core protocol guarantees:
- Deterministic receipt creation
- Hash-chain integrity and tamper detection
- Device-level signature validation
- Offline chain divergence handling
- Deterministic sync and merge rules
- Export-layer schema compliance
The reference validation environment includes simulation and operational tests covering:
- Mesh and partitioned network behaviour
- Prolonged offline operation
- Satellite-grade latency conditions
- Conflict and replay protection scenarios
- Multi-device deployment verification
Systems that pass validation are considered XIP Conformant Implementations.
Certification requirements for regulated or sovereign deployments are defined under the LumaCore licensing framework.
For validation access or certification enquiries:
https://verimesh.net | info@verimesh.net
The protocol has undergone multi-environment simulation covering:
- Mesh dynamics
- Partition + merge
- High-latency satellite models
- Packet loss, jitter, degraded links
- Offline chain splits
- Deterministic merge rules
- Conflict resolution
- Cold-start rejoin
- Hash-chain tamper detection
- Multi-signature edge cases
- ZK data-minimisation validation
- Samsung Knox rugged tablet provisioning (March 2026)
- Multi-device deployment completed
- Real operational provisioning runs confirmed
- UK Government (central and local)
- Emergency Services (police, fire, ambulance)
- Utilities (energy, water, infrastructure)
- Healthcare (NHS trusts, community health)
- Justice and legal
- Defence-adjacent field operations
The XIP Protocol is maintained by the inventor and patent holder (VERIMESH). Use of XIP in commercial, governmental, or nationwide deployments requires a signed licence agreement and release key under the LumaCore OS licensing model.
Copyright (c) 2023–2026 VERIMESH / Luma Core. All rights reserved.
For licensing, sovereign deployment, or technical review: https://verimesh.net | info@verimesh.net
- LumaCore Demo (Ultraslim PWA): https://luma-core-demo.netlify.app
- Demo Source: https://github.com/verimesh/luma-core-demo
- Protocol Source: https://github.com/verimesh/luma-xip-protocol
For financial institutions, CBDC teams, and regulated payment networks, XIP includes an optional Export Layer providing:
- ISO 20022 alignment — receipts map to MX message structures for cross-border compliance
- XRPL compatibility — receipt metadata compatible with XRPL transaction hooks and settlement proofs
- Stablecoin settlement compatibility — optional backing and reconciliation via regulated stablecoin rails, without affecting offline operation
- Offline bearer cash model — QR-based, single-use, burn-on-scan tokens enabling secure offline value exchange with full receipt auditability, independent of banking or network availability
This module is entirely optional and does not affect core OS operation. Government and emergency services deployments do not require or use this module.
See docs/standards-pack/03-XIP-ISO20022-Mapping.md and 04-XIP-XRPL-Mapping.md for full documentation.
VERIMESH — Sovereign Field Operations Technology verimesh.net