Getting and Using the Wallet — Research + Ideas

Written 2026-09-25. For Leonard's music chain. His definitions hold throughout: the chain of blocks is the ledger; apps and pages are doors, never the blockchain; a wallet is the only way in; no one declares or controls the chain. No one can take your assets unless you sign them away.

What the wallet actually is

A wallet is two things and nothing more:

A keypair — a secret (private key) that never leaves your device, and a public address (amc1…) the world sees.
The chain — every wallet carries and validates the full chain of blocks.

Everything in this document serves those two things: getting the keypair into a person's hands safely, and keeping the chain in their hands as it grows.

PART 1 — GETTING ONE: how wallets are gotten today, and what actually works

1a. The seed phrase (12/24 words) — the industry default, and its record

How it works: the wallet generates random entropy, encodes it as 12 or 24 English words (BIP-39). Those words ARE the wallet. Write them on paper, keep them secret, type them into a new phone to restore.

The honest record, from public research:

An estimated 20–25% of all Bitcoin is lost forever — not stolen, forgotten. Roughly $100B+ in Bitcoin alone, from people who lost their words.
In the first half of 2026, ~76% of all stolen crypto value came from compromised keys and seed phrases (TRM Labs) — a small minority of incidents, the overwhelming majority of losses. The expensive failure is always somebody obtaining the words.
Users don't understand what they hold: in one study, only 43% could even recognize a seed phrase, and ~58% of those believed they could choose and reset it. You can't. There is no reset. There is no support desk.
A 2026 Coinspect finding: five wallets shipped a weak random-number generator (CryptoJS) that made recovery phrases predictable — $5.69M+ stolen. Key generation is only as good as the randomness behind it. (His chain uses Ed25519 with deterministic nonces, which removes the per-signature RNG failure class — but the initial seed still needs real randomness.)
Physical coercion is real: ~$30M stolen by force in H1 2026, a quarter to a third of it by pressuring family, not the holder. Words in someone's head can be beaten out. No hardware defeats that.

