Adversarial Threat Model
Structured analysis of adversary categories, attack surfaces, attack scenarios, and residual risks. Institutional counterparties can evaluate exactly what JIL defends against and where residual risk remains.
Threat Modeling Philosophy
JIL's threat model follows the principle: assume breach, design for containment. Rather than assuming the perimeter is impenetrable, the architecture limits the blast radius of any single compromise. Every component is designed to fail safely - degrading to a halt rather than producing incorrect settlements.
- Defense in depth - multiple independent controls at each layer
- Fail-closed - ambiguous states halt processing rather than proceeding
- Blast radius containment - compromise of one component does not compromise all
- Transparent disclosure - known risks are published, not hidden
Adversary Categories
The threat model considers four categories of adversaries, each with different capabilities, motivations, and attack budgets.
| Category | Capability | Motivation | Budget |
|---|---|---|---|
| External Attacker | Network access, public API exploitation, phishing | Financial gain, service disruption | Low-Medium |
| Compromised Insider | Limited system access, credential theft, social engineering | Financial gain, coercion | Medium |
| Colluding Validators | Consensus participation, attestation manipulation | Financial gain, censorship | Medium-High |
| State-Level Actor | Infrastructure compromise, cryptographic resources, legal coercion | Surveillance, disruption, sanctions enforcement | High |
Attack Surfaces
Five primary attack surfaces are considered in the threat model. Each surface has specific mitigations and monitoring.
1. Consensus Layer
Attacks targeting validator quorum, settlement ordering, or attestation forgery. Mitigated by 14-of-20 threshold, geographic distribution, and 7-gate validator bootstrap.
2. Wallet / MPC Layer
Attacks targeting key shard compromise, MPC protocol exploitation, or unauthorized signing. Mitigated by 2-of-3 threshold, WebAuthn, and shard isolation.
3. Bridge Layer
Attacks targeting deposit spoofing, mint bypass, or chain watcher manipulation. Mitigated by validator attestation, rate limits, and contract verification.
4. Infrastructure Layer
Attacks targeting server compromise, DNS hijacking, or supply chain poisoning. Mitigated by image digest verification, signed deployments, and multi-zone redundancy.
5. API / Application Layer
Attacks targeting API abuse, input injection, or authentication bypass. Mitigated by rate limiting, input validation (Zod), JWT authentication, and CORS enforcement.
Consensus Attack Scenarios
Scenario: Validator Collusion (6 of 20)
Scenario: Validator Key Compromise (Single Node)
Wallet Attack Scenarios
Scenario: User Key Shard Compromise
Scenario: MPC Cosigner Compromise
Bridge Attack Scenarios
Scenario: Deposit Event Spoofing
Scenario: Bridge Contract Exploit
Infrastructure Attack Scenarios
Scenario: Supply Chain - Malicious Docker Image
Residual Risks
The following risks are acknowledged but not fully mitigated in the current architecture. They are actively managed through monitoring and roadmap items.
| Risk | Severity | Current Mitigation | Planned Resolution |
|---|---|---|---|
| Quantum computing threat to Ed25519 | Low (future) | Dilithium/Kyber implemented, not activated | Activation after audit (2027) |
| Zero-day in Node.js/Docker runtime | Medium | Regular patching, minimal base images | Continuous dependency scanning |
| Coordinated state-level validator seizure | Low | 10 zones, diverse jurisdictions | Expand to 20 zones post May 2026 |
| DNS-level traffic redirection | Medium | Cloudflare proxy, HTTPS enforcement | DNSSEC implementation (roadmap) |
| Smart contract vulnerability in bridge | Medium | Rate limits, Sourcify verification | Formal verification Q4 2026 |
Monitoring and Incident Response
- Real-time monitoring: SentinelAI fleet inspector with automated threat scoring across all validator nodes
- Anomaly detection: Voting pattern analysis, geographic origin tracking, signing velocity monitoring
- Auto-recovery: Fleet cycle triggers when health drops below 30% for 5 consecutive monitoring cycles
- Incident escalation: Automated alerting with defined severity levels and response procedures
- Anti-loop protection: Max 3 fleet cycles per 2 hours, max 2 failed cycles per node per 2 hours
- Post-incident: Root cause analysis, assumption review, and control updates
Ready to verify?
Start with a structured POC. Evaluate JIL settlement infrastructure on a single corridor.