TLDR

here is a way to think about self-custody as you create products for users, market products to users, and consider products yourself as a user.

nothing in life is 100% — happiness, uptime, health, or security. custody can’t be either.

where are we today?

• ethereum requires externally-owned accounts (EOAs) to initiate transactions. each EOA is tied to a single key pair. every abstraction still depends on that one signer — it can’t rotate, can’t revoke, and never expires.

• smart wallets don’t let you export a smart account into another wallet. a smart account you cannot port is vendor lock-in and high risk— the opposite of smart.

• smart wallets distribute keys with providers: with Privy for shamir secret sharing, and with others for MPC. shares often sit in Amazon or other clouds. they still call this self custody. it’s more like distributed and shared custody.

• recovery is fragile. in self-custody you must re-import your seed phrase exactly — lose it and it’s gone. in provider custody you wait for reset approval, locked out until they say yes.

• recovery providers also rely on apple and google app stores; aws nitro and other tee. if delisted, your account gets even harder to reach.

what to do then?

don’t rely on a single eoa key that never rotates. don’t rely on a smart wallet you cannot port.

use pure eoas for burners or daily spenders. don’t use them for anything seriously of financial or emotional value.

for real security, consider some mix of eoa, mpc/tss, and smart wallets because you will have and need them all in some way.

DETAILS

onchain user experience is account management is key management is access and control. the user journey in crypto is based on keys, that are really just secrets protecting user accounts from unauthorized access and control, and guaranteeing users access and control of their accounts.

access and control

every screen tap or click first authenticates (access) with a secret and authorizes (control) the action. users tap screens and press buttons with secrets—device pins, passwords, oauth tokens, seed phrases. each tap requires access, then control.

key management covers all these secrets, not just onchain seed phrases. creating, storing, rotating, and recovering passcodes, passwords, tokens, keys, and account metadata is core to both productivity and security. doing this takes more than a wallet and more than steps. it takes devices, networks, services, and apps—layers.

users have to go online to go onchain

users connect, sign in, and use services to reach onchain transactions. they move from being online to executing onchain transactions through layers.

services

to reach onchain, users must: connect to a network, unlock a device, launch an os and data-sync service, open a wallet app or extension, and reach an identity provider.

apps

software delivers these services, secured by credentials and profile metadata. apps run on devices or browsers for email, storage, messaging, browsing, and more. each app requires its own account and secret.

accounts

each service requires its own account—isp profile, device login, apple/google id, cloud-storage login, wallet login, oauth account. every account needs at least one secret: device pin or biometric, account password, oauth token, seed phrase, or private key.

users need distinct accounts for every service and every onchain address. accounts hold usernames, settings, permissions, and metadata. users create, import, recover, and export accounts across chains.

• internet (offchain) accounts: network provider, os, data-sync, wallet app, identity provider. secured with pins, passwords, oauth. recovery depends on the service.

• onchain accounts: ethereum, bitcoin, solana, and others use externally owned accounts (eoas). an eoa is one static key pair from a seed phrase. only eoas can initiate and pay for transactions. eoas cannot rotate or revoke keys if compromised.

wallets

all wallets are apps. all apps have accounts. therefore wallets are not accounts. wallets let users control accounts.

wallets generate, store, and use cryptographic secrets to bridge users into onchain accounts. they store seed phrases or private keys and provide interfaces to sign transactions, view balances, update settings, and recover access.

wallet types include:

• digital wallets (offchain): apple wallet, google wallet, no blockchain keys

• software wallets: mobile, desktop, web

• hardware wallets: air-gapped key storage

• multisig wallets: multiple keys per transaction

• smart-contract wallets: recovery, limits, role permissions, tied to eoa

• watch-only wallets: monitor balances without keys

secrets

every account relies on at least one secret: pin, password, oauth token, seed phrase, or private key.

key actions:

• create when setting up

• store in secure location (enclave, vault, manager)

• rotate to limit exposure

• back up and recover to prevent loss

seed phrases

a seed phrase is a 12–24 word bip-39 mnemonic that backs up your single master key and drives every onchain account you create. each word represents 11 bits of entropy from a fixed list of 2,048 words. words are easier to write, read, and speak aloud than raw numbers.

