Satheir

The complete Satheir flow

This page explains how the public site, owner console, heir verification path, and offline recovery package fit together.

How It Works

System shape

A coordination layer, not a custodian

Satheir organizes the human and operational side of Bitcoin inheritance while keeping the final secret reconstruction outside the live service.

Open guided demo

Start there if you want to see the flow instead of reading every page.

Operating modes

Demo mode

A seeded in-memory runtime keeps the full product explorable before Postgres or external delivery services are connected.

Database mode

Prisma-backed plan, heir, audit, and verification records become persistent once a production database is configured.

Offline recovery mode

The final reconstruction steps move to a local HTML package so mnemonic material stays off the live service.

Owner journey

  1. 1. Create the inheritance plan and define the wallet target.
  2. 2. Add primary and backup heirs with contact details.
  3. 3. Set the shared phrase and shard delivery notes.
  4. 4. Activate the plan and maintain confirmation cadence.
  5. 5. Export the Recovery Kit before it is ever needed.

Heir journey

  1. 1. Open the recovery entry linked to the inheritance-ready plan.
  2. 2. Identify the invited heir and start the verification session.
  3. 3. Pass email, phone, and shared phrase checks.
  4. 4. Download the offline Recovery Kit and retrieve the required shards.
  5. 5. Recover the mnemonic locally, import it into a wallet app, and verify the wallet address.

Layer map

How the site is structured now

Public trust layer

Homepage, security, privacy, terms, FAQ, and launch pages explain the boundary before the product asks for trust.

Owner console layer

The owner side handles plan setup, heirs, shared phrase, countdown operations, Recovery Kit exports, and audit visibility.

Heir recovery layer

The heir side handles identity selection, recovery session verification, instructions, milestones, and recovery completion.

Offline fallback layer

The final reconstruction moves into local exports so live infrastructure is not the only path available during a real incident.

Boundary chain

1. Public pages explain the trust boundary before product entry.
2. Owner console prepares contacts, timing rules, phrase verification, and offline exports.
3. Heir flow authorizes access before any retrieval map or package appears.
4. Offline recovery completes outside the live application boundary.

Reading note

This page is meant for understanding structure. The demo is still the clearest next step when you want to interact with the product.
For trust questions, read the security page after you understand this flow.