# Date: March 14, 2026
Phase: Alpha-Kernel stabilization and security hardening

This development cycle marked an important milestone in the evolution of NØNOS { operating system } and what began as a routine verification of graphical file operations quickly expanded into a deep technical audit of the kernel and its surrounding subsystems. During this session we uncovered and resolved more distinct issues affecting system reliability, memory safety and filesystem consistency. The work extended across nearly every layer of the system from low-level syscall handlers and synchronization primitives to the graphical file manager and application runtime. The result of this effort is a substantially more robust kernel. NØNOS starts to move beyond a proof-of-concept stage toward a hardened OS with predictable behavior, consistent error handling and well-defined memory boundaries between kernel and userspace.

This report summarizes the changes implemented during the session and the reasoning behind them.

Phase 1: IPC and Timer infrastructure

The initial work focused on the kernel inter-process.

IPC mechanisms are fundamental to the system architecture. They allow independent processes to exchange information while remaining isolated from one another. The original implementation worked in practice but lacked structural clarity and contained several unsafe patterns. One area that required immediate attention was the mechanism used for passing timing data between kernel and userspace. The previous design relied on direct pointer manipulation. While this approach was fast, it violated the basic security rule that the kernel must never blindly trust addresses supplied by userspace programs. To correct this, all direct pointer operations were replaced with calls to the kernel validated usercopy interface. Every transfer of data between kernel memory and userspace now passes through a controlled API that verifies the destination address before performing the operation. During this phase we also reorganized the select and eventfd subsystems. Several large files had grown difficult to maintain. They were split into smaller modules with clearly defined responsibilities. Each module now focuses on a single aspect of functionality, making the system easier to reason about and safer to modify in the future.

Phase 2: Filesystem foundation audit

{ NONOS uses an in-memory filesystem, ( RAMFS )
  as its primary storage mechanism. }

Audit details revealed several inconsistencies that could lead to incorrect behavior.

Directory Marker System

Directories in ramfs are represented using marker files with a .dir suffix stored within a flat BTreeMap. This design minimizes overhead and simplifies lookup operations but it requires strict consistency when constructing marker paths. Different parts of the codebase were generating these marker paths in slightly different ways. Some functions appended .dir directly to the path string, while others normalized trailing slashes first. These small inconsistencies caused directories to become invisible or undeletable under certain access patterns. To eliminate this problem, we introduced a single canonical rule: all paths must be normalized before marker generation. Trailing slashes are removed and only then is the .dir suffix appended. Applying this rule consistently across the filesystem removed an entire class of subtle bugs.

Root Directory Initialization

Another issue appeared during filesystem initialization. The root directories /ram, /disk, /home and /tmp were conceptually present at boot but lacked the marker files expected by the virtual filesystem layer. As a result, attempts to create files inside these directories sometimes failed silently because the VFS layer could not confirm the presence of the parent directory. The fix was straightforward but essential: marker files are now created explicitly during filesystem initialization. This change is invisible to users but ensures that directory validation behaves correctly from the moment the system boots.

Atomic Filesystem Operations

Several filesystem operations were vulnerable to time-of-check-time-of-use conditions. A common pattern involved checking whether a file existed and then performing an operation based on that result. If another thread modified the filesystem between the check and the operation, the result could be incorrect or inconsistent. To resolve this, we introducing atomic primitives that combine validation and execution in a single locked operation. The write_or_create function illustrates this approach. Rather than performing separate existence checks, the function performs both tasks within a single protected critical section. This eliminates race conditions and guarantees consistent filesystem state.

Phase 3: Syscall handler hardening

{ System calls form the boundary between untrusted userspace 
  applications and privileged kernel code. Ensuring that this 
  boundary is robust is essential for system security. }

Each syscall handler was audited for unsafe memory access patterns and insufficient validation.

Memory Safety Improvements

Several clock-related syscalls originally wrote time values directly into userspace pointers without validating those addresses first. A malicious application could exploit this behavior by providing kernel addresses instead of userspace addresses. All syscall handlers now interact with userspace memory exclusively through the usercopy API. This ensures that memory accesses are validated, faults are handled gracefully and consistent error codes are returned to applications.

Preventing Integer Overflow

Arithmetic involving user-supplied values was another source of potential vulnerabilities. For example, the mprotect syscall computed memory region boundaries by adding user-supplied offsets to base addresses. Without overflow checks, carefully crafted inputs could wrap around the address space and produce invalid results. These calculations have now been replaced with checked arithmetic operations such as checked_add. When an overflow would occur the kernel returns an error rather than continuing with undefined behavior.

Signalfd Race Condition

A subtle race condition was discovered in the signalfd instance allocation logic. The previous code checked available capacity, released a lock, generated an identifier, and then reacquired the lock to complete insertion. This allowed another thread to intervene and modify the state between steps. The new implementation holds the lock continuously throughout the creation process. This ensures that the state cannot change during allocation.

Phase 4: GUI application stabilization

Testing the graphical file manager revealed additional integration issues between the user interface layer and the filesystem.

Clipboard Path Handling

The file manager clipboard system used fixed-size buffers to store file paths during copy operations. When paths exceeded the buffer size, they were silently truncated. Pasting such entries produced confusing results. The new implementation verifies path length before performing any copy operation. If the path exceeds the allowed capacity, the operation fails with a clear error message instead of corrupting the data.

Filesystem-Aware Name Validation

The file manager previously enforced an eleven-character name limit across all filesystems. This restriction originates from FAT32 historical 8.3 filename format but does not apply to ramfs. Name validation is now filesystem-specific. Ramfs supports names up to 63 characters while FAT32 operations continue to enforce their native restrictions.

Paste Semantics

Paste operations previously relied on write_file which requires the destination file to exist beforehand. Attempting to paste into a new location therefore failed. The operation now uses write_or_create, which correctly handles both existing and new files.

Phase 5: Deep security audit

{ Once the most visible issues were resolved.
  A full audit of the filesystem, syscall layer 
  and GUI components was performed. }

Buffer Safety

Several buffer operations lacked proper bounds checks. The wallet password input field and clipboard buffers were particularly vulnerable when handling long input sequences. These routines now verify buffer limits before performing any write operation.

Error Propagation

Many functions previously suppressed errors internally and continued execution as if the operation had succeeded. This created misleading system statistics and confusing application behavior. Error handling has now been standardized. Failures propagate to callers, and statistics counters update only after successful operations.

Directory entry enumeration

The getdents syscall performed arithmetic on directory entry lengths without overflow checks. Malformed entries could produce incorrect buffer sizes. Overflow-safe calculations have now been introduced, preventing these edge cases.

Addressing technical debt

In addition to bug fixes, this session addressed several long-standing structural issues.

Module Organization

Large source files were divided into focused modules, each handling a single responsibility. The mod.rs pattern is now used purely for exports, while implementation code resides in dedicated files. This change significantly improves code navigation and reduces merge conflicts.

Consistent coding patterns

Common operations now follow consistent conventions. Path normalization, error naming and lock ordering all adhere to defined patterns. Consistency reduces cognitive overhead and prevents subtle bugs from reappearing.

Code Clarity

Unsafe blocks retain minimal documentation explaining the invariant being relied upon.

Methodology

The debugging process followed a systematic approach.

We began by exercising the graphical file manager under normal usage patterns. When failures occurred, we traced them back through the application layer to their kernel origins.

Once immediate problems were resolved, broader subsystem audits were performed. These audits focused on known failure patterns: unchecked arithmetic, unsafe memory access, inconsistent state transitions, and race conditions.

Fixes were applied incrementally, favoring small targeted changes over large rewrites.

Future Work

Several areas remain candidates for further development.

FAT32 support currently operates primarily at the root directory level. Extending full directory hierarchy support would improve interoperability with external storage devices.

The implementations of signalfd, eventfd and timerfd share similar patterns and could benefit from a unified abstraction.

Finally, systematic performance profiling has not yet been conducted. Future work will examine lock contention and latency in critical subsystems.

To conclude…

This development session marked a turning point in the maturity of the kernel. The combination of targeted debugging and systematic auditing resolved numerous issues that would otherwise have surfaced during deployment. More importantly, the changes established stronger foundations for the system going forward. The kernel now enforces clearer boundaries between userspace and privileged code, filesystem behavior is consistent and subsystem organization has improved significantly.

In December 2025, we published a technical whitepaper for NØNOS, an operating system designed around a single principle: leave no trace. One month later, the system boots to a graphical desktop. This article document what exists today, verified line by line against the source code. Nothing here is assumed or invented.

The NØNOS kernel currently stands at 369,436 lines of Rust code spread across 1,711 source files. { kernel + bootloader }

One of our deliberate architectural decision: large monolithic source files have been systematically broken apart into focused, single-responsibility modules organized in subdirectories.

This refactoring is not bloat. This pattern repeats throughout the codebase. The result is more maintainable code with clearer boundaries between components.

The compiled kernel binary grew from roughly Ca.300 kilobytes to 7.6 megabytes. The bootloader adds another 475 kilobytes.

The bootable USB image is 67 megabytes, formatted as a GPT-partitioned FAT32 EFI system partition ready to boot on any UEFI system. This growth represents real functionality that did not exist before: a complete cryptographic library implementing both classical and post-quantum algorithms, a
zero-knowledge proof engine with Groth16 verification, a graphics subsystem with font rendering and window management, a full TCP/IP network stack with onion routing and drivers for NVMe, AHCI, VirtIO, PS/2, USB HID and I2C HID devices and more stacks.

The codebase contains only six panic!() calls, all in situations representing genuinely unrecoverable errors like double faults. There are four uses of unreachable!(), all serving as compile-time assertions that certain match arms cannot be reached. This is an exceptionally clean codebase by any standard.

The capability system now contains a functional implementation. The module exports functions for creating, signing, verifying and revoking capability tokens. The signing function takes a token and a private key, constructs the canonical byte representation of the tokens fields, computes an Ed25519 signature over those bytes, and attaches the signature to the token. The verification function performs the inverse operation, checking that the signature was produced by the claimed public key over the exact bytes that the token contains. The token structure includes an expiration timestamp, preventing captured tokens from being replayed indefinitely. The revocation mechanism allows tokens to be invalidated before their natural expiration.

The zero-knowledge proof engine exports a complete interface for compiling circuits, generating proofs and verifying them. The implementation uses the Groth16 proof system with the BLS12–381 elliptic curve pairing.

The circuit compiler takes a high-level description of constraints and produces the rank-one constraint system representation required by Groth16. The setup phase generates proving and verification keys using a structured reference string. The prover takes a witness satisfying the constraints and produces a succinct. proof. The verifier checks the proof against the public inputs and verification key. Boot attestation is mandatory.

***The bootloader will not transfer control to the kernel without a valid ZK proof embedded in the kernel binary.***

The cryptographic module provides a comprehensive suite of algorithms spanning classical, post-quantum, and zero-knowledge domains. For classical public-key cryptography, the module implements Ed25519 for signatures and X25519 for key agreement. For symmetric encryption, the module provides AES-GCM and ChaCha20-Poly1305, both authenticated encryption schemes that protect confidentiality and integrity. For hash functions, the module implements BLAKE3 for performance-critical operations, SHA-256 and SHA-512 for compatibility, and SHA3–256 for scenarios requiring independence from the SHA-2 family.

The post-quantum implementations deserve particular attention. The module includes ML-KEM, the post-quantum key encapsulation mechanism standardized by NIST, providing key agreement that remains secure against
adversaries with quantum computers. For signatures, the module implements ML-DSA, the post-quantum signature scheme from NIST. As a hedge against potential weaknesses in lattice-based schemes, the module also includes SPHINCS+, a hash-based signature scheme with security relying only on the properties of the underlying hash function.

The boot sequence implements a multi-stage cryptographic verification chain. After UEFI initialization

the bootloader computes a BLAKE3 hash of the kernel binary, verifies an Ed25519 signature against an embedded public key, and validates a Groth16 zero-knowledge attestation proof. Only after all three checks pass does the bootloader exit UEFI boot services and transfer control. The kernel entry point is a naked function that executes assembly to enable SSE registers before any Rust code runs, avoiding undefined behavior from compiler-generated SIMD instructions. Initialization proceeds through GDT and IDT installation, heap setup, APIC configuration, PCI enumeration, framebuffer initialization from boot information, input device setup, network stack initialization, and finally desktop startup.

