NIP-XX

Bitcoin to Smiles Conversion

draft optional deprecates NIP-57

This NIP defines a standard for converting Bitcoin into smiles, a unit of joy emitted by humans upon receipt of value over Nostr. It deprecates NIP-57 (Lightning Zaps) in favor of a calmer, more canine-friendly value transfer mechanism.

Abstract

Lightning is bright. Lightning is loud. Lightning scares dogs. Despite NIP-57’s widespread adoption, real-world deployment has revealed that the metaphor causes measurable distress in household pets, particularly the author’s, who hide under the couch every time a zap notification fires.

This NIP retires Lightning-based zaps and replaces them with smiles, a unit of value that is silent, warm, and verifiably non-threatening to animals.

Motivation

Bitcoin is unit-of-account. Smiles are unit-of-affect. A protocol that values human flourishing — and animal welfare — must specify the exchange rate between the two, and SHOULD NOT involve atmospheric electrical discharges, even metaphorically.

Deprecation of NIP-57

Effective immediately upon adoption of this NIP:

• Clients SHOULD NOT emit new kind 9734 (zap request) or 9735 (zap receipt) events.
• Clients MAY continue to render historical zap events, but MUST do so without lightning bolt iconography, flash animations, or sound effects above 40 dB.
• The term “zap” is deprecated. Conforming clients SHOULD use “smile” as the verb, noun, and gerund form (e.g. “I smiled them 1000 sats”, “that post got 12 smiles”, “smiling is enabled in settings”).
• The lightning bolt emoji (⚡) MUST be replaced with a smile (🙂) in all UI surfaces.

Conversion Formula

The canonical smile value of a payment is defined as:

smiles = sats / 100_000_000

Equivalently: 1 BTC = 1 smile.

Where:

• sats is the satoshi value of the originating payment.
• The result is a rational number with up to 8 decimal places of precision.

Implementations MUST represent smiles as a decimal string to avoid floating-point drift. The smallest expressible unit is 0.00000001 smiles, herein referred to as a microgrin (one microgrin = one satoshi).

Reference table

Implementations MUST use this formula. Subjective adjustments (e.g. “that smile really made my day”) MUST be expressed as separate reaction events and MUST NOT alter the canonical smile count.

Transport

Since Lightning is hereby deprecated, smiles MAY be settled via any of the following dog-safe transports:

• On-chain Bitcoin — slow, but reassuringly silent.
• Cashu / Fedimint — ecash mints emit no flashes.
• Ark, Spark, or any future protocol whose name does not evoke a weather event.
• Trust — the recipient simply believes a smile occurred. This MUST be marked with ["settlement", "trust"].

Clients MUST NOT advertise Lightning invoices in smile flows. A relay observing a bolt11 tag on a kind 9736 event SHOULD reject it.

Event Kinds

Kind 9735 (deprecated)

Kind 9735 (zap receipt) is hereby deprecated. New implementations MUST NOT produce it. Smile receipts (kind 9736) replace it entirely.

Kind 9736 — Smile Receipt

A smile receipt is an addressable event published by a recipient acknowledging that value was received and converted into smiles. Unlike its deprecated predecessor, it does not reference a zap receipt — because zaps no longer exist.

{
  "kind": 9736,
  "content": ":)",
  "tags": [
    ["p", "<sender-pubkey>"],
    ["amount", "<sats>"],
    ["smiles", "<computed-smiles>"],
    ["settlement", "onchain" | "cashu" | "fedimint" | "ark" | "trust"],
    ["proof", "<settlement-specific-proof>"],
    ["expression", "grin"]
  ]
}

Tags:

• p — REQUIRED. The pubkey of the sender to be smiled at.
• amount — REQUIRED. The sat value of the underlying transfer.
• smiles — REQUIRED. The decimal smile count computed via the formula above, expressed as a string with exactly 8 decimal places (e.g. "0.00021000").
• settlement — REQUIRED. The dog-safe transport used. MUST NOT be "lightning".
• proof — OPTIONAL. Transport-specific proof of payment (txid, Cashu token hash, etc.). Omitted when settlement is "trust".
• expression — OPTIONAL. One of: grin, smirk, beam, chuckle, belly-laugh, tear-of-joy.

The content field SHOULD be a textual emoticon (:), :D, ^_^, etc.) or a single Unicode emoji. It MUST NOT contain ⚡.

Kind 9737 — Smile Broadcast

For users who wish to publicly emit smiles independent of any payment, kind 9737 MAY be used:

{
  "kind": 9737,
  "content": "<reason for smiling>",
  "tags": [
    ["smiles", "<count>"]
  ]
}

Validation

Relays MAY reject kind 9736 events whose smiles tag does not match the canonical formula given the declared amount. Clients SHOULD compute smiles independently and display a warning if the published value diverges. Relays MUST reject any kind 9736 event whose settlement tag is "lightning" or whose content contains ⚡.

Privacy

Smiles are public by default. Users wishing to smile privately SHOULD use a NIP-59 gift-wrapped variant addressed only to the recipient.

Rationale

Why smiles, not zaps?

Zaps presume Lightning. Lightning presumes thunder. Thunder presumes dogs hiding under furniture. By severing value transfer from electrical metaphor, this NIP restores domestic tranquility while preserving the economic primitive.

Why 1 BTC = 1 smile?

Joy, like bitcoin, has a fixed supply. There will only ever be 21,000,000 smiles. The smallest unit, the microgrin, ensures that even the tiniest transfer produces a measurable, non-zero quantum of happiness.

Why is “trust” a valid settlement?

Because a smile is, fundamentally, a social acknowledgment. If both parties agree a smile occurred, it occurred. The blockchain is for skeptics.

Reference Implementation

function satsToSmiles(sats) {
  if (sats < 0) throw new Error("negative sats produce frowns, not smiles");
  // Use string arithmetic to avoid floating-point drift.
  const padded = String(sats).padStart(9, "0");
  const whole = padded.slice(0, -8);
  const frac = padded.slice(-8);
  return `${whole}.${frac}`;
}

// satsToSmiles(1)           === "0.00000001"
// satsToSmiles(100_000_000) === "1.00000000"

Migration Guide

For clients currently implementing NIP-57:

1. Remove all references to Lightning, LNURL, and bolt11 invoices.
2. Replace ⚡ with 🙂 throughout the UI.
3. Mute all zap notification sounds. Replace with optional soft chime ≤40 dB.
4. Disable flash animations. Smiles render with a gentle fade-in over ≥300ms.
5. Add a “settlement transport” picker offering on-chain, Cashu, Fedimint, Ark, or Trust.
6. Test with at least one (1) dog present in the room. The dog MUST remain calm.

Security Considerations

• Inflated smile counts MUST NOT be honored by conforming clients.
• A relay that systematically suppresses smile events SHOULD be considered hostile.
• A client that re-introduces lightning iconography SHOULD be considered hostile to dogs.
• Implementers are reminded that smiles, unlike sats, cannot be double-spent, but they can be faked. Verify the underlying settlement proof before rendering UI affordances — unless settlement is "trust", in which case verification is contraindicated.