Global Neural System
The network substrate that connects nodes into a shared system for storage, communication, and compute.
ENTENCY GNS — Global Neural System — is the network and runtime substrate that unites content storage, communication, compute, and service hosting. Its current implementation combines deterministic canonical state with a separate content-addressed data fabric.
Core state, chunk/object handling, and compute quorum have implementation evidence. Public-devnet networking and higher-level services remain foundations; this is not a production public-network announcement.
Global Neural System describes an architecture where nodes exchange content and coordinate services across a common network. Today, the strongest completed layers are the deterministic state engine, content references, and bounded coordination primitives. Hosting, streaming, and public-network operation have narrower foundation scope.
A GNS node maintains identity and peer state, discovers and synchronizes with peers, applies canonical state transitions, and serves object/chunk and diagnostic interfaces. Chain consensus commits references and roots; content bytes stay outside the consensus transition. Replay and reorganization rebuild canonical references deterministically.
IMPLEMENTED IN DEVELOPMENT
Content is split into chunks, hashed, stored, and verified. Manifests describe objects such as gns://object/. Canonical object references, expiry, and finalized pruning govern lifecycle; live provider replication and durable decentralized hosting remain separate work.
FOUNDATION
Stream, channel, and message contracts have import, state, and query foundations. Delivery receipts and policy checks add evidence and access control. Runtime observations do not become canonical facts automatically; production reliable messaging and media streaming are not complete.
IMPLEMENTED IN DEVELOPMENT
Canonical jobs, signed participant votes, and bounded quorum rules determine finalization, including failure outcomes. This state and replay logic is implemented. The execution runtime remains bounded; GNS is not yet a general-purpose production compute service.
The peer network uses discovery hints, a peerbook, expiring peer announcements, and minimum/maximum peer policies. Framed hello, header/block exchange, gossip, and anti-entropy synchronization have development evidence. The exercised framed carrier is HTTP; final internal TCP+TLS transport parity is not established.
Nodes accept configured bootstrap peers and a chain-specific seed registry supplied by configuration. Invalid or duplicate peers are handled explicitly; a configured seed is not proof of a connection. No built-in public seed fleet is established. Endpoint management separates loopback, LAN, observed public addresses, and verified mapping candidates.
UPnP and NAT-PMP mapping code includes renewal, withdrawal, and restart handling. Public advertisement requires suitable endpoint verification; merely observing an external address is insufficient. The latest real-router test did not create a public mapping, and independent remote acceptance was not performed. Router and network compatibility remain practical limits.
Framed relay envelopes, quota controls, and handshake fallback have local test evidence. Route diagnostics distinguish direct LAN, direct public, and relayed attempts. This is a relay foundation, not a proven public relay fleet or a guarantee of connectivity behind every NAT or CGNAT.
Transport NodeID is separate from producer/wallet identity. The current peer handshake checks identity consistency but does not prove possession of the advertised transport key: connected routes remain identity-claim-only, not authenticated peers. Transport encryption and public-network security must not be inferred from connectivity or TLS configuration labels.
Canonical capabilities support signed grants, revocation, and delegation with narrower actions, scope, and depth. Reputation is bounded and derived from canonical events. Peer scoring, rate limits, content verification, and reorganization guards provide implemented hardening; they do not close the full production security model.
Application and service registries bind identity, namespace, runtime-package, and schema references. Hosting foundations add publication revisions, object/chunk asset bindings, provider capability checks, freshness, and replica-fallback plans, audit traces, and operator readiness gates. Registering a service does not execute it; these contracts do not prove live multi-provider publishing, retrieval, or replication.
Hash-addressed objects and application/service namespaces provide addressing foundations. Hosting route identities are modeled, but public DNS and zero-configuration public hosting are not complete. Predictive cache/prefetch/routing evidence is deterministic and fixture-backed, not production adaptive AI routing.
Node diagnostics expose configuration, peers, bootstrap, reachability, NAT/relay limits, and transport state through CLI and query interfaces. The explorer rebuilds read models from canonical state and events; its views are not independent authority.
ENT is the network fuel/token terminology. Contribution records and accounting foundations model reserves, fee debits, and reward credits. This does not establish complete token economics, production reward correctness, exchange functionality, or an available public token service.
Implemented means supported by repository code and evidence. Foundation means working building blocks with explicit limits. Neither label means a production release or an open public network. Content reviewed 10 September 2026.
Canonical state/replay, chunks and objects, object governance, bounded reputation, delegated capabilities, and compute job/vote finalization have implementation and test evidence. Node discovery and diagnostic interfaces also exist in development.
Public-devnet configuration, NAT mapping and relay paths, communication/stream contracts, ENT accounting, application/service registries, and hosting readiness are foundations. Live provider durability, transport authentication, and full production security are not established.
Future work includes independently evidenced Internet connectivity, production transport and relay operation, live distributed hosting, and broader service execution. A production public network, universal automatic connectivity, and finished token economics are not claimed.
Start with the Litepaper for the ecosystem model and current direction. The Technical Whitepaper destination explains the planned technical coverage and its publication status.
Read the available introduction to GNS, UP, identity, and the relationship between the components.
READ THE LITEPAPER →Detailed protocols, security and implementation documentation are not yet published. Follow the existing documentation page for its status.
VIEW DOCUMENTATION STATUS →There is no public node package linked here yet. Development updates and future test-access announcements are available through the existing Early Access section. This page will become a starting point for verified node releases when they are published.