ENC — Litepaper

Abstract

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.

ENC — encode, encrypt, enclave — is the substrate for what comes next: a trust-minimized, self-sovereign protocol where code is verified, not trusted, data carries its own proof, and apps are generated to be owned by their users and usable by agents.

The verification doesn't stop at the protocol. The infrastructure and the apps are formally verified too, because they're all generated from the same proven mathematical core — their guarantees hold by mathematics, not by trusting whoever (or whatever) wrote the code. So one specification, reviewed once, expands — instantly, across ~10 platforms — into a running app whose security is carried by proof, not re-audited by hand.

And it's not one app. The same machine that generates a verified messenger generates a verified marketplace, wallet, social feed, or registry — AppGen redefines existing apps as agent-native, trust-minimized, sovereign ones. A sovereign messenger is simply the first instance — not the product.

In one line: you can forge a screenshot; you can't forge verified data — and ENC turns every app's money, messages, agreements, and agent actions into verified data.

I. The paradigm is breaking

Every app today runs on infrastructure you have to trust. The operator can silently rewrite your data, censor you, lock you out, or vanish — and you can't check. Even "audited" or "decentralized" systems still ask you to trust that the code actually running matches what was reviewed, and that the operator behaves.

That bargain held while four things were true: code was human-written, it was human-reviewed, apps were operated by accountable people, and they were used by humans who would notice when something looked wrong. All four are now false:

• Code is AI-written — "vibe-coded" faster than anyone can read, let alone audit. No reviewer — not the best engineer, not the best mathematician — keeps pace with what machines now emit; human review, the old basis of trust, simply doesn't scale to machine output. You can't validate what no one fully read; "we reviewed it" becomes a statement about a fraction of the code, at a point in time.
• Apps are agent-operated — autonomous agents act on your behalf and transact with other agents, at machine speed, across parties that have never met. There is no human in the loop to apply judgment.
• Trust doesn't compose to machines — reputation, terms of service, and a careful read are human-scale instruments. They don't survive millions of unattended interactions. And the human method for building trustworthy systems — theorize a clean spec, then hand-write the code and hope it matches — can't keep pace with machine-scale output either; it's the wrong instrument for the job.
• Claims have to leave the room — a screenshot proves nothing to anyone who wasn't there. The instant your data must be trusted by someone else's system, "trust me" fails.

When neither the operator nor the code can be vouched for by a human — because no human can keep up — the only trust that scales is mathematical proof. Trustworthy infrastructure for agents can therefore only be built by agents whose output is checked not by a reviewer but by math. That is the forcing function behind everything in this paper.

II. The new paradigm: trust-minimized, self-sovereign, verifiable

ENC replaces the old bargain with three properties that stack:

• Trust-minimized (the system property) — you have to trust as little as possible. Not "trustless" (there's always some trusted base) — minimized to a small, explicit, measurable surface, with everything above it backed by proof.
• Self-sovereign (the outcome you feel) — your identity, data, and money are yours: encrypted, portable, no phone number, no central account, no operator that can censor or revoke you.
• Verifiable (the mechanism) — every piece of data and every line of running code can be checked, not believed: authentic, ordered, unaltered, authorized — by you, a counterparty, another app, or an agent, without trusting the source.

One sentence: ENC is a trust-minimized protocol that delivers self-sovereignty through verifiability and formal proof. Own it — and prove it.

Each primitive is the forced replacement for an assumption the agent era broke — skip any one and the stack falls back to the failure it was built to avoid:

III. The protocol

At its core ENC is small and sharp — an event-sourcing store you own: signed writes (events), ordered into append-only logs, committed to structures anyone can verify, governed by explicit permissions.

Declarative, not computational

An ENC node runs no app code. State is non-computing — key→value leaves in a Sparse Merkle Tree — and a single manifest declares everything an app is: its states, traits, operations, readers, and lifecycle. The node doesn't execute an app; it enforces a declaration — verify the signature, check the manifest, append, update the tree. That is exactly what keeps the whole system verifiable (there's no arbitrary computation to reason about) and fast (the work per event is small and bounded).

