Abstract
RIP Wallet is a self-custody crypto wallet with one job no other wallet takes seriously: your assets should survive you. The protocol pairs a shipped, working wallet with a set of audited-by-fire smart contracts that pass a vault to a named heir after a provable period of silence. No lawyers, no custodian, no permission but time.
$RIP is the protocol's planned utility token. It is designed to govern protocol parameters, share keeper execution tips, and reduce protocol fees for stakers. The wallet works fully without it, and this document says so plainly. What follows is the mechanism design, what already exists in code, what is built but not yet deployed, and what remains a plan.
$RIP does not exist as a contract today. There is no sale. Anyone offering you $RIP before an address is published in this document is running a scam.
The problem: keys die with their holders
Self-custody has one silent failure mode. If the only holder of a seed phrase dies, the assets do not transfer. They freeze forever. Chainalysis estimated in 2020 that roughly a fifth of all mined Bitcoin sits in wallets that have not moved in years and are likely lost. Every year of crypto adoption adds more value locked behind twelve words that exactly one person knew.
The existing answers all reintroduce trust. Exchanges hold your keys and fail. Legal wills reveal seed phrases to executors. Sharing the phrase with family means sharing full control today, not after death. A mechanism is needed that keeps the owner in exclusive control while alive, and moves control, not secrets, after provable silence.
The protocol: silence as a signal
The Afterlife Protocol is a dead-man's switch implemented in four contracts. The owner holds an ERC-4337-compatible smart vault (RIPAccount). Every transaction the vault sends implicitly calls checkIn(). Living is proof of life, no extra ritual required.
| Parameter | Value in the contract |
|---|---|
| Silence periods | Exactly three: 180 days, 365 days, or 730 days. Anything else reverts. Default is one year. |
| Grace window | A hard constant of 30 days after the heir starts a claim. One transaction from the owner cancels it instantly. |
| Heir | One address per vault in v1. Zero address and self-heir are rejected. Multi-heir is deferred to v2, on purpose. |
| Handover | Ownership of the account transfers, and assets follow it. The heir receives a clean vault. The old heir and timer are deleted. |
| Fail-open | A broken inheritance module can never freeze funds: the check-in poke is try/catch on every path. Availability of your own money beats every other property. |
| Epitaph | The contracts carry an on-chain constant: Mors certa, hora incerta. |
Vault addresses are personal. Each vault deploys via CREATE2 with a salt mined client-side so the address ends in dead. The salt is mined deterministically by candidate count, so a slow phone and a fast laptop compute the same address, and funds sent before deployment can never strand.
Status: all four contracts are written and covered by 56 tests, including a 10-agent adversarial review of the Sentinel with every finding fixed. They are deployed to a local development chain only. Public deployment is gated behind a security checklist (see section VIII).
What exists today
A whitepaper is a promise until the code exists. Here is the honest inventory, in three states.
Shipped and working
- A full wallet: 91 EVM networks plus a testnet, one seed, the same address everywhere. 398 automated tests pass on every commit.
- Client-side custody: seeds encrypted with AES-256-GCM, keys derived by PBKDF2-SHA256 at 310,000 iterations, entirely in the browser. No server holds anything.
- The Forge: marked addresses (ending in
dead) mined over the public key only, at about 3,600 candidates per second per thread, with deterministic results across devices. - Swaps and cross-chain crossings through the LI.FI aggregator, executed and receipt-verified, with a recipient guard before every signature.
- A client-side Sentinel for stop-loss and limit orders, honest about its limit: it executes only while the wallet is awake.
- The Oracle: a rule-based, deterministic parser for trade orders in 20 languages. No LLM, no API key, nothing leaves the device.
- The Testament: a printable inheritance document plus a check-in calendar file. It never contains a seed, key, or password.
- 20 interface languages, a PWA install path, and zero telemetry.
Built, awaiting deployment
- The four protocol contracts (vault, factory, inheritance module, on-chain Sentinel), tested on a local chain.
- A reference keeper bot that fires eligible Sentinel orders for the on-chain tip. It never holds user funds.
- The 0.25% crossing tithe (protocol fee): coded, disclosed in the UI, and dormant until the integrator registration is completed.
Planned
- The $RIP token itself, its governance, staking for fee relief, and keeper-tip sharing.
- Sleep-proof automation via ERC-4337 session keys, multi-heir bequests, and mobile apps.
No third-party audit exists today. Here is what exists instead: 398 web tests and 56 contract tests, fifteen recorded rounds of adversarial multi-agent review with every confirmed finding fixed, and a rule in the deployment scripts that blocks mainnet until a security checklist passes. We will publish any future audit report in full, including findings we choose not to fix.
Protocol economics: two real revenue mechanisms
Token value talk is cheap. Fee mechanisms in code are not. The protocol has two, both already written, neither activated for revenue today.
The crossing tithe: 0.25% on swaps and bridges
Every swap and cross-chain crossing routed through the wallet can carry a 0.25% integrator fee (LIFI_FEE = 0.0025), collected through the LI.FI fee system into a protocol treasury. The disclosed rate and the charged rate come from one constant, so they can never drift apart, and the quote screen prints the fee line whenever it is active.BUILT · AWAITING DEPLOYMENT
The fee is dormant: it activates only after integrator registration, and it has charged nobody anything yet. When it activates, the treasury address will be published here.
Keeper economics: paid execution with a hard floor
On-chain Sentinel orders pay their executor a tip: 0.5% of output by default, hard-capped at 1%. Orders can name a trusted executor or open execution to anyone. The contract protects the owner with two floors (the Chainlink price at execution minus at most 1% slippage, and an absolute minimum output) and reverts the whole trade if either fails. A tip that would eat the floor is rejected at order creation.BUILT · AWAITING DEPLOYMENT
This creates a real market: efficient keepers execute near market price and keep the spread above the floor plus the tip. The router list is locked at deployment with no admin function. Nobody, including the team, can point keeper flow at a malicious router later.
$RIP utility
$RIP is designed as a working token, not a mascot. Its four planned roles map one-to-one onto the mechanisms above. The wallet stays fully functional without it.
| Utility | Mechanism it plugs into |
|---|---|
| GovernancePLANNED | Vote on the protocol's living parameters: silence periods offered, keeper reward bounds, supported chains. These are today constants in contracts and config. Governance moves them from the team to holders. |
| Fee reliefPLANNED | Stake $RIP to reduce the 0.25% crossing tithe and keeper fees across the Explore suite. The tithe mechanism already exists in code. Staking will discount it at quote time. |
| Keeper networkPLANNED | Run a Sentinel keeper, or delegate stake to one, and share the execution tips the contract already pays. The tip plumbing is written. The sharing layer is not. |
| Legacy tiersPLANNED | Unlock extended rites: multiple heirs, staggered bequests, longer vault archives. The v1 contract deliberately supports one heir. Tiers arrive with the v2 module. |
Token utility describes the protocol's design. Nothing here is a solicitation, an offer, or financial advice.
Supply, allocation, distribution
This section is deliberately unfinished, and we would rather show you the empty chair than seat a mannequin in it. Total supply, allocation, and vesting schedules are not yet fixed. We will not publish placeholder numbers that quietly change later.
- Supply, allocation percentages with absolute amounts, and vesting schedules will be fixed and published in this document before any token generation event.
- The token contract address, the treasury address, and any vesting contracts will be published here with explorer links at the same time.
- A token generation event is planned only after the core contracts are deployed publicly and the security checklist in section VIII is complete. No date is set, and we will not announce one we cannot keep.
- Until an address appears in this document, no $RIP exists. Treat any token using this name before then as counterfeit.
Roadmap
Three states only. Done items carry evidence in the repository. Nothing here carries a date.
| State | Items |
|---|---|
| Done | The wallet (custody, Forge, swaps, crossings, Sentinel client, Oracle, Testament, 20 languages, 91 networks). The four protocol contracts with 56 tests. The reference keeper. The fee mechanism, dormant. |
| In progress | Security checklist for mainnet. Public deployment planned in the order Base, then Arbitrum, then Ethereum. Treasury address and ENS setup. |
| Planned | $RIP token and TGE, governance, staking for fee relief, keeper-tip sharing, session-key automation, multi-heir v2, mobile apps, and a perpetuals desk. |
Risk, stated before you ask
- You can lose everything you put into this protocol. Nothing in it can reverse a transaction, and nobody can restore a lost seed phrase.
- Smart contracts can fail, including contracts that have been audited. The inheritance contracts are not yet deployed to any public network and have no third-party audit today.
- $RIP may never launch, may launch with different parameters than this document describes, and may have no market or no liquidity if it does. Do not spend money you need on the expectation of a token.
- The protocol is not registered with any securities or financial regulator in any jurisdiction. Rules differ by country and can change. Holding or using crypto assets may be restricted where you live.
- Everything in sections VI and VII is forward-looking design, not a commitment to deliver by any date.
This document is not an offer to sell, a solicitation to buy, or investment advice. It describes the design of software. Make your own assessment, and verify every claim against the code.
Companion reading: the wallet documentation covers every shipped mechanism in detail: custody, the Forge, the Sentinel, and the full inheritance flow. The wallet itself is open at /app, and a no-keys demo at /showcase.
What you built shouldn't be buried with you.