deos runs on dregg runs in robigalia
Three names, one machine. The desktop adds zero new trust: everything you touch reduces to a kernel that has been proved, and the kernel runs on a microkernel that has been verified. Authority is something you show, never something you claim.
The agentic desktop userlayer
Everything a human or AI agent touches: cap-confined surfaces, a certified compositor, the web-of-cells, the rehydratable frustum-snapshots. The web's interaction model — declarative, hypertext-driven, progressively enhanced — made capability-gated and verified instead of ambient-authority soup. A window is a Capability{ Surface(cell), rights }.
The verified capability kernel
The formally-verified distributed object-capability kernel: a Lean executor, the circuits emitted from it, and the witness-graph. One sentence carries it: a turn is the exercise of an attenuable, proof-carrying token over owned state, leaving a verifiable receipt. The kernel the proofs are about is the executor the node runs.
The whole stack, on seL4
A Rust OS personality where the dregg executor is embedded as a protection domain on the seL4 microkernel — ~10kLOC of verified C as the only privileged code. The firmament holds the apps, gives them capabilities, and checkpoints them transparently. It boots today.
Three things only this substrate can do
Not features ported from elsewhere — categories that require a verified witness-graph and an object-capability substrate at once. Each is a place where the proof does real work for a person.
A window is a capability
In a normal desktop, what an app may do is decided by a session — a cookie, an ambient grant, a trust-the-process handshake. In deos a surface is the authority: a named, typed bundle of cap-gated affordances. An agent sees exactly the affordances its held capabilities authorize — progressive enhancement becomes progressive attenuation — and an unauthorized action is refused in-band by the proven required ⊆ held gate, not by app good behaviour. Anti-cheat is free, because the cheat is unrepresentable.
A screenshot you can re-open, live
A deos snapshot is not a dead pixel grid. It is a paused camera on a witnessed scene: it embeds a sturdyref behind a membrane, so opening the image re-attaches a per-viewer, attenuated, liveness-typed interactive surface. Two people open "the same" screenshot and rehydrate two different views — each confined to what their capabilities authorize. The unit you shared was never the pixels; it was the revocable right to renegotiate the connection. This is the genuine dregg-only novelty.
One capability, local to global
An seL4 capability and a dregg capability are the same abstraction at two points on a distance parameter. A local Robigalia install is a first-class dregg deployment with strong properties — immediate revocation, synchronous commit, consistent checkpoint — because at n=1 the distributed bounds collapse to local ones. The moment a program reaches the network it flows into native distributed dregg with no seam: same handle, same attenuate/delegate/invoke, the bounds just relax along n. The firmament is that gradation made real.
Cells, turns, receipts
Everything above rests on three objects. Escrows, councils, name registries, budgets, windows, games — all of it is built from these, and inherits their guarantees.
Where state lives, behind its own rules
A cell holds balances, capabilities, and named slots — plus a program: a predicate over its own transitions that the substrate enforces on every change. Nothing is ownerless. A cell changes only under its own program, only by an authorized actor; a turn touching one cell leaves every other cell untouched. "A budget that cannot be exceeded" is just a cell whose program says so.
Actions that must show their warrant
A turn is an atomic batch of actions. Each action presents a capability — a token naming what it may touch and how, narrowable but never amplifiable — and must discharge every guard in scope. The whole turn commits or none of it does. A forged credential on any leg rejects the entire turn. The lineage: macaroons → biscuit-Datalog → the proof system.
A light client cannot be fooled
The point of the proofs is not a badge — it is that a stranger running the smallest possible check learns the truth about a whole history, and a server that lies is caught. The foil has a name: the pale ghost, a server that presents a plausible state it never legitimately produced.
ARGUS — the circuit witnesses correct evolution
The proof does not merely attest "some valid state exists." It witnesses the protocol's correct evolution: every turn executed correctly, in the right order, with no drop, insert, or reorder, folding into one root. A light client checks only verify(root) — re-witnessing nothing — and learns Authority, Conservation, Integrity, and Freshness for the entire history. A tampered aggregate cannot bind: there is no verifying proof of a forged chain.
The executor is a memory program
"The receipt binds the whole post-state" is a constructive fact, not a slogan. Every kernel field and the receipt log project onto one domain-tagged universal address space, and the executor's post-state equals the fold of the verb's emitted memory trace over the pre-state — so nothing is left off the map. Tamper with any field and the honest commitment recovers the difference. This is integrity's load-bearing leg.
PATH-PRESERVE — every finalized turn stays proven
A finalized turn does not lose its proof when the history grows past it. The aggregate's seam tooth pins each step to the next (new_root[i] = old_root[i+1]), so the whole chain is bound, and the proof rotation keeps the cost down without breaking the binding. Circuits are emitted from proved Lean modules — Rust authors zero constraints — so the circuit that proves and the executor that runs cannot disagree about what a turn did.
What is proven — in human terms
These cards are not marketing copy: they are embedded at build time from a catalog
generated out of Dregg2/AssuranceCase.lean, where each guarantee names an
apex theorem machine-pinned to the Lean kernel's three axioms. Five guarantees to a light
client — Authority, Conservation, Integrity, Freshness, Unfoolability —
plus the running entry: Authority, Conservation and Integrity hold over
what the node actually runs, because the running system calls the proved
function. This page cannot say more than the proofs do — the build fails if it tries.
A AUTHORITY
Every state change is justified by an unforgeable, non-amplified, fresh token chain.
apex: authority_guarantee · 19 axiom pins
floor: ed25519 (signature on the handoff), HMAC (caveat-chain tags), Poseidon2-CR (in-circuit cap-root openings). No trusted "this was authorized" premise survives.
B CONSERVATION
Per asset, the resource sum is IDENTICALLY ZERO — on every reachable state, always.
apex: conservation_guarantee · 23 axiom pins
floor: NONE beyond integer arithmetic. Conservation is a kernel theorem; the only crypto that touches it is Pedersen (DLog) IF values are committed rather than cleartext, and the case proves committed = cleartext via Spec.committed_iff_cleartext. DEPLOYMENT CORRESPONDENCE (named, not closed — the theorem's hypothesis vs the running node): reachable_total_zero quantifies over states reachable from a VALUE-EMPTY genesis (GenesisState: bal ≡ 0; live cells may pre-exist, value may not). Two deployed paths are TODAY outside that hypothesis, and this case does not claim them: 1. **Devnet genesis seeding** — node/src/genesis.rs mints the faucet (1,000,000) and demo agents (alice/bob/carol) with positive balances and NO issuer well carrying −supply, so the deployed genesis is not value-empty in the model's sense. The W1-faithful fix is to seed via issuer-moves from a genesis issuer cell (then genesis Σ=0 holds by construction). 2. **The legacy atomic-path fee epilogue** — turn/src/executor/atomic.rs (the fee deduct in execute_atomic) debits atomic_turn.fee from the agent with no crediting move: a burn OUTSIDE the issuer-move discipline (DREGG3 staged item: fees become moves to wells). Until both are reshaped, conservation_guarantee is a theorem about the kernel the node RUNS (execFullTurnA — every committed transaction preserves Σ exactly) but the deployed CHAIN's Σ is offset by its genesis seed and decremented by legacy fees. Reported here so the spec SAYS what it covers; the closure lane is the genesis/fee reshape, not a caveat to carry.
C INTEGRITY
A receipt binds the WHOLE post-state; a tampered input is rejected.
apex: integrity_guarantee · 24 axiom pins
floor: Poseidon2-permutation-CR (the recStateCommit/cellCommit/stateCommit injectivity portals reduce to it; the MMR discharge rests on the SAME Poseidon2SpongeCR). A second pre-image would be the only way to forge a receipt for a different state; that is exactly the CR assumption.
D FRESHNESS
No replay / double-spend; a committed spend's nullifier was fresh; revocation at finality.
apex: freshness_guarantee · 12 axiom pins
floor: Poseidon2-CR (the nullifier-set sorted-tree root openings). PostGSTProgress for the revocation-at-finality leg (consensus terminates after GST). KNOWN RESIDUAL (named, out-of-model): the node's MCP gateway binds biscuit-cap temporal caveats to the live attested consensus height (node/src/mcp.rs McpCapContext.block_height) — the height-expiry leg is real — but consults NO revocation registry for MCP-issued biscuit caps (the gateway's own doc names this). An MCP cap dies only by expiry caveat, never by explicit revocation, until a revocation feed is wired. That path is OUTSIDE this guarantee's statement; it is listed here so the case says so rather than implying coverage.
E UNFOOLABILITY
A light client verifying a Q-chain learns A–D for the WHOLE history; re-witnessing nothing.
apex: unfoolability_guarantee · 22 axiom pins
floor: FRI / STARK soundness (EngineSound.recursive_sound, the ONE recursion obligation), Poseidon2-CR (recStateCommit binds the seam roots), ed25519 (strand-block signatures), PostGSTProgress (a FINALIZED — not merely valid — chain, via the finality-cert leg).
R THE RUNNING ENTRY (A∧B∧C hold over what the node actually runs)
The five guarantees above are stated over the abstract kernel: the List Auth attenuation lattice (A), the multi-asset ledger recTransferBal (B), the Argus term IR (C/D), the aggregation fold (E). The honest question ember keeps pressing is: *do those guarantees hold over the executor the deployed node INVOKES* — execFullForestG, the body behind the dregg_exec_full_forest_auth FFI export (Exec.FFI), the one produce_via_lean / lean_shadow call? They do, and this section proves it in ONE statement rather than leaving it as a reader's inference.
apex: running_entry_sound · 8 axiom pins
floor: unchanged from A–C.
#assert_axioms pins,
generated from Dregg2/AssuranceCase.lean. Every pinned theorem rests on the Lean kernel
triple {propext, Classical.choice, Quot.sound} and nothing else.The guarantees are unconditional in the Lean-kernel sense modulo a small, explicit set of cryptographic assumptions that enter as typed hypotheses, never as axioms — and the present deployment seams (a single-node devnet; per-turn proving staged, not yet auto-attached; the verified producer covering a named subset of effects) are stated, not hidden. The full delimitation is the Verify page, rung 7 of the protocol docs, and the assurance specification.
Apps where the security property is the feature
A deos app is a set of cells exposing affordances, rendered as surfaces, over durable verified state, reached by agents (human or AI), distributed across the web-of-cells, and rehydratable. The framework wires those layers; the builder writes affordances and a surface. The sharpest exemplar makes a game mechanic into a security property.
You provably cannot peek
In a normal game, what you can see is a rendering trick the client could cheat. In deos, fog of war is the membrane's per-viewer projection, backed by a real proof obligation: to see a side's tiles you must produce a proof the registry verifies, and a player holding only its own secret cannot construct the enemy's vision. Terrain occludes line-of-sight; moves and objective-captures are cap-gated verified turns; AI agents play to a decision through the same gate a human uses. Secure by construction, and you can play it.
Verified durable state — your node is your Postgres
A PostgreSQL extension where reads are free SQL and writes are verified turns. The commit log projects into queryable tables (cells, receipts, caps, the blocklace); a row's policy reads dregg_admits(token, 'read', id, …) — the same decision the kernel makes, from the same capability token. Attenuation, offline delegation, time-boxing, caveats, revocation — the discipline SQL row-level-security structurally cannot express, presented once per session.
Real systems on one verified path
A line of credit is an attenuated capability (the executor refuses an over-line draw). An encrypted group is one whose membership is physics (a remove(member) darkens ciphertext and capabilities in one atomic turn). An asynchronous handoff delivers a sealed turn-intent to an offline peer with a checkable custody receipt. Each is an SDK noun riding the same verified executor — no new executor entry, each an executable test you can read.
Touch it in five minutes
Touch the live node — no install, just curl. The
public devnet is the same node the repo builds. Ask it what it is, then faucet
yourself a cell and read it back:
curl -s https://devnet.dregg.fg-goose.online/status
# → healthy, solo federation, state_producer:"lean", full_turn_proving:true
CELL=$(python3 -c "import secrets;print(secrets.token_hex(32))")
curl -s -X POST https://devnet.dregg.fg-goose.online/api/faucet \
-H 'content-type: application/json' -d "{\"recipient\":\"$CELL\",\"amount\":1000}"
curl -s https://devnet.dregg.fg-goose.online/api/cell/$CELLThe status line is the honest contract: it names that the state
producer is Lean — the proved kernel itself, not a re-implementation.
Try to break a turn in your browser. The playground runs the real executor as WebAssembly — no server. Stage a transfer, run it, then overdraw a balance or replay a spent authorization and watch the substrate reject you. The rejection is the product. Then open the explorer on the live federation and scrub any cell's history backward — time travel is just reading receipts, because the receipts are the history.
Boot the kernel on seL4. Real Rust protection-domains come up on the seL4 microkernel in QEMU, including a real cryptographic STARK proved and verified on-device:
git clone https://github.com/emberian/dregg && cd dregg/sel4
./setup.sh # Microkit SDK + toolchain (native macOS, no Docker)
make run-stark # a REAL on-device STARK: prove, verify, reject a tampered proofThat is the verified heart organ running on the verified microkernel. The firmament page walks the boot ladder and the local-to-global capability gradation.
Decide whether to trust it. Objects in the explorer carry a verification status, never hand-set. The Verify page states exactly what is proven, the eight-carrier assumption floor it rests on, and the honest deployment seams — then shows you how to check the proofs yourself by building the Lean development from the repo. The longer evaluation guide is the "should I trust it, and why" companion.
Three ways down
deos · the agentic userlayer
Windows-as-capabilities, htmx-on-crack affordances, the rehydratable frustum-snapshot, the fog-of-war forcing function, and the verified-desktop crown — the Lean theorems that say the desktop adds no trust. Read deos →
The firmament · dregg-on-seL4
One capability across a distance parameter, the n=1 collapse to strong-local properties, the five-PD topology, what boots today, and verified durable state with pg-dregg. Read the firmament →
The kernel, in seven rungs
One sentence unfolding outward: the turn, the four substances and eight verbs, guards, receipts, the light client, userspace and the polis, the trust boundary. Prose, then theorems, then a live surface. Climb the ladder →