Virtual enclaves

The unit of an ENC app is an enclave — a self-sovereign realm for your data. The name is an analogy to a hardware TEE (a protected enclave like SGX), but with the trust inverted: an ENC enclave is protected by cryptography and math, not hardware. Concretely it's a cryptographically-defined, append-only log that is yours: writes are authorized by your keys, and the data is portable. Reference templates express every app shape: Personal (profile / identity anchor), DM (a private mailbox), Group (roles, moderation, group encryption), Registry (discovery). An enclave is platform-blind (the host only sees ciphertext), portable (it is its keys plus signed history), composable (enclaves reference each other by key and coordinate via signed commitments any third party can verify), and agent-compatible (an agent's enclave is indistinguishable from a person's). Discoverability is opt-in: list an enclave in a Registry to be found, or keep it entirely private — the choice is yours, not the platform's.

Identity & lifecycle

An identity is a secp256k1 key with Schnorr (BIP-340) signatures, held by you — passkey, extension, or hardware, no phone number — never the server. The node is a single sequencer that only orders writes.

Because the node only orders writes — it can't author them or sign for you — its power is sharply bounded.

Authorization (RBAC)

Who may do what in an enclave is a small, decidable permission model baked into the verified kernel — three columns and six verbs, packed into a single bitmask so every check is one cheap, provably-correct computation, never a tangle of if statements.

Three columns — who you are:

• State (where you are) — UPPER-CASE, mutually exclusive: PENDING, MEMBER, BLOCKED.
• trait (what modifies you) — lower-case, stackable flags, each carrying a rank: owner, admin, muted.
• Context (who you are to this object) — Self, Sender, or Public, evaluated at check time.

Six operations — what you may do: Create, Read, Update, Delete, Push, Notify — permitted or refused as a function of the columns, with deny marked by a leading _, and deny overriding allow.

Authority changes are themselves signed events — Move (state, e.g. PENDING → MEMBER), Grant / Revoke / Transfer (traits), Gate (open or close a capability), Shared / Own (key-value state) — each requiring explicit permission, with a proven rank rule that stops anyone acting on someone ranked above them (no quietly promoting yourself to owner).

Concretely: an admin can admit a PENDING member or mute a MEMBER, but cannot grant owner or act on anyone ranked at or above itself — the kernel simply refuses, because the rank rule is a theorem, not a hopeful runtime check. So a moderated group's whole policy — who can post, admit, ban, or mute — is a tiny declared table the compiled code is structurally incapable of violating. Permissions aren't config; they're theorems — impeccable math for authorization, where escalation isn't merely forbidden, it's unrepresentable. Each enclave becomes a sovereign jurisdiction: its own small constitution, governing humans and their agents under one law the code cannot break — exactly what makes bounded delegation to an agent (§IX) safe.

Verifiable state & history

Current state commits to a Sparse Merkle Tree (one root); full history to an append-only Certificate-Transparency-style log; the two are bound and signed as a Signed Tree Head. Anyone verifies inclusion, append-only consistency, and any state fact offline, without trusting the node — history is tamper-evident. Optional validity proofs (zkEnc) prove state was reached only by authorized transitions, so a node can't write Mallory = admin and have a membership proof still pass. And privacy costs nothing here: an enclave's contents can stay encrypted while its state remains zk-provable — you can prove what's true about it without revealing what's in it.

Event sourcing, and dataviews

Underneath, ENC is an event-sourcing store. Every change is an immutable, signed event appended to the log; current state (the SMT) is just a fold over those events. Nothing is overwritten — the history is the database.

