Why Integrate Satograms#

The opportunity#

Satograms are message-attached sats that get broadcast to many lightning-address recipients in a single campaign. Senders pay upfront; the service fans the payment out across the Lightning Network. If your users have lightning addresses on your domain (e.g. alice@yourwallet.com), they will already receive Satograms through the LNURL-pay flow you have today, no integration on your part beyond what LUD-12 already requires. Integration unlocks two things: (1) display the sender’s message to your user, turning a “5 sats received” notification into “Bob sent you 5 sats with this note”, and (2) if your volume justifies it, opting into the batch keysend path which lets you take a delivery cut on batch keysends to your users.

What’s in it for you#

1. The cut (batch keysend mode)#

This is the headline number. When you opt into batch keysends:

• The Satogram service sends one keysend to your node that covers N of your users at once.
• The keysend’s amount_msat is N × per_satogram_amount × 1000.
• You credit each user and keep a delivery fee. The delivery fee rate is set during onboarding. There is no operator-side share.

A worked example. A Satogram campaign at 1 sat per recipient (the default) hits 10,000 lightning addresses across the network. 1,200 of those are on your wallet:

Multiply by campaigns per month and the cut compounds. The cut works for one specific reason: Satograms are unsolicited inbound messages, not user-requested payments. Charging a delivery fee on incoming-spam-with-sats is a legitimately better revenue source than charging your users on payments they explicitly accepted.

The example code in this guide leaves the rate as a configurable constant; replace it with the rate set during onboarding.

2. Free inbound activity for your users#

Satogram campaigns pay lightning addresses across the network, as far as each campaign’s budget and audience reach. Each user on your domain that a campaign reaches gets an inbound payment, with zero marketing spend on your side. Users see activity in their wallets. Engagement goes up. Inbound activity is one of the strongest retention signals in any consumer fintech.

3. Stickier lightning addresses#

Lightning addresses are sticky identities, a user with alice@yourwallet.com has a reason to keep the handle live, which means keeping the account live. Inbound Satograms reinforce this: the more sats land in their handle, the higher the switching cost.

What does it cost?#

Honest accounting:

• Engineering effort: roughly 1-3 dev-days for LNURL-pay delivery (configuration check + reading two TLVs off settled invoices). Add 2-5 more dev-days for batch keysend delivery (keysend acceptance + recipient-list parsing + accounting policy for the cut).
• Inbound liquidity: for batch keysends you receive in chunks of up to 50 × per_satogram sats per payment. At the default 1 sat per recipient that’s 50 sats per HTLC, trivial. For most providers this volume is well below normal channel-capacity headroom; you don’t need to provision specifically for Satograms.
• Routing fees: zero. You’re the receiver.
• Ongoing ops: your existing invoice subscriber plus ~50 lines of TLV-parsing code. No new infrastructure.
• Integration fee / token / escrow: none. Opt-in is a one-line config change on our side (your domain + node pubkey added to our opt-in list).

Who’s already integrated?#

A leading Lightning custodial wallet has used the batch keysend path successfully in production. The design was built around their integration pattern, so adopting it means following a well-trodden path, not pioneering.

What you’re agreeing to (and what you’re not)#

What you’re agreeing to:

• Crediting users who appear in TLV 6789998212 of an incoming Satogram payment, on a reasonable best-effort basis.
• Keeping commentAllowed > 0 on your LNURL-pay endpoint so per-recipient delivery works.
• If opting into batch keysend: keeping keysend enabled (LND accept-keysend=true) and your node reachable.

What you’re not agreeing to:

• No SLA. If your node is down, our service tolerates the failures and moves on.
• No mandated UX. How you surface the message to users (notification, transaction history, in-app message inbox) is up to you.

How to get started#

1. Read How it works for the technical model. 10-minute read.
2. Verify your LNURL-pay endpoint meets the requirements. For many wallets this is a one-line config bump on commentAllowed.
3. Add TLV reading to your existing invoice subscriber: Detecting payments.
4. Test on regtest: Testing.
5. If you want the cut: Opt into batch keysends.

Realistic timeline from kickoff to first Satogram credited in production: 1-2 weeks.