The driver subsystem implements support for several storage controllers. The AHCI driver handles SATA devices, implementing command submission and completion queues per the AHCI specification. The NVMe driver handles modern solid-state drives over PCI Express. The VirtIO block driver provides storage access in virtual machine environments. For input devices, the kernel implements PS/2 keyboard and mouse, USB HID, and I2C HID for modern laptop touchpads. The network stack integrates smoltcp for TCP/IP with an onion routing layer that encrypts traffic through three-hop circuits.

The memory management subsystem handles physical frame allocation using a bitmap, four-level x86–64 page tables with guard pages for isolation and a kernel heap with linked-list allocation. All memory lives in RAM. On shutdown, memory is explicitly zeroed before power-off.

Work remains. User-space ring-3 isolation exists but the transition and syscall interface need finishing. SMP initializes application processors but the scheduler remains essentially single-core.

The foundation is solid. The architecture works. Capability tokens are cryptographically signed with Ed25519. The ZK engine verifies Groth16 proofs at boot. Post-quantum algorithms provide security against future quantum threats. The 64 megabyte USB image contains a functional operating system with security features most systems lack entirely.


NØNOS is released under AGPL-3.0.

NØNOS didn’t start as a product pitch. It wasn’t born from a token launch, a company deck, or an urge to disrupt anything. It started with a problem that kept repeating: privacy tools kept improving but the environments they ran in stayed fundamentally untrustworthy. Not because cryptography failed but because operating systems quietly keep history, caches, identifiers, logs, metadata, background services long after a user believes they’re safe. Developers get blamed when privacy collapses, even when the code did what it promised, because the platform beneath it never stopped collecting context. Eventually the real question stops being: “How do we encrypt better?”

It becomes: “Why does the system need to know anything about me at all?” NØNOS exists in the space opened by that question.

The operating system is not neutral

We treat operating systems like neutral ground: inherited foundations you build on top of, not something you challenge.

That assumption doesn’t hold anymore.

The OS decides what persists.

It decides what is observable. It decides what is logged, cached, replayed, correlated and later used against you.

Modern mainstream systems are built around permanence:

permanent storage, permanent users, permanent identities, long-lived processes and services, logs as a default, background subsystems that accumulate state etc.

We then try to “add privacy” on top but you can’t reliably bolt anonymity onto a system designed to remember. You can’t claim sovereignty while inheriting architectures that treat history as valuable and identity as normal. Linux deserves respect, it’s a masterpiece and it shaped generations of engineers but its core assumptions come from an older world: shared machines, stable users, long-running sessions, permissions accumulating over time.

Over decades, complexity piled on: invisible caches, implicit state, firmware dependencies, DMA assumptions, sprawling subsystems, and paths no single human can fully audit end-to-end. That doesn’t make Linux malicious.

It makes it a poor base layer for a privacy model that demands deliberate forgetting. NØNOS exists because that problem isn’t solvable as an overlay.

Refusing Inheritance.

NØNOS is not an evolution of existing operating systems.

It is a refusal to inherit them.

The system is built around one principle:

Privacy isn’t mainly about hiding actions.

Privacy is about preventing stable identity, durable history, and unwanted state from forming in the first place.

In NØNOS: nothing persists unless you explicitly choose it

1) no silent accumulation happens because that’s what systems do

2) no long-lived identity is assumed by default

3) no background telemetry exists waiting to be correlated later

4) The system lives in memory.

When power disappears, the session collapses with it. That isn’t aesthetic; it’s the security model.

Boot is where trust is won or lost

In NØNOS, trust is never implied. It is constructed explicitly at boot then enforced. The bootloader is not just a thin stage that “jumps to the kernel.” It is the first hard boundary. Before the kernel executes a single instruction, the bootloader:

1) collects final UEFI firmware state

2) captures the post-ExitBootServices memory map

3) records ACPI and SMBIOS descriptors

4) seeds entropy and timing baselines

5) measures the kernel binary cryptographically

6) verifies a signed kernel capsule

7) verifies an embedded zero-knowledge proof of authorization

Only if every step succeeds does execution continue.

All of this is packaged into a strict handoff structure: a fixed memory layout passed as the first argument to the kernel entry point. No late discovery. No fuzzy inference. No “we’ll query that later.”

The kernel validates the structure immediately. If validation fails, the system halts. This design is intentional: early boot is where most systems are weakest and where ambiguity becomes an exploit surface.

What “Explicit and Deterministic Handoff” means

“Explicit and deterministic handoff” means the kernel does not infer system state.

It doesn’t scan firmware later.

It doesn’t opportunistically query hardware.

It doesn’t rely on undocumented behaviors or “common” platform quirks.

Everything the kernel is allowed to know is provided once, in a bounded structure, validated on entry, and treated as immutable. That includes:

1) physical memory layout (usable, reserved, MMIO)

2) firmware provenance and security flags

3) framebuffer configuration

4) cryptographic measurements

5) entropy seed

6) timing baselines

7) zero-knowledge attestation results

This eliminates broad classes of TOCTOU problems and reduces the attack surface created by “deferred trust.”

Zero-Knowledge at the Point of Power

The zero-knowledge system in NØNOS isn’t there for aesthetics. It solves a specific problem: how do you prove a kernel is authorized to run without revealing who authorized it, how it was built, or which private keys exist behind the authorization?

The answer isn’t “more signatures.” The answer is proof.

The kernel capsule contains:

{ the kernel ELF binary, an Ed25519 signature, a Groth16 zero-knowledge proof and a cryptographic commitment binding the proof to the exact kernel binary }

The bootloader verifies the proof using BLS12–381 pairings. The proof attests that the kernel satisfies an authorization circuit — without exposing build secrets, private signing material, or identity-bearing metadata. The proof is bound to the kernel hash, so it can’t be replayed, swapped, or repurposed. The result is passed forward so the kernel knows immediately whether it is operating in an attested environment. It doesn’t have to ask later. It doesn’t outsource trust.

Memory as a Boundary, Not a Convenience

NØNOS treats memory as a security boundary, not just a resource pool.

Physical regions are explicitly classified.

DMA buffers are bounded and validated.

Kernel text is mapped read-only.

User memory is isolated by design.

There is no allocator until one is built. There is no libc.

There is no ambient runtime assumed to be safe.

Drivers interact with hardware through minimal unsafe code, documented line-by-line with justification. Sensitive buffers are zeroized. Comparisons are constant-time where needed. DMA targets are constrained so devices cannot scribble into kernel text or critical regions. This isn’t a performance flex. It’s about knowing exactly where the system can be touched and where it cannot.

Statelessness changes the economics of exploitation

Hardware backdoors exist. Side channels exist. Absolute security doesn’t but exploitation becomes profitable when systems preserve identity, storage, and timelines across time. NØNOS reduces that profit window.

1) Power off means state collapse.

2) A memory scrape yields nothing durable.

3) A DMA capture dies with the session.

4) Forensics finds no disk, no logs, no default timeline.

NØNOS doesn’t claim to make attacks impossible. It aims to make long-term exploitation harder to operationalize and less rational to pursue.

Why NØNOS Fits Hostile-Network Computing

Blockchains, zero-knowledge systems and decentralized networks all start from the same assumption: the environment is hostile.

Keys leak.

Machines get compromised.

Infrastructure can’t be trusted.

Yet people still access these systems through operating systems that assume persistence, identity, and constant background activity. NØNOS closes that mismatch.

It doesn’t replace privacy tools; it gives them an environment that doesn’t quietly undermine them.

In my opinion;

. zero-knowledge proofs become more meaningful when the host leaks less context

. mix networks become harder to correlate when the OS avoids stable identifiers

. wallets operate without inheriting default telemetry paths

. nodes execute without leaving a persistent forensic trail by default

This isn’t branding alignment. It’s an architectural fit.

The role of NOX: An economic primitive, not a paywall

$NOX is not “pay to use the OS.”

It exists because stateless systems can’t rely on traditional identity structures accounts, subscriptions and long-lived profiles don’t work when the OS refuses to remember.

NOX is used where trust would otherwise require persistence:

1) verifying capsules and packages

2) attesting software provenance

3) rate-limiting privileged operations without accounts

4) coordinating stateless reputation across reboots

5) funding network and ecosystem services without identity

Instead of “log in,” the model becomes proof-based:

You don’t create an account.

You prove authorization, stake value, or burn capability then the system forgets you afterward.

NOX exists because NØNOS refuses to remember.

Open Source as a Constraint

NØNOS is open source by design not as marketing, but as a constraint on power. If a system cannot be inspected, reproduced, and verified, it cannot be trusted, no matter how impressive the credentials behind it.

Trust isn’t granted. It’s bounded.

Every subsystem is meant to be audited. Every assumption is meant to be challenged. Every design choice is meant to be questioned.

The Hard Path (On Purpose)

This path isn’t efficient.

Drivers are written instead of borrowed.

Subsystems are questioned instead of reused.

Design choices get filtered through one persistent test:

What does this cause the system to remember?

Who benefits from that memory?

What breaks if it disappears?

The system won’t be perfect. There will be bugs, rewrites and hard lessons but building a real kernel, real hardware drivers, real cryptographic enforcement and real stateless execution proves something practical: choosing the hard path now changes what becomes possible later. NØNOS is not a destination. It’s a starting position for systems that refuse silent compromise — for developers who don’t believe code should incriminate its authors, and for users who believe privacy is a right rather than a subscription tier. If you’re here to audit, challenge, improve, or build, you’re welcome. If you’re here for certainty or shortcuts, this isn’t that system.

NØNOS is an operating system built to forget.

That is the point.

HISTORY ACHIEVEMENT: First breath.

How We Are Creating a Post-Quantum, Privacy-First OS Written Entirely in Rust

The conventional wisdom in operating system security has failed us. Despite decades of incremental improvements, modern operating systems remain fundamentally vulnerable. Memory corruption exploits continue to dominate CVE databases. Access control systems designed in the 1970s struggle against sophisticated adversaries and with quantum computing advancing rapidly, the cryptographic foundations underpinning our digital infrastructure face obsolescence. NONOS represents our attempt to build something fundamentally different. Not an incremental improvement, but a complete reimagining of what an operating system can be when designed with mathematical proof systems at its core. This article documents the technical journey of building NØNOS, the challenges we encountered, the solutions we developed and what we learned along the way.

The Problem We Set Out to Solve

Traditional operating systems operate on implicit trust. When a process requests memory, the kernel trusts it needs that memory. When a user authenticates, the system trusts they are who they claim. When code executes, the CPU trusts the instructions are legitimate. This trust model made sense when computers were isolated machines operated by trusted individuals. It makes no sense in a world of networked systems, remote attacks and adversaries with nation-state resources. The numbers tell the story. Microsoft reported that approximately seventy percent of their security vulnerabilities stem from memory safety issues. The Linux kernel, despite rigorous review processes, accumulates hundreds of CVEs annually. Buffer overflows, use-after-free bugs, and integer overflows continue to plague systems written in C and C++.

Meanwhile, quantum computing threatens to undermine the cryptographic assumptions protecting our communications. RSA and elliptic curve cryptography, the foundations of modern secure communication, will become vulnerable to sufficiently powerful quantum computers running Shor’s algorithm. We asked ourselves: what would an operating system look like if we assumed nothing could be trusted, if every operation required cryptographic proof, and if we prepared for quantum adversaries from day one?

Architecture: Zero Trust as a Design Principle

We implements what we call a zero-trust microkernel architecture. The term “zero trust” has become marketing jargon in the security industry, but we use it literally. Every operation in NØNOS requires cryptographic verification. No implicit trust exists between any components of the system. The kernel compiles to approximately 1.7 megabytes. (Previously 67KB) While this may seem larger than traditional microkernels, this single binary includes a complete. graphical desktop environment, TLS 1.3 networking stack, three-hop onion routing circuits, post-quantum cryptography primitives (ML-KEM-768, ML-DSA-65), a preemptive scheduler, PS/2 input drivers and a RAM-only encrypted filesystem. For comparison, a minimal Linux kernel typically starts at 5–10MB without any of these integrated features. The size reflects our design philosophy: a single, cohesive binary with no external dependencies rather than a tiny kernel that requires loading megabytes of external modules.

ls -lh target/x86_64-nonos/release/nonos_kernel && echo "---" && file target/x86_64-nonos/release/nonos_kernel)
  ⎿  -rwxr-xr-x@   1.7M Dec 13 15:23 target/x86_64-nonos/release/nonos_kernel                                      
     ---
     target/x86_64-nonos/release/nonos_kernel: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped

