Identity is content.
Arkane has no filesystem — on purpose. The kernel multiplexes exactly one block device, minimally. Format, caching, durability and policy live in cells that own their own memory. Everything durable is content-addressed: a blob's name is the Blake3 hash of its bytes, so dedup, snapshots, versioning and integrity proof fall out of the design instead of being bolted on.
The tower Linux built — and what replaces it.
On Linux, every write climbs a tower the kernel owns: VFS, page cache, filesystem, block layer — one shared stack for every workload, cached twice when a database brings its own buffer pool. Arkane inverts this: the kernel touches only the bottom sector layer, and each level above is a userspace cell holding its frames directly.
Linux (kernel owns it all) Arkane (cells own it) ┌────────────────────┐ 3 zero-copy distribution │ app / database │ SYS_CELL_MAP_BLOB — ro, cap-gated ├────────────────────┤ ▲ │ VFS │ 2 structured stores (service cells) ├────────────────────┤ WAL · cluster state · journals │ page cache │ ← caches ▲ ├────────────────────┤ twice 1 content-addressed blob store (cell) │ filesystem │ blake3 blobs · refcount + GC · dedup ├────────────────────┤ ▲ │ block layer │ 0 block device — one virtio-blk └────────────────────┘ ───────────────────────────── one stack for all kernel: multiplexes level 0, minimally. everything above is userspace.
No double caching: the cell that owns the data owns its frames — there is no OS page cache underneath re-caching the same blocks. That is the structural claim; the speed claim waits for the benchmark.
Hash-addressed, owned by cells.
The durable core is a content-addressed blob store run by the persistence cell — not by the kernel. A blob's identity is its Blake3 hash: identical content stores once, every revision is verifiable, and a model or snapshot maps read-only into N consumer cells at zero copies — cap-gated and content-verified at the reader. On top sits a Blake3-chained write-ahead log: apply → reboot → state intact, demonstrated end-to-end. The kernel keeps only a tiny durable root pointer; store, format and distribution are cells all the way up.
Because identity is content, audit works on the data level: what was stored, when, and that it never changed is cryptographically checkable — not reconstructed from logs after the fact.
Keys the app never holds.
Encryption at rest is layered, and we say by which layer. The baseline comes from your infrastructure: run Arkane as a VM on an encrypted array (FlashSystem, LUKS, encrypted LUNs) and its sectors land encrypted — from storage you already certified. On top, Arkane seals sensitive stores at the application layer: bodies are encrypted in the storage path with per-scope data keys, wrapped by a net-free keystore cell whose key encryption key lives in RAM only and never touches disk. Manifests reference secrets by name — value-free: neither the operator nor the app ever sees the plaintext key material.
KEK ram-only, never on disk DEK per scope, stored only KEK-wrapped forbid(net::inbound, net::outbound) # structurally net-free
Sealing today covers selected stores, not every byte — the audit chain is deliberately plaintext, and per-tenant sealing-by-default is the build-out. We will not say "encrypted" without saying by what.
One driver, not a zoo.
Arkane needs no storage-driver menagerie. It runs as a guest and sees one virtio-blk device — a single, tiny, audited driver. Whatever sits underneath is your hypervisor's job: FlashSystem or local NVMe, NAS-backed images, SAN LUNs, Ceph. The blob store sees sectors, not NVMe queues or NFS RPCs. Your storage stays yours — redundancy, replication and snapshots come from infrastructure you already run and certify, and Arkane ships no storage stack to patch. VM-first is the deliberate choice, not a limitation.
Bare metal moves the real driver (NVMe, network storage) into contracted driver cells — consistent with the model, but that is roadmap, not today.
What is not there today.
not yet performance numbers — the structure avoids Linux's costs, but "faster" is claimed only after the benchmark not yet bare-metal drivers (NVMe / NAS-native) — until then: VM + virtio-blk not yet multi-host replication — single-host durability is solid, distribution is the hardest open problem on the roadmap bounded blobs cap at 256 MiB; large models need more RAM (and GPUs, later) — CPU + mid-sized models is the honest v1 reality
Everything above the line is running and gated in QEMU — the proof page shows how.