Zero-Knowledge Compliance Operational Specification

1. Executive Summary

This document captures the binding operational decisions for the ZK Compliance (ZKC) subsystem of JIL Sovereign. It resolves five open questions that remained after the original ZKC specification was published: per-circuit gas benchmarks, jurisdictional conflict resolution hierarchy, proof validity windows by type, KYC provider selection and failover strategy, and the multi-phase proof system migration path.

All parameters in this document are authoritative for production. They supersede any earlier draft values referenced in design discussions or the original ZKC spec. Changes to these parameters require a governance proposal and 14-of-20 validator approval.

2. ZK Circuit Gas Benchmarks

All six production circuits use Groth16 proving with BN254 curves. Gas costs are measured on the JIL L1 execution environment and include calldata, verification computation, and state storage for the proof record.

Batch Verification

Submitting 5 or more proofs in a single transaction activates batch verification, which amortizes pairing computation across proofs. The discount is 15% off aggregate gas for the batch. Maximum batch size is 20 proofs per transaction - larger batches are rejected at the contract level to prevent block stuffing.

3. Jurisdictional Conflict Resolution

When a transaction crosses jurisdictions, compliance rules from multiple regulatory frameworks may apply simultaneously. JIL uses strict interpretation - the stricter rule always wins. This eliminates regulatory arbitrage and ensures every transaction satisfies the most demanding applicable standard.

Resolution Hierarchy

1. Bilateral corridor agreement - Negotiated rules for specific jurisdiction pairs (e.g., US-EU corridor). These take precedence because both regulators have explicitly approved them.
2. Receiving jurisdiction regulations - The destination jurisdiction's rules apply next, since the receiving regulator has primary enforcement authority over incoming funds.
3. Sending jurisdiction regulations - The origin jurisdiction's rules apply as a secondary layer, covering outbound transfer restrictions and reporting requirements.
4. FATF baseline recommendations - When no specific bilateral or jurisdictional rule exists, FATF Travel Rule and baseline AML recommendations serve as the floor.

Conflict Detection

The rule-engine service (port 8460) performs conflict detection at compile time when jurisdiction rule sets are loaded. If two rules produce contradictory requirements for the same proof type, the engine flags the conflict and applies the stricter interpretation automatically. Unresolvable conflicts - where no valid proof can satisfy both rules simultaneously - escalate to compliance-api (port 8100) for manual review by a compliance officer.

Currently 10 jurisdiction rule sets are loaded: US (SEC/FinCEN), EU (MiCA), UK (FCA), Singapore (MAS), Switzerland (FINMA), Japan (FSA), UAE (VARA), Brazil (CVM), Germany (BaFin), and South Korea (FSC).

4. Proof Validity Windows

Proof validity is tiered by type and risk level. Higher-risk proof types expire faster. Each proof type has a renewal grace period during which the old proof remains valid while the user generates a replacement.

Risk-Adjusted Windows

When a user's risk score exceeds 0.7 (as computed by the compliance-api risk engine), all validity windows are halved. For example, a high-risk user's KYC_AGE proof expires in 182 days instead of 365. This forces more frequent re-verification for accounts exhibiting suspicious patterns.

Proofs covering assets in the Protected zone (accounts with active protection coverage) use shorter windows - also halved from the base values. This layering is cumulative: a high-risk user in the Protected zone has validity windows at one-quarter of the base period.

5. KYC Provider Selection

JIL uses a dual-provider strategy for identity verification. Two providers ensure failover coverage and broader geographic reach. Both providers' results are stored as ZK-compatible attestations - the raw identity data never touches JIL infrastructure.

5.1 Primary - Onfido

• Regulation: FCA-regulated (United Kingdom)
• Coverage: 195 countries, document + biometric verification
• Certifications: SOC 2 Type II, ISO 27001
• API Latency: ~8s average per verification
• Routing: Default provider for all FATF member countries

5.2 Secondary - Sumsub

• Coverage: 220+ countries, real-time checks
• Strength: Broader emerging market coverage
• API Latency: ~6s average per verification
• Routing: Used for non-FATF jurisdictions and countries unsupported by Onfido

5.3 Routing Logic

The compliance-api service (port 8100) wraps both providers behind a unified interface. Routing decisions follow this order:

1. If the user's jurisdiction is a FATF member country and Onfido supports it, route to Onfido.
2. If the user's jurisdiction is not a FATF member, or Onfido does not support the document type, route to Sumsub.
3. If the primary provider returns 3 consecutive failures (timeout, 5xx, or verification system error), automatic failover to the secondary provider activates.
4. Health checks run every 60 seconds against both provider APIs. An unhealthy provider is removed from the routing pool until it recovers.

6. Proof System Migration Strategy

When ZK circuits are upgraded - whether for security patches, new proof types, or proving system migration (e.g., Groth16 to PLONK) - a structured 5-phase epoch migration ensures no user is disrupted and no valid position is forcibly liquidated.

Emergency Migration Path

If a critical vulnerability is discovered in an active circuit, the standard 150-day timeline is too slow. An emergency path compresses the entire migration to 7 days. This requires a 14-of-20 validator vote (matching the bridge quorum threshold) and must include simultaneous JILHQ announcement plus validator config push to all nodes.

During an emergency migration, the Dual-Accept window is reduced to 3 days, Soft-Deprecation to 2 days, and Hard-Deprecation to 2 days. Deactivation occurs immediately after Hard-Deprecation ends. Users with expiring positions receive automated notifications via the wallet-api webhook channel.

7. Cross-Reference Matrix

This matrix maps each operational parameter to its owning service, configuration source, and governance requirements for changes.