Verdict: seed phrases are the most honest option (zero trust in any company) and the most punishing option (one tired evening and it's gone). They made sense for cypherpunks in 2014. For his people — artists, families, normal phone users — the loss rate is the argument against them.

1b. Passkeys (Face ID / fingerprint) — the current best onboarding

How it works: the phone's secure hardware (Secure Enclave on iPhone, StrongBox on Android) generates a key. The private key never leaves the chip — it can't be exported, photographed, or typed into a phishing site. You unlock it with your face or fingerprint. No words to write down.

The production proof: Coinbase Smart Wallet has shipped passkey wallets at scale since June 2024 — WebAuthn, P-256 signatures verified on-chain (RIP-7212), MIT-licensed contracts anyone can fork. Users sign in like they sign into any website. Leonard's own NEXUS whitepaper already specifies this exact architecture (passkeys + social recovery + session keys) — it is his prior art, and it is the industry's direction.

The catch for HIS chain: WebAuthn authenticators sign with P-256 (secp256r1). His chain is Ed25519. A phone secure element can hold an Ed25519 key too (Android StrongBox and iOS Secure Enclave both support raw key storage), biometric-gated — but then the key is device-bound: it does not sync to iCloud/Google like a WebAuthn passkey does. Lose the phone, lose the key, unless a separate recovery path exists. The synced-passkey convenience (new phone, face unlock, wallet's back) comes from Apple/Google's cloud — which is a trust assumption (see Part 2).

1c. Social logins / custodial — NOT his model

"Sign in with Google" wallets exist. They work by a company holding your key (or a share of it) and handing it over after you log in. That is a bank with extra steps. It violates his first law — no one can take it from you becomes the company can take it from you. Listed here only to reject it: any "getting one" flow where someone else can move your assets is not a wallet on his chain. It's an account.

1d. What his prototype already does

The PWA at ~/workspace/music-blockchain/wallet-app/: generates the Ed25519 keypair in the browser on the user's device, shows the private key once with a warning, keeps it in the browser, signs locally. That is the correct shape — key born on the device, never transmitted. What's missing is everything around it: backup, recovery, and a way to get the page into people's hands (Part 4).

PART 2 — KEEPING IT: backup and recovery, with the trust each one smuggles in

His law: no one can say they own it or take it from you unless you transfer it. Every recovery mechanism below reintroduces someone or something. The honest move is to name the smuggled trust plainly, so HE chooses it instead of it hiding in the design.

Method	How it works	Trust smuggled in	What breaks
Paper words (BIP-39)	12/24 words on paper/metal	Trusts YOU forever: no fire, no loss, no photo, no one finds it	Lose it = lose everything. No recovery, ever. (~20% of BTC proves the rate.)
Encrypted cloud backup (iCloud/Google Drive)	Key encrypted with a password, ciphertext in your cloud	Trusts Apple/Google to hold the ciphertext honestly; trusts your cloud password	Cloud account hacked or locked = wallet gone or exposed. Provider sees that you have a wallet.
Device passkey sync (iCloud Keychain / Google Password Manager)	Key syncs E2E-encrypted across YOUR devices	Trusts Apple/Google's sync infrastructure and your platform account	Locked out of your Apple/Google account = locked out of the wallet.
Social recovery (guardians)	3-of-5 chosen people/devices can rotate your key after a delay (Argent: 48h, cancellable)	Trusts guardians not to collude, not to all die/lose interest, to be reachable and competent	Guardians collude = they take your assets. Guardians vanish = no recovery. Needs a delay + cancel, or a thief with 3 friends wins.
Shamir split (2-of-3 shares)	Key split mathematically: phone + paper + trusted person; any 2 rebuild it	Trusts each share-holder with a piece; trusts you to understand the scheme	Lose 2 shares = gone. One share-holder + your phone = they own it. Complexity kills normal users.
NO recovery (pure)	Key lives on the device. Lost phone = lost assets. Period.	Trusts nothing and no one	The only option with zero trust assumptions — and the cruelest UX. This is Bitcoin's original position.

The Vitalik framing, which is the honest one: the goal was never to remove all trust — it's to give people choice in whom to trust, in constrained forms (someone can help you recover, but can't spend). Every row above is a different answer to "who do you trust, and with how much power?"

His NEXUS design already chose: 3-of-5 guardians (biometric passkey, backup device, Garcia Holdings attestor, co-op member, validator partner) with a 48h timelock and root-key cancel. Note the tension honestly: the "Garcia Holdings attestor" as a guardian means his company holds recovery power over users' wallets — that is a real trust assumption sitting inside his own design, and it cuts against "no one can take it from you" unless the attestor's power is strictly limited to helping recovery the user initiates, never initiating.

PART 3 — USING IT: what makes wallets hard, and the catalog idea

Why normal people bounce off wallets

Addresses. amc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh is not a thing a human can check. One wrong character = money gone. (His amc1 prefix at least tells the eye which chain it belongs to — the prefix is inside the address checksum, so a wrong-chain address fails loudly instead of silently.)
Jargon at the moment of action. Gas, nonce, UTXO, confirmations — every unfamiliar word at the "send" screen is a reason to close the app.
Confirmations that read like riddles. "Sign this hex blob?" Nobody can verify what they're signing. The best wallets show what happens in plain words: "Send 'Purple Monster' to Sara."
Irreversibility with no guardrails. No undo button, ever. Combined with (3), this is where life-changing mistakes happen.
The empty-wallet problem. You get a wallet, it holds nothing, you can't do anything, you leave. (NEXUS names this: ~41% abandonment when a user receives an asset but can't move it.)

The catalog, not the coins

His insight — we move music as currency — is also the UX answer. The wallet does not show "balances." It shows your catalog:

  ┌─────────────────────────────┐
  │  MY CATALOG                 │
  │                             │
  │  ♪  Purple Monster          │
  │     yours · registered      │
  │     2026-09-25              │
  │                             │
  │  ♪  Cash Talk               │
  │     50% yours · split with  │
  │     Sara                    │
  │                             │
  │  ▤  1420 W Deed — Lot 9     │
  │     yours · registered      │
  │     2026-08-14              │
  │                             │
  │  [+ Register something]     │
  └─────────────────────────────┘

No coin amounts on the home screen. No gas. No hex. Things you own, who they're split with, when they were registered. The chain mechanics (fees, blocks, seals) live one screen deeper, for whoever wants them — the same way a bank app shows your money first and the wire-transfer plumbing never.

The five core actions, step by step