The kernel handles five fundamental operations: memory management, process scheduling, interrupt handling, capability token verification, and inter-process communication. Everything else, including device drivers, filesystems and network protocols, runs in user space with restricted privileges. This design means a bug in a device driver cannot compromise kernel memory. A vulnerability in the network stack cannot escalate to root access. Each component operates in isolation, communicating only through verified capability tokens.

The Capability System

Traditional Unix-style permissions divide the world into users and groups, granting broad access based on identity. NONOS replaces this with cryptographically signed capability tokens. A capability token is a signed assertion granting specific permissions for specific operations. When a process wants to read a file, it presents a token explicitly granting read access to that specific file. The kernel verifies the token’s cryptographic signature before permitting the operation. We defined thirty-two distinct capability types covering the full range of system operations. ProcessCreate allows spawning new processes. MemoryMap permits memory allocation. FileRead enables reading specific files. NetworkConnect allows establishing outbound network connections. Each capability includes temporal bounds, usage limits and delegation restrictions. The signature scheme uses Ed25519, providing one hundred twenty-eight bits of security with excellent performance characteristics. Verification requires only three hundred thousand CPU cycles on modern hardware. We batch verify when possible, reducing overhead for processes making many capability-checked calls. This approach enables fine-grained access control impossible with traditional permission systems. A web browser can receive capability tokens allowing network access and reading specific directories, but nothing else. If compromised, the browser cannot access the user’s documents, spawn background processes, or modify system files. The capability tokens it holds define its entire universe of permitted operations.

The Cryptographic Engine

Security architectures are only as strong as their cryptographic implementations. We built NØNOS cryptographic subsystem from the ground up, implementing both classical and post-quantum algorithms.

Classical Cryptography

For symmetric encryption, we implemented AES-256-GCM and ChaCha20-Poly1305. AES-GCM provides hardware-accelerated performance on processors with AES-NI instructions. ChaCha20-Poly1305 offers consistent performance across all hardware and resistance to timing attacks without specialized instructions. For digital signatures, we chose Ed25519. The algorithm provides excellent security margins with fast verification, critical for a capability system verifying signatures on every privileged operation. Our implementation uses the ref10 reference code, carefully audited for constant-time operation to prevent timing side-channel attacks. For hashing, we implemented BLAKE3. The algorithm provides exceptional performance, hashing data at rates exceeding several gigabytes per second on modern processors, while maintaining strong security properties. We use BLAKE3 for integrity verification, key derivation, and content addressing throughout the system.

Post-Quantum Cryptography

Classical cryptography will not survive the quantum era. We integrated post-quantum algorithms from the beginning rather than treating them as a future upgrade. For key encapsulation, we implemented ML-KEM-768, the NIST-standardized successor to Kyber. The algorithm provides security against both classical and quantum adversaries, with key sizes and performance practical for real-world use. Public keys require 1,184 bytes, secret keys require 2,400 bytes, and the encapsulated shared secret provides 256 bits of security. For digital signatures, we integrated ML-DSA, the Dilithium-based standard. Post-quantum signatures are larger than classical alternatives, but the security guarantees justify the overhead for high-value operations like software signing and root capability token generation.

Hardware Integration

Modern processors include hardware acceleration for cryptographic operations. We integrated support for AES-NI instructions, providing three to five times speedup for AES operations. SHA extensions accelerate SHA-256 computation by similar factors. For entropy collection, we utilize RDRAND and RDSEED instructions when available, falling back to TSC-based entropy collection on systems lacking hardware random number generation. The kernel’s ChaCha20-based CSPRNG accepts entropy from multiple sources, mixing hardware randomness with timing jitter and interrupt patterns.

The Zero-Knowledge Proof System Ø

Perhaps our most ambitious technical achievement is the integration of zero-knowledge proofs into the kernel’s trust model. This is, to our knowledge;

The first operating system to use zk-SNARKs as a core security mechanism.

Zero-knowledge proofs allow one party to prove knowledge of information without revealing the information itself. In NONOS, this enables a profound shift in how we think about software attestation. Traditional code signing proves that code came from a specific developer. Zero-knowledge attestation proves that code has specific properties without revealing the code itself. A process can prove it performs only permitted operations, handles data according to policy, and maintains required invariants, all without exposing its implementation details. We implemented Groth16 proofs over the BLS12–381 curve. The choice reflects practical tradeoffs. Groth16 requires a trusted setup ceremony, but produces the smallest proofs and fastest verification times. For an operating system kernel where verification occurs frequently, verification speed matters enormously.

