Self-Custody MPC Architecture with Threshold Signing

Executive Summary

JIL Sovereign's self-custody architecture splits a wallet's signing authority into cryptographic key shares using Shamir Secret Sharing, requiring a configurable threshold of shares to reconstruct a valid signature for any transaction. In JIL's default configuration a wallet key is split : the user's device holds one share, generated in a client-side ceremony and returned only to the user - never persisted by the platform - the platform's signing service holds a second, and a third share is written to encrypted cold backup under the recovery system described separately. No subset of shares that excludes the user's own share can ever reach the signing threshold, so the platform cannot unilaterally move funds under any internal failure, insider-compromise, or legal-compulsion scenario.

The architecture's other defining property is fail-closed degradation: production signing prefers a hardware-security-module-backed signer, and explicitly refuses to fall back to software threshold reconstruction when that path fails - the software fallback exists only outside production. Where software threshold participation is used, the platform-held share is encrypted at rest with a server-held key-derivation secret rather than by the share's own identifier, closing a class of at-rest exposure common to naive Shamir implementations.

Together, the user-primary shard, the HSM-preferred signing path, and the deliberate refusal to silently degrade in production distinguish this architecture from custodial MPC platforms, where the platform's own operated infrastructure can hold a signing majority in the deployed configuration and act without independent user participation.

Problem Statement

Custody sits on a spectrum with two failure modes at the ends. Pure self-custody - a seed phrase held only by the user - has no recourse if the device is lost, and offers an institution nothing it can audit or govern. Custodial platforms solve the operational-control problem but require the customer to surrender key material into infrastructure the customer does not operate, concentrating risk in a single organization; the collapse of large custodial platforms is the industry's standing evidence that "the custodian holds your keys" is itself a risk to be priced, not one that better UI eliminates.

Existing semi-custodial MPC designs close this gap only partially. Widely-deployed 2-of-2 schemes (a user device plus a single platform server share) go dark entirely if the platform's share is unavailable, and a compromised or coerced server combined with a compromised device is jointly sufficient to reach quorum. Multi-signature designs are not MPC at all - the full signer set and the multi-sig script are exposed on-chain, and the platform's key is typically a required signer regardless of the transaction's origin.

Why Existing Solutions Are Insufficient

• Custodial MPC platforms: use a real MPC protocol, but the platform's own operated infrastructure holds a signing majority in the customer's deployed configuration; the customer is not structurally required to co-sign every transaction.
• 2-of-2 semi-custodial designs: no independent third recovery share; a platform-side outage halts signing entirely.
• Multi-signature ("multi-sig") custody: not MPC - the signer set and script are on-chain, and the platform's key is a required signer irrespective of who initiated the transaction.
• Fully custodial HSM platforms: the customer never holds signing material of any kind.

Technical Architecture

Shard Distribution Model

Threshold Configuration

The default signing mode is a threshold (two of three shares required); an alternate 3-of-5 mode is available for higher-assurance accounts, selected per deployment. In either mode, the platform alone holds strictly fewer shares than the configured threshold, so it can never assemble a valid signature without the user's participation.

Signing Session Flow

A transaction opens a cosign session; the user's device submits its partial signature, and the session manager - holding the registered key shares for the account - reconstructs the composite signature only once collected partial signatures meet the configured threshold, using Lagrange interpolation over the underlying secret-sharing scheme to combine partials into a threshold Schnorr or ECDSA signature.

HSM-Preferred, Fail-Closed Execution

In production, the signing service attempts a hardware-security-module-backed signer first. If the HSM path fails, the request is rejected outright rather than silently falling back to software-based threshold reconstruction; that software fallback path is available only in non-production environments. A production HSM outage therefore produces a visible, immediate failure rather than an invisible change to the system's security boundary.

Shard Lifecycle Integration

The shard model above is integrated with a companion backup/recovery/rotation lifecycle (filed as a separate, more granular claim): every shard-backup operation, every recovery attempt - successful or denied - and every rotation is appended to a hash-chained audit log, so the custody architecture's operational history is tamper-evident independent of any single transaction's own signing history.

Prior Art Differentiation

Patent Claim