Riktha
Inheritance for Stellar accounts, enforced by the Stellar protocol itself.
No custodian, no seed-phrase sharing, no smart contract to trust.
Riktha (Sanskrit): inherited wealth; the estate left by the dead.
The problem
When a crypto holder dies without passing on their keys, the assets are gone: chain data can't tell "the owner is gone" from "the owner is quiet". Chainalysis-based estimates put 2.3–3.7 million BTC as permanently lost. Tokenized real-world assets on Stellar passed $3.9B in 2026, and none of the existing inheritance products (Casa, Unchained, Liana, Nunchuk, Sarcophagus…) supports Stellar. Today a Stellar holder can share the seed phrase (and risk a leak), put it in a will (and show it to everyone who reads it), or lose everything.
How it works
The owner signs one setup transaction. It registers two pre-authorized transactions (preauth_tx signers) on their own account, each guarded by CAP-21 preconditions:
| Phase | Valid when | Effect |
|---|
| 1. Notice | the owner has sent nothing for the inactivity window (minSeqAge = I, minSeqNum = X) | a no-op BumpSequence to sequence s1: the public "a claim has started" signal |
| 2. Handover | the grace window has passed since the notice and the owner has sent nothing since (minSeqAge = G, sequence must be exactly s1) | SetOptions adds the heir as a signer; the heir can now move every asset |
owner signs setup ──► 2 preauth signers on the owner's account
… any tx the owner sends resets the clock (seqTime) …
inactivity window passes ──► keeper (or anyone) submits Notice, fee-bumped ──► owner alerted on 3 channels
… any tx from the owner now consumes s1+1 and kills the Handover forever …
grace window passes ──► heir submits Handover, fee-bumped ──► heir is a signer ──► heir moves assets
Why it's safe (all enforced by validators, not by Riktha):
- Riktha holds no keys. The server stores only pre-signed transactions the network refuses until their conditions hold. A compromised server can only submit them early, and the network rejects that.
- Early submissions are harmless. A transaction rejected for unmet preconditions never reaches application, so its pre-auth signer stays in place (CAP-28).
- One click cancels. After a notice, any transaction from the owner uses up the exact sequence number the handover needs.
- Riktha can disappear. The heir holds an inheritance packet (both transactions as JSON) and can claim at
/claim (no login, no database) or with any Stellar tool.
- Private until handover. Before phase 2 the ledger shows only two opaque hash signers.
- The owner keeps control. Their key is never removed.
Heirs who don't use crypto (claim kit)
An owner can name an heir by email only. The owner's browser creates a fresh key for the heir and locks it with a 6-word claim code (PBKDF2-SHA256 at 600k iterations, then AES-256-GCM). The owner keeps the code with their will. Riktha stores only the locked kit and never sees the code. When it's time, the heir opens the link from their email, types the code, and claims. The heir needs no wallet and no XLM: the handover is submitted without a wallet, and afterwards the owner's account is their wallet, ready to send funds to any address or exchange (with a memo). See ARCHITECTURE §15.
Why Stellar
This design is only possible because Stellar has, at protocol level, transaction preconditions (minSeqAge, minSeqNum; Protocol 19), pre-authorized transaction signers, fee-bump transactions, and Soroban auth that goes through classic signers. CAP-21 itself lists time-delayed key recovery as a goal. Riktha turns that designed-in, unused capability into a product. It doesn't port as-is to most chains.
Protocol findings from our spike (pnpm spike, results in docs/PROGRESS.md)
- A sequence jump of 1e9 for phase 1 is accepted.
sequence_time is absent on fresh accounts until their first V3-extension update (setup provides it).- No reserve guard is needed for the plain handover. Phase 1 removes its own pre-auth signer, which frees one base reserve before phase 2 can run. The owner can't spend that reserve without cancelling the claim.
- Phase transactions also work without a fee-bump: the pre-auth signer authorizes them and the owner's account pays the 100-stroop fee.
- Freighter signs both PreconditionsV2 transactions and fee-bump envelopes.
- SDK 17 returns
Uint8Array from tx.hash() and text memos. .toString("hex") silently produces "1,2,3…", so we use explicit helpers (txHashHex, memoText).
Architecture
Browser (Next.js) lib/core: builders, state machine, packet ◄── same code on the server
Freighter signs ──────────► Horizon (user txs go straight to the network)
│ /api/*
Vercel (Next.js routes) ── Neon Postgres (cache + contacts; the chain is the source of truth)
/api/cron/tick ◄── cron-job.org every minute: derive state → notify → auto-submit Notice
notifications ──► dashboard · email (SMTP) · Telegram bot
- The chain is the source of truth. Plan state is always derived from the owner's Horizon account (
lib/core/state.ts); the DB only caches it.
- One pure, isomorphic, unit-tested module builds every transaction (
lib/core).
- Sign-in is a SEP-10-style challenge signed in Freighter → JWT in an httpOnly cookie.
- Keeper is idempotent: notifications are deduplicated by a unique index per (plan, kind, cycle, recipient, channel).
Full specs: docs/PRD.md · docs/ARCHITECTURE.md · progress log docs/PROGRESS.md.
Run it locally
Requires Node 22+, pnpm, the Freighter extension set to Testnet, and a free Neon Postgres database.
pnpm install
cp .env.example .env.local # add DATABASE_URL (Neon) and, optionally, SMTP + Telegram values
pnpm gen-secrets # fills JWT/cron/webhook secrets, a SEP-10 key and a funded testnet keeper
pnpm db:push # creates the tables
pnpm dev # http://localhost:3000
Try it with fresh demo accounts: pnpm seed-demo creates a funded owner (holding XLM and a test asset) and a funded heir, and saves their secret keys to demo-accounts.local.json (git-ignored) for importing into Freighter. Choose the Demo preset (2-minute windows) when creating a plan. To run the keeper locally, call it with your cron secret:
curl -X POST http://localhost:3000/api/cron/tick -H "Authorization: Bearer $CRON_SECRET"
| Variable | Purpose |
|---|
NEXT_PUBLIC_NETWORK | testnet (mainnet is disabled) |
NEXT_PUBLIC_APP_URL | links in emails and Telegram messages |
DATABASE_URL / DATABASE_URL_UNPOOLED | Neon Postgres |
JWT_SECRET | session cookies |
SEP10_SIGNING_SECRET | server key that signs sign-in challenges (no funds needed) |
KEEPER_SECRET | funded testnet account that pays Notice fee-bumps |
CRON_SECRET | bearer secret for /api/cron/tick |
SMTP_HOST SMTP_PORT SMTP_USER SMTP_PASS MAIL_FROM | email (e.g. a Gmail app password) |
TELEGRAM_BOT_TOKEN TELEGRAM_BOT_USERNAME TELEGRAM_WEBHOOK_SECRET | Telegram alerts |
Tests
pnpm test # unit tests: builders, state machine, packet, errors, eligibility, notifications
pnpm scenarios # the 10 protocol scenarios on live testnet → docs/evidence.json
pnpm test:auth # sign-in e2e against a running app
pnpm test:plans # plan API e2e on testnet
pnpm test:lifecycle # arm → keeper notice → handover → estate, plus re-arm and revoke
pnpm test:kit # heir named by email → claim code → handover with no wallet → heir spends
Deploying
- Import the repo into Vercel and add Neon from the Vercel Marketplace.
pnpm db:push, then copy secrets with pnpm push-env.- Point Telegram at the webhook:
https://api.telegram.org/bot<TOKEN>/setWebhook?url=<APP_URL>/api/telegram/webhook&secret_token=<TELEGRAM_WEBHOOK_SECRET>.
- cron-job.org:
POST <APP_URL>/api/cron/tick every minute with Authorization: Bearer <CRON_SECRET>. Vercel Hobby cron runs only daily, so vercel.json keeps a daily run as a backup.
Honest limits
- Not a legal will. Heirs may still need probate; Riktha is the technical half that pairs with a will.
- Only sent transactions count. Receiving payments doesn't reset the clock, and neither does activity where the owner isn't the transaction source (e.g. a Soroban app relaying the owner's auth entry). The grace window and alerts exist for exactly this.
- Classic, standard accounts only: a master key and no other signers. Smart-wallet (C-address) balances aren't covered unless they authorize through the G account. The estate screen lists classic balances only.
- The heir's key is a single point of failure. If the heir loses it, re-plan while the owner is alive.
- Testnet only, unaudited.
Roadmap
Cash-out for claim-kit heirs (convert to USDC and withdraw to a bank through a SEP-24 anchor); multiple heirs with weights; staged release; a wallet SDK so Freighter/Lobstr/xBull can offer "Set up inheritance" natively; anchor and RWA-issuer integrations; hardware wallets; mainnet after an audit.
License
MIT
