padreug commented on issue aiolabs/lightning-pub#11

padreug
2026-04-01T16:50:39Z

Extension: Satoshi Machine (DCA Distribution)
NIP Review: Applicable Standards for Satoshi Machine Extension

Core NIPs to Implement

NIP-47: Nostr Wallet Connect (NWC) — PAYMENT ENGINE

Kinds: 13194 (info), 23194 (request), 23195 (response), 23197 (notification)

The backbone for DCA distribution payments. Relevant methods:

NWC Method | DCA Use
pay_invoice | Execute distribution payments to clients
make_invoice | Generate invoices for fiat deposit collection
get_balance | Verify sufficient funds before distribution
list_transactions | Audit trail of all distributions
pay_keysend | Direct pubkey payment with TLV records (no invoice needed)

pay_keysend is particularly interesting — DCA distributions to registered clients (known pubkeys) could bypass invoice generation entirely.

The metadata field (up to 4KB) stores distribution context: client ID, deposit reference, commission breakdown, batch ID.

Key insight: NWC provides the authorization layer. The DCA extension can be a lightweight orchestrator that issues NWC requests for each distribution payment, with Lightning.Pub handling the actual settlement.

NIP-78: Application-Specific Data — CONFIG & STATE

Kind: 30078 (addressable, replaceable)

Store DCA configuration as encrypted addressable events:

{
  "kind": 30078,
  "tags": [["d", "satmachine-config"]],
  "content": "nip44_encrypt({
    'commission_percentage': 0.03,
    'discount': 0,
    'distribution_mode': 'flow',
    'atm_pubkey': '<lamassu-next-pubkey>',
    'poll_interval': 3600
  })"
}

Also use for client registry, distribution history snapshots, and batch state recovery after restart.

NIP-44: Versioned Encryption — REQUIRED

All financial data (configs, balances, distribution records) encrypted with NIP-44 (ChaCha20 + HMAC-SHA256 + HKDF). Non-negotiable for DCA where amounts and client identities are sensitive.

Supplementary NIPs

NIP | Kind | Use Case | Priority
NIP-17 (Private DMs) | 14, 1059, 13 | Notify clients of distributions via sealed gift-wrapped messages | Recommended
NIP-57 (Zaps) | 9735 | Zap receipts as secondary payment proof / audit trail | Optional
NIP-51 (Lists) | 30000 | Manage recipient cohorts as named follow sets | Optional
NIP-40 (Expiration) | — | Time-limited DCA campaigns with auto-expiry | Nice-to-have
NIP-75 (Zap Goals) | 9041 | DCA savings targets with progress tracking | Low priority
NIP-60 (Cashu) | 7375, 7376 | Offline ecash distribution alternative | Future exploration

Architecture Using NIPs

DCA Distribution Flow:

1. ATM publishes transaction event (kind 30079) via Nostr

2. Extension receives via onNostrEvent() subscription

3. Extension loads config from kind 30078 event

4. Commission calculated, client shares determined

5. For each client: issue NWC pay_keysend (kind 23194) or pay_invoice

6. On NWC response (kind 23195): record in local DB, update client balance

7. Notify client via NIP-17 sealed DM (kind 14 → 13 → 1059)

8. Update config/state event (kind 30078) with last processed transaction

What's NOT in any NIP:

No standard for scheduled/recurring payments — the extension must implement its own scheduler

No standard financial ledger event kind — recommend a custom kind or use NIP-78 with structured content

No subscription/recurring authorization model beyond NIP-47's per-request approval

Recommendation: Use NWC (NIP-47) as the payment primitive, NIP-78 for state, NIP-17 for notifications, NIP-44 for encryption. The DCA scheduling logic lives entirely in the extension — NIPs provide the communication and payment rails.