Crucible

Deterministic simulation, UltraHonk proving, and conformance stress-testing for Stellar confidential tokens — built as three repositories that compile each other.

Crucible exists to make one claim checkable rather than assumed: what a Confidential Token transaction does locally is what it does on-chain. It does that by putting a deterministic execution model, a real proving backend, and a conformance harness around the same operations, then testing that they agree.

Verified on testnet, today

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

Reproduce 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 a committed proof 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; it simply does not settle on-chain.

The contract is Nethermind’s audited rs-soroban-ultrahonk wrapper, not code from this project. Reimplementing UltraHonk verification on-chain would replace audited cryptography with unaudited code, so the project owns the integration instead. See the deployment record.

The three repositories

The graph is acyclic and one-way. Every dependency edge is pinned to an immutable revision rather than a version range, and the pinned set is recorded and enforced by a test — see pinning.

Status, stated precisely

This project distinguishes what it has verified from what it has decided.

Verified

• On-chain proof verification against a live testnet contract, including rejection of a tampered proof (the gated suite above).
• The simulation layer’s determinism: state roots and fixture outcomes are pinned, and the hashing construction is pinned by known-answer vectors.
• Artifact integrity: manifests, checksums, and loader rejection paths.

Not yet, and not claimed

• The circuit scheme is scaffold-shaped until aligned with the Confidential Token circuit specification. Artifacts, keys, and proofs produced before that alignment must not be treated as final.
• Stellar labels Confidential Tokens a developer preview; the contracts and verifier are under audit and not intended for production use.
• Only the transfer circuit has on-chain fixtures. Register, deposit, merge and withdraw follow the same recipe when needed.
• The local and on-chain toolchains emit different proof layouts (bb 6.0.0-nightly locally, bb 0.87.0 on the contract pin), so the two formats are each tested on their own terms rather than assumed interchangeable.
• No independent cryptographic audit has been performed.

Where to start

• How it fits together — architecture
• The verification seam — Soroban verification
• Security guarantees — guarantees and mechanisms, threat model
• The execution model — simulator model, deterministic execution
• What the harness checks — conformance

About this site

Every page under Simulator, Prover, and Stress-test is generated at build time from the three source repositories — this site is a view, never a second copy. Each build records the exact revision it rendered, listed under Built from, so any page can be traced back to the commit that produced it.