# on keystores

> research notes

**Published by:** [accountless.eth](https://paragraph.com/@accountless-2/)
**Published on:** 2025-11-19
**URL:** https://paragraph.com/@accountless-2/on-keystores

## Content

Identity and AccountsPeople want one account that works everywhere, but today they end up with many. This splits their identity and makes setup painful.Use one account across chains Today: Create EOAs that work everywhere or deploy smart accounts per chain Problem: Accounts split per chain, no single source of truth Need: Single identifier Solution: Keystore rollup or DID system for global account mappingAdopt new chains smoothly Today: Deploy fresh accounts and re-apply old config Problem: Reconfiguration effort repeats (state drift) Need: Seamless migration Solution: Counterfactual deployments with keystore replayAvoid vendor lock-in Today: Use wallet-specific recovery models Problem: Recovery tied to one provider Need: Portability Solution: Sidetree or DID keystore networks for public recoveryKeys and SecurityPeople want to change their keys or add signers once and have it work everywhere. Today they must repeat changes per chain, which is costly and exposes private data.Rotate keys once across chains Today: Rotate keys separately on each chain Problem: Keys and configs get out of sync (state drift) Need: Global config source Solution: Keystore rollup with Merkle root for cross-chain key rotationManage multi-signer or role-based permissions Today: Store multiple signer keys onchain per chain Problem: Expensive duplication per chain (cost + fragmentation) Need: Scalable storage Solution: Offchain config with Merkle proofs for signer setsKeep recovery and guardian data private Today: Post full guardian or recovery set onchain Problem: Sensitive recovery data is public Need: Privacy-preserving recovery Solution: ZK proofs or Merkle proofs for recovery validationDelegation and AutomationPeople want to let apps, bots, or helpers use their wallet without giving away full control. Today sharing keys is unsafe.Use session keys for limited access Today: Ad-hoc contracts or manual delegation Problem: No expiry or scope limits (unsafe delegation) Need: Scoped delegation Solution: Session keys with expiry and session compositionAutomate or delegate safely Today: Share raw keys with bots or agents Problem: Bots or agents get full control (unsafe delegation) Need: Safe delegation Solution: Session keys with scoped intent and expiry for agentsTransactions and InteroperabilityPeople want to send tokens and use apps across chains without mistakes, high fees, or waiting. Today addresses and transactions don’t sync well.Send and receive assets safely Today: Share addresses without chain info; rely on bridges Problem: Addresses lack chain context, causing mis-sends Need: Clear identifiers Solution: ENS or chain-prefixed addresses for multichain resolutionUse wallets and paymasters safely with ERC-4337 Today: Rely on rigid simulation rules and bundler whitelists Problem: Hardcoded rules and whitelists (centralization) Need: Flexible simulation rules Solution: JSON schema for opcode and storage slot whitelistingSync accounts across rollups cheaply Today: Rely on L1 proofs and settlement Problem: L1 roundtrips are slow and expensive (cost + latency) Need: Cheap, fast sync Solution: Embedded rollups for shared read-only stateProblemsFragmentation — same action split across chains or accountsState drift — config diverges across chains, updates not consistentPrivacy exposure — sensitive recovery/guardian data visible onchainUnsafe delegation — master key permissionsCentralization — reliance on whitelists or intermediariesCost + Latency — repeated updates, L1 reliance, high gas or time overheadVendor lock-in — proprietary recovery or custody systems trap usersSolutions: KeystoresAll of these try to give users one place to manage accounts, keys, and recovery across chains. They differ in where the keystore “lives.” L1 keystore Keys and configs are stored directly on Ethereum mainnet. Good: Most secure, anyone can fall back to L1. Bad: Expensive updates (can cost tens or hundreds of dollars). L2 keystore Keys live on a rollup like Optimism, Arbitrum, or Scroll. Good: Cheaper to update. Bad: Tied to one rollup’s security and uptime; other rollups must read its state. Dedicated keystore rollup (Minimal Keystore Rollup, MKSR) A rollup that only stores key data, nothing else. Good: Cheap, auditable, optimized for this one task. Bad: Needs enough users and updates to be efficient; new trust and infra. Hybrid (L1 anchor + L2 updates) Data is anchored on Ethereum, but you update from an L2 of your choice. Good: Security of L1 plus low-cost updates. Bad: Ties liveness to the chosen L2, adds complexity. Embedded rollup A small rollup embedded inside other rollups. Everyone shares the same keystore state locally. Good: Fast reads, no expensive L1 roundtrips. Bad: Settlement and sync rules get more complex. DID / Sidetree-based keystore Uses global identity standards (DIDs, VCs). Anchors updates onchain, stores docs offchain (IPFS, Filecoin). Good: Interoperable, avoids vendor lock-in. Bad: New standards, not wallet-native yet.SOURCES

## Publication Information

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