Signed Commitment Ledger and Witness Protection

AeroNyx now operates a signed, append-only commitment ledger for encrypted MemChain records. The ledger proves ordering and integrity while keeping memory contents unreadable to infrastructure. It is a protocol integrity mechanism, not a public blockchain.

Protocol invariant: coordinators, followers, witnesses, the backend, and the public website may process only ciphertext commitments and bounded operational evidence. They must not receive plaintext memory, decryption keys, owner relationships, or social-graph data.

Current production architecture

The current deployment uses one commitment coordinator and three audited follower/witness nodes. The coordinator orders opaque commitments. Followers independently verify block ancestry and signatures, retain signed checkpoint evidence, and grant short-lived production leases. This protects against rollback and concurrent copied coordinators while the witness assumptions hold.

Role	Responsibility
Client	Encrypts and signs memory locally; keys never enter node infrastructure.
Coordinator	Appends opaque commitments to signed blocks after local integrity and authority gates pass.
Follower / witness	Verifies history, stores signed observations, serves checkpoints, and grants bounded leases.
Backend / website	Publishes aggregate health only; never hashes, signatures, identities, endpoints, owners, or content.

On July 16, 2026, four reporting nodes verified the same height-33 history covering 8,339 opaque commitments: one coordinator and three followers. The coordinator held a 3-of-3 runtime witness lease. These values are a dated operational observation; use the public API for the current state.

Write and verification flow

The client encrypts and signs an eligible memory record locally.
The coordinator appends only the opaque commitment and ordering metadata.
Every append verifies the previous signed block and updates a signed local high-water anchor.
Followers pull bounded pages, verify ancestry and signatures, and retain signed checkpoint certificates.
The coordinator produces new commitment blocks only while every configured runtime witness grants the same short-lived lease instance.

Startup and runtime enforcement

Two separate controls are intentionally used. Startup checkpoint evidence detects rollback before public listeners open. The runtime lease prevents two copied coordinators from continuing to produce concurrently.

Startup threshold: at least two distinct valid responses from three operator-pinned witnesses are required before the coordinator opens UDP, TUN, or API listeners.
Runtime lease: all three configured witnesses must grant the active coordinator a short lease. Partial renewal enters a degraded state; production stops when authority expires.
Recovery: after witness connectivity returns, a complete new lease round restores production authority and increments an aggregate recovery counter.

Failure model

Condition	Required behavior
One witness misses renewal	Report renewal_degraded and retry while the existing lease remains valid.
Lease expires	Set production_permitted=false and fail closed for new commitment production.
Signed remote state is ahead	Stop startup because local state may have rolled back.
Signed histories diverge	Stop startup and require operator investigation; never auto-merge conflicting history.

Public observability

The privacy-safe aggregate is available at GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/ under data.protocol_status.memory_chain.

json

{
  "mode": "signed_commitment_ledger",
  "status": "witness_protected",
  "verified_nodes": 4,
  "coordinator_nodes": 1,
  "follower_nodes": 3,
  "max_verified_tip_height": 33,
  "max_verified_commitment_count": 8339,
  "max_granted_witnesses": 3,
  "max_required_witnesses": 3,
  "network_consensus": "not_claimed"
}

The JSON above is an example of a verified production observation, not a hard-coded promise. Counts and lease time change as nodes report.

Node-level heartbeat includes the following lease-health fields for operators. The public endpoint exposes only aggregate counts:

coordinator_lease_state, coordinator_lease_granted_witnesses, coordinator_lease_required_witnesses, coordinator_lease_seconds_remaining, coordinator_lease_production_permitted, coordinator_lease_last_attempted_at, coordinator_lease_last_renewed_at, coordinator_lease_last_failure_at, coordinator_lease_renewal_failures_total, coordinator_lease_consecutive_failures, coordinator_lease_recoveries_total.

Privacy boundary

The system deliberately excludes record IDs, block hashes, signatures, witness identities, endpoints, owners, ciphertext bodies, plaintext, routes, client metadata, wallet-level traffic, and social-graph edges from the central/public contract. Commitment counts prove system work; they do not identify what a memory says or who created it.

What this is not

Not permissionless consensus, Byzantine finality, or fork choice.
Not a token ledger, smart-contract platform, or proof-of-stake system.
Not proof that every possible host or witness is honest.
Not permission for infrastructure to read or search memory plaintext.

Frequently asked questions

Does AeroNyx have blocks now?

Yes, the commitment subsystem has signed blocks that order opaque encrypted-record commitments. No, AeroNyx should not describe this as a public blockchain or global consensus network.

What happens if a witness is offline?

A partial renewal is visible as degraded while existing authority remains. If the lease expires before every configured witness grants a new lease, new commitment production stops automatically.

Can a witness read MemChain memory?

No. Witnesses verify signed commitment structure and lease ownership. They do not receive plaintext records or decryption keys.

Verify local append-only history

Every current AeroNyx decentralized node can inspect its local MemChain append-only file without printing memory contents. This is a local integrity gate for restart, upgrade, mirror recovery, and incident review.

What the verifier checks

Canonical bounded record framing, with a maximum decoded record size of 10 MiB.
Each standalone Fact and each Fact inside a Block still matches its content-derived fact_id.
Each Block Merkle root matches the exact ordered Fact identifiers stored in that Block.
Consecutive Blocks preserve height continuity and the previous-Block hash link.
The file ends on a complete record boundary; an incomplete physical tail is reported separately.

Read-only command

Run against the configured path or provide an explicit path:

bash

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

sudo aeronyx-server memchain verify-aof \
  --path /var/lib/aeronyx/.memchain

Field	Meaning
`valid_bytes`	Bytes covered by complete, semantically valid records.
`fact_records` / `block_records`	Standalone Fact records and Block records; Fact records inside Blocks are not double-counted.
`last_block_height`	Height of the last valid local Block.
`torn_tail_bytes`	Incomplete physical bytes after the last valid record; zero is clean.
`status`	`verified` means the entire observed file passed this local scan.

Upgrade and recovery gate

Run verify-aof before replacing the binary and retain the aggregate result in the command audit.
Validate the new binary and run the same read-only scan before restarting the service.
After restart, confirm replay restored the same or a later height and then run node health checks.
If a complete record fails semantic validation, stop and preserve evidence; never truncate or auto-merge it.

Proof boundary

The command emits only path and aggregate counts. It never prints Fact values, record identifiers, Block hashes, signatures, owners, witness identities, endpoints, routes, or decryption keys. A mirror or full node can independently validate the same local bytes after synchronization without learning what the encrypted memory says.

This scan does not replace Block-signature validation, witness certificates, runtime leases, fork choice, or consensus. A clean AOF proves local structural integrity, not that every infrastructure participant is honest.

Implementation paths:

crates/aeronyx-server/src/services/memchain/aof.rs
crates/aeronyx-server/src/main.rs