EstateVault: Threshold Digital Estate Planning

The Problem

Digital assets are locked forever when their owners die. Cryptocurrency wallets, password vaults, encrypted documents, and online accounts vanish with no recovery path. An estimated $140 billion in cryptocurrency is permanently inaccessible due to lost keys from deceased holders.

Traditional estate planning uses single executors — lawyers, family members, or cloud services — who hold complete access credentials. This creates four critical failures:

1. Single Point of Compromise

One corrupt or coerced executor can steal the entire digital estate before heirs ever know it existed. A single compromised password vault, lawyer's safe deposit box, or cloud service account exposes everything. There is no cryptographic enforcement preventing premature access.

2. No Trigger Guarantee

Who tells the executor when to release the assets? Death certificates take days to weeks. Incapacitation is ambiguous. The owner might be in a coma, held hostage, or traveling off-grid. False triggers from a single missed contact destroy trust. Late triggers mean assets remain locked while dependents wait.

3. Lost Keys Equal Lost Assets

Writing passwords in a will or safe deposit box creates plaintext exposure. Hardware wallets without recovery mechanisms are permanently inaccessible when the owner dies. Password managers lock out heirs. Cryptocurrency holdings vanish. Digital photo albums, business credentials, and intellectual property disappear.

4. Trustee Collusion Risk

If assets require multiple approvers, they can collude. Two conspirators in a three-person approval chain can bypass the third. Traditional multi-signature schemes provide procedural controls, not cryptographic impossibility.

The PRIVATE.ME Solution

EstateVault splits digital assets across designated trustees using XorIDA threshold sharing. A dead man's switch monitors periodic owner check-ins and triggers transfer only after consecutive missed intervals. No single trustee can reconstruct assets alone. Collusion below the threshold reveals zero information.

The asset owner calls storeAsset() to split passwords, seed phrases, documents, or keys into N shares distributed across trustees. The threshold K is configurable — for example, any 2-of-3 trustees must cooperate to recover assets. Below-threshold shares reveal mathematically zero information about the plaintext.

The dead man's switch requires the owner to checkIn() at regular intervals (configurable from 1 to 365 days). After a configurable number of consecutive missed check-ins (minimum 1, recommended 3), the switch triggers and trustees are notified. Trustees reconstruct assets by calling recoverAsset() with their shares. HMAC-SHA256 verification runs before reconstruction — if integrity fails, recovery aborts.

Key Properties

• No premature access: Trustees cannot reconstruct assets while the owner actively checks in. Threshold enforcement is cryptographic, not procedural.
• Configurable sensitivity: Number of consecutive missed check-ins is adjustable. 3 misses at 30-day intervals = 90-day dead man's switch.
• Information-theoretic security: Below-threshold shares reveal zero information. Not computationally hard — mathematically impossible.
• No single custodian: K-of-N trustees required. Single trustee compromise or coercion fails.
• Quantum-resistant: XorIDA operates over GF(2) with no computational assumptions. Quantum computers provide no advantage.

How It Works

The EstateVault lifecycle has three phases: vault creation, periodic check-in monitoring, and triggered recovery. Each phase produces cryptographic audit trails.

Phase 1: Vault Creation

The asset owner creates a DigitalAsset containing an identifier, type (password, seed-phrase, crypto-key, document), label, and data as a Uint8Array. An EstateVaultConfig defines trustees (each with id, name, contact), threshold K, dead man's switch parameters (check-in interval in days, missed check-ins before trigger), and owner ID.

import { storeAsset } from '@private.me/estatevault';

const asset = {
  id: 'btc-wallet',
  type: 'seed-phrase',
  label: 'BTC Cold Wallet',
  data: new TextEncoder().encode('abandon ability able...')
};

const config = {
  trustees: [
    { id: 'alice', name: 'Alice', contact: 'alice@example.com' },
    { id: 'bob', name: 'Bob', contact: 'bob@example.com' },
    { id: 'carol', name: 'Carol', contact: 'carol@example.com' }
  ],
  threshold: 2,  // Any 2-of-3 can recover
  deadManSwitch: {
    checkInIntervalDays: 30,
    lastCheckIn: new Date().toISOString(),
    missedCheckInsBeforeTrigger: 3,  // 3 consecutive misses = trigger
    armed: true
  },
  ownerId: 'owner-001'
};

