Security

Scope

Crucible Simulator is a deterministic testing environment. It contains no production secrets, signs nothing real, and holds no real funds. Its “security” concerns are about correctness of the simulation and the integrity of the testing pipeline — a flaw here could make crucible-prover or crucible-scenarios certify or rely on behavior that does not hold in production.

Threat model

• State corruption — an operation sequence that leaves partial, inconsistent, or double-spent state. Countermeasures: audited StateTransitions (mismatched records fail with StateCorruption), rollback scopes, and the invariant suite.
• Commitment reuse / replay — spending the same commitment twice. Countermeasures: Consumed status + nullifier registry; replaying a consumed deposit fails with ConsumedCommitment. Tested as a permanent regression.
• Fixture poisoning — malformed or version-skewed fixtures. Loader version-checks every fixture; the whole corpus replays in CI.
• Nondeterministic execution — entropy, wall-clock, iteration-order, or float leakage would break reproducibility and could hide bugs. See docs/deterministic-execution.md; the determinism suite compares full transcripts across runs.
• Rollback failure — a failed operation leaving partial state or skipped sequence numbers. TransactionScope restores bit-identical state; tested.
• Privacy leakage — confidential values appearing in observable output. Events are value-free by design; regression tests scan the event stream. Note this simulator stores plaintext values as private simulation state; it is a testing oracle, never a production data store.
• Incorrect proof-provider handling — flows treat proofs as opaque references and never interpret them; without a provider (or with a rejecting one) transfers fail cleanly with InvalidProof.
• Local/testnet divergence — the local simulator never requires network access; a future testnet adapter must be optional and explicit.

Reporting

If you find a flaw that could corrupt simulated state, break determinism, permit double-spending in the model, or leak private simulation state:

1. Do not open a public issue for exploitable findings.
2. Open a private report, or email the maintainers with full repro: fixture file (or environment + seed + operation sequence) and the observed vs expected behavior.
3. Reference the security checklist above so the report can be triaged fast.

Non-sensitive findings and design concerns are welcome as normal issues — tag them security so they get the review checklist.