A keystore wallet is an encrypted file or onchain registry that stores the private key controlling a blockchain account. The term covers two distinct concepts: the classic UTC/JSON keystore file format, which encrypts a raw private key behind a user password, and the modern cross-chain keystore design introduced in ERC-7560, which uses a shared L1 key registry so smart accounts on multiple L2s can rotate a single signing key without repeating the operation on every chain. As of Q1 2026, roughly 4 million ERC-4337 accounts have been deployed across Ethereum and its L2s (Dune Analytics), making key management across chains one of the most pressing problems in account abstraction.
​

A keystore wallet stores the credentials controlling a blockchain address in an encrypted container. Two distinct forms exist: the classic UTC/JSON file that encrypts a raw private key behind a user password, and the modern L1 registry contract whose state root is read by smart accounts on L2s before authorizing any transaction.
​

The original keystore format was standardized by the Ethereum Foundation alongside the Geth client in 2015. Tools like MyEtherWallet and MyCrypto built their import flows around it, and the format persists today as the standard export format for wallets including MetaMask. Each file contains ciphertext (the encrypted private key), a cipher algorithm (typically AES-128-CTR), a key-derivation function (PBKDF2 with SHA-256 or scrypt), and a MAC for integrity checking. The password never leaves the user's device; decryption happens locally.
​

The cross-chain keystore concept emerged from ERC-7560 (Native Account Abstraction) and the related ERC-7579 (Minimal Modular Smart Accounts) work. Where a UTC file protects a key at rest on a single device, a cross-chain keystore protects a key across an entire account estate spanning ten or more chains by anchoring the canonical signing state to one contract on Ethereum mainnet. L2 smart accounts query that L1 state via storage proofs before executing any transaction.
​

A classic UTC keystore file encrypts a private key using a password-derived symmetric key. The password is stretched through PBKDF2 (262,144 iterations) or scrypt to produce a 256-bit AES key that encrypts the raw 32-byte private key. The resulting JSON file stores entirely offline; decryption requires the same password and happens entirely client-side.
​

The file format is defined in the Ethereum Web3 Secret Storage Definition and has remained stable since Geth 1.0. A minimal keystore file contains six required fields:

When MetaMask exports a keystore file, it uses scrypt with n=8,192 (lighter than the security recommendations to reduce export latency). Geth's own keystore module defaults to n=262,144, which requires roughly 2-3 seconds to decrypt on a modern laptop. The iteration count is stored in the file itself, so any compliant client can decrypt regardless of which tool created the file.
​

The primary risk with UTC keystore files is password loss. The private key inside is encrypted with a symmetric cipher; without the correct password, the ciphertext is computationally indistinguishable from random bytes. There is no recovery path. A secondary risk is file theft: if an attacker copies the JSON file, they can attempt offline brute-force against the password. A weak password (fewer than 12 random characters) can be cracked in hours on commodity GPU hardware. The EIP-55 checksum address standard reduces typographical errors when copying the address field, but does nothing to protect the key itself.
​

Hardware wallet manufacturers like Ledger and Trezor use a different physical model but support keystore file import for migration: the user decrypts the JSON on a trusted device, enters the resulting seed, and the hardware wallet re-encrypts it in secure element storage. This is how many users who started with MyEtherWallet in 2016-2018 migrated to hardware devices.
​

Cross-chain keystore wallets solve the N-chain problem by anchoring the canonical signing key in a single L1 registry contract, then letting L2 smart accounts read that L1 state via storage proofs before authorizing any transaction. Rotating a key means updating one contract on Ethereum; every L2 account automatically inherits the change without a separate transaction on each chain.
​

The N-chain problem is straightforward to state and expensive to ignore. An account abstraction user with smart accounts on Ethereum, Optimism, Base, Arbitrum, and seven other chains owns N key-signing relationships. If that user wants to rotate their signing key (for example, after a suspected compromise), they must submit a key-rotation transaction on each chain. At Q1 2026 gas prices, that cost ranges from negligible on L2s to significant on Ethereum mainnet. More critically, any chain on which the rotation has not yet finalized remains vulnerable to the old key. The window between first rotation and last rotation is an attack surface.
​

The cross-chain keystore architecture, described in the ERC-7560 specification and implemented by teams including Rhinestone and ZeroDev, works as follows:

This design requires that L2 nodes (or their clients) can access recent L1 state roots. Most Ethereum L2s already derive their security from L1 state; the storage proof approach piggybacks on that existing trust channel rather than introducing new trust assumptions. The ERC-7560 Ethereum Magicians thread from 2023 contains the original motivation and mechanism description. The Ethereum Foundation's account abstraction working group has tracked this work through several iterations since the initial EIP-4337 deployment in March 2023.
​

An important implementation detail: the keystore does not store the private key onchain. What it stores is a public key commitment or a hash of the authorized signer set. The L1 registry tells each L2 "this is who is allowed to sign for this account right now" without revealing the private key material. The actual signing happens off-chain; only the verification of who is authorized to sign happens onchain.
​

Traditional EOA wallets tie a single permanent private key to a fixed address with no recovery mechanism. Keystore wallets add an encryption or governance layer on top of the raw key. The core difference is programmability: EOA keys cannot be rotated; keystore-backed smart accounts can swap signers, add guardians, and enforce time locks without changing the account address.
​

