Proposal: Multi-Asset Zaps (Extending NIP-57 for Native On-Chain Tari/XTM Support)

[floscodes]

Hi everyone,

I would like to propose a lightweight extension to NIP-57 (Zaps) to support native, on-chain zaps using the Tari (XTM) network.

Abstract & Design Pivot

Initially, my goal was to avoid modifying the user's profile metadata (Kind 0) altogether. However, after further consideration regarding client complexity, I decided to pivot. Forcing Nostr clients to derive native blockchain addresses directly from an npub would require every client to implement heavy, complex cryptographic libraries for chains like Tari or Sui and handle transaction building manually.

By introducing a structured wallets array to Kind 0 instead, the protocol becomes drastically simpler. Instead of bloating every single Zap Event with raw addresses or URLs, payment capabilities are defined once in the metadata. The client remains an asset-agnostic pipeline that triggers native wallet apps via dynamic deeplink templates, keeping the global relay events incredibly lightweight and preserving on-chain privacy.

Currently, NIP-57 is heavily tailored around Bitcoin Lightning invoices. While Lightning works great, incorporating an alternative, privacy-focused, and highly scalable asset like Tari opens up new possibilities for sovereign Web3 messaging clients—especially because it allows us to eliminate extra metadata.

The Core Advantage: Identity = Wallet

Since Nostr keys (npub / nsec) utilize the Secp256k1 elliptic curve, they can be directly mapped or deterministically converted into native Tari public/private keys.

This means:

1. Zero Profile Bloat: Users do not need to add a new custom tag (like ["tari", "..."]) to their Kind 0 metadata. The client can derive the destination payment address directly from the author's native Nostr pubkey.
2. One-Key Backup: Backing up the Nostr nsec automatically backs up the integrated Tari wallet.
3. No Third-Party/Custodial Hassle: Clients can embed a Tari light-client SDK directly into the app (e.g., in Rust/Zig) to handle peer-to-peer on-chain transactions directly.

---

Proposed Protocol Extension

Instead of introducing a brand-new Event Kind, we can gracefully extend the existing NIP-57 flow by introducing two optional tags: asset and tx.

1. Extended Zap Request (Kind 9734)

When a client intends to zap a post via Tari, it creates a standard Kind 9734 event but specifies the asset type and the amount (denominated in Micro-Tari to avoid rounding issues):

{
  "id": "...",
  "pubkey": "sender_nostr_pubkey_hex",
  "created_at": 1781874000,
  "kind": 9734,
  "tags": [
    ["p", "recipient_nostr_pubkey_hex"],
    ["e", "targeted_event_id_hex"],
    ["relays", "wss://relay.damus.io"],
    
    // Extension Tags:
    ["asset", "xtm"],
    ["amount", "5000000"] 
  ],
  "content": "Native Tari Zap!",
  "sig": "..."
}

2. Extended Zap Receipt (Kind 9735)

Once the integrated client/wallet executes the on-chain transfer to the derived Tari address and broadcasting is complete, a standard Kind 9735 Zap Receipt is published. Instead of a Lightning preimage, it attaches the cryptographic proof from the blockchain (the Tari Transaction ID or Kernel Excess Hash):

{
  "id": "...",
  "pubkey": "recipient_or_sender_nostr_pubkey_hex",
  "created_at": 1781874050,
  "kind": 9735,
  "tags": [
    ["p", "recipient_nostr_pubkey_hex"],
    ["P", "sender_nostr_pubkey_hex"],
    ["e", "targeted_event_id_hex"],
    
    // Extension Tags:
    ["asset", "xtm"],
    ["tx", "tari_tx_id_or_kernel_excess_hex"],
    ["description", "{\"...expanded_kind_9734_json...\"}"]
  ],
  "content": "",
  "sig": "..."
}

Backward Compatibility

This approach is fully backward-compatible. Relays don't need any modifications since they treat it as a standard NIP-57 event. Legacy clients that do not support Tari will simply ignore the unknown asset and tx tags, preventing any breaking behavior, while modern clients can render a seamless "Lightning or Tari" Zap UI.

