Context
At 0penw0rld, we’ve been building BCH wallet features that use Nostr relays as a decentralized communication layer: no servers, no APIs, just signed events relayed by standard Nostr infrastructure.
The problem: if another wallet (Electron Cash, Selene, Cashonize, etc.) wants to implement the same features, they need to use the same event kinds. Otherwise, a stealth payment sent from Wallet A will never be seen by Wallet B, a swap offer posted by one wallet is invisible to another, and CashFusion pools are fragmented.
This post proposes a standard set of Nostr event kinds for BCH wallet operations, so any wallet can implement these building blocks and be interoperable out of the box.
Proposed Event Kind Registry
Atomic Swaps - BCH ↔ BTC
| Kind | Name | Description | Storage |
|---|---|---|---|
4240 |
swap/offer |
Public swap offer (amount, rate, conditions) | Stored |
4241 |
swap/take |
Taker accepts offer (NIP-04 encrypted to maker) | Stored |
4242 |
swap/locked |
HTLC funded notification (encrypted) | Stored |
4243 |
swap/claimed |
Swap complete — preimage revealed (encrypted) | Stored |
Atomic Swaps - BCH ↔ XMR
| Kind | Name | Description | Storage |
|---|---|---|---|
4250 |
xswap/offer |
Public cross-chain swap offer | Stored |
4251 |
xswap/take |
Taker response (encrypted) | Stored |
4252 |
xswap/keys |
DLEQ key exchange (encrypted) | Stored |
4253 |
xswap/bch-locked |
BCH side locked in HTLC (encrypted) | Stored |
4254 |
xswap/xmr-locked |
XMR side locked (encrypted) | Stored |
4255 |
xswap/adaptor |
Adaptor signature exchange (encrypted) | Stored |
4256 |
xswap/claimed |
Swap finalized (encrypted) | Stored |
CashFusion (Coin Mixing)
| Kind | Name | Description | Storage |
|---|---|---|---|
22222 |
fusion/pool |
Pool announcement (tier, params) | Ephemeral |
22223 |
fusion/join |
Join pool + heartbeat | Ephemeral |
22224 |
fusion/proto |
Protocol messages (encrypted rounds) | Ephemeral |
Recurring Payments (Subscriptions)
| Kind | Name | Description | Storage |
|---|---|---|---|
22240 |
sub/invoice |
Receiver sends payment request to subscriber | Ephemeral |
22241 |
sub/tx-chain |
Payer sends pre-signed BCH TX chain | Ephemeral |
Onion Routing (Privacy Layer)
| Kind | Name | Description | Storage |
|---|---|---|---|
22230 |
onion/relay-announce |
Node announces itself as onion relay | Ephemeral |
22231 |
onion/blob |
Onion-encrypted routed payload | Ephemeral |
22232 |
onion/settle |
Payment settlement notification | Ephemeral |
Encrypted Chat
| Kind | Name | Description | Storage |
|---|---|---|---|
21059 |
chat/dm |
Ephemeral encrypted direct message (NIP-04) | Ephemeral |
How It Works
All communication uses standard NIP-01 events signed with secp256k1 Schnorr signatures. Encrypted content uses NIP-04 (ECDH shared secret + AES-256-CBC).
Key derivation: Wallets derive their Nostr identity from the BIP44 BCH path:
-
m/44'/145'/0'/2/0→ Nostr signing key (also used as stealth scan key) - Any BIP39 seed phrase automatically has a deterministic Nostr identity — no extra keys to manage
Relay infrastructure: Events are broadcast to standard public Nostr relays (relay.damus.io, nos.lol, etc.). No custom infrastructure needed. Any relay that supports these kind ranges works.
Kind ranges follow Nostr conventions:
-
4240–4256→ Regular stored events (1000–9999 range) - swap offers need to persist so counterparties can discover them -
21059→ Ephemeral (20000–29999 range) - chat messages don’t need permanent storage -
22222–22241→ Ephemeral (20000–29999 range) - fusion rounds, subscriptions, and onion routing are session-based
Why Standardize Now?
-
Stealth addresses: We implemented beaconless stealth addresses (ECDH shared secret + outpoint tweak). The paycode (
stealth:+ scan_pub + spend_pub) can be shared via NIP-04 DMs. If wallets use different event kinds, the sender’s notification never reaches the receiver. -
Atomic swaps: Swap offers should be visible to all BCH wallets listening on the same kinds, creating a shared decentralized orderbook. A user on Electron Cash should see offers from 0penw0rld and vice versa.
-
CashFusion: Fusion pools need maximum liquidity. Fragmenting pools across different kind numbers defeats the purpose of coin mixing.
-
Recurring payments: A merchant using Wallet A should be able to receive subscription payments from a customer using Wallet B using the same pre-signed TX chain protocol.
-
Chat & messaging: BCH-native encrypted messaging should work cross-wallet, like email works cross-provider.
What We Need From The Community
- Feedback on the kind numbers: Are there conflicts with existing NIPs or other projects using these ranges?
- Additional features: Should we reserve kinds for other operations? (Payment requests? Contact sharing? Stealth paycode announcements?)
- Adoption: Would other wallet teams be willing to implement these kinds?
All of this is live and working at 0penw0rld.com today. The source is open and any wallet can integrate these event kinds to become interoperable.
Built with 00 Protocol — 0penw0rld.com