Evidence Pack

Multiple cryptographic thresholds operate across the system. This section defines each threshold, minimum honest node assumptions, key rotation authorities, and emergency controls.

Minimum Honest Node Assumptions

• L1 consensus requires at least 14 of 20 honest validators (tolerates up to 6 Byzantine)
• Bridge requires at least 14 of 20 honest bridge validators (tolerates up to 6 Byzantine)
• Wallet MPC requires at least 2 of 3 shards (user always holds 1 shard)
• Chain halts automatically if fewer than 10 validators are healthy
• Adaptive quorum targets 70%, minimum 7 validators for any consensus action
• No single entity controls enough validator keys to reach any threshold unilaterally

Reference Documentation

System architecture covering 190+ microservices, protocol parameters, service topology, and inter-service communication. Port mappings, canonical parameters, and settlement flow documentation.

Threat model, key management, authorization design, fleet monitoring, and incident response architecture. Covers insider threats, validator compromise, supply chain attacks, bridge exploits, wallet compromise, and API abuse vectors.

Threat Model Coverage

• Insider threats (operator compromise, key theft)
• Validator compromise (Byzantine behavior, collusion)
• Supply chain attacks (dependency injection, image tampering)
• Bridge exploits (replay, double-spend, reserve drain)
• Wallet compromise (shard theft, session hijack)
• API abuse (rate limiting, authentication bypass)

Throughput and latency claims are backed by deterministic benchmarks with fully disclosed methodology. Test parameters, hardware profiles, network topology, and measurement methodology are published for reproducibility.

TPS Benchmark Methodology

• Hardware: Hetzner CPX52/62 (16 vCPU, 32 GB RAM, NVMe SSD)
• Validator count: 20 nodes (10 active + 10 sentry) across 13 jurisdictions
• Network topology: full mesh P2P, Hetzner private network (Nuremberg primary)
• Transaction type: standard settlement intent (structured JSON, ~512 bytes)
• Workload generation: deterministic test harness, 7 pluggable scenarios
• Measurement tool: wall-clock timer, intent submission to finality receipt
• Peak observed: 9,500 TPS per node; ~200K aggregate projected across 20 nodes
• Limitations: single-region latency profile; cross-region adds ~50-150ms RTT
• Failure mode: benchmark aborts on consensus timeout or validator failure
• Block size: 10 MB maximum; block time: 1.5 seconds (frozen parameter)

Finality Benchmark Methodology

• Definition: time from intent submission to cryptographically signed finality receipt
• Consensus model: CometBFT (Tendermint), instant finality after block commit
• Measured latency: sub-second under normal load (1.5s block time)
• Receipt contents: policy hash, beneficiary binding, quorum attestation, timestamps
• Verification: receipts independently verifiable via Ed25519 signature check
• Degraded mode: finality delayed proportional to validator response time

Validator Topology

• 20 validators: 10 active (consensus participants) + 10 sentry (hot standbys)
• Geographic distribution: 13 jurisdictions (US, DE, EU, SG, CH, JP, GB, AE, BR, plus 4 sentry zones)
• Server specs: Hetzner CCX33/CPX52 (8-16 vCPU, 16-32 GB RAM, NVMe)
• Consensus port: 26656 (P2P), 26657 (RPC), 9090 (metrics)
• Quorum: 70% adaptive, minimum 7 validators for any consensus action
• Halt threshold: fewer than 10 healthy validators triggers automatic halt
• Network: full mesh topology (every validator peers with every other)
• No single jurisdiction controls enough keys to reach any threshold unilaterally

Autonomous fleet management via SentinelAI. Health scoring, automated recovery, golden snapshot backups, anti-loop protection, and fleet-wide cycling across 10 mainnet validators.

Operational Runbooks

• Validator failure: auto-detection via heartbeat, fleet-cycle recovery
• Key rotation: per-validator, no downtime, HMAC-authenticated
• Disaster recovery: golden snapshot restore from Hetzner S3
• Security incident: SentinelAI auto-isolation, manual escalation path
• Fleet health below 30%: auto-triggers fleet-wide cycle (max 3 per 2h)
• Image deployment: DevNet build, digest verify, staged rollout

