Concepts
Will Transfer Protocol
Detailed of what happens when a will explanation is triggered — from survivor notification to document access.
Will Transfer Protocol
The Will Transfer Protocol defines exactly what happens when a will is activated — either through automated liveness check failure or survivor-initiated transfer.
Trigger Conditions
A will transfer can be triggered in two ways:
1. Automated Trigger (Liveness Failure)
After the host misses HCRAC consecutive liveness checks:
- HCIT (check interval) passes without response
- HCRT (response time) × HCRAC (retry attempts) expires
- Host is marked as "presumed dead"
2. Survivor-Initiated Trigger
Any survivor can initiate the transfer manually if they believe the host has died:
- Survivor verifies via OTP
- Transfer process begins immediately
- Host is notified and can cancel within HCRT
Transfer States
A will goes through these states during transfer:
| State | Description |
|---|---|
active | Normal state — host is alive |
pending_transfer | Triggered but awaiting confirmation period |
transfer_initiated | Transfer officially started |
awaiting_authentication | Survivors authenticating |
accessible | Threshold met, documents available |
transfer_stalled | Not enough survivors authenticated (30+ days) |
transfer_failed | Insufficient authentication after 90 days |
Step-by-Step Flow
Phase 1: Transfer Initiation
┌─────────────────────────────────────────────────────────────────┐
│ PHASE 1: INITIATION │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. Trigger condition met │
│ │
│ 2. All survivors notified: │
│ "The host of the will '[will name]' has not responded │
│ to liveness checks. The will transfer process has │
│ been initiated." │
│ │
│ 3. Survivor portal opens for authentication │
│ │
│ 4. Host (if alive) can cancel within HCRT │
│ │
│ 5. Transfer status → "transfer_initiated" │
│ │
└─────────────────────────────────────────────────────────────────┘Phase 2: Survivor Authentication
┌─────────────────────────────────────────────────────────────────┐
│ PHASE 2: AUTHENTICATION │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Each survivor must verify their identity: │
│ │
│ 1. Access Survivor Portal │
│ │
│ 2. Select their name from the will's survivor list │
│ (Names only — no contact details shown publicly) │
│ │
│ 3. OTP sent via their primary connector: │
│ - Try primary channel │
│ - Fall back to secondary if failed │
│ - If all fail, prompt for backup code │
│ │
│ 4. Enter 6-digit OTP (10-minute expiry) │
│ - 3 attempts per OTP │
│ - Max 5 OTP requests per hour per survivor │
│ │
│ 5. Or use backup code (single-use) │
│ │
│ 6. Successful verification → SSS share decrypted in memory │
│ │
│ 7. Authentication progress displayed: │
│ "2 of 3 survivors authenticated" │
│ │
└─────────────────────────────────────────────────────────────────┘Phase 3: Threshold Met
┌─────────────────────────────────────────────────────────────────┐
│ PHASE 3: THRESHOLD MET │
├─────────────────────────────────────────────────────────────────┤
│ │
│ When K survivors have authenticated: │
│ │
│ 1. Server collects decrypted SSS shares from memory │
│ │
│ 2. Lagrange interpolation reconstructs DEK │
│ │
│ 3. Documents decrypted │
│ │
│ 4. SHA-256 hashes verified │
│ │
│ 5. If hash mismatch → alert all survivors, provide anyway │
│ │
│ 6. Will status → "accessible" │
│ │
│ 7. All authenticated survivors can: │
│ - View personal message from host │
│ - Download documents │
│ - Verify integrity │
│ │
│ 8. Access window begins (default: 7 days) │
│ │
└─────────────────────────────────────────────────────────────────┘Phase 4: Document Access
Authenticated survivors see:
┌─────────────────────────────────────────────────────────────────┐
│ SURVIVOR ACCESS PORTAL │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Personal Message from Host │ │
│ │ ─────────────────────────────────────────────── │ │
│ │ "Dear Family, │ │
│ │ │ │
│ │ If you're reading this, I'm gone. I wanted to │ │
│ │ make sure you had access to these important │ │
│ │ documents. I love you all..." │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Your Documents │ │
│ │ ─────────────────────────────────────────────── │ │
│ │ │ │
│ │ 📄 last_will_and_testament.pdf 2.4 MB ✅ Verified │ │
│ │ 📄 insurance_policy_details.pdf 1.1 MB ✅ Verified │ │
│ │ 📄 account_passwords.odt 340 KB ✅ Verified │ │
│ │ │ │
│ │ [Download All] [View Individual] │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ ⚠️ Access expires in 5 days, 12 hours │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘Authentication Details
OTP Delivery
| Channel | Typical Delivery | Fallback |
|---|---|---|
| < 30 seconds | SMS | |
| SMS | < 10 seconds | |
| < 10 seconds | Telegram | |
| Telegram | < 10 seconds |
OTP Security
- 6 digits — 1 million possible codes
- 10-minute expiry — Time window for entry
- 3 attempts — Per OTP session
- Rate limiting — Max 5 OTP requests per hour per survivor
- Hashed storage — OTPs hashed with Argon2
Backup Codes
Each survivor has 5 backup codes:
- Format: 8-character alphanumeric (e.g.,
A3F7-K9M2) - Single-use — Marked as consumed after use
- Irreversible — Hash stored, can't be recovered
- Regeneration — Host can regenerate (invalidates old codes)
Failure Scenarios
Insufficient Survivors
If fewer than K survivors authenticate within 30 days:
- Status → "transfer_stalled"
- Weekly reminders sent to unauthenticated survivors
- After 90 days → "transfer_failed"
Document Integrity Failure
If SHA-256 hash doesn't match during decryption:
- Alert all authenticated survivors
- Log security incident
- Still provide access with warning
- Document may have been tampered with
Storage Unavailable
If storage provider is disconnected during transfer:
- Use cached presigned URLs if available
- Notify host to reconnect (if alive)
- May delay transfer until storage restored
Access Window
Once threshold is met, survivors have 7 days (configurable) to access documents.
After the window expires:
- Documents are re-encrypted
- SSS shares are redistributed
- Will returns to active state (if host revived)
Cancellation
Host Cancellation
If triggered but host is alive:
- Host logs into dashboard
- Clicks "Cancel Transfer"
- All survivors notified
- Will status returns to "active"
- Normal liveness checks resume
Limitations
- Host can only cancel during
transfer_initiatedstate - After threshold is met, cancellation is no longer possible
Complete Flow Diagram
┌─────────────────────────────────────────────────────────────────┐
│ │
│ ┌──────────┐ ┌─────────────────┐ ┌──────────────────┐ │
│ │ ACTIVE │───►│ PENDING_TRANSFER│───►│TRANSFER_INITIATED │ │
│ └──────────┘ └─────────────────┘ └──────────────────┘ │
│ ▲ │ │
│ │ ▼ │
│ │ ┌─────────────────────────────────┐ │
│ │ │ SURVIVORS AUTHENTICATING │ │
│ │ │ Each survivor verifies OTP │ │
│ │ │ Server collects SSS shares │ │
│ │ └─────────────────────────────────┘ │
│ │ │ │
│ │ ▼ │
│ │ ┌─────────────────────────────────┐ │
│ │ │ THRESHOLD MET (K of N) │ │
│ │ │ - Reconstruct DEK │ │
│ │ │ - Decrypt documents │ │
│ │ │ - Verify hashes │ │
│ │ └─────────────────────────────────┘ │
│ │ │ │
│ │ ▼ │
│ │ ┌─────────────────────────────────┐ │
│ │ │ ACCESSIBLE │ │
│ │ │ Survivors download docs │ │
│ │ │ Access window expires │ │
│ │ └─────────────────────────────────┘ │
│ │ │ │
│ │ ▼ │
│ │ ┌─────────────────────────────────┐ │
│ │ │ RE-SEALED (or STALLED/FAILED) │ │
│ │ └─────────────────────────────────┘ │
│ │ │
│ └──────────────────────────────────────────────────────┘FAQ
Can survivors coordinate with each other?
Yes. The portal shows progress (e.g., "2 of 3 survivors authenticated"). Survivors can see who has authenticated but not their contact information.
What if survivors can't receive OTP?
They can use backup codes. If they have neither OTP access nor backup codes, they cannot authenticate.
Can the host cancel after survivors authenticate?
No. Once the threshold is met, the transfer is final. This prevents a malicious host from canceling after survivors have already invested effort.
How long does the entire process take?
- If survivors respond quickly: 24-48 hours from first authentication to access
- If survivors are unavailable: Up to 30 days before "stalled", 90 days before "failed"
Is there a way to expedite transfer?
Survivors can all authenticate quickly by:
- Checking their email/SMS regularly
- Using backup codes if OTP delivery fails
Next Steps
- Receiving Access — What survivors experience
- OTP Verification — Detailed authentication guide
- Accessing Documents — Downloading and verifying