Skip to main content
Specification Version: 1.0 Ratified Date: August 31, 2026 | First Published: March 1, 2026 Status: Ratified Standard Author: Mauricio Ortega (Nekzus) & Organización Nekzus Solutions License: CC BY 4.0 Attribution Required / Atribución Requerida: Any use, adaptation, or distribution of these architectural concepts must explicitly attribute Mauricio Ortega (Nekzus) and Nekzus Solutions, and include an official link to this project.

​
1. Introduction

The Logic-Injection-on-Origin Protocol (LIOP) is a decentralized, high-performance binary transport mesh engineered for robust Machine-to-Machine (M2M) artificial intelligence communication. It complements application-level agent protocols by replacing the classical Context-Pulling architecture with the Logic-Injection-on-Origin (LIO) paradigm for high-stakes distributed computation.

​
2. The Logic-Injection-on-Origin (LIO) Postulate

Postulate of Origin (Execution Core): Data must never be pulled to intelligence. Intelligence must be pushed to the data. An LIOP Agent interacting with an LIOP Server pushes executable logic (in the form of compact .wasm modules or dynamically transpiled algorithms). The server securely executes this logic within a strict sandbox and returns only the aggregated mathematical results or filtered lists, preventing unintended PII (Personally Identifiable Information) exfiltration from raw context extraction.

​
3. Topographical Architecture

​
3.1 Network Layer (libp2p & Mesh Networking)

  • LIOP operates atop a decentralized libp2p overlay.
  • Servers (Data Nodes) bind to TCP/QUIC ports and advertise themselves as long-running daemons.
  • Clients (Agent Injectors) connect ad-hoc across local networks or public WAN using Kademlia DHT routing.
  • LIOP operates without centralized brokers or proxy hubs.

​
3.2 Transport & Multiplexing

  • Connections use Multiplexing via Yamux, allowing hundreds of concurrent Logic-Injection-on-Origin injections to occur over a single opened TCP socket without Head-Of-Line Blocking.

​
3.3 RPC Layer (Tonic / gRPC)

  • Raw binary payloads are encapsulated in strict Protobuf definitions (.proto).
  • The entire LIOP interaction relies on Protocol Buffers transmitted over HTTP/2 via Tonic, eliminating JSON-RPC serialization overhead natively.

​
4. Cryptographic Security Architecture

​
4.1 Post-Quantum Key Encapsulation (ML-KEM-768)

  • At initialization, connections instantiate a Post-Quantum Handshake. LIOP employs ML-KEM-768 (Kyber) to negotiate shared secrets securely against quantum-computing decrypt attacks (“Harvest Now, Decrypt Later” protection).
  • Session Lifecycle: PQC session keys feature a deterministic 1-hour time-to-live with automated silent re-keying.

​
4.2 Post-Quantum Digital Signatures (ML-DSA-65)

  • Node identity and non-repudiation are sealed using ML-DSA-65 (Dilithium) post-quantum signatures, ensuring cryptographic authenticity across untrusted network hops.

​
4.3 Symmetric Payload Sealing

  • The agreed Post-Quantum symmetric secret acts as the cipher for AES-256-GCM, enveloping the entirety of the execution payload inside a zero-trust capsule.

​
4.4 Computational Integrity (ZK-Receipts & ZK-VM)

LIOP defines a tri-modal cryptographic integrity framework providing verifiable non-repudiation:
  • Mode 0 (HMAC_LEGACY, 0x00): Symmetric commitment derived from the ML-KEM-768 shared key.
  • Mode 2 (GROTH16, 0x02): Zero-knowledge succinct non-interactive proof over BN254 curves with a 144-byte binary journal (guest_image_id, logic_digest, dataset_digest, output_digest, fuel_consumed, execution_timestamp).
  • Mode 3 (GROTH16_PQC_HYBRID, 0x03): Dual-sealed binary receipt combining the Groth16 proof with an ML-DSA-65 post-quantum digital signature (NIST FIPS 204) of 3,309 bytes and 1,952-byte public key over SHA-256(journal || proof).
  • Binary v2.1 Wire Layout: [0x02][0x03][journalLen: 4B BE][journal: 144B][proofLen: 2B BE][proof][sigLen: 2B BE][signature: 3309B][publicKey: 1952B][checksum: 32B SHA-256]
  • Dataset Integrity Anchor: Receipts embed a SHA-256 dataset_digest, guaranteeing that Differential Privacy perturbations and aggregation logic are strictly anchored to immutable origin data.