wallets use a seed phrase to derive every child key and address via hierarchical deterministic paths. you generate the phrase, derive keys and addresses, encrypt and store your keys, access your account by importing the phrase or keystore, unlock keys for signing, and use your private key to sign onchain transactions.

a seed phrase is not magic words—it is a human-readable encoding of a binary number (your entropy). instead of a 256-bit string like:

5f2b8c9a3d4e1f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0

you get 12–24 words like:

tiger kitchen dune puzzle until flash onion wagon among bicycle ginger

seed phrase lifecycle

• generate: create the 12–24 word bip-39 mnemonic

• derive: run pbkdf2 + bip-32/44 to produce master and child private keys and addresses

• store: encrypt keys locally; back up the seed phrase manually or in the cloud

• access: import or recover your wallet using the seed phrase or encrypted keystore

• control: unlock keys for signing and other key-management tasks

• sign: use the private key to produce an onchain signature

seed phrase properties

• immutable: phrase never changes once created

• sole secret: one mnemonic backs up every derived key and address

• hierarchical: one seed generates all sub-accounts via defined derivation paths

• multi-chain: same phrase works across every supported blockchain

• no metadata: encodes entropy only, no chain or account labels

• manual transcription: must write or type all 12–24 words exactly

• sequential entry: recovery prompts for each word in order

• phishing risk: typing or pasting the phrase exposes it to malicious sites

abstraction layers

developers wrap extra logic around static-key models—masking but not solving rotation and single-point-failure risks. smart-contract logic and offchain services simplify ux, but they don’t change the blockchain’s core rules. underlying keys stay static, so rotation is impossible and single points of failure remain.

account types

• internet account: use oauth/pki keys for offchain login → can’t initiate onchain transactions

• externally owned account (eoa): one static key → no rotation, same key forever

• multisig: multiple static keys for threshold signing → still no native rotation

• smart-contract account: wrap eoa in a contract, require onchain calls for auth → still depends on one eoa key

• smart-contract wallet: bind eoa to one app; add recovery, limits, permissions → can’t export or import between wallets

• erc-4337 (account abstraction): add user-ops, bundlers, paymasters to abstract gas and execution → underlying keys remain static

• eip-7702 (set code for aa): embed a temporary smart account per transaction → eoa key still controls everything

• eip-7701 (native aa): separate signing and fee payment into protocol modules → not yet in core protocol

addresses

onchain addresses are public identifiers for sending and receiving assets. each address derives from a private key or seed phrase via a defined path. generating a seed phrase creates a hierarchy of addresses across chains. managing addresses requires tracking which seed produced each address, verifying them before use, and backing up the seed phrase to recover all addresses.

networks

each blockchain applies its own derivation paths and transaction rules to addresses. ethereum, bitcoin, solana, and others use distinct formats and paths, but they can share the same seed phrase.

wallets apply network-specific rules (bip-44, custom prefixes) to derive valid addresses. users must select the correct network, know which keys and paths apply, and store network configurations alongside their seed to ensure they sign with the right key on the right chain.

user problems

key management problems

seed phrases are bad because they can’t rotate. they are harder to access and easier to lose control of.

access

• hard to use online: seed phrases are long, unusual text strings—difficult to type, copy, paste, or enter securely. usage is manual and error-prone.

• no familiar login options: users expect to sign in with email, phone, or social accounts—not a random phrase.

• no metadata or context: seed phrases carry no account info, labels, or preferences. apps and wallets can’t display context without external metadata.

• no secret manager: no decentralized account or secrets manager exists for crypto users, who manage secrets for multiple accounts across different tools and storage methods. 1password does have a crypto wallet field.

control

• single point of failure: one phrase controls all accounts. if lost or stolen, user loses access or attacker gains control of everything.

• no rotation: the phrase never changes. you can’t issue new keys without starting over. every use increases exposure.

• lifecycle risk: the phrase is used to create, store, recover, and sign. exposure at any step compromises all tied functions.

• no transaction privacy: all transactions from one key are publicly visible and linkable—no way to split or shield identities.

• no message encryption: private key signs transactions but doesn’t encrypt messages or data. apps can verify authenticity but not protect content.

• must start over: if compromised, users must create a new phrase, migrate funds, and reset every account and integration.

layers

1. go online to go onchain: each step adds friction and risk—network, device, login, app

2. services: repeated authentication across services

