Background
MoonPay launched the Open Wallet Standard (OWS) — a local-first protocol for AI agent wallet storage and signing. The standard launched with 21 founding organizations including PayPal, OKX, Ripple, Solana Foundation, Ethereum Foundation, Base, Circle, and others.
Stacks is not in the coalition. This represents both a gap and an opportunity — we could be the ones to bring Stacks support to a multi-chain standard backed by major players.
OWS addresses a real problem: every agent framework rolls its own key management, resulting in private keys scattered across dotfiles, env vars, and proprietary formats. OWS proposes one encrypted vault, one signing interface, and a security model where the private key is never exposed to the agent or LLM.
What OWS Provides
- One mnemonic, every chain — BIP-39 seed derives accounts for 9 chain families (EVM, Solana, Bitcoin, Cosmos, Tron, TON, Sui, Spark, Filecoin)
- Rust core with Node.js bindings — NAPI-RS for native performance, ~11 MB binary per platform
- AES-256-GCM encryption — scrypt KDF (N=65536), Ethereum Keystore v3 format
- Key isolation — mlock (pinned memory), zeroize after use, core dump prevention, ptrace protection
- Policy engine — Declarative rules (chain allowlists, expiry) + custom executable policies
- Agent API keys — Scoped tokens bound to wallets + policies, independently encrypted
- Audit logging — Append-only JSONL
What We Already Have (Strong Overlap)
Our wallet implementation across both repos (MCP server + skills) already covers significant ground:
| Feature |
Our Implementation |
OWS |
| BIP-39 mnemonic |
Yes |
Yes |
| AES-256-GCM encryption |
Yes |
Yes |
| scrypt KDF |
Yes (N=16384) |
Yes (N=65536) |
| Local-first storage |
Yes (~/.aibtc/) |
Yes (~/.ows/) |
| Session lifecycle |
Unlock/lock with auto-timeout |
Per-call passphrase |
| Memory clearing |
fill(0) on lock |
mlock + zeroize on drop |
| Bitcoin P2WPKH (m/84') |
Yes |
Yes |
| Multi-chain from one seed |
Stacks + BTC + Taproot |
9 chain families |
What We Have That OWS Doesn't
| Feature |
Details |
| Stacks support |
Full transaction building (transfers, contract calls, deploys) |
| Taproot (m/86') |
P2TR addresses, Schnorr signing, BIP-342 script-path |
| PSBT support |
Create, decode, sign, broadcast |
| SIP-018 signing |
Structured data signing for on-chain verification |
| BIP-137/322 message signing |
Full message signing with address type detection |
| Ordinal operations |
Inscriptions, P2P trades, rune transfers |
| UTXO management |
Selection, fee estimation, broadcast via mempool.space |
| x402 payment flow |
Automatic payment signing for HTTP 402 challenges |
Gap Analysis
Critical Blockers for OWS Adoption
- No Stacks chain support — Chains are hardcoded in a Rust enum. Adding Stacks requires writing a
StacksSigner in Rust and getting an upstream PR accepted.
- No raw signing API — No
signDigest() or signBytes(). All signing goes through chain-specific signers with their own hashing (Bitcoin = double-SHA256, EVM = keccak256). Stacks needs SHA-512/256.
- No plugin/extension system — Despite the spec claiming chains can be added without core changes, the implementation requires modifying Rust source and recompiling all platform binaries.
- No Taproot support — OWS Bitcoin is P2WPKH only. No BIP-86 derivation, no Schnorr signing, no P2TR addresses.
- No CAIP-2 namespace for Stacks — OWS uses CAIP-2 chain identifiers. Stacks doesn't have one registered.
What OWS Adds That We Lack
| Feature |
Value to Us |
| Policy engine |
Spending limits, chain restrictions, time-bound access — useful for agent scoping |
| Agent API keys |
Scoped tokens for different tools/agents — we have nothing like this |
| Audit logging |
Transaction history tracking — we have none |
| mlock + zeroize |
Real memory protection vs our fill(0) — meaningful security improvement |
| Process hardening |
Core dump prevention, ptrace protection — we have none |
| Standard vault format |
Wallet portability between tools — ours is proprietary |
Signing Delegation Analysis
| Category |
Operation |
Delegable to OWS? |
| Stacks |
STX Transfer, Contract Call, Deploy |
NO — @stacks/transactions signs internally |
| Stacks |
SIP-018 Signing |
Partially — can compute hash separately |
| Bitcoin |
P2WPKH Transfer, PSBT, Ordinals |
YES — build/sign already separated |
| Bitcoin |
Taproot Signing |
NO — OWS has no Taproot support |
| Messages |
BIP-137/322 |
YES — hash → sign |
| x402 |
Payment Signing |
NO — uses Stacks tx signing |
Opportunity: Guiding OWS Bitcoin L1 Support
OWS claims Bitcoin support, but what they actually have is minimal:
| Bitcoin Feature |
OWS |
Us |
| P2WPKH (SegWit) |
Basic sighash signing only |
Full: UTXO selection, fee estimation, broadcast |
| Taproot (P2TR) |
None |
Full: BIP-86 derivation, Schnorr signing, script-path |
| PSBT |
None |
Full: create, decode, sign, broadcast, multi-party |
| BIP-137/322 message signing |
Basic (137 only) |
Both standards with address type detection |
| Ordinals/Inscriptions |
None |
Atomic swap PSBTs, child inscriptions, rune transfers |
| UTXO management |
None |
Coin selection, dust threshold, change outputs |
| Fee estimation |
None |
Dynamic via mempool.space (fast/medium/slow) |
| Transaction broadcast |
Not implemented for BTC |
Via mempool.space API |
This is where we can lead, not follow. Rather than just adding Stacks as "another chain," we can help define what real Bitcoin L1 support looks like in the standard:
- Taproot as a first-class address type — BIP-86 derivation, Schnorr signing, not just P2WPKH
- PSBT as the signing interface for Bitcoin — The current raw sighash approach is too low-level for real use. Agents need to build, inspect, and sign PSBTs for multi-party transactions, ordinals, and runes.
- UTXO-aware transaction building — A wallet standard that can't select UTXOs or estimate fees isn't usable for Bitcoin agents
- Stacks as a Bitcoin L2 — Same BIP-39 seed, related derivation paths, bridged via sBTC. Position Stacks alongside Bitcoin in the standard, not as a standalone chain.
What We'd Contribute Upstream
| Contribution |
Rust Work Required |
Our Reference Implementation |
ChainType::Stacks signer |
New signer with SHA-512/256 + Crockford base32 |
src/transactions/builder.ts |
| Taproot (BIP-86) for Bitcoin |
Add P2TR path + Schnorr to BitcoinSigner |
src/utils/bitcoin.ts |
| PSBT signing interface |
New signPsbt() function in signing API |
src/tools/psbt.tools.ts |
| BIP-322 message signing |
Extend sign_message() for Bitcoin |
src/utils/bip322.ts |
| CAIP-2 namespace for Stacks |
Propose stacks:mainnet / stacks:testnet |
N/A (standards work) |
Maturity Assessment
| Metric |
Value |
Risk Level |
| Repo age |
Brand new (first commit 2026-02-27) |
Critical |
| Time to v1.0.0 |
10 days (from v0.3.0) |
Critical |
| npm downloads (total) |
~640 |
High |
| GitHub stars |
73 |
Moderate |
| Human contributors |
6 |
High — effectively single maintainer |
| Coalition partner contributions |
0 PRs |
High — announcements only |
The 21-org coalition is currently marketing, not engineering. Zero external contributions are visible in the repo. All code is from MoonPay/Dawn Labs.
Recommended Path
Engage Now, Contribute When Ready
- OWS is brand new with zero coalition contributions — betting on it today is premature
- Adopting OWS design patterns sounds incremental but is actually a major rewrite (~20 files across both repos) for features we don't urgently need
- Our wallet works well. The gaps (policy engine, audit logging, API keys) are real but not blocking current use cases
- Our Bitcoin L1 implementation is ahead of OWS — that's leverage for when we do engage
Immediate steps:
- Open an issue on OWS repo outlining what Bitcoin L1 support should look like (Taproot, PSBT, UTXO management) and offering Stacks as a Bitcoin L2 addition
- Track the project — is the coalition contributing? Is the API stabilizing?
- When OWS adds a raw signing API or plugin system, contribute Stacks + enhanced Bitcoin upstream
- Design our wallet abstraction layer incrementally (shared package for MCP + skills) so we're ready to swap backends later
Action Items
Migration Considerations
Existing Wallet Users
- Current
~/.aibtc/ wallets use the same BIP-39 mnemonic standard
- Same mnemonic imports into OWS — Bitcoin addresses match at m/84'
- Stacks addresses need Stacks chain support first
- One-time migration: decrypt with password → re-import to new format
Both Repos (MCP + Skills)
- Core signing code is identical across repos where they overlap
- MCP has additional signing tools (message signing, ordinals, PSBTs) that skills doesn't
- Any wallet abstraction should be a shared package
- Skills may become primary long-term — design abstraction there first
Blast Radius of a Backend Swap
- Bitcoin operations: LOW — build/sign already separated in
@scure/btc-signer
- Stacks operations: VERY HIGH —
@stacks/transactions requires private key internally, ~15-20 files affected
- The Stacks SDK is the main constraint, not our code — until
@stacks/transactions supports external signers, any wallet backend swap still needs to hand it a private key
Background
MoonPay launched the Open Wallet Standard (OWS) — a local-first protocol for AI agent wallet storage and signing. The standard launched with 21 founding organizations including PayPal, OKX, Ripple, Solana Foundation, Ethereum Foundation, Base, Circle, and others.
Stacks is not in the coalition. This represents both a gap and an opportunity — we could be the ones to bring Stacks support to a multi-chain standard backed by major players.
OWS addresses a real problem: every agent framework rolls its own key management, resulting in private keys scattered across dotfiles, env vars, and proprietary formats. OWS proposes one encrypted vault, one signing interface, and a security model where the private key is never exposed to the agent or LLM.
What OWS Provides
What We Already Have (Strong Overlap)
Our wallet implementation across both repos (MCP server + skills) already covers significant ground:
~/.aibtc/)~/.ows/)fill(0)on lockWhat We Have That OWS Doesn't
Gap Analysis
Critical Blockers for OWS Adoption
StacksSignerin Rust and getting an upstream PR accepted.signDigest()orsignBytes(). All signing goes through chain-specific signers with their own hashing (Bitcoin = double-SHA256, EVM = keccak256). Stacks needs SHA-512/256.What OWS Adds That We Lack
fill(0)— meaningful security improvementSigning Delegation Analysis
Opportunity: Guiding OWS Bitcoin L1 Support
OWS claims Bitcoin support, but what they actually have is minimal:
This is where we can lead, not follow. Rather than just adding Stacks as "another chain," we can help define what real Bitcoin L1 support looks like in the standard:
What We'd Contribute Upstream
ChainType::Stackssignersrc/transactions/builder.tsBitcoinSignersrc/utils/bitcoin.tssignPsbt()function in signing APIsrc/tools/psbt.tools.tssign_message()for Bitcoinsrc/utils/bip322.tsstacks:mainnet/stacks:testnetMaturity Assessment
The 21-org coalition is currently marketing, not engineering. Zero external contributions are visible in the repo. All code is from MoonPay/Dawn Labs.
Recommended Path
Engage Now, Contribute When Ready
Immediate steps:
Action Items
Migration Considerations
Existing Wallet Users
~/.aibtc/wallets use the same BIP-39 mnemonic standardBoth Repos (MCP + Skills)
Blast Radius of a Backend Swap
@scure/btc-signer@stacks/transactionsrequires private key internally, ~15-20 files affected@stacks/transactionssupports external signers, any wallet backend swap still needs to hand it a private key