1. GETTING ONE (first run)

  open wallet page → "Create my wallet"
      → phone generates keypair IN THE PHONE (nothing sent anywhere)
      → "This is your wallet: amc1…"
      → backup step (whichever recovery he chooses — Part 2)
      → DONE. You hold the chain's newest wallet.

What it must never do: send the key anywhere, show the key on screen longer than the backup moment, or let the user skip backup without typing "I understand no one can recover this for me."

2. REGISTERING A SONG

  tap [+] → pick audio file
      → phone hashes the audio LOCALLY (the file never uploads)
      → shows: title, artist, fingerprint, "claiming as: you"
      → Face ID → signed → sealed into a block
      → "Registered. The chain says you claimed this on 2026-09-25."

Honest wording (from the research): it proves a timestamped claim, not legal ownership. The screen should say "claimant," not "rights holder," unless a real adjudication mechanism exists.

3. SENDING AN ASSET

  open the track → "Send" → scan her QR (or pick from contacts)
      → plain-words confirm: "Send 'Purple Monster' (100%) to Sara (amc1…9f2)?"
      → Face ID → signed → "Sent. It's hers now — only her key can move it."

The QR carries the address only — never any secret. This is also the phone-to-phone handshake shape his NEXUS work already designed (intent by QR, execution on-device, receipt back over the channel).

4. EARNING SEALING FEES

  wallet seals a block → small fee from every move in that block
      → "Your wallet earned 0.42 keeping the chain running."

This is his exchange model made visible. The wallet should show earnings like a payout, not like mining jargon. It is also the reason to keep the wallet installed and the chain syncing: the wallet pays its holder.

5. PROVING WHAT YOU HOLD (to anyone, offline)

  open the deed → "Show proof" → QR on screen
      → verifier's wallet checks the chain IT carries
      → "Valid: registered 2026-08-14, never moved since."

No server involved. Two phones, one QR, each trusting only the chain they hold. This is the thing no bank app and no custodial wallet can do.

PART 4 — WHERE IT LIVES: distribution, honestly

The wallet page has to live somewhere people can open it. Every option has a gatekeeper except the ones where Leonard IS the infrastructure.

