Build Non-Interactive Payment Streams with Cashu

Recently, I have been surrounded by people experimenting with various projects, and a common theme among them is the use of cashu as the payment layer. While this fact alone is already great, the best part is to identify users and implementers needs and combining forces to come up with novel solutions.

Subscriptions with Cashu

One of the most remarkable aspects of cashu is that it is a bearer asset. This hands ownership and control back to the user. Even though mints back the tokens, they have no authority to move a token on behalf of a user or any other party. How cool is that?

However, this also introduces challenges when building subscription-based services. Subscriptions typically require periodic payments, and with cashu, users must renew these manually. Currently, there are two primary approaches to address this:

1. Overpaying:
   To minimize the number of interactions, users can pay for longer periods upfront. For example, instead of paying 2,100 sats for one hour, they could pay 6,000 sats for three hours. If they realize they don’t need the full three hours, the excess payment is effectively wasted.

2. Full Interactivity:
   In this setup, payers and receivers stay connected through a communication channel, and payments are made at small, regular intervals. While this avoids overpayment, it requires constant connectivity. If the connection is lost, the subscription ends.

Enter Locking Scripts

One of the most powerful features of cashu is its locking scripts. Let’s take a quick refresher. A locking script defines the conditions under which a token (or "nut") becomes spendable. In essence, it’s similar to Bitcoin’s spending conditions, but instead of being enforced by the Bitcoin network, these conditions are enforced by the cashu mint alone.

A widely-used locking condition is Pay-to-Public-Key (P2PK). This locks a token to a specific public key, meaning it can only be spent when a valid signature from the key’s owner is provided. This mechanism is what enables NIP-61 nut zaps, where a token can be publicly shared but is only claimable by the intended recipient who holds the private key.

To address situations where a recipient loses access to their keys or simply doesn’t claim the token, P2PK includes additional options: locktime and a refund key. These options allow for the inclusion of a fallback mechanism. If the primary lock expires after a set time, a refund key can reclaim the token.

With these tools, we can now create non-interactive payment streams!

One Missing Piece…

Before diving into payment streams, there’s one more crucial concept to cover: cashu tokens are not singular "things". Instead, they’re composed of multiple proofs, each carrying its own cryptographic data and spendability. For example, if you receive a cashu token made up of five proofs, you could choose to claim only three proofs and leave the other two untouched. This flexibility is rarely utilized but is vital for building payment streams.

The Grand Finale: Payment Streams

Now that we have all the building blocks, let’s construct a payment stream using cashu. By leveraging locking scripts, refund keys, and multiple proofs, we can design a token that enables recipients to claim small portions of the total amount at regular intervals—without requiring any further interaction from the sender.

Even better, as the sender, you retain the ability to cancel the stream at any time and reclaim any unspent portions.

Example: Renting a VPS

Imagine renting a VPS for a week, priced at 1,000 sats per day. Here’s how a payment stream could work:

1. Construct a token worth 7,000 sats to cover the entire week.
2. Divide the token into 7 proofs, each worth 1,000 sats.
3. Lock each proof using a P2PK script, locking to your key and adding the recipients key as a refund key.
   • The first proof has a locktime of now.
   • The second proof has a locktime of now + 1 day.
   • The third proof has a locktime of now + 2 days, and so on.

When the token is sent, the receiver can immediately claim the first proof since its locktime has expired and the refund key is now able to claim. The second proof becomes claimable after one day, the third after two days, and so on.

At the same time, the sender retains the ability to reclaim any unclaimed proofs by signing with their key. If you decide to stop using the VPS midweek, you can cancel the stream and reclaim the remaining proofs; all without further interaction with the receiver.

With this approach, we can create robust, non-interactive payment streams that combine the autonomy of cashu with the flexibility to reclaim funds.

Thank you for reading. Make sure to leave a nut if you enjoyed this :)