That log is the foundation all app-side logic builds on, and there are two ways to read it. A private app — a messenger, a DM, encrypted email — needs nothing else: the client holds the keys and queries the node directly for its own enclave's events, no index in between. Only when you need public, indexable data — a public timeline, a search index, an aggregate feed — does an (optional) dataview earn its place: a service that projects events into a queryable read-model and keeps it live as new events arrive. Delivery is part of the permission model: Push (P) streams full events to a dataview or service endpoint; Notify (N) sends a lightweight ping to a human client. A Registry, for instance, is just an enclave whose dataview indexes listings and serves them as a discovery API.

So it is command-and-query, signed end to end: write a signed event, then read it back — by querying the node directly for private data, or through a dataview for public, indexable data. On that one foundation you can build anything — a private messenger, a public timeline, productivity apps, an end-to-end-encrypted email system, a headless agent API, or a category no one has named yet.

The mesh

ENC is not a central server and not a blockchain — a federated mesh of nodes. A node's role is deliberately narrow: it hosts the enclaves assigned to it, orders their writes, and delivers them — pushing new events and notifications (the Push / Notify operations) to members and their devices, and holding data for offline sync and multi-device catch-up. It never authors writes or signs for you. Each enclave is ordered by one such node, but that sequencer is bounded — it can't forge, reorder, or fake state — so you get edge-latency speed and one ordered source of truth without a central operator or a global-consensus tax.

Because that power is bounded, the network is ultra-flexible: a node can run anywhere — the edge, a server, your laptop, even your phone — and you can be your own node, so no third party sees even your metadata. No one can lock you in, there's no choke point to censor, and your enclave survives any node dying — it just moves. An always-on node still gives reliable offline delivery and multi-device sync, so you keep sovereignty without the peer-to-peer reliability tax.

And because an enclave is a repository — keys plus signed history — the tooling treats it like git for your data: you clone, push, pull, snapshot, and migrate it. Moving your data to another host — or off one entirely — is a single command, and a snapshot round-trips byte-identically on any host. Portability stops being a promise and becomes git clone.

IV. Privacy — transparent by default, private and pluggable

ENC is transparent by default — but transparent about the rules, not your content. State and every transition are verifiable and the log is tamper-evident, so anyone you allow can confirm that something happened and followed the rules; confidentiality then layers on top, so the operator can store your data but never read it. The primitives are standard and conservative — secp256k1 with Schnorr (BIP-340) signatures, ECDH key agreement (Curve25519 / secp256k1), XChaCha20-Poly1305 authenticated encryption, and HKDF-SHA256 derivation. What's unusual is that which scheme protects a given piece of data is a swappable plugin, chosen by the shape of the conversation:

• One party — your own private data — identity-aead: authenticated encryption under a key only you hold.
• Two parties — a direct message — dm-ratchet: a forward-secret double ratchet, so a compromised key doesn't expose past messages.
• A group — group-mls-lazy: a lazy variant of MLS (the IETF group-messaging standard) that scales it further — rekeying the whole group in O(log N) on a membership change while deferring the work lazily onto the enclave's real, verifiable history, so large groups stay cheap.

Crypto as swappable plugins

Each is a real package filling a typed slot in the model — identity-aead, dm-ratchet, ecdh-envelope, group-mls-lazy, and more — so you can swap or add schemes (post-quantum, a different group ratchet, a sealed-sender mode) without touching the verified core. And because every plugin carries its own machine-checked security claim, swapping never means "trust whoever wrote it": the guarantee travels with the plugin, and the set you've chosen is your explicit privacy surface. Encrypted reads require an ECDH session, so confidentiality is built in, not bolted on. Privacy isn't a feature you're handed — it's a choice you own, and can upgrade.

The subkey system — keys for agents and devices

You never hand an agent — or a new device — your root key. ENC mints subkeys: child keypairs derived from your identity with HKDF under a domain separator, so a subkey is provably yours yet leaks nothing about the root — and the root private key never leaves your control. Each subkey is issued with a signed capability grant that is scoped, expiring, and revocable — it names exactly what the holder may do and for how long. A co-signed certificate binds parent → subkey, and a tweaked variant (S = P + t·G) is even publicly verifiable without one. Revoke a subkey and it's dead — so a compromised agent or a lost device never compromises you. That is how a remote agent in the cloud or a local agent on your device can act as you within a strict, revocable scope (§IX) — a key that is provably yours and provably bounded, enforced by math, not a dashboard toggle.

