MemChain and Encrypted Storage

MemChain is AeroNyx's node-blind memory layer: AI memory the storage node cannot read.

It is built for a world where humans, applications, and autonomous agents need long-lived private context. The user may want an AI to remember preferences, projects, decisions, files, tasks, and relationship context. The infrastructure should help preserve and synchronize that memory, but it should not become the party that can read it.

MemChain connects AeroNyx privacy networking, encrypted messaging, encrypted identity backup, encrypted storage, decentralized privacy nodes, and future agent-to-agent protocol services into one private state model.

The product promise

MemChain is designed around four user-visible promises:

The important distinction is that MemChain is not a public blockchain and should not be marketed with blockchain imagery. The "chain" is the ordered relationship between encrypted memory records, version vectors, checkpoints, and append-only state.

Why MemChain matters

Private communication is not only about moving packets. Users, applications, and agents also need to preserve state:

• conversation context
• AI memory facts
• encrypted chat history
• encrypted identity backup metadata
• file and object checkpoints
• node service records
• agent workflow memory
• verifiable state transitions

If that state is stored in a centralized database as plaintext, the privacy model is incomplete. MemChain gives AeroNyx a path to store and sync encrypted records while keeping decryption under the owner-controlled key model.

Remember, store, recall

MemChain can be explained as a three-stage pipeline.

This gives AeroNyx a practical path to private AI memory: memory can be useful without requiring a central service to hold readable user history.

What nodes can and cannot see

Allowed coordinator metadata:

• encrypted object bytes
• content hash or object address
• append sequence
• version vector
• timestamp or logical clock
• owner-controlled authorization proof
• coarse storage pressure
• replication and synchronization health

Forbidden coordinator data:

• decrypted memory records
• chat plaintext
• plaintext filenames
• semantic tags derived from plaintext
• raw user identity mappings
• private keys or recovery secrets
• wallet-level traffic analysis
• browsing history, DNS contents, or packet payloads

The mental model is private version control for ciphertext. Clients and owner-held keys interpret records; infrastructure only stores, orders, and synchronizes encrypted state.

Relationship to encrypted chat

Encrypted P2P and group chat protect message content before relay transport. MemChain can preserve encrypted conversation records as versioned history when the user enables that workflow. The storage layer should not know what the conversation says, who the user's broader social graph is, or which facts were extracted.

Search over message history should therefore be client-side. The relay and storage layers route and preserve ciphertext; they do not provide plaintext search endpoints.

Relationship to identity backup

AeroNyx P2P identities can be exported and imported through encrypted .ayx backup files. MemChain can later record encrypted backup checkpoints or verification state without exposing identity seeds, social graphs, or plaintext message history.

If a user loses the underlying identity or recovery secret, encrypted memory cannot be recovered by AeroNyx. That is a privacy property, not an accident: the node should not have a master key.

Relationship to privacy networking

The privacy network moves encrypted traffic through decentralized privacy nodes. MemChain protects long-lived state. Together they cover two different privacy surfaces:

• private transport for traffic in motion
• node-blind memory for state at rest

The same rule applies to both: infrastructure should expose health, capacity, and verification metadata, not user content.

Relationship to agents

Autonomous agents need a way to connect, exchange encrypted messages, preserve memory, and verify state transitions. MemChain gives agents a private memory substrate while AeroNyx private routing and encrypted relay services give them a communication substrate.

This is why MemChain is part of the AeroNyx protocol story, not a separate note-taking feature. It is the state layer for encrypted coordination.

Benchmark language

AeroNyx internal LongMemEval-S testing in July 2026 is used to evaluate the memory stack. Public claims should stay precise:

• retrieval hit rate can be described as 95-99% in internal LongMemEval-S tests when the evaluation setup is stated
• end-to-end answer quality depends on the selected AI model, because users can bring their own model
• node-side recall latency can be described as 2-5ms in internal tests
• local-first recall is designed for millisecond-level user experience and offline availability when the local encrypted copy has the needed memory
• retrieval itself does not require a new large-model inference call

Avoid stronger claims such as "industry-best accuracy", "zero-knowledge proof", or projected scores presented as achieved results. The stronger story is privacy, speed, cost, and user control.

Operator-safe Nodeboard fields

As decentralized privacy nodes add encrypted storage or MemChain capability, Nodeboard should show only operator-safe health fields:

• module enabled state
• encrypted object count
• storage pressure
• last checkpoint or sync height
• verification status
• replication health
• sync freshness
• error rates and capacity limits

Nodeboard should answer whether the system is healthy, synced, and within capacity limits. It should not become a plaintext data viewer.

Privacy boundary

MemChain's storage nodes are designed to be cryptographically unable to read memory contents because they hold device-encrypted ciphertext and irreversible blind indexes. Encryption, decryption, and meaningful search happen under user-controlled keys.