Non-custodial architecture. MPC 2-of-3 threshold signing, Passkey/WebAuthn device authentication, guardian recovery, and hardware key support. User always holds one shard.

Key Management Details

• MPC key generation: distributed, no single party sees full key
• Shard distribution: user device, platform HSM, recovery guardian
• Device authentication: WebAuthn/FIDO2 passkeys
• Recovery: guardian-assisted shard reconstruction
• Key storage: AES-256-GCM encrypted at rest
• Signing protocol: threshold ECDSA (2-of-3 required)

Settlement produces a cryptographically signed finality receipt containing policy hash, beneficiary binding, quorum attestation, and timing metadata. DvP workflows and receipt verification tooling.

Cross-chain bridge deployed on Ethereum mainnet with 14-of-20 validator threshold (70% BFT). Custody assumptions, mint/burn logic, replay protection, reserve accounting, and emergency pause triggers.

Reserve Invariants

• minted_assets <= locked_assets at all times
• Withdrawal requires verified burn transaction
• Deposit requires finalized on-chain event (21 confirmations)
• Replay protection: nonce-based, per-chain transaction ID
• Emergency pause: deployer (bootstrap) or 14-of-20 validator quorum
• Anomaly detection: rate limiting on mint volume, alert thresholds
• 5 registered tokens: ETH (native), USDC, USDT, WBTC, DAI
• Monitoring: on-chain reserve vs. minted supply reconciliation

Bridge Reserve Model

• Custody: assets locked in JILBridge.sol on Ethereum mainnet (verifiable on-chain)
• Mint authority: bridge_authority key executes only after 14-of-20 validator attestation
• Deposit flow: lock on source chain, validator attestation, mint on JIL L1
• Withdrawal flow: burn on JIL L1, validator signature collection, release on destination chain
• Deposit idempotency: unique on (source_chain, tx_hash, log_index) prevents double-mint
• Daily outflow caps: configurable per-asset limits, auto-pause on breach
• Reserve check: total_minted <= total_deposited - total_withdrawn enforced before every mint AND withdrawal
• Auto-pause triggers: reserves mismatch or daily outflow cap breach

Zone-based compliance enforcement, ZK proof circuits, BEC fraud detection, BID identity verification, sanctions screening, transaction monitoring, and jurisdiction-aware policy corridors.

JIL ERC-20 (10B supply), multi-vault treasury (5 vaults, 7.5B funded), legacy migration swap contracts, and cliff-vesting sale contracts. All contracts deployed on Ethereum mainnet and verified on Sourcify.

Economic Documentation

18 published API specifications, enterprise API gateway, ISO 20022 message support, webhook infrastructure, and sandbox access for evaluation.

Entity structure, 48 provisional patent claims across 10 independent inventions, validator governance model, upgrade governance, and emergency controls.

Governance Coverage

• Ownership structure: JIL Sovereign Technologies, Inc.
• Validator governance: admission, removal, slashing conditions
• Upgrade governance: staged rollout, validator opt-in
• Emergency controls: chain halt (14-of-20), bridge pause (deployer or quorum)

Structured POC framework, sandbox evaluation environment, documented reference use cases, and case study scenarios across institutional settlement operations.

Independent validation is required to move artifacts from L1/L2 to L3 maturity. This section tracks the external audit and verification roadmap. Completing any single item materially increases institutional trust.

Audit Deliverables (per engagement)

• Final audit report (public or partner-restricted)
• Findings classification (critical, high, medium, low, informational)
• Remediation plan with timelines
• Remediation verification (re-test after fixes)

Transparent disclosure of evidence gaps, known risks, and items that have not been independently verified. This section exists because institutional counterparties require honest assessment, not selective presentation.

Supporting reference material. Port mappings, canonical parameters, validator geography, operational specifications, and protocol glossary.