Docs Center

EternVault User Guide & Security Model

EternVault is a decentralized digital inheritance system. Core principles: auditable on-chain state, client-side encryption for private body, key-layer isolation, and beneficiary key retrieval only after inheritance signal.

Unified Terms (A / B / C)

Symbol A

Content Decryption Key (AES Session Key)

A reversible key generated locally in browser each time private content is created/updated. A is dedicated to encrypting private body.

Stored at: Never stored in plaintext; appears only in encrypted form inside C.

Symbol B

Encrypted Private Body

Ciphertext generated by encrypting private body with A. Without A, B cannot be restored to plaintext.

Stored at: Published on blockchain only (visible, auditable, tamper-resistant). Platform does not store B.

Symbol C

Beneficiary Key Capsule

Result of encrypting key A with beneficiary wallet public key. Only matching beneficiary private key can decrypt C and recover A.

Stored at: Stored in platform backend Vault (without private body).

Note: A/B/C are educational aliases used in docs only. They are not on-chain field names or DB column names.

Security Flow Summary (6 Steps)

1) Testator locally generates A. 2) Private body is encrypted by A to get B, and B is written on-chain. 3) A is encrypted by beneficiary public key to get C, and C is stored on platform. 4) Only when status is SignalEmitted and identity checks pass, beneficiary can retrieve C. 5) Beneficiary decrypts C locally using private key to recover A. 6) Beneficiary decrypts on-chain B with A to recover plaintext.

Testator

The will owner who configures beneficiary, heartbeat period, public note, and optional secret vault content.

Beneficiary

The designated recipient in the will. Can retrieve key capsule and run decryption flow only after inheritance signal and identity checks.

How the System Works

01 Create Will

Testator submits will and parameters on-chain.

02 Maintain Heartbeat

Update heartbeat before deadline to keep Active status.

03 Enter Waiting Window

After timeout, enter death confirmation period to reduce false trigger risk.

04 Emit Inheritance Signal

After SignalEmitted, beneficiary can retrieve key capsule.

Security Capability Notes

Tamper-Resistant On-Chain State

Will status, beneficiary settings, heartbeat, and trigger process are constrained by contracts. Every update is an auditable on-chain transaction.

Client-Side Private Encryption

Private body plaintext is processed only in user browser. Platform backend does not receive private plaintext.

Layered Key Isolation

Chain stores B only; backend stores C only. B and C are isolated so either side alone cannot restore plaintext.

Key Retrieval Only After Signal

Backend API enforces SignalEmitted status and beneficiary identity before returning C.

Figure 1: Private Will Data Layering

User Browser (Local)

Generate key and encrypt

Private plaintext -> encrypt with A to get B
Encrypt A with beneficiary public key to get C

↓

On-Chain Contract Metadata

Store only ciphertext B

Public note (plaintext if provided)
B = private ciphertext body (plaintext not directly readable)

+

Platform Backend Vault

Store only C

C = A encrypted by beneficiary public key
Cannot decrypt C without beneficiary private key

Figure 2: Post-Signal Retrieval & Decryption Sequence

Participant

Beneficiary Wallet

Participant

EternVault API

Participant

WillRegistry Contract

Participant

On-chain Ciphertext B

  1. 1.Contract status reaches SignalEmitted.
  2. 2.Beneficiary signs in and requests key retrieval via API.
  3. 3.API verifies on-chain status and beneficiary identity before returning C.
  4. 4.Beneficiary decrypts C locally with private key to recover A.
  5. 5.Beneficiary decrypts on-chain B using A to recover plaintext.

Key point: the platform never needs beneficiary private key and cannot decrypt on behalf of beneficiary, so it cannot recover A or plaintext.

Key Retrieval Gates (Backend Hard Checks)

  • •On-chain status check: must be SignalEmitted.
  • •Beneficiary identity check: caller must still be on-chain beneficiary.
  • •Login identity check: caller must pass wallet-signature JWT auth.

Will Status Overview

Active

Will is running. You can update heartbeat, edit will, and revoke will.

DeathConfirming

After timeout, enters default 14-day window to reduce false trigger risk.

SignalEmitted

After waiting window, inheritance signal is emitted. Beneficiary can start retrieval flow.

Revoked

Will is revoked and inheritance flow is terminated.

Create Will Guide (Step by Step)

Step 1: Basic Settings (Heartbeat)

Define how often you prove you are still alive. If timeout occurs, system enters death confirmation window.

  • •Heartbeat period (days): recommended 180 or 365; minimum 90.
  • •System adds a 14-day waiting window automatically to reduce false triggers.
  • •Total trigger window = heartbeat period + 14 days.
Filling tip: If you are worried about forgetting heartbeat, start with 365 days and set a yearly reminder.

Step 2: Beneficiary Address

Enter beneficiary EVM wallet address (0x + 42 chars). Current flow is optimized for single beneficiary.

  • •Beneficiary wallet address must be valid format.
  • •Ask beneficiary to sign in at least once so the system can fetch public key.
  • •Wrong address can break decryption path later.
Filling tip: Verify address with beneficiary first, then copy and paste.

Step 3: Public Will Note (Plaintext On-chain)

Write actionable instructions beneficiary can follow immediately. This section is plaintext.

  • •Suitable info: asset clues, contacts, operation sequence.
  • •Do not write: mnemonic, private key, account passwords, or other highly sensitive secrets.
  • •Can be left empty and updated later via on-chain transaction in Active state.
Filling tip: Treat this as an execution guide. Prioritize actionable clarity.

Step 4: Secret Vault (Optional)

Sensitive content is encrypted locally in browser before being written on-chain. Platform never stores private plaintext.

  • •Browser generates A locally and encrypts private body into B.
  • •A is then encrypted with beneficiary public key to produce C.
  • •If beneficiary has no public key (not signed in), this step fails and blocks submit.
Filling tip: Only store highly sensitive content after you fully understand this flow.

Step 5: Confirm and Pay

Review summary, then send on-chain transaction. Will becomes effective once confirmed.

  • •Review fields: heartbeat period, beneficiary, public note, secret vault status.
  • •Creation fee is read from contract and paid on-chain.
  • •After transaction, you can view will and status on dashboard.
Filling tip: Use a stable network environment to avoid repeated submissions.

How Beneficiaries Use the System

  1. 1.Connect wallet and complete signature login.
  2. 2.Open Beneficiary page to view linked wills.
  3. 3.Optionally register notification email for each will.
  4. 4.Wait until status becomes SignalEmitted.
  5. 5.Call beneficiary key retrieval to get your C.
  6. 6.Use your private key offline to decrypt C and recover A, then decrypt on-chain B.

FAQ

Can the platform read my private will content?

No. Private body is encrypted in browser before on-chain storage. Backend stores only beneficiary key capsule, not private plaintext.

Why is private inheritance available only after death confirmation?

Because key retrieval API has on-chain status gate. It returns key capsule only when status is SignalEmitted and caller is verified on-chain beneficiary.

If encrypted key is on backend, can platform decrypt by itself?

Backend stores C (A encrypted with beneficiary public key). Without beneficiary private key, C cannot be decrypted, so A cannot be recovered.

What if someone sees ciphertext on-chain?

On-chain data is B (ciphertext), not plaintext. Without A (and without decrypting C), private content cannot be restored.

Go to Create WillView My WillsI Am a BeneficiaryDead Man's Switch Guide