Status

What Oak Chain runs today, what it proves next, and where the evidence lives. Checked on 2026-11-02 against jackrabbit-oak trunk d6962279d9.

Running today

A three-validator cluster orders every write and delete with Raft over Aeron Cluster. Each validator applies the same ordered commands to its own Oak segment store.
A write is a wallet-signed proposal. The validator answers 202 PENDING with an operation id, and the operation reaches COMMITTED once a majority of validators has applied and flushed it.
A proposal id takes effect once. A resent proposal is refused with 409 duplicate_proposal, and any validator can answer the status of a proposal that has been applied.
Committed content is readable through the validator's explorer, wallet and event APIs, and on each validator's local dashboard, content explorer and configuration console.
Payment settlement runs in mock mode: the validator simulates settlement and checks signature format. The settlement contract, ValidatorPaymentV5, has its source, tests and gas baseline on Settlement Contract.

Demonstrated

Unit and package gates on JDK 17 and 21, run in CI on every change to trunk.
A bounded three-validator campaign in mock mode, with 39 assertions: writes reached COMMITTED and the typed repository state converged on every validator. The validation record lists the evidence and its limits.
Enterprise federation on one host: two clusters of three validators in mock mode with a static directory. A smoke run passed 58 assertions (ownership, redirects, read-only mounts in both directions, directory epochs), and stopping the member another cluster read from passed 30 (leader and mount failover, no missing reads).
Garbage collection on the same two clusters: each validator runs Oak's own segment GC and binary GC. While one cluster compacted every minute and released deleted binaries, the other read its content through a mount without a missing read, a 503 or a 500 (40 assertions). See Segment Store GC.
Fault and recovery on one host, three validators in mock mode: the charter's rebaseline suite passed 125 assertions, comparing the full typed repository state of every validator after each fault. A follower or the leader was stopped or killed, with six writes in flight during the leader kill; each of those writes ended on every surviving validator or on none. Below a majority no write committed, and the cluster recovered when members returned. Full graceful and hard restarts kept every write and delete and left the repository state unchanged. A killed validator restarted on the first attempt within seconds.
AEM 6.5 LTS SP3 author (Apache Oak 2.4.0, Java 21) mounted /oak-chain read-only from a three-validator mock-mode cluster on one host. Two opt-in and opt-out rounds passed, and validator garbage collection ran under the live mount: every segment AEM had read for deleted content was reclaimed while all current reads stayed correct. See AEM 6.5 LTS Integration.

Next to prove

Chain-backed payments on Sepolia, with the signed write intent bound to its settlement. The Testnet Runbook is the procedure.
Network partitions, repeated or compound faults, a crash inside a single write's lifecycle, rebuilding an empty validator from a snapshot, overload, and long soaks.
Federation across several hosts, with a deployed enterprise registry, and dynamic membership.
Garbage collection under sustained write load and across several hosts.
Cloud storage backends, and IPFS Cluster replication with live validators.
The AEM 6.5 LTS mount on publish instances, other service packs, chain-backed mode, several hosts, and sustained load.

Each kind of evidence stands on its own: unit tests, bounded multi-validator convergence, fault and recovery runs, and chain-backed runs. A pass in one does not establish another. Live-cluster tests follow the consensus test charter.

Reports

Run it yourself with the Quickstart, or start a validator with Run a Validator.