A turn is the exercise of an attenuable proof-carrying token over owned state, leaving a verifiable receipt.

Six words, and what they mean

The model is small. State lives in cells; capabilities say what may touch it; a turn is one atomic change; effects are the fixed vocabulary of changes a turn can make; a proof witnesses that the change obeyed the rules; a receipt is the record a third party can verify without trusting you.

Verify a whole history · re-executing nothing

A finalized history is a chain of turns: each turn's after-state is the next one's before-state. A producer folds the whole chain into one succinct recursive STARK. Your browser tab verifies that single proof: no re-execution, no re-hashing, no walk of the chain. If it verifies, every folded turn executed correctly, in order, from genesis to the final root. This is the in-browser recursive-STARK verification, and it runs right here.

The trust anchor is your configuration, held separately, never read off the artifact under verification. Tamper one hex digit of the anchor and the proof is refused, not laundered. This is the executable counterpart of the Lean theorem light_client_verifies_whole_history.

Everything here is live, most of it in your tab

The surfaces in the first group below load a verified executor compiled to WebAssembly and run it in your browser. Click an affordance and you fire a real cap-gated turn against an in-tab ledger; the bound fields re-paint from the committed state. No install, no account, no server.

client-side WebAssembly · real verified turns · nothing leaves your machine

Three surfaces run server-side, on a devnet box, served over the public web: you play against a real executor there rather than one in your tab. The rule enforcement is the same (an illegal move is refused and commits nothing), and two limits are named on the surfaces themselves: a run is checked by deterministic replay re-execution (a stranger re-runs it), not by checking a STARK, and a web player is a self-asserted cookie, not a signature.

hosted devnet · real verified turns · replay-checked, not proof-checked

Call it from your own code

The shape is the same in every language: an identity makes a turn, signs it, and submits it; you get back a receipt. An unauthorized act is not expressible on the public surface. Every action carries a real signature over the canonical, federation-bound message.

npm install @dregg/sdk

import { AgentRuntime, NodeClient, profiles } from "@dregg/sdk";

// 1. a named identity (the same store as the `dregg id` CLI)
const identity = profiles.loadActive() ?? (profiles.create("me"), profiles.load("me"));

// 2. bind to a node (your local dev node, or a remote node + its operator token)
const node = new NodeClient("http://localhost:8421");
const runtime = new AgentRuntime(identity, node);

// 3. identity -> turn -> sign -> submit -> receipt
const receipt = await runtime.turn()
  .transfer({ to: "cell:...", amount: 10n })
  .sign()
  .submit();

console.log(receipt.committed, receipt.postState);

pip install dregg

from dregg import Identity, NodeClient

identity = Identity.load_active() or Identity.create("me")
node = NodeClient("http://localhost:8421")

receipt = (
    node.turn(identity)
        .transfer(to="cell:...", amount=10)
        .sign()
        .submit()
)
print(receipt.committed, receipt.post_state)

git clone https://github.com/emberian/dregg
cd dregg/pg-dregg
cargo run --example three_pillars

The guarantees, stated plainly

What you can build on it

A host that cannot tamper with what it serves

Publish a minisite and you commit its blake3 hash to your cell, on-chain, in one cap-gated receipted turn. <name>.dregg.works then serves the bytes, but the host has no way to change them. Every served page carries a verify badge: your browser re-hashes the bytes it received and checks them against the commitment fetched from the node. ✓ match, or ✗ tampered, and you don't have to take the host's word for either.