Custody: where your keys live
RIP Wallet is non-custodial in the strict sense: there is no server, no account, and no recovery desk. Your seed phrase is generated in your browser, encrypted in your browser, and stored in your browser. Nothing that can move funds ever leaves the device.
| What | How |
|---|---|
| Encryption | AES-256-GCM via WebCrypto. The key is derived from your password with PBKDF2-SHA256 at 310,000 iterations, with a random 16-byte salt and 12-byte IV per keystore. |
| Storage | One encrypted blob in localStorage. A wrong password fails the GCM auth tag cryptographically. There is no server-side check, because there is no server. |
| While unlocked | Decrypted seeds live in plain module memory only: never persisted, never in app state, cleared on lock, emptied by any page reload. |
| Auto-seal | The vault seals after 15 minutes without input by default (configurable, 0 disables). Sealing one tab seals every tab. |
| Across tabs | A cross-tab guard propagates locks and wipes: delete the keystore in one tab and every tab resets. Rewrite it and every tab re-locks. |
| Demo isolation | The /showcase demo is severed from real storage at the storage layer itself. The three keystore writers are hard-gated so a demo can never overwrite your real seal. |
Metadata poisoning is designed out: only public data (labels, indexes, addresses) persists between sessions, and on every unlock all addresses are re-derived from the seed itself. The lock screen shows no address at all. Nothing unverified is displayed before the seed proves it.
Getting started
Creating a vault
The ceremony shows your twelve words once, then requires you to recall three of them, chosen at random, before you may set a password of at least 8 characters (the strength meter is local and deterministic). A browser that refuses storage (private mode, full quota) is reported loudly instead of letting you believe a vault exists.
Every new vault is born marked: a background search finds an address ending in dead within seconds and makes it your first tomb. Creation never blocks on it. If the search needs longer than 20 seconds, the wallet proceeds and tells you.
Restoring
Restore with your twelve words on any device, set a fresh password, and the same addresses rise again. The password only guards the local copy. The words are the wallet. An imported seed's first address may already hold funds, so the marked tomb is added alongside it, never over it.
Losing a device
Nothing that matters lives on the device. Funds are on-chain. The keystore is an encrypted local copy of keys that derive from the twelve words. Install the wallet anywhere, restore with the words, and everything returns. There is no password reset and no support channel that can help. This is by design, because any channel that could recover your wallet could also steal it.
Lose the twelve words while your device is dead, and no one can help. This is exactly what the Afterlife Protocol exists for: if you can no longer transact, silence eventually falls, and your named heir can still claim the vault (section X). Write the words on paper. The Testament (section XI) gives your heir everything else they need.
Tombs and dynasties
One vault holds up to 8 seed phrases (dynasties) with up to 64 accounts each, derived on the standard EVM path m/44'/60'/0'/0/{index}. Each tomb has its own address, balances, and history. One password seals them all.
Unlocking a completely full vault takes under a second. The derivation pipeline was rebuilt after profiling showed 4.7 seconds. It now measures 0.9.
The Forge: marked addresses
The Forge searches your own seed's address space for addresses bearing a mark, by default the protocol's dead suffix. It searches over the extended public key only: Web Workers never see a private key, and the seed never leaves the main thread.
| Property | Detail |
|---|---|
| Speed | About 3,600 candidates per second per thread via public-key point arithmetic. This is 29× faster than naive derivation, verified address-identical against the signer library. |
| Marks | 2 to 5 hex characters. Expected work is stated before you start: a suffix of n characters costs about 16ⁿ candidates. |
| Determinism | A sequential-window protocol (windows of 65,536 indexes) guarantees any device, any thread count, finds the same address for the same mark. |
| Honesty | The both-ends mark (dead at the start and the end) has only ~39% odds of existing in your seed's search space at all. The UI says so before you burn CPU, not after. |
Forged addresses usually live beyond the BIP-44 gap limit of 20 sequential accounts. MetaMask or Rabby importing your twelve words will not find them automatically. Each stone engraves its full derivation path. Add the account by index in the other wallet, or keep using RIP Wallet.
Sending
- Every send passes a Review step with a network-cost estimate first, and is recorded as success only when the receipt says success. A transfer that mines but reverts is reported as a failure, never as done.
- Recipients: raw addresses, ENS names (resolved against Ethereum mainnet regardless of the active chain), and your local address book. Optional whitelist-only mode restricts sending to the book, your own tombs, and your vault.
- The Max button measures the real gas buffer instead of guessing: 2× headroom on execution cost, and on OP-Stack chains 3× on the separately-billed L1 data fee, read live from the chain's own oracle.
- Wallet-born transactions carry ten UTF-8 bytes,
RIP Wallet, appended to calldata (~160 gas). The tag is estimate-guarded and skipped anywhere it could break a transfer. Aggregator calldata is never touched. - Amount input is locale-aware: comma or dot decimals by locale, thousands separators stripped, and Arabic-Indic, Persian, and Devanagari digits accepted.
Swap and the Crossing
Swaps and cross-chain crossings route through the LI.FI aggregator and are executed, not merely quoted: the wallet sends the transaction and verifies the receipt. The receive picker takes any contract address, so a token five minutes old is as reachable as USDC, and a complete form quotes itself after a short pause.
| Guard | Behavior |
|---|---|
| Token by address | Paste a contract address into the receive picker and its metadata is read from the contract itself. The homoglyph guard still applies, and the full address stays visible, because the address is the token's only identity. After a successful swap the token is saved so its balance shows in Assets. |
| Slippage | Presets 0.1% / 0.5% / 1% plus a custom value up to 50%. Changing it voids the current quote. Slippage wide enough to feed sandwich bots draws a warning instead of silence. |
| Anti-MEV | On Ethereum and BNB Chain the trade can travel through a private relay, Flashbots Protect or 48 Club, so the public mempool never sees it before it lands. Chains whose sequencer keeps no public mempool say exactly that instead of faking a shield. |
| Price impact | The change between the USD worth of what you pay and what you receive, taken from the aggregator's own numbers, never computed cosmetically. Past five percent it becomes a warning. |
| Auto-quote | A complete form asks for its own route after a short pause, and asks again when the 75-second passage expires. Nothing executes without your press. |
| Quote age | Bridge quotes expire after exactly 75 seconds and are re-checked after a slow token approval. A stale quote is refused before signing. |
| Recipient guard | The address embedded in the route is compared with the recipient you expect, before signature. Cross-chain sends cannot be canceled, so mismatches never reach the network. |
| Balance pre-check | Value plus worst-case gas is checked up front, so an opaque node rejection after signing never reaches you. |
| Protocol fee | When active, a 0.25% fee is included and printed on the quote screen. It is currently inactive. The label and the charge derive from one constant and cannot diverge. |
| Testnets | Aggregation does not exist on testnets, and the wallet says so instead of simulating. |
Destination-side settlement of a crossing belongs to the bridge and can take minutes after the source receipt. A crossing that reverts at the source moves nothing.
Token import and approvals
Importing a token
Metadata is read from the token contract itself, with no third-party list. Because that metadata is attacker-controlled text, symbols are capped at 12 characters, names at 48, decimals validated 0-36, and control and bidi characters stripped. Anti-spoofing rejects a symbol that collides with an existing token even through Cyrillic or Greek lookalikes, using an NFKC skeleton comparison.
The revoke panel
The approval scanner reads on-chain approval logs, then re-verifies each against current chain state, so revoked history is never shown as live. Allowances at or above 10³⁰ are classed unlimited and sorted to the top. When a public RPC caps the scan range, the result is flagged incomplete. A list that hides its own gaps is worse than no list.
The panel exists for a serious reason: inheritance transfers vault ownership, not its history. Spending approvals granted by the previous owner survive, and the heir, who never consented to them, gets a panel to see and demolish them.
Launching a token
The Launch menu sends a token to the launchpad you choose, from this wallet, with your keys, on the launchpad's own contracts and open APIs. The list carries the five networks with the largest trading volume on DEX Screener, at most three pads each, taken by volume. Six pads launch natively, Solana included: the vault's seed also derives a Solana key on Phantom's own path, so the same twelve words sign in both worlds and never leave the device. A pad with no verified public creation path is an honest outbound link, never a form that ends in nothing.
| Pad | How it launches |
|---|---|
| Pons | The house pad of Robinhood Chain, called straight at its public V2 factory. The launch fee and the creator-tax ceiling are read from the contract, the economics are pinned with previewLaunchEconomics so an owner re-peg cannot land under an in-flight launch, and your token is born onto its bonding curve. Simulated first, refused before signing if it would revert. |
| pump.fun | Solana. The metadata pins through pump.fun's own IPFS route, PumpPortal's local API assembles the creation unsigned, and the vault's derived Solana key signs it on this device together with the newborn mint key. We broadcast it ourselves. Creation is free, the route takes half a percent of the first buy only. |
| LetsBonk | The same local route pointed at LetsBonk's LaunchLab pool on Solana. Identical custody: assembled unsigned, signed here, sent by us. |
| four.meme | The wallet signs you in with a message signature, uploads your image, asks four.meme's backend to countersign the creation, then submits createToken on BNB Chain. Supply is fixed at one billion by the platform, and the raise parameters are copied from their live public config, never invented. |
| Clanker | A direct call to Clanker's public v4 factory on seven chains, Ethereum and Base to Robinhood. The token and its Uniswap pool deploy in one transaction, simulated first. Optional creator lock, seven days at minimum, and an optional first buy. |
| Flaunch | A Uniswap V4 launch on Base through Flaunch's public contracts and keyless IPFS uploader. You set the starting market cap and your own share of the trading fees. Flaunch charges no protocol fee below a 10k USD market cap. |
Launching costs gas plus whatever first buy you choose. The wallet never takes custody of the new supply: it lives in the launchpad's contracts, under that launchpad's published rules.
Watching other wallets
Every address is public, and the Watch menu treats that as the feature it is: paste any address or ENS name and see what it holds across the five networks with the most users, Ethereum, BNB Chain, Base, Arbitrum, and Polygon. Balances come from the chains, prices from the same public feed the rest of the wallet uses, and assets without a public price are counted out loud instead of silently rounded to zero.
A watched wallet gets a baseline: the value it held when you began watching. What the panel shows after that is honest value change, labeled as such, because deposits and withdrawals move it too. Trade-by-trade PnL of a stranger's wallet needs a paid indexer of their whole history, and this wallet does not pretend to have one. Watching is read-only in the strictest sense: nothing is ever signed, and the watchlist lives in your browser, not on a server.
The Sentinel and the Oracle
Beside the Sentinel hangs the Knell: one-shot price bells, set from any Market row. When a coin crosses your threshold the bell rings once, in the app and as a browser notification if you allowed it, then falls, so an alert never becomes a noise. Bells ring only while the wallet is awake, and the wallet says so where you hang them. The Assets header also carries a daily line, the change in your holdings' value since yesterday, labeled as value change because deposits and withdrawals move it too.
Client-side Sentinel (shipped)
- Standing stop-loss and limit orders, checked every 45 seconds while the wallet is awake and unlocked. It is not an anti-sleep keeper, and the UI says so.
- Execution takes a 10-minute lease with tab identity, closed against multi-tab races via the Web Locks API. A refresh mid-execution cannot double-fire an order.
- Prices older than 90 seconds never sign. Display tolerates 5 minutes. Spending does not.
- Three attempts, then the order fails permanently. Your cancel is final and is only ever overridden by the on-chain fact of an already-broadcast transaction.
On-chain Sentinel (built, awaiting deployment)
RIPSentinel holds orders that survive sleep: Chainlink-triggered, with an executor tip of 0.5% by default, capped at 1%, and a 90-day order TTL. The owner is protected by a dynamic floor, the oracle price at execution minus at most 1% slippage (hard cap 10%), plus an absolute minimum-output floor. Failing either reverts everything. No deposits: funds move only via your allowance at execution, and you can cancel anytime before. The router whitelist is fixed at deployment with no admin function.BUILT · AWAITING DEPLOYMENT
The Oracle (shipped)
The natural-language order parser is rule-based and deterministic: no LLM, no API key, fully client-side, in the same 20 languages as the interface. Three audited rules keep it safe: trigger direction is never guessed, the first-named token is the one released, and every number carries its token unit so "buy 100 USDC with ETH" can never become 100 ETH.
The Afterlife Protocol
The full mechanism design lives in the whitepaper. This is the operator's view.
| Step | What happens |
|---|---|
| 1 · Raise | Deploy your vault: a smart account whose address ends in dead, mined deterministically so the address is identical on every device, even before deployment. |
| 2 · Name | Name exactly one heir and a silence period: 180, 365, or 730 days. Default one year. You can change or unbind either at any time. |
| 3 · Live | Every transaction the vault sends is an implicit check-in. Transactions from your plain accounts do not touch the timer. The interface tells you this to your face. |
| 4 · Silence | If the timer runs out, the heir may start a claim. This opens a hard 30-day grace window. |
| 5 · Grace | One transaction from you, any transaction, cancels the claim instantly. As long as you breathe on-chain, the vault is yours. |
| 6 · Handover | If grace passes untouched, ownership transfers. Assets follow the account: every token, every balance, in one transfer. |
| 7 · Clean slate | The heir receives an unconfigured vault. Your heir setting and timer are deleted, never inherited. The revoke panel then shows them every approval you left behind. |
Fail-open is the protocol's spine: a broken or malicious inheritance module can never freeze the vault, because every fund-moving path treats the module as optional. Availability of your own money outranks every other property.
Deployment status: the contracts run on a local development chain today, covered by 56 tests. On networks without contracts the app shows the Afterlife panel as an explicit model. Public deployment order is Base, Arbitrum, then Ethereum, after the security checklist.
The Testament
The Testament is a printable paper document for a notary, a safe, or a sealed envelope. It contains public addresses and instructions for your heir, and never a seed phrase, private key, or password, which the document itself states out loud. It ships with a calendar file: monthly check-in reminders, three per silence period, each with an alarm 12 hours ahead.
WalletConnect
The bridge to external dApps is fully coded and dormant until a relay project id is configured. When active, it is deliberately narrow:
- Seven whitelisted methods. Unknown methods are rejected, not forwarded.
eth_sign(raw blind signing) is rejected forever. - A
personal_signpayload that is exactly 32 opaque bytes is flagged as a disguised transaction hash. - The request's chain must equal your active chain, and typed data's own embedded chain id must match too. An innocent-looking envelope can wrap a permit for a chain you never saw.
- Every peer-supplied string is sanitized (bidi overrides, zero-width characters, control characters), and the approval screen shows the origin host, never the dApp's self-chosen title.
Networks, RPC, and the backend
- 91 EVM mainnets plus Base Sepolia for testing. One seed, the same address on every one of them. Non-EVM chains are refused honestly. We will not show an address we cannot sign for.
- Per-chain RPC overrides accept http(s) endpoints and are probed with
eth_chainIdbefore saving. In the demo they live only in tab memory, so a private endpoint with an API key is never exposed. - The optional backend only caches public prices and proxies quotes behind a rate limiter. It holds no keys and no funds, and cannot intervene in inheritance. The app works without it.
Privacy and storage
Telemetry: one empty counter ping when an address is forged, carrying nothing. Nothing else ever leaves your device. Prices come from public endpoints without an account. Market numbers are cached for 90 seconds and always carry their age. Stale data is never passed off as live.
| Data | Where it lives |
|---|---|
| Seed phrases | Encrypted blob in localStorage. The decrypted copy is in memory only while unlocked. |
| Password | Nowhere. It exists only in your head and, momentarily, in the key-derivation call. |
| Address book, settings, activity | localStorage, local to the device, wiped by Reset. |
| Anything on a server | One integer: how many marked addresses were ever forged, counted by an empty ping. No account, no database of you. |
What RIP Wallet does not do
Read this before trusting us with anything. Every product has edges. These are ours, today.
- No non-EVM chains: Solana, Bitcoin, and Tron use different cryptography. Planned later for balances and sending, explicitly without inheritance.
- No hardware-wallet support yet.
- The inheritance and on-chain Sentinel contracts are not yet on any public network. The in-app Afterlife panel runs as a model until they are.
- No third-party audit yet: 398 web tests, 56 contract tests, and fifteen adversarial review rounds exist instead, and mainnet is gated on a security checklist.
- Client-side Sentinel orders execute only while the wallet is awake. Sleep-proof keepers arrive with session keys.
- The NFT tab links to your collection on OpenSea. It does not render it in-app.
- One heir per vault in v1. Multi-heir with splits is deferred deliberately.
- No recovery service of any kind. See section III, and mean it.
Deep links
Every screen is addressable: /app?go=<target> opens a tab or ritual directly, and the intent survives the unlock screen. Unknown targets are discarded and the URL swept clean.
| Target | Opens |
|---|---|
assets · legacy · activity · ai | The four tabs. |
send · receive · swap · launch · watch · futures · market · discover · earn · buy · nft · accounts · forge | The rituals: modals for each, ready to use. |
Questions about the token belong in the $RIP whitepaper. Try everything in the showcase. No keys, no vows.