A keystore is an encrypted file that wraps your private key behind a password-derived cipher. Instead of storing a raw 256-bit private key that anyone who sees the file can use immediately, the keystore runs your password through a key-derivation function, uses the resulting key to encrypt the private key, and writes the whole bundle to disk as a portable JSON document. Losing the password means losing access even with the file.
​

Think of it as a locked safe whose combination is your password. The safe itself can be copied freely — to cloud storage, a USB drive, a second laptop — but without the combination the contents are inaccessible. That portability-plus-encryption tradeoff is what makes keystores the dominant format for developer wallets and server-side signing in Ethereum and EVM-compatible networks.
​

Keystores are standardized under the Ethereum Secret Storage Definition, which specifies exactly how the encryption, key derivation, and MAC verification must work so that any compliant wallet library can open any compliant keystore file.
​

A keystore file is a JSON document with four top-level fields: version, id, address, and crypto. The crypto object is where the cryptographic work lives. It records the key-derivation function parameters, the cipher algorithm and initialization vector, the encrypted private key ciphertext, and a MAC that lets the wallet verify the password before attempting decryption.
​

The standard supports two key-derivation functions: scrypt and PBKDF2.
​

scrypt is the default for most modern wallets including Geth. It is deliberately memory-hard: the n parameter (work factor), r (block size), and p (parallelization factor) are tuned so that brute-forcing passwords requires large amounts of RAM in addition to CPU cycles. Geth's defaults — n=262144, r=8, p=1 — mean a single password guess requires roughly 256 MB of memory, making GPU-based cracking attacks far more expensive than they are against PBKDF2.
​

PBKDF2-SHA-256 is the fallback option. It is widely supported across languages and platforms and is FIPS-140 compliant, which matters in regulated environments. Its weakness is that it is compute-only, not memory-hard, so large GPU farms can test millions of passwords per second if the iteration count is set too low. Modern best practice is at least 600,000 iterations when using PBKDF2.
​

Once the key-derivation function produces a 32-byte derived key, the keystore uses the first 16 bytes as the AES-128-CTR encryption key. AES-128-CTR is a stream cipher mode: a counter block is encrypted with AES to produce a keystream, then XOR'd with the plaintext private key bytes. The result is the ciphertext stored in the ciphertext field. The last 16 bytes of the derived key are combined with the ciphertext and hashed with Keccak-256 to produce the MAC. On unlock, the wallet recomputes this MAC and rejects the password immediately if there is a mismatch, which prevents silent decryption failures and avoids exposing any private key bytes.
​

A minimal keystore object looks like this:
​

The Ethereum Foundation's Web3 Secret Storage Definition specifies every field in full, including test vectors that wallet libraries can use to verify their implementations.
​

Keystores, recovery phrases, and hardware wallets all protect private keys, but they make fundamentally different tradeoffs around encryption strength, physical form factor, and recovery paths. Knowing which tradeoff fits your situation is more useful than treating any one option as universally superior. The table below compares the three across six dimensions that matter in practice.
​

For a deeper look at how recovery phrases work at the protocol level, see What Is a Recovery Phrase? Seed Phrases Explained. The Ethereum Foundation's wallet comparison page covers additional wallet types including multisig and smart contract wallets.
​

A keystore wallet extends the basic keystore concept from raw key storage into a full account model. Instead of only encrypting a private key on disk, a keystore wallet uses that encrypted key as the signer for a smart contract account, separating the cryptographic key from the onchain address. The key can be rotated, recovered, or replaced without changing the account address that holds funds and history.
​

Eco's keystore wallets implement this model on top of ERC-4337 account abstraction. The smart contract account is deployed onchain and owns assets. The keystore stores the private key that authorizes transactions from that account. Because the account is a contract, its authorization logic can be upgraded: a user can add guardians, set spending limits, or swap signing keys without migrating funds to a new address.
​

This architecture matters because it resolves a core tension in traditional EOA (externally owned account) wallets: the address and the key are the same thing. Lose or rotate the key on an EOA and you lose the address. With a keystore wallet backed by a smart contract account, the address persists onchain independently of the key material. You can update the keystore, rotate credentials, and recover through social recovery mechanisms without any onchain asset movement.
​

For more on how the underlying account abstraction standard works, see What Is ERC-4337? Account Abstraction Explained. The ERC-4337 specification itself is published at EIPs.ethereum.org.
​

Account portability means a user can access the same onchain account from multiple devices, browsers, or apps without copying a seed phrase across each one. Keystore wallets achieve this by splitting what needs to travel from what stays put: the encrypted keystore file travels, the onchain account does not.
​

In practice the flow works like this. A user creates a keystore wallet on their phone. The smart contract account is deployed onchain and that address is theirs. The keystore file is uploaded encrypted to cloud storage — iCloud Keychain, Google Drive, or an app-managed vault. When the user logs in on a second device, the app downloads the encrypted keystore and prompts for the password. After successful decryption, the private key is available in memory to authorize transactions. At no point does a seed phrase appear on screen or travel across any network connection.
​

This is a meaningful security improvement over seed phrase portability. Seed phrases are plaintext the moment they leave the hardware they were generated on. A keystore file in transit is ciphertext: even if the cloud storage provider is compromised, an attacker only has an encrypted blob. They still need the password, and with scrypt's memory-hard derivation, offline cracking is expensive enough that a strong password provides genuine security.
​

Keystore wallets also compose well with social recovery. If a user forgets the password to their keystore, the onchain smart contract account can allow nominated guardians to authorize a key rotation, replacing the old encrypted keystore with a new one tied to a new password. Funds never move; only the authorization key changes. For a full explanation of that mechanism, see What Is Social Recovery for Crypto Wallets.
​

