What happens to your crypto when you die?

If you hold crypto, you have a problem your bank will never have. There is no helpline. There is no probate court that knows what a BIP39 phrase is. Your keys are the asset, and whoever has them, has everything.

deny.sh inheritance is for the people who took self-custody seriously and now want to plan for the day they aren't around to manage it. Three customer shapes in particular:

• Individual holders with material crypto positions, a partner or two trusted family members, and no appetite to hand their seed to a lawyer.
• Families with shared holdings where multiple people might need access in a crisis (spouse, adult children, sibling) and a clear cooling-off window before anything happens.
• Institutional custodians (funds, family offices, estate professionals) who need ID-verified nominees, a documented release process, and an audit trail their regulator will accept.

You can't put a seed phrase in a will. Probate is public record. A safety deposit box needs a court order to open, and by then everyone knows what's inside. A lawyer holding your keys is a single point of failure with a billable hour rate.

Existing crypto inheritance services ask you to trust a third party with your keys. That defeats the point of self-custody.

deny.sh works differently. You set a heartbeat. Your nominees verify themselves. If the heartbeat stops, the system enters a cooling-off window, then routes the request through manual review before any encrypted bundle leaves. The file itself is deniably encrypted, so even the inheritance mechanism doesn't expose what's really inside.

You could roll your own. A cron job, a PGP-encrypted file in cloud storage, a script that emails your brother if you stop logging in for 90 days. People have built versions of this on a weekend, and most have one of three problems: they leak the bytes the moment they fire, they fire on the wrong signal (cloud outage, password change), or they are so brittle that the heir gets a corrupt blob and a sympathy card.

deny.sh is built for the parts you'd rather not build yourself:

• UK operator, regulated by default. Treehouse in Valhalla Ltd is Cyber Essentials Certified (IASME, May 2026). We are a UK company with a registered address, a director, a tax ID, and accountable people. Your nominees can find us. Your regulator can audit us.
• Multi-party verification. Every nominee proves they are who they say they are before the moment matters. Email plus SMS at minimum, document plus selfie on the institutional tier. Nobody learns your seed phrase because somebody intercepted a single email.
• Cooling-off built in. 7 to 30 days where you can still cancel with one click. Long trips, hospital stays, sabbaticals: none of those wipe out your nominees.
• Manual review before any release. A human at deny.sh reads every release request, confirms the contract really did escalate, and only then mints the download token. Three buttons: approve, reject, or hold pending more info.
• Single-use download tokens consumed before the bundle streams. A replay is structurally impossible. A crash mid-stream means a dead link, not a leak.
• Deniable encryption underneath. The control file itself encrypts to two plaintexts under two passwords. Even if the bundle leaks, an attacker can't tell what is real and what is a decoy.
• Hash-chained audit log for the whole journey. Every heartbeat, every state transition, every verification step, every release decision lands in your per-tenant audit chain. RFC 3161 TSA timestamped within minutes. Signed PDF receipts on demand.