Security model

Crucible Simulator is a testing environment, not a production system. It models Stellar Confidential Token flows so their behavior can be exercised deterministically. Its security posture follows from that role, and the boundaries are documented so nobody mistakes the simulation for the real thing.

What this repository is and is not

The privacy boundary

The single most important boundary in the codebase is between private simulation state and publicly observable output.

• Private simulation state — commitment values, account balances, confidential heads — is reachable only through explicitly labeled testing APIs (inspect_private_balance, inspect_private_head) and the state store itself. It is internal.
• Observable output — events, transaction records, proofs, published fixtures — is value-free by construction. Event carries no amounts; Transaction records inputs/outputs by commitment ID, not value.

The rule for contributors: never write a value or a commitment value into an event, a proof, or any serialized output intended for publication. Tests may assert on private state; output may not leak it.

Trust assumptions in the simulation

Because this is a simulator, several things that production must resist are assumed safe and are the responsibility of the real implementation:

1. Synthetic identities are trusted. Authorizations are synthesized for the acting account; there is no key management. Unauthorized operations are still rejected (authorization validation exists and is tested), but the identity layer itself is simulated.
2. The mock proof provider always proves. MockProofProvider attests validity deterministically. The validation pipeline still requires a proof reference for confidential transfers, so a missing or invalid proof is rejected — but a real provider must do the actual cryptographic work.
3. Hashes are not adversarial-strength secrets. SHA-256 with domain separation gives deterministic, collision-resistant digests for testing purposes. Nothing here is a commitment scheme safe against a determined attacker; production uses the real Confidential Token primitives.
4. Internal values are visible to the harness by design. That is the point of a simulator. It must never be confused with production confidentiality.

Guarantees the simulator does provide

Within its role, the simulator is strict:

• Determinism — same configuration + state + operations + seed ⇒ same result. No system entropy, no hash-map iteration order, no platform dependencies (see docs/deterministic-execution.md).
• Atomicity — a failed operation rolls back completely; partial state is impossible (see docs/state-model.md).
• Replay protection — consumed commitments are nullified and can never be spent again; double-spend replays fail with consumed_commitment.
• Auditability — every state change is an explicit, recorded transition between roots; corruption is detectable by replaying.

Reporting vulnerabilities

See SECURITY.md for the process. Because this repository never touches real assets, the main reportable classes are correctness bugs (state corruption, nondeterminism, rollback failures) and leaks of private simulation state into observable output.