Channel	Friction	Gatekeeper	Honest notes
His own domain (self-hosted page)	User types a URL or scans a QR	None — he controls the server	No review, no rejection, no expiry. But: he runs a server (cost, upkeep), and users must trust the page hasn't been swapped — the page should be byte-verifiable / content-addressed so anyone can check.
IPFS (content-addressed)	Needs a gateway or local node in a normal browser	None for publishing; gateways for reading	The CID is the integrity check — the page can't be silently swapped. Matches "verify, don't trust." But normal users won't type `ipfs://` — it needs a friendly gateway or his domain pointing at it.
PWA install (Add to Home Screen)	Manual on iOS (Safari → Share → Add); ~50MB storage cap on iOS; no push notifications on iOS	Apple (Safari's limits)	Works, offline-capable, no store review. But iOS treats PWAs as second-class: manual install, storage ceiling, no Face ID inside the PWA frame on some versions (biometric-gated keys may need the browser context). Android PWAs are first-class citizens.
Google Play (native app)	Normal install	Google	Non-custodial wallets are explicitly EXEMPT from the Oct 2025 licensing rules (FinCEN/MSB/MiCA apply to custodial). His wallet qualifies as non-custodial. Still: review roulette, takedown risk, Google can delist.
Apple App Store (native app)	Normal install	Apple	Allowed under guideline 3.1.5(b) for self-custodial wallets, but the developer must enroll as an organization, and Apple is the permanent gatekeeper — review, 30% politics on anything that smells like a sale, delisting power.
Android sideload (direct APK)	"Unknown sources" warning scares users; no auto-update	None	No gatekeeper at all. Real cost: users are trained to fear it, and updates are manual unless he builds an updater.
BrewPage	One link, easy	REJECTED his wallet page ("content rejected" — apparently over in-browser key generation)	Lesson learned: hosted-page services with content filters can refuse a key-generating page with no appeal. Not a durable home for the wallet.
here.now	Easy link	Expiry	24 hours. A try-it link, never infrastructure. He already ruled: a page is not the blockchain, and a 24h link is not a home.

The pattern: every easy channel has a gatekeeper; every gatekeeper-free channel has friction. The realistic shape is probably two doors: his own domain (primary, no gatekeeper) + app stores (reach, with their rules) — the same page, two doors, and the wallet itself identical because the key is born on the device either way.

PART 5 — THE CHAIN ON THE PHONE: what it costs as it grows

His rule: every wallet carries and validates the chain. The honest physics:

Day one: the chain is megabytes. Every phone holds it easily. This is where Bitcoin was in 2010 — and it worked.
The wall: chains grow monotonically. Bitcoin went from megabytes to hundreds of gigabytes; full-node-on-phone died there (multi-day syncs, metered data, batteries). Nobody has ever kept "every wallet is a full node" on a growing chain without changing what "the chain" means.
What "carrying the chain" actually costs: storage (blocks), bandwidth (initial sync + staying current), CPU/battery (verifying signatures), and — the forgotten one — first sync: a new phone downloading and re-validating everything from genesis. That was the wall even Bitcoin Core's developers never got past on mobile.

Mitigations, with tradeoffs stated (no invented solved design):

Keep blocks small, history prunable. Wallets keep recent blocks + headers, drop ancient block bodies once validated. Cost: a pruned wallet can't serve old blocks to new phones — someone must hold the archive, or new users can't sync. (Bitcoin's pruned nodes: <1GB, but they leech.)
Checkpoint sync. New phone downloads a recent verified snapshot from a peer it chooses, then validates forward. Cost: you trust the snapshot — whoever gave it to you could lie about history. Mitigate by cross-checking multiple peers, but it's still trust, not verification.
Phone-to-phone chainstate copy (the bitcoin-pocket-node pattern: QR code, full node on a phone in under 20 minutes, resume on failure). This FITS his model beautifully — no server, just phones handing the chain to phones. Cost: still the full data, and the first phone in a room has to get it from somewhere.
Succinct proofs (Mina-style ZK). The whole chain compresses to ~20KB a phone verifies in milliseconds. Cost: someone with serious compute generates the proofs — a new specialized infrastructure role — and the proof system's soundness becomes the trust surface. Research-grade for his chain, not a plan.
Utreexo-style accumulators. Keep a hash-commitment to all state instead of the state; proofs travel with transactions. Cost: bandwidth per transaction goes up, still research-phase on Bitcoin itself.

The honest bottom line: "every wallet carries the chain" is true at small scale and gets expensive at large scale, and there is no free fix. The protocol has to pick its tradeoff early — small blocks + pruning is the simplest honest path — or the rule becomes one everyone quietly breaks (light clients asking someone else's server for balances — which is a middleman with a new name, and fails his test).

THE IDEAS — concrete options

Idea 1: "The Paper Key" (seed words, his prototype + BIP-39)

Get: open wallet → tap "Create" → keypair born on device → 12 words shown once → user writes them down → re-enter 3 random words to prove it.
Use: Face ID/PIN unlocks the app; words never needed again unless restoring on a new phone.
Trusts: the user, forever, with paper. Nobody else.
Breaks: fire, loss, a photo of the words, death with no plan. ~20% of Bitcoin's supply is the measured outcome of this design.
Fits his law perfectly; punishes normal people relentlessly. Best for: the power users and the principled core. Worst for: his artists' families.

Idea 2: "The Face Key" (biometric device key, no words)

Get: open wallet → tap "Create" → secure chip generates Ed25519 key, biometric-gated, non-exportable → "Your wallet is your face/fingerprint." Nothing to write down. Nothing to photograph.
Use: every send/register is a Face ID prompt. Feels like Apple Pay.
Trusts: the phone's secure hardware + the user not losing the phone.
Breaks: lost/broken phone with no backup = everything gone. Device-bound keys don't sync (unlike WebAuthn passkeys), so this REQUIRES pairing with a recovery idea (3 or 4). Cannot stand alone.
Best onboarding in the industry (Coinbase proved it at scale) with the sharpest recovery requirement. The backup step is not optional — it's the whole design.

Idea 3: "The Trusted Circle" (guardians — his NEXUS model, adapted)

Get: create wallet (Face Key) → pick 3–5 guardians: people whose wallets you trust, a second device of yours, maybe a paper backup as one "guardian."
Use: daily use is just Face ID. If the phone dies: new phone → "Recover" → 3 of 5 guardians approve → 48h waiting period (you can cancel if it's an attack) → key rotates to the new phone. Address stays the same.
Trusts: guardians not to collude, to still exist and answer when needed.
Breaks: guardians collude (they take it); guardians ghost (no recovery); no delay/cancel (a thief with 3 friends wins instantly).
The only recovery real humans actually complete. Argent ran it for years. The 48h delay + cancel is non-negotiable. And: if any guardian is his company, that power must be strictly "help when the user asks" — never "initiate" — or his law breaks.

Idea 4: "The Split Secret" (2-of-3 Shamir shares)

Get: wallet creates key → splits into 3 shares: phone keeps one, one printed as QR in a drawer, one with someone you trust.
Use: phone alone signs daily. Lose the phone: scan the paper QR + call your person → any 2 rebuild the key on the new phone.
Trusts: share-holders individually (one share is useless alone).
Breaks: lose 2 shares = gone; confusing to explain; users will photograph shares "for safekeeping" and defeat the math.
Elegant, unusable for normal people. Keep as the power-user option.

Idea 5: "The Handoff" (get your wallet FROM another wallet)

Get: no website, no store. You meet someone with the wallet → they tap "Invite" → your phone scans their QR → your phone generates its OWN keypair locally → their wallet sends you the chain's current state phone-to-phone → you're in, holding the chain, in under a minute.
Use: identical to Ideas 1–3 from here (the Handoff is about getting, not using).
Trusts: the inviter's copy of the chain (your wallet re-validates what it receives — trust, then verify).
Breaks: first phone in a city still needs the chain from somewhere; invitation-gating can feel exclusive instead of open.
This is the most HIS idea. No gatekeeper, no store, no server — the network grows the way his decentralization works: person to person, wallet to wallet. It turns onboarding into the P2P sync his model already requires. Pair it with any of Ideas 1–3 for the key itself.

Recommended shape (for his decision, not mine)

Getting: The Handoff (Idea 5) as the primary path — wallet from wallet, chain from chain — with his own domain as the always-open door for anyone without an inviter. Key: The Face Key (Idea 2) for daily use — no words, nothing to lose on day one. Backup: The Trusted Circle (Idea 3) offered at setup, with the 48h delay + cancel, guardians as other wallets on his chain. Paper words (Idea 1) kept as the advanced option for whoever wants zero trust in anyone. Nothing custodial, ever.

DECISIONS ONLY HE CAN MAKE

Recovery model. Pure (key loss = asset loss, zero trust, cruelest UX) vs. Trusted Circle (humans can fail you) vs. cloud backup (Apple/Google in the loop). No design avoids this choice — even "no recovery" is a choice.
Distribution channel. His own domain (no gatekeeper, he runs it) vs. app stores (reach, Apple/Google rules, review roulette) vs. both. BrewPage already refused the wallet; here.now expires; the wallet needs a real home.
What "getting one" costs. Free (fastest growth, Sybil food — ties to the unsolved sealing question) vs. a small fee or invite (slower, pricier, harder to attack).
Guardian power limits. If his company is ever a guardian in anyone's circle, exactly what it can and cannot do — written down, in the open — or "no one can take it from you" has an asterisk with his name on it.
Claim language. "Claimant" vs. "rights holder" vs. "owner" on deeds, titles, birth certificates. The chain proves a timestamped claim; calling it ownership is a legal statement no chain can make alone.
The growth tradeoff. Small blocks + pruning (simplest, someone must archive) vs. heavier phone requirements vs. succinct-proof research. Pick early — retrofitting this later means changing what "carrying the chain" means.

Research sources: BIP-39/32/44, SLIP-0010/0044/0173, RFC 8032, Bitcoin wallets-and-keys ingest (~/workspace/study/blockchain-ingest/wallets-and-keys.md), NEXUS whitepaper skill, Argent/Safe social-recovery docs and audits, Coinbase Smart Wallet (passkeys in production since 2024), TRM Labs H1 2026, Chainalysis/Glassnode loss estimates, Google Play Oct 2025 crypto policy (non-custodial exempt), Apple guideline 3.1.5(b), Mina/Utreexo, bitcoin-pocket-node (phone-to-phone chainstate).