NTL Specification — Formal Protocol Definition

Version: beta_0.0.0 Status: Beta Authors: The Bundu Foundation License: Apache 2.0

Abstract

The Neural Transfer Layer (NTL) is a neural signal-based data transfer layer for modern compute systems. It replaces the request-response paradigm of traditional APIs with signal propagation through a self-organizing, weighted graph topology. NTL is designed for AI-native systems, Web3 compatibility, post-quantum cryptographic agility, and resource-constrained environments.

Versioning

The specification carries its own version, independent of any implementation’s: beta_MAJOR.MINOR.PATCH, starting at beta_0.0.0. Two separate things were previously conflated under one number. A specification and an implementation of it move at different speeds and for different reasons — a wording clarification is not a release, and a bug fix in the reference implementation is not a specification change. Sharing a version made every implementation release look like a protocol revision. So:

What	Versioned as	Increments when
This specification	`beta_0.0.0`	A normative requirement is added, changed or removed
The reference implementation	semver (`0.2.0-beta.1`)	Ordinary release cadence, independent of this document

The crates and npm packages must carry semver, because Cargo and npm require it — beta_0.0.0 is not a valid semver string and would fail to build. That is not a workaround; it is the separation above working as intended. Within beta_, the three numbers mean what they usually do. A patch bump is editorial: clarified wording, a corrected example, a stated consequence that was already implied. A minor bump adds a requirement without invalidating a conforming implementation. A major bump breaks one — a changed MUST, a wire format revision, a removed guarantee. The beta_ prefix drops when a second independent implementation interoperates; see below for why that is the gate.

Status of This Document

Beta. Every normative requirement here is implemented and tested in the reference implementation, which is what moved this out of draft: a specification whose claims nobody has run is a design document, not a spec. Beta rather than final because interoperability has been demonstrated between two instances of one implementation, not between two independent ones. Wire formats and normative requirements will not change gratuitously, but a second implementation is the thing most likely to find a requirement that is ambiguous or unimplementable as written, and that feedback is worth a version number. Where the reference implementation does not yet satisfy something this specification requires, the gap is stated in the document that requires it rather than left for a reader to discover — see crypto-interface on pq-v1 and threat-model §8 on verified delivery beyond one hop. Feedback is welcome via the GitHub repository.

Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

Specification Documents

The NTL specification is divided into the following documents:

Signal Format

Binary format, fields, encoding, and validation rules for NTL signals

Synapse Lifecycle

Formation, state transitions, weight management, and pruning of synapses

Propagation Rules

How signals route through the network topology

Activation Model

Threshold-based signal processing and flow control

Crypto Interface

Pluggable cryptographic module specification

Adapter Contract

Interface specification for protocol translation adapters

Learning Model

Reward signals, weight updates, decay, and exploration sampling

Delivery Semantics

Best-effort and acknowledged delivery, retry, and idempotency

Threat Model

Adversarial analysis, and what NTL does not defend against

Storage Interface

What a node must persist, and durability per deployment class

Changes in beta_0.0.0

This revision closes the gaps that made the routing claims uncheckable and the protocol unusable for transactional traffic, and it is the first revision whose requirements are all exercised by a running implementation.

Change	Document
Routing model given an explicit reward signal, update rule, decay, and exploration policy	new learning-model
Adversarial analysis of learned routing, with an explicit out-of-scope list	new threat-model
`acknowledged` delivery class — failure is always reported	new delivery-semantics
Storage defined as a pluggable contract, not a named database	new storage-interface
Firing ambiguity resolved; bounded queue and overflow policy specified; refractory period made a node-class parameter	activation-model
Deterministic top-N fanout replaced with stochastic sampling; receipt handling and outcome journalling added	propagation-rules

Design Goals

Signal-native — The fundamental data unit is a signal, not a request
Self-organizing — Network topology emerges from usage patterns
Storage-agnostic — Nodes persist state through a pluggable interface; no database is privileged
Crypto-agile — No cryptographic scheme is hardcoded
Resource-efficient — Designed for constrained devices and networks
Interoperable — Adapters enable Web2, Web3, and legacy system connectivity
Open — Fully open source, community-governed specification

Reference Implementation

The reference implementation is maintained by Nyuchi Web Services under The Bundu Foundation in Rust:

Repository: github.com/openNTL/ntl
Language: Rust
Minimum Rust Version: 1.85
License: Apache 2.0

The reference implementation is authoritative for behavior not fully specified in this document. Where the specification and implementation differ, the specification takes precedence, and the implementation should be updated.

​Abstract

​Versioning

​Status of This Document

​Conventions

​Specification Documents