Inheritance, end to end.

Sign up and upgrade to an inheritance tier.

Create a deny.sh consumer account at /inherit-signup. Email plus password. No legal name, no ID, no probate paperwork. Then pick an inheritance tier and pay via Stripe.

Three tiers, all annual, sized by household:

After Stripe checkout completes, the webhook flips your api_keys.tier in real time and the customer dashboard at /dashboard/inheritance unlocks the New contract button.

What lands in the audit chain: a billing.checkout.completed op with your tier transition and Stripe session id.

Create your first contract.

A contract is the policy that watches your heartbeat. Label it whatever helps you remember (Family seed phrase, Estate vault, Bitcoin keys), pick a heartbeat cadence, choose a cooling-off length, and save.

You can also rotate the heartbeat token at any time, which returns a fresh plaintext value shown to you once. Use it for API or webhook based check-in instead of clicking the email link every cycle.

State at creation: ACTIVE. The contract enters the heartbeat cycle immediately and the next due date is set to now + cadence.

Add nominees who verify themselves.

Add up to N nominees (tier-dependent) by name and email. Each nominee receives a view-link email with a 24-hour token. That link takes them to their own read-only dashboard at /nominee/dashboard?token=*** where they can complete verification.

Verification is staged:

Unverified nominees are skipped when escalation eventually happens. The customer can see this in real time on their own dashboard and chase or replace anyone who hasn't completed verification.

Heartbeat in on your schedule.

Every cycle, deny.sh sends a heartbeat reminder email with a one-tap link. Click it, and the next due date moves forward by one cadence. Or call the API yourself if you'd rather automate it:

curl -X POST https://deny.sh/v1/inheritance/contracts/$CID/heartbeat \
  -H "X-Consumer-Session: $SESSION" \
  -d '{"token": "hb_..."}'

The dashboard shows your countdown in plain English ("6 days until next heartbeat") and a coloured badge on each contract: ACTIVE when you're on track, MISSED_1 after the first miss, MISSED_2 after the second.

The escalation worker runs every 5 minutes against all active contracts. It's a cheap loop: most contracts are ACTIVE and don't change state.

If the heartbeat stops, the contract escalates.

Miss the first heartbeat: state flips to MISSED_1, a louder reminder goes out. Miss the second (cadence later): MISSED_2, harder reminder plus a heads-up that cooling-off starts on the next miss.

Miss the third: state flips to COOLING_OFF. The cooling-off clock starts (7 to 30 days, your choice at contract creation). You can still cancel with a single heartbeat.

Every transition is auditable. The chain captures inheritance.state.transition ops with before-state, after-state, trigger reason, and timestamp.

Cooling-off window with cancel-anytime.

A contract in COOLING_OFF hasn't escalated to anyone yet. Nominees have not been notified. You can cancel the whole thing by sending one fresh heartbeat, which immediately drops the contract back to ACTIVE.

This is the deliberate safety valve. If you went on a long trip and missed three cycles, you have 7 to 30 days to come back and cancel before the system involves anyone else. Pause is also available via the dashboard for known multi-month absences (sabbaticals, hospital stays); that suspends the heartbeat clock entirely.

If the cooling-off window expires without a heartbeat, the contract advances to AWAITING_NOMINEE and nominees receive their first email.

Awaiting nominee, then customer or admin requests release.

In AWAITING_NOMINEE, each verified nominee gets an email with a 7-day single-use action token. The token lands them at /nominee/awaiting/:id?token=***, where they confirm they want to proceed.

The release request itself is initiated by either:

One release_request row is created per (contract, verified-nominee) pair. Pending or refused nominees are collected in a skipped[] list and returned to the dashboard so the customer can see who fell out.

Manual review, then a single-use download token.

Every release request lands in the admin queue at /admin/release. A human at deny.sh reads the row, confirms the contract really did escalate (heartbeats genuinely missed, nominee genuinely verified, no recent customer login), and clicks one of three buttons:

The token is consumed before the bundle is streamed. A crash mid-stream means a dead link, never a replay. The admin can reissue from the queue if delivery genuinely failed.

The download lands at /nominee/receive/:release_id?token=*** and serves the deniably encrypted control file. The nominee uses their own deny.sh CLI or the web app to decrypt with the password the customer shared with them out of band.

Audit chain captures the whole journey.

Every meaningful op lands in the per-tenant hash chain. RFC 3161 TSA timestamps every entry within minutes. Anyone holding the receipt can prove what happened, when, and that nothing has been tampered with after the fact.

For an inheritance contract, that means:

billing.checkout.completed         <-- step 1, tier upgrade
inheritance.contract.created       <-- step 2, contract row written
inheritance.nominee.add            <-- step 3, one per nominee
inheritance.nominee.email_verified <-- step 3, per nominee
inheritance.nominee.sms_verified   <-- step 3, per nominee
inheritance.heartbeat.received     <-- step 4, every cycle
inheritance.state.transition       <-- steps 5+6, ACTIVE->MISSED_1->...
inheritance.release.requested      <-- step 7
inheritance.release.admin_decision <-- step 8 (approve/reject/hold)
inheritance.release.delivered      <-- step 8, bundle handed to nominee
inheritance.nominee.refused        <-- if the nominee declined

Pull the full chain at /dashboard/audit or export it via GET /api/consumer/audit/export?format=json. Generate a signed PDF receipt for any single op with GET /api/consumer/audit/:id/receipt.pdf. Hand the receipt to a regulator, lawyer, or curious family member and they can independently verify the chain.