
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


accountless.eth
No comments yet