Deployment

What shipping this repository actually means today: the release gate, the artifact that ships, and what a production deployment would still need. This is intentionally short and honest — most of this repo is proving infrastructure, not a deployed service.

Releases

Cutting a tag (v*) triggers .github/workflows/release.yml:

1. The gate — fmt, clippy, schema validation, and the full workspace test suite must pass, then a release build (cargo build --release).
2. The artifact — the crucible-prover CLI binary is attached to the tag’s GitHub release (creating the release object when a pushed tag has none). Only tags whose tree passes the whole gate ship a binary.

The CLI is the deployment surface: circuits, artifact pinning, proving, verification, vector judging, benchmarking (docs/cli.md). It is orchestration only; it performs no key management and holds no secrets.

What a checkout carries

• Pinned artifacts — artifacts/circuits/<op>/ bytecode + manifests are committed and strict-loaded before any proving (docs/artifacts.md).
• Verification keys — written at runtime into the VK store (artifacts/verification-keys/, created on demand by prove / verify). Keys are derived by bb during proving and resolved by id during verification; they are not committed today.
• Fixtures and vectors — committed catalog + envelope material used by tests and tooling, not shipped to end users.

Deployed on testnet

An UltraHonk verifier contract is live on Stellar testnet, and this repository verifies proofs against it:

The contract is Nethermind’s audited rs-soroban-ultrahonk wrapper, not code from this repository. Reimplementing UltraHonk verification on-chain would replace audited cryptography with unaudited code for no gain, so this repository owns the integration instead: the wire payload, the verifier service registration, the real LiveSorobanClient, and the agreement tests (docs/soroban-verification.md).

Verify it from a checkout, with no key and no fee:

CRUCIBLE_SOROBAN_LIVE=1 cargo test -p crucible-soroban-adapter --test live

That suite submits the committed on-chain fixture to the deployed contract through Soroban RPC simulation, and asserts the pristine proof is accepted while a tampered one is rejected. Simulation is a real execution of the contract and is the definitive verdict for a read-only call; it just does not settle on-chain.

Production gaps (by design)

• The on-chain path is testnet-only, and the verifier is a third party’s. Mainnet deployment needs a mainnet-funded account and an audited key-management story. Stellar labels Confidential Tokens a developer preview — the contracts and verifier are under audit and not intended for production use (docs/testnet.md).
• Only the transfer circuit has on-chain fixtures. Register, deposit, merge and withdraw follow the same recipe when on-chain verification is needed for them, so the live path currently proves the seam is correct rather than covering every circuit.
• The local and on-chain toolchains emit different proof layouts. The contract is pinned to bb 0.87.0 (456-word proofs, 1,760-byte VK) while the local backend tracks bb 6.0.0-nightly (458 words, 3,680 bytes). The committed on-chain fixture is produced on the contract’s pin, so the two formats are each tested on their own terms rather than assumed interchangeable (docs/soroban-verification.md).
• The exact circuit scheme is scaffold-shaped until aligned with the Confidential Token circuit specification (docs/circuit-model.md); artifacts, keys, and proofs produced before that alignment must not be treated as final.
• No transaction-submitting testnet automation. Proof verification runs over read-only RPC simulation, so nothing in ordinary CI signs or submits a transaction, and the scenario layer’s live-network adapter stays opt-in and out of the default pipeline (docs/testnet.md).

Related

• docs/reproducibility.md — the pins that make a release reproducible.
• docs/compatibility.md — why a release is a bundle of agreeing versions, not a single binary.