MemChain and Encrypted Storage

MemChain is AeroNyx's private memory layer for humans, applications, and autonomous agents. Its strongest production path is local-first: the device keeps an encrypted memory store and performs useful recall locally, while a configured AeroNyx node may retain an owner-signed sealed copy for synchronization and recovery. The node-blind claim is technical and narrow: it applies to records encrypted by the client before remember_sealed, not to every legacy or cognitive MemChain operating mode.

The product promise

MemChain is designed around four promises:

Node-blind sealed storage: a participating node receives ciphertext and has no content key.
Local-first recall: an unlocked device searches its own encrypted replica and can work offline when the needed record is present.
Owner-controlled identity: records are signed and keys are derived from the user's P2P identity; AeroNyx has no recovery master key.
Bring your own brain: memory storage is separate from the model chosen to distill or answer over it.

The word chain describes linked and ordered memory state. MemChain is not marketed as a token chain or general-purpose blockchain.

Implemented system layers

The current codebase contains distinct layers that must not be conflated:

Layer	Current role	Trust boundary
Device memory store	AES-256-GCM sealed records, encrypted embeddings, local BM25/vector recall	Plaintext is available only while the owner unlocks the local process
Sealed MPI path	`remember_sealed`, owner-authenticated recall/detail/forget/status	Node stores owner-signed ciphertext and cannot decrypt it
Standard MemChain modes	Local/P2P/SaaS cognition, graph, vector and compatibility features	Some deployments may process readable records; not covered by the strict node-blind promise
Commitment ledger	Signed ordering commitments, follower recovery and pinned witness evidence	Commits opaque record identifiers, not memory plaintext

Blind storage is configuration-gated. A node does not become a memory provider merely because it runs the privacy-network service.

Remember, store, recall

The product flow has three stages:

Remember: an eligible AI turn is distilled under user control, converted to a durable record, encrypted on the device with AES-256-GCM, content-addressed over the sealed form, and signed by the owner. P2P private chat is not automatically ingested as AI memory.
Store: the device writes the ciphertext to its local SQLite replica. If sealed node storage is enabled and reachable, it uploads the same opaque record as a best-effort backup.
Recall: the unlocked device combines local keyword, vector, time, layer, project, and structured signals. It decrypts only selected hits and supplies relevant context to the chosen AI workflow.

A fresh device with the same recoverable identity can backfill sealed records from a configured node and rebuild local indexes. Recovery depends on the identity material and available synchronized data; AeroNyx cannot decrypt or reconstruct a lost identity.

The strict node-blind contract

For the strict sealed path, the client encrypts before transport. The node recomputes a record identifier over owner, timestamp, layer, tags, source label, and ciphertext, then verifies the owner's Ed25519 signature. It stores the ciphertext verbatim and never decrypts, re-encrypts, or re-signs it. Optional keyed token hashes, client-generated vectors, opaque record edges, provenance IDs, and a project label or opaque project hash may support retrieval.

This is node-blind storage, not a zero-knowledge proof. A vector can reveal similarity structure, and a plaintext project label reveals that label. Privacy-sensitive clients should prefer local recall and opaque metadata.

Metadata a sealed-storage node still sees

A sealed-storage node still observes bounded metadata required for authentication, storage, and abuse controls:

owner public key used by the current signed request protocol
request timing, ciphertext size, record count, layer and source fields
record IDs, opaque relation/provenance graph shape and optional project grouping
client-supplied vectors or keyed search terms when those optional fields are used
aggregate quota, storage pressure, latency and error outcomes

It must not receive or log memory plaintext, content keys, raw search tokens, private identity seed, AI prompt, chat plaintext, DNS contents, destinations, browsing history, or wallet-level traffic. Node-blind means content-confidential; it does not by itself provide traffic-analysis or owner unlinkability.

Local-first encrypted recall

The local Rust store writes ciphertext only to disk. Unlock derives a domain-separated content key from the active P2P identity, builds an in-memory index, and decrypts selected records on demand. Embeddings and index snapshots are also sealed at rest. Locking drops the usable key/index state.

Recall is deterministic and does not require a new model call: BM25 and vector candidates are fused, with time, layer, project, structured tuples, supersession, deduplication, protection, archive, and conservative working-set rules layered around retrieval. A node backup remains secondary; a successful local write is the authoritative remembered signal. Offline recall works when the local encrypted replica already contains the record.

