AeroNyx Signed Commitment Ledger: Status, Design and Limits

The MemChain record-commitment ledger is a chain of signed blocks that records the order of opaque commitments to encrypted memory records. It is currently frozen. It has produced no block since 2026-07-13, because its only authorized coordinator was decommissioned and the design cannot hand authority to another node without that coordinator's signature. It has never provided global consensus.

Current status

Item	State
Blocks	33 blocks. The last one was produced on 2026-07-13
Coordinator	One pinned coordinator node (US1), decommissioned on 2026-10-03
Followers	Still hold and audit the history. When they try to sync, they report `active_coordinator_unavailable`
Coordinator handover	Needs a proof signed by both the old and the new coordinator. Production code has no way to issue one
New blocks	None. The ledger is frozen
Consensus	None. There is no fork choice, quorum finality or public-chain confirmation

Live aggregates are published at GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/ under data.protocol_status.memory_chain. The fields that reflect the current state are coordinator_nodes, follower_nodes, verified_nodes, max_verified_tip_height and block_confirmation_state. Some descriptive text fields in that response still describe the intended witness design rather than today's state, so read the numeric fields.

What the ledger records

Each block contains a header (protocol version, chain ID, height, timestamp, previous block hash, Merkle root, record count and proposer key), a list of record IDs, and the proposer's Ed25519 signature over the header.

A record ID is a SHA-256 hash computed over an encrypted memory record: the owner key, timestamp, layer, tags, source and ciphertext. The ledger never contains memory content, decryption keys or plaintext. It can show that an opaque record existed, and in what order, at a given height. It cannot show what a record says, and it does not store the record.

The memory records themselves are described in MemChain and Blind Vault.

How the design works

One coordinator appends blocks. Exactly one configured node may append. It signs each block and keeps a signed high-water mark beside its database, so that an older copy of the database file is detected at startup.
Followers replicate and audit. Each follower pulls pages only from the pinned coordinator. It checks signatures, height continuity and hash links, and stops on rollback, fork or signature errors. It never merges conflicting histories.
Witnesses check for rollback. Operator-pinned witness nodes return signed checkpoints. At startup, a checkpoint showing that a witness holds a later or diverging history stops the coordinator before it opens its listeners.
An optional lease limits duplicate writers. If this is enabled, the coordinator may produce blocks only while every pinned witness grants it a short lease of 60 to 300 seconds. When the lease expires, production pauses.
Handover uses a dual-signed proof. Authority moves to a new coordinator only through a RecordCoordinatorHandoverV1 proof signed by both the outgoing and the incoming coordinator. Historical blocks are never rewritten.

The witness requirement and the lease are both off by default in the node software.

Why it is frozen

The design depends on a single coordinator. That coordinator was decommissioned on 2026-10-03. A handover needs its signature, and no production code path creates a handover proof. Followers therefore cannot accept a new proposer, and no new blocks can be added. A single coordinator is a single point of failure, and this is the failure.

Memory is not affected. The ledger holds only commitments. Your encrypted memories are stored on your device, and optionally on the node you connect to, independently of the ledger.

Checking the historical blocks

The 33 historical blocks remain verifiable:

Every node that holds a copy audits it at startup. It decodes each stored block, verifies the proposer signature, height continuity, previous-hash links and the record index, and refuses to start if any check fails. The results appear as aggregates (verified_nodes, max_verified_tip_height) on the public stats endpoint.
aeronyx-server memchain verify-aof does a separate check. It verifies the node's legacy MemChain append-only file (framing, content IDs, Merkle roots and block ancestry) and prints only aggregate counts. It does not read the commitment ledger, which is stored in the node's SQLite database.

bash

sudo aeronyx-server memchain verify-aof --config /etc/aeronyx/server.toml

Limits

One coordinator means one point of failure. When it is unavailable, no new commitments are recorded.
There is no consensus, fork choice or finality. Signed ordering is not agreement among independent parties.
Witnesses are pinned by the operator. All production nodes today are operated by AeroNyx, so witness checks do not prove independence.
It is not a token ledger, smart-contract platform or proof-of-stake system.
A commitment proves that an opaque record existed. It does not prove that the record is still stored anywhere.

What is planned

The replacement design drops the single coordinator. Each node will keep its own signed log, other nodes will mirror it, and peers will cross-witness the logs. This is the model the Directory Chain already uses today for node descriptors. No release date has been set. The 33 historical blocks remain auditable as described above.

Frequently asked questions

Is the AeroNyx commitment ledger running?

No. It has produced no block since 2026-07-13. Its only coordinator was decommissioned on 2026-10-03, and production code has no path to hand authority to a new coordinator, so the ledger is frozen.

Is AeroNyx a blockchain?

No. The commitment ledger used signed blocks from one coordinator, with no consensus, fork choice or token. It is now frozen, and AeroNyx does not describe it as a public blockchain or a global consensus network.

Did I lose my memories because the ledger is frozen?

No. The ledger stores only opaque commitments, never memory content. Your encrypted memories are kept on your device, and optionally on the node you connect to, independently of the ledger.

Can the existing blocks still be verified?

Yes. Every node that holds the 33 blocks re-audits signatures and hash links at each startup and will not start if they fail. The aggregate result is visible on the public network stats endpoint.

What will replace the single-coordinator ledger?

The planned design uses per-node signed logs that are mirrored and cross-witnessed by other nodes. This is the same model as the Directory Chain, which already runs for node descriptors. No release date has been set.

Signed Commitment Ledger: Design, Current Status and Limits