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 77 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. 1043 web tests pass on every commit.
- The Solana realm: SOL, SPL, and Token-2022 balances, sends, and Jupiter-routed swaps from the same seed, derived on Phantom's path. Every transaction is simulated with a spend cap before it is signed, and confirmation is polled from the chain, never assumed.
- 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. Any token is reachable by pasting its contract address, and on Ethereum and BNB Chain the trade can travel a private relay so the public mempool never sees it.
- Launching: six launchpads accept a token created from inside the wallet, on their own contracts and open APIs. Pons on Robinhood Chain, pump.fun and LetsBonk on Solana, four.meme on BNB Chain, Clanker across seven networks, Flaunch on Base. The same seed signs on Solana, derived on the standard path, and never leaves the device.
- The Séance: read any address or ENS name across the five largest networks, and keep an honest record of its value since you began watching. Read-only, nothing signed.
- The Knell: one-shot price bells that ring once, in the app and as a desktop notification, then fall silent.
- Swap in the shape of relay.link: one panel, either leg pickable from any of the 91 EVM networks or Solana, without switching the active network first. The aggregator decides which pairs it can actually route, and a pair it does not cover is reported as no route with the reason it gave, never as a price. Value moves between realms through the LI.FI aggregator, with the route's embedded recipient checked character for character before anything is signed, and native Bitcoin as a receiving leg from any of them.
- On-chain limit orders on Solana through Jupiter's trigger program: they execute when the price arrives even with the wallet closed, and the escrow trade-off is stated before signing.
- A lookalike guard on every send: an address that matches a trusted one at both ends but differs in the middle is held up with both addresses shown in full.
- The final form: the owner inscribes on-chain which one coin the estate should become for the heir, Bitcoin by default, together with the Bitcoin address it should arrive at, checked against the address checksums before signing. The same signature sets aside about five dollars of gas in the inheritance module, released to the heir at the claim so an empty heir wallet can carry the estate across.
- A Solana tomb: an Anchor program with the same dead man's switch, final form and gas fund, built and tested through the full claim on a local validator. Not yet deployed to mainnet, and the wallet says so.
- A real on-chain history in the Solana realm, read from the chain rather than from what the wallet happens to remember, alongside the issuer powers still live on any token you hold.
- 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.
- Housekeeping a holder expects: every standing spending permission of the active account listed and revocable, a hanging send sped up or cancelled with the same nonce, one list of everything held across every EVM network and the Solana realm, read on demand, trending and newborn pools per network, and balances under a dollar folded away.
- 20 interface languages, a PWA install path, and no telemetry beyond one empty, anonymous counter ping when an address is forged.
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: 1043 web tests, 77 contract tests, 48 deploy-gate tests, 85 keeper tests and 29 Solana program tests, more than twenty recorded rounds of adversarial multi-agent review, the most recent on 6 September 2026, 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: the executor is paid exactly its tip, a fixed share of the output, and every other wei goes to the owner. A worse route does not pay the executor less, it pays nothing at all, because the owner's floor is checked after the tip and a route below it reverts the whole call. 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 77 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.