Bitcoin taproot identity (BIP-322) — proposal + contribution offer

XIPs (XMTP Improvement Proposals) XIP Stage 0: Ideas
1

We just opened a GitHub issue on libxmtp proposing Bitcoin taproot address support as a first-class XMTP identity type. Posting here to introduce the use case and see if there’s interest before the PR work begins.

What we’re building

BNRP (Bitcoin Name Resolution Protocol) stores name records as Ordinals inscriptions on Bitcoin. A name like satoshi.btc resolves to a taproot address, an avatar, and routing metadata. All verifiable on-chain, no smart contracts, no API dependency.

We recently added a messaging field to the routing inscription (BNRP-IP-08). The idea: a name owner inscribes their XMTP inbox ID into their name record. Anyone can look up satoshi.btc, find the inbox ID, and open an E2E encrypted conversation. The name is the messaging address.

The current implementation works. Users link an EVM wallet to get an inbox ID, then store it. But the long-term fix is letting a Bitcoin taproot key associate with an XMTP inbox directly, without needing Ethereum at all.

XMTP’s identity page lists BTC as a planned future network. We want to build it.

What BIP-322 gives you

BIP-322 (“Generic Signed Message Format”) is a single signing interface covering all Bitcoin address types: P2PKH, P2WPKH, P2SH, and P2TR (taproot). For taproot it produces a BIP-340 Schnorr signature. The proof is compact and self-contained. No chain state needed to verify.

UniSat and Xverse both expose signMessage with bip322-simple today. The wallet side is already there.

What needs to change in XMTP

Following the blueprint from the identity extension docs:

  1. New MemberIdentifier variant (bitcoin_address = 4) in association.proto

  2. New BitcoinSignature message + bitcoin_bip322 = 6 in signature.proto

  3. BIP-322 verifier in verified_signature.rs (Schnorr path for P2TR, ECDSA for P2WPKH)

  4. TypeScript Signer wrapping UniSat / Xverse signMessage

Phase 1 scope: association with an existing inbox only. Per the capabilities table in the docs, inbox creation stays passkey/ETH. That’s sufficient for the BNRP use case and keeps the PR surface small.

The full proposal has proto diffs with exact field numbers read from the live files, Rust pseudocode mirroring the real verified_signature.rs structure, a working TypeScript signer for both wallets, and 4 specific questions for maintainers.

Our intent

We’re prepared to contribute the implementation. We’re not asking the team to build this. We’re asking for alignment on: Rust crate for BIP-322, address storage format, network gating (mainnet-only Phase 1 or not), and IdentifierKind granularity.

If anyone on the XMTP side is tracking the Bitcoin identity work, or others are building in the Bitcoin/Ordinals space and want this, would appreciate hearing from you.

GitHub issue (proto diffs, Rust pseudocode, TypeScript signer, 4 questions for maintainers): Bitcoin Identity Support (BIP-322 / taproot) — implementation proposal · Issue #3568 · xmtp/libxmtp · GitHub
BNRP messaging spec: BNRP: Bitcoin Name Resolution Protocol — BTCNative

6 Likes