MPC 2-of-3 Threshold Signing

01Executive Summary

JIL Sovereign implements a non-custodial multi-party computation (MPC) key management system using a 2-of-3 threshold signing protocol based on GG20 (Gennaro-Goldfeder 2020). The user retains primary control through Shard A stored on their personal device, while the platform holds Shard B in a hardware security module (HSM) in a separate legal jurisdiction, and Shard C is encrypted at rest with AES-256-GCM in a third jurisdiction.

This architecture guarantees that no single party - including the platform itself - can unilaterally move user funds. The user's shard never leaves their device. Any two of three shards are sufficient to produce a valid signature, enabling recovery scenarios without compromising the non-custodial guarantee.

02Problem Statement

The crypto custody landscape presents institutions with an impossible tradeoff: centralized custodians (Fireblocks, BitGo, Coinbase Custody) provide operational convenience and insurance but require surrendering key control to a third party. Self-custody solutions eliminate counterparty risk but offer no protection against key loss, device failure, or operational errors.

2.1 The Custody Trilemma

2.2 Why Existing MPC Solutions Are Insufficient

• Fireblocks: MPC-CMP protocol but platform retains operational control over 2 of 3 shards. User cannot independently sign. Not truly non-custodial.
• ZenGo: 2-of-2 MPC with user device + server. No recovery shard. No integrated protection coverage. Server compromise halts all signing.
• Coinbase Custody: Centralized HSM custody. Full custodial model. Insurance through traditional carriers with manual claims process taking weeks to months.
• BitGo: Multi-signature (not MPC) with custody agreement. Platform can freeze assets. Insurance requires separate policy negotiation.

03Technical Architecture

3.1 Shard Distribution

3.2 GG20 Signing Protocol

The GG20 protocol enables any 2-of-3 shard holders to collaboratively produce a valid ECDSA or Ed25519 signature without any party revealing their shard to the other. The protocol operates in four rounds:

1. Round 1 - Commitment: Each party generates a random nonce share and broadcasts a commitment (hash of the nonce share).
2. Round 2 - Decommitment: Parties reveal their nonce shares and verify against commitments. Paillier encryption protects intermediate values.
3. Round 3 - Partial Signatures: Each party computes a partial signature using their shard and the combined nonce. Zero-knowledge proofs verify correctness.
4. Round 4 - Aggregation: Partial signatures are combined into a single valid signature that is indistinguishable from a standard single-key signature on-chain.

3.3 Distributed Key Generation (DKG)

Initial key generation uses Feldman's Verifiable Secret Sharing (VSS) to create the three shards from a jointly generated secret. No single party ever sees the complete private key - not even during generation. The public key is derived from the combined public shares and registered on-chain as the account's signing key.

// DKG Output (per party)
{
  "shard_index": 1,          // 1=User, 2=Platform, 3=Recovery
  "shard_share": "encrypted(32 bytes)",
  "public_key": "Ed25519 public key (shared)",
  "verification_shares": [    // Feldman VSS commitments
    "g^a0", "g^a1"           // For threshold t=2
  ],
  "paillier_pk": "...",       // For GG20 signing rounds
  "jurisdiction": "CH_FINMA"  // Shard B jurisdiction
}

04Implementation

4.1 Key Generation Ceremony

1. Initiation: User opens wallet app and triggers new account creation. Device generates entropy from secure enclave TRNG.
2. DKG Round 1: User device, platform HSM, and recovery service each generate polynomial shares and broadcast VSS commitments over TLS 1.3 channels.
3. DKG Round 2: Encrypted share exchanges between all three parties. Each party verifies received shares against VSS commitments.
4. DKG Completion: Public key derived. User's Shard A stored in device secure enclave. Shard B sealed in HSM. Shard C encrypted with AES-256-GCM and transferred to cold storage.
5. On-Chain Registration: Public key registered as account signing key on JIL L1 ledger.

4.2 Standard Signing Flow (Shards A + B)

For routine transactions, the user's device (Shard A) and the platform HSM (Shard B) collaborate via the GG20 protocol. The user initiates the transaction, their device produces a partial signature, the platform verifies the transaction against policy rules, and then contributes its partial signature. The combined result is a single valid signature submitted to the network.

4.3 Recovery Flow (Shards A + C)

If the platform becomes unavailable, the user can recover using their device shard (A) combined with the recovery shard (C). Recovery requires a 24-hour timelock, multi-factor authentication, and validator attestation confirming the recovery request legitimacy. This ensures that even platform failure does not lock user funds.

05Integration with JIL Ecosystem

5.1 Protection Coverage Module

Every MPC-protected account on JIL Sovereign includes automatic protection coverage of up to $250,000 (Premium tier). Premiums are calculated at 100 basis points per year on monthly average assets under management, collected automatically via on-chain micro-transactions.

5.2 Covered Loss Events

5.3 Automatic Payout Mechanism

Unlike traditional insurance that requires manual claims filing, investigation periods, and adjudication delays, JIL's protection coverage executes automatically. When a loss event is detected and attested by 14-of-20 validators, the payout is triggered on-chain without any action required from the affected user. The entire process - from detection to payout - completes within minutes, not weeks.

5.4 MPC Cosigner Service Integration

The MPC cosigner service (port 8200) manages the platform's Shard B operations. It enforces transaction policies before co-signing, including velocity limits, amount thresholds, destination whitelists, and compliance zone restrictions. The cosigner logs every signing request to an append-only audit trail verifiable by the proof-verifier service.

06Prior Art Differentiation

07Implementation Roadmap

08Patent Claim