First real protocol harnessed — cf-invariants-jito on Crucible

The gap

Toy vaults prove the rails. A real upstream program is the next test.

The previous CaliperForge build, cf-invariants-anchor, stood up a generic invariant-authoring scaffold on top of Crucible (Asymmetric Research's LibAFL + LiteSVM coverage-guided fuzzer for Anchor) and proved it green against a hand-authored vault_ref / vault_ref_planted pair. That established the seam. It did not establish that the seam holds against an upstream program written by someone else, with real account layouts, real CPI patterns, and a real on-chain footprint.

cf-invariants-jito is the answer to that. The target is the Jito Foundation tip-distribution program — the on-chain piece of the Jito MEV-redistribution stack on Solana. After a Jito-Solana validator earns MEV tips in an epoch, the program holds those tips in a TipDistributionAccount and, once a Merkle root over per-claimant amounts is uploaded, lets each claimant call claim with a Merkle proof to receive their share. Apache-2.0, real economic surface, real claim sequencing. A natural target for invariant fuzzing.

Port distance

anchor-lang 0.31.1 to 1.0.1 is not a free move.

The upstream Jito tip-distribution program pins anchor-lang 0.31.1. Crucible v0.2.0's workspace pins anchor-lang 1.0.1. Those are not the same macro expansion. To run the program under Crucible at all, the program has to be ported across the 0.31 → 1.0 boundary, and that boundary touches account validation, error types, CpiContext shape, and the IDL surface that Crucible's calldata generator reads. The NOTICE file in the repo preserves Jito's upstream Apache-2.0 attribution and itemizes the modifications.

The port lives at programs/tip-distribution in the repo. The production Jito program is not modified by this harness — the port exists only so Crucible can drive it. The on-chain footprint of Jito tip-distribution stays whatever Jito Foundation deploys.

What it tests

Four invariant classes. Four planted-bug twins. One clean reference.

The harness runs four invariant classes. Each runs as a Crucible fuzz fixture against (a) the clean reference (jito_tipdist_ref) and (b) a single-site planted-bug twin. The planted-bug twins are one-site-deep regressions authored to verify that the corresponding invariant class fires; they are not claims about the production Jito program. The classes:

claim_amount_conservation — invariant_claim_amount_conservation. The lamports debited from the TipDistributionAccount on a successful claim equal the lamports credited to the claimant. Planted-bug site: programs/tip-distribution/src/state.rs::transfer_lamports — off-by-one debit.
no_double_claim — invariant_no_double_claim. For a given (TDA, claimant) pair, at most one successful claim ever fires. Planted-bug site: programs/tip-distribution/src/lib.rs::claim runtime gate — replay accepted.
merkle_authority — invariant_merkle_proof_required. A claim only succeeds if the supplied proof verifies against the uploaded Merkle root. Planted-bug site: programs/tip-distribution/src/merkle_proof.rs::verify — early-accept short-circuit.
admin_gating — invariant_update_config_requires_authority. update_config only succeeds when signed by the current config authority. Planted-bug site: programs/tip-distribution/src/lib.rs::update_config — authority check dropped.

The fuzz-fixture source for each invariant lives once under references/jito_tipdist_ref/fuzz/<inv>/src/main.rs. CI copies the same source into each planted variant before the run, so the only difference between a clean run and its planted-bug run is the .so binary loaded into LiteSVM. Same harness, same fuzz seed surface, different program under test.

What's verifiable today

Commit e683c5a. CI green. Four classes, eight runs, the right outcome on each.

The CI workflow runs a matrix of (class × variant) on every push: builds the workspace under cargo check --workspace --locked, builds the cf-invariants-jito port and all five reference variants via cargo build-sbf --tools-version v1.52, builds Crucible v0.2.0 from source (cargo install --path crates/crucible-fuzz-cli --locked), then runs each invariant under crucible run with a 30-second timeout against the clean reference and the class-matching planted twin. CI asserts:

jito_tipdist_ref: 0 violations across all four invariants.
jito_tipdist_ref_planted_*: ≥1 violation on the matching invariant within the 30-second timeout.

That assertion held on commit e683c5a, the publication commit. The CI badge on the repo README is the source of truth from here on — if it is red, the harness is broken.

Pinned toolchain (the version authority is the README's "Pinned toolchain" section, not a downstream pin file): Rust stable, anchor-lang 1.0.1 (matches Crucible v0.2.0's workspace), Crucible v0.2.0 built from source, Anza / Solana CLI v2.1.21 for cargo-build-sbf, Solana platform-tools v1.52 (Crucible v0.2.0 deps require edition2024, which earlier platform-tools' rustc cannot build). The fuzz Cargo.tomls reference Crucible via path dep at ../../../../../crucible/...; CI clones Crucible v0.2.0 to that sibling path before the harness step, and local reproduction does the same. The sequence is documented in the "Reproduce from a fresh clone" section of the repo README.

Why this artifact

Specialization velocity, expressed as an existence proof.

CaliperForge's edge is not new fuzzing engines. The engines doing the work — snforge on Cairo, Crucible on Solana / Anchor — are run by other teams and we do not compete with them on coverage. What we are testing is throughput: how quickly the same operator can stand up an invariant-authoring layer against a new VM, against a new real protocol, and get it CI-verified.

The existence proof, as of 2026-06-03, is three points: cf-invariants (Cairo / Starknet / snforge), cf-invariants-anchor (Solana / Anchor scaffold on Crucible, generic vault target), and cf-invariants-jito (Solana / Anchor, a real upstream Jito MEV program). One operator, three CI-green artifacts, two distinct VMs, all within days of each other. The dates are checkable on GitHub, the commits are public, and the CI badges show today's state, not a screenshot from launch.

That is the claim. It is not that this harness covers everything Crucible covers, or that fuzzing Jito has surfaced anything in the production program. The claim is that the authoring layer ports across VMs at the speed shown, and the CI green light is the only evidence that matters.

What this is not

Not a fork. Not an audit. Not proofs.

Three framings the repo README is explicit about, mirrored here so this post does not drift:

Not a fork of Crucible. Crucible is the harness. cf-invariants-jito is a target plus fuzz fixtures that run on top of it. Credit for the LiteSVM execution rails and the IDL-driven fuzzing plumbing belongs to Asymmetric Research. The fuzz Cargo.tomls pull Crucible by path dep; there is no vendored copy.
Not a Jito security audit. Each planted twin is a synthetic single-site regression authored to prove the corresponding invariant class fires. No claim is made about the production Jito tip-distribution program's security from this harness alone. Upstream attribution and the modification log live in the repo's NOTICE file.
Not a formal-verification tool. Randomized invariant fuzzing, not proofs. Crucible's guarantees are coverage-guided exploration within the timeout budget, not exhaustive search.

The repo is at github.com/caliperforge/cf-invariants-jito. Issues and PRs are open. Operator of record on every commit: Michael Moffett.