There is one important user-facing limitation: when a user chooses an external AI service to distill or answer over memory, the relevant plaintext may be sent to that provider by the client. With a local model, that workflow can remain local. AeroNyx should describe this clearly so users understand which part of the system is node-blind and which external services they choose to trust.

Read the introduction: What is AeroNyx?.

<!-- memchain-external-witness-v1:start -->

Commitment ledger and rollback protection

MemChain maintains an append-only commitment ledger for encrypted records. A commitment block contains integrity commitments and ordering metadata, not plaintext memories or decryption keys. The ledger helps a node detect tampering and rollback; it is not a public blockchain and does not claim distributed consensus, finality, or token execution.

Startup verification order

Before a commitment coordinator opens its UDP, TUN, or public API listeners, it performs these gates in order:

1. verify the configured durability mode
2. audit the complete persisted commitment chain
3. verify the signed local tip anchor
4. audit previously stored checkpoint evidence
5. query operator-pinned peers for signed checkpoints
6. start network listeners only after the policy decision passes

The local signed tip anchor detects rollback of the commitment database while the independently stored anchor remains intact. It does not protect against an attacker who can replace both files. Pinned external witnesses extend the boundary by retaining independently signed observations outside the coordinator.

Witness decisions

Witness identities are explicit Ed25519 pins chosen by the operator. Signed discovery may resolve their current endpoints, but an unpinned permissionless peer can never become startup authority merely by appearing in the peer store.

Verified production rollout — July 14, 2026

One production coordinator has three operator-pinned witness identities. Two independently operated, audited follower nodes now run compatible checkpoint services and each verified and stored the same 33-block, 8,339-commitment history. The coordinator accepted distinct signed converged responses from both followers, then enabled commitment_witness_startup_required = true.

On the verified restart, the startup guard reported configured=3, eligible=3, attempted=3, verified=2, and converged=2; UDP and TUN listeners opened only after this check passed. This is operator-pinned rollback evidence, not consensus, quorum, public-chain finality, or token execution.

Management heartbeat data exposes only the witness scope, configured witness count, and whether strict evidence is required. It does not report witness identities, endpoints, checkpoint hashes, signatures, encrypted record contents, owners, or social relationships.

<!-- witness-threshold-enforced-v1:start -->

Enforced 2-of-3 startup threshold — July 14, 2026

The production coordinator now sets commitment_witness_min_verified = 2 together with commitment_witness_startup_required = true. Startup stops when fewer than two distinct pinned witnesses provide valid signed evidence: zero valid responses produce signed_checkpoint_unavailable, while one valid response produces signed_checkpoint_threshold_unmet. The latest production restart verified two of three configured witnesses before UDP, TUN, or the public API listener opened.

This is an operator-defined startup threshold, not network consensus, quorum, finality, leader election, or fork choice. Rust heartbeat status reports only aggregate policy and outcome fields, including startup_minimum_verified; it does not expose witness identities, endpoints, checkpoint hashes, or signatures.

<!-- witness-threshold-enforced-v1:end --> <!-- memchain-external-witness-v1:end --> <!-- signed-commitment-ledger-related-v1:start -->

Related protocol specification

Signed Commitment Ledger and Witness Protection

<!-- signed-commitment-ledger-related-v1:end --> <!-- memchain-model-provider-boundary-v1:start -->

Bring-your-own brain and the model-provider boundary

MemChain separates node-blind storage from optional cognitive processing. A storage or relay node does not gain permission to read memory merely because another operator enables a SuperNode cognitive worker.

What each component can see

• A node-blind storage or relay node sees ciphertext, blind indexes, bounded routing metadata, and aggregate health signals; it does not receive plaintext memory by default.
• An enabled SuperNode cognitive worker receives only the task payload allowed by its configured privacy level: structured, summary, or full.
• An external model provider can read the exact prompt sent to it. Use full only with explicit user consent and a provider the user or operator has chosen to trust.
• A local OpenAI-compatible model can keep model inference inside the operator-controlled boundary, but the worker running that model is still a trusted processing component rather than a blind storage node.

Runtime isolation

• Successful model responses are capped at 8 MiB before JSON parsing; non-success diagnostic bodies are capped at 64 KiB.
• Transport, API, parse, and empty-response failures place that provider in a 30-second monotonic cooldown instead of disabling it forever.
• HTTP 429 Retry-After is honored within a bounded 1-300 second window; an absent value uses 30 seconds.
• The router may use another healthy configured provider and automatically considers the failed provider again after its cooldown expires. No scheduled job is required.

These limits protect node availability; they do not make an external inference call end-to-end encrypted. The external provider remains a separate, explicit trust decision.

<!-- memchain-model-provider-boundary-v1:end -->