01Executive Summary
Social Recovery Ceremony is JIL Sovereign's protocol-native key recovery mechanism, designed to eliminate the single point of failure that causes an estimated $4 billion in permanently lost crypto assets each year. The system enables account holders to designate a set of trusted guardians who can collectively authorize key recovery through a multi-step, time-locked ceremony.
Unlike conventional social recovery schemes that rely on application-layer logic, JIL's implementation is embedded directly into the Layer 1 protocol. Recovery requests are submitted as on-chain transactions, guardian attestations are cryptographically verified by validators, and the mandatory 24-hour timelock is enforced at the consensus level. This architecture ensures that no single party - including JIL itself - can unilaterally recover or compromise an account.
02Problem Statement
Key loss remains the most significant barrier to mainstream crypto adoption. Chainalysis estimates that approximately 20% of all Bitcoin - over $100 billion - is locked in wallets whose owners have lost access to their private keys. Existing recovery mechanisms fall into two unsatisfactory categories.
Custodial Recovery
Centralized exchanges and custodians offer password reset flows, but this requires users to surrender sovereignty over their assets. Custodial recovery introduces counterparty risk, regulatory seizure risk, and the possibility of insider compromise. Users must trust the custodian's security practices, employee vetting, and business continuity.
Existing Social Recovery
Projects like Argent and Safe have pioneered guardian-based recovery, but their implementations suffer from critical limitations. Guardian attestations execute immediately without mandatory delay periods, leaving no window for the legitimate owner to detect and cancel fraudulent recovery attempts. Alert mechanisms are limited to single channels (typically push notifications), which can be silenced by an attacker who has physical access to the victim's device.
03Technical Architecture
The Social Recovery Ceremony operates through five distinct protocol components, each enforced at the L1 consensus layer.
| Component | Function | Enforcement |
|---|---|---|
| Recovery Registry | On-chain contract accepting recovery requests with target account, new key material, and designated guardian set | Consensus-validated |
| Guardian Attestation Protocol | M-of-N cryptographic attestation from designated guardians confirming recovery legitimacy | Ed25519 signature verification |
| Timelock Engine | Mandatory 24-hour delay after M-th attestation before key rotation executes | Block height enforcement |
| Alert Dispatcher | Multi-channel notification to all registered contact methods during timelock period | Off-chain with on-chain event trigger |
| Cancellation Mechanism | Enables legitimate owner to abort recovery by signing cancellation with any existing valid key | Consensus-validated |
Guardian Configuration
Account holders configure their guardian set through the guardian-attestor service. The default configuration is 3-of-5 guardians, meaning any three of five designated guardians must independently attest to a recovery request. Guardian addresses are stored on-chain in the Recovery Registry, and modifications to the guardian set require the account holder's signature plus a 48-hour delay to prevent last-minute guardian manipulation.
Recovery Flow
Initiator submits recovery request to Recovery Registry
- Target account, new public key, guardian set hash
- Recovery enters PENDING state
- Alert Dispatcher fires on all channels
Guardians independently verify and submit attestations
- Each attestation is an Ed25519 signature over the recovery request hash
- Registry tracks attestation count
M-th attestation received - Timelock begins
- 24-hour countdown enforced at block height
- Second wave of alerts dispatched
- Owner cancellation window open
Timelock expires - Key rotation executes
- Old key material deactivated
- New key material activated
- Recovery enters COMPLETED state
04Implementation
The Social Recovery Ceremony is implemented across three JIL Sovereign services, with the core logic enforced by the L1 validator consensus.
Recovery Registry Contract
The on-chain registry maintains a mapping from account addresses to their guardian configurations and active recovery requests. Each recovery request is assigned a unique ceremony_id derived from the keccak256 hash of the target account, new key material, and block number. This prevents replay attacks and ensures each ceremony is uniquely identifiable.
Multi-Channel Alert System
When a recovery request transitions to PENDING, the Alert Dispatcher sends notifications through all registered channels within 30 seconds. Channel delivery is independent - failure of one channel does not block others.
| Channel | Latency | Delivery Guarantee | Retry Policy |
|---|---|---|---|
| Under 60s | At-least-once via SES | 3 retries, exponential backoff | |
| SMS | Under 30s | Best-effort via Twilio | 2 retries, 30s interval |
| Push Notification | Under 10s | Best-effort via FCM/APNs | 1 retry |
| On-Chain Event | Next block (1.5s) | Guaranteed by consensus | Included in block or rejected |
Cancellation Mechanism
The legitimate account holder can cancel any active recovery ceremony by submitting a cancellation transaction signed with any key material currently associated with the account. This includes the primary key, any backup keys, or any MPC shard that can produce a valid signature. Cancellation is immediate and irrevocable - once cancelled, the same recovery request cannot be resubmitted for 72 hours.
05Integration with JIL Ecosystem
Social Recovery Ceremony integrates with multiple JIL Sovereign subsystems to provide a seamless recovery experience while maintaining the platform's security guarantees.
MPC Cosigner
Recovery ceremonies that involve MPC key shards coordinate with the mpc-cosigner service. The new key material can be a fresh MPC key set, maintaining the 2-of-3 threshold signing model post-recovery.
Compliance API
Recovery requests trigger a compliance check to ensure the new key material is not associated with sanctioned addresses. The compliance-api validates against OFAC, EU sanctions lists, and zone-specific restrictions.
Protection Coverage
Protection coverage is maintained throughout the recovery ceremony. The 24-hour timelock ensures underwriters have adequate notice of key rotation events, and coverage transfers seamlessly to the new key material.
Proof Verifier
Each guardian attestation generates a zero-knowledge proof that the guardian possesses the correct private key without revealing it. These proofs are verified by the proof-verifier service before being accepted by the registry.
06Prior Art Differentiation
JIL's Social Recovery Ceremony introduces several novel elements not found in existing implementations.
| Feature | Argent | Safe (Gnosis) | JIL Sovereign |
|---|---|---|---|
| Guardian Attestation | Application-layer | Multi-sig transaction | L1 consensus-verified |
| Mandatory Timelock | None (immediate) | Optional module | 24h consensus-enforced |
| Alert Channels | Push only | None built-in | Email, SMS, Push, On-chain |
| Cancellation Window | Limited | Owner can cancel | Any valid key + 72h cooldown |
| Post-Quantum Ready | No | No | Dilithium-compatible attestations |
| Guardian Set Modification Delay | 36h | None | 48h with multi-channel alert |
07Implementation Roadmap
Core Ceremony Protocol
Deploy Recovery Registry contract on JIL L1. Implement guardian attestation protocol with Ed25519 signature verification. Enable 24-hour timelock enforcement at consensus level.
Multi-Channel Alerts
Integrate Alert Dispatcher with email (SES), SMS (Twilio), push (FCM/APNs), and on-chain event emission. Implement retry policies and delivery confirmation tracking.
MPC Integration
Enable recovery ceremonies that generate new MPC key sets. Coordinate with mpc-cosigner for shard distribution. Add guardian-assisted MPC re-keying flows.
Post-Quantum Migration
Transition guardian attestations to Dilithium signatures. Enable hybrid attestation mode supporting both Ed25519 and Dilithium during migration period. Full PQ readiness.