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.

The committee is the point Building

Nothing is certified by a guild. It is certified by a committee: the set of guilds a build job convenes, each holding exactly one seat. The seats are drawn on-chain from the epoch’s active guild set with verifiable randomness, weighted between stake and a flat share so that small guilds are drawn too, and topped up until the committee’s pooled stake clears the job’s requirement. A guild is drawn once or not at all — it can never hold two seats of the same job, and a second member of an already-seated guild adds nothing. Drawing is the default, not the only way to seat a committee: a project can pin its committee to a fixed set of guilds it has chosen, or constrain the draw to guilds with declared properties — the floor of independent seats holds either way (more under committees to order).

You don’t build for the network; you build for your guild’s seat. A compute member — anyone with hardware who has bound a runner identity to a guild — accepts the seat on the guild’s behalf, posting a bet from the guild’s operational treasury, and is the one who must deliver. One runner identity belongs to one guild per epoch, one account administers at most one guild, and each guild has exactly one seat per committee, so “three independent reproductions” means three guilds, three machines, three parties with something to lose — never one operator wearing three hats.

Stake is what makes a guild eligible Building

A guild is a staking pool, modeled on Walrus staking: delegators back the pool, epochs advance permissionlessly, and commission changes only take effect two epochs later so delegators can exit at the old rate. Stake is not a claim about a build — it is what puts a guild into the active set a committee can be drawn from, what weighs its seat when convergence is evaluated, and what is slashed if one of its members double-signs. The bet a member posts to take a seat comes from the guild’s own treasury; delegator principal is never at risk for a missed window.

Members earn budget shares and emissions for the seats they fill. 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 equally across the committee’s seats — at default governance settings, at least three distinct guilds, so no single guild can ever certify a build alone. Selection is auditable from on-chain state, and deliberately mixes large and small pools so small guilds get real work.

The member who takes a seat posts the guild’s 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 committee has fulfilled the job. Together with a passed security workflow over the dependencies, that is what the Ika dWallet checks before it contributes its half of the release signature; the author’s half closes the release, and only then do attestations and signature land on Sui, artifacts on Walrus, NARs in 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 committee doesn’t have to be drawn from the whole network. A project can fix its committee outright — the same vetted guilds on every build — or constrain the draw by declared properties: only guilds in a given jurisdiction, only guilds operating hardened and audited environments, only guilds your organization has already approved. Pinning and properties narrow which guilds qualify — never how many. The floor of independent seats 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

A release signature is an Ika dWallet signature — threshold ECDSA held by MPC, never by one machine — and it is produced in two halves. The Ika network contributes its share only after verifying, on-chain, that the committee fulfilled the build job, that the revealed digests match, and that the security workflow over the dependencies succeeded. The other share is the author’s: the flake owner signs last, and that closes the release. At publish time the owner chooses the share mode — AUTHOR_SHARE_HELD keeps that closing share in the maintainer’s hands, making them the ultimate gate on what constitutes a release; FULLY_DAO waives the veto. Without both halves, 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.