When to use this
- You’re a coordinator running a training run and need on-chain settlement for rollout rewards.
- You’re a worker participating in a run and need to submit batches.
- You’re building tooling around Crucible (a dashboard, a stake leaderboard, etc.).
Prerequisites
- A funded coordinator DID with the run’s reward pool ready to escrow.
- A signed-off model configuration that all participants agree on (hosted on Weave/IPFS).
Recipe (coordinator side)
Commit a rollout batch
Each batch is a Merkle root over the worker’s off-chain rollout records. The chain stores the root and the batch’s claimed reward budget; the records themselves stay off-chain.Same shape via CLI:
Attest rewards
Attesters review off-chain rollout records and sign a reward attestation that aligns or revises the claimed reward.The chain pays
final_reward from the escrow when the attestation lands.Publish weights
When a run produces a checkpointable weight artifact, publish its content address and commitment.
Slashing dishonest workers
If a worker submits a rollout batch whose records do not match the committed Merkle root, anyone can submitCrucibleSlash with the evidence:
sigil-cli crucible slash for the CLI form.
Inspecting state
Common errors
| Symptom | Cause | Fix |
|---|---|---|
run already closed | Tried to commit to a closed run | Open a new run; closed runs are immutable |
worker not in allowlist | Worker is not eligible | Check the run’s worker policy |
reward exceeds escrow remainder | Cumulative attested rewards > escrow | Top up via CrucibleDeposit or attest a lower amount |
weights commitment mismatch | weights_root ≠ BLAKE3 of file at weights_cid | Recompute the root before publishing |
See also
- Primitive: Crucible training
- CLI reference: crucible — every command exposed by
sigil-cli. - Cookbook: Mint an NFT — for issuing checkpoint NFTs that reference weight CIDs.