Open Standard v0.1

LWS

Local Wallet Standard

An open, neutral standard for secure local wallet storage and agent access. One vault, one interface, every chain. Agents sign transactions without ever touching private keys. LWS exists to give every AI agent a wallet it can trust—and every user a wallet they control.

Read the Spec Quick Start

Sign a transaction with one call

const result = await lws.signAndSend({
  walletId: "agent-treasury",
  chainId:  "eip155:8453",        // Base
  transaction: {
    to:    "0x4B08...4D2dB",
    value: "10000000000000000",  // 0.01 ETH
  }
});
// Policy engine evaluates -> Simulation runs -> Key signs in enclave
// => { transactionHash: "0xabc...", status: "confirmed" }

The Problem

Every tool reinvents the wallet

Every CLI, agent, and script that touches a blockchain implements its own wallet management from scratch. Foundry stores keys one way. Hardhat expects environment variables. Your trading bot has its own keystore. Your AI agent can't access wallets created by your deployment tool. The result: N tools × M chains = N×M integration problems, and keys scattered across dotfiles, env vars, and proprietary formats with no shared security model.

Today — fragmented

 dawn-cli ──── own keystore ──── EVM
 foundry  ──── cast wallet  ──── EVM
 hardhat  ──── .env vars    ──── EVM
 solana-cli ── own keystore ──── Solana
 agent-x  ──── cloud API    ──── EVM + Solana
 your-bot ──── custom JSON  ──── ???

 6 tools. 6 key formats. 6 security models.
 None of them talk to each other.

With LWS — one interface

 dawn-cli ─────┐
 foundry  ─────┤
 hardhat  ─────┤
 solana-cli ───┼──── LWS ──── All chains
 agent-x  ─────┤
 your-bot ─────┘

 Any tool. One vault. One security model.
 A wallet created by one tool works in every other.

No portability. Create a wallet in one CLI, re-import it into every other tool manually. Export, copy, paste private keys between tools. Every migration is a security risk.

No shared security. Each tool invents its own key storage, its own encryption, its own access control. Some get it right. Many don't. Private keys end up in plaintext env vars and shell history.

No single point of access. There's no standard way for a CLI, agent, or application to say "give me a wallet and let me sign." Every integration is bespoke. Every new tool starts from zero.

Design Principles

Built for the agent era

Five principles that make LWS different from every wallet SDK, cloud API, and ad-hoc keystore that came before it.

Keys never leave the vault

Private keys are encrypted at rest and decrypted only inside an isolated signing process. They are never exposed to agent prompts, LLM contexts, or parent processes.

Chain-agnostic by default

CAIP-2 chain identifiers and CAIP-10 account identifiers. EVM, Solana, Tron, Cosmos, Bitcoin—all first-class citizens. No chain is special.

Policy before signing

Every agent transaction passes through a policy engine before key material is touched. Policies are attached to API keys, scoping what each agent can do. The owner bypasses policies entirely—sudo access to all wallets.

One interface, any consumer

CLI tools, MCP servers, REST APIs, and library imports all use the same abstract interface. A wallet created by one tool is usable by any other.

Open and forkable

Permissionlessly extensible. New chains, policy types, and storage backends are added via plugins, not core spec changes. CC0 licensed. No vendor lock-in.

Architecture

How it works

Agents talk to the Access Layer. The Access Layer enforces policies, delegates signing to an isolated enclave, and never exposes key material upstream.

 Agent / CLI / App                        Signing Flow
 (Claude, dawn-cli, custom)
        │                            1. Agent calls lws.sign()
        │ LWS Interface             2. Policy engine evaluates
        ▼                            3. Enclave decrypts key
 ┌─────────────────────┐             4. Transaction signed
 │    Access Layer      │             5. Key wiped from memory
 │  MCP │ REST │ SDK    │             6. Signature returned
 │      │      │        │             7. Submit via RPC (optional)
 │  ┌───┴──────┴──────┐ │
 │  │  Policy Engine   │ │            The agent NEVER sees
 │  │  (pre-signing)   │ │            the private key.
 │  └────────┬────────┘ │
 │  ┌────────▼────────┐ │            Chain plugins handle
 │  │ Signing Enclave  │ │            serialization, signing,
 │  │ (isolated proc)  │ │            broadcasting, and
 │  └────────┬────────┘ │            simulation per-chain.
 │  ┌────────▼────────┐ │
 │  │  Wallet Vault    │ │
 │  │ ~/.lws/wallets/  │ │
 │  └─────────────────┘ │
 └─────────────────────┘

Step 1

Request