I am planning to build an experimental proof-of-concept for this inside a custom Rust-based client, but I would love to hear the community's thoughts on the tag naming conventions (asset vs. currency) and the general flow before opening a formal PR.

Looking forward to your feedback!

[psam21]

Hi @floscodes Happy to collab on building out the PoC for this. Do update if you happen to have a link to the repo for it.

[floscodes]

Hey @psam21! Thanks for reaching out, I'd love to collaborate on this. Right now, I don't have a public repo or anything ready to show yet—it's mostly just a conceptual idea and some loose local notes at the moment.

I'll definitely keep you posted and share a link here as soon as I have a basic structure pushed to GitHub. Appreciate the interest!

[vitorpamplona]

Keep in mind that amount is always millisats in the original nip, so if you send anything else in that same tag it will not be backwards compatible: older apps will just show the wrong sum of sats instead.

[floscodes]

Good catch, thanks for the reminder! That's actually the exact architectural puzzle I'm currently pondering. Appreciate the feedback!

[floscodes]

Hi, @vitorpamplona ,

A possible solution is to introduce a new custom tag, like ⁠asset-amount⁠. That way, it stays perfectly backwards compatible: older apps will simply ignore the unknown tag, while newer clients can specifically look for it and interpret the correct asset logic.

[floscodes]

Hi, @vitorpamplona ,

A possible solution is to introduce a new custom tag, like ⁠asset-amount⁠. That way, it stays perfectly backwards compatible: older apps will simply ignore the unknown tag, while newer clients can specifically look for it and interpret the correct asset logic.

...or even more elegant: put the amount in the "asset" tag itself, as well as all other relevant data for a transaction.

[floscodes]

I was thinking about it... and therefore I woudl like to propose the following:

Instead of forcing Nostr clients to derive native blockchain addresses directly from an npub—which would require every client to implement complex, heavy cryptographic libraries for chains like Tari or Sui and handle transaction building manually—we propose a decentralized, metadata-driven approach.

By leveraging Nostr's native Kind 0 (Metadata), users can broadcast their sovereign wallet configurations. The client remains an asset-agnostic pipeline that triggers native wallet apps via dynamic deep links, keeping the global relay events incredibly lightweight.

1. User Profile Setup (Kind 0)

Users register their supported assets directly in their profile metadata by adding a standardized wallets array. Each object in the array defines the asset, the target address, and a deeplink_template containing {address} and {amount} placeholders.

{
  "name": "Florian",
  "about": "Nostr & Crypto Developer",
  "wallets": [
    { 
      "asset": "xtm", 
      "address": "<WALLET_ADDRESS>",
      "deeplink_template": "tari://testnet/payments/send?tariAddress={address}&amount={amount}" 
    },
    { 
      "asset": "sui", 
      "address": "<WALLET_ADDRESS>",
      "deeplink_template": "sui://transfer?asset=sui&to={address}&amount={amount}" 
    },
    { 
      "asset": "btc", 
      "address": "<WALLET_ADDRESS>",
      "deeplink_template": "bitcoin:{address}?amount={amount}" 
    }
  ]
}

2. The Zap Request (kind: 9734)

When a user wants to send a Zap, the sending client fetches the recipient’s profile, looks up the requested asset, and publishes a highly stripped-down Zap Request event. It contains only the asset name and the intended amount—no raw addresses or bloated URLs are leaked to the relay.

// The "asset" tag structure: ["asset", "asset_name", "amount"]
[
  "asset", 
  "xtm", 
  "1000"
]

3. Client Execution (Generating the Deep Link)

Simultaneously, the sender-client resolves the deeplink_template locally by replacing the placeholders with the data from the recipient's profile and the chosen amount. It then hands over execution to the operating system to trigger the native wallet app for signing.

// 1. Find the target wallet configuration from the recipient's Kind 0
const wallet = recipientProfile.wallets.find(w => w.asset === 'xtm');

// 2. Dynamically build the deep link using the template
const deepLink = wallet.deeplink_template
    .replace('{address}', wallet.address)
    .replace('{amount}', chosenAmount);

// 3. Publish the Zap Request (Kind 9734) to the relay
publishZapRequest('xtm', chosenAmount);

// 4. Trigger the native wallet app for signing and broadcasting
window.location.href = deepLink;

