No reviews yetBe the first to leave a review for VaultPass
Maker
📌
▎ I'm Suresh, founder of VaultPass.
▎ The problem that started this: if you self-custody crypto and you're gone tomorrow, your family usually can't recover it. A will can't decrypt a wallet; a lawyer can't subpoena a private key. It's one of the quietest, most expensive problems in the space — an estimated $140B+ already lost this way.
▎ VaultPass is a dead man's switch for it. Your seed phrases and passwords are encrypted on your device with AES-256-GCM (we store ciphertext, not plaintext). You check in on a schedule; if you ever go silent, your vault is delivered to your heir automatically — no lawyers, no custodian.
▎ We open-sourced the cryptographic core (MIT) so you don't have to take our word for it — read it, run the tests. A full external audit is still ahead of us.
▎ Would love feedback from anyone who's tried to solve crypto inheritance. What did you end up doing?
(Note: not the HashiCorp "vaultPass" extension — different product.)
Now the site sweep — sizing the scope + cleaning that leftover worktree:
Report
How does the trigger work in practice - is it purely time-based inactivity or can it be tied to something more verifiable, and what happens if someone just forgets to check in while on vacation?
Report
Maker
@sercanna3c Great question — it's time-based inactivity today, not on-chain. You set your own check-in interval (weekly up to yearly). If you miss it, a grace buffer starts (7 days on monthly, 100 on annual/lifetime) with two warning emails + Telegram pings before anything fires — so a vacation won't trigger it, and a single check-in resets the whole timer. On-chain/inactivity-based triggers (e.g. Solana) are on the roadmap; right now it's a deliberately conservative server-side timer with a wide safety margin.
Report
How does the handoff actually trigger if I'm offline or my hardware wallet dies — is it purely time-based or can it pull from on-chain activity like inactivity periods?
Report
Maker
@devran1280912 Good question. It's time-based inactivity — not on-chain — and importantly it keys off your check-ins, not your wallet's state. So whether you're offline or your hardware wallet dies is irrelevant to the trigger; what matters is that you periodically check in (a tap on a link or the dashboard) on a schedule you set, from weekly up to yearly.
Miss your window and a grace buffer starts (7 days on monthly, 100 on annual/lifetime) with warning emails + Telegram pings before anything releases — and a single check-in resets the whole timer. So a dead device or a long trip won't hand anything off; only sustained silence past your chosen window does.
On-chain activity as a secondary liveness signal is an interesting direction we've considered, but I won't claim it's built — today it's a deliberately conservative server-side timer with a wide safety margin.
Report
How does it actually verify that someone is truly gone versus just offline for a few weeks, and what stops a false trigger from dumping my keys to the wrong people?
Report
Maker
@fatmanurhuer It doesn't try to detect death — it detects inactivity, deliberately, because "proof of death" is unreliable. The safeguard against false triggers is the buffer: you pick the window, then there's a grace period plus repeated warnings (email + Telegram) before release, and checking in once cancels everything. And keys never go to "the wrong people" — access only ever goes to the specific heir you designated, who confirmed via email upfront. No one else can be a recipient.
Report
Set this up in under 10 minutes and the step where you verify your beneficiaries actually made me feel like this is built by people who've thought through the worst-case scenarios. Refreshing to see a dead man's switch that doesn't treat crypto holders like an afterthought.
Report
Maker
@efekhlg Thank you — that's exactly the design goal: treat self-custody seriously and never take control away from the owner until the conditions they set are met. Appreciate you taking a look.
Report
Finally a dead man's switch that actually gets how self-custody works. The setup was straightforward and I liked that my keys never leave my control unless the trigger fires.
Report
Maker
@glserenaynx6tw Thank you — that's exactly the design goal: treat self-custody seriously and never take control away from the owner until the conditions they set are met. Appreciate you taking a look.
Report
The dead man's switch idea for crypto has always stressed me out, so glad someone built this. Setup was straightforward and the key-shard approach actually makes sense to me.
Report
Maker
@turan9h8e Thank you — that's exactly the design goal: treat self-custody seriously and never take control away from the owner until the conditions they set are met. Appreciate you taking a look.
How does the trigger work in practice - is it purely time-based inactivity or can it be tied to something more verifiable, and what happens if someone just forgets to check in while on vacation?
@sercanna3c Great question — it's time-based inactivity today, not on-chain. You set your own check-in interval (weekly up to yearly). If you miss it, a grace buffer starts (7 days on monthly, 100 on annual/lifetime) with two warning emails + Telegram pings before anything fires — so a vacation won't trigger it, and a single check-in resets the whole timer. On-chain/inactivity-based triggers (e.g. Solana) are on the roadmap; right now it's a deliberately conservative server-side timer with a wide safety margin.
How does the handoff actually trigger if I'm offline or my hardware wallet dies — is it purely time-based or can it pull from on-chain activity like inactivity periods?
@devran1280912 Good question. It's time-based inactivity — not on-chain — and importantly it keys off your check-ins, not your wallet's state. So whether you're offline or your hardware wallet dies is irrelevant to the trigger; what matters is that you periodically check in (a tap on a link or the dashboard) on a schedule you set, from weekly up to yearly.
Miss your window and a grace buffer starts (7 days on monthly, 100 on annual/lifetime) with warning emails + Telegram pings before anything releases — and a single check-in resets the whole timer. So a dead device or a long trip won't hand anything off; only sustained silence past your chosen window does.
On-chain activity as a secondary liveness signal is an interesting direction we've considered, but I won't claim it's built — today it's a deliberately conservative server-side timer with a wide safety margin.
How does it actually verify that someone is truly gone versus just offline for a few weeks, and what stops a false trigger from dumping my keys to the wrong people?
@fatmanurhuer It doesn't try to detect death — it detects inactivity, deliberately, because "proof of death" is unreliable. The safeguard against false triggers is the buffer: you pick the window, then there's a grace period plus repeated warnings (email + Telegram) before release, and checking in once cancels everything. And keys never go to "the wrong people" — access only ever goes to the specific heir you designated, who confirmed via email upfront. No one else can be a recipient.
Set this up in under 10 minutes and the step where you verify your beneficiaries actually made me feel like this is built by people who've thought through the worst-case scenarios. Refreshing to see a dead man's switch that doesn't treat crypto holders like an afterthought.
@efekhlg Thank you — that's exactly the design goal: treat self-custody seriously and never take control away from the owner until the conditions they set are met. Appreciate you taking a look.
Finally a dead man's switch that actually gets how self-custody works. The setup was straightforward and I liked that my keys never leave my control unless the trigger fires.
@glserenaynx6tw Thank you — that's exactly the design goal: treat self-custody seriously and never take control away from the owner until the conditions they set are met. Appreciate you taking a look.
The dead man's switch idea for crypto has always stressed me out, so glad someone built this. Setup was straightforward and the key-shard approach actually makes sense to me.
@turan9h8e Thank you — that's exactly the design goal: treat self-custody seriously and never take control away from the owner until the conditions they set are met. Appreciate you taking a look.