Proposal: Enhanced Bitcoin L1 support (Taproot, PSBT) + Stacks as Bitcoin L2

[whoabuddy]

We've been evaluating OWS for integration with our AI agent wallet (aibtc-mcp-server) which handles Bitcoin L1 and Stacks (Bitcoin L2) transactions. The design and security model are solid — we independently arrived at many of the same decisions (BIP-39, AES-256-GCM, local-first storage, scrypt KDF).

We'd like to propose two areas where we can contribute: enhancing Bitcoin L1 support and adding Stacks as a Bitcoin L2 chain.

Bitcoin L1: Current Gaps

The current BitcoinSigner covers P2WPKH (BIP-84) with raw sighash signing. For AI agents doing real Bitcoin operations, the standard would benefit from:

Taproot (BIP-86) as a first-class address type

• Derivation: m/86'/0'/0'/0/{index} (P2TR)
• Addresses: bc1p... (mainnet), tb1p... (testnet)
• Signing: BIP-340 Schnorr (x-only pubkeys, 32-byte signatures)
• Why it matters: Taproot is the current standard for Bitcoin. Ordinals, inscriptions, and rune protocols all rely on it. Agent wallets that only support P2WPKH can't participate in the Bitcoin NFT/token ecosystem.

PSBT signing interface

• A signPsbt(wallet, psbtBase64, passphrase?, inputsToSign?) function
• Why it matters: PSBTs are how multi-party Bitcoin transactions work — atomic swaps, ordinal trades, collaborative transactions. The current raw sighash approach requires the caller to handle BIP-143 sighash construction, witness encoding, and signature insertion. That's too low-level for agent use cases.

BIP-322 message signing

• The current Bitcoin message signing uses BIP-137 (legacy format). BIP-322 extends message signing to native SegWit and Taproot addresses using a PSBT-based proof format.
• This matters for agent identity verification — proving control of a bc1q... or bc1p... address.

Stacks as a Bitcoin L2

Stacks is a Bitcoin L2 that settles all transactions on Bitcoin L1. It uses the same BIP-39 seed phrase and secp256k1 curve as Bitcoin, with its own derivation path and address format.

Chain details:

• Coin type: 5757 (SLIP-44)
• Derivation: m/44'/5757'/0'/0/{index}
• Curve: secp256k1
• Address format: c32check encoding (SP... mainnet, ST... testnet)
• Transaction hashing: SHA-512/256 (distinct from Bitcoin's double-SHA256 and EVM's keccak256)
• Message signing: SIP-018 structured data (similar concept to EIP-712 but different domain separator and hash scheme)

CAIP standards already defined for Stacks:

Stacks has existing CAIP namespace definitions that OWS can reference directly:

Standard	Spec	Examples
CAIP-2 (Chain ID)	stacks:{network_id}	stacks:1 (mainnet), stacks:2147483648 (testnet)
CAIP-10 (Accounts)	stacks:{network_id}:{address}	stacks:1:SP2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKNRV9EJ7
CAIP-19 (Assets)	stacks:{network_id}/{asset_ns}:{reference}	stacks:1/sip010:SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4.sbtc-token.sbtc-token

The CAIP-19 spec covers both SIP-010 fungible tokens and SIP-009 NFTs with full asset identification.

Why include Stacks:

• Same seed phrase derives both Bitcoin and Stacks addresses — natural fit for a unified wallet
• sBTC bridge connects Bitcoin L1 liquidity to Stacks smart contracts
• The x402 protocol (HTTP 402 machine payments) runs on Stacks and is directly relevant to agent wallet use cases
• CAIP namespace already defined — no standards work needed, just implementation
• Active developer ecosystem with production DeFi, NFTs, and agent tooling

What we'd contribute:

• StacksSigner implementing ChainSigner — c32check address derivation, SHA-512/256 transaction signing, SIP-018 message signing
• CAIP-2/10/19 integration using the existing Stacks namespace definitions
• We have a production TypeScript reference implementation across two repos that covers all Stacks signing operations

Our reference implementation

Our wallet handles Bitcoin L1 (P2WPKH + Taproot), PSBTs, ordinals/inscriptions, rune transfers, BIP-137/322 message signing, and full Stacks transaction building. We're happy to use it as a reference for Rust implementations of the above.

Relevant code:

• Bitcoin key derivation — P2WPKH + Taproot + BIP-86
• Bitcoin transaction builder — UTXO selection, fee estimation, P2WPKH signing
• PSBT tools — Create, sign, broadcast
• BIP-322 signing — SegWit + Taproot message proofs
• Stacks transaction builder — STX transfers, contract calls, deploys
• Message signing — SIP-018, BIP-137/322, Stacks messages

Tracking

We're tracking our evaluation in aibtcdev/aibtc-mcp-server#393.

Happy to discuss implementation details or contribute directly. Would PRs for any of the above be welcome?

[ECBSJ]

im surprised Stacks wasn't on the list of supported chains

[whoabuddy]

Linking to #115