Relationship to chat, identity, and private routing

These are separate protocol surfaces:

Encrypted chat: relays store and forward E2E ciphertext; chat content is not automatically converted into MemChain memory.
AI conversations: eligible completed AI turns may enter memory only when the user has enabled the workflow.
Identity backup: encrypted .ayx backup protects identity recovery; losing all valid identity material also loses the ability to decrypt memory.
Privacy networking: protects traffic in motion; MemChain protects selected state at rest. Neither replaces the other.

Raw conversation journaling, if offered, must remain a separate opt-in encrypted record history rather than silently changing the semantics of distilled AI memory.

Agents and the model-provider boundary

AeroNyx separates blind storage from cognitive processing. A blind node does not gain permission to read memory because an operator also runs a cognitive worker. A local model can keep inference inside the user's or operator's boundary. An external model provider can read the exact plaintext prompt sent to it and is therefore a separate, explicit trust choice.

Provider timeouts, response limits, cooldowns, fallback routing, or TEE deployment may improve availability and isolation, but they do not make an external plaintext inference call end-to-end encrypted. Product UI and agent APIs must show which model receives content and obtain consent for any non-local processing.

Commitment ledger and witness protection

The Rust node implements an append-only signed commitment ledger for opaque record IDs, plus bounded follower synchronization, signed local anchors, checkpoint certificates, pinned witness comparison, and optional short-lived coordinator leases. Strict startup can require a configured number of distinct pinned witnesses before listeners open. Followers can recover verified commitment history from the coordinator or compatible carriers.

This protects ordering and detects rollback, fork, divergence, or equivocation within an operator-defined trust set. It is not permissionless consensus, public-chain finality, leader election, token execution, or proof that witnesses hold encrypted payload bytes. Coordinator, follower, witness, and lease features are default-off/configuration-controlled and must fail closed when strict policy is enabled.

Benchmark language

Public benchmark language must identify the test and its limits. AeroNyx internal LongMemEval-S runs in July 2026 measured retrieval hit rates of 95-99% for the tested setup and node-side recall in the 2-5 ms range. End-to-end answer quality depends heavily on the selected model, extraction policy, dataset, device, corpus size, and whether the query hits local or node storage. Retrieval itself does not require a new LLM inference call.

Do not claim SOTA, industry-best accuracy, formal zero knowledge, guaranteed offline recovery, audited benchmark parity, or projected scores as achieved results. Use the exact test date, configuration, and model when publishing a number.

Operator-safe observability

Nodeboard and health APIs may expose only aggregate operational evidence:

feature enabled/configured state and sealed-record capacity
encrypted object count, bytes, quota pressure and cleanup health
local commitment height, audit outcome, follower freshness and carrier recovery status
configured/eligible/verified witness counts and strict-threshold outcome
coarse latency, error, retry and synchronization buckets

They must not expose owner keys, record IDs, project labels, blind terms, vectors, graph edges, checkpoint hashes/signatures, witness identities/endpoints, ciphertext, plaintext, prompts, or per-user storage history.

Current maturity and non-claims

Accurate status:

Implemented: encrypted device store, identity-derived unlock, local hybrid recall, sealed node write/recall/forget, owner signatures, opaque search support and storage-root attestation.
Implemented but config-gated: public blind storage, remote ownership, commitment coordinator/follower, pinned witnesses, threshold startup and coordinator leases.
Separate trust boundary: standard readable MemChain cognition, SuperNode workers, local or external model providers.
Not claimed: every AeroNyx node stores memory, all nodes share one global memory chain, permissionless consensus, token economics, universal multi-device durability, metadata anonymity, or immunity to a compromised client.

Deployment status must be read from the node's current configuration and health output, not inferred from source-code presence.

Privacy boundary

The durable invariant is simple: the client decides what becomes memory, encrypts before sealed-node upload, retains the content key, and decrypts selected records locally. The node may authenticate the owner, preserve and order opaque state, answer owner-authorized sealed retrieval, and publish aggregate health; it may not read or transform the content.

If an external AI provider is selected, the client may send relevant plaintext to that provider. If identity keys are lost, AeroNyx cannot recover the memory. These are explicit boundaries, not footnotes.