The mathematical foundation relies on bilinear pairings. Given proof elements A, B, and C, verification checks that e(A, equals the product of e(alpha, . beta), e(vk_x, gamma), and e(C, delta). This equation holds if and only if the prover knows a valid witness satisfying the circuit constraints. Our implementation handles constraint systems with up to one million gates, sufficient for meaningful computational proofs. Proof generation runs in time proportional to n log n where n is the constraint count. Verification runs in constant time regardless of circuit complexity, taking approximately two to three milliseconds on current hardware. The ZeroState runtime uses these proofs for behavioral attestation. When a capsule, our term for application containers, executes, it can generate proofs about its behavior that the kernel verifies. This creates accountability without surveillance. The system knows applications behave correctly without monitoring what they actually do.

The Boot Process: Seven Phases of Verification

NONOS boots through a seven-phase sequence, each phase establishing trust for the next. The bootloader itself comprises over thirteen thousand lines of Rust, implementing a sophisticated verification chain. Phase zero loads and validates the boot configuration. Configuration files are Ed25519 signed, preventing tampering even if an attacker gains access to the boot media.

> Phase one initializes the security subsystem. The bootloader queries UEFI Secure Boot status, initializes TPM communication if available, and collects initial entropy from hardware sources.

> Phase two performs hardware discovery. The bootloader enumerates CPU security features including SMEP, SMAP, and CET. It maps physical memory, identifies NUMA topology, and detects hardware cryptographic acceleration.

> Phase three initializes network capabilities for environments supporting network boot. This includes DHCP, PXE, and HTTP boot protocols, each with appropriate security validation.

> Phase four configures graphics and memory. The bootloader queries UEFI Graphics Output Protocol, establishes framebuffer access, and constructs initial page tables.

> Phase five loads and verifies the kernel. The bootloader reads the kernel binary, computes its BLAKE3 hash, and verifies its Ed25519 signature against embedded keys. Verification failure halts the boot process.

> Phase six performs the critical handoff from UEFI to kernel control. This involves exiting UEFI Boot Services, transferring the memory map, and jumping to the kernel entry point with interrupts disabled.

> Phase seven, zK circuits embedded to the bootloader.

The entire sequence produces detailed output visible during boot, showing each verification step and its result. Users can observe the chain of trust establishing itself in real time.

Memory Management: Safety without garbage collection

Operating system kernels cannot rely on garbage collection. The unpredictable latency of collection pauses is unacceptable for interrupt handlers and real-time scheduling. Yet manual memory management in C has proven catastrophically error-prone. Rust’s ownership system provides the solution. The compiler statically verifies that memory is freed exactly once, that references do not outlive their referents, and that mutable state is never aliased. These guarantees eliminate entire categories of vulnerabilities at compile time rather than runtime. Our physical memory allocator combines multiple strategies. A bitmap allocator handles single-page requests with O(1) average complexity. A buddy system allocator handles larger allocations, coalescing adjacent free blocks to prevent fragmentation. Large page support reduces TLB pressure for memory-intensive workloads. For virtual memory, the kernel uses hierarchical page tables with four levels of indirection, standard for x86–64. We maintain separate address spaces for each process, with the kernel mapped into the upper half of every address space. Context switches update the page table base register without remapping kernel memory. Guard pages surround all kernel stacks, immediately detecting stack overflows rather than allowing silent corruption. Copy-on-write sharing reduces memory consumption for forked processes. The kernel supports ASLR, randomizing code and data locations to complicate exploitation of any remaining vulnerabilities. NUMA awareness matters for systems with non-uniform memory access patterns. The allocator preferentially allocates from memory local to the requesting CPU, falling back to remote nodes only when local memory is depleted or when allocation patterns suggest better performance from cross-node access.

Hardware Drivers: Isolation through architecture

Device drivers represent a significant vulnerability surface in traditional operating systems. They run in kernel space with full privileges, yet they interface with complex hardware through protocols prone to implementation errors. A bug in a USB driver should not compromise filesystem integrity. NONOS runs most device drivers in user space. Drivers receive capability tokens granting access to specific memory-mapped I/O regions and interrupt vectors. They communicate with the kernel through message passing, never through shared memory or function calls. This architecture sacrifices some performance for security. A context switch is required for each driver interaction. But the isolation benefits are substantial. A compromised driver cannot access memory outside its assigned regions. It cannot intercept interrupts from other devices. It cannot modify kernel data structures. For performance-critical paths, we implemented a small set of kernel-space drivers. The AHCI driver handles SATA devices with Native Command Queuing support. The NVMe driver supports modern solid-state storage with multi-queue parallelism. The VirtIO drivers enable efficient operation in virtualized environments. The network stack deserves particular mention. We integrated smoltcp, a Rust TCP/IP implementation, providing full TCP and UDP support without the complexity of porting a C network stack. VirtIO network drivers enable efficient packet transmission in virtual machines. The architecture supports future integration of anonymous networking through onion routing. During development, we implemented a complete ACPI MADT parsing system to properly initialize the IOAPIC for interrupt routing. This required parsing the ACPI tables provided by firmware, extracting IOAPIC addresses and interrupt source overrides, and configuring the interrupt routing hardware. Without proper IOAPIC configuration, hardware interrupts for keyboard, mouse and network devices would not function.

The Graphical Desktop: Privacy at the Interface

NONOS includes a graphical desktop environment. The system boots to a functional GUI with a terminal emulator, dock, and application launcher. The graphics subsystem initializes through UEFI Graphics Output Protocol, obtaining framebuffer access before exiting boot services. The kernel maintains a simple framebuffer driver, with actual rendering performed by user-space composition. We implemented PS/2 keyboard and mouse drivers with interrupt-driven input handling. Mouse movement tracking required careful synchronization to prevent race conditions between interrupt handlers and user-space readers. We encountered and resolved a crash caused by unsynchronized access to mouse packet buffers, replacing unsafe static mutables with properly synchronized atomic operations. The terminal provides access to over one hundred sixty shell commands, from basic utilities like ls and cat to system administration tools and cryptographic operations. Users can generate Ed25519 keys, hash files with BLAKE3 and inspect capability tokens directly from the command line.

Challenges and Solutions

Building an operating system surfaces problems rarely encountered in application development. We documented several significant challenges and their resolutions.

The PXE Boot Hang

Early in development, boots would occasionally hang during network initialization. Investigation revealed the bootloader was attempting DHCP discovery even when network boot was unnecessary. On some firmware implementations, failed DHCP requests blocked indefinitely.

The solution involved restructuring network initialization to be purely optional and implementing proper timeouts for all network operations. Boot now completes reliably regardless of network availability.

The RNG Initialization Hang

On certain QEMU configurations, the kernel would hang during random number generator initialization. The cause was attempting to use RDRAND instructions on virtualized CPUs that did not properly emulate hardware random number generation.

We implemented a fallback path using TSC-based entropy collection when RDRAND fails. The bootloader now probes for hardware RNG availability and passes this information to the kernel, allowing appropriate initialization strategy selection.

The Mouse Driver Race Condition

Moving the mouse would occasionally crash the kernel. Analysis revealed a race condition in the PS/2 mouse driver. The interrupt handler and polling code accessed shared packet buffers without synchronization.

The fix involved wrapping packet buffers in a mutex and using atomic operations for the packet cycle counter. The mouse driver now operates correctly under all conditions.

ZK Pairing Verification

The zero-knowledge proof verifier contained placeholder code from architecture code, that would accept any proof. Implementing proper verification required careful implementation of bilinear pairings over BLS12–381, including proper handling of the ate pairing computation and final exponentiation.

SMM Hash Verification

The System Management Mode security module contained incomplete integrity verification. We implemented proper SHA-256 hash comparison with constant-time operations to prevent timing attacks, along with handler location validation ensuring SMM handlers reside within proper memory regions.

Development Statistics

The NONOS codebase comprises substantial engineering effort. The kernel alone contains over 80 thousand lines of Rust across approximately 267 forty files. Including the bootloader, tools, and supporting infrastructure, the total exceeds three hundred thousand lines.

We identified 950 unsafe blocks throughout the codebase, each manually audited and documented. Rust’s unsafe keyword marks code where the compiler cannot verify safety, requiring human review. The relatively small count for a kernel indicates our success in pushing dangerous operations to minimal, well-reviewed code sections. Build output totals approximately 1.7 megabytes for the kernel binary, remarkably compact for a system with a full graphical interface, post-quantum cryptography, onion routing, and 170+ shell commands. The size reflects careful dependency management and Rust’s aggressive dead code elimination during linking. The project uses Rust’s nightly compiler for access to unstable features required for bare-metal development. Custom target specifications define the x86–64 ABI without operating system assumptions. Build configurations enable link-time optimization across the entire kernel, producing optimal code at the cost of longer compile times.

Current Status and Future Direction

NONOS currently boots to a graphical desktop, accepts keyboard and mouse input, and provides a functional shell environment. The cryptographic subsystems are production-ready, implementing all specified algorithms with proper security properties. Work continues on several fronts. The network stack requires completion of higher-level protocols. The process scheduler needs refinement for real-time workloads. The capability system requires complete enforcement throughout all kernel paths.

Longer-term goals include full Tor/Anyone/Nym integration for anonymous networking, distributed consensus protocols for multi-node deployments, and formal verification of critical kernel components.

Extras by eK:

Rust’s safety guarantees are transformative for systems programming. The time spent fighting the borrow checker pays dividends in bugs that never occur. We encountered no memory corruption issues throughout development, a stark contrast to typical kernel development experiences. Microkernel architecture provides security benefits but requires careful performance optimization. Message passing overhead accumulates quickly. Batching operations and minimizing context switches proved essential for acceptable performance. Cryptographic implementation is harder than it appears. Side-channel resistance requires constant-time algorithms throughout, not just in obvious locations. We learned to distrust any code path where timing depends on secret data. Hardware compatibility remains challenging. Documentation is often incomplete or inaccurate. Features work differently across vendors. Extensive testing on real hardware is irreplaceable.

Conclusion

NONOS represents our attempt to build an operating system worthy of the threat environment we actually face. Not incremental improvements to decades-old designs, but fundamental rethinking of what operating systems can provide. The project demonstrates that zero-trust security is achievable in practice. Capability-based access control can replace the permission models of the past. Post-quantum cryptography can be integrated today rather than deferred until quantum computers arrive. Memory safety can be enforced at compile time, eliminating vulnerability classes that have plagued systems programming for fifty years.

We do not claim perfection. Substantial work remains. But NONOS proves that a different approach is possible. Operating systems can be built on mathematical proof rather than implicit trust. Security can be an architectural property rather than an afterthought. The source code commits updates will eventually be released starting tonight, AGPL-3.0 licensing. We believe secure infrastructure should be publicly auditable and verifiable. Security through obscurity has failed. It is time for security through transparency.

This article documents work in progress. NØNOS is under active development. Technical details may change as the project evolves.

Watch the moment the OS came to life for first time:

https://youtu.be/3Ry_MZIF1X0?si=4wEjuB_5EBwiEjmi

The modern web has fundamentally transformed how we interact with software. Yet terminal access, one of computing’s most powerful interfaces, remains largely tethered to local machines or persistent remote servers that accumulate history, state and potential vulnerabilities. Noxterm represents a departure from this paradigm by providing fully isolated, ephemeral terminal environments that exist only for the duration of a session and leave no trace upon disconnection.

The Problem with Traditional Terminal Access

When developers, system administrators, or security researchers require terminal access, they typically face a limited set of options. Local terminals expose the host operating system to potentially destructive commands. Traditional SSH access to remote servers creates persistent environments where command history, temporary files, and session artifacts accumulate over time. Cloud-based development environments, while convenient, often retain user data and lack true isolation between sessions. These approaches share a common architectural assumption: that terminal state should persist. This assumption creates several challenges. Security-conscious users must manually sanitize their environments. Shared systems accumulate technical debt from previous sessions. Educational contexts struggle to provide students with clean, reproducible environments. Privacy-focused users have limited options for executing commands without creating permanent records.

Architectural Foundation

Noxterm addresses these challenges through a containerized architecture that treats ephemeral execution as a first-class design principle rather than an afterthought. The system comprises three primary components working in concert to deliver isolated terminal sessions through a standard web browser. The backend is implemented in Rust using the Axum web framework running on the Tokio asynchronous runtime. This technology choice provides memory safety guarantees critical for a security-focused application while delivering the performance characteristics necessary for real-time terminal interaction. The backend manages session lifecycle, communicates with the Docker daemon through the Bollard client library, and maintains WebSocket connections for bidirectional terminal input and output.

The frontend is built with React and TypeScript, utilizing xterm.js for terminal emulation. Xterm.js provides accurate VT100 and xterm escape sequence handling, enabling support for interactive applications including text editors, process managers, and other programs that rely on terminal control sequences. The frontend maintains persistent WebSocket connections to the backend, transmitting user input and rendering terminal output with minimal latency. Container orchestration occurs through direct Docker API integration. When a user initiates a session, the backend provisions a fresh container from one of several supported base images including Ubuntu, Debian, Alpine Linux, CentOS, and specialized development environments for Node.js, Python, and Rust. Each container operates under strict resource constraints including memory limits of 1024 megabytes, CPU throttling and process ID limitations to prevent fork bombs and runaway processes.

Security Model

Security in Noxterm operates at multiple layers, implementing defense in depth principles throughout the stack. At the input validation layer, the system analyzes incoming commands against a comprehensive set of patterns designed to identify and block potentially dangerous operations. These patterns detect attempts at recursive filesystem deletion, fork bombs, reverse shell establishment, container escape techniques and privilege escalation attempts. The validation logic categorizes threats by severity and logs security events for audit purposes while preventing execution of flagged commands. Container isolation provides the primary security boundary. Each session operates within its own container namespace, with separate process trees, filesystem mounts and network stacks. Containers run with the no-new-privileges flag, preventing processes from gaining additional capabilities through setuid binaries or similar mechanisms. The Docker daemon itself operates with user namespace remapping enabled, adding an additional layer of isolation between container processes and the host system. Network security is implemented through configurable bridge networking that isolates container traffic while permitting controlled internet access for package installation and legitimate network operations. Rate limiting at both the application and infrastructure levels prevents abuse through rapid request flooding or resource exhaustion attacks. The audit subsystem maintains detailed logs of session creation, command execution when enabled, security events, and system access patterns. These logs facilitate incident investigation and compliance requirements while respecting user privacy through configurable retention policies.

Session Lifecycle Management

Unlike traditional terminal services that maintain indefinite connections, Noxterm implements a sophisticated session lifecycle system designed around the principle of eventual termination. Session creation begins when a user connects and selects a container image. The backend provisions a new container, establishes a pseudo-terminal within that container, and bridges the PTY to the user’s WebSocket connection. This process typically completes within seconds, providing users with a fully functional terminal environment. During active use, the session maintains bidirectional communication through the WebSocket connection. The PTY layer handles terminal control sequences, enabling full support for interactive applications, line editing, and terminal-based user interfaces. Container metrics including CPU utilization, memory consumption and network activity are collected periodically for monitoring and resource management.

Disconnection triggers a grace period rather than immediate termination. This design accommodates temporary network interruptions and browser refreshes without destroying active work. The default grace period of five minutes allows users to reconnect and resume their session. Users may also explicitly reconnect to disconnected sessions through the API. Upon grace period expiration or explicit termination, the system destroys the container and all associated state. The filesystem, process table, network configuration and any data created during the session cease to exist. No command history persists. No temporary files remain. The environment returns to a pristine state, ready for the next session to begin with identical initial conditions.

Privacy Through Architecture

Privacy in Noxterm extends beyond policy statements to architectural decisions that make data retention technically infeasible for terminated sessions. The ephemeral container model ensures that session data exists only in volatile storage during active use. When a container terminates, the Docker daemon removes all associated filesystem layers. Unlike traditional logging approaches that require active deletion, Noxterm’s default state is zero retention. For users requiring additional network-level privacy, Noxterm integrates with the Anyone Protocol, a decentralized network providing SOCKS5 proxy capabilities. When privacy mode is enabled, container network traffic routes through the Anyone network, obscuring the origin of requests from destination servers. This integration operates transparently to applications running within the container, requiring no configuration changes to benefit from network-level anonymity.

The optional nature of command logging represents another privacy-by-design decision. The system supports command history recording for users who desire it, but this functionality is disabled by default. Users explicitly opt into logging rather than opting out, ensuring that the default experience maximizes privacy.

Technical Implementation Details

The WebSocket implementation deserves particular attention given its role in delivering responsive terminal interaction. The system uses a binary protocol for efficiency, transmitting raw terminal data without JSON encoding overhead. Connection management includes automatic reconnection logic with exponential backoff, ensuring resilience against temporary network disruptions. PTY handling in the backend involves careful management of terminal dimensions, signal propagation, and process group associations. When users resize their browser window, the frontend transmits updated dimensions through the WebSocket connection and the backend issues the appropriate ioctl call to resize the PTY. This enables proper behavior for applications that query terminal dimensions or respond to SIGWINCH signals. Database integration through PostgreSQL with the SQLx library provides persistent storage for session metadata, audit logs, and system configuration. The schema includes tables for session tracking, security events, container metrics, and rate limiting state. Cleanup functions run periodically to remove expired data and prevent unbounded storage growth. The frontend build process uses Vite for development and production bundling, producing optimized assets with content hashing for effective caching. Production deployment serves the frontend through Nginx, which handles static asset delivery with appropriate cache headers while proxying API and WebSocket connections to the Rust backend.

Operational Considerations

Deploying Noxterm at scale requires attention to several operational factors. Container image management becomes significant as the number of supported environments grows. The system pre-pulls configured images to minimize session startup latency, but this requires adequate storage and periodic updates to maintain security patches in base images. Resource allocation must balance user experience against infrastructure costs. Memory limits that are too restrictive prevent users from running memory-intensive operations, while overly generous limits reduce the number of concurrent sessions a host can support. The default configuration of 1024 megabytes per container represents a reasonable compromise for general-purpose terminal use. Monitoring integration through Prometheus-compatible metrics enables operators to track system health, identify capacity constraints, and detect anomalous behavior. Key metrics include container count, WebSocket connection count, API request rates, and resource utilization across active containers.

Applications and Use Cases

The ephemeral terminal model enables several use cases that traditional approaches serve poorly. Educational environments benefit from guaranteed clean state between student sessions. Instructors can provide exercises knowing that each student begins with identical conditions, eliminating variables introduced by accumulated state from previous work. Students can experiment freely knowing that errors cannot permanently damage their environment.

Security research and malware analysis gain isolation guarantees that protect the researcher’s primary system. Suspicious scripts can execute in a contained environment that terminates completely upon session end, leaving no persistent artifacts that could compromise the host.

Development and testing workflows benefit from reproducible environments that match production configurations. Developers can test installation procedures, verify dependency requirements, and debug environment-specific issues without polluting their local systems.

Privacy-conscious users gain a terminal environment that leaves no local traces and, when combined with the Anyone Protocol integration, minimizes network-level tracking as well.

Looking Forward

Noxterm launches next week at noxterm.com, beginning with the first phase of public availability. This initial release provides the core terminal functionality described throughout this article, including multiple container image options, session persistence across brief disconnections, and optional privacy mode integration. Subsequent phases will introduce additional capabilities based on user feedback and operational experience. Planned enhancements include file transfer functionality for moving data into and out of containers, session sharing for collaborative terminal use, and expanded container image options for specialized development environments. The fundamental architecture supports these extensions while maintaining the core principle of ephemeral, isolated execution. Each enhancement will preserve the security model and privacy guarantees that define the platform.

Conclusion

Noxterm represents a considered approach to terminal access that prioritizes isolation, privacy and reproducibility. By treating ephemeral execution as an architectural foundation rather than an optional feature, the platform delivers guarantees that traditional terminal services cannot match. The technical implementation combines proven technologies including Rust, Docker, and WebSocket communication in a configuration optimized for secure, responsive terminal interaction. Multiple security layers protect both users and infrastructure while the privacy-by-design approach ensures that default behavior maximizes user confidentiality. As computing continues to migrate toward web-based interfaces, terminal access need not remain an exception. Noxterm demonstrates that browser-based terminals can match or exceed the functionality of traditional approaches while providing security and privacy properties previously unavailable in this domain.

Youtube: https://youtube.com/@nonos.systems?si=OWRJIcjSN2FZAdto

X: https://x.com/nonossystems?s=21

A tutorial: https://x.com/eknonos/status/1999242071509753891?s=46

To our community, contributors, and supporters as we move forward with NØNOS, it’s important to reaffirm what this project represents and why we are building it in the way we are.

This isn’t a short-term venture or an attempt to capture hype. It’s a deliberate, structured journey toward something far more fundamental: creating a system that can prove its integrity from the moment it boots. NØNOS is not just an operating system; it’s a redefinition of how computing trust should work, built entirely from scratch, with no inherited assumptions from legacy software. Every part of it from the bootloader to the kernel is being engineered to enforce verifiability, cryptographic proof and zero-state execution.

Privacy today is mostly treated as a layer that can be added later, an optional setting or a toggle in an interface. But that’s not what privacy really means. True privacy starts at the system level at the point where execution begins. It’s not about hiding; it’s about ensuring that nothing in the stack can misrepresent, retain, or leak what the user does not intend to share. Privacy is not resistance. its restoration. It’s the process of rebuilding the right to compute without fear, to communicate without exposure, to exist digitally without surveillance or dependency.

That philosophy drives every decision we make, and it’s why we take our time. The architecture of NØNOS demands precision and proof, not speed. The focus remains entirely on building a verifiable foundation, and the progress in recent weeks shows that this vision is maturing technically. The UEFI bootloader is now capable of verified kernel handoff under QEMU, integrating attestation through TPM measurements and cryptographic validation through Groth16 and Ed25519 schemes. The work has transitioned from theory to execution from design to proof and that’s the difference between announcements and engineering.

The NOXORIUS privacy engine, which continues to evolve alongside the kernel, has now reached a significant point of stability. It integrates a universal session cleanup system that automatically identifies, tracks, and securely removes session artifacts across any application type, a practical answer to a real-world privacy failure that exists in every operating system today. It also issues cryptographic receipts that prove the privacy policy was enforced, bridging the gap between operating policy and measurable security. NOXORIUS will be the first complete subsystem to reach production readiness and will form the backbone for how user applications interact with NØNOS.

We often describe the system as something that grows, a living structure that gains autonomy piece by piece. Every subsystem, the bootloader, kernel, crypto-provider, TUI and later userland. adds to a chain of verifiable components that work together to form a zero-trust, zero-state environment. This is not a project that can or should move fast; it must move precisely, because at the foundation level of trust, there is no room for error.

To clarify for those following development closely: the Kernel Management Interface (KMI) is under active construction and is not yet released. It represents the user’s first direct interaction with the kernel’s cryptographic modules and its completion will mark a major milestone toward system usability. If there isn’t an official release announcement, it means it’s still being built this is how we operate: transparency before publicity.

Development continues to progress through planned milestones. The immediate focus is the completion of Bootloader v0.1, followed by kernel hardening and the implementation of the first integrated network stack. Once this foundation is fully verified, we will transition to userland development, introducing the first graphical, terminal, and command interfaces (GUI, TUI, CLI).

Every layer builds upon the last, ensuring that each component is deterministic, auditable, and isolated.

The $NOX supply remains fully aligned with this long-term mission.

65% of the total supply has been permanently burned, representing liquidity that can never re-enter the market. (LIQUIDITY NOT TOKENS)

25% remains locked for ten years to secure development continuity and ecosystem alignment.

The remaining portion supports operations and technical growth there are no hidden reserves, no liquidity games, no exits. This structure reflects what we believe: that trust must be demonstrable, not declarative.

We want our community to know that we are here, working continuously, responding to questions, and building transparently. This project was never about speculation, it’s about engineering a foundation for digital autonomy. Every verified component we complete brings us closer to that goal.

As we move forward, remember why this exists. In a world that rewards exposure, we are building for protection. In a culture that values attention, we are building for silence and in an industry that celebrates convenience, we are building for correctness.

“Freedom begins when systems forget who you are.” This isn’t a slogan; it’s a principle that defines every line of code we write.

The mission remains simple and absolute, to give users back control over their computing environment. Not through abstraction, not through promises, but through provable architecture. We are still early, but we are steady and the foundation being built now will be the one that defines the next decade of verifiable, trustless computing.

— The NØNOS Development Team

This document details the build, structure and verification of the NØNOS microkernel ELF artifact produced by the x86_64-nonos target profile. Running the command:

$NONOS_SIGNING_KEY=/home/nonos/nonos-kernel/.keys/signing.seed cargo build --release --target x86_64-nonos.json -Zbuild-std=core,alloc

The goal of this kernel series is auditable, deterministic, security-first execution then a capsuled-based boot, capability enforcement and reproducible ELF layouts designed for formal loader validation. All data shown below is from the release build:

target/x86_64-nonos/release/nonos_kernel

ELF Header . Baseline Verification

$ readelf -h target/x86_64-nonos/release/nonos_kernel
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 ...
  Class:                             ELF64
  Data:                              2's complement, little endian
  OS/ABI:                            UNIX - System V
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x100010
  Start of program headers:          64 (bytes into file)
  Start of section headers:          71424 (bytes into file)
  Number of program headers:         5
  Number of section headers:         7

Interpretation analysis follows as:

• Class: ELF64 and Type: EXEC designate a statically linked, 64-bit long-mode image with fixed addressing.
• Entry point: 0x100010 is the precise instruction address at which the firmware/loader must transfer control.
• The ELF header begins at byte 0; the program header table begins at byte 64 and describes five segments.
• The section table begins at offset 0x11700, containing seven section entries.

This format is intentionally minimal: no interpreter, no relocation records, no dynamic tags, fully static, suitable for early firmware execution.

Program Header Table. Segment Layout.

$ readelf -W -l target/x86_64-nonos/release/nonos_kernel

Elf file type is EXEC (Executable file)
Entry point 0x100010
There are 5 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  LOAD           0x001000 0x0000000000100000 0x0000000000100000 0x00000c 0x00000c R   0x1000
  LOAD           0x001010 0x0000000000100010 0x0000000000100010 0x000675 0x000675 R E 0x1000
  LOAD           0x001690 0x0000000000100690 0x0000000000100690 0x00003d 0x00003d R   0x1000
  LOAD           0x0016cd 0x00000000001006cd 0x00000000001006cd 0x010000 0x010000 RW  0x1000
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0

Segment-to-section mapping:

00 → .multiboot
01 → .text
02 → .rodata
03 → .bss .stack

Observations

• Every PT_LOAD is page-aligned (Align = 0x1000).

The contiguous physical range spans from 0x0010_0000 through 0x0016_cd + 0x010000 ≈ 0x0026_CD.

The kernel fits cleanly within a 17-page contiguous region.

• The largest segment (.bss + .stack) reserves 0x010000 (64 KiB) RW memory for runtime stack and uninitialized data.

The GNU_STACK segment enforces a non-executable stack (Flags: RW). This is a deliberate NX policy embedded into the ELF metadata.

Each segment follows a classic kernel structure:

| Segment | File Offset | Virtual Address | Flags | Role |
|---------|-------------:|----------------:|:------|:-----|
| #0      | 0x001000     | 0x0010_0000     | R     | Multiboot header |
| #1      | 0x001010     | 0x0010_0010     | R E   | .text — executable code |
| #2      | 0x001690     | 0x0010_0690     | R     | .rodata — const data |
| #3      | 0x0016CD     | 0x0010_06CD     | R W   | .bss + .stack — runtime state |
| #4      | —            | —               | R W   | GNU_STACK (metadata only) |

These descriptors are the authoritative loader contract.

Section Table. Fine-Grained Structure.

$ readelf -S target/x86_64-nonos/release/nonos_kernel
There are 7 section headers, starting at offset 0x11700:

[ 1] .multiboot  PROGBITS  0x100000  Off 0x001000  Sz 0x00000c  Flags A
[ 2] .text       PROGBITS  0x100010  Off 0x001010  Sz 0x000675  Flags AX
[ 3] .rodata     PROGBITS  0x100690  Off 0x001690  Sz 0x00003d  Flags AM
[ 4] .bss        NOBITS    0x1006cd  Off 0x0016cd  Sz 0x000000  Flags WA
[ 5] .stack      PROGBITS  0x1006cd  Off 0x0016cd  Sz 0x010000  Flags WA
[ 6] .shstrtab   STRTAB    0x000000  Off 0x0116cd  Sz 0x000030

Technical summary:

.multiboot, aligned to 0x100000; 12 B header recognized by multiboot-compliant stubs and UEFI parser.

.text RX, 1653 B of kernel code; entry point (0x100010) resides here.

.rodata read-only constants; AM flags = alloc + merge.

.bss NOBITS, write-alloc; zeroed by loader.

.stack pre-allocated 64 KiB contiguous region following .bss; reserved for the primary bootstrap stack.

The ELF presents perfect section-to-segment congruence. Each .text / .rodata / .bss / .stack falls inside a PT_LOAD of matching permissions essential for W^X enforcement in virtual memory.

Loader Responsibilities. Deterministic Algorithm.

Our nonos-boot loader is responsible for transforming this static ELF into live memory mappings during firmware boot (UEFI phase). We enforce a heap-less, deterministic allocation model using fixed-sized page tables and compile-time static arrays.

Loader procedure (simplified):

1. Parse ELF header and validate magic, class (ELF64), machine (EM_X86_64), type (ET_EXEC/ET_DYN).

2. Enumerate PT_LOAD segments. For each:

• base_page = align_down(p_vaddr, 0x1000)

• offset = p_vaddr — base_page

• end = offset + p_memsz

• pages = align_up(end, 0x1000) / 0x1000

3. Allocate pages from UEFI Boot Services.

• R segments -> allocate as read-only.

• RX segments -> allocate executable.

• RW segments -> allocate writable, non-executable.

4. Copy file-backed data:

• memcpy(dst, file + p_offset, p_filesz)

• memset(dst + p_filesz, 0, p_memsz, p_filesz)for .bss

5. Record mapping table into a fixed in-stack structure (LoadTableEntry[4]), no heap.

6. ExitBootServices only after all allocations are stable.

7. Prepare BootInfo: memory map snapshot, stack pointer, entry pointer = 0x100010.

8. Trampoline: Switch to long mode (if not already), disable paging identity map if required, and jmp e_entry.

Failure at any stage (invalid magic, misaligned segment, allocation failure, copy mismatch) = abort and return EFI_LOAD_ERROR. This procedure yields a fully deterministic, auditable boot path: same ELF, same page map, same entry context.

Target JSON. Architecture Contract.

We maintain this x86_64-nonos.json as the canonical target contract for every build that becomes a kernel artifact. The JSON is not an incidental file; it is a specification that the linker, the build pipeline, the loader and the runtime must obey. Every field has an engineering consequence. We list them below with what the loader and test harness must assert at runtime.

{
  "llvm-target": "x86_64-unknown-none",
  "arch": "x86_64",
  "vendor": "nonos",
  "os": "none",
  "env": "",
  "data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128",

  "target-endian": "little",
  "target-pointer-width": "64",
  "target-c-int-width": 32,
  "max-atomic-width": 64,

  "executables": true,
  "panic-strategy": "abort",
  "disable-redzone": true,

  "frame-pointer": "always",

  "cpu": "x86-64",
  "features": "-mmx,-sse3,-ssse3,-sse4.1,-sse4.2,-avx,-avx2",

  "linker-flavor": "ld.lld",
  "linker": "rust-lld",

  "pre-link-args": {
    "ld.lld": [
      "--script=linker.ld"
    ]
  },

  "relocation-model": "static",
  "code-model": "small",
  "position-independent-executables": false,
  "static-position-independent-executables": false,

  "no-default-libraries": true,
  "has-rpath": false,

  "stack-probes": { "kind": "inline" }
}

What this enforces (explicit):

• os: “none” / llvm-target: x86_64-unknown-none

The binary is not a userland ELF; we produce an image for firmware/bootloader execution. The standard library is excluded by default. The loader must treat the image as the OS.

• panic-strategy: “abort”

No unwinding frames. Panics are fatal and must not be relied on to unwind stacks or run destructors. The loader and any pre-kernel code must assume abort semantics and instrument any critical resource with explicit cleanup on failure paths.

• disable-redzone: true

The ABI contract forbids reliance on the 128B red zone below RSP. All interrupt handlers, NMI handlers, and early trampolines must either preserve or not depend on the red zone. The loader must set up stacks and never assume the red zone is available.

• frame-pointer: “always”

We keep frame pointers even under optimizations so postmortem stack walks are feasible on stripped binaries. CI must produce an unwind-map verification step that checks frame pointers are present. The kernel’s entry code must preserve a valid frame chain across trampoline transitions.

• relocation-model: “static” and position-independent-executables: false

Fixed virtual addresses are mandatory in this build profile. The loader must map the image to the addresses encoded in p_vaddr. There is no runtime relocator stage in this profile; if we support ET_DYN, that will be a separate build artifact and a distinct loader flow.

• code-model: “small”

Function pointers and symbol tables assume 32-bit relative addressing when possible; the code generator will produce smaller code sequences. We must use -Wl, script=linker.ld to precisely control symbol placement.

• linker: “rust-lld” + pre-link-args

We control placement via linker.ld. The loader and audit scripts assert that the linker script did not emit any unexpected segments or PT_DYNAMIC tags.

• stack-probes: { “kind”: “inline” }

Stack probes are inlined for stack-growth safety in certain circumstances. The kernel must ensure sufficient stack pre-allocation for early routines.

Loader runtime assertions (what loader.rs must check before mapping) We implement the following strict checks at the start of the loader run. Each check fails hard and returns a clear EFI_INVALID_PARAMETER / EFI_LOAD_ERROR.

• ELF magic and class: EI_MAG == 0x7F ELF, EI_CLASS == ELFCLASS64.
• e_machine == EM_X86_64.
• e_type == ET_EXEC (unless this build produces an ET_DYN artifact — separate pipeline).
• Program headers: p_align == 0x1000 for all PT_LOAD entries. If any p_align ≠ 0x1000 = reject the image.

Verify p_vaddr values fall into chosen kernel virtual region (e.g., 0x0000_0010_0000..0x0000_0011_ffff) as specified by linker.ld. If a p_vaddr lies outside expected bounds = reject.

• Confirm p_memsz >= p_filesz. If not, reject.

• Confirm there are no PT_DYNAMIC / DT_* tags in the executable. If present and we are in static profile = reject. These are non-negotiable: they make the boot path auditable and eliminate loader heuristics.

Exact page math we use (code we commit)

We implement and test the following routine in loader.rs. This is the authoritative copy we will use in CI and in our internal code review.

// Pseudocode (no_std friendly)
const PAGE: u64 = 0x1000;

fn align_down(addr: u64) -> u64 { addr & !(PAGE - 1) }
fn align_up(addr: u64) -> u64 { (addr + PAGE - 1) & !(PAGE - 1) }

struct LoadRange {
    base_page: u64,
    offset_into_page: u64,
    pages: usize,
}

fn compute_load_range(p_vaddr: u64, p_memsz: u64) -> LoadRange {
    let base = align_down(p_vaddr);
    let offset = p_vaddr - base;
    let end = offset + p_memsz;
    let pages = (align_up(end) / PAGE) as usize;
    LoadRange { base_page: base, offset_into_page: offset, pages }
}

Why we do this

base_page is the memory allocation anchor, we allocate at page granularity.

offset_into_page is where the file-backed bytes land inside the first physical page.

pages is how many pages the loader must request via UEFI AllocatePages before any copy occurs.

We maintain a LoadTableEntry array with fields { p_vaddr, p_offset, p_filesz, p_memsz, base_page, pages } populated during parsing and committed atomically to a small fixed region on the loader stack. We do not use heap allocation here.

Copy & zero semantics. For each PT_LOAD:

dst = (base_page) + offset_into_page

copy_len = p_filesz

zero_len = p_memsz — p_filesz

memcpy(dst, file_buffer + p_offset, copy_len)

if zero_len > 0 { memset(dst + copy_len, 0, zero_len) }

Edge cases

If p_filesz extends beyond file size = abort.

If dst + p_memsz overlaps previously mapped firmware-managed pages = abort.

If pages cannot be allocated contiguously then attempt to allocate a contiguous set in the same physical region; if impossible, abort. We prefer fail-fast to unpredictable relocation.

Permission enforcement

We set the memory attributes exactly as the PT_LOAD flags require:

PF_X. Tomap as executable (EFI_MEMORY_RUNTIME or equivalent attributes as allowed by firmware).

PF_W to writable and non-executable.

PF_R to readable.

We enforce GNU_STACK by marking stack pages RW and not executable. Additionally, the loader writes a small runtime validation step after mapping: walk the page table entries (if we built page tables) or call a small probe that verifies execute permission bits match the intended policy. If any mismatch = abort.

Conclusion. Determinism as a Design Discipline.

Every offset, flag, and build parameter in this kernel exists for one reason: reproducibility under inspection.

We design so that readelf, not marketing, defines the truth.

The ELF header, program headers, section layout, linker script, and target JSON together form an immutable contract between the compiler, the loader, and the firmware. Once those constraints are respected, the kernel becomes a predictable piece of software, not a probabilistic one.

We treat determinism as a security property.

If a kernel boots the same way twice with identical segment alignment, identical stack posture, and an identical entry instruction at 0x100010, we can reason about it, audit it, and prove its invariants. When the layout drifts, we lose the ability to make guarantees about safety or correctness. That’s why the entire NONOS toolchain enforces static relocation, no heap in early boot, and a deterministic build pipeline down to the linker invocation. Our position is that trust in system software doesn’t come from obscurity or complexity, it comes from visibility and mechanical proof.

Every feature gate we add (nonos-wx-audit, nonos-nx-stack, nonos-smap-smep, nonos-cet) is a deliberate attempt to make exploitation measurably harder while keeping the binary fully analyzable. By removing dynamic relocation and undefined behavior, the loader and the kernel can exist in a one-to-one verifiable relationship each knows exactly where the other stands.

This series of audits and engineering notes is not about aesthetics; it’s about having a build process you can swear by. You can open the binary in a hex editor, match every section by hand, and confirm that what executes is exactly what was linked.

That’s the bar.

That’s how we build NØNOS.

— The NONOS Systems Team

• Part I, The Problem

The Hidden Architecture of Power

Centralization Disguised as Convenience

The Cracks We See Today

• Part II, Why NØNOS Is Necessary

The poisoned soil of inherited systems

Why patching Linux, Qubes, and Tails is not enough

History’s lessons: GNU, Linux, Bitcoin

Sovereignty must begin at zero

• Part III, What We’re Building

The kernel as the ZeroState

Cryptography at the syscall level

A transparent, verifiable bootloader

Onion routing as a native network layer

Secure memory management and PQC integration

Redefining the soil of computation

• Part IV, Why It’s Hard

Complexity at the raw machine

The isolation of foundation work

Ecosystem challenges: compilers, drivers, communities

Human cost and disbelief

Difficulty as proof of necessity

• Part V, The Inevitability of Change

Every empire of computation falls

Mainframes → PCs, Proprietary → Free, Banks → Bitcoin

Research convergences: ZK proofs, PQC, verified kernels

Social inevitability: surveillance, capture, and resistance

The future cannot be built on compromised ground

• Part VI, A Call to Action

The moral choice of computation

Why open-source is the only path

Roadmap, hackathon, and contributions

Building systems that will last decades

The ZeroState is waiting

Part I, The Problem

The Hidden Architecture of Power

Most people imagine their operating systems to be neutral tools, silent enablers of computation. Yet neutrality is an illusion. Every system encodes an architecture of power, and in the operating systems that dominate our world today, power does not belong to the individual. Windows does not serve its users; it serves its vendor. It is built around telemetry, licenses, and updates outside the control of the person who purchased the machine. macOS presents itself as elegance and simplicity, but it is a closed garden, where Apple alone decides which applications may exist and under what conditions. iOS is even more severe, an ecosystem where the device you “own” can only run what the corporation approves. Android, despite its open-source core, remains tethered to Google services that dictate functionality. Even Linux, celebrated as the open alternative, depends on the governance of a narrow group of maintainers and is almost always distributed within proprietary supply chains. The truth is blunt: users today do not own their machines. They are granted temporary access, subject to the permissions of others. What we call “personal computing” is personal only in name.

Centralization disguised as convenience, mean this loss of sovereignty has not been sold as oppression. It has been sold as progress. The story of the last two decades of computing is the story of centralization disguised as convenience. Cloud computing promised infinite scalability. In practice, it delivered dependence on Amazon, Google, and Microsoft. A small group of companies now holds custody over most of the world’s data, deciding how it is stored, who can access it, and under what terms. Mobile platforms promised freedom through portability. What they delivered were app stores acting as gatekeepers of culture and commerce. If Apple or Google disapproves of an application, it disappears from the marketplace. A billion users are instantly cut off not by law, not by collective agreement, but by unilateral decision. Artificial intelligence now promises intelligence as a service, reasoning at your fingertips but this power is locked behind proprietary APIs. A handful of corporations train massive models on the open contributions of humanity, only to wall them off behind paywalls and permissions. The irony is staggering: the collective work of billions is transformed into closed systems serving only the few. Even within Web3, a space born from the dream of decentralization, the pattern repeats. Custodial wallets dominate adoption, RPC nodes run on centralized infrastructure, and most smart contracts execute atop operating systems that are hostile to privacy. What appears to be sovereignty is, too often, dependency dressed in new language. The pattern is always the same. What is sold as efficiency is in truth capture. What is framed as progress is in truth control. Once the architecture of computation is centralized, the individual is reduced to a tenant in a digital empire.

The Cracks We See Today…

The consequences of this capture are visible, and they grow sharper every year. Edward Snowden’s revelations showed how state agencies exploit operating systems and network infrastructure to monitor entire populations. The debate over Apple’s plan to implement client-side scanning revealed how quickly personal devices can be transformed into surveillance machines. Microsoft’s Secure Boot controversy showed how even the very act of starting a computer can be subordinated to centralized authority. Surveillance capitalism has made daily life itself into an extractive industry. Every action is recorded, categorized, and monetized. The individual becomes raw material for corporations that design systems not to empower, but to predict and manipulate. Artificial intelligence is deepening the asymmetry. The most powerful models are not released to the public. They are gated by companies that decide who may access them, under what terms, and at what price. The data to train them is taken from the open internet, but the models are closed. The risks disinformation, surveillance, automation of control are distributed across society, while the benefits are concentrated in boardrooms. Even in the Web3 ecosystem, decentralization too often collapses under scrutiny. Major “decentralized” applications depend on centralized infrastructure providers. Custodial exchanges still hold the majority of assets. Protocol governance is frequently controlled by small foundations, easily pressured or compromised. These are not hypothetical dangers. They are lived realities. They are symptoms of an architecture that has surrendered sovereignty at the deepest layer: the operating system itself. We are nearing a breaking point. The illusions cannot last. An ecosystem built on poisoned foundations cannot sustain freedom. What grows from this soil is not autonomy, but dependency. Not resilience, but fragility. Not liberty, but control. This is the condition we inherit. This is the problem NØNOS was created to confront.

Part II, Why NØNOS Is Necessary

The temptation to accept the world as it is has always been strong in computing. Most people do not build from scratch; they inherit, they adapt, they patch, and they compromise. It is easier to stand on the shoulders of giants than to break new ground. Yet this is precisely why so few systems ever escape the gravitational pull of centralization. Most “decentralized” projects are not truly decentralized at all. They exist as layers placed delicately on top of operating systems that were designed from birth to serve institutions, not individuals. A blockchain may be immutable, a smart contract may be transparent, a wallet may be secure in design but if all of these run on an OS that is itself compromised, their sovereignty is an illusion. The foundation does not belong to the user, and so neither does the system. This is the essential problem: the operating system is the deepest layer of trust. It is the soil from which all digital life grows. To build freedom on poisoned soil is to plant seeds in sand. No matter how clever the application, no matter how brilliant the protocol, it remains hostage to the operating system beneath it. If the kernel is compromised, everything above it is compromised too. This is why NØNOS must exist. It does not attempt to patch old systems or retrofit decentralization into architectures designed for control. It does not imagine that simply bolting on cryptographic libraries to Linux or building privacy tools on top of Windows will solve the problem. It does not seek to harden fragments of a poisoned soil. NØNOS begins at zero. It is a ZeroState Operating System, a system where sovereignty is not a feature but an axiom. Building an operating system from scratch is one of the most difficult tasks in all of technology. It is not like writing an application, which can depend on the OS for memory, process scheduling, networking, and security. It is not like launching a blockchain, which, despite its complexity, ultimately executes on infrastructure provided by existing systems. An OS cannot depend on another for protection. It is the protector. It must manage the CPU, allocate memory, initialize devices, enforce security, and coordinate everything that runs above it. This difficulty is not a weakness. It is the proof that the work matters. If a sovereign OS were easy, it would already exist. The fact that it does not exist is not evidence that it is impossible, but that it is necessary and feared. Every obstacle is the shadow of its importance. Consider the history of computation. When Richard Stallman wrote the GNU Manifesto in 1985, the idea of free software seemed naïve. Proprietary vendors controlled everything, and the idea of sharing code openly was dismissed as utopian. Today, free software powers the majority of the world’s servers and infrastructure. What was once a dream has become the backbone of modern computing. When Satoshi Nakamoto released the Bitcoin whitepaper in 2008, the idea that money could be decentralized without banks seemed absurd. Central banks and governments were seen as unchallengeable authorities. Yet within a decade, Bitcoin became a trillion-dollar asset and a philosophical movement, proving that decentralized systems can outlast skepticism. The lesson is clear: what appears impossible is often simply unattempted. Yet patchwork solutions cannot deliver sovereignty. Linux, as vital as it is, still embeds trust in centralized maintainers, and its distributions are distributed through supply chains vulnerable to compromise. Qubes OS, designed for compartmentalization, remains layered on Linux and inherits its dependencies. Tails OS, built for privacy, still relies on the very infrastructures it seeks to escape. Each of these efforts is noble, but each is constrained by the soil in which it grows. They are branches of a tree that was planted in the wrong ground. NØNOS dares to do what others will not. It does not bend to inherited compromises. It does not accept the assumption that sovereignty must always be partial, conditional, or mediated. It seeks to redefine the ground itself. This is not about software alone. It is about sovereignty. Without a sovereign OS, every decentralized protocol rests on centralized ground. Without a sovereign OS, every cryptographic breakthrough is mediated by infrastructures hostile to freedom. Without a sovereign OS, the individual remains a tenant in someone else’s empire, granted access only at permission.

NØNOS is necessary because the alternative is silence. Either we accept the systems we have been given, or we build the system that must exist.

This is why NØNOS begins not at the application, not at the blockchain, not at the API, but at the kernel itself. Sovereignty cannot be added later. It must be designed from the first line of code.

Part III, What We’re Building

The idea of sovereignty in computation is meaningless unless it takes form in code. Dreams must become systems. Principles must become architecture. This is the task of NØNOS: to embody the promise of decentralization in the operating system itself, to move from abstraction to reality, and to demonstrate that freedom can be engineered. At the heart of NØNOS is the kernel, the living core of the system. Unlike traditional kernels, which inherit decades of compromises and assumptions, the NØNOS kernel is born from the ZeroState. It is designed as a higher-half kernel, operating in a memory space mapped for resilience and clarity, while maintaining precise control over the lower physical regions. From the moment it takes control of the CPU, the kernel asserts a principle: sovereignty begins here. This kernel does not treat cryptography as an afterthought or a library. It integrates cryptographic primitives at the syscall level, where proofs and verifications are executed as natively as memory allocations or process scheduling. Zero-knowledge systems such as Groth16, PLONK, Halo2 recursion, and STARKs are not “applications” that one may install later. They are the very grammar of the OS. A program running on NØNOS can request proof generation or verification with the same immediacy as it can request access to memory. Cryptography is no longer an optional layer it is a law of the system itself. The bootloader reflects the same philosophy. Most modern systems treat the boot process as an opaque passage, where firmware and vendor certificates assert control before the user ever sees the machine. Secure Boot, as implemented today, secures the interests of corporations, not the sovereignty of the user. NØNOS rejects this paradigm. Its bootloader is transparent, cryptographically verifiable, and stripped of hidden anchors. Trust begins not in vendor signatures, but in proofs generated and verified within the system itself. The act of turning on the machine becomes an act of autonomy, not subordination. Networking within NØNOS is equally reimagined. Privacy is not relegated to applications or external tools. Onion routing is implemented at the kernel level, making anonymity and routing obfuscation a default property of communication. Timing-attack detection, adaptive padding, and circuit quotas ensure that even the most subtle forms of traffic analysis are resisted. Where other systems ask the user to trust external networks or applications to protect them, NØNOS builds protection into the bloodstream of the OS. Every packet carries the assumption of resistance. Memory management, often ignored in the pursuit of speed, is also redefined. NØNOS implements secure allocators seeded with canaries, ensuring that memory corruption and overflow attacks are detected before they can metastasize. Constant-time operations prevent the leakage of secrets through timing. Buffers are sanitized, overwritten with cryptographic randomness before they are freed. The memory itself becomes a terrain hostile to exploitation but perhaps the most significant dimension of NØNOS is its relationship to the future: its integration of post-quantum cryptography. Where most systems still rest upon ECDSA and RSA algorithms that will collapse under the weight of quantum computation, NØNOS builds with lattice-based and hash-based algorithms that resist the inevitable. It does not defer sovereignty to tomorrow; it asserts it now, with eyes fixed on the horizon of quantum adversaries. The design of NØNOS does not stop at security. It encompasses philosophy. An OS is more than lines of code it is a declaration of what kind of world its users will inhabit. NØNOS is a rejection of inherited compromises. It is a refusal to trust in corporations, vendors, or governments as intermediaries. It is a system where trust grows only from mathematics, proofs, and transparency. Consider the alternative. In Linux, the root of trust begins in maintainers and distribution pipelines. In macOS and iOS, it begins in Apple’s signature. In Windows, it begins in Microsoft’s license. In NØNOS, it begins in nothing but the ZeroState: no external permissions, no centralized authorities, only proofs, protocols, and the consent of the community that builds and runs it. This is what it means to build an OS from zero. It is not a derivative or a fork. It is not a patch or a hardened distribution. It is a new foundation. A soil where sovereignty is the native property, not an invasive addition.

What we are building is not only an operating system. It is a statement that the individual can reclaim the machine, that computation can belong once again to those who compute, and that the architecture of power can be rewritten.

This is NØNOS. Not a patch, not an application, not a dream but an OS born from the ZeroState, designed to be sovereign, secure, and eternal.

Part IV, Why It’s Hard

The path of NØNOS is not the easy path. It is not glamorous in the way that applications, tokens, or flashy products can be. It is a path filled with endless debugging, sleepless nights, and walls of errors that refuse to yield. The difficulty is staggering. But it is also necessary, because the very reason no one has built a sovereign operating system before is precisely because it is so hard. To build an operating system is to confront complexity at its rawest. Applications can fail in isolation; they crash, they restart, they patch, and life continues. But the OS cannot fail. It must orchestrate the CPU, memory, storage, devices, networking, and graphics with precision so exact that a single flaw can collapse the entire system. It is the soil in which everything else grows. If the soil is corrupted, the harvest is poisoned. If the OS is weak, nothing built upon it can be strong. Most developers will never encounter this level of work. Writing an app, deploying a smart contract, launching a DeFi protocol these are real accomplishments, but they are possible only because an invisible OS beneath them quietly provides stability. To build the OS itself is to strip away that invisible foundation and face the raw machine directly. There is no safety net. The isolation of this task is profound. An application can lean on the OS for protection. A blockchain can lean on Linux for drivers and networking but an operating system must stand alone. It is the final line of defense, the last wall between the user and collapse. There is nothing beneath it but the raw metal of the hardware. That is why an OS is more than code it is responsibility incarnate. The ecosystem challenge compounds the difficulty. Building an OS is not only writing a kernel. It is creating compilers, toolchains, drivers, libraries, documentation, and eventually entire communities of applications. An OS is not one program; it is the condition for all programs. To create one is not to launch a product, but to seed an entire world and then there is the human cost. Burnout, skepticism, resource constraints , these are not theoretical risks, they are lived realities. To pursue something of this magnitude is to fight not only against technical impossibility, but against disbelief. Most will say it cannot be done. Many will argue it is not worth doing. Some will dismiss it as a dream. Yet history teaches us that what is dismissed as impossible is often simply unattempted. When Stallman began GNU, he was told free software would never compete. When Linus released the first Linux kernel, he was told it would never scale. When Satoshi launched Bitcoin, the world laughed at the idea of decentralized money. Each was ridiculed, each was doubted, and each reshaped history. The difficulty is not the reason to abandon the task. The difficulty is the proof of its importance. The fact that no sovereign OS exists today is not evidence that it cannot exist. It is evidence that it must. To build NØNOS is to accept this burden. It is to choose the hard path, the lonely path, the impossible path because it is the only path that leads to sovereignty. We will not inherit freedom from systems designed for control. We must engineer it ourselves, line by line, instruction by instruction, until the foundation itself belongs to us. This is why it is hard. This is why it matters. This is why NØNOS will be built.

Part V, The Inevitability of Change

Every age of computation has believed that its architecture was permanent. Every age has been wrong. In the 1960s, IBM mainframes were the immovable center of the computing world. They filled entire rooms, their terminals wired like veins into corporate and government offices. To imagine a computer in every home was absurd. And yet the personal computer emerged, small enough to sit on a desk, cheap enough to spread across the world, and powerful enough to overthrow the monopoly of mainframes. In the 1980s, proprietary software reigned. Code was locked away, guarded as treasure, and those who dared to suggest that software could be free were mocked as dreamers. Richard Stallman’s GNU Manifesto was dismissed as impractical. But the tide shifted. Linux, born from the free software movement, now runs most of the world’s servers and infrastructure. What was once unthinkable is now the default. In 2008, the idea that money could exist without banks or governments seemed impossible. Satoshi Nakamoto’s Bitcoin whitepaper was met with skepticism, even ridicule. Yet within a decade, a trillion-dollar asset class had been born, and central banks themselves began to study, copy, or fear what was unleashed. The pattern is always the same. Systems of power present themselves as eternal, yet they are temporary. What looks like immovable stone is often sand waiting for the tide.

We are entering the next cycle of inevitability. Research streams that once ran parallel are converging.

Zero-knowledge proofs, once theoretical exercises in academic journals, are now efficient enough to verify complex computations in milliseconds. Protocols like Groth16, PLONK, and Halo2 recursion show that privacy and scalability can coexist. STARKs demonstrate that proof systems can be both transparent and quantum-resistant. These are not side projects; they are the beginnings of a cryptographic renaissance. Operating system research has revealed what is possible when rigor meets code. The seL4 microkernel, formally verified down to the instruction level, has proven that entire kernels can be mathematically guaranteed to be correct. If such verification can be achieved in specialized contexts, it can inspire broader movements toward formally proven sovereignty. Post-quantum cryptography has left the realm of speculation. NIST has standardized algorithms designed to withstand quantum adversaries, and governments now acknowledge openly that the cryptographic foundations of today will not survive tomorrow. The clock is ticking. To ignore it is to sleepwalk into catastrophe. Anonymity networks like Tor and mixnets, though limited in performance, have proven the demand for privacy at the network layer. Millions of people around the world rely on these tools to survive under censorship and surveillance. Their flaws are not evidence that the vision is wrong, but that it must be pushed deeper into the kernel, into the foundation. All of these research paths point in one direction: sovereignty is possible, and it is necessary. What is missing is the system that unites them, the soil into which they can be planted. That soil is the operating system. That system is NØNOS. The inevitability is not only technical. It is social. As states demand backdoors, as corporations centralize AI, as surveillance deepens, the need for alternatives will only grow sharper. History shows that when control reaches its peak, resistance organizes. The personal computer was born as resistance to mainframes. Free software was born as resistance to proprietary capture. Bitcoin was born as resistance to financial monopolies. NØNOS is born as resistance to the capture of the very soil of computation. The future will not be built on today’s foundations. It cannot be. The foundations are already compromised. The future must be built on new ground, where sovereignty is the native property. This shift will happen. The only question is who will build it and whether it will arrive in time.

Part VI, A Call to Action

An operating system is not just code. It is a world and a world cannot be built by one person alone. The foundations of sovereignty require many hands, many minds, and many hearts. They require researchers who understand the mathematics of zero-knowledge proofs. They require engineers who can map memory, tame bootloaders, and build device drivers. They require network architects who can make anonymity resilient and scalable. They require designers, educators, writers, and community builders who can translate code into culture. This is why NØNOS is open-source. Sovereignty cannot belong to one company, one team, or one foundation. If it did, it would repeat the very errors it seeks to undo. Sovereignty must be shared, transparent, and co-created. The source must be visible to all, and the system must grow stronger with every contribution. The road ahead is not easy. It will take months, years, perhaps decades of refinement. There will be setbacks, failures, and long stretches where progress seems invisible. But the only way to build something eternal is to build it slowly, deliberately, with patience and conviction. The difficulty is the proof that the work matters. We are at the beginning of this journey. A roadmap exists, but it is only the start. The kernel is taking form. The bootloader is alive. Cryptographic scaffolding is being designed. A hackathon has been launched to invite the world to join us. Rewards have been allocated, not as charity, but as recognition that every contribution is a piece of sovereignty written into code but this is larger than code. It is a moral choice. We live in an age where control is marketed as convenience, where surveillance is sold as safety, where dependency is disguised as progress. To accept this is to surrender not only our machines but our humanity. To resist it is to build.

Every generation faces a test. For ours, the test is computation. Will the future of machines belong to a handful of corporations and governments, or will it belong to the people who use them?

Will we inhabit systems of control, or will we inhabit systems of freedom?

NØNOS is our answer. It is not the only path, but it is a path that begins at the root. It dares to rebuild the foundation, to declare that sovereignty must start not at the application layer, not at the blockchain, not at the API, but at the kernel itself. This is an invitation. To coders, to researchers, to dreamers, to skeptics: join us. Audit, contribute, propose, critique. Write code, write documentation, write history. Every line matters. Every moment matters.

We do not promise that this will be easy. We promise only that it will be worth it. NØNOS is not a product. It is not a company. It is not a hype cycle. It is a declaration of faith in sovereignty, privacy, and freedom. It is an operating system but more than that, it is a movement.

The machine is waiting.

The future is waiting.

The ZeroState is waiting.

The only question is: will you build it with us?

Context: The project remains NØNOS, and the token on Ethereum will be NOX. From day 1, we said we would launch on the Ethereum ecosystem. Yesterday’s security incident simply accelerated the timing from September to August. We have a live community poll on whether we should launch on Ethereum’s Mainnet or its L2 – Base.

This article covers what happened, the snapshot, the deadlines, the security measures, why we’re moving to the Ethereum ecosystem, and how this will work. Please read carefully – especially the dates.

The Quick Overview

Snapshot: Block 360884872 at 13:13:23 UTC – Aug 18, 2025, taken just before the major trade that led to price and LP changes.

Eligibility: If you held ≥ 10 NØNOS (Solana) at that moment, you qualify for a 1:1 airdrop of NONOS.

Dashboard flow: Connect your eligible Solana address, then enter your Ethereum address to receive the NONOS airdrop next week.

Key deadlines (UTC):

Manual review cutoff (if your SOL address doesn’t auto-appear): by Friday, August 22nd.

Submit your ETH address in the upcoming dashboard by Monday, August 25 (For first batches of airdrop claims)

Miss this and you won’t be part of the first airdrop but still have chance to claim your tokens after.

Do not buy NØNOS on Solana. We’re letting that LP fade, but if you still hold there, you can sell to exit; trade activity after the snapshot does not affect eligibility.

What’s next: This week – Collecting ETH addresses via our upcoming dashboard + a DAO vote on tokenomics. Next week – NOX on Ethereum goes live, airdropped to all submitted ETH addresses based on snapshot eligibility, and targeting a good starting valuation via an LP seeded with sustainable amount in ETH + 4% of NOX total supply.

What Happened

One of our large holders was phished. While debugging OS issues, he ran a script whose final line hid a curl command that downloaded AtomStealer, a local backdoor. The malware enabled the attacker to siphon funds across hundreds of wallets, one by one. We were alerted in time.

Our response prioritized holders immediately:

Snapshot first: We captured all NØNOS balances at block 360884872 (Mon, Aug 18, 2025 13:13:23 UTC).

Value preservation: From the team wallet “nonos-tech.sol”, we sold into the LP after the snapshot to frontrun the attacker’s sale and protect the community.

No profit: No one on the team – or anyone else – profited. We will add personal funds to make the new LP stronger.

Why that method: On Solana’s PumpFun, LPs cannot be pulled. Selling was the only viable way to secure some of the funds from our LP for the upcoming Ethereum launch.

We acted proactively. The hacker ended up giving us a successful stress test: we faced a black swan early – and are coming back stronger, secured, and more united.

Snapshot & Eligibility (Read Carefully)

Captured moment: 13:13:23 UTC – Aug 18, 2025 (block 360,884,872).

Threshold: You must have held ≥ 10 NØNOS (on Solana) at that moment to qualify.

After-snapshot trading: Irrelevant to eligibility. If you were in at the snapshot, you’re in.

For those who didn’t read the announcement about having to hold ≥10 NØNOS (and sold everything after the snapshot):

Your address may not appear as eligible on the dashboard due to blockchain-level restrictions.

We can manually fix this if you contact us by Fri, Aug 22 (i.e., 23:59 UTC Thu, Aug 21) with your Solana wallet:

Email us at: eK@nonos-tech.xyx

Or DM our Telegram mod: @bl4z3ng41n

The Eligibility Dashboard (This Week)

Here’s how it will work:

Connect your eligible Solana address.

Enter your self-custodial Ethereum address (we’re collecting EVM addresses to execute the NOX airdrop next week).

Deadline to submit ETH address on first airdrop batch: Mon, Aug 25 (23:59 UTC Sun, Aug 24).

No submission = no airdrop.

We’ll share the link across official channels as soon as it’s live.

Guidance on Solana Liquidity

Please do not buy NØNOS on Solana; we’re letting that LP fade into oblivion.

If you still hold there, you can sell to pull out what you can via that LP.

The snapshot already locks your airdrop eligibility.

Why Ethereum, and What’s Coming

Solana’s PumpFun helped NØNOS get off the ground, but its immutability restricted crisis tooling and long-term design. Ethereum gives us the modularity, governance, and security practices we need.

1. Chain decision (live): Community poll on Ethereum Mainnet vs L2 Base, ending Wed, Aug 20, 2025 16:00 UTC

2. Eligibility Dashboard (this week): The community will verify eligibility to receive the same amount of tokens on ETH and submit their EVM address

3. DAO vote (this week): Tokenomics and tax fee structure

4. Launch (next week): NOX on Ethereum, valuation TBD, seeding LP with +50k $ in ETH + likely 4% of NOX (32M tokens)

5. Roadmap focus: Flexibility, sustainability, and community-directed development

Security – What We’re Doing, What You Should Do

Protocol-side safeguards

Security audit of the new contract before deployment.

Rigorous internal testing and staged rollout checks.

Team supply in a multi-sig, with long-term vesting earmarked for ecosystem development.

On-chain governance: holders guide parameters and future upgrades.

Personal OPSEC tips (please adopt these)

Read before you run: avoid one-liners that pipe curl/wget to shell.

Use a hardware wallet (Ledger/Trezor) for meaningful balances; keep hot wallets light.

Verify downloads (checksums/signatures); avoid macros in documents.

Keep extensions and OS updated; regularly revoke stale approvals.

Never share seed phrases; consider a passphrase and store backups offline in multiple safe locations.

Security is a continuous discipline. We’ll keep raising the bar and sharing best practices.

• Key Dates (UTC)

Aug 18, 2025 – 13:13:23: Snapshot taken at block 360884872.

By 23:59 UTC Thu, Aug 21: If your address doesn’t appear on the dashboard because you sold everything after the snapshot, email eK@nonos-tech.xyx or DM our Telegram mod @bl4z3ng41n with your Solana wallet for manual inclusion.

By 23:59 UTC Sun, Aug 24: Enter your Ethereum address in the dashboard (after connecting your eligible Solana address). No entry = no airdrop.

Next week: NONOS on Ethereum goes live (with the DAO vote wrapped up this week).

Closing

Early adversity forced clarity and speed. We protected holders, preserved value, and set NØNOS on the architecture it deserves. The next chapter is about execution, security, and community governance – with NOX on Ethereum at the core.

Onward.

This article is for informational purposes only and does not constitute financial advice. Always do your own research and practice strict operational security.

For half a century, operating systems have been built to run code, store data, and connect machines. They have been designed for performance, compatibility, and sometimes for a illusion of security but they have never been designed for proof. In the modern landscape, where decentralization is as much marketing buzz as engineering discipline, and where anonymity often comes at the expense of verifiability, the lack of native proof capabilities in operating systems has become a critical gap. NØNOS exists to fill it. This is not merely a kernel project or a networking stack; it is the foundation for a proof-native, decentralized physical infrastructure network – where every action, from a packet relay to an AI inference, can be verified cryptographically without revealing sensitive data.

At its core, NØNOS runs on an architecture we call “Capsules • Mesh • zk • Micro-fees.” The diagram of this model is not an abstract vision sketch; it is a wiring diagram of how the system operates in the real world. Capsules are isolated, signed runtime environments that execute specific workloads – some persistent, others running entirely in RAM while generating zero-knowledge proofs of their execution. Because NØN-OS is zero-state, nothing mutable survives between reboots; each session starts from a verified baseline. Proofs, ledger entries, and state can be reconstructed from the network itself, so even a freshly booted node can resume trustless operation. The mesh layer is a peer-to-peer transport fabric based on libp2p, but enhanced with our own onion routing implementation. This onion protocol, written in onion.rs, is the first of its kind to carry zero-knowledge proofs within the onion packet itself, enabling peers to validate the claims made about a packet without decrypting its contents. The result is a network where every message is both anonymous and provably valid, and where no node needs to persist state locally to remain trustworthy.

The Beacon layer, implemented in modules like beacon/trust.rs, provides the Proof of Decentralization mechanism that sits at the heart of the trust model. In a traditional network, decentralization is something you assume or hope for; here, it’s a quantifiable, verifiable property. Nodes issue signed attestations of their uptime, peers, and contribution, which are then zk-verified by others in the network. This makes it possible to produce an auditable record of the network’s decentralization over time, with no single party controlling the narrative. That record can also be used in reputation scoring for marketplace participants – because in NØNOS, the economic layer is inseparable from the proof layer.

That economic layer is the micro-fee ledger. Every node maintains a local, cryptographically sealed JSON file at /var/nonos/ledger.json which records each economic event: capsule installations, relay jobs, proof verifications. The entries are hash-linked so that any tampering is immediately detectable. Fees are not abstract – each install in the decentralized mod marketplace costs a baseline e.g 0.0001 NØNOS, with the potential for dynamic pricing based on supply, demand, and proof of service quality. Because the ledger is local, it can operate in disconnected or partitioned network environments, later reconciling with the broader network or anchoring its state on-chain for long-term auditability.

Operator control is provided through a unified set of tools: the nonosctl CLI for scripted and automated control, a text-based UI for quick management in bare-metal or Terminal- only environments, and a planned GUI (local:host) for visualizing the proof graph, micro-fee economy, and capsule ecosystem in real time. Crucially, even administrative actions are themselves recorded in the proof chain – meaning there is no “out-of-band” operation that can’t be audited later.

All of this sits atop the secure substrate we’ve been building at the kernel level – the part of NØN-OS that was our primary focus today. The kernel’s role is not just to schedule tasks and move bytes; it is to serve as a root of trust. We’ve built per-CPU Global Descriptor Tables (GDTs) and Task State Segments (TSS) with dedicated Interrupt Stack Table (IST) stacks for fault isolation. The Interrupt Descriptor Table (IDT) covers every architectural exception, each handler logging its state through a cryptographic hash-linked logging system that starts running from the moment the first instruction executes after reset. Build reproducibility is enforced at the Cargo and linker level: no-redzone for interrupt safety, frame pointers for traceability, Link Time Optimization in fat mode for deterministic codegen, and embedded LLVM bitcode for reproducibility audits. Security extensions like NX, SMEP, and SMAP are activated immediately if supported by hardware, and write protection is enforced in CR0 to prevent runtime code injection at the kernel level.

When you combine these layers – the capsule isolation, the zk-enhanced onion mesh, the beacon trust layer, the micro-fee economy, the proof-aware operator tools, and the cryptographically hardened kernel – you get something unprecedented: an operating system where proof is as fundamental as process scheduling, and where decentralization is not a configuration choice but a verifiable protocol property. It is the first onion routing implementation to embed zero-knowledge proofs natively, the first DePIN runtime to make Proof of Decentralization a built-in feature rather than a social contract, and the first OS to integrate micro-economic accounting directly into the kernel-application boundary.

From here, the roadmap is about deepening that proof integration. The scheduler will eventually produce attestations of task execution order. Syscall entry and exit will be logged into the proof chain, allowing complete replayable audit trails. Proof generation will expand beyond current zk-SNARKs into STARKs for certain workloads. The capsule marketplace will become a governed ecosystem, with staking and slashing tied to proof validity. And the beacon attestations will be periodically anchored on-chain, creating a permanent, public decentralization record for NØNOS networks.

What we are building is not an experimental OS for hobbyists. It’s a production-grade, proof-native infrastructure layer that can host AI inference workloads, privacy relays, distributed computation markets, and anything else that benefits from anonymity without sacrificing verifiability. It’s the first operating system that knows – and can prove – that it is trustworthy and that’s not just a milestone for NØNOS. That’s a milestone for computing & everyone.

By eK.

Email: eK@nonos-tech.xyz