Protocol
openwallet.sh · v1.3.2
Local-first wallet storage, policy-gated signing, one interface for every chain.
The Open Wallet Standard (OWS) defines how cryptographic wallets live on a local filesystem, how agents access them through a unified interface, and how policy-based controls govern what operations are permitted. 5 Kings implements OWS for AI-agent commerce flows where keys must never leave the device and policy must be enforced before any signature.
Six wallet formats. Six locations. Zero encryption.
Every CLI, agent, and script today implements its own key management. Keys end up scattered across plaintext config files, env vars, and shell history — with no shared security model between tools.
# Before OWS — keys scattered everywhere foundry → ~/.foundry/keystores/ hardhat → .env PRIVATE_KEY=0xab3f... solana → ~/.config/solana/id.json agent-x → .env.local SIGNER=0x91c... your-bot → ./config/wallet.json shell history → export PRIVATE_KEY=0x... # 6 formats · 6 locations · 0 encryption # After OWS — one vault, one interface, real encryption ~/.ows/wallets/ → AES-256-GCM encrypted # 1 vault · 1 interface # 6 formats → 1 standard # plaintext keys → AES-256-GCM # per-tool silos → shared vault
How a signing request flows through OWS
The keys never cross a single boundary. Every layer between the agent and the key material is hardened, audited, and short-lived.
Agent / CLI / App
│
│ OWS Interface (SDK / CLI)
▼
┌──────────────────────────┐
│ Access Layer │
│ ┌──────────────────────┐ │
│ │ Policy Engine │ │ 1. Caller invokes sign()
│ │ (pre-signing) │ │ 2. Policy engine evaluates for API tokens
│ └──────────┬───────────┘ │ 3. Key decrypted in hardened memory
│ ┌──────────▼───────────┐ │ 4. Transaction signed
│ │ Signing Core │ │ 5. Key wiped from memory
│ │ (in-process) │ │ 6. Signature returned
│ └──────────┬───────────┘ │
│ ┌──────────▼───────────┐ │ The OWS API never returns
│ │ Wallet Vault │ │ raw private keys.
│ │ ~/.ows/wallets/ │ │
│ └──────────────────────┘ │
└──────────────────────────┘
The OWS spec, in seven documents
OWS is published as a modular spec at docs.openwallet.sh.
Each document defines one piece of the contract; implementations must satisfy all seven to claim OWS compliance.
Storage Format
Encrypted keystore format, file layout, and vault structure. AES-256-GCM with PBKDF2-derived keys.
Signing Interface
The core sign, signAndSend, signMessage, and simulate operations.
Policy Engine
Policy types, evaluation order, and enforcement model. Every signing request runs through policy before any key is touched.
Agent Access Layer
MCP server, REST API, and SDK interfaces for agents. The same wallet, the same security model, across every entry point.
Key Isolation
Current in-process hardening (mlock + zeroize), future enclave options, and the explicit threat model.
Wallet Lifecycle
Creation, import, export, backup, recovery, and migration. No vendor lock-in — keys can be re-derived from any BIP-39 mnemonic.
Supported Chains
Chain families, CAIP identifiers, derivation paths, RPC endpoints, and asset identification. The canonical source of truth for what OWS signs for.
Ten chains, one wallet, standard derivation paths
Every chain uses the BIP-39 mnemonic as the root, with chain-specific BIP-44 / BIP-84 derivation. One seed, ten addresses.
| Chain | Curve | Address format | Derivation path |
|---|---|---|---|
| EVM (Ethereum, Polygon, …) | secp256k1 | EIP-55 checksummed | m/44'/60'/0'/0/0 |
| Solana | Ed25519 | base58 | m/44'/501'/0'/0' |
| Bitcoin | secp256k1 | BIP-84 bech32 | m/84'/0'/0'/0/0 |
| Cosmos (ATOM) | secp256k1 | bech32 | m/44'/118'/0'/0/0 |
| Tron | secp256k1 | base58check | m/44'/195'/0'/0/0 |
| TON | Ed25519 | raw / bounceable | m/44'/607'/0' |
| Sui | Ed25519 | 0x + BLAKE2b-256 hex | m/44'/784'/0'/0'/0' |
| Spark (Bitcoin L2) | secp256k1 | spark: prefixed | m/84'/0'/0'/0/0 |
| Filecoin | secp256k1 | f1 base32 | m/44'/461'/0'/0/0 |
| XRPL | secp256k1 | base58check | m/44'/144'/0'/0/0 |
One CLI, every operation
The OWS CLI is the canonical reference implementation. It is fully self-contained
and ships the Rust core via native FFI — install globally and the
ows command is on your PATH immediately.
Why OWS exists
These six principles are non-negotiable in any compliant OWS implementation. They are the reason the spec exists at all.
Keys live in ~/.ows/
Not in browser extension, cloud, or tool-specific configs. The vault is a directory on disk the operator controls.
No HTTP, no vendor lock-in
No auth flows, no rate limits, no remote dependencies. The signing core runs entirely on the operator's machine.
One wallet, every chain
BTC, ETH, SOL, ATOM, TON, TRON, Sui, Spark, Filecoin, XRPL — derived from the same BIP-39 mnemonic.
Your keys, your device
No remote signing, no custodians, no third-party access. The mnemonic is the only secret and never leaves the device.
Agents never see plaintext
Agents authenticate via scoped API tokens. The OWS API never returns raw private keys, ever.
Works with any JSON-speaking tool
CLI, MCP server, REST API, SDK — same wallet, same security model. Drop OWS into any agent stack.
Three production patterns
OWS is the wallet layer for the AI-agent products we build. We implement it on top of MCP, REST, and SDK surfaces depending on what the deployment looks like.
AI agents with wallets
Claude, Tempo, OpenAI Operator, or any MCP-compatible agent can sign transactions through a single OWS MCP server. The agent never holds the key — it asks, OWS evaluates the policy, signs if allowed, returns the signature.
Paid API flows (x402)
When a request returns HTTP 402 Payment Required, the OWS CLI handles the pay-cycle automatically: discover the price, evaluate the policy, sign the payment, retry the request. ows pay request & ows pay discover ship in the box.
Embedded wallet in custom apps
For SaaS products where users own their own keys, we embed OWS via the Rust core + native FFI bindings. The vault lives in the user's filesystem; the application never touches plaintext keys.
OWS builds on, does not replace, the open stack
OWS explicitly borrows from existing standards. The spec is the integration layer, not a competing wallet format.
Mnemonic phrase standard
All wallets are derived from a 12/24-word BIP-39 mnemonic. Any BIP-39-compatible wallet can restore an OWS wallet and vice-versa.
Hierarchical deterministic derivation
Standard derivation paths for every chain (m/44'/60'/0'/0/0 for EVM, m/84'/0'/0'/0/0 for Bitcoin bech32, etc).
Chain-agnostic identifiers
Chain IDs, account IDs, and asset IDs all use the CAIP standards from ChainAgnostic.org. OWS uses eip155:1, solana:mainnet, bip122:000000000019d6689c085ae165831e93 — not proprietary strings.
HTTP 402 payment protocol
The native ows pay request / ows pay discover commands implement the x402 paid-request flow. OWS is the wallet layer; x402 is the protocol layer.
Smart account concepts
Session keys, programmable validation, and paymaster sponsorship concepts inform OWS policy design.
Encrypted storage format
The OWS vault uses the proven Keystore v3 encrypted JSON format (since 2015) as a baseline, extended for multi-chain and policy metadata.
Questions about OWS and how we use it
What is the Open Wallet Standard?
OWS is an open specification (MIT-licensed) for how cryptographic wallets are stored on a local filesystem, how agents and CLI tools access them through a unified interface, and how policy-based controls govern what operations are permitted. Current implementations keep key material encrypted at rest with AES-256-GCM, apply policy checks before signing, and use in-process hardening during decryption and signing. See the full spec at docs.openwallet.sh.
Why is OWS different from a hardware wallet?
A hardware wallet (Ledger, Trezor) secures a single device's keys against physical extraction. OWS secures a local filesystem vault against software threats — the operator's machine runs the signing core and the vault is just an encrypted directory. They are complementary: OWS can integrate with hardware signing devices, and many OWS users also use a hardware wallet for high-value cold storage. OWS is for agent and automation flows where a hardware wallet's manual UX is a blocker.
Can I migrate my existing wallet into OWS?
Yes. ows wallet create takes a BIP-39 mnemonic as input — any wallet that already speaks BIP-39 (MetaMask, Phantom, Ledger, Trezor, any HD wallet) can have its keys re-derived into an OWS vault. The encrypted vault file format is open and documented in spec doc 01.
Does OWS support MPC / threshold signing?
Not in the current reference implementation. The spec explicitly notes key sharding as future work in doc 05. MPC is a complementary architecture — you would run an OWS-compatible signer inside each MPC participant and have OWS orchestrate the policy around them. We have done this for clients where the threat model demanded it.
What happens if the operator's machine is compromised at signing time?
OWS assumes the operator's machine is the trust boundary. The threat model in spec doc 05 is explicit: OWS defends against key exfiltration at rest, but if an attacker has live code execution on the host, they can sign. Mitigations include: (1) keep the vault on an encrypted filesystem, (2) lock the vault when idle, (3) integrate with hardware signing devices, (4) use policy limits so even a compromised host can only drain up to the per-tx / per-day cap.
What is the x402 payment flow and how does OWS plug into it?
x402 is the emerging standard for HTTP 402 Payment Required. When an API returns 402, the client has to discover the price, sign a payment, and retry the request. OWS ships native CLI commands for this: ows pay discover finds x402-enabled services, ows pay request handles the full pay-cycle (discover → evaluate policy → sign → submit). The OWS MCP server exposes the same surface to agents.
How does 5 Kings use OWS in client work?
We implement OWS as the wallet layer for AI-agent products we build. Three patterns: (1) embed the OWS MCP server so agents in the customer's stack can sign without ever holding a key, (2) wrap the OWS CLI as a pay-agent for x402 commerce flows (bookings, API purchases, B2B procurement), (3) integrate OWS into custom SaaS dashboards via the Rust FFI bindings. We also contribute upstream to the OWS spec where our client work surfaces gaps.
How do I get started?
For a self-serve path: npm install -g @open-wallet-standard/core, then ows wallet create --name my-agent. For an integrated build (MCP server in your agent stack, x402 flows, custom policy engine): book a free call with us.
Ready to ship OWS in your agent stack?
Free, no-pressure call. We will review your current wallet / agent architecture, share our honest take on where OWS fits (and where it does not), and let you decide.
Book a free 30-min call →Read the full spec at docs.openwallet.sh · Star the repo at github.com/open-wallet-standard/core