Vol. I · No. IMAY 24Price · One Wei

Bequest

“An onchain agent for what comes next.”

Editorial

On building an inheritance agent

A reader’s note

Some lessons of the present decade (the bridges that fail, the rugs that pull, the tokens whose original holders forget the seed) accumulate slowly until one day they are the entire weather of the place. We have been told, repeatedly, that an autonomous agent will solve our problems. The proposed agents are usually larger than the problem they solve. They hold our keys. They speak for us in places we would not authorize them to speak. They have opinions about which DEX to use.

Bequest is the smallest agent we could imagine that still does something worth doing. Each instance is bound to one beneficiary on one chain. It cannot grant approvals. It cannot swap. It does not hold funds beyond what you bequeathed; the bequest wallet is its own custody, isolated from your main holdings. There is no API key stored alongside it, no LLM in the decision loop, no “fall back to” path. The agent’s job, in full, is this: when the dead-man timer expires, sign the one transaction it was authorized to sign.

We forked the Zerion CLI because its primitives are exactly what an agent of this shape requires: chain locks, recipient allowlists, approval-blocking gates, and the executable-policy dispatcher. We did not extend them. We did not add new capabilities to the agent token. We removed the parts we did not need. The result is, we hope, boring in the way infrastructure should be boring.

A few notes on what is genuinely difficult, and what we ducked. Crypto inheritance is not a key-management problem. It is a notification problem, a coordination problem with bereaved relatives, and a problem of trusting that the agent you set up two years ago will still be running when it is needed. Bequest sends nudges by email and by Telegram so that the notification problem is at least visible to the user; the coordination problem with relatives we leave to the relatives; the longevity problem we leave for our successors. If we have done our work, you will be able to rebuild Bequest from the public source and rerun your dead-man’s switch on your own infrastructure. We expect, in the long arc, you will. That is a good outcome.

The Editors

Construction notes

  • Forked Zerion CLI. The runtime for transfer construction, policy schema, and Zerion API auth. See /cli/ in the source repo.
  • Per-bequest hot wallet. Privkey encrypted at rest with envelope AES-GCM (HKDF over a master key). For a production deployment, swap to KMS or Turnkey; for the hackathon, keys are written into Postgres.
  • Scoped agent token. Chain-locked, allowlist of one recipient, approval calls denied, expires in 30 days. Defined in web/lib/zerion/policy.ts, faithful to cli/policies/{allowlist,deny-approvals}.mjs.
  • Watcher. Vercel Cron runs daily as a backstop; the bequest detail page’s 8-second poll drives the watcher inline during active sessions. Idempotent on transaction hash.
  • Notifications. Resend for email, Telegram bot for chat, both sending nudges at 50%, 75%, and 90% of the check-in window.