Agent calls lws_sign via MCP, REST, or SDK with a chain ID and transaction object.

→

Step 2

Policy Check

Spending limits, allowlists, chain restrictions, and simulation requirements are evaluated before any key is touched.

→

Step 3

Sign

Key is decrypted in the isolated enclave, transaction signed, key wiped from memory. Signed transaction returned to caller.

→

Step 4

Submit (optional)

If RPC URLs are configured, the signed transaction is broadcast on-chain and the transaction hash is returned.

Why LWS

Zero compromise wallet access

🔒

Zero key exposure

Private keys are decrypted only inside an isolated subprocess. Agents, LLMs, and parent processes never see raw key material. Following the Privy/Turnkey enclave model—locally.

⛓

Zero chain lock-in

CAIP-2 chain identifiers work for every chain. EVM, Solana, Cosmos, Bitcoin, Tron—and any future chain via the plugin system. Same interface, same vault, same policies.

🛡

Zero trust required

No cloud accounts, no API keys, no network dependency. Everything runs on your machine. Wallets are encrypted with scrypt + AES-256-GCM and stored at ~/.lws/.

⚙

Zero integration friction

MCP server for AI agents (Claude, GPT, LangChain). REST API on localhost for scripts. Library SDK for embedding. All three share one implementation.

📜

Zero unaudited actions

Every signing operation is logged to an append-only audit trail. Policy evaluations, simulation results, transaction hashes—all recorded in ~/.lws/logs/audit.jsonl.

🔌

Zero vendor lock-in

Built on open standards: Keystore v3, BIP-39/44, CAIP-2/10, MCP. Import from MetaMask, export to any wallet. CC0 licensed—use it, fork it, extend it.

Get Started

From zero to signing in 60 seconds

Install the CLI, create a wallet, create an API key with policies, and start signing. Works with any agent that supports MCP.

Terminal

# Install
npm install -g @lws/cli

# Create a wallet
lws wallet create --name "agent-treasury" --chain evm
# => Created wallet 3198bc9c-... with account eip155:8453:0xab16...

# Create a policy and an API key scoped to the wallet
lws policy create --file safe-agent-policy.json
lws key create --name "claude-agent" --wallet agent-treasury --policy safe-agent
# => lws_key_a1b2c3d4e5f6...  (shown once, store securely)

# Start the MCP server (agents connect here)
lws serve --mcp

# Or start the REST API
lws serve --rest --port 8402

# Sign a transaction directly
lws tx sign --wallet agent-treasury \
  --chain eip155:8453 \
  --to 0x4B0897b0513fdC7C541B6d9D7E929C4e5364D2dB \
  --value 0.01

claude_code_config.json — Connect Claude to LWS

{
  "mcpServers": {
    "lws": {
      "command": "lws",
      "args": ["serve", "--mcp"]
    }
  }
}

Landscape

How LWS compares

Existing solutions are cloud-first. LWS is local-first with an upgrade path to TEEs.

Feature	LWS	Privy	Turnkey	Coinbase CDP	Lit Protocol
Local-first	Yes	No (cloud)	No (cloud)	No (cloud)	No (network)
Key isolation	OS process	TEE + SSS	AWS Nitro	TEE	DKG threshold
Multi-chain	Plugin system	Tiered support	Curve primitives	EVM + Solana	ECDSA chains
Policy engine	Pre-signing	Pre-signing	API-level	Session caps	On-chain
Agent interface	MCP + REST	REST + SDK	REST	AgentKit	Vincent SDK
Open standard	CC0	Proprietary	Proprietary	Partial (x402)	Open source
Network required	No*	Yes	Yes	Yes	Yes

* Network required only for transaction broadcasting and balance queries, not for signing.

Prior Art

Standing on the shoulders of

LWS synthesizes ideas from the best wallet infrastructure in the industry.

x402

Spec structure, scheme/network/transport separation, contribution templates

Privy

Policy engine design, key sharding concepts, CAIP-2 chain identifiers

Coinbase AgentKit

ActionProvider/WalletProvider pattern, MCP tool exposure

Keystore v3

Proven encrypted storage format since 2015

CAIP Standards

Chain-agnostic identifiers for chains, accounts, and methods

ERC-4337

Session keys, programmable validation, paymaster sponsorship

Turnkey

TEE-based signing, sub-100ms latency targets

W3C Universal Wallet

lock/unlock/import/export interface patterns

Solana Wallet Standard

Feature-based capability registration

Crossmint

Dual-key model, on-chain policy enforcement

Lit Protocol

Decentralized key management, IPFS-published policies

WalletConnect v2

Session authorization model, relay architecture

LWS