Signed Commitment Ledger and Witness Protection
How AeroNyx verifies an append-only encrypted commitment ledger with one coordinator, audited followers, pinned checkpoint witnesses, and a fail-closed production lease without claiming public-chain consensus.
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.
{
"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.
Related: MemChain and Encrypted Storage and Decentralized Node Operations.