Technical architecture
Keystore Layer
The authorization layer that travels with your agents, team or wallet.
01
Why a Keystore Layer Exists
The Problem: One Key Controls Everything
If you use Ethereum, your wallet is controlled by a single private key. That key signs every transaction, on every chain, for every asset you own. If it's compromised or lost, everything is gone.
There's no way to scope what a key can do. You can't give one key permission to spend 1 ETH per day and another key unlimited access. You can't add a backup key that only activates if the primary is lost. Every key is all-or-nothing.
If you want:
- •Multiple keys with different permissions
- •A backup key for recovery
- •A way to rotate credentials without moving assets
- •Session keys for agents or automation
You need somewhere to store and manage those keys.
That's the keystore layer.
A single key is a single point of failure — lose it, lose everything
No way to attach multiple signers with different permissions to one wallet
No recovery path if your primary signing device is lost or compromised
If you hold serious value onchain, one key is not enough.
02
Asset-Signer Separation
Vitalik's “Three Transitions” article introduced the idea of asset-signer separation: keep your signers in a different place from your assets. That way, losing access to one chain doesn't mean losing access to your keys.
Assets stay where they are. Your tokens, NFTs, and positions live on whatever chain you're using. They move constantly across protocols and L2s.
Your signers live in one place. A single registry on Ethereum L1 — the keystore — stores your public keys, backup keys, guardians, session keys, and verification logic.
03
What Is a Keystore Layer?
The keystore layer introduces a shared global state, a single registry of signers that every chain can read from.
Instead of your wallet relying on a single key, it references a registry that stores all your signing credentials. Your phone passkey, your hardware wallet key, a session key for your DeFi bot, a backup key for recovery. They all live in one place.
How It Works
Your wallet address stays the same. Your transaction history stays the same. Your token approvals stay the same. What changes is that behind your address, the keystore holds multiple keys — each with its own permissions, its own scope, and its own lifecycle.
The keystore answers one question: is this key allowed to sign for this account?
Insight
Your tokens might move hundreds of times per day across different chains, but your authentication credentials should remain stable and secure in one location.
04
How Keystore State Communicates to L2
High-Level Architecture
The keystore contract lives on Ethereum L1. Each L2 has a mirror contract that reads from it. All keys, verification logic, and account data are stored on L1.
Any design that “reads L1 state on L2” needs two ingredients:
A commitment to the keystore state
A Merkle root, or some root hash on L1.
A proof that a specific key/value is consistent with that commitment
A Merkle proof, SNARK Proof, etc.
Design Space
RIP-7728 (L1SLOAD)
RIP-7728 defines a precompile that lets an L2 contract load L1 storage slots directly. When available, the VERIFY frame on any L2 will be able to read keystore state without any bridge or proof infrastructure.
Canonical Bridge
Send a message over the canonical bridge. The L2 mirror receives keystore state updates and caches them locally for the VERIFY frame to read.
05
Benefits & Outcomes
Outcome 01
Multiple Signers, One Wallet
Want multiple keys with different permissions? Register them in the keystore.
Your phone passkey for daily use. Your hardware wallet for high-value transfers. A session key for your DeFi agent with a 24-hour expiry. All attached to the same wallet address, all with different policies.
- •You don't need to deploy separate smart contracts
- •There's no middleware between your key and the protocol
- •The VERIFY frame reads the keystore directly
Outcome 02
Native Recovery
Lost your phone? Use your backup key.
Without a keystore, losing your signing device means losing your wallet. With the keystore, your second registered key lets you continue signing transactions with the same address.
- •You don't need social recovery contracts
- •There's no guardian infrastructure to maintain
- •It works across every chain where your wallet exists
Outcome 03
Instant Multi-Chain Presence
New L2 launched tomorrow? Your signers are already there.
Your wallet on any new chain references the same keystore entry on L1. It inherits all your keys, all your permissions, all your recovery configuration. No re-onboarding.
- •Your wallet works on the new chain immediately
- •You don't need to set up security again
- •Same keys, same policies, different chain
06
New Design Space Unlocked
With a keystore layer, all your wallets across all chains behave like one wallet.
When signer management is built into wallet infrastructure, a few things change:
- •Your signers work across every chain
- •Your security configuration follows you
- •Recovery works the same everywhere
What This Enables
Programmable Wallets
Configure different permissions for each of your signers. Phone passkey: up to 1 ETH per day, allowlisted contracts only. Hardware wallet: up to 50 ETH per day, any contract. Session key for a DeFi bot: 0.1 ETH max per transaction, 24-hour expiry, restricted to Aave and Uniswap.
A Global Policy Engine
Set spending limits, session keys, or approval workflows once. They apply on every chain where the wallet exists.
Automation & Agents
Register a session key in the keystore. Temporary, scoped, with an expiry. The policy engine recognizes the key type and applies tight constraints. Smart agents can operate across chains with consistent permissions and controls.
Institutional Signers
Three authorized signers for a company treasury: CFO, CTO, ops lead. All keys in the keystore. Policy: transactions over $100k require two signatures, only approved counterparties.
07
The Future We Envision
Frame Transactions Change the Game
EIP-8141 introduces frame transactions, a new transaction type that builds programmable validation directly into Ethereum. Every EOA gets this natively. You keep your address, you keep your history, and you don't need any middleware.
Your existing wallet address will be able to:
- •Verify signatures using any scheme (passkeys, post-quantum, ECDSA)
- •Batch multiple operations into one atomic transaction
- •Enforce policies before execution
- •Have gas sponsored by third parties
Frame transactions fix how wallets validate. The VERIFY frame can read the keystore directly, with no bundler, EntryPoint, or validator module in between. The keystore is the signer backend for every wallet.
What This Means Together
With a keystore layer, all your wallets across all chains behave like one wallet.
That changes what the EVM looks like as a whole:
One source of truth
Your keys live in one place. Every chain reads from it.
Manage once
Rotate a key or update a policy on L1. It applies everywhere.
New chains for free
Deploy your wallet on a new L2 and it inherits your full security config.
Less operational overhead
No per-chain key management. No repeated setup.
Our Thesis
AI Agents, stablecoins and institutions are bringing billions of dollars onchain. The keystore layer is the infrastructure that secures it.
We're building the layer that lets users manage their onchain signers in one place, across every chain, fully non-custodial.
Start issuing authorization records in under a minute.
Connect your agent fleet, set your spending limits, and go. Authorization records are live immediately.