Guilds & trust circles

Package registries ask you to trust an operator. CI badges ask you to trust a server. Tixim asks you to trust arithmetic: a build is certified when independent, economically committed parties reproduce it byte for byte.

Guilds put stake behind claims Building

A guild is a staking collective, modeled on Walrus staking: delegators back a guild’s pool, epochs advance permissionlessly, and commission changes only take effect two epochs later so delegators can exit at the old rate. One account can administer at most one guild, and one runner identity can build for at most one guild per epoch — so “independent reproductions” are actually independent, never one machine wearing three hats.

Anyone with hardware can join a guild as a compute member: bind your runner identity, build and attest on the guild’s behalf, earn budget shares and emissions. That is how idle machines become useful safely — more on the compute page.

A guild can be anyone Building

Nothing about a guild presumes a datacenter or a legal form. Three friends pooling their homelabs are a guild. A CI provider selling verified build capacity is a guild. A company running its own releases through an internal guild is a guild. They can be public — open for delegation, taking slots from the open job market — or private, visible only to the projects that invited them. The protocol doesn’t care about the org chart; it cares about stake, independence, and byte-identical results.

What a guild runs Building

A guild is an infrastructure collective, not just a pool of stake. The reference deployment — every piece a Nix-packaged service, so standing one up is a flake deploy, not a runbook:

• tix-guild cluster, three nodes — the guild’s own control plane: coordinates slots and bets, runs the guild’s Seal key server for the trust circles that chose it, and signs the guild’s attestations. Three nodes, so the guild itself has no single point of failure.
• Sui API nodes — chain access for the guild’s members and services.
• Sui full node — an independent view of chain state. A guild verifies against its own node; it does not take someone else’s RPC at its word.
• Walrus gateway — reading and writing release artifacts, sealed digests, and NARs.
• Indexer — fast queries over the registry, releases, and events the guild acts on.

Beyond the baseline, a guild can deepen its commitment to the network it serves — each optional service also strengthens the layer the guild depends on:

• Walrus storage node — contribute the storage the artifacts live on.
• Sui validator — help secure the chain that roots everything.
• Ika node — join the MPC network that signs the releases.

A build job, step by step Building

A requester funds a build job and the budget is split across slots — at default governance settings, at least three distinct guilds, so no single guild can ever certify a build alone. Selection is deterministic and auditable from on-chain state, and deliberately mixes large and small pools so small guilds get real work.

Each selected guild posts a bet from its operational treasury (never from delegators’ principal) and must deliver inside a window derived from the package’s real build history. Deliverables are result digests encrypted to the job’s MPC key — blind until everyone has delivered. Then the reveal:

• All digests match — the release publishes: attestations and the signature on Sui, artifacts on Walrus, NARs into the decentralized cache.
• Honest divergence — if the package itself is non-deterministic, that’s the author’s fault: the author pays, no worker is penalized.
• A worker diverges in patterns across projects — reward slashing.
• Double-signing — immediate slash of the guild pool’s principal, shared pro-rata. Active guilds can additionally vote to burn a misbehaving guild’s accrued commission.

Committees to order Horizon

A build job’s guild committee doesn’t have to be drawn from the whole network. Selection can be constrained by declared properties: only guilds in a given jurisdiction, only guilds operating hardened and audited environments, only guilds your organization has already vetted. Properties narrow which guilds qualify — never how many. The floor of independent reproductions stands regardless of how exclusive the committee is.

Combine that with Seal and something rare falls out: a closed-source build pipeline with reproducibility consensus. Sources live in encrypted repositories; the keys release only to the selected committee under an on-chain policy your trust circle enforces; deliverables come back as sealed digests and the artifacts publish encrypted. Whole classes of attack simply lose their surface: no public forge holding your source, no single CI host worth compromising — a tampered builder is exposed by its own divergence — and no vendor account whose takeover hands an attacker your supply chain. Closed source has never had reproducible-build guarantees from infrastructure it doesn’t have to trust. This is that.

The maintainer keeps the last word Building

Source releases are signed by an Ika dWallet — threshold ECDSA held by MPC, never by one machine. At publish time the flake owner chooses the share mode: AUTHOR_SHARE_HELD keeps one share in the maintainer’s hands, making them the ultimate gate on what constitutes a release; FULLY_DAO waives that veto. Without a valid dWallet signature, nothing reaches PUBLISHED.

Keys rotate; history survives. A retired key is never deleted, so old releases stay verifiable. Every key records whether its maintainer share lives in hardware or software custody, and a software key can be marked tainted — permanently, visibly, propagating into the provenance of every release that chains to it. The only cure is rotation. A flake policy can refuse to release on tainted or software-custody keys outright.

Trust circles: your keys, your quorum Building

Secrets in Tixim are gated by Seal — and the access key itself is held by a trust circle: two or more guilds you picked, holding threshold shares, each running its own key server. Releasing the key takes t of n approvals, and every server independently dry-runs the on-chain access policy before serving its share. No single guild can read anything. No fixed key-server company either — custody follows your choice of guilds.

The chain reports circle health — OK, warning at threshold, at-risk below it — so a circle can never silently rot. A guild leaving the network must keep serving shares through a wind-down grace period.

This is the primitive the whole platform leans on, up to and including the horizon goal: clusters where an instance is admitted because a trust circle of guilds verified it — not because a corporation said so.