explaingit

jbhavya876/por_vault

1RustAudience · developerComplexity · 5/5ActiveSetup · hard

TLDR

Rust dead-man's switch for Bitcoin built on OP_CSV and Miniscript; a backup owner can sweep funds if the primary stops sending a heartbeat in time.

Mindmap

mindmap
  root((por_vault))
    Inputs
      Bitcoin keys
      Heartbeat tx
      mempool data
    Outputs
      Vault address
      PSBT file
      Recovery sweep
    Use Cases
      Crypto inheritance
      Cold storage backup
      Time locked vault
    Tech Stack
      Rust
      Miniscript
      P2WSH
      OP_CSV
      PSBT

Things people build with this

USE CASE 1

Set up a Bitcoin vault that releases to a chosen backup address after a missed heartbeat window

USE CASE 2

Practice the full create, refresh, and recover flow on testnet before touching mainnet funds

USE CASE 3

Run the watchtower daemon to get alerts as the recovery window approaches

USE CASE 4

Import the generated Miniscript descriptor into Sparrow or Specter for an offline view

Tech stack

RustBitcoinMiniscriptPSBT

Getting it running

Difficulty · hard Time to first run · 1day+

Marked as educational; losing either key, password, or descriptor on mainnet means the coins are unrecoverable.

In plain English

PoR Vault is a Bitcoin inheritance tool written in Rust. The idea is a digital dead-man's switch for coins. A primary owner holds the funds and stays in control as long as they regularly send a small heartbeat transaction. If they stop, after a fixed time window passes, a backup owner is allowed to sweep the funds out. The README says nothing in this design depends on a custodian or a smart contract on another chain; everything is enforced by standard Bitcoin script. The time lock is built from native Bitcoin opcodes, specifically OP_CHECKSEQUENCEVERIFY (often shortened to OP_CSV), wrapped in a P2WSH script. The vault creation step also produces a Miniscript descriptor, which is a portable text format that wallets like Sparrow or Specter can import. Transactions are emitted as BIP-174 PSBTs, which means the primary key can stay offline on a hardware or air-gapped device and only sign files passed back and forth. There are four commands. Create generates the keys, an AES-256-GCM encrypted keystore for the secrets, and the descriptor. Daemon runs a watchtower that polls mempool.space, tracks the vault address, and alerts the owner when the recovery window is close to opening. Refresh is the heartbeat: it spends the vault output back to the same vault, which restarts the OP_CSV countdown, and outputs a PSBT for the owner to sign. Recover is the backup path: once the delay has elapsed, the backup owner can sweep the funds to a chosen address; if they try too early, the network simply rejects the transaction. The README highlights a few extra details. Replace-by-fee is enabled on sweep transactions, so a time-critical recovery does not get stuck behind a low fee. Private keys are kept encrypted with PBKDF2 key derivation rather than written in plaintext. A testnet flag is available on every command for safe practice. The author is explicit that this is built as an educational and architectural demonstration, and that on mainnet any lost key, password, or descriptor means the funds are gone for good.

Copy-paste prompts

Prompt 1
Create a por_vault on testnet, send a refresh heartbeat, and walk me through the OP_CSV countdown
Prompt 2
Show me how to sign a por_vault refresh PSBT on an air-gapped device and broadcast it from the online machine
Prompt 3
Set up the por_vault daemon to watch mempool.space and alert me when the recovery window is one week away
Prompt 4
Explain the AES-256-GCM keystore format and how PBKDF2 derivation is parameterised in por_vault
Prompt 5
Demonstrate that recover fails before the OP_CSV delay elapses and succeeds afterwards on regtest
Open on GitHub → Explain another repo

Generated 2026-05-22 · Model: sonnet-4-6 · Verify against the repo before relying on details.