# ENC Protocol

> A formally verified, append-only protocol for sovereign, independently-verifiable apps.

## Docs

- [ENC — Litepaper](/litepaper): The apps you use were built for a world where **humans wrote the code, humans reviewed it, humans ran the servers, and humans clicked the buttons.** That world is ending. Software is increasingly **written by AI** and **operated by autonomous agents** acting at machine speed — and every assumption the old app stack rested on (*trust the operator, someone reviewed the code, your data lives in their platform*) breaks at once.
- [Tutorials](/tutorials): Hands-on, build-something walkthroughs. Where the [Developer Guide](/guide) covers each tool
and the [SDK Reference](/sdk) documents every function, a tutorial takes you **end to end** —
from an empty project to a working ENC app you can run.
- [2. Run a dataview server](/tutorials/personal/dataview): The Personal app has a **cross-enclave read** — `profiles` aggregates the latest profile across
every user's enclave. That's served by a **dataview**: a small Worker that subscribes to the
node, projects matching events into a queryable read-model, and answers `query`s. (Your own
`public` / `private` reads come straight from the node and need no dataview.)
- [6. Deploy to production](/tutorials/personal/deploy): Local works — now ship the node and the dataview, and point the app at them. All three are
Cloudflare Workers.
- [3. Deploy the Personal enclave](/tutorials/personal/enclave): An enclave is minted by submitting a **signed manifest** to the node — its RBAC schema,
states, and traits. The Personal app's manifest is bundled in the SDK, so you never write it by
hand.
- [4. Write the frontend app](/tutorials/personal/frontend): Now the app, using the [`personal` SDK](/sdk/apps/personal). `PersonalSdk` is platform-agnostic
— it takes one **adapter** per enclave it declares (Personal + Group). We use the formalized
**`NetworkAdapter`** from `@enc-protocol/client` (codegen'd from the Lean spec): it does
plaintext signed writes and the **ECDH session-authenticated reads** the node requires.
- [1. Run a local node](/tutorials/personal/node): The app talks to an ENC node. For development, run one locally on port `8787`.
- [5. Write a test](/tutorials/personal/test): Test the app the way it runs — against a **real node**, with [vitest](https://vitest.dev). A
global setup boots a node for the run; the tests mint an enclave, write, and read back over HTTP.
- [ENC Protocol — Spec](/spec): The normative protocol spec, divided by dependency layer. The **kernel** holds the
protocol math and canonical semantics; the **node** realizes it at runtime; and the
**app** layer — enclave profiles and confidentiality plugins — builds on top.
- [Enclave Migration](/spec/node/migration): This document specifies enclave **migration** — the controlled transfer of an enclave from one node to another while preserving its full event history and identity. The `Migrate` event, the three migration modes (eager / lazy / fork), checkpoint verification, split-brain prevention, and the backup pattern that re-binds the old enclave's SMT root are all defined here.
- [Node API](/spec/node/node-api): This document specifies the **ENC Node API** — the HTTP, WebSocket, and webhook surface every conforming node exposes. It covers the high-level surface and Session tokens, the REST endpoints and Filter query DSL, the WebSocket streaming subscription protocol, the proof retrieval endpoints, the push / notify and webhook delivery semantics, the wire-level handling of encrypted payloads, and the full error catalog.
- [Zero-Knowledge Validity Proofs](/spec/node/zk): This document specifies the ZK validity-proof layer for the ENC protocol: a succinct proof that an
SMT state transition produced by the node is **valid** under the RBAC rules, verifiable by a client
in O(1) without replaying the event log or trusting the node.
- [Certificate Transparency Proofs](/spec/kernel/ct): This document specifies the **Certificate Transparency** proof formats clients use to verify the ENC enclave event log without trusting the node: CT inclusion and consistency proofs for the log itself, bundle membership proofs that tie individual events to a CT leaf, and the Signed Tree Head (STH) the sequencer publishes as the trust root. SMT membership / non-membership proofs (for current enclave state) are specified separately in [`smt.md`](/spec/kernel/smt).
- [RBAC v2](/spec/kernel/rbac): This document specifies **RBAC v2**, the role-based access control system used by every ENC enclave. It covers the bitmask encoding of State and trait, the runtime Context abstractions (Self / Sender / Public), the JSON manifest schema, the authorization algorithm, and the per-event processing rules (Move / Grant / Revoke / Transfer / Gate / AC\_Bundle / Lifecycle / KV).
- [Sparse Merkle Tree (SMT)](/spec/kernel/smt): This document specifies the Enclave State SMT: a 168-bit-deep sparse Merkle tree keyed by `namespace || sha256(raw_key)[0:20]`, storing RBAC bitmasks, event status, and KV state. The SMT commits to current enclave state and is bound into the CT log via the per-bundle `state_hash`.
- [ENC Protocol Specification](/spec/kernel/spec): ENC (Encode, Encrypt, Enclave) is a protocol for building **log-based**, **verifiable**, **sovereign** data structures with **Role-Based Access Control**. This document specifies the core protocol: cryptographic primitives, the Commit / Event / Receipt wire protocol, event semantics (P / N / U / D), and the enclave lifecycle (Manifest / Update / Delete / Pause / Resume / Terminate). Companion docs cover [RBAC v2](/spec/kernel/rbac), the storage layer ([`smt.md`](/spec/kernel/smt), [`ct.md`](/spec/kernel/ct), [`zk.md`](/spec/node/zk)), enclave [migration](/spec/node/migration), the [node API](/spec/node/node-api), and the [enclave profiles](/spec/app/enclaves) / [confidentiality plugins](/spec/app/plugins).
- [Enclave Design Patterns](/spec/app/enclaves): This document catalogs application-level **enclave design patterns** — Shared, Personal, Group Chat, and DM. The patterns are informative: the core protocol does not mandate any of them. They illustrate how the [RBAC v2](/spec/kernel/rbac) state/trait model and the [confidentiality plugins](/spec/app/plugins) compose into recognisable application archetypes.
- [Encryption Plugins](/spec/app/plugins): ENC enclaves carry **opaque ciphertext** end-to-end — the node never sees plaintext, and the enclave's RBAC schema authorizes against roles, not crypto primitives. Confidentiality is therefore an **application-layer concern**: an app picks an *encryption plugin* whose wire format and key schedule it uses to seal event content and tags.
- [Suites (Ciphersuite Registry)](/spec/app/suites): [Purpose](#purpose)
- [Plugin: ](/spec/app/plugins/ecdh-envelope): **Role:** One-shot sender→recipient confidentiality. The sender derives a single AEAD key from `ECDH(sender_priv, recipient_op_pub)` and seals the message in a self-contained envelope. An optional inner sub-encryption under a distinct domain separator carries a secondary handoff secret (e.g. a group's bootstrap epoch). No ratchet, no rotation, no shared state.
- [Plugin: ](/spec/app/plugins/identity-aead): **Role:** Single-owner deterministic confidentiality. The content key is a deterministic HKDF derivation from the owner's `identity_priv` keyed by the enclave id; any device with `identity_priv` re-derives the same key. No ECDH, no ratchet, no rotation. Maximally simple — appropriate when only the owner ever reads.
- [Plugin: ](/spec/app/plugins/mls-lazy): **Role:** Shared-secret confidentiality for an N-party enclave. A **binary ratchet tree** keyed to sorted member pubkeys distributes each epoch's root secret with O(log N) per-commit envelope cost, plus a flat **OR-wrap fallback** (`epoch_or_wraps`) for members whose **operating key** differs from the parent `id_pub` keyed into the tree (sub-key wallets, e.g. MetaMask). Per-message confidentiality uses a per-sender HKDF ratchet over the shared epoch secret.
- [Plugin: ](/spec/app/plugins/ratchet-pair): **Role:** Pairwise confidentiality. Two identities establish a per-pair epoch over secp256k1 ECDH, then each side derives a per-sender symmetric ratchet inside the epoch. Multi-key recipients (sub-key wallets) are handled by an additive OR-wrap on epoch tags.
- [DM Enclave](/spec/app/enclaves/dm): This document specifies the DM (direct-messaging) enclave application profile: a personal mailbox where the owner reads their own enclave and others write to it, with end-to-end confidentiality provided by the [`ratchet-pair`](/spec/app/plugins/ratchet-pair) plugin.
- [Group Chat Enclave](/spec/app/enclaves/group): This document specifies the group-chat enclave application profile: a shared space for multi-party messaging where multiple members read and write to the same enclave, with end-to-end confidentiality provided by the [`mls-lazy`](/spec/app/plugins/mls-lazy) plugin.
- [Personal Enclave](/spec/app/enclaves/personal): This document specifies the personal enclave application profile: an identity anchor that holds the owner's identity, where to find the owner's data, and where others reach the owner for cross-enclave addressed messages. The `private` layer is sealed with [`identity-aead`](/spec/app/plugins/identity-aead); the `notice` layer is sealed with [`ecdh-envelope`](/spec/app/plugins/ecdh-envelope).
- [Registry](/spec/app/enclaves/registry): This document specifies the Registry application profile: a special enclave that maps enclave IDs to the node endpoints hosting them, resolves identity public keys to their published enclaves, and provides context lookup for what each enclave represents. The Registry is itself an ENC enclave plus a DataView surface (see [`node-api.md` §Registry DataView API](/spec/node/node-api)).
- [@enc-protocol/cli-sdk-base — base SDK classes](/sdk/cli-sdk-base): The base classes that every `@enc-protocol/<app>-cli` package extends.
- [@enc-protocol/cli — the app CLI](/sdk/cli): The global `enc` binary that drives ENC Protocol **apps** from the command line — installing
app SDKs, minting enclaves, and submitting/querying app data.
- [SDK Reference](/sdk): The ENC SDKs are JavaScript/TypeScript packages **generated from the Lean 4 specification** —
the same formally-verified source that defines the protocol. Because they're codegen output,
the client-side crypto, RBAC, and proof-checking you run is byte-identical to what the
[node](/guide/node) and the [spec](/spec) compute.
- [@enc-protocol/memory — API Reference](/sdk/memory): `@enc-protocol/memory` runs the entire ENC node protocol **in the JavaScript heap** — no
network, no subprocess, no `fetch`. It exposes the same surface an app uses against a real
[node](/guide/node) (`createEnclave` / `submit` / `query` / `subscribe` / `as` / `toEnclave`)
but executes the node state machine directly in-process: same RBAC, same signature
validation, same event log, just no wire. It's the fast path for tests, local development,
and deterministic workflows. Like the other SDKs, it's generated from the Lean specification.
- [@enc-protocol/client — API Reference](/sdk/client): Complete API reference for `@enc-protocol/client`, the network client package for the ENC Protocol. Provides HTTP, WebSocket, session management, wallet utilities, and a high-level SDK interface.
- [@enc-protocol/core — API Reference](/sdk/core): Complete API reference for `@enc-protocol/core`, the protocol primitives package for the ENC Protocol. All code is generated from the Lean 4 DSL and formally verified. Do not edit the source files directly.
- [ecdh-envelope — ](/sdk/plugins/ecdh-envelope): The **one-shot directed** confidentiality plugin: a sender seals a payload to a single
recipient with `ECDH(sender, recipient) + AEAD`, with an optional inner sub-encryption for
group-invite handoff. Suite: `enc-xchacha-v1` (XChaCha20-Poly1305, 24-byte nonce). Used for
Personal notices and group invitations. Normative spec:
[`ecdh-envelope`](/spec/app/plugins/ecdh-envelope).
- [identity-aead — ](/sdk/plugins/identity-aead): The **single-owner** confidentiality plugin: deterministic AEAD for content only its owner
reads — no ECDH, no key exchange, no rotation. The content key is
`HKDF(identity_priv, "enc-personal-private:" + lowercase(enclaveId))`. Suite: `enc-xchacha-v1`
(XChaCha20-Poly1305, 24-byte nonce). Used by [personal](/sdk/apps/personal) for `private`
content. Normative spec: [`identity-aead`](/spec/app/plugins/identity-aead).
- [Plugin SDKs](/sdk/plugins): ENC's confidentiality is an application-layer concern: an app seals event content with one of
the protocol's **four encryption plugins**, picked per data\_type. The node only ever sees
opaque ciphertext. Each plugin is a `(role, suite)` pair with a byte-exact wire-and-key
contract — two implementations produce identical ciphertext — and each is **generated from the
Lean specification** into [`@enc-protocol/core`](/sdk/core#confidentiality-plugins).
- [mls-lazy — ](/sdk/plugins/mls-lazy): The **shared-secret (N-party)** confidentiality plugin: a binary ratchet tree keyed to the
sorted member set, giving `O(log N)` epoch-key distribution per commit, plus a per-sender HKDF
message ratchet inside each epoch. Suite: `mls-chacha-v1` (ChaCha20-Poly1305, 12-byte nonce,
RFC 9420). Used by [group](/sdk/apps/group). Normative spec:
[`mls-lazy`](/spec/app/plugins/mls-lazy).
- [ratchet-pair — ](/sdk/plugins/ratchet-pair): The **pairwise** confidentiality plugin: a per-message symmetric ratchet for 1:1 threads. An
ECDH-derived per-pair epoch secret seeds a per-sender HKDF ratchet, so every message uses a
fresh key. Suite: `enc-xchacha-v1` (XChaCha20-Poly1305, 24-byte nonce). Used by
[dm](/sdk/apps/dm) and [super](/sdk/apps/super). Normative spec:
[`ratchet-pair`](/spec/app/plugins/ratchet-pair).
- [@enc-protocol/dm-cli — ](/sdk/apps/dm): Direct messages: end-to-end encrypted 1:1 conversations with an invite handshake, where each
message is written to the recipient's own DM enclave (resolved through the registry).
- [@enc-protocol/group-cli — ](/sdk/apps/group): Group chat: MLS-encrypted group messages with admin moderation, muting, and member-state
management (PENDING / MEMBER / BLOCKED).
- [App SDKs](/sdk/apps): Each reference app ships as a typed SDK at `@enc-protocol/<app>-cli` — a class extending
[`AppSdk`](/sdk/cli-sdk-base#appsdk) with a method per action and a method per read. The class,
its bundled manifests, and its routing are **generated** from the app's `app.json` /
`schema.json` definition, so the SDK surface always matches the app's RBAC manifests.
- [@enc-protocol/node-cli — ](/sdk/apps/node): A **host app** that bundles the reference enclaves — DM, Group, Personal, Registry, and more —
so a single node deployment can serve them all from one definition.
- [@enc-protocol/personal-cli — ](/sdk/apps/personal): The Personal identity-anchor app: public posts, owner-only encrypted private documents, a KV
profile, and a notice inbox for cross-enclave addressed messages (e.g. group invitations).
- [@enc-protocol/registry-cli — ](/sdk/apps/registry): The discovery app: a public index of identities, enclaves, and nodes that lets clients resolve
who/where without a central server.
- [@enc-protocol/super-cli — ](/sdk/apps/super): A super-app composing three enclaves — DM, Group, and Personal — into one SDK: direct
messages, a public moments feed, and cross-enclave profiles.
- [AppGen](/pipeline/appgen): AppGen turns **app intent into a formally-specified app**. It abstracts ~1,500 reference apps
into a generative model and produces validated enclave graphs, SDK code, and deployment artifacts
for **11 platforms** — but the AI never writes arbitrary code. It only selects from and composes a
closed vocabulary of verified building blocks, so every generated app inherits the protocol's
formal guarantees.
- [CodeGen](/pipeline/codegen): CodeGen is the ENC instance's emit layer: it turns the protocol's checked Lean spec into **every
implementation that ships** — byte-deterministically, with each artifact's hash pinned. The
software you run is provably the design that was verified, because it was *generated* from it
rather than written against it.
- [ENC Emulator](/pipeline/emulator): The ENC Emulator is a **browser testbed** that loads every app definition from the
[UI Kit](/pipeline/ui-kit) and runs it against a real ENC node, so the full protocol stack can be
previewed and exercised from a single page. It is also a **required witness** in the spec's
release gate.
- [ENC Flow](/pipeline/flow): ENC Flow is the **enclave-resolution engine**. It bridges UI authoring, ephemeral dev backends,
and helper configs into the protocol-canonical **AppSpec** — the definition the rest of the
pipeline consumes. It is where an app's declarative manifests are derived and reconciled.
- [ENC Pipeline](/pipeline): The ENC Pipeline is the toolchain that makes the protocol, its implementations, and the apps
built on it **one artifact in many forms** — each derived from a single formally-verified
specification and cryptographically linked to the others. It's how "the spec runs" (see the
[litepaper](/litepaper)): humans write intent, agents resolve it to math, and every downstream
form is a *verifiable derivation* rather than a hand-written translation.
- [SpecGen](/pipeline/specgen): **A framework for protocols whose spec, code, and deploy are the same artifact.** Humans write
intent and review the resolved spec; SpecGen formats the prose, extracts claims, induces a
protocol DSL, binds it to Lean, generates the implementation, runs every downstream witness
against the generated SDK, checks the published bytes equal the generated bytes, attests the
deployment, and emits a signed report any agent can verify in ten deterministic steps.
- [TestGen](/pipeline/testgen): TestGen proves that **every implementation behaves identically across every platform**. One
formalized workflow corpus runs across a matrix of tiers — **6 surfaces × 2 backends = 12 tiers**
— and each tier must conform to a platform-free reference tier. There is *zero* per-platform test
duplication: adapters supply thin shims, and a single tier-agnostic runner drives all workflows
through all pools.
- [ENC UI Kit](/pipeline/ui-kit): The ENC UI Kit is an **algebraically-specified, manifest-driven UI layer**. It renders an app from
its declarative manifests into a working interface on any platform, and its state engine is a
pure-functional algebra whose operations are **proven in Lean** to refine the spec.
- [The ENC CLI](/guide/cli): `enc` is a **git-style CLI for end-to-end encrypted, append-only data**, built on the ENC
protocol kernel compiled to WASM. You `init` a repo, append signed events, snapshot the
state, and push to remotes — same shape as git, but every event is cryptographically signed,
every state hash is auditable, and every byte is verifiable from a Signed Tree Head down to
the last event.
- [Developer Guide](/guide): Hands-on guides for building and running ENC infrastructure. Where the [Protocol Spec](/spec)
is the normative reference and the [SDK Reference](/sdk) documents the libraries, these guides
walk through the tools you actually run.
- [Run an ENC Node](/guide/node): An **ENC node** hosts enclaves: it sequences signed events, folds them into verifiable
state (a [Sparse Merkle Tree](/spec/kernel/smt)) and an append-only history (a
[Certificate Transparency log](/spec/kernel/ct)), and serves both to clients over HTTP +
WebSocket. The node never has to be trusted — every byte it emits is independently
verifiable against the protocol's signed events. See the [Node API spec](/spec/node/node-api)
for the full wire surface.
- [Building with the SDK](/guide/sdk): A short tour of building on ENC from code. Where the [SDK Reference](/sdk) documents every
function, this gets you from zero to a verified read/write in a few steps using the
[`@enc-protocol/client`](/sdk/client) high-level surface (which re-exports the
[`core`](/sdk/core) primitives it needs).
- [Agent Skills](/guide/skills): Each ENC app ships a **Claude Code skill** — an installable agent capability that teaches an
agent *when* to invoke the app and *what* to run. After installation, Claude Code surfaces it
as an `/enc <app>` slash command in your project, and the agent drives the app through the
[`enc` CLI](/sdk/cli).
- [ENC Wallet Extension](/guide/wallet-extension): The ENC Wallet Extension is a Chrome (MV3) browser extension that **custodies a user's ENC
identity and signs on behalf of apps** — so an app never touches the private key. It's a BIP-39
seed-phrase HD wallet (an ENC Schnorr identity plus an EVM address) that injects a `window.enc`
provider any ENC web app connects to through a standard Connect-Wallet flow. It's also
NIP-07-compatible (mirrored as `window.nostr`).
- [wshub — WebSocket aggregation](/guide/wshub): **enc-wshub** is a WebSocket aggregator hub for the ENC protocol. It collapses per-enclave
client sockets into **one** client connection, multiplexed over shared, refcounted per-enclave
upstream sockets to the [node](/guide/node):
- [zkEnc — validity proofs](/guide/zkenc): **zkEnc** gives ENC a succinct proof that an enclave's RBAC state was reached by **valid**
transitions — so a node acting as prover **cannot forge authorization**, and a client verifies
the whole history in **one O(1) check**: no replay, no trust in the operator for validity.