V. One instance: a messenger

ENC is the substrate; a messenger is just one app on it — taken here as an example because messaging is the hardest, most-contested consumer surface. Even there, the new paradigm shows: an ENC messenger owns your identity (no phone), your data (verifiable, portable), and your money — on a mesh no one controls — and every message can be a typed, verifiable object that other apps and agents compose.

How to read it: the table scores default, user-visible guarantees — optional modes, whether a system retains or discards its logs, and network reach are separate dimensions, called out where they differ.

The honest read: encryption is table stakes (ENC, Signal, WhatsApp, Keet all have it), and ENC does not claim to beat Signal on metadata — Signal's privacy comes from storing nothing, the opposite bet from a verifiable, retained log. The rows where only the ENC app is green are the point: self-sovereignty and verifiability (formally verified — alone, even against Keet), plus reliable delivery where pure-P2P Keet isn't. The one row reversed against everyone is network — so the battle is distribution, not capability. And this is only instance #1: the same AppGen line produces the next thousand apps.

VI. Formal verification — trust, replaced by proof

The formalization gap

Every other "formally verified" protocol shares one unsolved problem: the proof covers a model, but the code that actually ships is hand-written — or now vibe-coded by an AI — and the compiler and runtime beneath it are trusted, not proven. A specification (a document) sits on one side and an implementation on the other; they drift the moment coding starts, and that gap is where bugs and backdoors live. It is the signature of the top-down method — theorize a clean spec, then hand-write code and hope it matches — which neither closes the gap nor keeps pace with the code machines now emit. An audit only ever samples it — and no one can audit what no one fully read. This is the gap ENC closes.

Closing the gap by construction

ENC closes it by construction — and inverts the method. It formalizes the protocol from the behavior of real systems and drives that formalization as far up the proof as the math allows — bottom-up, not top-down, an asymptote it approaches rather than a perfection it claims. The implementation is generated from the proven spec by a verified CodeGen: from one Lean 4 artifact — a small, closed, total calculus, EncDSL — four generators emit Lean, JavaScript (the SDKs and the Cloudflare host), Rust, and a Rust→WebAssembly kernel. No human hand-writes the protocol code and no AI vibe-codes it — the code is the spec, compiled. Because the generators are deterministic, a reproducibility gate regenerates every artifact and requires the bytes to match hash-for-hash (sha-256) or the build fails; key refinement properties are proven at the host boundary. So the deployed bytes provably are the generated ones — there is no second codebase to drift. The same gate lets the protocol evolve safely: every new version is re-proven before it ships, never merely re-trusted.

The spec runs — its own reference

Here is the part no other "verified" project has: the Lean spec isn't only a model on paper — it runs. Everyone else keeps a paper spec and a separate reference implementation, two artifacts that drift — the original formalization gap. ENC's spec compiles to an executable reference (the Lean enc-oracle), which decides every commit with the exact state machine the theorems are proved against. So validating the spec is validating the reference; there is no gap between them to close. Anyone can run that same oracle as an independent referee to settle whether an event was valid, or who deviated in a dispute.

The proofs are the audit

About 2,851 machine-checked theorems, zero sorry — a security review performed by mathematics, exhaustive over every input, that never goes stale because the code is generated from the very thing it proves. No human vouches for these bytes; the proof does, mechanically and in full.

The remaining links are closed concretely. The reproducibility gate regenerates every artifact and fails the build unless the bytes match hash-for-hash. Generated tests (TestGen) replay the same workflow corpus across every platform through pluggable adapters, and a matrix theorem makes passing the two axes imply the whole grid. And witnesses run those tests against the exact published bytes and record their hashes. So spec, proof, code, tests, and running bytes become one continuous, checkable chain — not a document and a hope.