const result = await storeAsset(asset, config);
if (!result.ok) throw new Error(result.error.message);

// result.value.shares contains AssetShare[] for each trustee
// Distribute shares via secure channels (email, physical paper, USB)

storeAsset() pads the asset data (PKCS#7), computes HMAC-SHA256 over the padded data, then splits it via XorIDA into N shares. Each trustee receives an AssetShare containing their share index, total shares, threshold, base64-encoded share data, base64-encoded HMAC (key+signature), and original size.

Phase 2: Check-In Monitoring

The owner must call checkIn() at least once per configured interval. This resets the dead man's switch timer and clears the missed check-in counter. Missing consecutive check-ins increments the counter. When the counter reaches missedCheckInsBeforeTrigger, the switch triggers.

import { checkIn, isTriggered, nextDeadline } from '@private.me/estatevault';

// Owner checks in -- resets switch
const updatedSwitch = checkIn(config.deadManSwitch);

// Check trigger status
if (isTriggered(updatedSwitch)) {
  console.log('Dead man\'s switch has triggered -- trustees can recover');
}

// Next required check-in deadline
const deadline = nextDeadline(updatedSwitch);
console.log(`Next check-in required by: ${deadline.toISOString()}`);

isTriggered() calculates the time since the last check-in, divides by the check-in interval to get the number of missed intervals, and returns true if missed intervals meet or exceed the trigger threshold. This logic is deterministic and verifiable by all trustees.

Phase 3: Triggered Recovery

Once the switch triggers, trustees can reconstruct the asset. At least K trustees provide their shares to recoverAsset(). The function verifies HMAC integrity before reconstruction. If HMAC fails, the operation aborts with HMAC_FAILED error. If reconstruction succeeds, the function unpads the data and returns the original DigitalAsset.

import { recoverAsset } from '@private.me/estatevault';

// Trustees Alice and Bob provide their shares (2-of-3)
const shares = [aliceShare, bobShare];

const recovered = await recoverAsset(shares);
if (!recovered.ok) {
  console.error(`Recovery failed: ${recovered.error.message}`);
  return;
}

// recovered.value is the original DigitalAsset
const seedPhrase = new TextDecoder().decode(recovered.value.data);
console.log(`Recovered BTC seed: ${seedPhrase}`);

Use Cases

Six scenarios where EstateVault replaces single-custodian estate planning with threshold cryptographic protection.

Integration

EstateVault provides five core functions for digital estate planning workflows. All operations return Result<T, E> for structured error handling.

Installation

# Install EstateVault
pnpm add @private.me/estatevault

# Peer dependencies (XorIDA crypto primitives)
pnpm add @private.me/crypto @private.me/shared

Developer Experience

EstateVault provides structured error codes with actionable hints and field attribution for debugging estate vault workflows.

Error Handling

All asynchronous operations return Result<T, EstateVaultError>. The EstateVaultError discriminated union provides seven error codes with descriptive messages. Each error is actionable — the message tells you exactly what went wrong and how to fix it.

const result = await storeAsset(asset, config);

if (!result.ok) {
  switch (result.error.code) {
    case 'INVALID_CONFIG':
      console.error('Configuration invalid:', result.error.message);
      // Show user which config field failed
      break;
    case 'SPLIT_FAILED':
      console.error('Asset splitting failed:', result.error.message);
      // Log error, retry with different asset data
      break;
    default:
      console.error('Unexpected error:', result.error);
  }
  return;
}

// Success path -- distribute shares to trustees
const shares = result.value.shares;

TypeScript Types

EstateVault is fully typed with strict TypeScript. All interfaces are exported for integration into estate planning applications.

interface DigitalAsset {
  id: string;        // Asset identifier
  type: string;      // password | seed-phrase | crypto-key | document
  label: string;     // Human-readable label
  data: Uint8Array;  // Asset bytes
}

interface Trustee {
  id: string;       // Trustee identifier
  name: string;     // Trustee name
  contact: string;  // Contact info (email, phone)
}

interface DeadManSwitch {
  checkInIntervalDays: number;           // 1-365 days
  lastCheckIn: string;                  // ISO 8601 timestamp
  missedCheckInsBeforeTrigger: number;  // Minimum 1
  armed: boolean;                       // Whether switch is active
}

interface EstateVaultConfig {
  trustees: Trustee[];             // Minimum 2 trustees
  threshold: number;               // K-of-N (>= 2, <= trustees.length)
  deadManSwitch: DeadManSwitch;    // Switch configuration
  ownerId: string;                 // Vault owner identifier
}

Security Properties

EstateVault inherits information-theoretic security from XorIDA threshold sharing and adds HMAC-SHA256 integrity verification plus dead man's switch authorization control.

Threat Model

In scope: Adversary who compromises K-1 trustees, corrupts shares, intercepts communication channels, observes check-in patterns, coerces individual trustees, or gains access to dead owner's devices. EstateVault provides cryptographic enforcement against all these threats.

Out of scope: Adversary who compromises K or more trustees simultaneously (threshold broken by design). Social engineering that convinces K trustees to collude (procedural, not cryptographic). Physical coercion of the asset owner before death (dead man's switch cannot protect against living coercion). Side-channel attacks on trustee devices after reconstruction (secure the endpoints).

Benchmarks

EstateVault inherits XorIDA's sub-millisecond performance for typical digital estate assets. Benchmarks measured on Node.js 20 (Apple M1 Pro).

Honest Limitations

EstateVault solves specific cryptographic and authorization problems. It does not solve every estate planning challenge. Here are the edges where EstateVault stops and other solutions are required.

1. Trustee Cooperation Required

EstateVault enforces K-of-N threshold cryptographically. But it cannot force trustees to cooperate. If K trustees refuse to provide shares, or lose their shares, the asset is permanently inaccessible. Choose trustees carefully. Consider geographic and relationship diversity. Store shares in durable formats (paper QR codes, metal engravings, encrypted USB drives).

2. No Legal Enforcement

EstateVault provides cryptographic access control, not legal authority. Reconstructed assets must still comply with probate law, tax regulations, and beneficiary rights. Consult an estate attorney to ensure digital asset succession aligns with legal requirements. EstateVault does not replace a will or trust — it complements them.

3. Switch Timing Is Approximate

The dead man's switch uses consecutive missed check-ins, not exact timestamps. If the owner checks in on day 29 of a 30-day interval, then dies, the switch won't trigger for 60+ days (miss interval 1, miss interval 2, miss interval 3 = trigger). This is a tradeoff for false-trigger prevention. Shorter intervals and lower miss thresholds reduce delay but increase false-trigger risk.

4. No Automatic Share Distribution

EstateVault splits assets into shares. You must distribute shares to trustees manually via secure channels (encrypted email, physical delivery, secure cloud storage). The package does not handle share delivery or storage. Integration with Xlink (secure M2M communication) or Xstore (split storage backends) can automate distribution, but those are separate packages.

5. Large Assets Are Slow

XorIDA is fast for typical estate assets (passwords, keys, seed phrases) but becomes a bottleneck for large files. A 100 MB file takes ~20 seconds to split and reconstruct. For large assets, store the file externally (IPFS, S3, physical media) and vault only the decryption key or access credentials. Do not vault multi-gigabyte files directly.

6. No Built-In Notification System

When the dead man's switch triggers, EstateVault does not send notifications to trustees. The package provides isTriggered() for polling, but you must build notification infrastructure (email, SMS, push notifications) separately. Consider integrating with existing notification services or building a monitoring dashboard for trustees.

7. Trustee Identity Not Verified

EstateVault stores trustee IDs, names, and contact info in plaintext (memory only, not persisted). It does not verify trustee identity cryptographically. A malicious actor who intercepts shares can impersonate a trustee. For high-value estates, integrate with Xid (cryptographic identity) or require trustees to prove identity via separate channels before accepting shares.

8. No Revocation or Key Rotation

Once shares are distributed, there is no built-in revocation mechanism. If a trustee becomes untrustworthy, you must create a new vault with different trustees and destroy the old shares. This is manual and error-prone. Procedural controls (trustee agreements, legal contracts) are required to handle trustee removal scenarios.

Verifiable Estate Protection

Every EstateVault operation produces verifiable audit trails via Xprove. HMAC-chained integrity proofs let auditors and trustees confirm assets were split, stored, and reconstructed correctly without accessing the plaintext data.

Ready to deploy EstateVault?

Talk to Sol, our AI sales engineer, or book a live demo with our team.