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

• Settlement requires the independent signing quorum (tolerates a minority of faulty nodes)
• Bridge requires the independent bridge signing quorum (tolerates a minority of faulty nodes)
• Wallet MPC requires at least 2 of 3 shards (user always holds 1 shard)
• Settlement halts automatically if fewer than 10 signing nodes are healthy
• Adaptive quorum targets 70%, minimum 7 signing nodes for any signing action
• No single entity controls enough signing-node keys to reach any threshold unilaterally

Reference Documentation

System architecture covering 300+ production services, 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, signing-node compromise, supply chain attacks, bridge exploits, wallet compromise, and API abuse vectors.

Threat Model Coverage

• Insider threats (operator compromise, key theft)
• Signing-node compromise (faulty 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)
• Signing-node 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 signing timeout or signing-node 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
• Signing model: independent cryptographic signing, instant finality after record 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 signing-node response time

Signing-Node Topology

• 20 signing nodes: 10 active (signing 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)
• Network port: 26656 (P2P), 26657 (RPC), 9090 (metrics)
• Quorum: 70% adaptive, minimum 7 signing nodes for any signing action
• Halt threshold: fewer than 10 healthy signing nodes triggers automatic halt
• Network: full mesh topology (every signing node 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 signing nodes.

Operational Runbooks

• Signing-node failure: auto-detection via heartbeat, fleet-cycle recovery
• Key rotation: per-signing-node, 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

Self-custody 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 an independent signing-node threshold across 13+ jurisdictions. 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 independent signing-node 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 independent signing-node attestation
• Deposit flow: lock on source chain, signing-node attestation, mint on the JIL settlement engine
• Withdrawal flow: burn on the JIL settlement engine, signing-node 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 evaluation, 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, 53 provisional patent claims across 10 independent inventions, signing-node governance model, upgrade governance, and emergency controls.

Governance Coverage

• Ownership structure: JIL Sovereign Technologies, Inc.
• Signing-node governance: admission, removal, slashing conditions
• Upgrade governance: staged rollout, signing-node opt-in
• Emergency controls: settlement halt (independent quorum), 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, signing-node geography, operational specifications, and protocol glossary.