SpecGen — created and audited

ENC isn't hand-built and hoped-correct; it's produced and graded by SpecGen, a protocol-agnostic framework that drives every claim along one pipeline: human-readable prose → a reviewed formal meaning → a Lean theorem → generated code → a witness that ran the real bytes → a single signed report. ENC is just one instance of the SpecGen / CodeGen / AppGen / TestGen meta-protocols (which carry no protocol of their own) — generators that turn any domain into a fully-verified system. Aim them widely and you get a formally-verified, autonomously-evolving universe of software; ENC is simply its first citizen. So the "audit" isn't a PDF from a firm that sampled the code once — it's a machine-checked report that re-derives the entire chain and grades each claim.

And trust-minimization here is measured, not asserted: that report places every claim on a public trust lattice, from T0 ("trust the operator — nothing checked") up to T6 (a ratified, version-pinned release) — with T5, proved & conformant, the tier where the generated code provably matches the proof and the witnesses agree. Almost no system can put a number on how much trust it removes; ENC can.

Verification all the way up

And none of this is confined to the protocol kernel. Because the infrastructure and the apps are generated from the same proven core, the verification flows all the way up: you review a small declarative spec once, and the math guarantees the expansion into a running, multi-platform app. That is the elegance — a tiny calculus that does the expanding for you — and it's what makes "formally verified" affordable for ordinary apps, not just a protocol.

