Decentralized Custody Marketplace

01Executive Summary

The Decentralized Custody Marketplace is an on-chain registry of approved custody providers that enables institutional users to distribute assets across multiple custodians with aggregated protection coverage. Instead of relying on a single custody provider - and accepting the counterparty concentration risk that entails - institutions can split holdings across providers whose coverage amounts combine additively.

The marketplace maintains verified profiles for each custody provider including coverage limits, jurisdictional licenses, supported asset types, historical uptime, and real-time liveness status. Hourly liveness probes monitor every registered provider, and automatic failover triggers asset migration via 2-of-3 multi-sig within 15 minutes when a provider becomes unresponsive.

02Problem Statement

Institutional crypto custody concentrates assets and risk with a single provider. When that provider fails - as FTX, Celsius, and Voyager demonstrated - clients lose access to all custodied assets simultaneously. Even regulated custodians carry concentration risk that traditional finance mitigates through multi-bank relationships.

2.1 Single-Custodian Risk

2.2 Current Custody Limitations

• Single Point of Failure: One custodian holds all assets. Operational failure, regulatory seizure, or insolvency affects 100% of holdings.
• Coverage Gaps: Individual custodian insurance typically caps at $250M aggregate (shared across all clients), not per-client.
• No Automatic Failover: When a custodian goes offline, clients must manually initiate asset migration - a process that can take days to weeks during a crisis.
• Opaque Provider Quality: No standardized registry for comparing custody providers on uptime, security incidents, coverage terms, or jurisdictional compliance.
• Lock-In: Migrating between custody providers requires complex legal and technical coordination, creating vendor lock-in.

03Technical Architecture

3.1 Provider Registry

3.2 Coverage Aggregation Model

When a user distributes assets across multiple providers, coverage limits aggregate additively. For example, distributing $15M across three providers with $5M coverage each yields $15M total coverage. The on-chain registry tracks the exact allocation per provider and computes the aggregate coverage in real time.

// Coverage aggregation example
{
  "user": "jil1abc...def",
  "total_assets_usd": 15000000,
  "allocations": [
    {"provider": "CustodyProvider-A", "amount_usd": 5000000, "coverage_usd": 5000000},
    {"provider": "CustodyProvider-B", "amount_usd": 5000000, "coverage_usd": 3000000},
    {"provider": "CustodyProvider-C", "amount_usd": 5000000, "coverage_usd": 7000000}
  ],
  "aggregate_coverage_usd": 15000000,
  "coverage_ratio": 1.0
}

3.3 Liveness Probe System

Every registered provider is probed hourly through a standardized health check protocol. The probe verifies API availability, signing capability (test transaction signature), and asset balances (proof-of-reserves). Providers that fail three consecutive probes transition to DEGRADED status. Providers offline for more than 4 hours trigger automatic failover procedures.

04Implementation

4.1 Automatic Failover Protocol

1. Detection: Liveness probe system detects provider OFFLINE status (3 consecutive probe failures over 3 hours).
2. Alert: User notified via wallet push notification and on-chain event. Failover countdown begins (1 hour grace period for provider recovery).
3. Target Selection: Marketplace engine selects optimal migration target based on: available coverage capacity, jurisdiction match, asset support, and current uptime score.
4. Migration Initiation: 2-of-3 multi-sig transaction initiated (user shard + platform shard). Assets begin transferring from offline provider's escrow to target provider.
5. Completion: Migration completes within 15 minutes. On-chain allocation records updated. New coverage aggregation computed. Proof posted to bulletin board.

4.2 Provider Onboarding

05Integration with JIL Ecosystem

5.1 MPC Cosigner

The MPC cosigner service (port 8200) manages the signing ceremonies for asset migration transactions. When failover is triggered, the cosigner initiates a priority signing round using the user's Shard A and the platform's Shard B, bypassing normal transaction queue priorities to ensure rapid migration completion.

5.2 Protection Coverage Registry

The custody marketplace integrates with the on-chain protection coverage registry (Claim 06). Aggregated coverage across multiple providers is reflected in the user's policy record. If a provider fails and migration succeeds, coverage continues seamlessly with the new provider. If migration fails, the coverage payout mechanism activates.

5.3 Compliance Zones

Provider selection respects compliance zone boundaries. A user registered in the DE_BAFIN zone can only allocate assets to providers licensed in compatible jurisdictions. Cross-jurisdiction allocations require corridor approval from the corridor switchboard.

5.4 Proof Bulletin Board

Every provider onboarding, liveness status change, failover event, and migration completion is recorded as an audit receipt on the proof bulletin board. This creates a permanent, verifiable history of all custody marketplace operations.

06Prior Art Differentiation

07Implementation Roadmap

08Patent Claim