The portability model also removes the hardware wallet requirement for multi-device access. Ethereum core developer Justin Drake's writings on account abstraction and Vitalik Buterin's proposals on smart contract wallets both point toward encrypted key portability combined with onchain recovery as the path toward mainstream usability without sacrificing self-custody.
​

Keystore security reduces to two factors: the strength of the password and the safety of the file backup. The encryption is only as strong as the password behind it, and any backup that is not itself encrypted is effectively a plaintext private key waiting to be stolen.
​

Password strength. Use a passphrase of at least four random words (Diceware or similar), or a random string of at least 16 characters mixing uppercase, lowercase, digits, and symbols. Avoid dictionary words, names, dates, and anything connected to public information about you. The scrypt work factor is tuned for interactive use (one unlock per session), so a weak password that could be guessed in 10,000 tries is still vulnerable even with scrypt, given enough time and hardware.
​

Never store password and file together. If your cloud backup contains the keystore and a password hint in the same folder, you have effectively removed the encryption. Store the password in a reputable password manager (Bitwarden, 1Password, or similar) and the keystore in a separate location. An attacker who compromises one should not automatically get the other.
​

Encrypted backups only. If you back up the keystore to a USB drive or external disk, encrypt the drive or at minimum put the keystore inside an encrypted archive. macOS FileVault and Windows BitLocker protect the local disk but not removable media by default.
​

Phishing is the primary attack vector. Most keystore thefts are not brute-force attacks; they are password-capture attacks. A fake wallet website prompts you to import your keystore and enter your password, then exfiltrates both. Always verify the URL before entering a keystore password. Bookmark official wallet URLs rather than relying on search results or links in messages.
​

Rotate after exposure. If you ever enter your keystore password into a site you are not certain is legitimate, treat the keystore as compromised. Generate a new key, transfer assets, and retire the old keystore. On a smart contract account using Eco keystore wallets, rotation is an onchain transaction that does not require moving funds, making recovery substantially less disruptive than on a traditional EOA.
​

The Open Web Application Security Project's Key Management Cheat Sheet provides a detailed reference for cryptographic key handling that goes beyond wallets into broader system design.
​

For background on what self-custody means in practice and how to evaluate which custody model is right for a given use case, see What Is a Non-Custodial Wallet? Self-Custody Explained.
​

Keystores solve a specific problem: you need encrypted, portable private key storage that works without a physical device and without exposing a seed phrase. That problem comes up in a handful of contexts where other wallet formats are either overkill or impractical.
​

Developer and test wallets. When building onchain applications, developers routinely need a signing key available in CI/CD pipelines, local test environments, and staging nodes. A keystore file checked into a secrets manager satisfies this need: it is encrypted at rest, can be decrypted programmatically using the wallet library of choice (ethers.js, web3.py, viem), and does not require a hardware device to be connected to a build server. Most Ethereum tooling natively supports the Ethereum Secret Storage v3 format.
​

Server-side signing. Backend services that relay transactions on behalf of users — relayers in ERC-4337 infrastructure, bridge operators, oracle nodes — need a hot wallet that is always available but never exposed as plaintext. A keystore loaded into memory at service startup and never written to disk in decrypted form is a reasonable operational model for moderate-risk signing operations. High-value signing infrastructure should layer in hardware security modules (HSMs) on top, but keystores are a sensible first tier.
​

Multi-device consumer wallets. For end users who want to access the same account from a phone and a laptop without hardware wallet friction, a keystore backed by encrypted cloud sync is the practical option. This is the model Eco's keystore wallets implement: the account lives onchain, the key material travels encrypted, and the user authenticates with a password rather than transcribing 24 words.
​

Situations where keystores are the wrong tool. Long-term cold storage of high-value assets is better served by a hardware wallet with an air-gapped seed phrase backup. Keystores are hot by nature: they require an internet-connected device to function and the password must be entered in software, which is a larger attack surface than a hardware secure element. If the primary requirement is maximum security with minimal access frequency, hardware wallets win. If the requirement is daily use across multiple devices with good security, keystore wallets are the right fit.
​

ConsenSys's Ethereum Developer Tools list catalogues the major libraries and frameworks that support keystore import, useful if you are evaluating tooling for a specific language or runtime.
​

No. The private key is encrypted with AES-128-CTR using a key derived from your password via scrypt or PBKDF2. Without the correct password, decryption produces garbage and the MAC check will fail, immediately rejecting the attempt. The only practical attack is guessing the password, which scrypt's memory-hard design makes expensive at scale.
​

If you lose the file and have no backup, the private key is gone regardless of whether you remember the password. The password alone cannot reconstruct the key. For smart contract accounts like Eco keystore wallets, social recovery can rotate the signing key and restore access to the onchain account even without the original keystore file, as long as you have enrolled guardians.
​

A keystore is the encrypted storage format for a private key; a wallet is the broader application or account model built on top of that key. A keystore file by itself cannot do anything until software loads and decrypts it. A keystore wallet specifically refers to a smart contract account that uses keystore-encrypted signing keys, as described in the section above.
​

A raw private key export is an unencrypted hex string — anyone who sees it owns the funds instantly. A keystore wraps that same key in AES encryption tied to your password, so the file can be stored, transmitted, and backed up without immediately exposing the key. Never export an unencrypted private key unless you are transferring it directly into another secure system.
​

Yes, as long as both apps support the Ethereum Secret Storage Definition v3 format. Geth, MetaMask, ethers.js, web3.py, viem, and most other EVM tooling support this standard. Be aware that importing a keystore into a new app exposes the decrypted key in that app's memory at the moment of import, so only use apps you trust and verify their URLs before entering your password.
​