An externally owned account (EOA) on Ethereum is controlled by a single private key. Lose that key, and the account is permanently inaccessible. Leak that key, and the account is permanently compromised. There is no governance, no recovery, and no upgrade path. The UTC keystore file improves on this in exactly one way: the private key is encrypted at rest, reducing the risk of theft from disk access. The key relationship itself remains static.
​

Smart accounts (ERC-4337 or ERC-7560) replace the fixed key relationship with a programmable validation module. The account address is derived from an initial deployment, but the set of signers authorized to control the account can change over time. Social recovery is one application of this programmability: the user designates guardians who can collectively authorize a key rotation if the original signing key is lost. Cross-chain keystores extend this to the multi-chain context: the programmable signer set lives on L1 and gets read by every L2 account in the estate.
​

The table below maps four wallet types across four dimensions to make the comparison concrete.
​

The comparison highlights a progression: each row adds one layer of programmability over the previous. EOAs are the baseline (zero programmability). UTC files add encryption at rest but leave the key static. Single-chain smart accounts add programmable rotation but require per-chain execution. Cross-chain keystores complete the pattern by making rotation atomic across the entire account estate.
​

Three production implementations demonstrate the cross-chain keystore architecture at different layers of the stack. Rhinestone provides the smart account module infrastructure, ZeroDev's Kernel ships a modular execution environment that supports keystore-style validation, and Coinbase Smart Wallet has introduced key-sync features targeting its consumer base. Each takes a different approach to the L1-to-L2 proof pipeline.
​

Rhinestone is a smart account module registry and development platform. Its keystore module implements the cross-chain signer sync pattern as an ERC-7579 validator module: developers install it on any compliant smart account and point the module at an L1 keystore contract address. When the user submits a transaction on an L2, the Rhinestone module fetches a storage proof from its proving service, verifies the proof against the L1 state root embedded in the L2 block, and proceeds with validation if the proof matches the expected signer. The module is audited and installable without redeploying the base account. Rhinestone's module registry (live on Ethereum, Optimism, Base, and Arbitrum as of Q1 2026) indexes over 40 validator and executor modules, with the keystore module listed under the account recovery category.
​

ZeroDev's Kernel account is one of the most widely deployed ERC-4337 smart account implementations, with over 600,000 accounts deployed as of early 2026 per ZeroDev's public deployment tracker. Kernel supports a modular validator architecture compatible with ERC-7579, meaning any ERC-7579-compliant keystore module (including Rhinestone's) can be installed without a Kernel-specific fork. ZeroDev has also prototyped its own "session keys" feature, which is a lighter-weight version of the same pattern: the canonical signer set lives in one place and scoped session keys are derived from it, reducing the number of full key rotations needed in practice.
​

Coinbase Smart Wallet launched in May 2024 as a Coinbase product targeting retail users who want passkey-based authentication without a seed phrase. The wallet uses ERC-4337 under the hood, with passkeys (WebAuthn credentials) as the initial signing authority. In 2025, Coinbase shipped a cross-chain key-sync feature that uses a simplified version of the keystore pattern: a canonical key record lives on Base (Coinbase's L2), and L2 deployments on Optimism and Arbitrum reference that record via cross-chain message verification rather than full storage proofs. This trades some proof generality for faster latency, accepting a brief delay window during key propagation rather than waiting for a full Merkle proof. The Coinbase Smart Wallet GitHub repository contains the implementation details and audit reports.
​

Classic UTC keystore files are only as secure as the password protecting them; cross-chain keystore registries shift the attack surface to the L1 contract and the storage proof pipeline. Both models have distinct failure modes that developers need to account for before using them for high-value accounts.
​

For classic UTC keystore files, the primary attack vectors are:

For cross-chain keystore registries, the relevant risks are:

The private key itself, whether stored in a UTC file or referenced by a cross-chain keystore contract, is the irreducible secret that controls assets. No keystore design eliminates key security; both models assume the private key is held securely by the user and focus on protecting it at rest (UTC) or reducing the blast radius if rotation is needed (cross-chain).
​

Eco Portal is built on smart account architecture, meaning user accounts are programmable contracts rather than EOAs. This design is compatible with ERC-7579 validator modules, including cross-chain keystore modules, because Eco's account layer follows the same ERC-4337 primitives that Rhinestone and ZeroDev build on.
​

For teams building treasury or payment workflows on top of Eco using the non-custodial Routes CLI or Routes API, cross-chain keystore support means a single key rotation policy can cover accounts operating across all 15 chains Eco supports (Ethereum, Optimism, Base, Arbitrum, HyperEVM, Plasma, Polygon, Ronin, Unichain, Ink, Celo, Solana, Sonic, BSC, and Worldchain). The stablecoin execution network operates at the routing layer, while keystore infrastructure operates at the account layer; the two compose without conflict.
​

Sources and methodology. ERC-4337 deployment count from Dune Analytics ERC-4337 dashboard, Q1 2026. Stablecoin market total from DeFiLlama, April 29, 2026. Protocol deployment counts from ZeroDev public announcements and Rhinestone module registry. Keystore specification references from Ethereum Magicians ERC-7560 thread and EIP-4337 specification. Figures reflect Q1 2026 state; EIP specifications are living documents subject to revision.
​