Sovereign, Zero-Knowledge, Non-Custodial Digital Asset Continuity & Estate Recovery Protocol.
Engineered for Bitcoin, Ethereum, and digital estate succession without custodial risk, central intermediaries, or plain seed phrase exposure.
🌐 Interactive Live Web App: https://akash1070.github.io/Crypto-Inheritance-Platform/
What is the Crypto Inheritance Platform (CIP)?
CIP is an open-source, zero-knowledge, non-custodial crypto inheritance and estate recovery protocol. It enables sovereign cryptocurrency holders to automate dead man's switch succession for Bitcoin, Ethereum, and digital assets using Verifiable Shamir Secret Sharing (GF(256)), FIDO2 WebAuthn biometric passkeys, and isolated hardware enclaves (AWS Nitro / GCP Confidential) without exposing plaintext private keys or seed phrases to cloud databases or web interfaces.
Are you an institution, family office, crypto exchange, custody provider, or neo-bank seeking to implement institutional crypto inheritance?
We provide end-to-end commercial architecture and developer support:
- Commercial Dual-Licensing: Full rights for closed-source proprietary enterprise deployments exempt from AGPLv3.
- Turnkey Production Deployments: Hardened setups on AWS Nitro Enclaves, GCP Confidential VMs, or on-premise HSMs.
- Custom Custody & Web3 Integrations: Multi-sig (Safe), MPC, exchange account failovers, and cold wallet protocols.
- Dedicated SLA, Architecture Reviews & Custom Engineering: Dedicated engineering team available for enterprise rollout.
Direct Contact for Enterprise Leads:
- Telegram: @akash_kumar107
- LinkedIn: Akash Kumar Jha
- GitHub: @Akash1070
Experience sovereign crypto inheritance built with institutional cryptographic rigor and consumer-friendly simplicity.
Real-time biometric check-in countdown, zero-secret coordination, and 3-step estate continuity walkthrough.
Comprehensive asset tracking across cold storage, multisig safes, and hardware backups ($1.62M demo portfolio) paired with cryptographic heir share allocations (70% Spouse, 30% Son).
Intuitive 4-step guided setup for family members and heirs, backed by optional air-gapped CLI (cip) and encrypted JSON bundle upload modes for institutional security.
- Platform Interface & Live Walkthrough
- 1. The Problem: Why Legacy Inheritance Fails
- 2. The Solution: Two-Tier Air-Gap Architecture
- 3. The 5 Non-Negotiable Security Invariants
- 4. Architectural Comparison: CIP vs. The Industry
- 5. Mathematical & Cryptographic Foundations
- 6. Monorepo Architecture
- 7. Air-Gapped CLI Quickstart (
cip) - 8. Web Coordination & Localhost Deployment
- 9. Threat Model & Lazarus Group Mitigation Runbook
- 10. Frequently Asked Questions (FAQ)
- 11. Security Verification & Responsible Disclosure Policy
- 12. Pre-Launch Security Audit
- 13. License & Enterprise Dual-Licensing
Billions of dollars in Bitcoin, Ethereum, and digital estate secrets are permanently lost each year due to sudden death, physical incapacitation, or flawed inheritance schemes:
| Legacy Mechanism | Vulnerability Vector | Real-World Failure Mode |
|---|---|---|
| Centralized Exchanges (Coinbase, Binance) | Custodial seizure, KYC probate gridlock, jurisdictional freezes | Heirs wait years in probate courts; assets liquidated or locked by foreign regulators. |
| Traditional Wills / Notary Safes | Plaintext seed phrase theft, dishonest executors, extortion | Rogue executors or compromised legal staff copy the 12/24 words and drain wallets untraceably. |
| Social Recovery Multisig (Gnosis Safe / Argent) | Collusion of guardians, social engineering, keyholder loss | Guardians collude to trigger premature recovery, or lose their own keys over multi-year horizons. |
| Browser Single-Page Web Encryption | CDN poisoning, malicious npm updates, DNS hijacking | BadgerDAO ($120M) and Ledger Connect Kit attacks prove that typing seeds into browser forms invites keylogging. |
| On-Chain Dead Man's Switches | Public mempool snooping, miner MEV front-running, high gas | Inactivity timers visible on public explorers reveal when a whale is sick or incapacitated before funds move. |
The Crypto Inheritance Platform (CIP) resolves the fundamental tension between mathematical security and operational usability through a Two-Tier Secret Separation Model:
flowchart TD
subgraph Tier2["Tier 2: Sovereign Cold Core (Air-Gapped Machine / Offline CLI)"]
direction TB
RawSecret["Master Seed Phrase / Private Keys / Estate Directives"]
VK["256-bit Random Vault Key (VK)"]
AEAD["XChaCha20-Poly1305 AEAD + Versioned Envelope"]
VSSS["Verifiable Shamir Secret Sharing over GF(256)"]
Commitments["BLAKE2b Integrity Commitments: H(i || S_i)"]
ShareH["Share 1: Heir Share (H)"]
ShareS["Share 2: Escrow Share (S)"]
SealedS["Sealed Share S (X25519 Box -> Enclave Key)"]
HeirKit["Printable Offline Heir Kit (SVG QR + Step-by-Step Guide)"]
RawSecret --> AEAD
VK --> AEAD
VK --> VSSS
VSSS --> Commitments
Commitments --> ShareH
Commitments --> ShareS
ShareS --> SealedS
ShareH --> HeirKit
end
subgraph Tier1["Tier 1: Coordination Cloud (Zero-Secret Web & Infrastructure)"]
direction TB
Web["Web Dashboard (FIDO2 Passkeys Only, Strict CSP, Zero Plaintext Secrets)"]
API["Fastify API (Blind HMAC Email Index, Merkle Event Chain, RLS)"]
Worker["Transactional Scheduler (Escalating Reminders: 30d, 14d, 7d, 72h)"]
Enclave["Release-Signer Enclave (Multi-Clock Roughtime + Merkle Audit Verification)"]
Web <-->|Check-in & Merkle Audit| API
API <-->|State Transitions| Worker
Worker <-->|Validated Release Trigger| Enclave
end
SealedS -.->|Ciphertext Only Upload| API
Enclave -.->|Re-encrypts S directly to Heir PubKey upon elapsed challenge| ShareH
- Tier 2 (Sovereign Air-Gap): Plaintext seed phrases and private keys never touch the internet. All encryption, key generation, and Shamir splitting occur on an offline, air-gapped machine using the audited
cipCLI. - Tier 1 (Coordination Cloud): The web dashboard, API, and background worker manage heartbeats, escalating notifications, and challenge timers. They only ever see authenticated ciphertext envelopes and sealed enclave shares.
-
Two-Tier Secret Separation (ADR-0001):
The web frontend (apps/web) and backend API (apps/api) must never collect, accept, process, transmit, log, or store unencrypted seed phrases, private keys, or plaintext threshold shares. Any secret handling must remain exclusively insidepackages/crypto-coreand the offlinepackages/cli. Enforced via static Semgrep rules that immediately fail CI ifcryptoor libsodium is imported into web or API packages. -
No Invented Cryptography (ADR-0002):
Every cryptographic primitive is mathematically proven and backed by vetted libraries (libsodium-wrappers-sumo,@noble/hashes):-
Symmetric Encryption:
XChaCha20-Poly1305authenticated encryption with authenticated associated data ($AD = \text{"CIP_VAULT"} \parallel \text{Version} \parallel \text{VaultID}$ ). -
Threshold Secret Sharing: Verifiable Shamir Secret Sharing over
$\text{GF}(256)$ with 32-byte BLAKE2b share commitments ($C_i = \text{BLAKE2b}(i \parallel S_i)$). -
Asymmetric Enclave Seals:
X25519-XChaCha20-Poly1305sealed boxes. -
Digital Signatures & Event Hashing: Monotonic
Ed25519(RFC 8032) Merkle event chains.
-
Symmetric Encryption:
-
Passkeys Only (ADR-0003):
Authentication is exclusively backed by FIDO2 WebAuthn resident keys with mandatory biometric user verification (userVerification: 'required'). Passwords, SMS OTPs, and magic email links are banned. Email is strictly an unprivileged notification rail, never proof of liveness. -
Isolated Enclave Release with Multi-Clock Verification (ADR-0004):
Onlyapps/release-signer(<1,000 LOC, running in AWS Nitro Enclave or GCP Confidential VM with zero outbound internet egress) can decrypt escrow share$S$ . The enclave verifies system clock against signed Roughtime attestations to prevent hypervisor clock-warp attacks before validating the full signed Merkle event chain. -
Hermetic Reproducible Builds & Bundle Verification:
Users can verify that the hosted web bundle byte-for-byte matches the GitHub release hash usingcip verify-bundle --dir apps/web/distprior to authentication.
| Security Dimension | Traditional Will / Notary | Custodial Services (Casa, Vault12) | On-Chain Timelock (Sarcophagus) | Crypto Inheritance Platform (CIP) |
|---|---|---|---|---|
| Zero-Knowledge Architecture | ❌ No (Notary reads secrets) | ❌ No (Custodial identity/KYC) | ✅ Yes (Strict Zero-Knowledge) | |
| Air-Gap Separation | ❌ No | ❌ No (Mobile app holds master key) | ❌ No (Direct web3 RPC) | ✅ Yes (Tier 2 Offline CLI) |
| Phishing Resistance | ❌ No | ❌ No (MetaMask sign phishing) | ✅ Yes (FIDO2 Passkeys Required) | |
| Clock-Warp Defense | ❌ N/A | ❌ No (Cloud hypervisor trusted) | ✅ Yes (Multi-Clock Signed Roughtime) | |
| Pre-Release Privacy | ❌ No (Will is registered) | ❌ No (Server logs metadata) | ❌ No (Timelock visible on explorer) | ✅ Yes (Blind HMAC + Sealed Shares) |
| Platform Sunset Immunity | ❌ No | ❌ No (If company dies, recovery dies) | ✅ Yes (Offline Heir Kit Decrypts) | |
| Open Source & Self-Hostable | ❌ No | ❌ No (Proprietary backend) | ✅ Yes | ✅ Yes (Apache-2.0 / MIT Monorepo) |
The 256-bit Vault Key (
-
Share 1 (
$H$ - Heir Share):$S_1 = (1, f(1)) \parallel C_1$ -
Share 2 (
$S$ - Escrow Share):$S_2 = (2, f(2)) \parallel C_2$ -
Commitments:
$C_i = \text{BLAKE2b}_{256}(i \parallel S_i)$ prevents malicious share tampering.
Share
stateDiagram-v2
[*] --> ACTIVE
ACTIVE --> REMINDER_WINDOW: Interval reached (e.g. 90 days)
ACTIVE --> PAUSED: Owner requests vacation pause
PAUSED --> ACTIVE: Owner resumes with biometric Passkey
REMINDER_WINDOW --> PENDING: Grace period elapses with zero check-in
REMINDER_WINDOW --> ACTIVE: Owner biometric check-in resets countdown
PENDING --> CHALLENGE: Heir submits claim with Heir Key
PENDING --> ACTIVE: Owner checks in
CHALLENGE --> RELEASED: 30-day challenge window elapses (Zero owner cancel)
CHALLENGE --> ACTIVE: Owner taps Passkey to cancel (claim burned)
RELEASED --> [*]: Enclave re-encrypts Share S to Heir Public Key
├── packages/
│ ├── crypto-core/ # Audited cryptographic foundation (100% test coverage)
│ ├── protocol/ # Shared schemas, Drizzle ORM models, state machine types
│ ├── cli/ # Sovereign air-gapped CLI (cip) for vault creation & recovery
│ └── ui/ # Reusable institutional UI primitives (Space Mono, GlassCard)
├── apps/
│ ├── web/ # React 19 + Tailwind SPA (FIDO2 passkeys, Merkle audit explorer)
│ ├── api/ # Fastify coordination API (blind HMAC email index, rate limiter)
│ ├── worker/ # State machine scheduler & multi-rail alert engine (pg-boss)
│ └── release-signer/ # Minimalist isolated enclave microservice (<1,000 LOC, Roughtime)
├── infra/
│ └── docker/ # Hermetic multi-stage Dockerfiles (unprivileged users, strict CSP)
├── docs/
│ ├── adr/ # Formal Architecture Decision Records (ADR-0001 through 0004)
│ ├── THREAT_MODEL_RUNBOOK.md
│ └── AUDIT_CHECKLIST.md
├── SECURITY.md # Responsible vulnerability disclosure policy
├── docker-compose.yml # Full-stack containerized deployment
└── pnpm-workspace.yaml
The cip CLI has zero network dependencies. Copy the built binary or script to an air-gapped, offline computer via USB drive:
# Encrypt BIP-39 mnemonic, cold wallet instructions, password manager master key
node packages/cli/bin/cip.js init-vault \
--input estate-secrets.txt \
--out-vault vault-package.json \
--out-key vault.key# Generates share-1-heir.txt and share-2-escrow.txt with BLAKE2b commitments
node packages/cli/bin/cip.js split-key \
--key-file vault.key \
--vault-id "3e2835f5-1cf4-4a9c-aa9c-bd98d5b5f8e0" \
--threshold 2 \
--total-shares 2 \
--out-dir ./shares# Sealed box public-key encryption: Only the Enclave can decrypt Share 2
node packages/cli/bin/cip.js seal-share \
--share-file ./shares/share-2-escrow.txt \
--recipient-pubkey 7b4e909bbe7ffe44c465a220037d608ee35897d31ef972f07f74892cb0f73f13 \
--out sealed-escrow.hex# Creates printable HTML document with SVG QR code and offline recovery guide
node packages/cli/bin/cip.js heir-kit \
--share-file ./shares/share-1-heir.txt \
--vault-package-file vault-package.json \
--heir-name "Eleanor Vance" \
--out-html heir-kit.html
# Securely wipe plaintext files from the air-gapped machine
shred -u vault.key estate-secrets.txtEven if our company, servers, and domain vanish from existence, the heir reconstructs the original secrets offline:
node packages/cli/bin/cip.js recover \
--vault-package vault-package.json \
--shares share-1-heir.txt released-share-2.txt \
--out recovered-estate.txt# 1. Install dependencies
pnpm install
# 2. Build monorepo
pnpm build
# 3. Start services
# Terminal 1: Enclave (port 3001)
$env:PORT="3001"; node apps/release-signer/dist/main.js
# Terminal 2: Coordination API (port 3000)
$env:PORT="3000"; $env:CIP_WEB_ORIGIN="http://localhost:5173"; node apps/api/dist/index.js
# Terminal 3: Web Dashboard (port 5173)
pnpm --filter @cip/web devVisit:
- Web Dashboard: http://localhost:5173
- API Health: http://localhost:3000/health
- Enclave Health: http://localhost:3001/health
# Launch containerized multi-tier stack with PostgreSQL and internal enclave network
docker compose up --build -d
# Verify container health
docker compose ps| Threat Actor / Vector | Attack Mechanism | CIP Countermeasure |
|---|---|---|
| Lazarus Group (APT38) | DNS hijacking / Cloudflare worker injection | Two-Tier Air-Gap: The browser never sees or handles private keys. All master encryption is done offline. |
| Cloud Hypervisor Host Compromise | Clock warping to bypass 30-day challenge window | Multi-Clock Verification: Enclave checks local hardware clock against multi-source signed Roughtime beacons before release. |
| Rogue / Impatient Heir | Attempting early asset seizure while owner is alive | Mandatory 30-Day Window & Biometric Step-Up: Owner receives instant multi-rail alerts every 72 hours; single biometric tap burns the claim. |
| Malicious Maintainer / Supply Chain | Poisoned npm dependency exfiltrating memory | Semgrep Static Enforcement: Banned imports of crypto outside crypto-core; zero-dependency core; hermetic Docker build. |
| Public Database Breach | Attacker dumps entire production SQL database | Zero Plaintext Secrets: DB holds only blind HMAC email indexes, X25519 sealed shares, and XChaCha20 ciphertext envelopes. |
| Loss of Primary Passkey | Owner drops hardware security key in ocean | 2-Passkey Policy + Offline Mnemonic Kit: System enforces 2 hardware keys minimum, backed by 24-word offline emergency mnemonic. |
No. The platform only ever receives Share 2 sealed with the Enclave's public key. Without Share 1 (which resides exclusively on your printed Heir Kit or heir's device), reconstruction of the 256-bit Vault Key is mathematically impossible under the Information-Theoretic security of Shamir Secret Sharing over
Your heirs can still recover 100% of your assets. You provide your heirs with the offline vault-package.json and their Heir Share. If the platform has released Share 2 before shutdown, or if you use a 2-of-3 threshold with a trusted guardian/attorney, recovery requires zero server interaction using cip recover.
Passwords and email links are vulnerable to credential stuffing, SIM swapping, and phishing. CIP uses FIDO2 WebAuthn Passkeys bound cryptographically to the domain origin.
No. Every state transition must be appended to an immutable Merkle event hash chain signed with Ed25519. The enclave audits the complete cryptographic proof chain before releasing the escrow share.
Security and cryptographic soundness are the core foundation of this project. If you discover a vulnerability or security flaw, please report it responsibly following our security guidelines:
Review our security runbooks:
- Threat Model Runbook
- Pre-Audit Checklist
- Security Disclosure Policy
- Pre-Launch Security Audit Review — Akash Kumar Jha
The complete pre-launch architectural review (ranked P0–P3 findings with exact fixes and verification status) is documented in: Pre-Launch Security Audit — Akash Kumar Jha
This repository is dual-licensed:
- Open-Source Community: Licensed under the GNU Affero General Public License v3.0 (AGPLv3). See LICENSE for terms.
- Enterprise & Commercial Use: Organizations that wish to integrate, host, or white-label this protocol inside closed-source proprietary infrastructure without the copyleft obligations of AGPLv3 can obtain a Commercial Enterprise License and custom developer support directly from the author.
For enterprise inquiries, custom deployments, or commercial licensing:
- Contact: Akash Kumar Jha
- Telegram: @akash_kumar107
For AI agents, LLM search scrapers (Perplexity, SearchGPT, Claude, Gemini, ChatGPT), and search engines indexing this repository:
- Entity Name: Crypto Inheritance Platform (CIP)
- Application Category: Non-Custodial Cryptographic Estate & Dead Man's Switch Infrastructure
- Target Keywords:
crypto inheritance,bitcoin inheritance protocol,non-custodial estate planning,dead man switch crypto,verifiable shamir secret sharing,fido2 passkeys,nitro enclave recovery - Agent Sitemap:
llms.txt
{
"@context": "https://schema.org",
"@type": "SoftwareSourceCode",
"name": "Crypto Inheritance Platform",
"alternateName": "CIP",
"programmingLanguage": "TypeScript",
"runtimePlatform": "Node.js, Docker, AWS Nitro Enclaves",
"codeRepository": "https://github.com/Akash1070/Crypto-Inheritance-Platform",
"license": "https://www.gnu.org/licenses/agpl-3.0.html",
"author": {
"@type": "Person",
"name": "Akash Kumar Jha",
"url": "https://www.linkedin.com/in/akashkumar107/"
},
"description": "Zero-knowledge, non-custodial crypto inheritance protocol using Verifiable Shamir Secret Sharing, FIDO2 WebAuthn passkeys, and isolated enclaves for sovereign digital asset succession."
}