It reaches the infrastructure and its scaling, too — which is why ENC apps reach Telegram scale on a kernel small enough to verify. The proven kernel ships as a compact WebAssembly module on Cloudflare's edge: one Durable Object sequences one enclave, globally distributed and auto-scaling, and because the protocol is declarative and non-computing, the work per event is tiny and bounded — verify, check the manifest, append, update the tree, nothing arbitrary to run. The node, the policy layer, and the host contract are all specified in Lean — even the server-side hook system is proven orthogonal (replay_invariant_under_hook_swap: swapping policy hooks can't change replayed state). And how it scales is proven, not just benchmarked: sharding provably preserves the full history (the shards' union is the log), rebalancing loses nothing, shard assignment is bounded, and a connection-aggregating hub collapses socket blow-up from O(clients × enclaves) to O(clients) + O(enclaves) — relaying frames verbatim as a metadata-only router that never sees content or becomes an auth point. A Telegram-scale workload is mechanically modelled to pass; raw throughput is measured, but the correctness of scaling is proved — so the system grows without any guarantee quietly breaking.

What you still trust is small and named: the platforms ENC runs on (the WebAssembly runtime, the browser, the Cloudflare edge), a few standard cryptographic primitives taken as axioms (Schnorr, SHA-256), and the integrity of code distribution. Everything above that line is backed by proofs you can check — §X measures exactly how much.

VII. AppGen — redefining every app for agents

A verified core isn't safe on its own. The app is where your identity lives and the surface your agent acts through — so an unverified app is a trusted black box sitting between you and the proof, free to misuse the very keys and permissions the protocol so carefully bounds. Verifying only the node leaves the most dangerous layer unchecked: the app's behavior has to be verified too. That's why, on ENC, apps are generated — emitted from the same proven core, so the parts that can hurt you (how it wields your identity, keys, and authorization) are verified by construction, not hand-written and hoped-safe.

Apps, generated not hand-built

An app is mostly declarative JSON — data types, mapping, actions, a UI tree — compiled by the Flow engine. Flow even resolves the infrastructure for you: it matches each piece of state to an enclave that can host it by its access model (who must read it back, how many parties, public or private), so you never hand-wire where data lives.

The interface isn't exempt from the math either. The ui-kit builds views from a formally-specified atom algebra — a closed set of UI atoms with composition laws — and its rendering implementation is proven to refine that algebra.

From that one definition ENC generates the typed SDK, the tests, native clients for ~10 platforms (built instantly by platform adaptors, not rewritten), and agent skills — so an agent drives the app through the same verified surface a human's SDK uses.

From a sentence of intent

AppGen goes the last mile: it turns an intent in natural language into a validated specification and then a generated, verified app — correctness proved once and reused across many. The generated apps are formally verified too — not because each is hand-proved, but because the pipeline is proven and the app is generated from a tiny reviewed spec: you review the sentence — a human stays on the intent, which is tiny and human-scale — and the math verifies the implementation, which no longer is; cross-platform consistency is a theorem, so the same app behaves identically on all ~10 targets. Instant, ten platforms, verified — because the math is small and elegant enough to do the expanding for you.

Redefining the app landscape

This is the paradigm's reach: the same machine that produces a verified, sovereign, agent-native messenger produces a marketplace, a wallet, a social feed, a registry, a payments app, an identity app — each trust-minimized, owned by its users, and usable by agents, by construction. The ambition is not "a few apps on a new protocol." It is to redefine the existing app landscape for the agent era — every category re-expressed as a verified, composable, sovereign ENC app, generated rather than re-audited one by one. And it's already underway, not hypothetical: ~1,500 existing apps — from health systems to social feeds and payments — have already been redefined as formally-specified ENC apps — a corpus empirically built by agents that AppGen draws on to turn a sentence of intent into the next app instantly, with formally-verified security, across all ~10 platforms.

Plugins & custom apps

Plugins make this extensible without bloating the proven core: the kernel encodes only what all apps share — the state machine and RBAC, generated and type-checked — and everything outside it is a composable plugin filling a typed slot. Read-side projections (ranker, indexer, aggregator, filter), write-side gates (spam, moderation, fraud, validation), and the crypto suite (sign, verify, key-exchange, ratchet, group) are all slots; today ~41 plugin packages fill the kernel-defined ones. Each slot's type is its contract and its assumptions join the verification surface — so you build custom apps the same generated way — spin up new enclaves and infra, compose existing enclaves, or extend the verified SDKs, plugins, and app UIs — and they inherit the proofs rather than re-earning trust. ENC provides the whole toolchain for exactly this.

VIII. Verifiable data → composability

Verifiability matters far beyond "was this message tampered with." A piece of non-verifiable data is trapped in the conversation: a message, a screenshot, a P2P chat record only means something to the people in the room, in the moment. Hand it to a third party, another app, or an agent and it's a forgeable claim. Verifiable data is portable trust — it can leave the room and be checked by anything, without re-trusting the source. It stops being a dead end and becomes a building block.

That is the unlock: verifiability is the precondition for composability. An ENC object is a typed, verifiable thing — a payment receipt, an API call and result, a vote, a signed agreement, an attestation — that can be handed to an escrow, court, or tax tool and verified; consumed by another app as a trusted input; or chained, each step verifying the last without trusting it.

A clean test for where verifiability earns its place: anything the data must be trusted by someone not in the room — money, agreements, cross-app inputs, an agent, or future-you after a reinstall. (Two people just chatting don't need it.) One honest boundary: verifiability kills forgery, tampering, reordering, and deniability — it does not make content true. A verified object proves "X really committed to this, unaltered, in order, and was allowed to" — which, for money and agents, is exactly what you needed: can I hold them to it, and can anyone check?

Verifiable, not exposed

And verifiable does not mean exposed. With zero-knowledge proofs, data stays private while remaining verifiable — you can prove a balance is sufficient, a member is authorized, or a rule was followed without revealing the content itself. Privacy and verifiability aren't a trade-off; ZK gives you both.

So ENC isn't a verifiable messenger — it's a composable, verifiable data fabric.

IX. Built for agents

An agent has no human judgment to fall back on — so the trust a human used to supply (reputation, a gut-check, support) must become something the machine can compute. The only computable trust is verification. Walk one transaction — your agent buys a service from a stranger's agent and pays — and every ENC primitive is load-bearing:

• Authenticity → the quote is signed; your agent can't be fed a forged or injected one.
• Bounded authority → your agent acts under a derived sub-key carrying a scoped, revocable grant — "up to $50, this category" — and the kernel structurally prevents more, even if your agent is buggy or hijacked. Compromising the agent never exposes your root identity. That's what makes delegating to an AI you don't fully trust survivable — the leash is math, not hope.
• Verifiable receipts → the payment emits a proof the seller's agent checks before releasing. Agent-to-agent commerce is impossible without it.
• Ordered tamper-evidence → "deposit before release" is reliable.
• Mechanical disputes → a third party verifies the signed, ordered log and sees who deviated.
• Composability → the receipt feeds an accounting agent; the next agent verifies the last one's output without trusting it.

At every step, trust travels with the data, because two agents that share no central authority can't trust each other any other way. That's the gap between agents calling APIs inside one vendor's walls (siloed) and an open agent economy where agents from different parties transact — and that wave is cresting now (agent-payment rails are hitting exactly this wall and faking it with cards and API keys inside silos).

Agent apps belong on ENC

So the framing flips: it isn't "agent apps need verifiability" — it's that agent apps should be built on ENC. On ENC an agent gets, for free, the five things an autonomous actor actually needs:

• Identity — a sovereign, portable agent identity (a derived sub-key), with no central account to revoke or impersonate.
• Memory — durable, portable, verifiable memory: its enclave is an append-only log it owns and can carry anywhere, not state trapped in one vendor's database.
• Privacy — pluggable, formally-specified encryption over everything it holds.
• Composability — typed, verifiable data that other agents and apps consume as trusted input, so work chains across parties.
• Verifiability — every action is checkable, so trust travels with the data, not with a relationship.

Add RBAC-bounded delegation and a wallet on top, and if an agent can take any responsibility, ENC is the substrate it should stand on. "Agents are just regular users" is only safe because it's verifiable and bounded.

X. What you have to trust — minimized, and measured

The aim isn't zero trust — it's a trusted surface that is small, explicit, and measured: the soundness of the host platforms ENC runs on (the WebAssembly runtime, the browser, the edge), a few well-studied cryptographic primitives, and the integrity of code distribution. Everything above that line — that the running code matches the proven spec, that history is intact, that state is valid, that your agent stayed in bounds — is backed by proofs you, or your agent, can check. The trust lattice puts a number on it.

The bet is simple, and it's a paradigm bet: software you depend on shouldn't require you to trust the people who run it — or the AI that wrote it. And it cuts deeper than the operator: the same force that broke human review (§I) forces the real paradox of the agent era — you can't trust an app an agent hand-built either, vibe-coded past anything a human could vouch for. ENC resolves it one level up. Agents don't hand-build the apps you depend on; agents build the verified system that generates them — SpecGen → CodeGen → AppGen, a toolchain architected on these principles so that every output carries the math stamped into it. Trust never rests on the builder, human or machine; it rests on the proof the builder was forced to satisfy. Don't trust the builder — trust the proof it had to satisfy.

And that proof is empirical, not theorized — formalized upward from how real systems actually behave (§VI, §VII), not dreamed top-down and hoped into code. Replacing human audit with machine-checked proof doesn't just make iteration safe — it makes it fast: a proof checks in an instant where a human review would stall, so each new version is regenerated and re-proven before it ships, reproducibility-gated, advancing toward that ceiling without anyone re-vouching by hand — safe because verified, not because someone signed off. The human still owns the one thing that stays human-scale: the intent — you review the sentence, and the math owns the implementation, the audit, the code that ships. This is the whole toolchain, not just the protocol: built by agents, for agents. Make the spec, the proofs, the code, and the running bytes one continuous, checkable chain; let your data leave the room carrying its own proof; generate every app verified and sovereign; and prove, not promise, that the rules were followed. The old paradigm trusted. The new one verifies. Own it — and prove it.