System Trust Assumptions
Every security system makes trust assumptions. JIL documents what the system trusts, what it verifies, what it cannot prevent, and where residual risk exists. Transparency about assumptions is itself a security property.
Security Philosophy
JIL's security model is built on the principle that trust should be minimized, distributed, and verified. No single entity - including JIL itself - should have unilateral control over settlement outcomes. This philosophy drives every architectural decision.
- Trust is distributed across 14-of-20 validators across 13 jurisdictions
- Users retain custody of their key shard - MPC 2-of-3 ensures non-custodial operation
- Every trust assumption is documented and testable
- Known limitations are disclosed, not hidden
Five Core Trust Domains
JIL's trust model spans five interconnected domains. Each domain has explicit assumptions, verification mechanisms, and failure modes.
1. Consensus Trust
The system trusts that fewer than 7 of 20 validators are simultaneously compromised or colluding. This 14-of-20 threshold (70% BFT) ensures that no single jurisdiction, operator, or attack vector can unilaterally control settlement outcomes.
2. Wallet Trust
The system trusts that the user securely stores their MPC key shard. JIL holds 2 shards but cannot sign without the user's shard. If the user's shard is compromised, the attacker still needs a second shard.
3. Bridge Trust
Cross-chain bridge operations trust the Ethereum smart contract (JILBridge.sol) and the 14-of-20 validator attestation for deposit confirmation. Bridge operations are bounded by per-transaction and per-day limits.
4. Infrastructure Trust
The system trusts the underlying infrastructure providers (Hetzner, Cloudflare) for availability but not for data integrity. All data is encrypted at rest and verified cryptographically.
Consensus Security Assumptions
The consensus model makes the following assumptions:
| Assumption | Basis | Failure Mode |
|---|---|---|
| Fewer than 7/20 validators compromised | Geographic distribution across 10 zones | If violated: consensus halts (safety preserved) |
| Network latency under 2 seconds between validators | Validators in Tier 1 data centers | If violated: increased settlement latency, not failure |
| Validator clocks within 5-second drift | NTP synchronization | If violated: timestamp ordering issues, flagged by monitoring |
| Validator signing keys are secure | HSM storage, AES-256-GCM encryption at rest | If violated: key revocation, validator replacement |
Wallet Security Assumptions
- User key shard security: The system assumes the user protects their key shard. JIL provides WebAuthn-based access but cannot prevent device compromise
- MPC protocol correctness: The 2-of-3 threshold signing protocol is assumed to be correctly implemented. Implementation has been reviewed by external firms
- Non-custodial guarantee: JIL cannot initiate settlements without the user's shard. This is a cryptographic guarantee, not a policy guarantee
Bridge Security Assumptions
- Ethereum contract integrity: The JILBridge.sol contract on Ethereum mainnet is assumed to be correctly deployed and verified (Sourcify-verified)
- Chain watcher reliability: The bridge chain watcher monitors Ethereum for deposit events. If the watcher fails, deposits queue until recovery - no funds are lost
- Validator attestation for minting: Wrapped tokens (jETH, jBTC, etc.) are only minted after 14-of-20 validators confirm the deposit on the source chain
- Rate limiting: Bridge operations are bounded by per-transaction limits and daily aggregate limits to contain blast radius
Cryptographic Assumptions
- Ed25519 security: Elliptic curve signatures are assumed secure against classical attacks. Post-quantum migration path via Dilithium is implemented but not yet active
- AES-256-GCM: Symmetric encryption for keys at rest is assumed to resist brute force and side-channel attacks
- SHA-256 collision resistance: Content-addressed storage and Merkle trees assume SHA-256 collision resistance
- HMAC-SHA256: Remote control command authentication assumes HMAC is unforgeable without the shared secret
Infrastructure Assumptions
- Data center availability: Hetzner infrastructure is assumed to provide 99.9%+ uptime. Multi-zone distribution provides redundancy
- DNS integrity: Cloudflare DNS is assumed to correctly resolve domain names. DNSSEC is not currently enforced (roadmap item)
- TLS termination: Cloudflare proxy terminates TLS at the edge. Origin-to-Cloudflare traffic is HTTP - acceptable because Cloudflare is within the trust boundary
- Docker image integrity: Image distribution uses digest verification - validators verify image hashes before deploying new versions
Monitoring and Failure Recovery
- SentinelAI detection: Fleet inspector monitors validator health with automated threat scoring. Assumption: monitoring detects anomalies within 5 minutes
- Heartbeat monitoring: Validators send periodic heartbeats. 3 missed heartbeats trigger investigation. Assumption: network partitions are detectable
- Auto-recovery: Fleet cycle triggers automatic validator restart when health drops below 30%. Assumption: most failures are recoverable via restart
- Golden snapshots: Known-good validator state is backed up to S3. Recovery from snapshot is tested but not yet automated in production
Known Limitations
JIL openly discloses the following limitations of the current system.
| Limitation | Impact | Mitigation / Roadmap |
|---|---|---|
| No formal verification of consensus protocol | Protocol correctness relies on testing, not mathematical proof | Formal verification planned Q4 2026 |
| Post-quantum cryptography not yet active | Current Ed25519 is vulnerable to future quantum attacks | Dilithium/Kyber implemented, activation pending audit |
| Single bridge chain watcher | Watcher failure delays deposit confirmation | Redundant watcher deployment planned |
| No independent security audit completed | Security posture relies on internal review and external technical validation | Independent protocol audit planned Q3 2026 |
| Manual validator key rotation | Key rotation requires operator intervention | Automated key rotation in development |
Transparency Commitment
JIL's approach to trust assumptions is based on three principles:
- Document everything: Every trust assumption is written down, not implicit
- Disclose limitations: Known weaknesses are published, not concealed
- Verify continuously: Assumptions are tested through automated monitoring, not assumed to hold indefinitely
This page will be updated as assumptions change, new limitations are discovered, or existing limitations are resolved.
Ready to verify?
Start with a structured POC. Evaluate JIL settlement infrastructure on a single corridor.