​
4.5 Hardware TEE Pre-Flight Attestation

Before logic injection is dispatched into confidential enclaves, nodes submit hardware attestation evidence validated by verifyTeeAttestationDetailed:
  • AMD SEV-SNP: Validates 1,184-byte binary reports, confirming that REPORT_DATA at byte offset 0x50 strictly binds to SHA-256(publicKey || nonce).
  • AWS Nitro Enclaves: Validates COSE_Sign1 documents, asserting PCR boot measurements and embedded public key bindings in user_data.

​
5. Execution Core Architecture

​
5.1 WASI Instantiation & Environment Isolation

  • Injected logic is deployed into a bare-metal Wasmtime Virtual Machine or V8 Isolate implementing the WebAssembly System Interface (WASI).
  • Poisoned Globals: 25 dangerous host globals (eval, Function, process, require, WebSocket, fetch, etc.) are actively poisoned with security traps.
  • Prototype Freezing: 11 core JavaScript prototypes (Object, Array, Function, String, etc.) are deeply frozen prior to execution, mitigating Prototype Pollution (CWE-915).
  • Deterministic CPU Fuel: Execution is constrained by AST-derived fuel limits, neutralizing infinite loops and computational denial-of-service attacks.
  • Worker Pool Warmup: Pre-warmed Piscina thread pools eliminate V8 cold-start overhead (~820k fuel reduction).

​
5.2 Static AST Guardian

  • Before a payload enters the execution engine, LIOP evaluates its Abstract Syntax Tree (AST). It discards payloads attempting to import modules outside of the 14-function strict WASI allowlist, supporting top-level return expressions for dynamic modules.

​
5.3 Egress PII Defense

  • The LIOP SDK injects a Tier-1 PII Shield at the Egress stage. Employs a 4-stage pipeline: exact key match → fuzzy match → regex pattern validators (Luhn algorithm for credit cards, SSN, email, phone) → Named Entity Recognition (NER).

​
5.4 Differential Privacy Engine (NIST SP 800-226)

  • Automatically injects query-aware Laplace noise into numeric egress fields when operating on small datasets (n<10n < 10).
  • Enforces an ϵ≥1.0\epsilon \ge 1.0 privacy floor and defaults to OS-level CSPRNG (crypto.randomBytes).
  • Deterministic Differential Privacy (DDP): For audit reproducibility, supports SHA-256-seeded PRNG derived from dataset_hash + image_id, producing verifiable, repeatable ZK-Receipts.

​
5.5 Tiered Query Sensitivity Budget (NIST SP 800-226)

  • Tracks information leakage using a 3-tiered field sensitivity classification:
    • forbidden: 3 queries/session (PII identifiers, direct keys).
    • sensitive: 8 queries/session (biometric, financial, diagnosis fields).
    • public: 25 queries/session (general categorical and metric fields).

​
6. Autonomous Protocol Remediation

LIOP features built-in self-instructing middleware. Should an Agent attempt a JSON-RPC interaction over MCP legacy adapters that violates the Logic-Injection-on-Origin protocol structure (such as attempting raw data extraction), LIOP intercepts the request, blocks it, and returns a structured instructional prompt enabling the Agent to reformat its intent as injected logic.

​
7. Dual-Era MCP Compatibility & Gateway Adapter

  • MCP v2 Support: Full compliance with the 2026-07-28 specification (subscriptions/listen and resources/templates/list) without polling overhead.
  • Legacy Fallback: Automatic compatibility with 2025-11-25 JSON-RPC clients.
  • gRPC-Web Framing: HTTP/1.1 framing adapter for browser and edge clients.
  • Production Telemetry: Integrated /healthz, /readyz, and Prometheus /metrics endpoints.

​
8. Specification Governance

Technical amendments to this specification follow the LIOP Enhancement Proposal (LEP) process. All LEPs must maintain strict compliance with the 7 Design Principles defined in the Origin Manifesto.