Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/natureloved/DeadMan-Vault/llms.txt

Use this file to discover all available pages before exploring further.

When a vault owner stops checking in and the grace period expires, the vault status moves to triggered and the keeper begins distributing funds to registered beneficiaries. For most beneficiaries this happens automatically — the keeper cron settles payouts without any action required on their part. But if a beneficiary wants to initiate the release themselves, or if they received a claim link before the automatic sweep ran, they can visit the claim page and trigger their payout on demand. This document explains both paths.

Two paths to receiving funds

Automatic settlement

The keeper cron runs periodic sweeps over all triggered vaults. When it finds a vault with unclaimed beneficiaries whose vesting period has elapsed, it calls settleVaultPayout for each eligible beneficiary and sends USDCx directly to their Stacks address via a SIP-010 token transfer. Beneficiaries receive an email notification at the address registered during vault creation once their payout is confirmed on-chain. No wallet connection or page visit is required.

Manual claim

If a beneficiary receives a claim-ready email or already has the vault ID, they can visit /claim/[vaultId] and trigger their own release. This calls the same settleVaultPayout logic server-side, meaning it is safe to use even if the automatic sweep has already run — the server detects a prior claim and returns the existing transaction ID without double-paying.

Manual claim flow

1

Navigate to /claim/[vaultId]

Open the claim URL shared in your notification email, or navigate directly to /claim/[vaultId] in your browser. A Stacks wallet connection is required — the page shows a Connect Your Wallet prompt before any vault details are revealed. Click Connect Wallet and authenticate with Leather or Xverse to proceed.
2

Confirm vault is in a claimable state

The page fetches GET /api/vaults/[vaultId] on load. The claim UI is only rendered when the vault status is triggered, grace_period, or claimed. Any other status — including active, warning, or funding — renders a Not Yet Claimable screen instead.If the vault is in grace_period, the owner still has a window to check in and prevent succession. Claiming is technically possible but the vault may return to active if the owner checks in before the keeper finalises the trigger.
3

Verify your connected address is a registered beneficiary

The page checks your connected wallet address against the beneficiaries array returned with the vault record. If your address is not found, the page shows Not a Beneficiary — make sure you are connected with the exact Stacks address the vault owner registered for you.When matched, the page shows:
  • Your inheritance amount: totalDeposited × allocationPercent / 100 USDCx
  • Your allocation percentage
  • The vault owner’s optional message to beneficiaries
  • Your vesting schedule (vesting_days > 0) or “Lump sum”
4

Check for a vesting lock

If the vault owner configured a vesting delay for your beneficiary entry, the page computes:
vesting_release_at = triggeredAt + vestingDays
If vesting_release_at is in the future, the Check & Release Funds button shows Locked and a yellow notice explains the exact date when your funds become available. Funds are sent to your wallet automatically once that date arrives — you do not need to return to this page.If no vesting delay was set, or if the release date has already passed, you can proceed to claim immediately.
5

Click Check & Release Funds

Click the Check & Release Funds button. The app calls:
POST /api/heartbeat
Content-Type: application/json

{
  "action": "claim",
  "vaultId": "your-vault-id",
  "beneficiaryAddress": "your-stacks-address"
}
6

Server runs settleVaultPayout

The server performs the following:
  1. Verifies the vault is in a triggered or claimable state.
  2. Confirms the beneficiaryAddress matches a registered beneficiary for this vault.
  3. Checks whether the beneficiary has already been paid (idempotency guard).
  4. If unpaid and vesting has elapsed, calls settleVaultPayout — the keeper signs a SIP-010 USDCx transfer for the beneficiary’s proportional share.
  5. Records the claimed_tx_id against the beneficiary row.
  6. Returns { txId } on success.
On success, the page updates to show Already Paid on the button and displays a transaction link.
7

Confirm on-chain

The transaction link on the claim page points to the Stacks testnet explorer. Click it to verify the SIP-010 transfer landed in your wallet. Standard testnet confirmation takes one to three block confirmations (~10–30 minutes).
Funds transfer directly on-chain via SIP-010 token transfer. Check the Stacks testnet explorer for the transaction using the txId shown on the claim page. If funds haven’t arrived within an hour, verify you are looking at the correct testnet address.

Vesting delays in detail

Vesting is configured per beneficiary at vault creation time via the vestingDays field. When the vault triggers:
vesting_release_at = vault.triggered_at + beneficiary.vesting_days (days)
The keeper cron iterates over all beneficiaries during each sweep. For each beneficiary it checks:
  • Is the beneficiary already claimed? → skip
  • Is vesting_release_at in the future? → skip, retry on next sweep
  • Otherwise → call settleVaultPayout and mark claimed = true
This means vesting delays are enforced automatically without any action from the beneficiary. The manual claim page enforces the same check — the Check & Release Funds button is disabled and shows Locked until vesting_release_at has passed.

Viewing vault and claim status

The /status/[vaultId] page provides a full view of any vault: current block, deadline block, beneficiary list with allocation percentages, the owner’s message, and the complete on-chain activity log including all heartbeat events and the initial deposit transaction. Beneficiaries can use this page to monitor vault state before and after triggering.

Dashboard

Monitor your own vaults, deadlines, and block-height countdowns.

Check In

Keep your vault alive by performing a heartbeat check-in.

Build docs developers (and LLMs) love