Content Provenance Infrastructure

Oak Chain records who authorized every change to an Oak content repository.

Apache Oak is the content repository underneath Adobe Experience Manager. It stores and publishes content well, but it cannot prove who authorized a given change. Oak Chain adds that proof where the data is stored: each write is signed by a wallet, paid for on Ethereum, and ordered by the validator cluster that owns its address before it is applied. An organization runs its own cluster of three or five validators and gives each business unit its own address, a separate branch of the repository managed from the organization's wallet. Other clusters can mount and read that content but never change it. Applications built on Oak keep working as they are.

Run It Locally

Read the Thesis

Document
The JCR node you write.
Signature
Signed by your wallet.
Settlement
Paid for on Ethereum.
Ordering
Ordered by your own validator cluster.
Storage
Applied on every validator in that cluster.
Style
manual-hero

Two axioms this project is built on

These aren't certainties. They're the operating assumptions Oak Chain treats as real enough to build against.

Axiom 1: Ethereum Is Physics

Some internet layers stop being choices and become physics. Ethereum is becoming that layer for trust and settlement: public event ordering, wallet-based identity, programmable settlement, and independently verifiable state.

ETH is not a feature of Oak Chain. ETH is the base asset and the trust anchor.

Read the full argument →

Axiom 2: Oak Is Entrenched

Some enterprise systems become entrenched. Adobe Experience Manager is the dominant CMS underneath the marketing sites, commerce catalogs, and brand estates of much of the Fortune 500. AEM runs on Apache Oak: the content repository Adobe acquired with Day Software in 2010 and has stewarded ever since.

Read the full argument →

The bridge in one view

Oak Chain combines Ethereum's economic finality model with Oak's content model. Familiar developer surface; stricter trust boundary.

What stays familiar
What is introduced
JCR API
Wallet-scoped namespace ownership
Sling authoring patterns
ETH-backed authorization path
Oak TAR segment model
Raft validator replication
Content and asset semantics
CID-linked binary durability

The system in one diagram

Authoring layer connects to validators. Validators reach Raft consensus, verify on-chain settlement events, and persist to Oak segments. Edge Delivery serves the result.

architecture

The protocol path

In chain-backed mode, an accepted write can leave a stronger trail: signed, settled, replicated, and durable.

Author signs write intent
On-chain settlement is recorded
Leader verifies auth + settlement
Proposal enters consensus queue
Validators replicate via consensus
State persists in Oak + CID graph

Choose your route

Two integration patterns share one validator core. Pick the path that matches where you are today.

Build on Oak Chain For new applications and edge-delivered surfaces. Start with the quickstart, auth, paths, and the API.
Operate a Validator For infrastructure teams. Run validators and watch the write pipeline.

Where to next

Read the Thesis The two axioms in full, plus why now.
How It Works Interactive flows for write, payment, IPFS, consensus.
Architecture Two deployment models, three operational planes, storage stack.
Status What runs today, what is proven, and what comes next.
FAQ Common questions answered.
Oak and JCR remain the foundation. The validator runtime adds attributable, economically authorized writes, and the connector lets AEM 6.5 LTS author read that content at /oak-chain.