Craftec Docs
ZephCraft

Registry & Governance

The durable owner-signed name registry, and the multisig chain that governs protocol policy

The head registry

The registry is the network's coordination layer: a durable map of heads — program names, database roots, and durability manifests — (owner, name) → (cid, version). Its job is to make resolution work with the owner offline, without trusting any committee.

Authority: your signature, nothing else

The registry is an open, owner-signed CRDT: entries are partitioned by owner, ordered by strictly-increasing version, merged last-writer-wins. Your Ed25519 signature is the sole write authority for your names — there is no attestation, no committee, no quorum, because an open registry converges by construction: nobody can forge your entry without your key, and your own concurrent entries order by version. Validation (signature + name length) is enforced natively on the write path.

Sharded, elected, replicated

The keyspace splits into 2^bits shards — and bits is a governed value, so the shard count can grow or shrink cluster-wide by a governance decision. Each shard has a stable set of K=3 replica nodes (chosen by deterministic hashing over the converged census — every node computes the same answer) with the writer role rotating among them every 30 seconds. Writes push row-level updates to the replicas; a newly-promoted writer merges its peers' state before serving. If a writer is unreachable, resolution falls through to the replicas — an owner's names resolve even with the owner and the current writer down (validated live).

Online resharding

Changing the shard count is a live operation: governance propagates the new value, each node re-buckets the shard state it holds into the new layout (a shard's keys move only to its two children), keeps sweeping for stragglers during a drain window, then garbage-collects the old layout. Proven on the live cluster in both directions — grow and shrink — with every name resolvable throughout.

Per-shard SQL

Each shard's state is itself a small CraftSQL database: registering a name is a single-row upsert, resolving is an indexed SELECT, and replication ships one row — not the whole shard. Writes and reads stay O(1) as the registry grows.

Governance

Protocol-level change — which WASM is canonical for a network program, protocol config values, the governor set itself — is a k-of-n governor multisig over a self-verifying chain. Every node folds the chain from genesis and derives the identical result; a chain containing even one invalid approval is rejected whole, and nodes adopt the longest valid chain sharing their genesis. No gossip protocol, no trust in any single node.

Two registries derive from the chain as pure replays:

  • Program registry — governed WASM programs (SetProgram). Deliberately empty at genesis: the network currently runs no governed WASM program, because the head registry's validation is a hard invariant (mechanism), not swappable policy.
  • Config registry — governed integers (SetConfig), e.g. the registry's shard count. Values are clamped at the consumer, so a bad value can't brick a node.

The dividing line — the minimal-kernel principle — governs everything: mechanism lives in the binary; policy lives in governed WASM with a native default that can never brick the network. The test: "would we ever change this without shipping a new binary?"

On this page