# What is self custody

> secrets management

**Published by:** [accountless.eth](https://paragraph.com/@accountless/)
**Published on:** 2025-09-14
**URL:** https://paragraph.com/@accountless/what-is-self-custody

## Content

Table of Contents TLDRcustody is never absolutewhere we are todaywhat to do thenDETAILSonchain user experienceaccess and controlusers have to go online to go onchainServices, Apps, Accounts, Walletsservicesappsaccounts (internet + onchain)wallets (types and roles)Secretssecretskey actionsseed phraseslifecyclepropertiesAbstraction Layersaccount types (internet, eoa, multisig, smart contracts, aa)addressesnetworksUser Problemskey management problemsaccess issuescontrol issueslayers of frictionsecret formatsUser Needsaccess needscontrol needsKey Management PrinciplesMix and match example method for stronger custodyWho actually needs this?comparison to Apple’s advanced data protectionTLDR 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.wallets use a seed phrase to derive every child key and address. the seed phrase cannot change and if leaked all sub accounts are lost. it’s also 12-24 words that must be input in the correct order. 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, and actually worse than an eoa.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 keyssoftware wallets: mobile, desktop, webhardware wallets: air-gapped key storagemultisig wallets: multiple keys per transactionsmart-contract wallets: recovery, limits, role permissions, tied to eoawatch-only wallets: monitor balances without keyssecrets every account relies on at least one secret: pin, password, oauth token, seed phrase, or private key. key actions:create when setting upstore in secure location (enclave, vault, manager)rotate to limit exposureback up and recover to prevent lossseed 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 battery emerge puzzle until flash track whale among happy tailseed phrase lifecyclegenerate: create the 12–24 word bip-39 mnemonicderive: run pbkdf2 + bip-32/44 to produce master and child private keys and addressesstore: encrypt keys locally; back up the seed phrase manually or in the cloudaccess: import or recover your wallet using the seed phrase or encrypted keystorecontrol: unlock keys for signing and other key-management taskssign: use the private key to produce an onchain signatureseed phrase propertiesimmutable: phrase never changes once createdsole secret: one mnemonic backs up every derived key and addresshierarchical: one seed generates all sub-accounts via defined derivation pathsmulti-chain: same phrase works across every supported blockchainno metadata: encodes entropy only, no chain or account labelsmanual transcription: must write or type all 12–24 words exactlysequential entry: recovery prompts for each word in orderphishing risk: typing or pasting the phrase exposes it to malicious sitesabstraction 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 typesinternet account: use oauth/pki keys for offchain login → can’t initiate onchain transactionsexternally owned account (eoa): one static key → no rotation, same key forevermultisig: multiple static keys for threshold signing → still no native rotationsmart-contract account: wrap eoa in a contract, require onchain calls for auth → still depends on one eoa keysmart-contract wallet: bind eoa to one app; add recovery, limits, permissions → can’t export or import between walletserc-4337 (account abstraction): add user-ops, bundlers, paymasters to abstract gas and execution → underlying keys remain staticeip-7702 (set code for aa): embed a temporary smart account per transaction → eoa key still controls everythingeip-7701 (native aa): separate signing and fee payment into protocol modules → not yet in core protocoladdresses 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 secure all sub accounts. they are worse because that seedphrase can’t rotate. they are harder to use for access and easier to lose control of sub accounts. accesshard 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. controlsingle 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.layersgo online to go onchain: each step adds friction and risk—network, device, login, appservices: repeated authentication across servicesapps: secrets and settings stored locally, fragmented across platformswallets: combine app, account, and key roles—hard to separate, confusing to manageaccounts: each isolated; create, recover, and manage independentlysecrets: manual backup and protection required; one leak compromises allseed phrases: hard to use, easy to lose, never change—exposing all accountsabstraction layers: wrappers improve ux but static-key risks remainaddresses: users don’t control derivation or reuse. no metadata, no groupingnetworks: each chain has different formats and paths—reuse is risky, recovery is complexsecret formatsseed phrase: single point of failure; loss or leak compromises all accountsprivate key: hard to store securely, manual management, easy to leak or pastekeystore (json): requires strong password and secure storage; format can be misused or corruptedpasskey: tied to platform ecosystems (icloud, google); limited portability and recoveryoauth token: often stored in browser memory; hijacking or theft riskpin / passcode: easy to guess or reuse; device compromise exposes accessbiometric (face id): convenient but non-revocable; spoofing or hardware failure can block access. sunlight can increases error rate and time to use 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 principlesno seed phrase required, everyour key is split into secure shares using mpcshares are never stored whole and never reconstructedyou can import, upgrade, or recover at any timeyou can rotate in place and keep the same addressyou can sign online and offline, on device and off deviceyou can have custody on devices with no provider holding sharesyou can have custody on network with no devices holding shares you have choice—you can move up and down the custody spectrumno 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 dkls23find 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.”

## Publication Information

- [accountless.eth](https://paragraph.com/@accountless/): Publication homepage
- [All Posts](https://paragraph.com/@accountless/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@accountless): Subscribe to updates
- [Twitter](https://twitter.com/alexanderchopan): Follow on Twitter