4. Verification & Zap Receipt (kind: 9735)

The recipient's client listens for incoming Zap Requests (kind: 9734) matching its own public key.

Since the recipient client inherently knows its own wallet addresses, it queries its local node or a public blockchain explorer/indexer to check for a matching incoming transaction (filtering by the designated amount and timeframe). Once verified, the recipient publishes the final Zap Receipt, appending the cryptographic proof (tx_id / transaction digest) as the final element of the tag.

// The "asset" tag structure: ["asset", "asset_name", "amount", "tx_id"]
[
  "asset", 
  "xtm", 
  "1000", 
  "0a3f8b9c2d1e0f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f"
]

I am currently in the process of designing a Proof of Concept (PoC) for this architecture to demonstrate its feasibility.

[floscodes]

Following up on my proposal above — after building an actual PoC, the design evolved in a few ways worth documenting here:

What changed and why

1. Renamed from "Zap" to "Spark"

The earlier draft extended NIP-57's Kind 9734/9735 pair with asset/tx tags. In practice this conflated two fundamentally different payment mechanisms: Zaps settle via Lightning invoices in-app, while this flow hands off to a native wallet (browser extension or mobile deep link) that signs and broadcasts the transaction itself — the client never touches the actual transfer. Reusing the Zap kinds implied a receipt/settlement model that doesn't really apply here, so I split it into its own kind: 9736 — Spark Request.

2. Dropped the Receipt event entirely

The original proposal kept Kind 9735 (Zap Receipt) with a tx/tx_id tag appended once the recipient verified an on-chain transaction. In practice this requires the recipient's client to watch a chain indexer or node for a matching inbound tx — extra infrastructure for every supported asset, and it doesn't fit chains where the sender's wallet extension already returns a signed tx hash directly to the sender. Since the wallet extension/app confirms execution to the sender synchronously, there's no need for a second relay round-trip just to prove settlement. So the protocol is now down to one event kind, not two.

3. Wallet config generalized beyond Tari

The wallets array in Kind 0 now carries a CAIP-2-style chain identifier (eip155:1, bitcoin:mainnet, sui:mainnet, tari:mainnet, …) alongside address and deeplink_template. This lets the sending client auto-detect an available wallet via open standards — EIP-6963 for EVM chains, Wallet Standard for Sui/Solana/others — with the deep link as a mobile fallback. No wallet names are hardcoded anywhere; detection is purely capability/standard-based. The original idea of deriving a Tari key deterministically from the Nostr nsec is still architecturally possible, but I moved to the explicit wallets array as the default since it generalizes to any chain without requiring every client to embed asset-specific derivation logic.

Current proposal

Kind 0 (extended, no new required fields):

{
  "name": "Florian",
  "wallets": [
    {
      "asset": "xtm",
      "chain": "tari:mainnet",
      "address": "<WALLET_ADDRESS>",
      "deeplink_template": "tari://payments/send?tariAddress={address}&amount={amount}"
    }
  ]
}

Kind 9736 — Spark Request (published by the sender, informational only — no receipt event follows):

{
  "kind": 9736,
  "tags": [
    ["p", "recipient_pubkey_hex"],
    ["asset", "xtm", "1000000"]
  ],
  "content": ""
}

The sending client resolves the recipient's wallets entry, publishes the Spark Request for visibility/logging, and simultaneously triggers the native wallet (extension API or OS deep link) to sign and broadcast. Settlement confirmation comes directly from the wallet, not from a second Nostr event.

PoC

I put together a working demo showing profile-driven wallet discovery, generic extension detection (EIP-6963 / Wallet Standard), and the deep-link fallback for BTC/XTM/SUI/ETH:

👉 https://floscodes.github.io/spark-poc/

It publishes real Kind 9736 events to wss://nos.lol with an ephemeral session key (no real funds involved unless you connect a real wallet — the page warns clearly before doing so).

Feedback welcome, especially on whether 9736 is a sensible landing spot and whether the asset/chain tag split makes sense long-term, or if this should be folded under a namespaced tag instead. - cc @psam21 — you mentioned earlier you'd be interested in helping out with a PoC. The demo above is functional now, would love your eyes on it