Read by Guy Swann.

---

One aspect that is still massively under-utilized is the programmability of Bitcoin. While simple things like scheduled payments and automated payment splits do exist, we are undoubtedly still trapped in conventional thinking when it comes to the flow of sats.

I’d like to share a simple idea that was shared with me a couple of months ago in the hopes that it will spread far and wide and, in the best case, that someone will just go ahead and implement it. (Or a better version of it.)

Here is the idea:

All credit to Mr. Kukks, who is now officially out of time¹ to implement it himself.

Lightning Prisms

A Lightning Prism is a construct that allows for “lightning address value split workflows,” to quote the originator.

Here’s the gist of it:

• A prism is identified by a lightning address (or similar)
• A prism has one or multiple recipients
• Another prism can be one of the recipients
• Splits are defined programmatically

This simple construct allows for all kinds of use cases and can be implemented on the application layer without any changes to Bitcoin or Lightning.

One obvious use case is value-splits for blog posts and similar long-form writing. Imagine if every blog post (or book chapter) had its own Lightning address, splitting value to author, editor, illustrator, and proof-readers automatically.

The concept of these value splits already exists in Podcasting 2.0, where it is widely applied to podcasts and episodes. One could argue that having a separate identifier for the split construct is the natural evolution of these payment splits, as it is easier to reason about them and chain them together.

Another obvious use case is the splitting of nostr zaps. Imagine that every “quote-tweet” that gets zapped results in an automated payment split, passing on 50% (or whatever the user has configured) to the original note. Or imagine a prism that’s created on-the-fly, splitting zaps equally for everyone tagged in a note.

Because payments are forwarded, every prism acts as a proxy of sorts. This can be useful for organizations and individuals alike, as your payment identifier remains the same even if your underlying infrastructure or wallet provider changes.

Issues & Improvements

There are two main issues: fees and privacy. One has to account for fees to pay for the splitting and forwarding, but there’s also the issue that lightning addresses are IP-based, which has certain privacy implications. We could do LNURL over nostr—again, shout-out to Kukks—which brings up the following question: Are Lightning Addresses the right level of abstraction for Lightning Prisms?

In the end, we don’t want to send sats to addresses, but to people. If nostr continues to catch on, it might turn itself into the global address book for these kinds of things, i.e., the go-to place to look up payment information of people, organizations, and other entities. In the future, a prism might have multiple nprofile or npub identifiers as targets, behind which the actual payment information lies.

In any case, at this point in time, I’m not too terribly concerned about implementation details. I’m concerned with a lack of imagination, which is what this post is supposed to address.

Speaking of imagination: why don’t we have any spending wallets that automatically move sats to a different wallet above a certain threshold? I’m more than happy to have some lunch money in a custodial wallet, but once it’s worth three months of rent, I’m not as comfortable anymore. Why can’t the wallet automatically send all excess sats to my fully self-sovereign lightning address once it’s more than a dinner’s worth of sats? Or do a loop-out once a month to move the sats to cold storage?

Anyway, I digress.

One improvement I’d love to see is to provide a way to make Lightning Prisms transparent. In the best case, users should have a way to see how payments are split that is both easy to understand and verify. One possibility would be to broadcast a NIP-33 parameterized replaceable event every time a prism is created or updated. Of course, depending on the use case, it might make sense to keep the final destination(s) hidden from public view.

I’m sure there are more issues and plenty of other improvements to be had. But as always, perfect is the enemy of the good, so let’s talk about practical solutions that can be implemented and used right now.

Implementation

Prisms based on lightning addresses can be built today without much effort. You can even build this yourself without any programming experience using two LNbits extensions: scrub & split. Add satdress on top of it all to give every wallet its own lightning address, and voilà, you’ve got yourself a Lightning Prism! You can even build a nice interface as a wrapper around it, as all of the above can be created programmatically with simple API calls.

I did all that (minus the “build a nice interface as a wrapper around it”) just to play around with the idea. Granted, it’s a bit hacky and probably not the most stable or elegant solution, but it kinda works, and it can be used today.

The blogpost@satprism.com address that is shown above is a working example.² It will split any payments 50/50 to Kukks and myself, forwarding the splits to our respective self-sovereign lightning addresses which are provided by our BTCPay Server instances.

I imagine multiple services being created that implement this properly, charging a small fee for providing said service. (As mentioned above, some sort of fee will be required to pay for routing fees, as payments are forwarded to external addresses.)

My hope is that these kinds of ideas and novel constructs become more prevalent as zaps and similar V4V payments—as well as Lightning in general—become more prevalent. Of course, in the best case, we will have these things natively integrated at the protocol level, but I see no reason why we shouldn’t do a little experimentation with what we have today, even if the solutions are imperfect. Until Bolt12 and similar are widespread, hacking something together that just works is probably not the worst idea.³

Final Thoughts

I expect this idea to find widespread adoption among writers and other content creators, just like the idea of “streaming sats”—and the splits of these value streams—found wide adoption among podcasters.

Special-purpose nostr clients for various content types are already in the works, with SubStack- and Medium-like interfaces like BlogStack and Habla popping up left and right.

What’s still missing is attaching payment information to individual events (as opposed to user profiles) in order for each long-form content to have its own payment information. Maybe it’s as easy as extending the NIP-23 metadata, or maybe it would make sense to have this kind of metadata for other event kinds too.

We’ll figure it out, and by “we,” I actually mean you guys: the developers that sit down to spec out and build stuff.

I’ll be cheering you on while I shitpost on nostr.

---

Translations

• German translation by HiP0

Want to help? Add a translation!

All translations »

---

💜

Found this valuable?

Give Value Back

Don't have sats to spare? Consider sharing it, translating it, or remixing it.
Confused? Learn more about the V4V concept.