Whitepaper v1.0
Reliquary Protocol
Programmable treasury continuity for the post-founder era
Reliquary Protocol · Base Network · May 2026
Chapter I
Vision
Crypto treasuries were built for speed, not succession. A founder deploys a token, raises funds, and holds the keys. The community trusts one wallet. When that person goes quiet, the project does not pause gracefully. It fractures.
Reliquary exists so continuity is decided in advance, sealed in public, and executed without negotiation after silence is proven.
We call this a dead man's switch for treasuries: not morbid, but precise. Founders define what happens next. The protocol waits. The agent watches. Code acts when humans stop responding.
Reliquary is not a wallet, not a multisig replacement, and not legal infrastructure. It is execution logic for a future the founder may never see.
Chapter II
Design principles
Every architectural choice follows five constraints that cannot be traded away:
- Non-custodial. Reliquary never holds keys or funds. It routes according to sealed rules only.
- Immutable after seal. Plans cannot be altered secretly. Changes require visible onchain action by the active controller.
- Proof before execution. Inactivity must be demonstrated through missed proof-of-life windows, not subjective judgment.
- Public verifiability. Anyone can read a plan, monitor its state, and witness execution.
- Minimal trust surface. No admin pause, no upgrade proxy, no backdoor withdrawal on v1 contracts.
These principles distinguish Reliquary from offchain wills, Telegram handoffs, and informal DAO votes that lack binding execution.
Chapter III
Succession modes
Founders choose one or more modes when sealing a plan. Each mode defines a different post-silence outcome:
M1
Founder Recovery
Backup wallet or multisig inherits controller permissions. Best for solo founders with a trusted second key.
M2
Community Vault
Treasury routes to a DAO or community multisig. Best for memecoins and open communities.
M3
Contributor Split
Predefined percentages to builders, advisors, and ops wallets. Best for small teams with clear roles.
M4
Agent Continuity
Automated agent wallet continues payroll, renewals, and basic ops. Best for AI-native projects.
M5
Final Message
Encrypted note published onchain at trigger. Best when context matters as much as capital.
Mode selection is permanent at seal time. The community sees the full configuration before any trigger fires.
Chapter IV
Token utility & fees
$RELIQ coordinates access to the protocol. It is not designed as a yield asset, revenue share, or claim on treasury funds.
| Action | Fee model | $RELIQ role |
|---|
| Seal a plan | Flat protocol fee | Pay fee or hold threshold |
| Extended inactivity window | Tier unlock | Stake or burn |
| Multiple active plans | Per-plan slot | Hold minimum balance |
| Agent alert channels | Subscription | Monthly $RELIQ debit |
| Future modules | Governance vote | Vote weight |
Fee parameters are set by governance after launch. v1 uses fixed constants documented in Technical Docs.
Chapter V
Roadmap
Now · v1
Base launch
Core succession contracts, agent monitoring, plan wizard, proof-of-life via tx + signed message.
Next · v1.1
Multi-chain
Ethereum, Arbitrum, Optimism support. Cross-chain plan registry for unified agent dashboard.
Future · v2
Governance module
Onchain parameter votes, delegated PoL for multisigs, conditional sub-plans for partial treasury splits.
Security reviews for each major release are published separately in the Audit Report.