Security Assurance
Security Invariants
Security invariants are properties that must always hold true regardless of system state, input, or load. Violating an invariant means the system is in an unsafe state. JIL defines, monitors, and enforces 7 categories of invariants.
What Are Security Invariants?
An invariant is a condition that must be true at all times. If an invariant is violated, the system is in a state that should not exist. Invariants serve as a formal specification of "what cannot go wrong" - they define the security boundary of the system.
Each invariant below specifies: the property, why it matters, how it is enforced, and what happens if it is violated.
1. Consensus Invariants
C1: No settlement is finalized without 14-of-20 validator attestations
WhyPrevents single-entity or small-group control of settlement outcomes
EnforcedConsensus protocol rejects proposals with fewer than 14 valid signatures
ViolationSettlement is rejected. Alert triggered. Forensic investigation initiated.
C2: No validator can vote twice on the same settlement proposal
WhyPrevents vote amplification and double-counting
EnforcedConsensus protocol tracks vote nonces per validator per proposal
ViolationDuplicate vote rejected. Validator flagged for anomalous behavior.
C3: Consensus halts if fewer than 10 validators are healthy
WhyPreserves safety over liveness - better to halt than to finalize with weak quorum
EnforcedAdaptive quorum monitor halts settlement processing below threshold
ViolationN/A - invariant is enforced by design. System enters safe halt mode.
2. Transaction Invariants
T1: No settlement can be processed without passing all active policy gates
WhyEnsures compliance enforcement cannot be bypassed
EnforcedPolicy engine evaluates all corridor-specific gates before consensus submission
ViolationSettlement rejected with specific gate failure reason in error receipt
T2: Settlement is atomic - it completes fully or not at all
WhyPrevents partial state, double-spending, or inconsistent balances
EnforcedDatabase transaction wraps entire settlement lifecycle with rollback on failure
ViolationTransaction rolled back. Retry or error receipt issued.
T3: Finalized settlements are immutable
WhyInstitutional counterparties require assurance that receipts cannot be modified
EnforcedLedger does not support UPDATE or DELETE on finalized records. Append-only design.
ViolationStructurally impossible via application layer. Database-level modification would be detected by hash verification.
3. Wallet Invariants
W1: No settlement can be authorized without the user's MPC key shard
WhyGuarantees non-custodial operation - JIL cannot move funds unilaterally
EnforcedMPC 2-of-3 threshold signing requires user shard participation in signing ceremony
ViolationCryptographically impossible - signature is invalid without 2 of 3 shards
W2: Key shards are never combined in a single location
WhyPrevents full key reconstruction by any single party
EnforcedMPC protocol performs distributed signing without key reconstruction
ViolationProtocol-level prevention - shards never leave their storage domain during signing
4. Bridge Invariants
B1: Wrapped tokens are only minted after deposit confirmation on the source chain
WhyPrevents unbacked token creation - every wrapped token has a 1:1 backing asset
EnforcedBridge authority requires 14-of-20 validator attestation of deposit event
ViolationMint request rejected. Deposit re-verified on source chain.
B2: Bridge withdrawals cannot exceed deposited balance
WhyEnsures bridge contract solvency at all times
EnforcedSmart contract balance check before withdrawal execution
ViolationTransaction reverts on-chain. No funds released.
5. Supply Invariants
S1: Total JIL token supply never exceeds 10 billion
WhyFixed supply guarantee to token holders
EnforcedERC-20 contract has no mint function. Burn is available but not mint.
ViolationStructurally impossible - no mint function exists in the deployed contract
S2: Wrapped token supply equals deposited collateral
Why1:1 backing guarantee for all wrapped assets (jETH, jBTC, etc.)
EnforcedBridge mint/burn operations are atomic with deposit/withdrawal events
ViolationBalance discrepancy flagged by monitoring. Bridge operations paused for investigation.
6. Safety Invariants
SA1: System prefers safety over liveness
WhyIncorrect settlements are worse than delayed settlements
EnforcedFail-closed design across all components. Ambiguous states halt processing.
ViolationN/A - safety is the design principle, not a runtime check
SA2: No settlement is processed during consensus uncertainty
WhyPrevents settlements during network partition or validator communication failure
EnforcedConsensus requires explicit attestation - silence is not consent
ViolationSettlements queue until consensus is re-established
7. Monitoring Invariants
M1: All validator nodes are monitored continuously
WhyUnmonitored nodes are invisible failure points
EnforcedSentinelAI health checks every 60 seconds. Heartbeat verification continuous.
Violation3 missed heartbeats trigger investigation. 5 missed triggers fleet cycle consideration.
M2: Security-relevant events are logged immutably
WhyPost-incident analysis requires complete audit trail
EnforcedAppend-only logging with Kafka persistence. Logs backed up to S3.
ViolationLog gap detection triggers alert. Missing log windows are flagged in audit reports.
Failure Detection and Response
Invariant violations are detected through multiple mechanisms.
| Detection Method | Coverage | Response Time |
|---|---|---|
| Consensus protocol enforcement | C1, C2, C3, T1, T2 | Immediate (inline) |
| Cryptographic verification | W1, W2, T3, S1 | Immediate (inline) |
| Smart contract enforcement | B1, B2, S1, S2 | Immediate (on-chain) |
| SentinelAI monitoring | M1, M2, SA1, SA2 | Under 5 minutes |
| Balance reconciliation | S2, B2 | Hourly automated check |
Future Verification
The following enhancements to invariant verification are planned.
- Formal verification: Mathematical proof of consensus invariants (C1-C3) - planned Q4 2026
- Runtime assertion monitoring: Continuous runtime checks for all invariants with automated alerts
- Chaos testing: Deliberate invariant violation attempts in isolated test environments
- Third-party audit: Independent verification of invariant enforcement - planned Q3 2026
Ready to verify?
Start with a structured POC. Evaluate JIL settlement infrastructure on a single corridor.