Executive Summary
JIL Sovereign's non-custodial custody architecture is the first system to combine user-primary MPC threshold signing with automatic on-chain protection coverage payouts. The user retains their primary key shard on their personal device, ensuring that no single party - including the platform - can unilaterally access funds.
Three innovations distinguish this architecture: (1) User-primary shard model where the user holds Shard A on their device, the platform holds Shard B in an HSM in a different jurisdiction, and Shard C is in cold storage in a third jurisdiction. (2) Protocol-embedded coverage payout triggered by 14-of-20 validator attestation. (3) Cross-jurisdictional shard distribution ensuring no single legal system can compel access to 2-of-3 shards.
Problem Statement
The crypto custody landscape presents institutions with an impossible tradeoff: centralized custodians (Fireblocks, BitGo, Coinbase Custody) provide operational convenience and coverage but require surrendering key control. Self-custody solutions eliminate counterparty risk but offer no protection against key loss, device failure, or operational errors.
Why Existing Solutions Are Insufficient
- Fireblocks: MPC-CMP protocol but platform retains operational control over 2 of 3 shards. Not truly non-custodial.
- ZenGo: 2-of-2 MPC with user device + server. No recovery shard. Server compromise halts all signing.
- BitGo: Multi-signature (not MPC) with custody agreement. Platform can freeze assets. Separate insurance policy.
- Coinbase Custody: Full custodial HSM. Manual claims process taking weeks to months.
Technical Architecture
Shard Distribution Model
| Shard | Holder | Location | Encryption |
|---|---|---|---|
| Shard A (User) | User's device | Device secure enclave (TEE/SE) | Biometric lock |
| Shard B (Platform) | JIL Platform | HSM in Jurisdiction 2 (Switzerland) | HSM hardware boundary |
| Shard C (Recovery) | Cold storage | Secure facility in Jurisdiction 3 (Singapore) | AES-256-GCM |
GG20 Signing Protocol
The GG20 protocol enables any 2-of-3 shard holders to collaboratively produce a valid ECDSA or Ed25519 signature without revealing their shard. The protocol operates in four rounds: commitment, decommitment, partial signatures, and aggregation. The resulting signature is indistinguishable from a standard single-key signature.
Distributed Key Generation
Initial key generation uses Feldman's Verifiable Secret Sharing (VSS). No single party ever sees the complete private key - not even during generation. The public key is derived from combined public shares and registered on-chain.
Protection Coverage Integration
Every MPC-protected account includes automatic protection coverage of up to $250,000 (Premium tier). Premiums are calculated at 100 basis points per year on monthly average AUM.
Covered Loss Events
| Loss Type | Detection Method | Payout Trigger |
|---|---|---|
| Key Compromise | Unauthorized signing attempt | 14-of-20 validator attestation |
| Bridge Failure | Settlement timeout >24h | Automatic proof-of-failure |
| Custodial Breach | HSM compromise or seizure | 14-of-20 emergency vote |
| Smart Contract Exploit | Unexpected fund movement | Proof-verifier anomaly detection |
Automatic Payout Mechanism
Unlike traditional insurance requiring manual claims, JIL's coverage executes automatically. When a loss event is detected and attested by 14-of-20 validators, payout triggers on-chain without user action. The process completes in minutes, not weeks.
Prior Art Differentiation
| Provider | Model | User Controls Keys? | Integrated Coverage? |
|---|---|---|---|
| Fireblocks | Custodial MPC (2/3 platform-controlled) | No | No |
| ZenGo | Semi-custodial (2/2) | Partial | No |
| Coinbase Custody | Full custodial HSM | No | Separate, manual |
| BitGo | Multi-sig custody | No | Separate, manual |
| JIL Sovereign | Non-custodial MPC | Yes | Yes, automatic |