3. apps: secrets and settings stored locally, fragmented across platforms

4. wallets: combine app, account, and key roles—hard to separate, confusing to manage

5. accounts: each isolated; create, recover, and manage independently

6. secrets: manual backup and protection required; one leak compromises all

7. seed phrases: hard to use, easy to lose, never change—exposing all accounts

8. abstraction layers: wrappers improve ux but static-key risks remain

9. addresses: users don’t control derivation or reuse. no metadata, no grouping

10. networks: each chain has different formats and paths—reuse is risky, recovery is complex

secret formats

• seed phrase: single point of failure; loss or leak compromises all accounts

• private key: hard to store securely, manual management, easy to leak or paste

• keystore (json): requires strong password and secure storage; format can be misused or corrupted

• passkey: tied to platform ecosystems (icloud, google); limited portability and recovery

• oauth token: often stored in browser memory; hijacking or theft risk

• pin / passcode: easy to guess or reuse; device compromise exposes access

• biometric (face id): convenient but non-revocable; spoofing or hardware failure can block access

user needs

access

users need a consistent way to reach accounts and services across devices—without resetting credentials or repeating logins.

• connect to wi-fi or mobile data → public networks are risky; devices and sessions are easy to hijack. users need a private connection that avoids public wi-fi risks.

• unlock phone or laptop → pins and biometrics can be weak or shared. users need strong local auth that only works for them.

• log into cloud or os account → these logins hold secrets but aren’t designed for that. users need system auth that treats os and cloud sign-in as part of key security.

• open an app and sign in → every app has its own login; nothing carries over. users need at least one identity they can use across wallets and apps.

• launch a session and use wallet → sessions don’t persist; users get logged out. users need persistent sessions that keep state alive without sacrificing security.

• recover an account or app → recovery requires hunting down codes or phrases. users need built-in recovery through trusted devices or contacts.

control

users need a safe way to manage secrets and use accounts across apps—without exposing a single key or starting over.

• write down a seed phrase → one phrase controls everything; if lost or exposed, everything’s gone. users need scoped secrets that are replaceable and limited.

• store secrets on devices or in the cloud → easy to misplace or expose; no standard way to do it. users need reliable, automatic, encrypted backups.

• sign a transaction → every signature uses the full key; nothing rotates or expires. users need rotating keys with temporary or scoped authority.

• share access with someone → no safe way to share; it’s all or nothing. users need delegated access without full exposure.

• import or export an account → seed phrases don’t rotate; sub-accounts can’t move. users need portable accounts that can import, export, and isolate.

• copy and paste addresses → addresses are long, confusing, and error-prone. users need human-readable identifiers that are safe and verifiable.

• switch devices or wallets → nothing transfers cleanly; users must start over. users need continuity so accounts, secrets, and sessions move across devices.

key management principles

• no seed phrase required, ever

• your key is split into secure shares using mpc

• shares are never stored whole and never reconstructed

• you can import, upgrade, or recover at any time

• you can rotate in place and keep the same address

• you can sign online and offline, on device and off device

• you can have custody on devices with no provider holding shares

• you can have custody on network with no devices holding shares

• you have choice—you can move up and down the custody spectrum

no system is perfect and so you’ll likely mix and match. for example, here is one method for getting closer to self custody without a seed phrase.

• start w single key pair eoa bc ofc you have one. upgrade it to mpc. use a protocol that lets you import seedphrase and upgrade to mpc and export to private key.

• use an mpc protocol has threshold signature schemes, and that’s lets you rotate in place, like dkls23

• find a provider that allows users to sign online and offline, add devices and remove providers, like dkls23, with Silent Shard by Silence Labs; and used in production by VultiSig.

• then, run N ceremonies till you get to your mathematically acceptable level of security, online and offline, on device and off device, same address or new address. there you go.

• now, export to private key if you wish, no seedphrase. choose your own methods for handling the exported private key, rinse and repeat before securing the account.

  who actually needs all this? ask Apple, they have a version too. Advanced Data Protection and Recovery Keys “With Advanced Data Protection enabled, Apple doesn't have the encryption keys needed to help you recover your end-to-end encrypted data. If you ever lose access to your account, you’ll need to use one of your account recovery methods.” and “Your account recovery methods are never shared with or known to Apple.”