Liveness Checks
Understanding the dead man's switch mechanism in BAP — how liveness checks work, intervals, and configuration.
Liveness Checks
Liveness checks are the core "dead man's switch" mechanism in BAP. They periodically verify that the host is still alive, and if the host fails to respond, the will transfer process begins.
Overview
The liveness system has three configurable parameters:
| Parameter | Full Name | What It Controls |
|---|---|---|
| HCIT | Host Check-In Interval Time | How often checks are sent |
| HCRT | Host Check-In Response Time | How long to wait for response |
| HCRAC | Host Check-In Retry Attempt Count | How many failures before activation |
Parameters Explained
HCIT — Check Interval
How often the system sends a liveness check notification to the host.
Options: 7, 14, 30, 60, or 90 days
Recommendation:
- 30 days — Good balance for most people
- 14 days — More responsive, but higher risk of accidental activation
- 60-90 days — Lower maintenance, but longer delay if something goes wrong
HCRT — Response Time
How long the host has to respond to each check before the next attempt is made.
Options: 24, 48, or 72 hours
Recommendation:
- 48 hours — Gives time to respond even if traveling
- 24 hours — Faster escalation, but less margin for error
- 72 hours — More forgiving, but delays transfer if truly deceased
HCRAC — Retry Count
How many consecutive missed checks (without response) before the will transfer is activated.
Options: 1, 2, 3, 4, or 5 attempts
Recommendation:
- 3 attempts — Default, good balance
- 1-2 — Faster activation, higher false-positive rate
- 4-5 — Safer against accidental activation, but longer delay
Time to Activation
The worst-case time from last response to will transfer activation:
Time to Activation = HCIT + (HCRT × HCRAC)Examples
| HCIT | HCRT | HCRAC | Total Time to Activation |
|---|---|---|---|
| 30 days | 48h | 3 | ~36 days |
| 14 days | 24h | 1 | ~15 days |
| 90 days | 72h | 5 | ~105 days |
The system warns if settings are too aggressive or too lenient:
- Too aggressive: Less than 14 days total
- Too lenient: More than 180 days total
How Liveness Checks Work
Normal Cycle
┌─────────────────────────────────────────────────────────────────┐
│ EVERY HCIT DAYS │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. System sends liveness notification via preferred connector │
│ │
│ 2. Notification includes "I'm Alive" confirmation link │
│ │
│ 3. Host clicks link → confirms alive → next check scheduled │
│ │
│ │
└─────────────────────────────────────────────────────────────────┘Escalation Cycle (Host Doesn't Respond)
┌─────────────────────────────────────────────────────────────────┐
│ ESCALATION CYCLE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Attempt 1: │
│ - Check sent via primary connector │
│ - Host has HCRT hours to respond │
│ - No response → proceed to attempt 2 │
│ │
│ Attempt 2: │
│ - Check sent via next connector in fallback chain │
│ - Host has HCRT hours to respond │
│ - No response → proceed to attempt 3 │
│ │
│ ... (up to HCRAC attempts) │
│ │
│ Final Attempt Failed: │
│ - Will status → "pending_transfer" │
│ - All survivors notified │
│ │
└─────────────────────────────────────────────────────────────────┘Connector Fallback
During escalation, the system tries different connectors:
- Host's preferred connector (first attempt)
- Then tries other configured connectors in priority order
This ensures that even if one delivery method fails, the host still receives the notification.
Example Fallback Chain
Host configured with: Email → SMS → Telegram
Check 1: Sent via Email
Check 2: Sent via SMS
Check 3: Sent via Telegram
Check 4: (if configured) Sent via Email againHost Response Flow
When a host receives a liveness notification:
- Click the link in the notification
- Log in if session expired
- Confirm "I'm Alive" with one click
- Done! — Next check scheduled for HCIT days
The confirmation is simple and fast. No forms to fill out.
Survivor-Initiated Transfer
Survivors can also start the transfer process manually:
When a Survivor Can Initiate
- If they believe the host has died
- At any time (doesn't require waiting for liveness checks)
Process
┌─────────────────────────────────────────────────────────────────┐
│ SURVIVOR-INITIATED TRANSFER │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. Survivor accesses Survivor Portal │
│ │
│ 2. Selects their name from the will's survivor list │
│ │
│ 3. Receives OTP to verify identity │
│ │
│ 4. Transfer initiated │
│ │
│ 5. HOST NOTIFIED IMMEDIATELY via all connectors: │
│ "A Survivor has initiated will transfer. │
│ If you are alive, cancel within [HCRT] hours." │
│ │
│ 6. If host cancels: transfer stopped, status → active │
│ │
│ 7. If host doesn't cancel: normal escalation begins │
│ │
└─────────────────────────────────────────────────────────────────┘This allows survivors to act even if the automated system hasn't detected the host's death yet.
Canceling a Transfer
If a survivor initiates a transfer but the host is still alive:
- Host receives urgent notification via all connectors
- Host logs into dashboard
- Clicks "Cancel Transfer"
- Transfer is canceled, will remains active
- All survivors are notified of cancellation
The initiating survivor is not penalized — the system understands that concerned survivors may act out of caution.
Configuration in Dashboard
Finding Liveness Settings
In the host dashboard:
- Go to Settings
- Click Liveness
- Adjust the three parameters
Visual Feedback
The dashboard shows:
- Time to activation — Calculated worst-case
- Next check due — When the next liveness check will be sent
- Warnings — If settings are too aggressive or lenient
Best Practices
Choosing Settings
Consider:
| Factor | Recommended Setting |
|---|---|
| Active/healthy host | 30-day interval, 48-hour response, 3 retries |
| Elderly host | 14-day interval, 72-hour response, 2 retries |
| Forgetful host | 60-day interval, 72-hour response, 5 retries |
| Tech-savvy host | 14-day interval, 24-hour response, 1 retry |
Common Mistakes
- Too aggressive — Settings like 7/24/1 (only 8 days to activation)
- No backup connectors — If primary fails, host never receives notification
- Forgetting to respond — Add a calendar reminder
Recommendations
- Add at least 2 connectors for redundancy
- Set calendar reminders for check-in days
- Choose moderate settings — 30/48/3 is a good default
- Tell your survivors — Let them know you're using BAP
Monitoring
Check History
The dashboard shows liveness check history:
- Date/time of each check
- Status (confirmed, missed, escalated)
- Channel used
- Response time
Alerts
If a check is missed, the host receives notification. After HCRAC failures, all survivors are notified that the transfer process has begun.
FAQ
What happens if I miss a check?
You'll receive additional notifications (up to HCRAC times). As long as you confirm at any point before the threshold is reached, the will stays active.
Can I trigger a check manually?
Yes. In the dashboard, you can click "Check Now" to trigger an immediate liveness check.
What if I'm in the hospital/unable to respond?
Your survivors can initiate the transfer if they're concerned. But you can also set up a " grace period" by communicating with your survivors directly.
Do I need to be online for checks?
No. Checks are delivered via your configured connectors (email, SMS, etc.). You just need to click the link when you receive it.
Can I pause liveness checks temporarily?
Not in the MVP. This is a feature planned for future versions.
Next Steps
- Liveness Settings — Configuring checks in practice
- Will Transfer Protocol — What happens after activation
- Quickstart Guide — Setting up liveness during onboarding