People 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 mapping

• Adopt 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 replay

• Avoid 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 recovery

People 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 rotation

• Manage 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 sets

• Keep 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 validation

People 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 composition

• Automate 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 agents

People 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 resolution

• Use 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 whitelisting

• Sync 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 state

• Fragmentation — same action split across chains or accounts

• State drift — config diverges across chains, updates not consistent

• Privacy exposure — sensitive recovery/guardian data visible onchain

• Unsafe delegation — master key permissions

• Centralization — reliance on whitelists or intermediaries

• Cost + Latency — repeated updates, L1 reliance, high gas or time overhead

• Vendor lock-in — proprietary recovery or custody systems trap users

All 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